RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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=

Report New Errata