Authentication strength and ticket policy

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Authentication strength and ticket policy

Matt Rogers
On the call we briefly discussed the request to be able to influence
the ticket lifetime based on the preauth method used (ie. shorter
lifetimes for 2FA tickets).  It would be good to continue the
discussion here. 

To summarize, my understanding is that there is not a good way to do
this with auth indicators and the current AS/TGS policy code. The
authentication level may be desireable for influencing not just ticket
lifetime but other bits of policy, like the session key type, so we
would need a type of KDC policy interface (KDB?) in order to be
sufficiently generic. Then at that point plugins can be written to
support these kinds of policy decisions.

Regards,
Matt
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Authentication strength and ticket policy

Greg Hudson
On 09/13/2016 03:57 PM, Matt Rogers wrote:
> On the call we briefly discussed the request to be able to influence
> the ticket lifetime based on the preauth method used (ie. shorter
> lifetimes for 2FA tickets).  It would be good to continue the
> discussion here.

We could either implement this feature request completely within the
core krb5 code, or merely make it possible to implement using plugin
modules.  The first option is difficult; our database schema isn't
especially malleable, and making ticket lifetimes conditional on
authentication indicators would require adding a lot of complexity to
it.  So I think it's more likely that we would enable the feature to be
implemented using plugin modules.

There are currently a few external interfaces for policy checking within
the KDB interface.  The relevant ones (check_policy_as and
check_policy_tgs) are inadequate for this feature for two reasons: they
do not receive the authentication indicators as an input, and they
cannot influence ticket lifetimes as an output.

Also, while having policy interfaces only within the KDB interface is
adequate for FreeIPA and similar integrations, it makes it impossible to
influence policy from a plugin module without also writing a complete
KDB module.  That's why I favor creating a separate KDC policy
interface.  Separating KDC policy interfaces from KDB interfaces also
allows us to better control the complexity of the KDB interface.

(Note that a single shared object can implement multiple module
interfaces.  Also, a policy module implemented within the same shared
object as a KDB module could still access the database by retrieving the
database handle from the krb5_context object.)
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Authentication strength and ticket policy

Matt Rogers
On Wed, Sep 14, 2016 at 11:51 AM, Greg Hudson <[hidden email]> wrote:

> On 09/13/2016 03:57 PM, Matt Rogers wrote:
>> On the call we briefly discussed the request to be able to influence
>> the ticket lifetime based on the preauth method used (ie. shorter
>> lifetimes for 2FA tickets).  It would be good to continue the
>> discussion here.
>
> We could either implement this feature request completely within the
> core krb5 code, or merely make it possible to implement using plugin
> modules.  The first option is difficult; our database schema isn't
> especially malleable, and making ticket lifetimes conditional on
> authentication indicators would require adding a lot of complexity to
> it.  So I think it's more likely that we would enable the feature to be
> implemented using plugin modules.
>
> There are currently a few external interfaces for policy checking within
> the KDB interface.  The relevant ones (check_policy_as and
> check_policy_tgs) are inadequate for this feature for two reasons: they
> do not receive the authentication indicators as an input, and they
> cannot influence ticket lifetimes as an output.
>
> Also, while having policy interfaces only within the KDB interface is
> adequate for FreeIPA and similar integrations, it makes it impossible to
> influence policy from a plugin module without also writing a complete
> KDB module.  That's why I favor creating a separate KDC policy
> interface.  Separating KDC policy interfaces from KDB interfaces also
> allows us to better control the complexity of the KDB interface.
>
> (Note that a single shared object can implement multiple module
> interfaces.  Also, a policy module implemented within the same shared
> object as a KDB module could still access the database by retrieving the
> database handle from the krb5_context object.)

(Resurrecting this thread now that I'm able to look into this feature
some more). I've added some design considerations for the plugin
approach to a wiki page:
https://k5wiki.kerberos.org/wiki/Projects/KDC_TGS_Policy_plugin
Comments and edits are welcome!

Regards,
Matt
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Loading...