[Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA

[Martin Kosek]

On 10/13/2014 07:37 PM, Simo Sorce wrote:
> On Mon, 13 Oct 2014 13:24:10 +0200
> Martin Kosek <mkosek at redhat.com> wrote:
> 
>> Hello all,
>>
>> Last week me, Jakub and Stef discussed a design for a candidate for a
>> FreeIPA&Gnome 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.com at 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.com at EXAMPLE.COM can get
>> vault/server.example.com at 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).