Re: rfc2831bis issues

[Alexey Melnikov <[e-mail]>]

Hallvard B Furuseth wrote:

>Here are various editorial and non-editorial comments for
>draft-ietf-sasl-rfc2831bis-02.txt.
>  
>
>>Table of Contents
>>    
>>
>>    3.8 CBC MODE ATTACKS.............................................
>>    
>>
>
>Missing page number.
>
Yes, I was lazy.
I was changing text a lot, so I had to spend a lot of time fixing page 
numbers when doing each revision. So I just gave up.

>>1.1  Conventions and Notation
>>    
>>
>>   This specification uses the same ABNF notation and lexical
>>   conventions as HTTP/1.1 specification; see section 7.
>>    
>>
>
>...as well as some named rules defined there (section 7.2).
>
7 implies 7.2.

>>   The value of a quoted string constant as an octet string does not
>>   include any terminating null character
>>    
>>
>
>...which the C language adds.
>
>[For readers who don't know C, if any.]
>  
>
IMHO, readers who don't know C will not care about this comment anyway, 
because it doesn't add any additional information.

>>2.1.1  Step One
>>
>>   The server starts by sending a challenge.
>>    
>>
>
>How does it know that it should do that?
>
The client always starts first (according to SASL). If the client 
doesn't includes an initial response, the server will  know.

Can you suggest any clarification text here?

>>   nonce
>>      Note
>>      that since the string is passed as a quoted string, the
>>      double-quote
>>    
>>
>
>and backslash?
>
Actually, I've changed ABNF to disallow double-quotes or backslashes.
So, this should be removed.

>>      character is not allowed unless escaped (see section
>>      7.2).
>>    
>>
>
>I think this applies to other quoted strings than the nonce.
>
Yes, but it is especially problematic for nonces, as people just 
generate binary data and than forget to quote it.

>>   server_maxbuf ("maximal ciphertext buffer size")
>>    
>>
>
>  
>
>>      Let call "maximal cleartext buffer size" (or "maximal sender
>>      size") the maximal size of a cleartext buffer that, after being
>>    
>>
>
>"Let call"?  Should be "Call", or "Let .... be", I think.
>
Ok.

>>   charset
>>      This directive, if present, specifies that the server supports
>>      UTF-8 [UTF-8] encoding for the username, realm and password. If
>>      present, the username, realm and password are in Unicode, prepared
>>      using the "SASLPrep" profile [SASLPrep] of the "stringprep"
>>      algorithm [StringPrep] and than encoded as UTF-8 [UTF-8].  If not
>>      present, the username, realm and password MUST be encoded in ISO
>>      8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset).
>>    
>>
>
>There is no username and password sent by the server.  Do you mean the
>_client_ MUST send them in UTF-8 if "charset" is given by the server?
>
Yes.

>>   cipher-opts
>>    
>>
>>      "qop-options" directive, in which case the "3des" cipher is
>>      mandatory-to-implement.
>>    
>>
>
>I suggest you remove the "-"s in mandatory-to-implement.
>
This is a term used in SASL. By using "-" I am trying to emphasize this.

>>2.1.2  Step Two
>>    
>>
>>   digest-uri
>>      Indicates the principal name of the service with which the client
>>      wishes to connect, formed from the serv-type, host, and serv-name.
>>      For example, the FTP service on "ftp.example.com" would have a
>>      "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
>>      the example above would have a "digest-uri" value of
>>      "SMTP/mail3.example.com/example.com".
>>
>>   Servers SHOULD check that the supplied value is correct. This will
>>   detect accidental connection to the incorrect server, as well as some
>>   redirection attacks. It is also so that clients will be trained to
>>   provide values that will work with implementations that use a shared
>>   back-end authentication service that can provide server
>>   authentication.
>>
>>   The serv-type component should match the service being offered. The
>>   host component should match one of the host names of the host on
>>   which the service is running, or it's IP address. Servers SHOULD NOT
>>   normally support the IP address form, because server authentication
>>   by IP address is not very useful; they should only do so if the DNS
>>   is unavailable or unreliable. The serv-name component should match
>>   one of the service's configured service names.
>>
>>   This directive may appear at most once; if multiple instances are
>>   present, the client should abort the authentication exchange.
>>
>>   Note: In the HTTP use of Digest authentication, the digest-uri is the
>>   URI (usually a URL) of the resource requested -- hence the name of
>>   the directive.
>>    
>>
>
>Is this entire section about digest-uri?  If so, most of it should be
>indented.
>  
>
>>   authzid
>>    
>>
>>      The server SHOULD verify the correctness of an authzid as
>>      specified by the corresponding SASL protocol profile.
>>    
>>
>
>Which corresponding SASL profile?
>
I meant that any protocol using SASL should verify authorization 
identity as specified in the SASL profile for the protocol. Any 
suggestion how to make this clear?

>>2.2  Subsequent Authentication
>>
>>   If the client has previously authenticated to the server, and
>>   remembers the values of username, realm, nonce, nonce-count, cnonce,
>>    
>>
>                             ^^^^^^^^
>  
>
>>   and qop that it used in that authentication, and the SASL profile for
>>   a protocol permits an initial client response, then it MAY perform
>>   "subsequent authentication", as defined in this section.
>>    
>>
>
>What's the point of authenticating again with the same username?  Auth
>with a _different_ username would be more interesting.
>
This is a case of fast reauthentication using a different TCP 
connection. This is similar to resuming a TLS session.

>>2.2.2  Step Two
>>    
>>
>>   If the response is valid, the server MAY choose to deem that
>>   authentication has succeeded. However, if it has been too long since
>>   the previous authentication, or for any o including the next
>>   subsequent authentication, between the client and the server MUST be
>>   integrity protected.
>>    
>>
>
>I don't understand the text starting with "or from any o".
>
The text in my copy says:

If the response is valid, the server MAY choose to deem that
authentication has succeeded. However, if it has been too long since the
previous authentication, or for any other reason, the server MAY send a
new "digest-challenge" with a new value for nonce. The challenge MAY
contain a "stale" directive with value "true", which says that the
client may respond to the challenge using the password it used in the
previous response; otherwise, the client must solicit the password anew
from the user. This permits the server to make sure that the user has
presented their password recently. (The directive name refers to the
previous nonce being stale, not to the last use of the password.) Except
for the handling of "stale", after sending the "digest-challenge"
authentication proceeds as in the case of initial authentication.

So I am not sure where have you found this.

>>   Using as a base session key the value of H(A1)
>>   as defined above
>>    
>>
>
>need a "," here
>
Ok.

>>   Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
>>   received value; the message is discarded if they differ.
>>
>> The
>>   receiver's sequence counter is incremented if they match.
>>    
>>
>
>Doesn't the server send a response?  How does the client know that the
>authentication is completed?
>
This whole section talks about protecting data when authentication is 
already complete.

> ...
>
>>5.1   Normative references
>>    
>>
>>   [RFC 2222] Myers, J., "Simple Authentication and Security Layer
>>              (SASL)", RFC 2222, October 1997.
>>    
>>
>
>Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt.
>
Fixed, thanks.

>... 
>
>>        ( *LWS element *( *LWS "," *LWS element ))
>>    
>>
>
>Should this really be asymmetric, or should it be
>          (      element *( *LWS "," *LWS element ))
>or
>          ( *LWS element *( *LWS "," *LWS element ) *LWS )
>
I can go for the last proposal. At least it seems to be the original intent.

>?
>
>  
>
>>7.2   Basic Rules
>>    
>>
>
>  
>
>>       OCTET          = <any 8-bit character>
>>    
>>
>
>s/character/byte/, I think.
>
I actually disagree in this case. A byte has 8 bits by definition.

>  A byte in a multi-byte UTF-8 character
>is not normally considered a character.
>
I am not talking about Unicode characters here.


Thank you for your comments. In the meantime I will work (and think 
more) on the rest of them.

Regards,

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