- From: Benjamin Kaduk <kaduk@mit.edu>
- Date: Sun, 1 Aug 2021 19:30:48 -0700
- To: RFC Errata System <rfc-editor@rfc-editor.org>
- Cc: alexey.melnikov@isode.com, rdd@cert.org, ynir.ietf@gmail.com, rifaat.ietf@gmail.com, benhollbergb@googlemail.com, ietf-http-wg@w3.org
Adding httpbis since, per https://mailarchive.ietf.org/arch/msg/http-auth/09-9tYS4hvI4C6Uhv1GEWSZ35W4/, http-auth is closed. Alexey, did you have any thoughts on this one? Thanks, Ben On Fri, Jul 09, 2021 at 01:19:24AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC7804, > "Salted Challenge Response HTTP Authentication Mechanism". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6633 > > -------------------------------------- > Type: Technical > Reported by: Ben Hollberg <benhollbergb@googlemail.com> > > Section: 5 > > Original Text > ------------- > 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= > > Corrected Text > -------------- > 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= > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7804 (draft-ietf-httpauth-scram-auth-15) > -------------------------------------- > Title : Salted Challenge Response HTTP Authentication Mechanism > Publication Date : March 2016 > Author(s) : A. Melnikov > Category : EXPERIMENTAL > Source : Hypertext Transfer Protocol Authentication > Area : Security > Stream : IETF > Verifying Party : IESG
Received on Monday, 2 August 2021 02:31:20 UTC