On Fri, 2016-02-26 at 15:44 -0500, Nathaniel McCallum wrote: > On Fri, 2016-02-26 at 11:20 -0500, Simo Sorce wrote: > > On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote: > > > 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 wish we had done this the first time. However, this really only makes > complete sense in a post-SPAKE world. > > I actually think we should have a different extop for each 2F type. > Each 2F type can define its own interface (and possibly more than one > round-trip; such as token sync).
Not sure about this. > > > > > 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. > > Consider the case of U2F. I don't think we can ever support LDAP simple > bind with U2F. And I think U2F will be supported long before anything > else. For things like U2F it may make more sense to develop a SASL mechanism, we use SASL for GSSAPI too. > > > > > > - 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. > > I'm missing something here. The idea is that the framework may use the control that the server should fail the bind if 2FA AI is not present on the ticket and re-bind to LDAP before performing a high privilege operation. The bind would fail if the required AI is not present and the higher priv. operation would fail. for normally privileged operation (like listing users) the control 2 require OTP AI wouldn't be sent so a bind would succeed even if original credentials were 1FA. Hope this makes it more clear. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
