Difference between revisions of "Projects/KDC TGS Policy plugin"
(Created page with "{{project-early}} This project implements a plugin interface for the KDC to enable modifying server ticket attributes based on the Pre-authentication indicator. ==Problem== ...") |
|||
| Line 1: | Line 1: | ||
{{project-early}} |
{{project-early}} |
||
| − | This project implements a plugin interface for the KDC to enable |
+ | This project implements a plugin interface for the KDC to enable modification of service ticket attributes based on the Pre-authentication indicator. |
==Problem== |
==Problem== |
||
| − | As an administrator I would like to be able to define the lifetime or other attributes of a service ticket based on the strength of the pre-authentication used. We have high value services that require 2FA and as an added precaution we want to ensure that these service tickets have a shorter lifetime/renew time |
+ | As an administrator I would like to be able to define the lifetime or other attributes of a service ticket based on the strength of the pre-authentication used. We have high value services that require 2FA and as an added precaution we want to ensure that these service tickets have a shorter lifetime/renew time. |
| − | For example: |
+ | For example, it would be possible to configure: |
| − | * |
+ | * Client obtains a TGT using a password, sends TGS_REQ for service fileserver@REALM; returned ticket has a 8 hour lifetime |
| − | * |
+ | * Client obtains a TGT with PKINIT, sends TGS_REQ for service fileserver@REALM; returned ticket has a 2 hour lifetime |
| − | * User C got TGT with PKINIT, asks for a TGS for service fileserver@REALM; returned ticket has a 8 hour lifetime |
||
==Design== |
==Design== |
||
| − | A plugin interface used during process_tgs_req(), separately from the KDB check_policy_tgs, that will accept an indicator and server entry and output a ticket lifetime (renew time?) and/or session key etype. The resulting ticket lifetime can be no longer than the entry max_life (or header ticket lifetime) and the etype can be no weaker than the normally allowed etype. |
||
| + | A new plugin interface is defined with methods that are called during process_tgs_req(). These methods will take the auth indicators (from get_auth_indicators()) and the server db entry as inputs, and output the module-suggested value for an element of the policy (lifetime/renew-time/skey etype) that goes into creating the resulting ticket. |
||
| ⚫ | |||
| + | One design option is to convert the current behavior to be a built-in module that runs in addition to custom modules. |
||
| − | - http://mailman.mit.edu/pipermail/krbdev/2016-September/012664.html |
||
| + | Currently, the ticket times are determined by kdc_get_ticket_endtime() and kdc_get_ticket_renewtime(), using options from the realm profile, request, and db entries. The session key encryption type is determined by select_session_keytype(), called by gen_session_key(). This is shared by the AS req code. The keytype is computed based on the request and what the KDC and KDB can support. |
||
| + | |||
| + | Another option is to leave the current functions alone, and have the plugin method(s) run separately afterwards, replacing the function provided values with the module provided ones. This might be less code and less complexity than option A, allowing for a single method without requiring that the plugin framework runs multiple modules. |
||
| + | |||
| ⚫ | |||
| + | |||
| + | * If multiple modules are supported and each output their desired policy values, how do we decide which to use? |
||
| + | ** For lifetime/renew time; If the plugins should only allow a time less than the built-in time, then use the shortest time from all modules? |
||
| + | ** For session key type; Custom module overrides built-in? |
||
| + | * Is there anything else in the TGS policy that should be influenced by the AI and included in the interface? |
||
Latest revision as of 12:14, 1 May 2017
This project implements a plugin interface for the KDC to enable modification of service ticket attributes based on the Pre-authentication indicator.
Problem
As an administrator I would like to be able to define the lifetime or other attributes of a service ticket based on the strength of the pre-authentication used. We have high value services that require 2FA and as an added precaution we want to ensure that these service tickets have a shorter lifetime/renew time.
For example, it would be possible to configure:
- Client obtains a TGT using a password, sends TGS_REQ for service fileserver@REALM; returned ticket has a 8 hour lifetime
- Client obtains a TGT with PKINIT, sends TGS_REQ for service fileserver@REALM; returned ticket has a 2 hour lifetime
Design
A new plugin interface is defined with methods that are called during process_tgs_req(). These methods will take the auth indicators (from get_auth_indicators()) and the server db entry as inputs, and output the module-suggested value for an element of the policy (lifetime/renew-time/skey etype) that goes into creating the resulting ticket.
One design option is to convert the current behavior to be a built-in module that runs in addition to custom modules. Currently, the ticket times are determined by kdc_get_ticket_endtime() and kdc_get_ticket_renewtime(), using options from the realm profile, request, and db entries. The session key encryption type is determined by select_session_keytype(), called by gen_session_key(). This is shared by the AS req code. The keytype is computed based on the request and what the KDC and KDB can support.
Another option is to leave the current functions alone, and have the plugin method(s) run separately afterwards, replacing the function provided values with the module provided ones. This might be less code and less complexity than option A, allowing for a single method without requiring that the plugin framework runs multiple modules.
Open questions
- If multiple modules are supported and each output their desired policy values, how do we decide which to use?
- For lifetime/renew time; If the plugins should only allow a time less than the built-in time, then use the shortest time from all modules?
- For session key type; Custom module overrides built-in?
- Is there anything else in the TGS policy that should be influenced by the AI and included in the interface?
