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

[Simo Sorce]

On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote:
> On Fri, 2016-02-26 at 10:12 -0500, Simo Sorce wrote:
> > On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote:
> > > 
> > > On Thu, 2016-02-25 at 16:51 -0500, Simo Sorce wrote:
> > > > Questions:
> > > > - Should the control specify what kind of auth specifically
> > > > should be
> > > > required ?
> > > I had also wondered that. I'm certainly not against it. But I'd
> > > probably prefer a simple utf8 string value to avoid parsing
> > > complexity.
> > > 
> > > > 
> > > > - 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 ?
> > > I'm personally hoping that we can deprecate ipa-otpd after SPAKE
> > > lands.
> > > Post-SPAKE validations will require a method for validating OTP-
> > > only
> > > (excluding password). This will probably be an extop. The same will
> > > be
> > > true for all new second factors.
> > Why an extop ? I was thinking you'd do a bind with this same control
> > with a string that specifies you want to check only the second
> > factor.
> > (The result of the bind will be positive but you won't be logged in
> > as
> > the user the connection will still be marked anonymous.)
> 
> How can you do this anonymously?

The bind is not done anonymously, but the outcome of the bind operation
is that the user DS sees is the anonymous user (because you didn't use
the first factor at all).

>  You need to know which tokens to
> validate. This requires a user dn.

Sure this is a different concern, I was concerned about the outcome of
the bind operation not its setup.

>  Besides, I would think we also want
> to be bound *before* performing this operation. Otherwise, we could
> allow brute force tries on the 2nd factor.

Yes, this is a concern, but only with HOTP, with TOTP, you cannot really
brute force easily as you have to wait 30 sec. between each try
(assuming we mark the current OTP has been used and immediately return
an error on any further attempt ?)

We can also still lock the user account if too many attempts are
performed.

However it is a concern indeed.

> I was thinking:
> 1. Bind as the entity validating the 2nd factor.
> 2. Extop which takes the:
>    * user dn
>    * type of 2nd factor
>    * validation data
>    * dn of 2nd factor (optional)
> 
> This provides an audit trail of who is validating 2nd factors.

Ok, this makes sense.
I wish we didn't have to create yet another extop, but if we want to
gate the check via another bind it makes sense.

> > > I'm thus not sure if we'll ever add more second factors to the
> > > existing
> > > simple bind mechanism.
> > LDAP binds still need to test both factors if they are required ...
> 
> We would grandfather OTP. But all new 2FA would require GSSAPI (using
> AIs) to use LDAP.

I do not think we can enforce this, we still have a lot of deployments
that rely on LDAP binds to check credentials, and we should try to
support this as much as possible.

> > > > - 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 ?)
> > > That seems to me like a decision LDAP can make internally. No?
> > Not if the user has optional 2FA and you want to enforce the second
> > factor only for certain operations from the framework (like say
> > changing
> > passwords or other more privileged operations).
> 
> Why can't we just use GSSAPI with AIs?

We would! But the AI check would be done (optionally) for the LDAP
server, not the HTTP service, remember that we do s4u2proxy and use
GSSAPI auth from the framework.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York