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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 11 Mar 2009 19:48:35 +0100

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 <[email-masked]> 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]

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 11 Mar 2009 13:21:41 -0700

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:
> _______________________________________________
> OPS-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-dir
>