Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
On 05/03/2016 06:11 PM, Nathaniel McCallum wrote: > On Mon, 2016-05-02 at 18:27 +0200, Petr Vobornik wrote: >> Hi Matt, Nathaniel and Simo, >> >> I'd like to kindly check the status of this effort therefore >> resurrecting this thread. >> >> First, Is the design up to date? Are there still aspects which need >> to >> be figured out? > > I do not believe there are any remaining design decisions. > >> Second execution, I see that Matt is about to finish >> https://fedorahosted.org/freeipa/ticket/5782 > > +1 > >> Is it planned to handle CLI and Web UI as a part of ticket >> https://fedorahosted.org/freeipa/ticket/433? If not then I can file >> tickets for it. > > I plan on doing the CLI work. We need a ticket for UI. This should > hopefully be a trivial change. > >> Will the rest be handled with variation of >> https://github.com/npmccallum/freeipa/pull/1 and >> https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de39f28eb6 >> 37f66199da7e9225 >> Or is an additional patch/work needed? > > One additional patch is needed for CLI. UI also needs a patch. > > I will work on the CLI patch and clean up the existing patches. They > should be on the list shortly. > Thanks Nathaniel. Web UI ticket created: https://fedorahosted.org/freeipa/ticket/5872 I expect that it will be implemented by me or Pavel V. -- Petr Vobornik -- 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
On Mon, 2016-05-02 at 18:27 +0200, Petr Vobornik wrote: > Hi Matt, Nathaniel and Simo, > > I'd like to kindly check the status of this effort therefore > resurrecting this thread. > > First, Is the design up to date? Are there still aspects which need > to > be figured out? I do not believe there are any remaining design decisions. > Second execution, I see that Matt is about to finish > https://fedorahosted.org/freeipa/ticket/5782 +1 > Is it planned to handle CLI and Web UI as a part of ticket > https://fedorahosted.org/freeipa/ticket/433? If not then I can file > tickets for it. I plan on doing the CLI work. We need a ticket for UI. This should hopefully be a trivial change. > Will the rest be handled with variation of > https://github.com/npmccallum/freeipa/pull/1 and > https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de39f28eb6 > 37f66199da7e9225 > Or is an additional patch/work needed? One additional patch is needed for CLI. UI also needs a patch. I will work on the CLI patch and clean up the existing patches. They should be on the list shortly. -- 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
Hi Matt, Nathaniel and Simo, I'd like to kindly check the status of this effort therefore resurrecting this thread. First, Is the design up to date? Are there still aspects which need to be figured out? Second execution, I see that Matt is about to finish https://fedorahosted.org/freeipa/ticket/5782 Is it planned to handle CLI and Web UI as a part of ticket https://fedorahosted.org/freeipa/ticket/433? If not then I can file tickets for it. Will the rest be handled with variation of https://github.com/npmccallum/freeipa/pull/1 and https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de39f28eb637f66199da7e9225 Or is an additional patch/work needed? Regards -- Petr Vobornik -- 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
On 02/29/2016 11:35 PM, Nathaniel McCallum wrote: 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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):
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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). > > > > 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. > > > > > - 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. -- 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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 -- 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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? You need to know which tokens to validate. This requires a user dn. 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. 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. > > 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. > > > - 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? -- 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote: > On Thu, 2016-02-25 at 16:51 -0500, 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/a78191 > > > > > > > ee5d > > > > > > > 31 > > > > > > > e1de > > > > > > > 39 > > > > > > >
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
On Thu, 2016-02-25 at 16:51 -0500, 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/a78191 > > > > > > ee5d > > > > > > 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 > > > > > >
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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/a78191ee5d >> 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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/a78191ee5d > > > > > 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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/a78191ee5d > > > > 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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/a78191ee5d31 > > > 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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/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? 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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/a78191ee5d31e1de39 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. Nathaniel -- 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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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. 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
[Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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. -- 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
