Re: [psg.com #460] IESG - Transport - Oakley

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi Folks,

>From all of the notes on this subject, it looks like we may have some
consensus on how to address this issue.  Many thanks to everyone who
partifipated in this discussion; it helps to move us forward.  I believe
that this is going to require edits to 4 places in the documents.


[TRANSPORT] - revise section 8.1 (formerly titled
"diffie-hellman-group1-sha1")

8.1 Required Key Exchange Methods

   Two methods for key exchange are defined in this document.

   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit
   MODP Group).  This method MUST be supported for interoperability as all
   of the known implementations currently support it.

   The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit
   MODP Group), and it MUST also be supported.



[NUMBERS] - Add a line in the current Section 4.3

4.3  Key Exchange Method Names

   The Key Exchange Method Name describes a key-exchange method for the
   protocol [SSH-TRANS].  The names MUST be printable US-ASCII strings,
   and MUST NOT contain the characters at-sign ('@'), comma (','), or
   whitespace or control characters (ASCII codes 32 or less).  Names are
   case-sensitive, and MUST NOT be longer than 64 characters.

   Requests for assignment of new key-exchange method names must be
   accompanied by a reference to a standards-track or Informational RFC
   which describes this method.

   Method name                   Reference
   ------------                  ---------
   diffie-hellman-group1-sha1    [SSH-TRANS, Section 8.1]
   diffie-hellman-group14-sha1   [SSH-TRANS, Section 8.1]



[ARCHITECTURE]  (2 changes needed)

(1)
Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically names
diffie-hellman-group1-sha1.  This can be changed to "the key exchange
methods described in Section 8.1 in [TRANS]".

(2)
A new section 9.2.8 will be needed to discuss the ordering of key exchange
method proposals.  Currently, [TRANS] Section 7.1 states:
-------------------
         kex_algorithms
         Key exchange algorithms were defined above.  The first
         algorithm MUST be the preferred (and guessed) algorithm.  If
         both sides make the same guess, that algorithm MUST be used.
         Otherwise, the following algorithm MUST be used to choose a key
         exchange method: iterate over client's kex algorithms, one at a
         time.  Choose the first algorithm that satisfies the following
         conditions:
         +  the server also supports the algorithm,
         +  if the algorithm requires an encryption-capable host key,
            there is an encryption-capable algorithm on the server's
            server_host_key_algorithms that is also supported by the
            client, and
         +  if the algorithm requires a signature-capable host key,
            there is a signature-capable algorithm on the server's
            server_host_key_algorithms that is also supported by the
            client.
         +  If no algorithm satisfying all these conditions can be
            found, the connection fails, and both sides MUST disconnect.
-------------------
The proposed new section in [ARCH] will say:

   As stated in Section 7.1 of [TRANS], each device will send a list of
   methods for key exchange.  The preferred method will be the first in
   the list.  The preferred method SHOULD be the cryptographically
   strongest method, and the method most likely to satisfy the conditions
   stated in that section.  Of the two methods defined in Section 8.1 of
   [TRANS], diffie-hellman-group14-sha1 MUST be listed before
   diffie-hellman-group1-sha1 in the kex list.  Implementors are
   encouraged to review current literature to decide upon the order of any
   other locally defined kex methods listed in the kex proposal.




These edits do _not_ address the following items:

- Parameterizing the kex namespace.

- Using SSH"group1" when we mean IKE"group2".  From what I understand,
making changes to this would have interoperability ramifications to the
deployed products.

- Referencing DH-GEX.

If there is strong consensus from the WG that any of these issues really
needs to be addressed, I will work on them.



Can I get some feedback on these proposed changes and the items I'm not
addressing?

Thanks,
Chris