Subject: The use of "name-list" in the core IDs.

From: Chris Lonvick <[email-masked]>
Date: Fri, 3 Dec 2004 09:40:12 -0800 (PST)

Hi,

I would like to make sure that I've made the right changes to the
documents with respect to "name-lists", as I havn't gotten any responses
back from the ID announcements.  Below is the section from [ARCH] that
details a "name-list".  I made very minor edits from [ARCH]-18 to
[ARCH]-19 for this.  Below that are the pertinent changes to the other
IDs.

=========================================================================
5.  Data Type Representations Used in the SSH Protocols

...skip some...

  name-list

      A string containing a comma-separated list of names.  A name-list
      is represented as a uint32 containing its length (number of bytes
      that follow) followed by a comma-separated list of zero or more
      names.  A name MUST be non-zero length, and it MUST NOT contain a
      comma (",").  Context may impose additional restrictions on the
      names; for example, the names in a name-list may have to be valid
      algorithm identifier (see Section 6 below), or [RFC3066] language
      tags.  The order of the names in a name-list may or may not be
      significant.  Again, this depends on the context where the list is
      used.  Terminating NUL characters are not used; neither for the
      individual names, nor for the list as a whole.

       Examples:

       value                      representation (hex)
       -----                      --------------------
       (), the empty name-list    00 00 00 00
       ("zlib")                   00 00 00 04 7a 6c 69 62
       ("zlib", "none")           00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
=========================================================================

Immediately below is the changed section in [TRANS]-21.  "name-list"
replaces "string" in each of the lines below.  Other things were modified
in this section to reflect the changes from "string" to "name-list".  (I
have a typo in [TRANS]-21:  s/listis/lists/  .)
=========================================================================
7.  Key Exchange

   Key exchange (kex) begins by each side sending name-lists of
   supported algorithms.  Each side has a preferred algorithm in each
   category, and it is assumed that most implementations at any given
   time will use the same preferred algorithm.  Each side MAY guess
   which algorithm the other side is using, and MAY send an initial key
   exchange packet according to the algorithm if appropriate for the
   preferred method.

...some skipped...

7.1  Algorithm Negotiation

   Key exchange begins by each side sending the following packet:

     byte         SSH_MSG_KEXINIT
     byte[16]     cookie (random bytes)
     name-list    kex_algorithms
     name-list    server_host_key_algorithms
     name-list    encryption_algorithms_client_to_server
     name-list    encryption_algorithms_server_to_client
     name-list    mac_algorithms_client_to_server
     name-list    mac_algorithms_server_to_client
     name-list    compression_algorithms_client_to_server
     name-list    compression_algorithms_server_to_client
     name-list    languages_client_to_server
     name-list    languages_server_to_client
     boolean      first_kex_packet_follows
     uint32       0 (reserved for future extension)
=========================================================================

Immediately below is the changed section in [AUTH]-24.
=========================================================================
5.1  Responses to Authentication Requests

   If the server rejects the authentication request, it MUST respond
   with the following:

     byte         SSH_MSG_USERAUTH_FAILURE
     name-list    authentications that can continue
     boolean      partial success

   The 'authentications that can continue' is a comma-separated
   name-list of authentication 'method name' values that may
   productively continue the authentication dialog.

   It is RECOMMENDED that servers only include those 'method name'
   values in the name-list that are actually useful.  However, it is not
   illegal to include 'method name' values that cannot be used to
   authenticate the user.

   Already successfully completed authentications SHOULD NOT be included
   in the name-list, unless they really should be performed again for
   some reason.
=========================================================================

All of these changes (and more :) can be found here:
  http://www.employees.org/~lonvick/secsh-wg/2004-nov-29/

Can I get either an "Amen!" for these changes, or some guidance on getting
them aligned with reality?

Thanks,
Chris

---

From: "denis bider" <[email-masked]>
Date: Sat, 4 Dec 2004 13:08:08 +0100

I believe the traditional syntax for name-lists might also be exampled ("",
"zlib", "zlib,none"), because the ("zlib", "none") notation is not what
actually appears in the protocol. Also I'm not sure how the charset is
restricted, but I think it's restricted at least to US-ASCII, if not also
the printable subset of it.

Otherwise I believe it's fine.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Chris Lonvick
> Sent: Friday, December 03, 2004 18:40
> To: [email-masked]
> Subject: The use of "name-list" in the core IDs.
> 
> 
> Hi,
> 
> I would like to make sure that I've made the right changes to 
> the documents with respect to "name-lists", as I havn't 
> gotten any responses back from the ID announcements.  Below 
> is the section from [ARCH] that details a "name-list".  I 
> made very minor edits from [ARCH]-18 to [ARCH]-19 for this.  
> Below that are the pertinent changes to the other IDs.
> 
> Immediately below is the changed section in [TRANS]-21.  
> "name-list" replaces "string" in each of the lines below.  
> Other things were modified in this section to reflect the 
> changes from "string" to "name-list".  (I have a typo in 
> [TRANS]-21:  s/listis/lists/  .) 
> Can I get either an "Amen!" for these changes, or some 
> guidance on getting them aligned with reality?
> 
> Thanks,
> Chris
>

---

From: [email-masked] (Niels Möller)
Date: 29 Dec 2004 21:10:44 +0100

"denis bider" <[email-masked]> writes:

> actually appears in the protocol.

I think it was I who wrote the original version of this text. The
point is to make it clear that the three given examples represents
lists containing zero, one and two elements, on a somewhat abstract
level. In particular, extra clarity is needed for the case of the
empty list.

To me, the proposed text is clear enough.

:        Examples:
: 
:        value                      representation (hex)
:        -----                      --------------------
:        (), the empty name-list    00 00 00 00
:        ("zlib")                   00 00 00 04 7a 6c 69 62
:        ("zlib", "none")           00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65

> Also I'm not sure how the charset is restricted, but I think it's
> restricted at least to US-ASCII, if not also the printable subset of
> it.

I think "anything but comma and NUL" is the only appropriate
restriction at this place (I would even allow NUL, but I guess using
NUL in the elements might be confusing). Context implies additional
requirements: For lists of algorithm identifiers, there are
restrictions to ascii-only, on the length of the elements, and on the
use of the @-character. For lists of language tags, requirements are
different (I'm not really familiar with them). I don't think all those
details need or should be duplicated in the description of the
name-list type. We may want to reuse the same type for new purposes,
even ones using non-ascii identifiers in some way.

> Otherwise I believe it's fine.

To me the proposed text looks fine as is. I won't object if anybody
wants to tweak the syntax used in the examples, but I don't think it
is needed.

Regards,
/Niels