Re: [AAA-DOCTORS] [OPS-DIR] FW: Evaluation: draft-gulbrandsen-imap-response-codes-07.txt to Proposed Standard

The security considerations note:

   Revealing information about a passphrase to unauthenticated IMAP
   clients has bad karma.

I'd say it's worse than that, notably:

AUTHENTICATIONFAILED doesn't reveal that much that can't already be
concluded.

   AUTHENTICATIONFAILED Authentication failed for some reason which the
               server is not willing to elaborate. Typically this
               includes "unknown user" and "bad password".

               This is the same as not sending any response code, except
               that when a client sees AUTHENTICATIONFAILED, it knows
               that the problem wasn't e.g. UNAVAILABLE, so there's no
               point in trying the same login/password again later.

               C: b LOGIN "fred" "foo"
               S: b NO [AUTHENTICATIONFAILED] Authentication failed

AUTHORIZATIONFAILED reveals that the identity is valid. The results can
be used to reduce the search space for the currently in vogue brute
force attempts considerably. Assuming some kind of congruence between
username and email address it can also be used as a brute force address
harvesting mechanism, or to generate more information about the users on
 a potential target.

   AUTHORIZATIONFAILED Authentication succeeded, but authorization
               failed. This is only applicable when the authentication
               and authorization identities are different.

               C: c AUTHENTICATE PLAIN
               [...]
               S: c NO [AUTHORIZATIONFAILED] No such auth-ID

Expired on the other hand only reveals information to possessors of
valid credentials.

   EXPIRED     Authentication succeeded or the server didn't have the
               necessary data any more, but access is no longer
               permitted using that passphrase. The client or user
               should get a new passphrase.

               C: d login "fred" "foo"
               S: d NO [EXPIRED] That password isn't valid any more

Romascanu, Dan (Dan) wrote:
>  
> 
> 
> 
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-gulbrandsen-imap-response-code
> s-07.txt'
> 
> Technical Summary
> 
>    IMAP responses consist of a response type (OK, NO, BAD), an optional
>    machine-readable response code and a human-readable text.
> 
>    This document collects and documents a variety of machine-readable
>    response codes, for better interoperation and error reporting.
> 
> Working Group Summary
> 
>   This is not a WG document.
>   Nothing worth reporting.
> 
> Document Quality
> 
>   The document was extensively reviewed by both IMAP client and
>   server implementors. There are already several implementations
>   of this document.
> 
>   At least 10 people have reviewed the document. Majority of posted
>   comments were addressed in the latest revision.
> 
> Personnel
> 
>   Alexey Melnikov <alexey.melnikov@isode.com> is the document shepherd
>   for this document.  Chris Newman has reviewed this document for the
>   IESG.
> 
> Note to RFC Editor
> 
>   [pending text for secdir review, possibly for IANA question]
> 
> 
> 
> 
> 
> 
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
> 