RFC 5802, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", July 2010

Note: This RFC has been updated by RFC 7677, RFC 9266

Errata ID: 5271
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Golden
Date Reported: 2018-03-02

Section 5.1, 7 says:

Section 5.1:

   o  e: This attribute specifies an error that occurred during
      authentication exchange.  It is sent by the server in its final
      message and can help diagnose the reason for the authentication
      exchange failure.  On failed authentication, the entire server-
      final-message is OPTIONAL; specifically, a server implementation
      MAY conclude the SASL exchange with a failure without sending the
      server-final-message.  This results in an application-level error
      response without an extra round-trip.  If the server-final-message
      is sent on authentication failure, then the "e" attribute MUST be
      included.

Section 7:

   server-first-message =
                     [reserved-mext ","] nonce "," salt ","
                     iteration-count ["," extensions]

It should say:

Section 5.1:

   o  e: This attribute specifies an error that occurred during
      authentication exchange.  It is sent by the server in its first
      or final message and can help diagnose the reason for the
      authentication exchange failure.  On failed authentication, the
      entire server-first-message or server-final-message is OPTIONAL;
      specifically, a server implementation MAY conclude the SASL
      exchange with a failure without sending the a message.  This
      results in an application-level error response without an extra
      round-trip.  If a server message is sent on authentication
      failure, then the "e" attribute MUST be included.

Section 7:

   server-first-message-bare =
                     [reserved-mext ","] nonce "," salt ","
                     iteration-count

   server-first-message = (server-error / server-first-message-bare)
                     ["," extensions]

Notes:

Many of the server-error message options in the formal syntax apply to fields received in the client-first message, e.g. "invalid-username-encoding" or "extensions-not-supported". There is no existing provision in the formal syntax for a server to return a server-error in response to a client-first message. The intent of the server-error field appears to include responses to the client-first message and there are no meaningful responses to such errors. E.g. what salt and iteration count should be returned in the case of invalid-username-encoding? Therefore, this proposed errata allows server-error to be returned as the server-first-message and amends the explanatory text of section 5.1 accordingly.

Report New Errata