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?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Feb 2005 20:20:26 -0500

On Tuesday, February 01, 2005 04:01:13 PM -0500 Florent Parent 
<[email-masked]> wrote:

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

A couple of key points here...

- "DSS" and "DH" do _not_ mean the same thing.  "DSS" is a public key
  signature algorithm; DH is a public key exchange mechanism.

- The SSH key exchange algorithm 'diffie-hellman-group1-sha1' does not
  use Oakley group 1; it uses group 2.

- The naming rules for SSH algorithms are different from those for SASL
  mechanisms.  SSH algorithm names can be up to 64-characters long and
  are case-sensitive.  SASL mechanism names have a maximum length of
  20 characters and may not contain lowercase letters.  Thus, it is not
  possible to map the entire SSH mechanism namespace onto unique SASL
  mechanism names, let alone unique partial SASL mechanism names.  Thus,
  a registry is unavoidable.

Chris's original draft proposes a DH exchange signed by DSS.  The DSS
key format used is the same as that used by SSH, but the protocol is not
the same as that used by SSH's Diffie-Hellman based key exchanges.  It 
would make sense to substitute alternative signature algorithms, symmetric 
ciphers, hashes, and DH groups into Chris's proposal, and to provide a 
method for negotiating these either via the mechanism name or via an 
exchange performed after the mechanism is selected.

However, it does _not_ make sense to negotiate an alternate ssh keyex 
algoritm, because the mechanism as defined does not make use of an SSH 
keyex algorithm.

In short, either of these approaches look interesting to me, except:

- "DSS" does not mean "DH"; it means "DSS".
  So PASSDSS-AES128-14 means this mechanism (which is always based on
  DH, since this is a part of its design) with DSS as the signature
  algorithm, 128-bit AES as the cipher, and group 14.  It does not
  provide a way to negotiate the hash.

- SECPASS-FOO does not mean "use the SSH keyex algorithm FOO", because
  that is nonsensical - neither Chris's document nor Ken's proposal
  actually uses an SSH keyex algorithm.  Rather, SECPASS-FOO would be
  its own SASL mechanism, likely designed along the same lines, but
  requiring its own specification.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Feb 2005 20:20:26 -0500