Re: [Technical Errata Reported] RFC7804 (6633)

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]>
> 
> 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="[e-mail]",
>           Digest realm="[e-mail]",
>           Digest realm="[e-mail]",
>           SCRAM-SHA-256 realm="[e-mail]",
>           SCRAM-SHA-256 realm="[e-mail]"
>    S: [...]
> 
>    C: GET /resource HTTP/1.1
>    C: Host: server.example.com
>    C: Authorization: SCRAM-SHA-256 realm="[e-mail]",
>           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="[e-mail]",
>           Digest realm="[e-mail]",
>           Digest realm="[e-mail]",
>           SCRAM-SHA-256 realm="[e-mail]",
>           SCRAM-SHA-256 realm="[e-mail]"
>    S: [...]
> 
>    C: GET /resource HTTP/1.1
>    C: Host: server.example.com
>    C: Authorization: SCRAM-SHA-256 realm="[e-mail]",
>           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