Subject: Re: Further thoughts on PASSDSS

From: Florent Parent <[email-masked]>
Date: Tue, 01 Feb 2005 16:01:13 -0500

In the -01 draft, the mechanism name is PASSDSS-3DES-1, which says use DH 
(DSS), group1 (1), and 3DES. If we extend from there, we could define names 
that would define the key exchange, group and the symmetric algo.

Example:

PASSDSS-AES128-14 could mean use DH with group14 (RFC3526), with 128 bit 
AES.

This would be less flexible than what you're proposing here, but would not 
require any extra round trip from what's currently defined in the draft.

Florent

-- On Wednesday, November 17, 2004 10:54:58 -0500, Ken Murchison wrote:

>
> I was getting ready to respin Chris' PASSDSS draft since we seem to have
> some support for such a mechanism and I started thinking about making it
> more extensible.
>
> http://www.watersprings.org/pub/id/draft-newman-sasl-passdss-01.txt
>
> As currently documented, this mech uses only the required features of
> SSH2: Diffie-Hellman Group 1 key exchange, DSS public key, SHA1 HMAC and
> 3DES cipher.  The big advantage of this is that its fairly simple.  The
> exchange only takes 2 roundtrips and looks something like this:
>
> client sends:
>    authzid
>    authid
>    DH pubkey X
>
> server responds:
>    DSA pubkey params
>    DH pubkey Y
>    available sec layers
>    max sec layer bufsize
>    DSA sig params
>
> client sends (3DES-CBC encrypted):
>    sec layer selection
>    sec layer bufsize
>    password
>    HMAC-SHA1 sig
>
>
> My thought is that we could make this more extensible/flexible by making
> all of these items (key exchange alg, pubkey type, HMAC, cipher)
> selectable/negotiable.  Depending on the key exchange alg, it would add
> at least one more roundtrip (only one for DH).
>
> For simplicity (and to eliminate yet another rountrip), the key exchange
> algorithm wouldn't be part of the exchange, it would be part of the
> mechanism name.  For instance, we'd have SECPASS-DH for Diffie-Hellman
> and SECPASS-FOO for the FOO key exchange method.
>
> The general form of the exchange would be a variation of the original and
> would something look like:
>
> client sends:
>    authzid
>    authid
>    (optional) initial key exch params
>
> server responds:
>    pubkey_algs
>    ciphers
>    hmac_algs
>    (optional) initial key exch params
>
> *(
>    client sends:
>      add'l key exch params
>
>    server responds:
>      add'l key exch params
> )
>
> client sends:
>    pubkey_alg selection
>    cipher selection
>    hmac selection
>    final key exch params
>
> server responds:
>    pubkey params
>    final key exch params
>    available sec layers
>    max sec layer bufsize
>    sig params
>
> client sends (encrypted):
>    sec layer selection
>    sec layer bufsize
>    password
>    HMAC sig
>
>
> The DH variant, with the the ability to have selectable prime/generator
> (per draft-ietf-secsh-dh-group-exchange-04) would look something like:
>
> client sends:
>    authzid
>    authid
>    1024 (min group size)
>    1024 (preferred group size)
>    2048 (max group size)
>
> server responds:
>    "ssh-dss,ssh-rsa" (pubkey_algs)
>    "3des-cbc,aes128-cbc,blowfish-cbc" (ciphers)
>    "hmac-sha1,hmac-sha1-96,hmac-md5" (hmac_algs)
>    p (e.g. group1 prime)
>    g (e.g. group1 generator)
>
> client sends:
>    "ssh-dss" (pubkey_alg selection)
>    "3des-cbc" (cipher selection)
>    "hmac-sha1" (hmac selection)
>    DH param X
>
> server responds:
>    DSA pubkey params
>    DH param Y
>    available sec layers
>    max sec layer bufsize
>    DSA sig params
>
> client sends (3DES-CBC encrypted):
>    sec layer selection
>    sec layer bufsize
>    password
>    HMAC-SHA1 sig
>
>
> For interoperability, we would require certain algorithms/params to be
> implemented such as DH group1, DSS, SHA1, and 3DES (as shown above).
>
> Thoughts?  Is this too complicated?