[Authentication] Session negotiation

[Stef Walter]

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.

> 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.

> 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.

> 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...

> I'm no longer that sure about the "SupportedAlgorithms" method I proposed 
> earlier. Seems that by making use of an existing crypto-library the generated 
> list might get too exhaustive to make sense.

Yes, I agree.

> Here are various values for the "arguments" of the algorithm name:
> 
> Key-exchange:
> - dh - Diffie-Hellman
> 
> Discrete logarithm groups:
> - ietf<size> - groups from rfc2412 and modp groups from rfc3526
> - do we need other groups? dsa?
> 
> Ciphers:
> - aes128|192|256
> - blowfish
> - twofish
> ...
> 
> Mode:
> - cbc
> - cfb
> - ofb
> (ecb doesn't make sense I think)
> 
> Padding:
> - pkcs7
> 
> All lists (as well as the default format for specifying the algorithm) should 
> be specified as preliminary. Once something new is available in any of the 
> implementations it should be amended to a minor revision of the specification 
> to make sure there aren't 2 names for the same thing.

Right.

Cheers,

Stef