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

Chaim Geretz <chaim.geretz@idt.net> Thu, 29 December 2016 18:21 UTC

Return-Path: <chaim.geretz@idt.net>
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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietf.org>; Thu, 29 Dec 2016 10:21:03 -0800 (PST)
Received: by mail-oi0-x230.google.com with SMTP id b126so405021831oia.2 for <http-auth@ietf.org>; 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: <CAP-tQRjKQOohQ0UyMAFPjZO=SupftpyDjTXuExNq9DKO-ybfyA@mail.gmail.com>
References: <CAP-tQRitZ6xfFWZA00S3xfnaGaCjOgtaxyO2ZW-DQgDX7+MN1Q@mail.gmail.com> <VI1PR07MB12649529192F4587ECB6CAF3856B0@VI1PR07MB1264.eurprd07.prod.outlook.com> <CAP-tQRjKQOohQ0UyMAFPjZO=SupftpyDjTXuExNq9DKO-ybfyA@mail.gmail.com>
From: Chaim Geretz <chaim.geretz@idt.net>
Date: Thu, 29 Dec 2016 13:20:41 -0500
Message-ID: <CAP-tQRj=OmFau_ahaXQJbjy4YpYSkuUhCD_JpM-_jamNz5Hm8g@mail.gmail.com>
To: Sophie Bremer <sophie.bremer@netzkonform.de>
Content-Type: multipart/alternative; boundary=001a113d818ad80a110544d025ea
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/rOjUBCMnnul_VzgLICXmjD4e_lA>
Cc: "http-auth@ietf.org" <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 <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Dec 2016 18:21:05 -0000

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 <chaim.geretz@idt.net> 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 <chaim.geretz@idt.net>et>:
>> >
>> > 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
>>
>
>