From nobody Wed Dec 28 11:53:10 2016 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5D8129564 for ; Wed, 28 Dec 2016 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=idt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3iEjiJvH97E for ; Wed, 28 Dec 2016 11:19:42 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6A312945D for ; Wed, 28 Dec 2016 11:19:42 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id v84so379123701oie.3 for ; Wed, 28 Dec 2016 11:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=xxgD71ss3ZbovkSvV40YABLjDPGh4G5ess281/Kzjro=; b=muG9R2XD10iHbss4avpF3LrkZIr5PmbpX61RAiup/EdlE6KXJLXcPj29R1F6Ds5LMs 6a4TE8m5/a3WntYyJNm14oS2FnglhLnWvFKc3a1CWZTju7UPO+sRZ0G40QRM0AXGi6rG 690hBYFMksW7mmRCFzdlvLjLM1mH5YKmTvdXDCHcZ1C49ZWyZs7s63R6koycOgXmhvVG J4p23TarvwCx3Mo2cgzecGvVhiD3FSiKgUzvqjoGOF940ISqDNJ6SNaoPAnkwqXz8GKS AEeFikEj2B+ogiQHTShqVkST4KgUMWIPdcFD8CZnWLdbOJ1c8EIzVIPhEf7o7vMIkR06 NwRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xxgD71ss3ZbovkSvV40YABLjDPGh4G5ess281/Kzjro=; b=mjhHgMxwb6uSI/BdoPjrKYIS16UajO+ULobQhIC7ruYZnbDqUrq8sOV6/nuxMOrQCX PNe8b6C/mD+lohKFXArIEzBeRRtA7AOTttfrOvEFMgXhX+UiTgV2qnbm6jOKk9liXWYj 7f6TRQCjyzd4WfBvVKKhIvwJfgLShI6y3OSIgiZ+qvw1vMFNqh3iwYAG6Zq4/KnPUBaA TLGrCgwyliamKZMheHgSCEv2RFLs1Vov1g1u980Jhl36kIITyZWcnvSF0tiwn3qSsVzB gk4NqWjjlNgzEs7LEtOkqETOYyKvpio/PSYVHPW67RdM9qDJkIDnqaf8HZ80sY0Oavl/ TOEg== X-Gm-Message-State: AIkVDXIxEc/ydWDYDcVCS8FcN57OAAEQGack98uJQQDG6ycJo7N9qaAk9EZxMvAwtPsboIlEv/lv02WAYtAPi0kX X-Received: by 10.202.240.195 with SMTP id o186mr18732817oih.28.1482952781488; Wed, 28 Dec 2016 11:19:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Wed, 28 Dec 2016 11:19:21 -0800 (PST) From: Chaim Geretz Date: Wed, 28 Dec 2016 14:19:21 -0500 Message-ID: To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=94eb2c096318c277560544bcd95f Archived-At: X-Mailman-Approved-At: Wed, 28 Dec 2016 11:53:08 -0800 Subject: [http-auth] Definition of SHA256 and SHA512/256 algorithms in RFC 7616 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 19:19:44 -0000 --94eb2c096318c277560544bcd95f Content-Type: text/plain; charset=UTF-8 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 --94eb2c096318c277560544bcd95f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings,
I think that RFC 7616 needs to define or poin= t to a document describing how the various hash algorithms mentioned in Sec= tion 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/25= 6 as described in FIPS 180.4 then this should be mentioned, and the values = changed to userhash=3D"793263caabb707a56211940d90411ea4a575adeccb7e360= aeb624ed06ece9b0b" and response=3D"3798d4131c277846293534c3edc11bd8a5e4c= dcbff78b05db9d95eeb1cec68a5"

Chaim Geretz
--94eb2c096318c277560544bcd95f-- From nobody Thu Dec 29 10:12:44 2016 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6056129640 for ; Thu, 29 Dec 2016 10:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=idt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mByq1gnSJmc for ; Thu, 29 Dec 2016 10:12:41 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0F4129443 for ; Thu, 29 Dec 2016 10:12:41 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id 128so209410485oig.0 for ; Thu, 29 Dec 2016 10:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kNuMyD3kpahEgAxk3L0wKgycvoArpOnKTzh0YDqHpzM=; b=ufb0SKh+u35mZZ/cA5lfbRZo6sCUlCcmgbui+VQJr3xuR2/69OIGKFVK9YfXP96Pqy vQMm85CqOYszlckpYj4goriPorZn8xwTNxvjeRKlB/laPMW31CGRFTZSKa491/A0Wg40 Kvv9c26JRFuhPuudrcnWDIUse+vK7rAgk+w37KPLozogzffDusmqyVxgyQl6olknYkc0 Ppzagn9N2mgMdyOMC1WXf1SQN5DpmYyjGeH3Wu623uqaV9SS/2rVvPAXs/95TSjEBBeD YDKcsqpQABQMtWQemL2FXER0g7rn9Zqyby7luIR5k8JrLcSXALUPFnV/JjgbXs7Ru8Dp 2e5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kNuMyD3kpahEgAxk3L0wKgycvoArpOnKTzh0YDqHpzM=; b=Yi1B/ywV0H5HWk9HhQNpzYYw6/Ks+hvR/DI4dzb6cknn7FJoSf6QnYEFTuNe7EL3Et gWtHdhYn6s87Lr71VJbFBeQqatHd7ADim0/cSm4qVV+VkXvkaUXgp5Y3KOv/UXTz8Ofg G1JMW40UeEwXa8ptWvXmUIbkX46dJDlvjIr6/84W/4D22dvRnCUCVGBbsP2zUSi+3u2e zX8vsafHBWeGVUUXbKURK4fHyix7FAlAEPEimN78XX3i1e/iTkqdr/0G9iBbGN5IHAhk xax2xRl6A+Q19DSk6nSo7ZmPtk8lpNk4QoIJOLQTlF78JQA+8w2EHxOdbhaxVBC5+jLr uDNw== X-Gm-Message-State: AIkVDXLSzZT7625tY5XYn+/8u0jfth6ruWsKKzdMc+ffU9vLd8qKvagnHGtCGtkBM5BWfyO+AROj9Pjp8g3wPVOs X-Received: by 10.157.9.249 with SMTP id 54mr22687505otz.157.1483035161030; Thu, 29 Dec 2016 10:12:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Thu, 29 Dec 2016 10:12:20 -0800 (PST) In-Reply-To: References: From: Chaim Geretz Date: Thu, 29 Dec 2016 13:12:20 -0500 Message-ID: To: Sophie Bremer Content-Type: multipart/alternative; boundary=001a1134f50ef686940544d00738 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Definition of SHA256 and SHA512/256 algorithms in RFC 7616 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 18:12:43 -0000 --001a1134f50ef686940544d00738 Content-Type: text/plain; charset=UTF-8 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 < sophie.bremer@netzkonform.de> 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 : > > > > 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. > > > If this is the desired implementation of SHA512/256 then this should be > mentioned in the RFC. > > 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 > userhash="793263caabb707a56211940d90411ea4a575adeccb7e360aeb624ed06ece9b0b" > 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 > --001a1134f50ef686940544d00738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sop= hie,

=
Thanks for your resp= onse

=
> 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=C2=A0HTTP Digest Algorithm Values SHA-256 and SHA-512.

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

=
Chaim


On Thu, Dec 29, 2016 at 12:43 PM, Sophie Bremer <sophie.bremer@netzkonform.de> wrote:
Hi Chaim,

thank you for pointing this out!
It explains some problems I had myself with the implementation for proxy se= rvers.

> Am 28.12.2016 um 20:19 schrieb Chaim Geretz <chaim.geretz@idt.net>:
>
> Greetings,
>
> I think that RFC 7616 needs to define or point to a document describin= g how the various hash algorithms mentioned in Section 3.2 are to be implem= ented.

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 definiti= on 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.

> If this is the desired implementation of SHA512/256 then this should b= e mentioned in the RFC.

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 userhash=3D= "793263caabb707a56211940d90411ea4a575adeccb7e360aeb624ed06ec= e9b0b" and response=3D"3798d4131c277846293534c3edc11bd8a5e4c= dcbff78b05db9d95eeb1cec68a5"

I will look into your provided values and clarify= /correct the example.

Once again, thank you for this catch!

Best Regards,
Sophie

--001a1134f50ef686940544d00738-- From nobody Thu Dec 29 10:21:06 2016 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9A129623 for ; Thu, 29 Dec 2016 10:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=idt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSe7mQPXKO0c for ; Thu, 29 Dec 2016 10:21:03 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F5D129497 for ; Thu, 29 Dec 2016 10:21:03 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id b126so405021831oia.2 for ; Thu, 29 Dec 2016 10:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fTayoj4EFKvpQYVt4VhablK6meuNlqdW0CFteT3rgvU=; b=bFFidkjh/z2BOwapt+ZS+RYAtnfpYE/jdpJScbpVJ5MZgrBMIwOnvuSzRwXBXoGuLK 8E9UlnHcBes24id8509Z1M2jdbURiw/pp1OZVE5KPMYoQdPYXg8i31kLfOLs+cjvQRKt WzcnOkvOOoPyX4ENI1Qs3kX3MMkbJn142L5yTcplTW9gXDNmJpQ06nnb5IGqpVO3lnfb b3dxeaxknin4Cd/fmmuitTa5VCyvHvyb3zrhmbvbKgf1jMd4QwkptHd6qBWjhI2qYv6V SUgL26j0Fq3SHeTpMko/u7oMQfgFl1AZy2uH4YLErUWuu8kKOIMoOe/YbC6ZOnqAE/A4 b8tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fTayoj4EFKvpQYVt4VhablK6meuNlqdW0CFteT3rgvU=; b=RXTWr9Sg03f4cMovavQSl5yhtGCcLxyo3MEDRsom/uosLwPLKp63aC7Kdht+BLkcLO WLNCavwPLsBoCmb/w3Pl7aXj4zn1Bh1UrFBjAEDwHITJLb240zyWKlBfL2TzlBfdxz/k G8ybZF4lKYQBaJEOlyCMEZAJ67omj7VLyyGTGP1sxikG5fEboVM+5GRXvPb2n7b+SrKD z4LssxXH/8qfwViuxByjiH9gbN42KfLDh2zEjk6s9C0nF/11+WITzKj/LZgcP8X62Uvb R/+OgTgiweFjh6tGiPFSGR7ioNGXRKuLwAtja7xO7CC5JpS6YrikrWsGo7CDLdZZQJk1 CiPA== X-Gm-Message-State: AIkVDXLjobxVssvkOENz2q9WC0AgMe2GJ4KYl6bST+9NeBk9GfiWaq5d9AFUb8MXJN+AwLIbzQGPEJnYv25QOnHp X-Received: by 10.202.80.149 with SMTP id e143mr18253276oib.93.1483035662347; Thu, 29 Dec 2016 10:21:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Thu, 29 Dec 2016 10:20:41 -0800 (PST) In-Reply-To: References: From: Chaim Geretz Date: Thu, 29 Dec 2016 13:20:41 -0500 Message-ID: To: Sophie Bremer Content-Type: multipart/alternative; boundary=001a113d818ad80a110544d025ea Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Definition of SHA256 and SHA512/256 algorithms in RFC 7616 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 18:21:05 -0000 --001a113d818ad80a110544d025ea Content-Type: text/plain; charset=UTF-8 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 wrote: > 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 < > sophie.bremer@netzkonform.de> 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 : >> > >> > 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. >> >> > If this is the desired implementation of SHA512/256 then this should be >> mentioned in the RFC. >> >> 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 >> userhash="793263caabb707a56211940d90411ea4a575adeccb7e360aeb624ed06ece9b0b" >> 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 >> > > --001a113d818ad80a110544d025ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As = a follow up, FIPS 180-3 does not have a definition of SHA512/256, other tha= n the inference from section 7 that allows truncation of the result of an e= xisting algorithm. That aligns with the example given in RFC 7616.

FIPS 180-4 introduced the possibi= lity 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 <chaim.geretz@idt.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Sophie,

Thanks for your response

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

The reference to FIPS 180-3 is only for the=C2= =A0HTTP Digest Algori= thm Values SHA= -256 and SHA-512.

=
http://www.iana.org/assignments/http-dig-alg/http-dig-alg.txt<= /a>=C2=A0does not include any specification information for SHA-512-256 sav= e for a pointer to RFC 7616.=C2=A0

= Chaim

On Thu, Dec 29, 2016 at 12:43 PM, Sophie Bremer= <sophie.bremer@netzkonform.de> wrote:
Hi Chaim,

thank you for pointing this out!
It explains some problems I had myself with the implementation for proxy se= rvers.

> Am 28.12.2016 um 20:19 schrieb Chaim Geretz <chaim.geretz@idt.net>:
>
> Greetings,
>
> I think that RFC 7616 needs to define or point to a document describin= g how the various hash algorithms mentioned in Section 3.2 are to be implem= ented.

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 definiti= on 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.

> If this is the desired implementation of SHA512/256 then this should b= e mentioned in the RFC.

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 mentio= ned, and the values changed to userhash=3D"793263caabb707a5621194= 0d90411ea4a575adeccb7e360aeb624ed06ece9b0b" and response=3D"= 3798d4131c277846293534c3edc11bd8a5e4cdcbff78b05db9d95eeb1cec68a5&= quot;

I will = look into your provided values and clarify/correct the example.

Once again, thank you for this catch!

Best Regards,
Sophie


--001a113d818ad80a110544d025ea-- From nobody Thu Dec 29 10:48:04 2016 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6A51299F1 for ; Thu, 29 Dec 2016 10:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txk1jcDN9sPD for ; Thu, 29 Dec 2016 10:48:01 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3521299F4 for ; Thu, 29 Dec 2016 10:48:00 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 88so231859189uaq.3 for ; Thu, 29 Dec 2016 10:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qMvqhAF6BPOWbQdJkpbrJGyjry2enYTiFyllVmX9j70=; b=VGkbQzJEnXXuBX39x3Fqs+qxv5Nwfddz9+hAwf7PJR/Sgii+chJ/aqRCAuDxeDfF2O x7LlKo9oymRASSDgCzIhZOTKnphEmLGTycqnsTIX/ASswXsr6wK7BpUoKW9UpHpTpfC+ xPxWRsujadEFbiTJpC5snLVNKt4S8O7p9V7gO8T4k6f/g6ES22tYO+EIftFP4S+s0sdX WdAWtD3jdmhaLK8ROLjSmDWZmnqcGTj5Bz/+VP2D+FCcB+T/g0E4h7UAbX2RAs0nFexW qnW+2mluvlSMGGICvZmcnJ+o3qX9/UyWfgRC+wXGZp9Q6LgdipP+lPdql6wHUJ6Qul1O BNpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qMvqhAF6BPOWbQdJkpbrJGyjry2enYTiFyllVmX9j70=; b=DgIOu71QUIkg+321B6UPUON8JRA/NSIBG4SY1rQ5idJDr8xktIdXnOqWCoFt71GdFJ E/cFmSUjdQxdO9SAZi+lj7ai3961nJR9UhFWF0C7ZfF7+ju5FJcM4zoD377husojRjsL OvDrPgmfkXTjI9qIHgixrmX3YvdtlvfXlHwIUO+eVtPI7METjNq1sPuYpRmqhWTUuL+e 1tIaAdnPx3xgMDAueYF0CGFzaM0lexAX+5CqgypXP8LiLbTn+a4pnL8TWI9ZjKOupG0Z nRg3E9g+beP5nkjGPJoNDc+45Y2zRR8E+mVfvUjD9qI3VlWUZiaqzXHl3PxJjwTCnc9o nnfQ== X-Gm-Message-State: AIkVDXJJ8dl5cpUh32XNAZiP0y3Y6mxf7wfIpuvcjBbsuRPGIHn0cQBvuCBChpoBFYodJEiFc+jDtjxq9WDzpA== X-Received: by 10.176.0.169 with SMTP id 38mr34551108uaj.34.1483037279936; Thu, 29 Dec 2016 10:47:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.176 with HTTP; Thu, 29 Dec 2016 10:47:59 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Thu, 29 Dec 2016 13:47:59 -0500 Message-ID: To: Chaim Geretz Content-Type: multipart/alternative; boundary=001a11c169da4265f70544d08645 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Definition of SHA256 and SHA512/256 algorithms in RFC 7616 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 18:48:02 -0000 --001a11c169da4265f70544d08645 Content-Type: text/plain; charset=UTF-8 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 wrote: > 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 > wrote: > >> 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 < >> sophie.bremer@netzkonform.de> 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 : >>> > >>> > 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. >>> >>> > If this is the desired implementation of SHA512/256 then this should >>> be mentioned in the RFC. >>> >>> 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 >>> userhash="793263caabb707a56211940d90411ea4a575adeccb7e360aeb624ed06ece9b0b" >>> 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 >>> >> >> > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > --001a11c169da4265f70544d08645 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chaim,

I do not think that the inten= tion was to truncate any of these hashes.
It seems that the examp= le is incorrect.

Can you please open a new errata = against the RFC?

On Thu, Dec 29, 2016 at 1:20 PM, Chaim Geretz <chaim.geretz@idt.net> wrote:
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. Th= at aligns with the example given in RFC 7616.

FIPS 180-4 introduced the possibility of a different i= mplementation of SHA512/256, but still leaves open the possibility of trunc= ation of the results of an existing algorithm.


On T= hu, Dec 29, 2016 at 1:12 PM, Chaim Geretz <chaim.geretz@idt.net>= wrote:
Sophie,

Thanks for your response

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

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

=
http://www.iana.org/assignments/http-dig-alg/http-dig-alg.= txt=C2=A0does not include any specification information for SHA-51= 2-256 save for a pointer to RFC 7616.=C2=A0
=
Chaim


On Thu, Dec 29, 2016 at 12:43 PM, Sophie Bremer <sophie.bremer@netzkonform.de> wrote:
Hi Chaim,

thank you for pointing this out!
It explains some problems I had myself with the implementation for proxy se= rvers.

> Am 28.12.2016 um 20:19 schrieb Chaim Geretz <chaim.geretz@idt.net>:
>
> Greetings,
>
> I think that RFC 7616 needs to define or point to a document describin= g how the various hash algorithms mentioned in Section 3.2 are to be implem= ented.

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 definiti= on 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.

> If this is the desired implementation of SHA512/256 then this should b= e mentioned in the RFC.

The example is not in sync with the IANA registry and = has to be updated.

> If the intention is to use SHA512/256 as describe= d in FIPS 180.4 then this should be mentioned, and the values changed to us= erhash=3D"793263caabb707a56211940d90411ea4a575adeccb7e360aeb= 624ed06ece9b0b" and response=3D"3798d4131c277846293534c3edc1= 1bd8a5e4cdcbff78b05db9d95eeb1cec68a5"

I will look into your provided values an= d clarify/correct the example.

Once again, thank you for this catch!

Best Regards,
Sophie



_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth<= /a>


--001a11c169da4265f70544d08645-- From nobody Thu Dec 29 12:04:05 2016 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FF8129614 for ; Thu, 29 Dec 2016 11:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.302 X-Spam-Level: X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNsdHMdJ3Y7p for ; Thu, 29 Dec 2016 11:37:13 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2768129488 for ; Thu, 29 Dec 2016 11:37:13 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8E1D9B80132; Thu, 29 Dec 2016 11:37:13 -0800 (PST) To: rifaat.ietf@gmail.com, ahrensdc@gmail.com, sophie.bremer@netzkonform.de, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, ynir.ietf@gmail.com, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161229193713.8E1D9B80132@rfc-editor.org> Date: Thu, 29 Dec 2016 11:37:13 -0800 (PST) Archived-At: X-Mailman-Approved-At: Thu, 29 Dec 2016 12:04:04 -0800 Cc: http-auth@ietf.org, rfc-editor@rfc-editor.org Subject: [http-auth] [Technical Errata Reported] RFC7616 (4897) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 19:37:15 -0000 The following errata report has been submitted for RFC7616, "HTTP Digest Access Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7616&eid=4897 -------------------------------------- Type: Technical Reported by: Chaim Geretz Section: 3.9.2 Original Text ------------- 3.9.2. Example with SHA-512-256, Charset, and Userhash The following example assumes that an access-protected document is being requested from the server via a GET request. The URI for the request is "http://api.example.org/doe.json". Both client and server know the userhash of the username, support the UTF-8 character encoding scheme, and use the SHA-512-256 algorithm. The username for the request is a variation of "Jason Doe", where the 'a' actually is Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"), and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL LETTER O WITH STROKE"), leading to the octet sequence using the UTF-8 encoding scheme: J U+00E4 s U+00F8 n D o e 4A C3A4 73 C3B8 6E 20 44 6F 65 The password is "Secret, or not?". The first time the client requests the document, no Authorization header field is sent, so the server responds with: HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="api@example.org", qop="auth", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", charset=UTF-8, userhash=true Shekh-Yusef, et al. Standards Track [Page 19] RFC 7616 HTTP Digest Access Authentication September 2015 The client can prompt the user for the required credentials and send a new request with following Authorization header field: Authorization: Digest username="488869477bf257147b804c45308cd62ac4e25eb717 b12b298c79e62dcea254ec", realm="api@example.org", uri="/doe.json", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nc=00000001, cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", qop=auth, response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d 6c861229025f607a79dd", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", userhash=true If the client cannot provide a hashed username for any reason, the client can try a request with this Authorization header field: Authorization: Digest username*=UTF-8''J%C3%A4s%C3%B8n%20Doe, realm="api@example.org", uri="/doe.json", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nc=00000001, cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", qop=auth, response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d 6c861229025f607a79dd", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", userhash=false Corrected Text -------------- 3.9.2. Example with SHA-512-256, Charset, and Userhash The following example assumes that an access-protected document is being requested from the server via a GET request. The URI for the request is "http://api.example.org/doe.json". Both client and server know the userhash of the username, support the UTF-8 character encoding scheme, and use the SHA-512-256 algorithm. The username for the request is a variation of "Jason Doe", where the 'a' actually is Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"), and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL LETTER O WITH STROKE"), leading to the octet sequence using the UTF-8 encoding scheme: J U+00E4 s U+00F8 n D o e 4A C3A4 73 C3B8 6E 20 44 6F 65 The password is "Secret, or not?". The first time the client requests the document, no Authorization header field is sent, so the server responds with: HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="api@example.org", qop="auth", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", charset=UTF-8, userhash=true Shekh-Yusef, et al. Standards Track [Page 19] RFC 7616 HTTP Digest Access Authentication September 2015 The client can prompt the user for the required credentials and send a new request with following Authorization header field: Authorization: Digest username="793263caabb707a56211940d90411ea4a575adeccb 7e360aeb624ed06ece9b0b", realm="api@example.org", uri="/doe.json", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nc=00000001, cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", qop=auth, response="3798d4131c277846293534c3edc11bd8a5e4cdcbff78 b05db9d95eeb1cec68a5", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", userhash=true If the client cannot provide a hashed username for any reason, the client can try a request with this Authorization header field: Authorization: Digest username*=UTF-8''J%C3%A4s%C3%B8n%20Doe, realm="api@example.org", uri="/doe.json", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nc=00000001, cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", qop=auth, response="3798d4131c277846293534c3edc11bd8a5e4cdcbff78 b05db9d95eeb1cec68a5", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", userhash=false Notes ----- If the SHA512/256 algorithm first mentioned in Section 3.2 is to be implemented as defined in FIPS 180.4 Section 6.7 the values of username and response need to be corrected. Changes start at page 19 of the RFC. I created this as technical errata since the current values given in the example are for a SHA512/256 algorithm implemented as described in Section 7 of both FIPS 180-3 and FIPS 180-4 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. -------------------------------------- RFC7616 (draft-ietf-httpauth-digest-19) -------------------------------------- Title : HTTP Digest Access Authentication Publication Date : September 2015 Author(s) : R. Shekh-Yusef, Ed., D. Ahrens, S. Bremer Category : PROPOSED STANDARD Source : Hypertext Transfer Protocol Authentication Area : Security Stream : IETF Verifying Party : IESG