Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
Alexey Melnikov <Alexey.Melnikov@isode.com> Fri, 03 October 2003 15:54 UTC
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93FsFKP027698 for <ietf-sasl-bks@above.proper.com>; Fri, 3 Oct 2003 08:54:15 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93FsFn3027697 for ietf-sasl-bks; Fri, 3 Oct 2003 08:54:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93Fs8KP027684 for <ietf-sasl@imc.org>; Fri, 3 Oct 2003 08:54:13 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTP; Fri, 3 Oct 2003 16:53:55 +0100
Message-ID: <3F7D9B91.7060906@isode.com>
Date: Fri, 03 Oct 2003 16:53:53 +0100
From: Alexey Melnikov <Alexey.Melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
CC: ietf-sasl@imc.org
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt
References: <5.2.0.9.0.20030915103818.03b51a88@127.0.0.1> <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1>
In-Reply-To: <6.0.0.22.0.20031001100505.03e9ffd0@127.0.0.1>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:ietf-sasl-request@imc.org?body=unsubscribe>
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 iana@iana.org. 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 "rfc-editor@rfc-editor.org" >> (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 >> <jgmyers@netscape.com>. 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
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Kurt D. Zeilenga
- WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt Kurt D. Zeilenga
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Alexey Melnikov
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Alexey Melnikov
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Kurt D. Zeilenga
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Alexey Melnikov
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Hallvard B Furuseth
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Jeffrey Hutzelman
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Sam Hartman
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Rob Siemborski
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Alexey Melnikov
- CHARSET-POLICY Re: WG Last Call: draft-ietf-sasl-… Kurt D. Zeilenga
- Proxy authentication (was WG Last Call: draft-iet… Alexey Melnikov
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Alexey Melnikov
- Re: CHARSET-POLICY Re: WG Last Call: draft-ietf-s… Alexey Melnikov
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Alexey Melnikov
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Jeffrey Hutzelman
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Alexey Melnikov
- Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.t… Kurt D. Zeilenga