Projects/KDC TGS Policy plugin

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

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?