RFC Errata
Found 8 records.
Status: Verified (3)
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
Source of RFC: sasl (sec)
Errata ID: 2651
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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 (2)
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
Source of RFC: sasl (sec)
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.
Errata ID: 5580
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wang Xin
Date Reported: 2018-12-19
Section 7 says:
server-error-value = "invalid-encoding" /
"extensions-not-supported" / ; unrecognized 'm' value
"invalid-proof" /
"channel-bindings-dont-match" /
"server-does-support-channel-binding" /
; server does not support channel binding
"channel-binding-not-supported" /
"unsupported-channel-binding-type" /
"unknown-user" /
"invalid-username-encoding" /
; invalid username encoding (invalid UTF-8 or
; SASLprep failed)
"no-resources" /
"other-error" /
server-error-value-ext
; Unrecognized errors should be treated as "other-error".
; In order to prevent information disclosure, the server
; may substitute the real reason with "other-error".
It should say:
server-error-value = "invalid-encoding" /
"extensions-not-supported" / ; unrecognized 'm' value
"invalid-proof" /
"channel-bindings-dont-match" /
"server-does-support-channel-binding" /
; the client thinks the server does not support
; channel binding, but the server does
"channel-binding-not-supported" /
"unsupported-channel-binding-type" /
"unknown-user" /
"invalid-username-encoding" /
; invalid username encoding (invalid UTF-8 or
; SASLprep failed)
"no-resources" /
"other-error" /
server-error-value-ext
; Unrecognized errors should be treated as "other-error".
; In order to prevent information disclosure, the server
; may substitute the real reason with "other-error".
Notes:
See Section 6, "If the flag is set to "y" and the server supports channel binding, the server MUST fail authentication. "
I assume the server-error-value "server-does-support-channel-binding" is designed for such situation.
Status: Held for Document Update (1)
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
Source of RFC: sasl (sec)
Errata ID: 2689
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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 (2)
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
Source of RFC: sasl (sec)
Errata ID: 3472
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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
Errata ID: 5882
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Neil Madden
Date Reported: 2019-10-25
Rejected by: Benjamin Kaduk
Date Rejected: 2019-10-25
Section 2.2 says:
Hi(str, salt, i):
U1 := HMAC(str, salt + INT(1))
U2 := HMAC(str, U1)
...
Ui-1 := HMAC(str, Ui-2)
Ui := HMAC(str, Ui-1)
Hi := U1 XOR U2 XOR ... XOR Ui
It should say:
Hi(str, salt, i):
U1 := HMAC(str, salt + INT(i))
U2 := HMAC(str, U1)
...
Ui-1 := HMAC(str, Ui-2)
Ui := HMAC(str, Ui-1)
Hi := U1 XOR U2 XOR ... XOR Ui
Notes:
The first round of PBKDF2 is defined incorrectly with a hard-coded value "INT(1)" rather than "INT(i)" (the iteration count). See RFC 2898 section 5.2 step 3. This error means that the computation of PBKDF2 with n iterations is a prefix of the computation required for PBKDF2 with m iterations (with m > n), which is otherwise not the case (and may have security implications?).
--VERIFIER NOTES--
Rejected per submitter request. The 1 here indicates it is the first block of the output stream being computed, and only one such block is needed.