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

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 1 Oct 2003 15:25:25 +0200

Kurt D. Zeilenga writes:
>>   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.  (...)
> I'm thinking "blob" should be replaced with "string".

But which string is the draft talking about?

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 01 Oct 2003 11:43:34 -0400

On Wednesday, October 01, 2003 10:17:55 -0700 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

>> Network Working Group                                        A. Melnikov
>> Internet Draft                                                    Editor
>> Document: draft-ietf-sasl-rfc2222bis-02.txt                  August 2003
>>                                                   Expires in six months

Well, it doesn't matter now, but "expires in six months" is not acceptable; 
a specific date must be specified.  See the "Formatting" section in 
1id-guidelines.txt

>> 1.    Abstract

Don't number the abstract.

>> 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.
>
>>   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".

Ick.  IMHO this phrasing is ugly and not necessary.  It appears to 
encourage authors of documents like SASL-GSSAPI to allocate themselves 
parts of the namespace without bothering to direct the IANA to reserve 
them.  This would be a bad thing, and would indeed require that a potential 
future protocol designer (and/or the IANA itself) search the complete space 
of standards-track documents to see if the name they want to use has been 
reserved.

IETF standards-track documents do not need the SASL spec's permission to 
direct the IANA to reserve parts of the namespace; thus, I don't think it's 
necessary to mention it at all.  However, if it is mentioned, it should be 
in the IANA considerations section, not here, and with text like "IETF 
standards track documents may direct the IANA to reserve a portion of the 
SASL mechansim namespace and may specify different registration criteria 
for the reserved portion."

Given the large size of the mechanism namespace, it is unfortunate that we 
have failed to provide for mechanism names of the form foo@domain. 
Delegated registration is much less work for IANA.

>>   Per IETF character set
>>   policy [CHARSET-POLICY], authentication mechanisms SHOULD encode
>>   these and other strings in UTF-8 [UTF-8].
>
> This seems counter to [CHARSET-POLICY] as it allows a mechanism to
> not support UTF-8 transfer of character data.
>
> [CHARSET-POLICY] says:
>    Protocols MUST be able to use the UTF-8 charset, which consists of
>    the ISO 10646 coded character set combined with the UTF-8 character
>    encoding scheme, as defined in [10646] Annex R (published in
>    Amendment 2), for all text.

It would probably be appropriate to require applications to deal, though 
the truth is that CHARSET-POLICY already does that without our help.

While we can impose requirements on SASL mechanisms, we really can't impose 
requirements on the authentication technologies upon which they are built. 
Requiring mechanisms to use UTF-8 might impose an impossible burden on the 
SASL mechansim designer, forcing them to do transformations between Unicode 
and some other character set.

So, it is appropriate to REQUIRE that authorization identities (which are 
not really owned by the mechanism anyway) be encoded as UTF-8, and I think 
we should do so.  But it may not be appropriate for "other strings".

>>   If the authorization identity transmitted during the authentication
>>   protocol exchange is not the empty string, this is typically referred
>>   to as "proxy authentication".
>
> Personally, I refer to this as "proxy authorization".  Proxy
> authentication makes it sound like the feature can be used by a
> proxy to authenticate its users.

The same argument can be made for "proxy authorization".  We are talking 
about "authentication by proxy", not "authentication to a proxy".  And yes, 
we're really talking about authorization, not authentication, but it's not 
really "authorization by proxy"; it's just authorization.

The terminology is pretty bad.  It's not clear to me that we need a name 
for this at all.  But I'm pretty sure the phrase "proxy authentication" has 
been in use for a while, and to change it might cause more confusion than 
leaving it alone.

>>   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.

Sure, but that's not really all it's good for.  It also allows 
[email-masked] to log in to the IMAP server on CYRUS.ANDREW.CMU.EDU as 
'jhutz', even though the server is in the ANDREW.CMU.EDU realm.  And 
similar functionality, though not using SASL, allows me to type 
"[email-masked],maint:" at a login prompt, followed by [email-masked]'s 
password, and log in as the user 'maint'.

>>   The server SHOULD verify the correctness of a received authorization
>>   identity.
>
> "Correctness" here doesn't appear to be correct.  And it should
> be a MUST.   I suggest:
> 	The server SHALL fail the authentication exchange if the
> 	authenticated client is not allowed to assume the asserted
> 	authorization identity.

s/SHALL/MUST/

>> 4.4.  Character string issues
>>
>>   Per IETF character set policy [CHARSET-POLICY], authentication
>>   mechanisms SHOULD encode character strings in UTF-8 [UTF-8].
>
> See above note about charset-policy.

And my response.  It's really quite important that we get this right for 
authentication identities, or we risk invalidating a number of popular 
mechanisms because they are based on underlying authentication technology 
which does not use UTF-8.

>> 5.    Protocol profile requirements
>>
>>   In order to use this specification, a protocol definition MUST supply
>>   the following information:
>>
>>   A service name, to be selected from the IANA registry of "service"
>>   elements for the GSSAPI host-based service name form. [GSSAPI]  This
>>   service name is made available to the authentication mechanism.
>>
>>   The registry is available at the URL
>>   "http://www.iana.org/assignments/gssapi-service-names" A definition

Paragraph break.

>>   A definition of the method by which the authentication protocol
>>   exchange is carried out, including how the challenges and responses
>>   are encoded, how the server indicates completion or failure of the
>>   exchange, how the client aborts an exchange, and how the exchange
>>   method interacts with any line length limits in the protocol.
>>
>>   The command SHOULD have a method for the server to include an
>>   optional challenge with a success notification.  This allows the
>>   server to avoid a round trip when using a mechanism which is defined
>>   to have the server send additional data along with the indication of
>>   successful completion.  See section 6.2 of this document for further
>>   information.

What command?  Who says "the method by which the authentication protocol 
exchange is carried out" is a command?  s/The command/The exchange method/

>>   Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept
>>   of realm.
>
> I think it unwise to enter into a discussion of realms here.
> Realm syntax and semantics are, for mechanisms which have realms,
> mechanism specific.  The mechanism specification should state how
> they are to be compared.  The mechanism specification should state
> how they are to constructed and used in the mechanism and, where
> appropriate, state any protocol profiling requirements.  (Note:
> I'd likely doubt any mechanism attempt to state protocol profiling
> requirements as this breaks SASL's separation of profile and
> mechanism).

I agree.  A realm is just part of the authentication identities used by 
certain mechanisms.  It is mechanism-specific, and a discussion of realms 
is irrelevant to protocol profiling.

>>   A protocol profile SHOULD provide a guidance how realms are to be
>>   constructed and used in the protocol and MAY further restrict its
>>   syntax and protocol-specific semantics.

Absolutely not.  Protocols may decide to include some concept of realm in 
their authorization identities, but they have no business whatsoever 
defining the semantics of authentication identities.  That is the 
responsiblity of the mechanism.

>>   Below the term "realm" has the meaning as defined in the section 5.
>>   A security layer that remains in effect when a client, which already
>>   has authenticated and established the security layer with "Realm A",
>>   authenticates to "Realm B", without negotiating a new security layer,
>>   enables "Realm B" to make guesses about previously observed
>>   ciphertext using the server's SASL engine as an oracle. "Realm B" may
>>   observe how known cleartext is encrypted.
>>
>>              +---------+                   +---------+
>>              |         |                   |         |
>>              | Realm B |                   | Realm A |
>>              |         |                   |         |
>>              +---------+                   +---------+
>>                  |  ^                           |
>>                  |  :      +-----------+        |
>>     Traffic from |  :      | Encryption|        | Traffic from A
>>      B to client +-------->| end point |<-------+ to client
>>                     :      | (SSL/SASL)|
>>                     :      +-----------+
>>                     :            |
>>                     :            |
>>                     :          +---+
>>                     :          |   |
>>                     :          |   |
>>                     :          |   | Encryption tunnel, e.g. SASL or SSL,
>>                     :          |   | between the server
>
>>           encrypted            |   | Separate tunnels to different
>>           traffic between      |   | clients.
>>           Realm A and client   +---+
>>                                  |
>>                                  |
>>                                  +-----------> Traffic to clients

This discussion is confusing and makes no sense to me.  SASL doesn't 
protect traffic between "realms" and clients; it protects traffic between 
_servers_ and clients.  This needs to be reworded so it makes sense, in 
terms of entities known to the SASL framework.  A "realm" is not such an 
entity; it is no more than part of the autentication identities used by 
some mechanisms, and has no place outside the mechainsm specification.

Put another way, and ignoring the issue of "realms"; the above description 
makes so little sense to me that I cannot evaluate its validity or 
understand what attack we are trying to avoid.

>> 8.    IANA Considerations
>>
>>   Registration of a SASL mechanism is done by filling in the template
>>   in section 8.4 and sending it in to [email-masked].  IANA has the
>>   right to reject obviously bogus registrations, but will perform no
>>   review of claims made in the registration form.

Provide the template.  Do not specify how to communicate the registration 
to the IANA, because that may change over time and is out of scope for this 
document.

>>   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.

Again, too bad we didn't allow for [email-masked].

>> 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.
>
>>   description and other supporting material may also be published as an
>>   Informational RFC by sending it to "[email-masked]"
>>   (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]).
>
> Drop "by sending (...)".

IMHO, drop the whole subsection.  IANA considerations are about telling the 
IANA what it needs to do and be aware of with respect to this document. 
It's appropriate to specify the form of registration and the rules which 
govern whether IANA should accept a registration.  It is not appropriate to 
specify the means used to communicate with the IANA or the RFC Editor, or 
to direct the IANA as to the URL at which it must provide the registration 
data.  These things may change over time, and it is out of scope for the 
SASL working group (or, indeed, the IETF) to specify them.

>> 8.3.  Change control
>>
>>   Once a SASL mechanism registration has been published by IANA, the
>>   author may request a change to its definition.  The change request
>>   follows the same procedure as the registration request.

This sounds a lot like the stringprep loophole, and it makes me nervous.

>> 9.2.  Informative References
>>
>>   <<Update the reference below>> [SASL-GSSAPI] Myers, "SASL GSSAPI
>>   mechanisms", work in progress, draft-ietf-cat-sasl-gssapi-XX.txt,
>>   September 2000

>>   [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

I think it would be good to eliminate references to new or updated 
mechanisms if at all possible, since otherwise we are forced to either 
publish a document with incorrect or incomplete references, or wait until 
those documents are ready.  If we keep them, use the correct reference form:

[SASL-GSSAPI] Myers, "SASL GSSAPI mechanisms" 
(draft-ietf-cat-sasl-gssapi-01.txt)

See "References" in section 2 of ID-nits.

>>   [IANA-SASL]  IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
>>   MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms.

Ew.  I don't think this is necessary.  Also, references to URL's are to be 
avoided, as they may change, rendering the document obsolete and confusing. 
See "References" in section 2 of id-nits.

>>   "stringprep" and Unicode security considerations apply to
>>   authentication identities, authorization identities and passwords.

Include references to these.

Put Security Considerations _before_ references, not after.

>> 12.   Acknowledgments

>>   Definition of realm was extracted from RFC 2617 ("HTTP
>>   Authentication: Basic and Digest Access Authentication").

Except we should be dropping the definition of "realm".

>>   In certain situations, it is reasonable to use SASL underneath one of
>>   these Transport Security services.  The transport service would
>>   secure the connection, either service would authenticate the client,
>>   and SASL would negotiate the authorization identity.  The SASL
>>   negotiation would be what moves the protocol from "unauthenticated"
>>   to "authenticated" state.  The "EXTERNAL" SASL mechanism is
>>   explicitly intended to handle the case where the transport service
>>   secures the connection and authenticates the client and SASL
>>   negotiates the authorization identity.
>>
>>   When using SASL underneath a sufficiently strong Transport Security
>>   service, a SASL security layer would most likely be redundant.  The
>>   client and server would thus probably want to negotiate off the use
>>   of a SASL security layer.

Please don't say this without a _lot_ more text explaining when it is safe. 
A common configuration is to run SASL under TLS, using SASL for client 
authentication and negotation of the authorization identity.  In this 
configuration, it is _not_ safe to skip using a SASL security layer if the 
client did not check the server's certificate (there is a tunnelling MitM 
attack), and it's not a particularly good idea even if the server cert was 
checked, because the client's authentication is still not bound to the 
encryption keys used at the TLS layer.

We already have problems with people who think it is actively bad to use a 
SASL security layer under TLS.  The result is that some insecure 
configurations are now widely deployed.  Let's not encourage this any 
further.

>> Appendix B. IANA considerations

Uh, no.  IANA considerations were section 8.  Please merge them.

>>   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:

It's not demanting; it's perfectly reasonable usage.  The IANA works for 
the IETF; it is appropriate for the IETF, in the form of a standards-track 
document, to direct it to make changes to a registry.  It is also common 
usage.

Put the TOC at the _top_ of the document, just after the abstract.  See the 
"Tabel of Contents" section at http://www.rfc-editor.org/policy.html

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Oct 2003 14:20:02 -0400

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    >> 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.

    Kurt> Can't the client challenge the server as well?

I always thought that in SASL, the challenge was defined to be the
message from the server to the client even if it didn't serve that
purpose in a security sense.

--Sam

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 1 Oct 2003 14:46:14 -0400 (EDT)

> purpose in a security sense.

I agree.

Indeed, in 6.1 we refer to an "initial client response" even though it
could, in fact, be an initial challenge from client to server.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 Oct 2003 16:53:53 +0100

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.

>>...
Ok.

>>  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
>>
>>
>>  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.
>>
>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 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).

>>  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
>>
>>A. Melnikov                                            FORMFEED[Page 11]
>>
>>
>>
>>
>>
>>Internet DRAFT                    SASL                    19 August 2003
>>
>>
>>  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.
>>
Already done.

>>  (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]).
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
>>  <[email-masked]>. 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.

>>  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.)

>>...
Ok.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 11:54:31 -0700

My main gripe here is that the I-D implied incorrectly that
the IETF character set policy RECOMMENDs protocols be able
to use UTF-8 when the police that protocols are REQUIRED
to be able to use UTF-8.

I think both these "Per IETF character set policy" statements
should be deleted.  Inserting a note like shown below might
be appropriate.

>   The character encoding scheme used (see [CHARSET-POLICY]
for IETF policy regarding character sets in IETF protocols)
for
>   transmitting an authorization identity over protocol is
>    specified in each authentication mechanism (with the
>   authentication mechanism's blob being further

At 08:43 AM 10/1/2003, Jeffrey Hutzelman wrote:
>It would probably be appropriate to require applications to deal, though the truth is that CHARSET-POLICY already does that without our help.
>While we can impose requirements on SASL mechanisms, we really can't impose requirements on the authentication technologies upon which they are built.
> Requiring mechanisms to use UTF-8 might impose an impossible burden on the SASL mechansim designer, forcing them to do transformations between Unicode and some other character set.
>
>So, it is appropriate to REQUIRE that authorization identities (which are not really owned by the mechanism anyway) be encoded as UTF-8, and I think we should do so.  But it may not be appropriate for "other strings".

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 13:06:19 +0100

[Because there are too many issues raised I will be starting a separate 
thread for each]

Kurt D. Zeilenga wrote:

>>  During the authentication protocol exchange, the mechanism performs
>>  authentication, transmits an authorization identity (frequently known
>>  as a userid) from the client to server, and negotiates the use of a
>>  mechanism-specific security layer.  If the use of a security layer is
>>  agreed upon, then the mechanism must also define or negotiate the
>>  maximum security layer buffer size that each side is able to receive.
>>
>>4.2.  Authorization identities and proxy authentication    
>>
>
>
>See note below regarding the term "proxy authentication".
>
>  
>
...

>>  The identity derived from the client's authentication credentials is
>>  known as the "authentication identity".  With any mechanism,
>>  transmitting an authorization identity of the empty string directs
>>  the server to derive an authorization identity from the client's
>>  authentication identity.
>>
Jeffrey Hutzelman wrote:

> The same argument can be made for "proxy authorization".  We are 
> talking about "authentication by proxy", not "authentication to a 
> proxy".  And yes, we're really talking about authorization, not 
> authentication, but it's not really "authorization by proxy"; it's 
> just authorization.
>
> The terminology is pretty bad.  It's not clear to me that we need a 
> name for this at all.  But I'm pretty sure the phrase "proxy 
> authentication" has been in use for a while, and to change it might 
> cause more confusion than leaving it alone.

So, I will leave it as is.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 13:38:33 +0100

>>>   "http://www.iana.org/assignments/gssapi-service-names" A definition

Yes, this is already fixed in my copy.

> What command?  Who says "the method by which the authentication 
> protocol exchange is carried out" is a command?  s/The command/The 
> exchange method/ 

Yes.

> This sounds a lot like the stringprep loophole, and it makes me nervous. 

Can you be more specific in what do you want to be changed.
Would you rather reference the SASL WG as the Change Controller?

> Please don't say this without a _lot_ more text explaining when it is 
> safe. A common configuration is to run SASL under TLS, using SASL for 
> client authentication and negotation of the authorization identity.  
> In this configuration, it is _not_ safe to skip using a SASL security 
> layer if the client did not check the server's certificate (there is a 
> tunnelling MitM attack), and it's not a particularly good idea even if 
> the server cert was checked, because the client's authentication is 
> still not bound to the encryption keys used at the TLS layer.
>
> We already have problems with people who think it is actively bad to 
> use a SASL security layer under TLS.  The result is that some insecure 

Should I just drop this paragraph?

> It's not demanting; it's perfectly reasonable usage.  The IANA works 
> for the IETF; it is appropriate for the IETF, in the form of a 
> standards-track document, to direct it to make changes to a registry.  
> It is also common usage. 

I've already changed this to be "nicer" to IANA ;-).

> Put the TOC at the _top_ of the document, just after the abstract.  
> See the "Tabel of Contents" section at 
> http://www.rfc-editor.org/policy.html 

This is editorial and I don't want to spend time doing this at this stage.
I am going to sort this out with the RFC editor directly.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 14:33:04 +0100

Kurt D. Zeilenga wrote:

>>  The character encoding scheme used 
>>    
>>
>(see [CHARSET-POLICY]for IETF policy regarding character sets in IETF protocols)
>
>  
>
>>  for transmitting an authorization identity over protocol is
I've changed the first reference as you suggested, and the last to:

Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8]
(see [CHARSET-POLICY] for IETF policy regarding character sets in IETF 
protocols).

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 14:58:08 +0100

Kurt D. Zeilenga wrote:

>>7.    The EXTERNAL mechanism
>>
>>  The mechanism name associated with external authentication is
>>  "EXTERNAL".
>>
>>  The client sends an initial response with the UTF-8 encoding of the
>>  authorization identity. The form of the authorization identity is
>>  further restricted by the application-level protocol's SASL profile.
>>
>>  The server uses information, external to SASL, to determine whether
>>  the client is authorized to authenticate as the authorization
>>  identity.
>>    
>>
>
>It may be appropriate to note that the client can make no
>assumptions as what information the server uses in determining
>client authorization.  E.g., just because TLS was established,
>doesn't mean the server will use TLS-provided information.
>  
>
Done. The new text reads:

The system providing this external information may be, for example,
IPSec or TLS. However, the client can make no assumptions as to what
information the server can use in determining client authorization.
E.g., just because TLS was established, doesn't mean that the server
will use the information provided by TLS.

>>7.2.  Example
>>
>>  The following is an example of an EXTERNAL authentication in the SMTP
>>  protocol [SMTP-AUTH].
>>    
>>
>
>Replace [SMTP-AUTH] with an informative reference to the SMTP base
>specification.  Insert [SMTP-AUTH] after the word "profile" below.
>
Done.

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 08 Oct 2003 10:19:29 -0400

> Can you be more specific in what do you want to be changed.

No.  Perhaps I'm being paranoid, but the concern is that if mechanism FOO 
gets registered and implemented, no one should be able to come along later 
and change FOO to mean some other, non-compatible mechanism.  Maybe it's 
not worth worrying about..

In any case, no, I can't be more specific; I don't know what change could 
make this better, and I don't think I was really asking for one.  It just 
makes me nervous.

> Would you rather reference the SASL WG as the Change Controller?

No, especially since the SASL WG will likely conclude within the 
foreseeable future.

> Should I just drop this paragraph?

Yeah, IMHO it would be reasonable to just drop the paragraph starting "When 
using SASL underneath..."

> I am going to sort this out with the RFC editor directly.

Fair enough.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 17:24:56 +0100

Jeffrey Hutzelman wrote:

> Yeah, IMHO it would be reasonable to just drop the paragraph starting 
> "When using SASL underneath..." 

Done.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 09 Oct 2003 03:04:16 -0700

At 07:19 AM 10/8/2003, Jeffrey Hutzelman wrote:
>No, especially since the SASL WG will likely conclude within the foreseeable future. 

The IESG should have change control mechanisms registered by
Standards Action.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 1 Oct 2003 15:25:25 +0200

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 01 Oct 2003 11:43:34 -0400

s/SHALL/MUST/

Paragraph break.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Oct 2003 14:20:02 -0400

--Sam

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 1 Oct 2003 14:46:14 -0400 (EDT)

I agree.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 Oct 2003 16:53:53 +0100

Done.

Done.

Ok.

Done.

See Rob's reply.

Ok.

Already done.

Done.

Ok.

Ok.

Ok.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 11:54:31 -0700

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 13:06:19 +0100

...

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 13:38:33 +0100

Yes.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 14:33:04 +0100

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 14:58:08 +0100

Done.

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 08 Oct 2003 10:19:29 -0400

Fair enough.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 17:24:56 +0100

Done.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 09 Oct 2003 03:04:16 -0700

Kurt