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

["denis bider" <ietf-ssh%denisbider.com@localhost>]

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: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Chris Lonvick
> Sent: Friday, December 03, 2004 18:40
> To: ietf-ssh%NetBSD.org@localhost
> 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.
> 
> ==============================================================
> ===========
> 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
>