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? -- 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
