RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (3)

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

Source of RFC: sasl (sec)

Errata ID: 2651
Status: Verified
Type: Technical

Reported By: Jehan Pagès
Date Reported: 2010-11-30
Verifier Name: Sean Turner
Date Verified: 2011-03-09

Section 7 says:

   nonce           = "r=" c-nonce [s-nonce]
                     ;; Second part provided by server.

   c-nonce         = printable

   s-nonce         = printable

It should say:

   nonce           = "r=" c-nonce [s-nonce]
                     ;; Second part provided by server.

   c-nonce         = 1*(printable)

   s-nonce         = 1*(printable)

Notes:

"printable" is defined this way:
printable = %x21-2B / %x2D-7E
;; Printable ASCII except ",".
;; Note that any "printable" is also
;; a valid "value".

Hence a "printable" is a single printable character (except ','). But a nonce is a "a sequence of random printable ASCII characters excluding ','" (section 5.1), as can also be seen by the examples (and common sense for a security feature using randomness).

Errata ID: 2652
Status: Verified
Type: Technical

Reported By: Jehan Pagès
Date Reported: 2010-11-30
Verifier Name: Sean Turner
Date Verified: 2011-03-26

Section 9 says:


It should say:

Add the follow to the end of the 4th paragraph (starts with if an attacker):

  Further, implementations are RECOMMENDED to reject salt values
  shorter than 2 characters and MAY reject even longer salt values if
  they are considered to be insufficient.  See [RFC4086] on generating
  randomness.

Notes:

The original version (in Sec 7) would allow the empty string (hence the base64 encoding of an empty string). Though it may technically be an acceptable base64 encoded string, it is not acceptable in our use as we use it for security features which are not supposed to be empty (though it is not defined this way, but common sense tells). This security consideration addresses this concern.

Errata ID: 2640
Status: Verified
Type: Editorial

Reported By: Jehan Pagès
Date Reported: 2010-11-22
Verifier Name: Tim Polk
Date Verified: 2011-03-26

Section 5 says:

The server verifies the nonce and the proof, verifies that the
authorization identity (if supplied by the client in the first
message) is authorized to act as the authentication identity, and,
finally, it responds with a "server-final-message", concluding the
authentication exchange.

It should say:

The server verifies the nonce and the proof, verifies that the
authentication identity is authorized to act as the authorization
identity (if supplied by the client in the first message) , and,
finally, it responds with a "server-final-message", concluding the
authentication exchange.

Notes:

It is the authentication identity which acts as (if authorized to) the authorization identity, not the opposite.

Status: Reported (1)

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

Source of RFC: sasl (sec)

Errata ID: 5271
Status: Reported
Type: Technical

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.

Status: Held for Document Update (1)

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

Source of RFC: sasl (sec)

Errata ID: 2689
Status: Held for Document Update
Type: Editorial

Reported By: Steffen Lehmann
Date Reported: 2011-01-21
Held for Document Update by: Tim Polk

Section 5.2 says:

2b) SCRAM sends additional data with success.

It should say:

2b) SCRAM sends additional data with success. If the server sends the additional data as a challenge, the response to this challenge is a empty response.

Notes:

The added information MUST be supplied according to RFC 4422, Section 5, Paragraph 2b.

Status: Rejected (1)

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

Source of RFC: sasl (sec)

Errata ID: 3472
Status: Rejected
Type: Technical

Reported By: Marko Kreen
Date Reported: 2013-01-28
Rejected by: Stephen Farrell

Section 5 says:

C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
   i=4096
C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
   p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=

It should say:

C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
   i=4096
C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
   p=frsVRm77a2tPQ5vy+zZuaKRR17o=
S: v=01o5+Qz2QpK1yrmPi3ZwOZzQTzs=

Notes:

The test vector seems wrong, at least I cannot find code pattern that produces same result. Here is the code I used to calculate it:

https://gist.github.com/4654875

Report New Errata