[SSSD] Two factor auth using SSSD

Erinn Looney-Triggs erinn.looneytriggs at gmail.com
Mon Jun 4 17:44:03 UTC 2012


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






More information about the sssd-devel mailing list