Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 09:37:00 -0700

Hallvard,

This wording concerns me a bit too.  I think we need to have
one registry which lists all "public" mechanisms.  Hence, I
suggest the text be reworded to allow a standard track RFC
to establish additional registration requirements for
portions of the name space (or "families of names").  That
is, the SASL-GSSAPI specification can establish additional
requirements for GSSAPI mechanisms.  However, SASL-GSSAPI
cannot (without updating the base specification) remove
requirements established by the base specification.

Also, I think having the text belongs only in the IANA
Considerations section.  Section 4 should just say
  SASL mechanism names must be registered with the IANA
  in accordance with Section 8 of this document.

Section 8 should include both the guidelines for IANA
to follow (for individual names and for families of names)
and procedures for those requesting registration.  (I
suggest having two subsections "Guidelines for IANA"
and "Registration Procedures".

Kurt

At 01:48 PM 9/30/2003, Hallvard B Furuseth wrote:
>>    SASL mechanism names must be registered with the IANA.
>>    IETF Standards Track documents may override this registration
>>    requirement by reserving a portion of the SASL mechanism namespace
>>    for their own use;
>
>Huh?  So I must search through all Standards Track RFCs as well as the
>IANA registry in order to find out if a mechanism name is reserved?
>Why not register these name reservations with IANA too?
>
>> 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,
>
>Does this mean that the initial auth command from the client is not
>considered part of the authentication protocol exchange?

---

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

Hallvard B Furuseth wrote:

>Sorry about coming with these comments so late.  I have just discovered
>the SASL list, and there was a lot to read:-)
>Feel free to ignore comments that have already been discussed.  
>
>>4.    Authentication mechanisms
>>
>>   SASL mechanisms are named by
>>    
>>
>
>ASCII
>
>  
>
>>   strings,
>>   (...)
>>   mech-char    = %x41-5A / DIGIT / "-" / "_"
>>                  ; mech names restricted to uppercase
>>    
>>
>
>ASCII
>
Ok.

>>letters,
>>                  ; digits, "-" and "_"    
IMHO, this was the intent. I will try to clarify this.

>considered part of the authentication protocol exchange?
Does it matter in this section?

>>4.2.  Authorization identities and proxy authentication
>>
>>   (...)
>>   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
>>    
>>
>                                          ^^^^
>
>What's a blob?  I don't think it's 'something ill-defined or amorphous',
>like the dictionary says:-)
>
I've changed this to "data".

>>4.3.  Security layers
>>
>>   If use of a security layer is negotiated by the authentication
>>   protocol exchange, the security layer is applied to all subsequent
>>   data sent over the connection    
>>
>
>... until another security layer or no security layer is negotiated.
>
>[Added according to section 6.3.]
>
>  
>
Done.

>>   In
>>   order to avoid noninteroperability due to differing normalizations,
>>   when a mechanism specifies that a string authentication identity or
>>   password used as input to a cryptographic function (or used for
>>   comparison) it SHOULD specify that the string first be prepared using
>>   the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm
>>   [StringPrep].  This should be done by both the client (upon getting
>>   user input or retrieving a value from configuration) and by the
>>   server (upon receiving the value from the client).
>>    
>>
>
>What's the point of this duplicate preparation?  Why not do it only
>at the server side?
>  
>
Because if the client doesn't do that, the hash calculated on the server 
will not match the one calculated on the client.

>>   A service name, to be selected from the IANA registry of "service"
>>   elements for the GSSAPI host-based service name form. [GSSAPI]    
>>
>
>Nitpick: I think the period should be after [GSSAPI].
>
Fixed.

>>   This
>>   service name is made available to the authentication mechanism.
>>    
>>
>
>There should be no paragraph break here.
>
Fixed.

>>   The registry is available at the URL
>>   "http://www.iana.org/assignments/gssapi-service-names"
>>    
>>
>
>Instead, a paragraph break here.  (And a trailing '.'.)
>  
>
Fixed.

>>   A definition
>>   of the command to initiate the authentication protocol exchange.
>>    
>>
>>   The command SHOULD have a method for the server to include an
>>   optional challenge with a success notification.
>>    
>>
>
>I suggest you rename "an optional challenge" to "optional data", or
>put "challenge" in quotes.
>  
>
Ok.

>>   A protocol profile MAY further refine the definition of an
>>   authorization identity by adding additional syntactic restrictions
>>   and protocol-specific semantics.
>>    
>>
>
>Add a paragraph break here, since the following is a new item.  Remove
>"A protocol profile MUST specify" to just make the following a new item
>in the list of things that must be specified.
>
>  
>
>>   A protocol profile MUST specify the
>>   form of the authorization identity (as it is protocol specific, as
>>   
>>
I would rather not do this, as this is a single logic item.

>
>  
>
>>6.3.  Multiple authentications
>>
>>   Unless otherwise stated by the protocol's profile, only one
>>   successful SASL negotiation may occur in a protocol session.
>>    
>>
>
>This should be mentioned in the "Protocol profile requirements" section.
>
I agree.

>>7.1.  Formal syntax
>>
>>   initial-response  = *( UTF8-char-no-null )
>>    
>>
>
>Why is initial-response required to be UTF-8 when the character encoding
>scheme of the rest of the exchange is left to the specifications of the
>individual mechanisms?  I would think that either initial-response
>merely "SHOULD" be UTF-8, like the rest of the exchange.
>
This is specific to EXTERNAL.
I've changed "initial-response" to "extern-init-resp" in order to avoid 
confusion.

> 
>
>
>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the
>top.
> 
>
I've added a sentence about this in the introduction section.

Alexey

---

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

At 04:52 AM 10/8/2003, Alexey Melnikov wrote:
>Because if the client doesn't do that, the hash calculated on the server will not match the one calculated on the client. 

Alexey, the current text suggests that client (1) prep the
value before sending, the server then preps it (2) again
(before comparing it to the store value, which also should
be prep'ed (3) either before storing it or before each compare).

We need to REQUIRE that mechanisms specify how character strings
are to be prepared for comparison and RECOMMEND that they use
SASLprep for simple user names and passwords.

We should not suggest that mechanisms should do both (1) and
(2).  (1) and (3) OR (2) or (3) are sufficient to ensure
proper matching.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 14 Oct 2003 16:52:21 +0200

> Does it matter in this section?

Well, that's where "authentication protocol exchange" seems to be
defined.  It matters if other documents refer to "the authentication
protocol exchange".

Anyway, I think I found the answer in section 6.1.  The initial auth
command from the client is not part of the exchange, but the optional
"response" in the auth command is.

> I've changed this to "data".

I still don't know _which_ data you are talking about.

> I would rather not do this, as this is a single logic item.

OK.

> I've added a sentence about this in the introduction section.

I'm pretty sure you will still need to insert the words "Obsoletes: rfc
2222" in the header sometime, though I don't remember where this is
stated.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Oct 2003 15:50:45 +0100

>"response" in the auth command is.
Sorry, this makes little sense to me.
Semantically the initial response *is* part of an authentication 
exchange. It is just an optimization to avoid a round trip.

>I still don't know _which_ data you are talking about.
Data is defined (and specific to) by each SASL mechanism.

>2222" in the header sometime, though I don't remember where this is
I think this is going to be added by a RFC editor.

Regards,
Alexey

__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Oct 2003 20:56:55 +0100

>be prep'ed (3) either before storing it or before each compare).
Ok, I am with you now.

IMHO, as a server writer, I would do (2) anyway. But of course this is 
my personal opinion.

However there is one case when all three may make sense. Imagine that 
there are two clients that use PLAIN.
One of the prepares username/password, the other one doesn't. If the 
server also does preparation, it will be able to interoperate with both 
clients.

>(2).  (1) and (3) OR (2) or (3) are sufficient to ensure
IMHO, this is a responsibility of the client, so I will clarify that. 
But I will add that the server "MAY prepare".

Alexey

Cell: +44 7753759732

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Oct 2003 21:06:44 +0100

>>>>> [StringPrep].
The new text after that reads:

There are three entities that has to deal with this issue: a client
(upon getting user input or retrieving a value from configuration), a server
(upon receiving the value from the client) and a utility that is able to 
store
passwords/hashes in a database that can be later used by the server.
The preparation must be done by the client and the utility and may be 
done by the
server. If preparation fails or results in an empty string, the entity doing
the preparation SHALL fail the authentication exchange.

>>>>> This should be done by both the client (upon getting
>>> Because if the client doesn't do that, the hash calculated on the 
>>> server will not match the one calculated on the client.    
>>
> server also does preparation, it will be able to interoperate with 
> both clients.
>

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Oct 2003 20:15:19 +0100

> the preparation SHALL fail the authentication exchange.

I like Kurt's suggestion better: The mechanism must define where
preparation is done.  That way clients using mechanisms like PLAIN can
leave as much work as possible to the server.

>> IMHO, as a server writer, I would do (2) anyway. But of course this is

I see no reason to prepare a string which we know already has been
prepared (if the client works correctly).  I guess it doesn't hurt to
allow that, but what you are saying is that if the client sends
incorrect data (it doesn't prepare when it should do so), auth on your
server would succeed anyway.  Put that way, I'm not sure if that is a
bug or a feature.

BTW, the server can't do (2) with mechanisms like DIGEST-MD5, where it
never sees the plain password from the client.  I got that wrong too
in my original message.

>> IMHO, this is a responsibility of the client,

Disagree.  It's the responsibility of the mechanism defintion to say
where it should happen.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Oct 2003 20:21:02 +0100

> exchange.

That's what I wrote.

> Data is defined (and specific to) by each SASL mechanism.

Is the text in the ()'s just saying that the SASL mechanism restricts
the data sent between client and server to more than just being random
strings in the character encoding scheme?  Well, of course.  Why mention
that at all?  If not, I still don't understand what this () is saying.

> I couldn't find anything saying so.  I did find rfc2223 (Instructions
> to RFC Authors) section 4, which lists 'Obsoletes:' as things it asks
> you to insert.  rfc2223 does say that the RFC Editor may make some
> changes, but preferably as few as possible, and it doesn't mention
> that one.

-- 
Hallvard

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 14:49:10 -0500

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> IMHO, as a server writer, I would do (2) anyway. But of
    Alexey> course this is my personal opinion.

This needs to be left up to individual mechanisms.  The server
definitely should not do this.  I can think of mechanisms where doing
(2) will break signatures of data, etc.

For plain, I would probably do all three as you suggest.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 15:02:37 -0500

>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:

    >>> Anyway, I think I found the answer in section 6.1.  The
    >>> initial auth command from the client is not part of the
    >>> exchange, but the optional "response" in the auth command is.
    >>> 
    >> Sorry, this makes little sense to me.  Semantically the initial
    >> response *is* part of an authentication exchange.

    Hallvard> That's what I wrote.

    >>>>> What's a blob?  I don't think it's 'something ill-defined or
    >>>>> amorphous', like the dictionary says:-)
    >>>>> 

    Hallvard> Is the text in the ()'s just saying that the SASL
    Hallvard> mechanism restricts the data sent between client and
    Hallvard> server to more than just being random strings in the
    Hallvard> character encoding scheme?  Well, of course.  Why
    Hallvard> mention that at all?  If not, I still don't understand
    Hallvard> what this () is saying.

Because you want to make it clear to application protocol designers
and SASL library implementers that mechanisms will be expected to
restrict this data.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 09:37:00 -0700

Hallvard,

Kurt

---

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

Ok.

Done.

Fixed.

Fixed.

Fixed.

Ok.

I agree.

Alexey

---

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

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 14 Oct 2003 16:52:21 +0200

OK.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Oct 2003 15:50:45 +0100

Regards,
Alexey

Cell: +44 7753759732

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Oct 2003 20:56:55 +0100

Ok, I am with you now.

Alexey

Cell: +44 7753759732

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Oct 2003 21:06:44 +0100

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Oct 2003 20:15:19 +0100

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Oct 2003 20:21:02 +0100

That's what I wrote.

-- 
Hallvard

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 14:49:10 -0500

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 15:02:37 -0500