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

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 13:39:57 +0000

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>Hallvard B Furuseth wrote:
>>    
>>
>>>Alexey Melnikov writes:
>>>      
>>>
>>>>Hallvard B Furuseth wrote:
>>>>        
>>>>
>>>>>>4.1.  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.
>>>      
>>>
>>Sorry, this makes little sense to me.
>>Semantically the initial response *is* part of an authentication 
>>exchange.
>>    
>>
>
>That's what I wrote.
>
Ok, but I think arguing whether the initial auth command is part of an 
exchange or not is not worth the time.

>>>>>>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".
>>>>        
>>>>
>>>I still don't know _which_ data you are talking about.
>>>
>>>      
>>>
>>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?
>
No, it talks about encoding data. The data itself is arbitrary binary 
data as far as the protocol is concerned.

>  Well, of course.  Why mention
>that at all?  If not, I still don't understand what this () is saying.
>
>  
>
>>>>>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.
>>>>        
>>>>
>>>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.
>>>
>>>      
>>>
>>I think this is going to be added by a RFC editor.
>>    
>>
>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.
>
Ok, I will make sure that Obsoletes: will be inserted.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 15:33:40 +0000

Hallvard B Furuseth wrote:

>>>>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.
>>>>        
>>>>
>>>IMHO, this is a responsibility of the client,
>>>      
>>>
>
>Disagree.  It's the responsibility of the mechanism definition to say
>where it should happen.
>
Ok.
But in all SASL mechanisms I know the client end sends username or 
retrieves-hashes-sends something derived from a password.
So, so far this is the same thing ;-).

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 19:41:35 +0000

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>>>>>>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].
>>>>>>>              
>>>>>>>
>>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.    
>>
>
>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.
>
I've updated the draft to say that each mechanism must describe where 
preparation takes place.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 13:39:57 +0000

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 15:33:40 +0000

Ok.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Nov 2003 19:41:35 +0000

Alexey