[Authentication] Session negotiation

[Michael Leupold]

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

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.

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.

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

Like this clients will know what they have to implement to be able to 
communicate with any implementation of the spec.
(I don't really have a preference for any of the ciphers, so feel free to 
propose anything you think makes sense).

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.

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.


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/20090715/e3e2609b/attachment.pgp