On Wed, 2010-08-04 at 14:04 +0100, pod wrote: > The case seems clear for STARTTLS; you advertise only non-plaintext AUTH > mechanisms and LOGINDISABLED initially and after successful STARTTLS you > can advertise plaintext AUTH mechanisms and remove LOGINDISABLED.
Yes. > I must > confess I am having trouble untangling the precise meaning of the text > related to AUTHENTICATE though. Some auth mechanisms like GSSAPI and DIGEST-MD5 can add encryption/integrity protection to the stream. So in case of MITM attacks, the attacker could alter the CAPABILITY list before AUTHENTICATE, but not after it. I think RFC 3501 primarily talks about capability changing because of this. RFC 3501 isn't fully clear that clients should update their capabilities when a CAPABILITY resp-code is sent on LOGIN, but this does strongly hint that: > A server MAY include a CAPABILITY response code in the tagged OK > response to a successful LOGIN command in order to send > capabilities automatically. It is unnecessary for a client to > send a separate CAPABILITY command if it recognizes these > automatic capabilities.
