[Authentication] Fwd: Re: Session negotiation

[Michael Leupold]

On Thursday 16 July 2009 13:52:57 Brad Hards wrote:
> On Thursday 16 July 2009 20:47:51 Michael Leupold wrote:
> > > We need to generate the key from some kind of passphrase (or other
> > > source, but passphrase is what I expect from this). So we need to
> > > define how to produce the key, and we need to store the IV with the
> > > ciphertext version of the secret. I think each secret should be
> > > encrypted separately (and so have a different IV).
> >
> > As I imagine it, the symkey used for secret transport will be assembled
> > from random values using diffie-hellman. And yes, due to the constraints
> > mentioned above we'd really have to send ivs along each of the secrets.
>
> I think there are two different issues here.
>
> Are the secrets going to be transferred in encrypted or decrypted form?
> That is, does the application-side library do the decryption, or is it done
> on the storage side? I'm assuming that the storage side will decrypt them
> from whatever disk encryption is used, and they will be transferred using
> dbus to the application in a decrypted (but optionally covered by DH) form.

Yes, I fully agree and I guess it's meant like that.

> In addition, the decryption key (or passphrase analog) for the disk
> encryption needs to go across dbus.

No. Methods to unlock secrets on disk are not part of the specification and 
meant to be implementation-specific. Current Keyring and KWallet 
implementations gather this key on the service-side (Keyring uses a pinentry-
style program, KWallet's dialog is built-in). Additionally Keyring provides 
unlocking using a pam module. Additionally services might implement other 
means to get the key (eg. use a Smartcard).

The specification tries to completely abstract from how and where collections 
are stored and encrypted. As gathering the secrets without the client is 
feasible and generally more secure (transport encryption is not required) I 
really prefer this approach.

> So there is a need to protect the session using some kind of transport
> security (e.g. DH, per the spec), but also to provide the key to decrypt
> the store. I note http://www.gnome.org/~stefw/secrets/html/ch08.html says
> "This specification does not mandate the use of master passwords to lock a
> collection of secrets. The service may choose to implement any method for
> authenticating secrets." but if the service is not required to provide
> secure storage, then what is it offering? If it might need to use an
> interoperable passphrase to provide key for the storage side, we need to
> define that approach.

see above.

Regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/authentication/attachments/20090716/96a027dc/attachment-0001.pgp