Re: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA
On 10/13/2014 07:37 PM, Simo Sorce wrote: On Mon, 13 Oct 2014 13:24:10 +0200 Martin Kosek mko...@redhat.com wrote: Hello all, Last week me, Jakub and Stef discussed a design for a candidate for a FreeIPAGnome keyring related thesis: https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa Apparently, there was a misunderstanding when crafting the topic proposal, it is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by SSSD on user log on even in non-password authentication case (like SSO). With SSO, Gnome keyring cannot grab the long term secret to unlock the keyring, the keyring also cannot re-encrypt itself when the long term password changes on the server (this is no problem locally as Gnome keyring is hooked to PAM password change module). Thus, there is the idea to store the master key/AUTHTOK centrally on the server. Given the sensitivity of the password, it would be best to store it in the upcoming FreeIPA Password Vault/KRA: http://www.freeipa.org/page/V4/Password_Vault However, here comes the problem with how to authorize the operation on SSSD level. To make it working, SSSD, host/client.example@example.com would need to be able to retrieve and decipher a key from (any) user's Vault, which is probably not what we want to allow. We may add S4U2Proxy rules so that host/client.example@example.com can get vault/server.example@example.com for the client, but then SSSD could grab any user's secret when he logs in. Are there any ideas how to overcome this issue? Otherwise, it seems that the Vault idea is not the right way. Maybe centralizing access to Gnome keyring is not a good idea at all, we will see. SSSD has access to the user credentials at authentication, that's what it should use to retrieve the user's master key. I am confused. I thought this would only work if someone authenticates with user+password or sends his TGT, right? Otherwise SSSD cannot use user credentials... It is true that authenticating with user+password will still be the most common authentication method on desktop interactive login, so it should cover the most scenarios. Question is if we are even interested in use cases like unlocking GNOME keyring after ssh-ing to a host with Kerberos. Martin Neither using its host key nor s4u2proxy is necessary (nor advisable). ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA
On Tue, 14 Oct 2014 13:21:53 +0200 Martin Kosek mko...@redhat.com wrote: On 10/13/2014 07:37 PM, Simo Sorce wrote: On Mon, 13 Oct 2014 13:24:10 +0200 Martin Kosek mko...@redhat.com wrote: Hello all, Last week me, Jakub and Stef discussed a design for a candidate for a FreeIPAGnome keyring related thesis: https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa Apparently, there was a misunderstanding when crafting the topic proposal, it is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by SSSD on user log on even in non-password authentication case (like SSO). With SSO, Gnome keyring cannot grab the long term secret to unlock the keyring, the keyring also cannot re-encrypt itself when the long term password changes on the server (this is no problem locally as Gnome keyring is hooked to PAM password change module). Thus, there is the idea to store the master key/AUTHTOK centrally on the server. Given the sensitivity of the password, it would be best to store it in the upcoming FreeIPA Password Vault/KRA: http://www.freeipa.org/page/V4/Password_Vault However, here comes the problem with how to authorize the operation on SSSD level. To make it working, SSSD, host/client.example@example.com would need to be able to retrieve and decipher a key from (any) user's Vault, which is probably not what we want to allow. We may add S4U2Proxy rules so that host/client.example@example.com can get vault/server.example@example.com for the client, but then SSSD could grab any user's secret when he logs in. Are there any ideas how to overcome this issue? Otherwise, it seems that the Vault idea is not the right way. Maybe centralizing access to Gnome keyring is not a good idea at all, we will see. SSSD has access to the user credentials at authentication, that's what it should use to retrieve the user's master key. I am confused. I thought this would only work if someone authenticates with user+password or sends his TGT, right? Otherwise SSSD cannot use user credentials... Well isn't this always the case when you do a GDM login ? You are not really going to use the gnome-keyring when you log in via SSH. It is true that authenticating with user+password will still be the most common authentication method on desktop interactive login, so it should cover the most scenarios. Question is if we are even interested in use cases like unlocking GNOME keyring after ssh-ing to a host with Kerberos. No, it doesn't happen today either as most people log in via ssh keys so gnome-keyring would have no password there either even if it were hooked in the sshd PAM stack (which is not). Also I think we could offer an option to cache this key (maybe encrypted in the host keytab (not that it helps much if someone get hold of the machine), so that it always works for offline or password-less logins (think swiping the fingeprint and bypassing SSSD auth altogether). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA
Hello all, Last week me, Jakub and Stef discussed a design for a candidate for a FreeIPAGnome keyring related thesis: https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa Apparently, there was a misunderstanding when crafting the topic proposal, it is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by SSSD on user log on even in non-password authentication case (like SSO). With SSO, Gnome keyring cannot grab the long term secret to unlock the keyring, the keyring also cannot re-encrypt itself when the long term password changes on the server (this is no problem locally as Gnome keyring is hooked to PAM password change module). Thus, there is the idea to store the master key/AUTHTOK centrally on the server. Given the sensitivity of the password, it would be best to store it in the upcoming FreeIPA Password Vault/KRA: http://www.freeipa.org/page/V4/Password_Vault However, here comes the problem with how to authorize the operation on SSSD level. To make it working, SSSD, host/client.example@example.com would need to be able to retrieve and decipher a key from (any) user's Vault, which is probably not what we want to allow. We may add S4U2Proxy rules so that host/client.example@example.com can get vault/server.example@example.com for the client, but then SSSD could grab any user's secret when he logs in. Are there any ideas how to overcome this issue? Otherwise, it seems that the Vault idea is not the right way. Maybe centralizing access to Gnome keyring is not a good idea at all, we will see. Thank you. -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA
On Mon, Oct 13, 2014 at 01:24:10PM +0200, Martin Kosek wrote: Hello all, Last week me, Jakub and Stef discussed a design for a candidate for a FreeIPAGnome keyring related thesis: https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa Apparently, there was a misunderstanding when crafting the topic proposal, it is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by SSSD on user log on even in non-password authentication case (like SSO). With SSO, Gnome keyring cannot grab the long term secret to unlock the keyring, the keyring also cannot re-encrypt itself when the long term password changes on the server (this is no problem locally as Gnome keyring is hooked to PAM password change module). Thus, there is the idea to store the master key/AUTHTOK centrally on the server. Given the sensitivity of the password, it would be best to store it in the upcoming FreeIPA Password Vault/KRA: http://www.freeipa.org/page/V4/Password_Vault However, here comes the problem with how to authorize the operation on SSSD level. To make it working, SSSD, host/client.example@example.com would need to be able to retrieve and decipher a key from (any) user's Vault, which is probably not what we want to allow. We may add S4U2Proxy rules so that host/client.example@example.com can get vault/server.example@example.com for the client, but then SSSD could grab any user's secret when he logs in. Are there any ideas how to overcome this issue? Otherwise, it seems that the Vault idea is not the right way. Maybe centralizing access to Gnome keyring is not a good idea at all, we will see. What about using a new authorization data type for the key. Then only the KDCs on the IPA servers need access to the key. The authorization data can be added to the service ticket of the host the user logs into. Since SSSD does ticket validation by default this service ticket would be available for password based logins as well. bye, Sumit Thank you. -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA
On Mon, 13 Oct 2014 13:24:10 +0200 Martin Kosek mko...@redhat.com wrote: Hello all, Last week me, Jakub and Stef discussed a design for a candidate for a FreeIPAGnome keyring related thesis: https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa Apparently, there was a misunderstanding when crafting the topic proposal, it is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by SSSD on user log on even in non-password authentication case (like SSO). With SSO, Gnome keyring cannot grab the long term secret to unlock the keyring, the keyring also cannot re-encrypt itself when the long term password changes on the server (this is no problem locally as Gnome keyring is hooked to PAM password change module). Thus, there is the idea to store the master key/AUTHTOK centrally on the server. Given the sensitivity of the password, it would be best to store it in the upcoming FreeIPA Password Vault/KRA: http://www.freeipa.org/page/V4/Password_Vault However, here comes the problem with how to authorize the operation on SSSD level. To make it working, SSSD, host/client.example@example.com would need to be able to retrieve and decipher a key from (any) user's Vault, which is probably not what we want to allow. We may add S4U2Proxy rules so that host/client.example@example.com can get vault/server.example@example.com for the client, but then SSSD could grab any user's secret when he logs in. Are there any ideas how to overcome this issue? Otherwise, it seems that the Vault idea is not the right way. Maybe centralizing access to Gnome keyring is not a good idea at all, we will see. SSSD has access to the user credentials at authentication, that's what it should use to retrieve the user's master key. Neither using its host key nor s4u2proxy is necessary (nor advisable). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA
On Mon, 13 Oct 2014 14:15:10 +0200 Sumit Bose sb...@redhat.com wrote: What about using a new authorization data type for the key. Then only the KDCs on the IPA servers need access to the key. The authorization data can be added to the service ticket of the host the user logs into. Since SSSD does ticket validation by default this service ticket would be available for password based logins as well. The KDC has no way to know what is the host the user is logging on, so it would end up sending this data to any host the user logs into (think SSH). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
