[Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Nathaniel McCallum]

On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote:
> On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote:
> > 
> > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote:
> > > 
> > > 
> > > https://github.com/npmccallum/freeipa/pull/1
> > > 
> > > The above (pseudo) pull request contains four patches against
> > > FreeIPA
> > > to enable the insertion of Authentication Indicators into
> > > Kerberos
> > > tickets. The basic flow looks like this.
> > > 
> > > First, we patch ipa-pwd-extop to return a control indicating what
> > > authentication method succeeded resulting in a successful bind.
> > > 
> > > Second, we patch ipa-otpd to check the returned control to ensure
> > > that
> > > the bind resulted from an otp validation.
> > > 
> > > Third, we patch ipa-kdb to enable the KDC to return either the
> > > encrypted timestamp or encrypted challenge preauth mechanism when
> > > the
> > > user is configured for optional 2FA logins. Clients can then
> > > decide
> > > whether to do 1FA or 2FA login (for kinit, sane behavior already
> > > exists).
> > > 
> > > Forth, we patch ipa-kdb again to insert hard-coded authentication
> > > indicators for either OTP or RADIUS.
> > > 
> > > Some explanation is required for the first two patches.
> > > Currently,
> > > it
> > > is possible to do a 1FA through the otp preauthentication
> > > mechanism
> > > if
> > > the user is configured for doing optional 2FA. However, because
> > > we
> > > want
> > > to insert an authentication indicator in this code path, we need
> > > to
> > > guarantee that a request going through the otp preauth mechanism
> > > actually validates an OTP. This is the purpose of the control.
> > > 
> > > Items still on the TODO list:
> > > 
> > >   * Authentication Indicator enforcement
> > >     - Upstream libkrb5 needs to grow funcs for reading indicators
> > >     - Schema change to add indicators multi-value attr to
> > > services
> > >     - ipa-kdb needs to implement check_policy_tgs()
> > > 
> > > 
> > >   * SSSD needs to learn to handle optional 2FA
> > > 
> > > I will write up a project page for all of this tomorrow. But this
> > > small
> > > code basically amounts to my brainstorming. It is not ready for
> > > merge,
> > > just basic review.
> > > 
> > It looks mostly ok, however the LDAP control part needs to be done
> > as
> > a
> > request/response pair.
> > A client that wishes to know what kind of authentication happened
> > should
> > send a request control, and only in that case , the server will
> > send
> > the
> > associated reply control with the requested information.
> I just pushed a new version of the control (now merged into a single
> patch): https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de
> 39
> f28eb637f66199da7e9225
> 
> In this version the client sends a critical control with no content
> indicating that the server must validate an OTP. If the LDAP server
> doesn't support the control (for whatever reason), bind will fail. If
> the LDAP server doesn't validate an OTP (for whatever reason), bind
> will fail.
> 
> This approach is simpler and doesn't require a request/response
> control
> pair.

I need some design advice. My goal here is that we need a way to expose
the authentication indicators to services in the FreeIPA UI/CLI.

Here is the good news: users can already set these values in FreeIPA
using kadmin. They do this by simply setting the require_auth string on
the target service principal. Our kdb plugin then encodes these with
the rest of the tl_data into the krbExtraData attribute.

I see two approaches here. First, we can try to manipulate the
krbExtraData attribute directly. Second, we can create a separate
attribute for the authentication indicator strings and then synthesize
the tl_data internally in kdb. We would have to do this for both reads
and writes so as not to break existing kdb functionality.

The trade-off that I see is that the first method complicates the
python framework side where the second method complicates the kdb
plugin.

A third option, which I doubt is even possible, is to use kadmin to
manipulate this option rather than modifying LDAP directly.

Thoughts?