RFC 7804, "Salted Challenge Response HTTP Authentication Mechanism", March 2016

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