[Authentication] Session negotiation

[Michael Leupold]

On Wednesday 15 July 2009 19:32:51 Stef Walter wrote:
> Michael Leupold wrote:
> > Regarding session negotiation we'll have to settle on a format for
> > algorithm names. I'd propose the following default format:
> > <key-exchange>-<dlgroup>-<cipher>-<mode>-<padding> (case shouldn't
> > matter) eg. dh-ietf1024-blowfish-cbc-pkcs7
> > or the alternative value "plain" (like already specified).
>
> Yes, I think that we'll need to come up with one or more specific
> strings like that.
>
> I think that negotiating specific parts of the algorithm (for example
> the cipher) is overkill. These should come in precanned sets. I believe
> that's how you envision it too.

Yeah, might indeed be easier :-) I'm just not entirely sure how to.

> > The input argument for Diffie-Hellman would then be:
> > struct
> > {
> >    Array<Byte> clientPubKey;
> >    Array<Byte> initializationVector;
> > };
> >
> > I think the Secret structure should be reduced to
> > struct Secret
> > {
> >   Variant parameter;
> >   Array<Byte> value;
> > }
> > I don't see a need to re-name the algorithm as that should already be
> > negotiated for the session.
>
> Hmmm, but nothing in the API prevents algorithms from being
> renegotiated. In crypto stuff you often see (algorithm, parameter,
> value) triples. I was following this convention.
>
> I also sort of imagine secret structs being stored in the client side,
> and it would be useful to know the algorithm of a secret struct.
>
> But I'm not stuck on this if you think that it's important not to have
> the algorithm.

I'd rather see renegotiation using Session.Negotiate. In my opinion it would 
make the API cleaner. While secret structs may be stored on the client side I 
don't see much benefit of keeping it encrypted vs. storing it deciphered in 
non-pageable memory to keep it secure. After all the secret used for 
decryption will be around as well.

> > For diffie-hellman parameter could be empty as transmitting the
> > initialization vector on session start should be enough. value would
> > simply be the value encrypted using the negotiated cipher.
>
> The Secret.parameter value would include an IV for the cipher, right?
> Obviously a cipher without an IV opens itself up to all sorts of
> attacks. This is reflected by the fact that most chaining modes have IVs.

I imagined the IV to be transmitted once during negotiation. The constructed 
cipher would then be used in streaming mode. As far as I understand it we 
wouldn't need to retransmit the iv as the service as well as the client would 
just keep some handle to an encryption struct around (eg. gcry_cipher_hd_t for 
gcrypt). Please tell me if I'm completely getting this wrong.

> > There should be a least common denominator so I'd like to add:
> > Implementations conforming to this spec MUST implement at least one of
> > the following algorithms:
> > - plain
> > - dh-ietf1024-aes128-cbc-pkcs7
>
> Good. Let's also reference the specs for each bit.
>
> However I don't think clients would need to implement anything but
> 'plain'. For VM languages (java, python, C#) it doesn't make sense to
> try to keep secrets in secure memory, so it's useless to make them
> handles specially when traversing dbus.
>
> Note that this encryption of secrets in transit is primarily to prevent
> passive attacks, such as accidentally writing a secret to a paging file.
> It allows a client application and the service to cooperate to keep the
> secret from being exposed accidentally.
>
> This encryption does not prevent active attacks, such as mitm on the
> dbus bus, or a nefarious application sending simulated X events etc...

Completely agree.
-------------- 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/20090715/e2156ce7/attachment-0001.pgp