RFC Errata
Found 3 records.
Status: Reported (3)
RFC 7804, "Salted Challenge Response HTTP Authentication Mechanism", March 2016
Source of RFC: httpauth (sec)
Errata ID: 5496
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-09-08
Section 2.2 says:
o Normalize(str): Apply the Preparation and Enforcement steps
according to the OpaqueString profile (see [RFC7613]) to a UTF-8
[RFC3629] encoded "str". The resulting string is also in UTF-8.
Note that implementations MUST either implement OpaqueString
profile operations from [RFC7613] or disallow the use of non
US-ASCII Unicode codepoints in "str". The latter is a particular
case of compliance with [RFC7613].
It should say:
o Normalize(str): Apply the Preparation and Enforcement steps
according to the OpaqueString profile (see [RFC7613]) to a UTF-8
[RFC3629] encoded "str". The resulting string is also in UTF-8.
Note that implementations MUST either implement OpaqueString
profile operations from [RFC7613] or disallow the use of Unicode
codepoints not ranging from U+0020 to U+007E in "str". The latter
is a particular case of compliance with [RFC7613].
Notes:
Control code points (including the ASCII controls U+0000 to U+001F as well as U+007F) are disallowed in the PRECIS FreeformClass, which the OpaqueString profile uses. Thus it's not enough to just disallow non-US-ASCII codepoints (rather than implement the full OpaqueString profile) to comply with a subset of the OpaqueString profile.
Errata ID: 6558
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephan Bosch
Date Reported: 2021-04-24
Section 5 says:
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
TUhnc3FtbWl6N0FuZFZRPQo=
C: [...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo=
S: [...Other header fields and resource body...]
It should say:
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
data="Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
TUhnc3FtbWl6N0FuZFZRPQo="
C: [...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data="dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo="
S: [...Other header fields and resource body...]
Notes:
The "data" parameter values for the example client request and server response are not quoted, even though these values do not comply with the HTTP token syntax (these both contain a final '='). This means that these examples are in fact invalid.
Found at least one server that implemented their HTTP SCRAM mechanism based on this example, expecting the data parameter to be unquoted and producing it unquoted as well.
Errata ID: 6633
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Hollberg
Date Reported: 2021-07-09
Section 5 says:
This is a simple example of a SCRAM-SHA-256 authentication exchange
(no support for channel bindings, as this feature is not currently
supported by HTTP). Username 'user' and password 'pencil' are used.
Note that long lines are folded for readability.
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@example.com",
Digest realm="realm2@example.com",
Digest realm="realm3@example.com",
SCRAM-SHA-256 realm="realm3@example.com",
SCRAM-SHA-256 realm="testrealm@example.com"
S: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8K
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: SCRAM-SHA-256
sid=AAAABBBBCCCCDDDD,
data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJ
bGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYK
S: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
TUhnc3FtbWl6N0FuZFZRPQo=
C: [...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo=
S: [...Other header fields and resource body...]
In the above example, the first client request contains a "data"
attribute that base64 decodes as follows:
n,,n=user,r=rOprNGfwEbeRWgbNEkqO
The server then responds with a "data" attribute that base64 decodes
as follows:
r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,s=W22ZaJ0SNY7soE
sUEjb6gQ==,i=4096
The next client request contains a "data" attribute that base64
decodes as follows:
c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZap
WIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=
The final server response contains a "data" attribute that base64
decodes as follows:
v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=
It should say:
This is a simple example of a SCRAM-SHA-256 authentication exchange
(no support for channel bindings, as this feature is not currently
supported by HTTP). Username 'user' and password 'pencil' are used.
Note that long lines are folded for readability.
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@example.com",
Digest realm="realm2@example.com",
Digest realm="realm3@example.com",
SCRAM-SHA-256 realm="realm3@example.com",
SCRAM-SHA-256 realm="testrealm@example.com"
S: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: SCRAM-SHA-256
sid=AAAABBBBCCCCDDDD,
data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJ
bGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=
S: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
TUhnc3FtbWl6N0FuZFZRPQo=
C: [...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo=
S: [...Other header fields and resource body...]
In the above example, the first client request contains a "data"
attribute that base64 decodes as follows:
n,,n=user,r=rOprNGfwEbeRWgbNEkqO
The server then responds with a "data" attribute that base64 decodes
as follows:
r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,s=W22ZaJ0SNY7soE
sUEjb6gQ==,i=4096
The next client request contains a "data" attribute that base64
decodes as follows:
c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZap
WIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=
The final server response contains a "data" attribute that base64
decodes as follows:
v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=
Notes:
The original base64 encoded values of the client first message and server first message are wrong.
Notice that these values end in K. These values base64 decode to strings that end in new line characters.
The original base64 encoded values of the client final message and server final message are correct.
Notice that these values end in =. These values base64 decode to string that do not end in new line characters.
It appears that during the base64 encoding of the client first message and server first message, the newline characters were accidentally included.
The correct base64 encoding is as follows:
n,,n=user,r=rOprNGfwEbeRWgbNEkqO base64 encodes to biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096 base64 encodes to cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=