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.
-Erinn
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/Diagra...
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?
-Erinn _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
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/Diagra...
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?
In short, yes it looks promising, thanks for the pointer.
-Erinn
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/Diagra...
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=db6...
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
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/Diagra...
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=db6...
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.
- Client sends to the server a request
- KDC gets request and calls authhub plugin
- 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
On 06/04/2012 01:44 PM, Erinn Looney-Triggs wrote:
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/Diagra...
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=db6...
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.
- Client sends to the server a request
- KDC gets request and calls authhub plugin
- 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?
I do not think PAM renders itself well for what we are trying to do here. Authentication back ends need to make a decision about what to prompt user for. This data is known to the KDC and passed over the RPC using JSON. There is no way to convey it via PAM interface. Also PAM would require loading back ends into the memory of KDC. You really do not want the back end error/core to bring the KDC down. If the back end dies it will be restarted automatically on the next request.
These are just couple reasons why. I remember there have been more but I do not recall them. The RPC mechanism with separate back end processes seems to be most logical architecture.
-Erinn
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Erinn Looney-Triggs