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

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Thu, 29 December 2016 18:48 UTC

Return-Path: <rifaat.ietf@gmail.com>
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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietf.org>; Thu, 29 Dec 2016 10:48:00 -0800 (PST)
Received: by mail-ua0-x229.google.com with SMTP id 88so231859189uaq.3 for <http-auth@ietf.org>; 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: <CAP-tQRj=OmFau_ahaXQJbjy4YpYSkuUhCD_JpM-_jamNz5Hm8g@mail.gmail.com>
References: <CAP-tQRitZ6xfFWZA00S3xfnaGaCjOgtaxyO2ZW-DQgDX7+MN1Q@mail.gmail.com> <VI1PR07MB12649529192F4587ECB6CAF3856B0@VI1PR07MB1264.eurprd07.prod.outlook.com> <CAP-tQRjKQOohQ0UyMAFPjZO=SupftpyDjTXuExNq9DKO-ybfyA@mail.gmail.com> <CAP-tQRj=OmFau_ahaXQJbjy4YpYSkuUhCD_JpM-_jamNz5Hm8g@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Thu, 29 Dec 2016 13:47:59 -0500
Message-ID: <CAGL6epKdVOjbrLNYYmy9bqbwSWs=sRrQyotJ_cFWdEDM3zPuag@mail.gmail.com>
To: Chaim Geretz <chaim.geretz@idt.net>
Content-Type: multipart/alternative; boundary="001a11c169da4265f70544d08645"
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/bo1re80BdgTHuZVjH99-wWeVVKk>
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:48:02 -0000

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 <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. 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>:
>>> >
>>> > 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
>
>