[SSSD] Two factor auth using SSSD

Dmitri Pal dpal at redhat.com
Wed May 30 21:21:08 UTC 2012


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
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list