On 05/30/2012 01:21 PM, Dmitri Pal wrote: > On 05/30/2012 04:39 PM, Erinn Looney-Triggs wrote: >> On 05/30/2012 12:13 PM, Dmitri Pal wrote: >>> On 05/30/2012 03:44 PM, Erinn Looney-Triggs wrote: >>>> I have for a while had an interest in integrating Google's two factor >>>> auth (https://code.google.com/p/google-authenticator/) into my >>>> environment. However, the code Google gives is close but not there for a >>>> centralized auth setup. >>>> >>>> Now there are other projects to deal with this like totp-cgi >>>> (https://github.com/mricon/totp-cgi) which relies on another PAM module >>>> (pam_url). >>>> >>>> However, it seems to me that SSSD might be an appropriate place for >>>> something like this, so I wanted to gather some thoughts on the >>>> feasibility of integrating two factor auth into SSSD. >>>> >>>> Let me lay out my idea here, and open it up to criticism. >>>> >>>> Essentially Google authenticator uses a shared secret that is held both >>>> on the authenticating system and on the device (your cell phone). This >>>> shared secret then has a bit of magic run on it >>>> (https://tools.ietf.org/html/rfc6238) and if what the user enters and >>>> what is computed match, you are good to go. >>>> >>>> It seems to me that it would be very easy to centrally store this shared >>>> secret (as well as some emergency codes that are generated in case you >>>> lose your phone) in LDAP then retrieve it using SSSD (thus allowing >>>> offline caching). The problem is that the shared secret is, well plain >>>> text, and sensitive, I don't know if there are ways to mitigate this or >>>> not. Is there a secure storage for something like this? >>>> >>>> Second question is, would SSSD be an appropriate use of this, and if so, >>>> is it easy to work into the PAM stack to have this as a second prompt, e.g. >>>> Password: >>>> TOTP: >>>> >>>> Let me know your thoughts, concerns, etc. >>> >>> Here is what were thinking about: >>> >>> https://fedorahosted.org/AuthHub/wiki/ArchitectureDiagrams >>> https://fedorahosted.org/AuthHub/attachment/wiki/ArchitectureDiagrams/Diagram.png >>> >>> Replace PAM box on the diagram with SSSD and you will get the picture. >>> >>> The benefit is that you get a kerberos ticket as a result of the 2FA. >>> >>> Will this meet your needs? >>> >>> >> Thanks Dmitri. >> >> If I am understanding this correctly, the place then for a plugin and >> interface to the google auth shared secret would be on the KDC? Which at >> that point could call out to anywhere and do what it needs to do. >> >> I assume the channel for passing information back would be encrypted and >> authenticated using kerberos from the client to the KDC? >> >> Do you have any more docs or info on how this all is put together? > > Here is the code http://git.fedorahosted.org/git/?p=AuthHub.git;a=summary > > Authub is a plugin to the KDC. It communicates with the back end > processes over the local domain socket. > The back ends are implemented in python, there are several of them > http://git.fedorahosted.org/git/?p=AuthHub.git;a=tree;f=plugins/python;h=db6579768164dd9ca4d2f09e21931e38ecc8ee48;hb=abc1fa62f31c1e82a8849a224f59f661a6381bfb > > The totp one supports the Google authenticator. > > There are two calls that back end needs to implement getTokenInfo - this > returns to the authhub and KDC information about what the user should be > prompted for and then verifyRequest to verify what the user replied with. > These back ends can do the work themselves or proxy the authentication > to another server using a protocol that that server supports. The > security of that communication is based on the attributes of the > protocol. For example yubikey has its own protocol. RADIUS is another one. > The flow is the following. > > 1) Client sends to the server a request > 2) KDC gets request and calls authhub plugin > 3) Authhub plugin enumerates available back ends that can be used for > this user (principal). This part needs to be implemented as currently > there is not DB/policy layer to authhub > 4) Authhub asks the back ends what user should be prompted for rpc call > getTokenInfo() > 5) AuthHub creates a list of the token info structures and KDC sends > them to the client > 6) An appropriate method is chosen on the client side (this is the > tricky part we are investigating now - which one to choose? how? what is > the user experience?) > 7) User is prompted > 8) User provides the requested info > 9) Client sends it to the KDC > 10) KDC passes it to authhub > 11) AuthHub calls RPC call into the bach end that corresponds to the > token info that was chosen > 12) Back end executes verifyRequest() - can send it to a different server > 13) The verifyRequest() returns success, failure or more (not supported > for now) > 14) AuthHub passes status to KDC > 15) In the case of success a TGT is created > 16) The result is sent to client > 17) User is authenticated (or not) and TGT is delivered > > There are several areas that require work so if you are interested in > helping let me know and we can drill down into more details. > a) Server side DB layer: DB driver, storage, management tools > b) Client side prompting and selection - this is complex and requires > more thinking we can probably publish our current thoughts about it if > anyone is interested. > > Thanks > Dmitri > >> In short, yes it looks promising, thanks for the pointer. >> >> -Erinn >>
Hmm ok, thanks for the pointers this is some interesting stuff. Just my off the cuff assessment here on the client side experience but it looks a lot like you are starting to replicate a lot of what PAM does in SSSD (or will need to to create the 2fa user experience). Is there a way to leverage PAM to create that user experience, or am I missing large chunks of the overall picture? -Erinn _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
