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 ***@mit.edu
https://mailman.mit.edu/

[Greg Hudson]

Post by 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.

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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Matt Rogers]

Post by Greg Hudson

Post by 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.

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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev