Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication

[Alexey Melnikov <[e-mail]>]

Abhijit Menon-Sen wrote:

>At 2007-01-14 08:45:44 +0100, [e-mail] wrote:
>  
>
>>None of the POP3 servers I know support SASL, let alone DIGEST-MD5.
>>    
>>
>Just a note: My POP3 server has supported SASL for a long time.
>  
>
The same is true for Cyrus and Isode implementations.

 [...]

>>Other nits / questions about the -08 draft:
>>
>>RFC 1734  had "AUTH" 1*WSP auth_type *(CRLF base64) CRLF
>>The draft has "AUTH" SP sasl-mech [SP (base64 / "=" )] *(CRLF [base64]) CRLF
>>
>>1: Why was 1*WSP replaced by a single SP ?
>>    
>>
>I don't know (happened before I inherited the draft). Rob?
>
 Only allowing for a single space makes implementation simpler.

[...]

>>The added DIGEST-MD5 example (thanks!) uses an RFC 4422 "empty response"
>>at the end:
>>
>>    S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
>>    C:
>>    S: +OK Maildrop locked and ready
>>
>>5: Why is an empty response no "=" as in the <initial-response> ?
>>    
>>
>Because it's not an initial response. (The "=" encoding for an empty
>SASL initial response is taken from Rob's IMAP SASL-IR draft.)
>  
>
Historically an empty response wasn't sent as "=". The "=" is used to 
specify an empty initial response (which is different from the missing 
initial response).

>>The syntax for <continue-req> requires a trailing space if it's empty.
>>
>>    continue-req    = "+" SP [base64] CRLF
>>    
>>
>That's consistent with IMAP.
>
>I notice the following:
>
>    Additionally, the ABNF specified in [RFC2449] is updated as follows:
>
>          challenge      /= continue-req
>
>But the ABNF specified in RFC2449 (pop3 extension mechanism) doesn't
>actually define a "challenge" at all (and that /= should be =/ in any
>case). I can't find anything that seems to define challenge in a way
>relevant to POP3. (1734 doesn't define challenge at all.)
>
>Rob? Do you remember what the intent was here?
>  
>
The space is required in other application protocols using SASL (e.g. IMAP).

 [...]

>>8: What is the meaning of a <realm> wrt POP3 ?  Can servers pick what
>>   they like ?
>>
Yes.

>>What's the definition of <authzid> wrt POP3 ?
>>
 From POP3 SASL draft:
          The authorization identity generated by the SASL exchange is a
          simple username, and SHOULD use the SASLprep profile (see
          [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to
          prepare these names for matching.  If preparation of the
          authorization identity fails or results in an empty string
          (unless it was transmitted as the empty string), the server
          MUST fail the authentication.

>>  If it
>>   isn't allowed the draft should mention this.
>>    
>>
>That depends entirely on the server implementation, I'd say.
>  
>
>>9: RFC 2831 requires that the size of a digest-response is less than
>>   4096 bytes.  4*4095/3=5460, the draft should state this limit for
>>   a DIGEST-MD5 response, it's more than the 40 guaranteed in RFC 1939.
>>    
>>
>
>I don't think it's really necessary. The length limitation, so far as it
>applies to the initial-response, is described already:
>
>          For the purposes of the initial client response, the line
>          length limitation defined in [RFC2449] still applies.  If a
>          client initial send would cause the AUTH command to exceed
>          this length, the client MUST NOT use the initial response
>          parameter (and must proceed instead by sending its initial
>          response after an empty challenge from the server, as in
>          section 3 of [RFC4422]).
>  
>
 [...]

>>11: Can the client indicate its <maxbuf>, and what would servers do
>>    with it ?
>>
The server is not allowed to send buffers encoded with SASL security 
layer, which are bigger than the value specified by the client.

>>Do all clients support the default 64 KB ?
>>
I don't think so. It wouldn't be the case for clients running on small 
devices.

>>Wrt POP3 is
>>    a <maxbuf> the maximal line lenght, or the combined multi-line
>>    lenght (i.e. message size) ?
>>    
>>
Neither. <maxbuf> is not related to line lengths during authentication 
exchange, it only affects SASL security layer.

>I'm afraid I have no idea.
>  
>