Subject: [http-auth] Definition of SHA256 and SHA512/256 algorithms in RFC 7616

From: Chaim Geretz <[email-masked]>
Date: Wed, 28 Dec 2016 14:19:21 -0500

Greetings,

I think that RFC 7616 needs to define or point to a document describing how
the various hash algorithms mentioned in Section 3.2 are to be implemented.

Inspecting the values used in Section 3.9.2 for userhash and response shows
that they are generated by truncating the hex output of a sha512 hash to
the initial 64 hex characters.

If this is the desired implementation of SHA512/256 then this should be
mentioned in the RFC.

If the intention is to use SHA512/256 as described in FIPS 180.4 then this
should be mentioned, and the values changed to
userhash="793263caabb707a56211940d90411ea4a575adeccb7e360aeb624ed06ece9b0b"
and response=
"3798d4131c277846293534c3edc11bd8a5e4cdcbff78b05db9d95eeb1cec68a5"

Chaim Geretz

---

From: Chaim Geretz <[email-masked]>
Date: Thu, 29 Dec 2016 13:12:20 -0500

Sophie,

Thanks for your response

> The linked IANA registry for the hash algorithms clarifies the use as in
FIPS 180-3.

The reference to FIPS 180-3 is only for the HTTP Digest Algorithm
Values SHA-256
and SHA-512.

http://www.iana.org/assignments/http-dig-alg/http-dig-alg.txt does not
include any specification information for SHA-512-256 save for a pointer to
RFC 7616.

Chaim

On Thu, Dec 29, 2016 at 12:43 PM, Sophie Bremer <
[email-masked]> wrote:

> Hi Chaim,
>
> thank you for pointing this out!
> It explains some problems I had myself with the implementation for proxy
> servers.
>
> > Am 28.12.2016 um 20:19 schrieb Chaim Geretz <[email-masked]>:
> >
> > Greetings,
> >
> > I think that RFC 7616 needs to define or point to a document describing
> how the various hash algorithms mentioned in Section 3.2 are to be
> implemented.
>
> The linked IANA registry for the hash algorithms clarifies the use as in
> FIPS 180-3.
> On the other hand the registry may change in the future and so the
> definition of the algorithm value too.
> If this is a possible scenario, I agree with you.
> I like to see more opinions for this proposal.
>
> > Inspecting the values used in Section 3.9.2 for userhash and response
> shows that they are generated by truncating the hex output of a sha512 hash
> to the initial 64 hex characters.
>
> You are right.
>
> The example is not in sync with the IANA registry and has to be updated.
>
> > If the intention is to use SHA512/256 as described in FIPS 180.4 then
> this should be mentioned, and the values changed to
> and response="3798d4131c277846293534c3edc11bd8a5e4cdcbff78b05db9
> d95eeb1cec68a5"
>
> I will look into your provided values and clarify/correct the example.
>
> Once again, thank you for this catch!
>
> Best Regards,
> Sophie
>

---

From: Chaim Geretz <[email-masked]>
Date: Thu, 29 Dec 2016 13:20:41 -0500

As a follow up, FIPS 180-3 does not have a definition of SHA512/256, other
than the inference from section 7 that allows truncation of the result of
an existing algorithm. That aligns with the example given in RFC 7616.

FIPS 180-4 introduced the possibility of a different implementation of
SHA512/256, but still leaves open the possibility of truncation of the
results of an existing algorithm.

On Thu, Dec 29, 2016 at 1:12 PM, Chaim Geretz <[email-masked]> wrote:

> The reference to FIPS 180-3 is only for the HTTP Digest Algorithm Values SHA-256
> and SHA-512.
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 29 Dec 2016 13:47:59 -0500

Hi Chaim,

I do not think that the intention was to truncate any of these hashes.
It seems that the example is incorrect.

Can you please open a new errata against the RFC?
https://www.rfc-editor.org/errata.php

Thanks,
 Rifaat

On Thu, Dec 29, 2016 at 1:20 PM, Chaim Geretz <[email-masked]> wrote:

>> > The linked IANA registry for the hash algorithms clarifies the use as
>> in FIPS 180-3.
>>
>>> > I think that RFC 7616 needs to define or point to a document
>>> describing how the various hash algorithms mentioned in Section 3.2 are to
>>> be implemented.
>>>
>>> > If this is the desired implementation of SHA512/256 then this should
>>> be mentioned in the RFC.
>>>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>
>