Editotorial changes (was Re: sasl-rfc2222bis review notes [long])

[Alexey Melnikov <[e-mail]>]

Kurt D. Zeilenga wrote:

>>  The Simple Authentication and Security Layer (SASL) provides a method
>>  for adding authentication support with an optional security layer to
>>  connection-based protocols.
>>    
>>
>
>As used here, the word "optional" implies that protocols MAY
>include security layer support.
>
In theory a protocol profile can disallow usage of a SASL security layer.

>Suggest this be reworded
>
>	The Simple Authentication and Security Layer (SASL) is a
>	framework for providing authentication and data security
>	services in connection-based protocols.
>
I like that.

>>                               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, describes 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.
>>    
>>
>
>It might be better to transpose EXTERNAL and SASL here.
>
Done.

>>2.    Organization of this document
>>
>>2.1.  How to read this document
>>
>>  This document is written to serve several different audiences,
>>  protocol designers using this specification to support authentication
>>  in their protocol, mechanism designers that define new SASL
>>  mechanisms, and implementors of clients or servers for those
>>  protocols using this specification.
>>    
>>
>
>I suggest using a bullet list for the above.
>
Sounds good.

>
>
>...
>
>>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].
>>
>>  Character names in this document use the notation for code points and
>>  names from the Unicode Standard [Unicode].  For example, the letter
>>  "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
>>
>>  This document uses terms "integrity protection" and "confidentiality
>>  protection".  The former references to a security layer that is able
>>  to detect data modification by using some kind of hash.  However,
>>    
>>
>
>I suggest the "by using some kind of hash" qualification be dropped.   
>The term "integrity protection" applies to any layer which is capable
>of detecting data modification (regardless of whether it using some
>kind of hash or not).  I suggest:
>
>    The term "integrity protection" refers to a security layer         
>    designed to detect unauthorized data modification.
>
Ok
...

>>  authentication mechanism to be defined once, making it usable by any
>>  SASL protocol profile.  In many implementations, the same SASL
>>  mechanism code is used for multiple protocols.
>>    
>>
>
>Add another (see above) subsection which
>
>X.Y. Relationship to other documents
>
>    This document obsoletes RFC 2222.  It replaces all portions of
>    RFC 2222 excepting sections 7.1 (Kerberos version 4 mechanism),
>    7.2 (GSSAPI mechanism), 7.3 (S/Key mechanism).  The Kerberos
>    version 4 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now        
>    viewed as obsolete.  The GSSAPI mechanism is now separately 
>    specified [SASL-GSSAPI].
>
I've added this as "Appendix B". The detailed list of changes in now 
Appendix C.

>>  Procedures for registering new SASL mechanisms are given in section 8.
>>
>>  The "sasl-mech" production below defines the syntax of a SASL
>>  mechanism name.  This uses the Augmented Backus-Naur Form (ABNF)
>>  notation as 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 ASCII uppercase letters,
>>                 ; digits, "-" and "_"
>>
>>    
>>
>
>I suggest this comment be replaced with:
>        ; mech-char is restricted to "A"-"Z", "0"-"9", "-", and "_"
>        : from ASCII character set.
>
Done

>...
>
>>5.2.  Mechanism profile guidelines
>>
>>  Designers of new SASL mechanism should be aware of the following
>>  issues:
>>
>>  1) Authorization identity.
>>    
>>
>
>Remove the "."
>
Ok.

>>6.1.1.  Client sends data first examples
>>
>>  The following are two examples of an SECURID authentication [SASL-
>>  SECURID] in the SMTP protocol [SMTP].  In the first example below,
>>  the client is trying fast reauthentication by sending the initial
>>  response:
>>
>>     S: 220-smtp.example.com ESMTP Server
>>     C: EHLO client.example.com
>>     S: 250-smtp.example.com Hello client.example.com, pleased to meet you
>>    
>>
>
>This line is too long.  Suggest you s/Hello.*/Welcome client.example.com/
>
Done.

>>     S: 250-AUTH GSSAPI SECURID
>>     S: 250 DSN
>>     C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA=
>>     S: 235 Authentication successful
>>
>>  The example below is almost identical to the previous, but here the
>>  client chooses not to use the initial response parameter.
>>
>>     S: 220-smtp.example.com ESMTP Server
>>     C: EHLO client.example.com
>>     S: 250-smtp.example.com Hello client.example.com, pleased to meet you
>>    
>>
>
>This line is too long.
>
Done.

>>     S: 250-AUTH GSSAPI SECURID
>>     S: 250 DSN
>>     C: AUTH SECURID
>>     S: 334
>>     C: AG1hZ251cwAxMjM0NTY3OAA=
>>     S: 235 Authentication successful
>>
>>     Section 7.2 contains an additional example.
>>    
>>
>
>Indention is off here.
>
Thanks.

>
>Also note that 7.2 provides two examples as does 6.2.1.
>So, this should read:
>	Additonal examples can be found in sections 6.2.1 and 7.2.
>
Changed.

>>     C: <stream:stream
>>         xmlns='jabber:client'
>>         xmlns:stream='http://etherx.jabber.org/streams'
>>         to='example.com'
>>         version='1.0'>
>>     S: <stream:stream
>>         xmlns='jabber:client'
>>         xmlns:stream='http://etherx.jabber.org/streams'
>>         id='c2s_234'
>>         from='example.com'
>>         version='1.0'>
>>     S: <stream:features>
>>          <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>            <mechanism>DIGEST-MD5</mechanism>
>>            <mechanism>CRAM-MD5</mechanism>
>>          </mechanisms>
>>        </stream:features>
>>     C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
>>              mechanism='DIGEST-MD5'/>
>>     S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>        cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi
>>    
>>
>
>This line is too long...
>
Fixed.

>>        LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
>>        </challenge>
>>     C: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>        dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
>>        T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
>>        MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
>>        LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
>>        YXJzZXQ9dXRmLTgK
>>        </response>
>>     S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>        cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
>>        </success>
>>
>>     The example below is almost identical to the previous, but here
>>     the server chooses not to use the additional data with success.
>>
>>     C: <stream:stream
>>         xmlns='jabber:client'
>>         xmlns:stream='http://etherx.jabber.org/streams'
>>         to='example.com'
>>         version='1.0'>
>>     S: <stream:stream
>>         xmlns='jabber:client'
>>         xmlns:stream='http://etherx.jabber.org/streams'
>>         id='c2s_234'
>>         from='example.com'
>>         version='1.0'>
>>     S: <stream:features>
>>          <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>            <mechanism>DIGEST-MD5</mechanism>
>>            <mechanism>CRAM-MD5</mechanism>
>>          </mechanisms>
>>        </stream:features>
>>     C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
>>              mechanism='DIGEST-MD5'/>
>>     S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>        cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi
>>    
>>
>
>This line is too long.
>
Fixed.

>...
>  
>
>>  Non-terminals referenced but not defined below are as defined by
>>  [UTF-8].
>>    
>>
>
>I suggest the non-terminal productions be directly incorporated
>into this document.
>
I actually disagree.
If there is an update to UTF-8, I wouldn't like to waste additional time 
trying to synchronize the two.

>>  The "extern-init-resp" rule below defines the initial response sent
>>  from client to server.
>>
>>  extern-init-resp  = *( UTF8-char-no-nul )
>>
>>  UTF8-char-no-nul  = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
>>
>>  UTF8-1-no-nul     = %x01-7F
>>
>>
>>7.2.  Example
>>
>>...
>>
>>  The following example is almost identical to the one above, but the
>>  client doesn't use proxy authentication.
>>    
>>
>
>s/use/request/
>
Changed.

>>     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
>>     S: 235 Authentication successful.
>>
>>
>>8.    IANA Considerations
>>
>>8.1.  Guidelines for IANA
>>
>>  It is requested that IANA updates the SASL mechanisms registry as
>>  follows:
>>
>>     Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
>>     registrations to OBSOLETE.  Change the "Published specification"
>>     of the EXTERNAL mechanism to this document. Updated registration
>>     is provided in Section 8.6.
>>    
>>
>
>s/registration/registration information/
>
Done.

>>...
>>    
>>
>>10.    References
>>
>>10.1.  Normative References
>>
>>  [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax
>>  Specifications: ABNF", RFC 2234, November 1997
>>
>>  [ASCII] American National Standards Institute, "Code Extension
>>  Techniques for Use with the 7-bit Coded Character Set of American
>>  National Standard Code (ASCII) for Information Interchange", FIPS PUB
>>  35, 1974
>>
>>  [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and
>>  Languages", RFC 2277, BCP 18, January 1998
>>
>>  [GSSAPI] Linn, J., "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.
>>    
>>
>
>This reference is never used and hence should be deleted.
>
Done.

>>  [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
>>  Requirement Levels", RFC 2119, BCP 19, March 1997
>>
>>  [Unicode] The Unicode Consortium, "The Unicode Standard, Version
>>  3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading,
>>  MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the
>>  "Unicode Standard Annex #27: Unicode 3.1"
>>  (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
>>  Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
>>
>>  [Stringprep] Hoffman, P., Blanchet, M., "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, F., "UTF-8, a transformation format of ISO 10646",
>>  RFC 3629, STD 63, November 2003.
>>
>>10.2.  Informative References
>>
>>  [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in
>>  progress, draft-ietf-sasl-gssapi-XX.txt, November 2003
>>
>>  [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest
>>  Authentication as a SASL Mechanism", work in progress, draft-ietf-
>>  sasl-rfc2831bis-XX.txt, replaces RFC 2831
>>
>>  [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC
>>  2444, October 1998.
>>
>>  [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC
>>  2808, April 2000.
>>
>>  [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
>>  2001.
>>
>>  [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
>>  RFC 2554, March 1999.
>>
>>  Being revised by Siemborski, R., "SMTP Service Extension for
>>  Authentication", work in progress, draft-siemborski-rfc2554bis-
>>  XX.txt.
>>    
>>
>
>This reference should be put into proper form.
>
I am not sure what exactly you suggest here.

>
>>  [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol
>>  (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt.
>>
>>  [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
>>
>>
>>
>>A. Melnikov                                            FORMFEED[Page 21]
>>
>>
>>
>>
>>
>>Internet DRAFT                    SASL                  14 February 2004
>>
>>
>>  Encodings", RFC 3548, July 2003.
>>
>>  [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC
>>  Authors", RFC 2223, October 1997.
>>
>>  [IANA-SASL]  IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
>>  MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms.
>>
>>11.   Editor's Address
>>
>>    Alexey Melnikov
>>    Isode Limited
>>
>>    Email: [e-mail]
>>
>>12.   Acknowledgments
>>
>>  This document is a revision of RFC 2222 written by John G. Myers.  He
>>  also contributed significantly to this revision.
>>
>>  Magnus Nystrom provided the ASCII art used in Section 6.3.
>>
>>  Definition of partition was extracted from RFC 2617 ("HTTP
>>  Authentication: Basic and Digest Access Authentication").
>>
>>  Contributions of many members of the SASL mailing list are gratefully
>>  acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob
>>  Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth, Tony Hansen and
>>  Abhijit Menon-Sen for proofreading the document and various editorial
>>  suggestions.
>>    
>>
>
>Suggest you drop middle initials.
>
As you wish :-).

>Needs IPR notice.
>
Added.

Alexey