[psg.com #460] IESG - Transport - Oakley - new proposal

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

Hi Folks,

I've gone through all of the notes on this Issue again and now have
6 changes to make to the documents for this.

---------------------
(1)
[TRANSPORT] - revise section 6.5

6.5  Key Exchange Methods

   The key exchange method specifies how one-time session keys are
   generated for encryption and for authentication, and how the server
   authentication is done.

   Two REQUIRED key exchange method has been defined:

     diffie-hellman-group1-sha1       REQUIRED
     diffie-hellman-group14-sha1      REQUIRED

   These methods are described later in this document.

   Additional methods may be defined as specified in [SSH-NUMBERS].
   Note that, for historical reasons, the name
   "diffie-hellman-group1-sha1" is used for a key exchange method using
   Oakley Group 2. This is considered an aberration and should not be
   repeated. Any future specifications of Diffie Hellman key exchange
   using Oakley groups defined in [RFC2412] or its successors should be
   named using the group numbers assigned by IANA, and names of the form
   "diffie-hellman-groupN-sha1" should be reserved for this purpose.

---------------------
(2)
[TRANSPORT] - revise section 8.1

8.1 diffie-hellman-group1-sha1

   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.  Note that, for
   historical reasons, this method is named using the phrase "group1"
   even though it specifies the use of Oakley Group 2.

---------------------
(3)
[TRANSPORT] - add section 8.2

8.2 diffie-hellman-group14-sha1

   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.

---------------------
(4)
[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.2]

---------------------
(5)
[ARCHITECTURE]  modify 9.2.7 (Security Considerations for TRANS)
Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically
names diffie-hellman-group1-sha1. I'd like to reference both defined
key exchange methods in this section.

Current extract from 9.2.7
   SSH sessions resulting from a key exchange using
   diffie-hellman-group1-sha1 are secure even if private keying/
   authentication material is later revealed, but not if the session
   keys are revealed.  So, given this definition of PFS, SSH does have
   PFS.
Change to:
   SSH sessions resulting from a key exchange using
   diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1
   are secure even if private keying/
   authentication material is later revealed, but not if the session
   keys are revealed.  So, given this definition of PFS, SSH does have
   PFS.

---------------------
(6)
[ARCHITECTURE]  new section 9.2.8 (Security Considerations for TRANS)
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
   preferred methods for key exchange.  The most-preferred method is the
   first in the list.  Implementations are free to determine their default
   preferences based upon relative cryptographic security, performance
   or other criteria.  If only the two methods defined in Section 8 of
   [TRANS] are are implemented, it is RECOMMENDED that
   diffie-hellman-group14-sha1 be listed before
   diffie-hellman-group1-sha1 in the kex list.

---------------------
Please send back your comments to this proposal.

Thanks,
Chris