[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Abhijit Menon-Sen wrote:
At 2007-01-14 08:45:44 +0100, nobody@xxxxxxxxxxxxxxxxx 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.