Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt

[Alexey Melnikov <[e-mail]>]

I've started with the easy (editorial) stuff and I will reply to other 
comments after the weekend.

Kurt D. Zeilenga wrote:

>Attached are my raw review notes... mostly editorial,
>clarifications, and such.  I do raise (as Hallvard did)
>some concerns with the realm text.  I'll try to pull
>that issue (and maybe a couple of other issues) out as
>separate threads.
>
>Kurt
>  
>
>>
>>1.    Abstract
>>
>>  SASL provides a method for adding authentication support with an
>>  optional security layer to connection-based protocols.
>>    
>>
>
>SASL needs to be spelled out here (first use in Abstract).
>
Done.

>>  It also
>>  describes a structure for authentication mechanisms.  The result is
>>  an abstraction layer between protocols and authentication mechanisms
>>  such that any SASL-compatible authentication mechanism can be used
>>  with any SASL-compatible protocol.
>>
>>  This document describes how a SASL authentication mechanism is
>>  structured, how a protocol adds support for SASL, defines the
>>  protocol for carrying a security layer over a connection, and defines
>>  the EXTERNAL SASL authentication mechanism.
>>
>>...
>>
>>2.2.  Conventions used in this document
>>
>>  In examples, "C:" and "S:" indicate lines sent by the client and
>>  server respectively.
>>
>>  The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
>>  in this document are to be interpreted as defined in "Key words for
>>  use in RFCs to Indicate Requirement Levels" [KEYWORDS].    
>>
>
>Add U+ convent description (see SASLprep).
>
>  
>
Done.

>>...
>>
>>4.    Authentication mechanisms
>>
>>  SASL mechanisms are named by strings, from 1 to 20 characters in
>>  length, consisting of upper-case letters, digits, hyphens, and/or
>>  underscores.  SASL mechanism names must be registered with the IANA.
>>    
>>
>
>IANA should be spelled out here.
>
Ok.

>>  IETF Standards Track documents may override this registration
>>  requirement by reserving a portion of the SASL mechanism namespace
>>  for their own use; the GSSAPI mechanism specification [SASL-GSSAPI]
>>  does this.  Procedures for registering new SASL mechanisms are given
>>  in the section "Registration procedures".
>>
>>  The "sasl-mech" rule below defines the syntax of a SASL mechanism
>>  name.  This uses the augmented Backus-Naur Form (BNF) notation as    
>>
>
>s/augmented Backus-Naur Form (BNF)/Augmented Backus-Naur Form (ABNF)/
>
Done.

>>  specified in [ABNF] and the ABNF core rules as specified in Appendix
>>  A of the ABNF specification [ABNF].
>>    
>>
>>  sasl-mech    = 1*20mech-char
>>  mech-char    = %x41-5A / DIGIT / "-" / "_"
>>                 ; mech names restricted to uppercase letters,
>>                 ; digits, "-" and "_"
>>
>>
>>
>>
>>
>>
>>A. Melnikov                                             FORMFEED[Page 3]
>>
>>
>>
>>
>>
>>Internet DRAFT                    SASL                    19 August 2003
>>
>>
>>4.1.  Authentication protocol exchange
>>
>>  A SASL mechanism is responsible for conducting an authentication
>>  protocol exchange.  This consists of a series of server challenges
>>  and client responses, the contents of which are specific to and
>>  defined by the mechanism.
>>    
>>
>
>Can't the client challenge the server as well?
>
Rob has already answered this question.

> ...
>
>>  After receiving a challenge, a client mechanism may issue a response
>>  or abort the exchange.  The protocol's profile specifies how each of
>>  these is then represented over the connection.
>>    
>>
>
>Indicate here that mechanisms may also involve challenges to
>the server by the client.
>  
>
See Rob's reply.

>>...
>>
>>  An authorization identity is a string of zero or more ISO 10646
>>  [ISO-10646] coded characters.  The NUL (U+0000) character is not
>>  permitted in authorization identities. The meaning of an
>>  authorization identity of the empty string (zero length) is defined
>>  below in this section. The authorization identity is used by the
>>  server as the primary identity for making access policy decisions.
>>
>>  The character encoding scheme used for transmitting an authorization
>>  identity over protocol is specified in each authentication mechanism
>>  (with the authentication mechanism's blob being further
>>  restricted/encoded by the protocol profile).
>>    
>>
>
>I'm thinking "blob" is not a good word choice here.
>
>  Blob \Blob\ (bl[o^]b), n. [See {Bleb}.]
>     1. Something blunt and round; a small drop or lump of
>        something viscid or thick; a drop; a bubble; a blister.
>        --Wright.
>  
>     2. (Zo["o]l.) A small fresh-water fish ({Uranidea
>        Richardsoni}); the miller's thumb.
>
>>From WordNet (r) 2.0 [wn]:
>
>  blob
>       n : an indistinct shapeless form
>       v : make a spot or mark onto; "The wine spotted the tablecloth"
>           [syn: {spot}, {fleck}, {blot}]
>       [also: {blobbing}, {blobbed}]
>
>       
>You could have meant BLOB (Binary Large OBject), but this seems not to
>fit as well.
>
>I'm thinking "blob" should be replaced with "string".
>
I would rather use "data".

>>  While some legacy
>>  mechanisms are incapable of transmitting an authorization identity
>>  other than the empty string,
>>    
>>
>
>I know of mechanisms which do not transmit an authorization identity...
>but are there ones which only allow transfers of empty authorization
>identity strings?
>
No, I am not aware of any such mechanism

>>  newly defined mechanisms are expected to
>>  be capable of carrying the entire Unicode repertoire (with the
>>  exception of the NUL character). An authorization identity of the
>>  empty string and and an absent authorization identity MUST be treated
>>    
>>
>
>s/and and/and/
>
Yes, already fixed in my diff ;-).

>>  as equivalent.  However, mechanisms SHOULD NOT allow both (i.e. if an
>>
>>
>>
>>A. Melnikov                                             FORMFEED[Page 4]
>>
>>
>>
>>
>>
>>Internet DRAFT                    SASL                    19 August 2003
>>
>>
>>  authorization identity is allowed to be absent, but one is
>>  transferred, it SHOULD NOT be an empty string).
>>    
>>
>
>Suggest this be reworded:
>	However, mechanisms SHOULD NOT allow both.  That is, a mechanism
>	which provides an optional field for an authorization identity,
>	SHOULD NOT allow that field, when present, to be empty.
>  
>
Done (I didn't like the original either, but couldn't think of anything 
better).

>>  This feature permits agents such as
>>  proxy servers to authenticate using their own credentials, yet
>>  request the access privileges of the identity for which they are
>>  proxying.
>>
>>  The server makes an implementation defined policy decision as to
>>  whether the authentication identity is permitted to have the access
>>  privileges of the authorization identity and whether the
>>  authorization identity is permitted to receive service.  If it is
>>  not, the server indicates failure of the authentication protocol
>>  exchange.
>>
>>  As a client might not have the same information as the server,
>>  clients SHOULD NOT themselves try to derive authorization identities
>>  from authentication identities when clients could instead transmit an
>>  authorization identity of the empty string.
>>    
>>
>
>I suggest rewording this:
>	As a client might not have the same information as the
>	server, clients SHOULD NOT derive authorization identities
>	from authentication identities.  Instead, clients SHOULD
>	provide no (or empty) authorization identity when the user
>	has not provided an authorization identity.
>
Ok.

>>...
>>
>>   In this example, the client is proxy
>>  authenticating, sending the authorization id "fred".  The server has
>>  determined the client's identity through IPsec and has a security
>>  policy that permits that identity to proxy authenticate as any other
>>  identity.
>>
>>  To the protocol profile, the four octet sequence "fred" is an opaque
>>  binary blob.  The SASL protocol profile for SMTP specifies that
>>  server challenges and client responses are encoded in BASE64; the
>>  BASE64 encoding of "fred" is "ZnJlZA==".
>>    
>>
>
>s/binary blob/string/
>
I've changed this to "data" instead, as above.

>>...
>>
>>     S: 220 smtp.example.com ESMTP server ready
>>     C: EHLO jgm.example.com
>>     S: 250-smtp.example.com
>>     S: 250 AUTH DIGEST-MD5 EXTERNAL
>>     C: AUTH EXTERNAL ZnJlZA==
>>     S: 235 Authentication successful.
>>
>>8.    IANA Considerations
>>
>>  Registration of a SASL mechanism is done by filling in the template
>>  in section 8.4 and sending it in to [e-mail].  IANA has the
>>  right to reject obviously bogus registrations, but will perform no
>>  review of claims made in the registration form.
>>
>>
>>
>>
>>A. Melnikov                                            FORMFEED[Page 11]
>>
>>
>>
>>
>>
>>Internet DRAFT                    SASL                    19 August 2003
>>
>>
>>  There is no naming convention for SASL mechanisms; any name that
>>  conforms to the syntax of a SASL mechanism name can be registered.
>>  An IETF Standards Track document may reserve a portion of the SASL
>>  mechanism namespace for its own use, amending the registration rules
>>  for that portion of the namespace.
>>
>>  While the registration procedures do not require it, authors of SASL
>>  mechanisms are encouraged to seek community review and comment
>>  whenever that is feasible.  Authors may seek community review by
>>  posting a specification of their proposed mechanism as an internet-
>>  draft.  SASL mechanisms intended for widespread use should be
>>  standardized through the normal IETF process, when appropriate.
>>
>>8.1.  Comments on SASL mechanism registrations
>>
>>  Comments on registered SASL mechanisms should first be sent to the
>>  "owner" of the mechanism.  Submitters of comments may, after a
>>  reasonable attempt to contact the owner, request IANA to attach their
>>  comment to the SASL mechanism registration itself.  If IANA approves
>>  of this the comment will be made accessible in conjunction with the
>>  SASL mechanism registration itself.
>>
>>8.2.  Location of registered SASL mechanism list
>>
>>  SASL mechanism registrations are available at the URL
>>  "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism
>>    
>>
>
>Replace quotes with < and >, and insert a period at the end of the
>sentence.
>  
>
Already done.

>>  description and other supporting material may also be published as an
>>  Informational RFC by sending it to "[e-mail]"
>>  (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]).
>>    
>>
>
>Drop "by sending (...)".
>
Done.

>>...
>>
>>9.    References
>>
>>9.1.  Normative References
>>
>>  [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
>>  ABNF", RFC 2234, November 1997
>>
>>  [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and
>>  Languages", RFC 2277, January 1998
>>
>>  [GSSAPI] Linn, "Generic Security Service Application Program
>>  Interface, Version 2, Update 1", RFC 2743, January 2000
>>
>>  [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) -
>>  Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993.
>>    
>>
>
>For consistency (all other references use tags not associated with
>their document numbers), I suggest replacing the tag [ISO-10646]
>with [UCS].
>  
>
I frankly doubt that this make it any better.

>>  [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
>>  Requirement Levels", RFC 2119, March 1997
>>
>>  [Stringprep] P. Hoffman, M. Blanchet, "Preparation of
>>  Internationalized Strings ("stringprep")", RFC 3454, December 2002.
>>
>>  [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
>>  and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt.
>>
>>  [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work
>>  in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279,
>>  Janyary 1998
>>
>>...
>>
>>12.   Acknowledgments
>>
>>  This document is a revision of RFC 2222 written by John G. Myers
>>  <[e-mail]>. He also wrote the major part of this
>>  document.
>>    
>>
>
>Drop John's e-mail address here.  I suggest replacing the second
>sentence with:
>	He also contributed significantly to this revision.
>
Ok.

>>  Thank you to Magnus Nystrom for the ASCII picture used in section
>>  6.3. 
>>
>
>	Magnus Nystrom provided the ASCII art used in Section 6.3.
>  
>
Ok.

>>  Definition of realm was extracted from RFC 2617 ("HTTP
>>  Authentication: Basic and Digest Access Authentication").
>>
>>  Contributions of many members of the SASL mailing list are gratefully
>>  acknowledged.
>>    
>>
>
>s/mailing list/working group/
>
A lot of contribution was done before we had a working group.
(Not that it worth arguing about anyway.)

>>...
>>
>>Appendix B. IANA considerations
>>
>>  The IANA is directed to modify the SASL mechanisms registry as
>>  follows:
>>    
>>
>
>Please reword this to be not so demanding.  For example,
>	It is requested that IANA update the SASL mechanisms registry
>	as follows:
>  
>
Ok.

Alexey