RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Reported (2)

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.

Report New Errata