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

Mon Feb 29 22:35:31 UTC 2016

On Fri, 2016-02-26 at 09:00 +0100, Martin Kosek wrote:
> On 02/25/2016 10:51 PM, Simo Sorce wrote:
> > 
> > On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote:
> > > 
> > > On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote:
> > > > 
> > > > On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote:
> > > > > 
> > > > > 
> > > > > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 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/a781
> > > > > > > 91ee5d
> > > > > > > 31
> > > > > > > e1de
> > > > > > > 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?
> > > > > We should translate it, we need that to allow to delegate
> > > > > access
> > > > > only
> > > > > to
> > > > > the specific attribute via our standard means.
> > > > > 
> > > > > We already do this for other tl_data entries.
> > > > > 
> > > > > The krbExtraData access cannot always be delegated because it
> > > > > would
> > > > > be
> > > > > open ended. also it is really obnoxious to have to manipulate
> > > > > ASN.1
> > > > > stuff in the framework.
> > > > > 
> > > > > kadmin could be used at some point, but we'd still want to
> > > > > have
> > > > > this
> > > > > attribute extracted in order to be able to grant access
> > > > > control
> > > > > individually, as our ACL system and delegation system is more
> > > > > fine
> > > > > grained than what kadmin can offer.
> > > > After discussing this with MIT, Simo and Matt, it seems that
> > > > the best
> > > > option is to update the (MIT) upstream krbPrincipal objectClass
> > > > to
> > > > have
> > > > a new attribute. The reason for this is twofold. First, it has
> > > > upstream
> > > > value. Second, we don't have good objectClass to attach the new
> > > > attribute to inside FreeIPA.
> > > > 
> > > > So the current plan is that Matt will create a patch for
> > > > storing auth
> > > > indicators (specifically, the "required_auth" strings) in a new
> > > > multi-
> > > > value string attribute on krbPrincipal objects. The
> > > > get_principal()
> > > > KDB
> > > > hook will read "required_auth" from krbExtraData or (if
> > > > present,
> > > > preferred) the new attribute. In turn, the put_principal() KDB
> > > > hook
> > > > will store "required_auth" in the new attribute. This will
> > > > allow the
> > > > transparent migration of any data currently stored in
> > > > krbExtraData.
> > > > 
> > > > As part of this process, Matt will also refactor
> > > > put_principal() into
> > > > smaller functions (it is currently 800+ LOC).
> > > > 
> > > > Once we have an attribute in upstream krbPrincipal, we will use
> > > > this
> > > > attribute exclusively in our KDB plugin.
> > > I have started a project page:
> > > http://www.freeipa.org/page/V4/AuthenticationIndicators
> Thanks Nathaniel! For starters, I moved the page to
> http://www.freeipa.org/page/V4/Authentication_Indicators
> to make sure the URL is consistent with other pages ;-)
> 
> I also updated the Use Cases and added the User Story I am tracking
> with this
> feature:
> http://www.freeipa.org/page/V4/Authentication_Indicators#Strong_Authe
> ntication_on_Selected_System
> 
> > 
> > > 
> > > We are still waiting on some details. But the general shape of
> > > things
> > > is there. Please review. :)
> > LGTM so far.
> > 
> > Questions:
> > - Should the control specify what kind of auth specifically should
> > be
> > required ?
> > 
> > - Will it make sense in future to have different strength otp-like
> > second factors and have ipa-otpd be able to specify which one it is
> > expecting to be validated ?
> > 
> > - Even if ipa-otpd will not grow such a feature, I see this control
> > could be useful for pure LDAP auth clients, so perhaps a different
> > kind
> > of client may want to set this control ? Perhaps one day we can
> > have a
> > way to do GSSAPI auth and check that the AI on the ldap ticket was
> > a 2FA
> > and then DS will refuse login if the otp AI was missing on the
> > ticket it
> > received and the control requires it ? (could be used for the IPA
> > UI
> > connection to LDAP maybe ?)
> It would be also nice to add some graph how the workflows look like.
> It may be
> something based on Simo's picture he created some time back
> (attached).

How's this (attached)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: indicators.png
Type: image/png
Size: 79761 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20160229/83e3bccf/attachment.png>