From nobody Tue Mar 4 02:06:17 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C741A049D; Tue, 4 Mar 2014 02:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1x895NJ4zLQg; Tue, 4 Mar 2014 02:06:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D681D1A049E; Tue, 4 Mar 2014 02:06:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140304100613.23860.66890.idtracker@ietfa.amsl.com> Date: Tue, 04 Mar 2014 02:06:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/FvUacxnPBoCRdKWUSh2KdpulVvw Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 10:06:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : An Encoding Parameter for HTTP Basic Authentication Author : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-enc-03.txt Pages : 11 Date : 2014-03-04 Abstract: The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has led to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character repertoire, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding scheme expectation, using a new authentication scheme parameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-enc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-enc-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-enc-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 4 02:28:42 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F951A04E8 for ; Tue, 4 Mar 2014 02:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 8tLGjE6ApQNA for ; Tue, 4 Mar 2014 02:28:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 14C101A03AC for ; Tue, 4 Mar 2014 02:28:38 -0800 (PST) Received: from [31.133.165.4] ([31.133.165.4]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MT74k-1WkfRP1zIU-00S4Lr for ; Tue, 04 Mar 2014 11:28:33 +0100 Message-ID: <5315AACE.6030703@gmx.de> Date: Tue, 04 Mar 2014 11:28:30 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: http-auth@ietf.org References: <20140304100613.23860.66890.idtracker@ietfa.amsl.com> In-Reply-To: <20140304100613.23860.66890.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:B0ZFbdQyAhTXL4VIFyWKz0igoGWtuaCijovDPKd0NW+Z2x3rmiI zdfrdyGIEC91NP89XPTQMAn5rCu7gs1xQeK59OWhkwcY238BY1GGWNRwD650/z1TA0DX5+W TPrZhUm+MNnwioGw+7nzoUDNlYneSXhna/8w6MdOLiGNaH6DbCMXIEURZKfxvR0lv2QX/bb jwJEtyxAwNhXFt3S5AWDg== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/XZQzuoO2LxPdkdMFu4Rfrj-C7TM Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 10:28:39 -0000 On 2014-03-04 11:06, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. > > Title : An Encoding Parameter for HTTP Basic Authentication > Author : Julian F. Reschke > Filename : draft-ietf-httpauth-basicauth-enc-03.txt > Pages : 11 > Date : 2014-03-04 > ... This updates the Basic encoding extension spec (*) to state that we want NFC: The only allowed value is "UTF-8", to be matched case-insensitively (see [RFC2978], Section 2.3). It indicates that the server expects user name and password to be converted to Unicode Normalization Form C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets using the UTF-8 character encoding scheme ([RFC3629]). See also: We also discussed further normalization during the WG meeting, and my understanding is that the rough consensus in the room was not to attempt this for now. Best regards, Julian (*) Yes, still to be integrated into the Basic auth spec replacement. From nobody Wed Mar 5 06:35:57 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAA31A020A for ; Wed, 5 Mar 2014 06:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ieJBbxsHaZ_Y for ; Wed, 5 Mar 2014 06:35:48 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id D5D301A022A for ; Wed, 5 Mar 2014 06:35:40 -0800 (PST) Received: from mail-ve0-f173.google.com ([209.85.128.173]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUxc2Ob+dgg0xrwhBvMBZlwLvk1M3gZF1@postini.com; Wed, 05 Mar 2014 06:35:37 PST Received: by mail-ve0-f173.google.com with SMTP id oy12so1105836veb.18 for ; Wed, 05 Mar 2014 06:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=cPMb4EPD2WYGbgc1BLB596GO7ONsf0B5JHY1BbtImkk=; b=SJdHBtx3M7jMXT6gBTl5tg77TiCf/cMM3Df1i4fKDKzYoho20R2oU7hmg0jJA7VeA3 TneG4s07mDxEZPxlChvskxBnjH+hsa+aoNX76/KtP/ZPnsKn00LuozfnP9T3bEnrcZyF uVbYeMN8RHdF3kCRn2LYFUmEfO6Fi89N9Qwuc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=cPMb4EPD2WYGbgc1BLB596GO7ONsf0B5JHY1BbtImkk=; b=OkvxOUS+Gko+nsghvBSUWJYluiWtBZcQWGbJQs4XYAwNWMrfD9PA+d6eIa9USp3WEu dXjxaQWOWyrYSJA0OWmGYUP+HFjBW7y5OpJkJ9BCq+NSxp4RtyF8/1B8+CUSODwpwpnv AReHkeXvBEiHUY0q2DDbos51QYhbUv34zzSMXA/4qNUjBftVnnK/bGPzWpUGcnzVy4PG P2sEdbxK9eX87U8qrRVZFoKE22T1UrG+I9XUNXKEjaHuAXoMoVE3FqAgUKfEQD8PLfCy 1s+ESmAwFKIUNfXndeLRa+1CJSBTsliqULCnCn1UbBTRTgMQdVOEVYPb6IPHcV7ne1wf fBQg== X-Gm-Message-State: ALoCoQkrdLC5R7GVwCkgGxLuT/Nkewu88aJ+K8VPJJGYqvD1MaKR75jnWH5upNunOkNt2hsoAF4tqVyiQ5nhPczdZx0Llc+ruD+duobW22CupsvZ4+EWq8D5cC7UIbl31j/P0A7m683gHmvrefB8LkdYAaSmKSHvWA== X-Received: by 10.220.99.72 with SMTP id t8mr349854vcn.10.1394030136801; Wed, 05 Mar 2014 06:35:36 -0800 (PST) X-Received: by 10.220.99.72 with SMTP id t8mr349843vcn.10.1394030136618; Wed, 05 Mar 2014 06:35:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Mar 2014 06:35:16 -0800 (PST) From: Yutaka OIWA Date: Wed, 5 Mar 2014 23:35:16 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/momcK0X6ab909UxUvF8Vv3l9ocU Subject: [http-auth] [Request for Reviews] HTTPAUTHprep X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 14:35:54 -0000 Dear all in HTTPAUTH WG, As I talked in the Monday's WG session, I'd like to have inputs from the HTTPAUTH WG about the string normalization requirements and applicability for HTTP authentication. http://tools.ietf.org/html/draft-oiwa-precis-httpauthprep-00 is my current draft, which are to be updated sooner after discussion with PRECIS WG people planned within this month. In the draft, Section 2 contains PRECIS-specific rule definition for the string preparation (including Unicode normalization and beyond). I'd like to have review comments especially for all OTHER sections, in particular for Section 3 (Applicability Notes). # Of course, reviews for Section 2 are also very welcome if possible. Thank you in advance for your cooperation. -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Wed Mar 5 06:48:34 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE511A06C8 for ; Wed, 5 Mar 2014 06:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 m9TqzQ0C9zFW for ; Wed, 5 Mar 2014 06:48:29 -0800 (PST) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with ESMTP id 608D01A065E for ; Wed, 5 Mar 2014 06:48:28 -0800 (PST) Received: from mail-vc0-f169.google.com ([209.85.220.169]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKUxc5OEX0GKmeJx8cNWpKwQNtaqIbMcsq@postini.com; Wed, 05 Mar 2014 06:48:25 PST Received: by mail-vc0-f169.google.com with SMTP id hq11so1144386vcb.0 for ; Wed, 05 Mar 2014 06:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=/pqAPLWTNiGM1Z8WVdSiJ7vobA1HpxrkFqa+Jhx0rpc=; b=DueaFJEjK66Vlz0s0VXZEhe35DEUOg1V6dOOSKO7RBCPVdfmPcL6M2qMGfXu4KvtWn ycjnRWR1bDWjjnU2TT7IvWmR3lz/k7sUIn++2QAcO84dij+zvOxBYJHYhi3DgbMzJ7Bs diA0BvcBOc+5tEz3Qk9bJuDaRQ0vfZ5Oa5YQ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=/pqAPLWTNiGM1Z8WVdSiJ7vobA1HpxrkFqa+Jhx0rpc=; b=fgetg62hQl8ZrDAsKj2Z/YSyzI1tt7oqh8VeeV6dBqbeDyaWedG1H2fBjyxNITRsru veUxStIzhivVYBqv/ityUDKQv8tavFQNlf3zNLEk0W0VbIUDgsBiUEHhqb7gDYpl/Yvn MtokCHb403scBNafB11kbNtOdWNMkHG58QE4/ncfBYE7TNF8b8vKPb11WSgexVWxeJ4z +zNauwMS4E7ZH9qJSdX1SVnkrJMseNHuUDbI295TtAbx+LP8QIJZi6Jk7BWvUwChcQk3 IOtLj9znzdE1LPb8hR1wrSvo2y7XtfTFuhy0xRZgg/sLSSATlw2++9i6tDb+3CSU+3Zp QiYA== X-Gm-Message-State: ALoCoQknaa0nplDn1iRD/02Ov+WbLBODGNV/sANDHwFBM3PV91jVW7Y+BxHWrPcHyc4B2PFHvgVgnEfYBdsotPUL6J0aE/o6xbhG0stdYvKstwfSXySSixZFsLhHDo2Y0xakiBDRwKXtmsuh3lg3WKHe+gsFGT0bTA== X-Received: by 10.220.88.204 with SMTP id b12mr336103vcm.3.1394030904432; Wed, 05 Mar 2014 06:48:24 -0800 (PST) X-Received: by 10.220.88.204 with SMTP id b12mr336092vcm.3.1394030904332; Wed, 05 Mar 2014 06:48:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Mar 2014 06:48:04 -0800 (PST) From: Yutaka OIWA Date: Wed, 5 Mar 2014 23:48:04 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/0CuyS6iuN-bC_TZVVnv-H4WjLM8 Subject: [http-auth] [Request for considerations] promote draft-oiwa-httpauth-mutual-algo to WG document X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 14:48:31 -0000 Dear all, Having had a short talk with WG Chairs on Monday, I'd like to request a companion draft for my Mutual auth proposal to be promoted for WG document. To implement my proposal, the content of this companion document (or something equivalent) is necessary. I have been considered between two options for handling of this document: to merge it with the main draft, or to keep it separate. What I'm requesting now is the latter way. The pros of keeping document separate is having a good cryptography agility. It can handle all possible cryptographic primitives in the class of "augmented PAKEs" as equally, and may promote a good competitions between such cryptographic primitives as TLS did for symmetric ciphers. The cons for doing that is that the total length of the documents will become slightly longer, and the understanding of the main draft slightly harder. The pros and cons of merging the two documents will be the opposite: it makes the total documents smaller, but it may gives a unintended feeling of that other augmented PAKE algorithms are very optional and non-default in future. If you have some opinions for/against my preference, please let us know for considerations. If many of you think that merging is better, I will consider it seriously. Chairs, please let me know anything we should do, further than sending this mail for the mailing list at this moment. -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Wed Mar 5 08:47:27 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A184A1A071A for ; Wed, 5 Mar 2014 08:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Ab6TEEyObxkZ for ; Wed, 5 Mar 2014 08:47:23 -0800 (PST) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9D11A0746 for ; Wed, 5 Mar 2014 08:47:20 -0800 (PST) Received: from mail-ve0-f171.google.com ([209.85.128.171]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUxdVFAo5Ap0V9CVPkoSAO9kJlCoaL+50@postini.com; Wed, 05 Mar 2014 08:47:17 PST Received: by mail-ve0-f171.google.com with SMTP id cz12so1292015veb.2 for ; Wed, 05 Mar 2014 08:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=n2VAQ2j1c6BWxXeBxmSzVx3hH6JPkAS72Yj5P+tzJyM=; b=OoS75Q8vLtbrm+EmP+vvN0TIQ07i+HHRUbAC6d4dYtJU6Z4qs9zxxaj27Ioli5fXGQ F5iTVasn3HzUbSgxU0MtHS78fVBBCDHz9JZpfffg9Tin55iRbcm7+9WMztz9ic+JbZ5x 8qh4XmN47ysCO2RWIWvf7vx5pXPyVCH2FpZls= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=n2VAQ2j1c6BWxXeBxmSzVx3hH6JPkAS72Yj5P+tzJyM=; b=jB0Lt5GFugZudpww2bFZZSkGn1U0zNAEUeQY2B4LNcQE5CITKXegGec52fayzLV2oC /+moY+IJH/+pyifsew/qsXf6HQOsp9ECI5XJJYoSaVxjnzJKg5z56fG3JFpJbCMyXAl7 SYAuRdSMROyX+4kNHDVFx52kJvL4TJQulGjpnZGoBwhhW+BLDcG5p1VDac3HXkFqy7XW pdhhDmShmtfCPX9GeY8VlRvlD6v1JqPN9wb4ju3Y6f4KMw46vSLtr+qgtcUAn/bw5QyR q/XIyF15t+cDzLK9j+ptbT1UjPGWoI7rAqwFWS5YwlkB7qALCg6Ni7LZQOMIMqcxBBBc z6TA== X-Gm-Message-State: ALoCoQlYiL15rupBK7p5ZSOPLFdN0HB3H10YGNSK4jFfLhBHdEgVdB85AUk6Yr+HtUPepyW9HJwRODmi9/bBK1REsdAsTiF9mf/nVhJgMNd966pdQn66BYpRz+LFqzOpbEfPXuw8xCNoSjGXPMLf7MHSAyF0OzCwXg== X-Received: by 10.58.161.227 with SMTP id xv3mr888843veb.31.1394038036205; Wed, 05 Mar 2014 08:47:16 -0800 (PST) X-Received: by 10.58.161.227 with SMTP id xv3mr888839veb.31.1394038036105; Wed, 05 Mar 2014 08:47:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Mar 2014 08:46:56 -0800 (PST) From: Yutaka OIWA Date: Thu, 6 Mar 2014 01:46:56 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/mD6uWjEIk3DtuHx6PLH5rdXfVJY Subject: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:47:25 -0000 Following the discussion in the HTTPAUTH WG sessions in several previous meeting, I believe it is a good thing to introduce a password hardening into the current MutualAuth draft. I'd like to incorporate the following changes to the next revision of the WG document. # I've talked with chairs Monday about how to make a # significant changes to the document in WG status, # and this is how we're suggested to try. If you think we should do something different, or if you have a suggestion for the open issues described below, please let me know. I really want to have suggestions from cryptography people for some security parameters. I'll work on the revisions within a few weeks. The following is the proposed text for the update: In Section 11.2 (Default Functions for Algorithms), ---OLD--- pi = INT(H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) | VS(ph(password)))). --- will be replaced with ---NEW--- pi = INT(PBKDF2(HMAC-H, ph(password), VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username), 2048, dkLen)) where o HMAC-H be the HMAC function [RFC2104] composed from the hash function H, and o dkLen shall be the length of hash H, counted in octets. --- The open issues for the above change are: * Which function, possibly other than PBKDF2, will be the best choice for the hardened password hash function? I currently chose PBKDF2 just because there is an RFC. * What number of iterations are to be used? Fixing it to 2048 makes sense? Or it should be a security parameter? * What is the best value for dkLen? It is an output length of the hardened password hash in octets. Hereafter assume SHA-256 hash and 2048-bit DL key exchange are used. The above definition lead to the value 256/8 = 32. It is easy to make it larger, up to 1792/8 = 224 (1792 = 2048 - 256). The cryptographically best values are either 2046/8, or more precisely some irrational number 2046.99999..../8 (*), but to achieve it, we need to modify/update PBKDF2 itself. (*) 2046.99999... is log_2 r, where r is a number of mathmatically possible elements (size of the generated group) for the passwords-equivalent. Thanks in advance. -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Wed Mar 5 09:31:03 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC761A01E1 for ; Wed, 5 Mar 2014 09:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 3y5xUtz8zFZN for ; Wed, 5 Mar 2014 09:31:00 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id F10051A01A7 for ; Wed, 5 Mar 2014 09:30:59 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s25HUptA012525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Mar 2014 17:30:52 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s25HUn38004174; Wed, 5 Mar 2014 17:30:51 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.175.34.17] (dhcp-uk-twvpn-2-vpnpool-10-175-53-184.vpn.oracle.com [10.175.53.184]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built Jan 22 2014)) with ESMTPA id <0N1Z00I0M4NA6500@gotmail.us.oracle.com>; Wed, 05 Mar 2014 09:30:49 -0800 (PST) Date: Wed, 05 Mar 2014 17:30:44 +0000 From: Chris Newman To: Yutaka OIWA , http-auth@ietf.org Message-id: <489C9E2B71B3170ADF31FB60@96B2F16665FF96BAE59E9B90> In-reply-to: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/7X9lgN02lkG9aH9mXnlbgb6ksVs Subject: Re: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:31:01 -0000 --On March 6, 2014 1:46:56 +0900 Yutaka OIWA wrote: > Following the discussion in the HTTPAUTH WG sessions in > several previous meeting, > I believe it is a good thing to introduce a password hardening > into the current MutualAuth draft. > I'd like to incorporate the following changes to the > next revision of the WG document. ># I've talked with chairs Monday about how to make a ># significant changes to the document in WG status, ># and this is how we're suggested to try. > > If you think we should do something different, > or if you have a suggestion for the open issues > described below, please let me know. > I really want to have suggestions from > cryptography people for some security parameters. > > I'll work on the revisions within a few weeks. > > The following is the proposed text for the update: > > In Section 11.2 (Default Functions for Algorithms), > > ---OLD--- > pi = INT(H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) > | VS(ph(password)))). > --- > will be replaced with > ---NEW--- > pi = INT(PBKDF2(HMAC-H, > ph(password), > VS(algorithm) | VS(auth-domain) | VS(realm) | > VS(username), 2048, dkLen)) > > where > > o HMAC-H be the HMAC function [RFC2104] composed from the hash > function H, and > o dkLen shall be the length of hash H, counted in octets. > --- > > The open issues for the above change are: > > * Which function, possibly other than PBKDF2, will be the best > choice for the hardened password hash function? > I currently chose PBKDF2 just because there is an RFC. That's also what SCRAM (RFC 5802) choose and that change was recommended to the SCRAM editors by security folks as it was done in a security WG. So I have reason to believe PBKDF2 is the right choice for this purpose until I hear otherwise from the security community. > * What number of iterations are to be used? SCRAM used 4096 as minimum iteration count several years ago. I suspect it should be higher now. > Fixing it to 2048 makes sense? No, that can't adapt to advancements in computing power. > Or it should be a security parameter? That's what SCRAM did. > * What is the best value for dkLen? > It is an output length of the hardened password hash in octets. Shouldn't it be the size of the base hash function output? > Hereafter assume SHA-256 hash and 2048-bit DL key exchange are used. > The above definition lead to the value 256/8 = 32. > It is easy to make it larger, up to 1792/8 = 224 (1792 = 2048 - 256). > The cryptographically best values are either 2046/8, or > more precisely some irrational number 2046.99999..../8 (*), but > to achieve it, we need to modify/update PBKDF2 itself. Please do not modify PBKDF2. Security primitives should be reused as-is for their primary purpose unless there's a really really good reason to develop something new and start the security analysis all over again. The reason has to be good enough to attract attention of security researchers. - Chris From nobody Wed Mar 5 09:54:28 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A09E1A045B for ; Wed, 5 Mar 2014 09:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 0ztFMdLhmc91 for ; Wed, 5 Mar 2014 09:54:24 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4048E1A00BB for ; Wed, 5 Mar 2014 09:54:24 -0800 (PST) Received: from mail-vc0-f174.google.com ([209.85.220.174]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUxdkzMgMugW1B+jPHXFfJWjqRiISRo6Q@postini.com; Wed, 05 Mar 2014 09:54:21 PST Received: by mail-vc0-f174.google.com with SMTP id im17so1392177vcb.33 for ; Wed, 05 Mar 2014 09:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fBKhWo8uA6dlh12QTMuyzcwOP3XxG1rwt3PSIR7shxU=; b=ALtSswq+4bE/IbMtnPqzJ7GWRvFPvKkm7rYLymrfUqlj6ChJdb7KzWdPyri+zsEZuC vQyNY7uYYQPygKIiQeOrqHdWnQcGkBKQ5vvhFPJnbtyUl2BkVuVuBziZk+hQSFTtki6E lHj+1bZ08g3znMwsG9t1wbpPyuzDBtaU1BL9g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fBKhWo8uA6dlh12QTMuyzcwOP3XxG1rwt3PSIR7shxU=; b=V4tslAoW0436c2MI8nc1nLngPYj3PfjttIcfFxflrpq5eTNhUYSBQPaVWg2IFPGU5R qkBLjteyCmSUDcd4q9qphnS7KSV2tPHognTm8FJLuKwLDu6YAWkfJoOBPngm2zkpwEd6 i3BObaWrs2kmgjexpbW0npihAuQDk6sj8LmU/S7X5OX2Uyjd2mQIhNSb559Xkrcoewyc s0d9HeNyY12YmIRYkgrAfFa68Kqg/WRtHW9aFTV3beYfuNaUxIhdlhKI9xpViVmoJoDw TykJpRkX4Mz+gmD6b9rX5n4Z0050OKIgibEOj/f3z6qtwUvI3ytAv8FyXupuH+grPYX9 tprA== X-Gm-Message-State: ALoCoQml/8sQ6xSjq22K0KjRIT8QjcCYiwg8ZoVwOt7cmiy7KoY6mKdk7Ien1RVZD9tEuZlKai6+KaUf22Xl2x6T3Orjv4oorSC2TmMxmx0EMBixVGOthjmDnj86dqEleO9DfCD13WS20m+PlH6FwPO8pTY5gNI9EQ== X-Received: by 10.58.201.5 with SMTP id jw5mr1192987vec.6.1394042060138; Wed, 05 Mar 2014 09:54:20 -0800 (PST) X-Received: by 10.58.201.5 with SMTP id jw5mr1192976vec.6.1394042059983; Wed, 05 Mar 2014 09:54:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Mar 2014 09:53:59 -0800 (PST) In-Reply-To: <489C9E2B71B3170ADF31FB60@96B2F16665FF96BAE59E9B90> References: <489C9E2B71B3170ADF31FB60@96B2F16665FF96BAE59E9B90> From: Yutaka OIWA Date: Thu, 6 Mar 2014 02:53:59 +0900 Message-ID: To: Chris Newman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/lAR63VuO6XxLtuUFzI99Ue8pZ7U Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:54:26 -0000 Chris, thank you very much. Iteration counts and function choices: Really valuable input for the iteration count, thanks. I will raise that number and make it a security parameter in some way. Additional question: If possible, I want to have it fixed with each "ciphersuites" we're defining, expecting that if we need to raise that iteration number, we also need to strengthen the hash itself. Do you have some thoughts about relation of those? Is it difficult to forecast these relations? # While writing this, I feel it's difficult... Output length of PBKDF2: Thank you very much, too. It's also very valuable information for me. I completely agree with your view on the security primitives modification. I actually want to make sure that such modification is not required (to make sure there is not "a really really good reason") around my use case. # I am putting the output to a field of large prime size (2^2046.99999...), # so it's a bit strange use case compared to the usual use cases of PBKDF2. Thank you again for your comments! 2014-03-06 2:30 GMT+09:00 Chris Newman : > --On March 6, 2014 1:46:56 +0900 Yutaka OIWA wrote: >> >> Following the discussion in the HTTPAUTH WG sessions in >> several previous meeting, >> I believe it is a good thing to introduce a password hardening >> into the current MutualAuth draft. >> I'd like to incorporate the following changes to the >> next revision of the WG document. >> # I've talked with chairs Monday about how to make a >> # significant changes to the document in WG status, >> # and this is how we're suggested to try. >> >> If you think we should do something different, >> or if you have a suggestion for the open issues >> described below, please let me know. >> I really want to have suggestions from >> cryptography people for some security parameters. >> >> I'll work on the revisions within a few weeks. >> >> The following is the proposed text for the update: >> >> In Section 11.2 (Default Functions for Algorithms), >> >> ---OLD--- >> pi = INT(H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) >> | VS(ph(password)))). >> --- >> will be replaced with >> ---NEW--- >> pi = INT(PBKDF2(HMAC-H, >> ph(password), >> VS(algorithm) | VS(auth-domain) | VS(realm) | >> VS(username), 2048, dkLen)) >> >> where >> >> o HMAC-H be the HMAC function [RFC2104] composed from the hash >> function H, and >> o dkLen shall be the length of hash H, counted in octets. >> --- >> >> The open issues for the above change are: >> >> * Which function, possibly other than PBKDF2, will be the best >> choice for the hardened password hash function? >> I currently chose PBKDF2 just because there is an RFC. > > > That's also what SCRAM (RFC 5802) choose and that change was recommended to > the SCRAM editors by security folks as it was done in a security WG. So I > have reason to believe PBKDF2 is the right choice for this purpose until I > hear otherwise from the security community. > > >> * What number of iterations are to be used? > > > SCRAM used 4096 as minimum iteration count several years ago. I suspect it > should be higher now. > > >> Fixing it to 2048 makes sense? > > > No, that can't adapt to advancements in computing power. > > >> Or it should be a security parameter? > > > That's what SCRAM did. > > >> * What is the best value for dkLen? >> It is an output length of the hardened password hash in octets. > > > Shouldn't it be the size of the base hash function output? > > >> Hereafter assume SHA-256 hash and 2048-bit DL key exchange are used. >> The above definition lead to the value 256/8 = 32. >> It is easy to make it larger, up to 1792/8 = 224 (1792 = 2048 - 256). >> The cryptographically best values are either 2046/8, or >> more precisely some irrational number 2046.99999..../8 (*), but >> to achieve it, we need to modify/update PBKDF2 itself. > > > Please do not modify PBKDF2. Security primitives should be reused as-is for > their primary purpose unless there's a really really good reason to develop > something new and start the security analysis all over again. The reason has > to be good enough to attract attention of security researchers. > > - Chris > -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Wed Mar 5 09:57:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19271A064D for ; Wed, 5 Mar 2014 09:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 yOQSF36HFXd9 for ; Wed, 5 Mar 2014 09:57:20 -0800 (PST) Received: from sentinelchicken.org (laim.sentinelchicken.org [96.126.98.9]) by ietfa.amsl.com (Postfix) with SMTP id 128981A013A for ; Wed, 5 Mar 2014 09:57:20 -0800 (PST) Received: (qmail 27935 invoked from network); 5 Mar 2014 17:57:16 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by lelantos.sentinelchicken.org with SMTP; 5 Mar 2014 17:57:16 -0000 Received: (qmail 20476 invoked from network); 5 Mar 2014 18:01:00 -0000 Received: from unknown (HELO shannon.sentinelchicken.org) (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 5 Mar 2014 18:01:00 -0000 Received: (nullmailer pid 19186 invoked by uid 1000); Wed, 05 Mar 2014 17:57:06 -0000 Date: Wed, 5 Mar 2014 09:57:06 -0800 From: Tim To: Yutaka OIWA Message-ID: <20140305175706.GV3070@sentinelchicken.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/8Zr5SQjcuREtvcjj1yS5JETftoA Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:57:21 -0000 > * Which function, possibly other than PBKDF2, will be the best > choice for the hardened password hash function? > I currently chose PBKDF2 just because there is an RFC. I'm currently fond of scrypt, since it can be made memory-hard in addition to computationally hard. There was an attempt to standardize it, but it appears the draft has expired: https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-01 I believe scrypt is used as the work-factor function in several crypto-currencies, so it certainly does receive some scrutiny, security-wise. I'm not sure how difficult it would be to integrate this into your protocol... tim From nobody Wed Mar 5 10:30:55 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFC81A01DD for ; Wed, 5 Mar 2014 10:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 qHwKpWET8ibN for ; Wed, 5 Mar 2014 10:30:51 -0800 (PST) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26E1A0128 for ; Wed, 5 Mar 2014 10:30:51 -0800 (PST) Received: from mail-ve0-f177.google.com ([209.85.128.177]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUxdtV62lorp7g/FlZ0ATmMASaO4FkwEN@postini.com; Wed, 05 Mar 2014 10:30:47 PST Received: by mail-ve0-f177.google.com with SMTP id sa20so1436488veb.36 for ; Wed, 05 Mar 2014 10:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RhoTWbx5b+8Vsml70kOOxnFNMVRyLv3hTGKvOpOX9Zc=; b=DpATLrWkGka/OCCatX7fEfnek7Es7Kr+DqVMYkEMzPM9/9UJs0N3Y32NIP89ENUoYX me1SBO6lGN+L7G7Q4WtbyknIrOWthLDiwNKEkUyJWoLCVbt/MDZxXwsXnQN69Zq0sDQ2 A2ouhNiUQlRfm7VG/yK/NlGB8NqvfD3X7lsg4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RhoTWbx5b+8Vsml70kOOxnFNMVRyLv3hTGKvOpOX9Zc=; b=gNmZLAB0ttbJOo9sBhL/3raLoAg1YzUET7CsRBI6tDXIxO4CkNFOfZoKFOO7NXoijA i1HwUD2avVElpclwMVjc5qmkhv4ST+m6UhL0f9tyJDZMc5l/xljiiXtXmMKdaPZi6G2F O77p4aezQKTnGRtaZd7R7EDBTa8pPN7Frp5b3lQFVWriZ8E57ULD8vuQKfWsgOcuVG+c DX6IZb+YhRklFxQBo/0T8FPa05unMTh49xTTRqYP3nvVHk0IwSBnrWNluVJGb0Casa69 ErAVHsOlikgYvw5oDW6mRkrJHwRnnIXagLtVYJwhG3aehuoPoYPXRQTWkuNOYigAUSPh UGJw== X-Gm-Message-State: ALoCoQkhn53dHWwG4IfITwmoMvEGFRDBGS5SvzyCbWuOVMC0cW0bTjz5cHlXX8CNhpKUPDEVQ3dRKc/CSo4ylJ2+0DzQ1TN8NnwHlnM5aMJaQ8oKj5DjepFwBC1y50SwYgvSMbgas65CR8qkPRt1Eks9O5zcm/MGJA== X-Received: by 10.220.99.72 with SMTP id t8mr1154683vcn.10.1394044247081; Wed, 05 Mar 2014 10:30:47 -0800 (PST) X-Received: by 10.220.99.72 with SMTP id t8mr1154670vcn.10.1394044246942; Wed, 05 Mar 2014 10:30:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Mar 2014 10:30:26 -0800 (PST) In-Reply-To: References: From: Yutaka OIWA Date: Thu, 6 Mar 2014 03:30:26 +0900 Message-ID: To: Yoav Nir , Watson Ladd Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/vD8ObfLJgDUGAIiGpS8Mk4A0NKU Cc: "http-auth@ietf.org" , cfrg@irtf.org Subject: Re: [http-auth] Fwd: [Cfrg] Another PAKE question X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:30:53 -0000 Watson, Sorry, I completely missed this mail in the pile of unread mails. # Thanks Yoav, your comment in WG reminds me and help finding out of this. AFAIK, putting the transaction history into the calculation is already embedded as the values t_1 and t_2 described in the algorithm in , Sections 2.2 and 2.3. Isn't this t_1 and t_2 (put into the calculation of z) suffice for the purpose? My understanding is that the functionality what Watson mentioned is a fundamental requirements for all PAKE primitives, and is already embedded in the specification of such primitives' layer. If this assumption is not, or if we need to protect more values than the values appear in the cryptographic primitives, I agree that the functionality should be again implemented in the layer of the "HTTP Mutual authentication". In such case I will do it with our cryptographer colleagues. Sorry for the very late reply, but I'm very happy if you can help me better understanding of this issue. 2014-01-10 0:24 GMT+09:00 Yoav Nir : > Hi. > > CFRG has recently had some discussion about PAKEs in general. I have asked > them to take a look at MutualAuth. This is one of the replies that we got. > > Yoav > > Begin forwarded message: > > From: Watson Ladd > Subject: Re: [Cfrg] Another PAKE question > Date: January 9, 2014 4:57:19 PM GMT+02:00 > To: Yoav Nir > > Why is this protocol secure? > I would recommend taking the z, and computing a hash of z and the > transcript of the protocol. In > this way under the ROM, the computed value doesn't reveal information. > It ensures that any > manipulation of the messages leads to different z values. > > I'll try to think of ways to make a proof given that change. > Sincerely, > Watson Ladd > > > On Wed, Jan 8, 2014 at 10:09 PM, Yoav Nir wrote: > > Hi > > I almost feel like I'm asking for trouble after the roast that Dan went > through, but some on this list might want to consider another PAKE going > through an IETF working group. > > HTTP-Auth is making experimental authentication mechanisms for the HTTP > layer. One of those is a PAKE. If people here on the CFRG list would like to > comment on it, that would be great. We can have some discussion here, but > ultimately, comments criticisms and suggestions should go to the HTTP-auth > list (details below). > > The draft in question is called "Mutual Authentication Protocol for HTTP". > > Link: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01 > > Yoav > co-chair of HTTP-Auth > > Mailing list details: > * http-auth List Information: > https://www.ietf.org/mailman/listinfo/http-auth > * http-auth List Archives: > http://www.ietf.org/mail-archive/web/http-auth/current/maillist.html > * http-auth Posting Address (requires registration): http-auth@ietf.org > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > > > Email secured by Check Point > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Wed Mar 5 10:47:13 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9E71A011E for ; Wed, 5 Mar 2014 10:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 k1d7eHvA5O5L for ; Wed, 5 Mar 2014 10:47:09 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 662B41A025D for ; Wed, 5 Mar 2014 10:47:05 -0800 (PST) Received: from mail-vc0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUxdxJfl7gFO+Z3DT6HsaHm1IYTHuZwV8@postini.com; Wed, 05 Mar 2014 10:47:02 PST Received: by mail-vc0-f172.google.com with SMTP id lf12so1460128vcb.17 for ; Wed, 05 Mar 2014 10:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=98JKnSmBvOmBlwpR9yChEsgCLWYIN1x7HZzzxiJaQzU=; b=ZGDMDoed27kdkW2sXh/OahdAdWIXU/TyT0H8SiJ2tVn2qhb6tAz5i/BbT5m9f6iJWk WxvsG3kdXZX9UMRX/Ys7x31BCWygL/nm0jt48qBseV5xRuiqkJ7S8Hn0r0FgnXVFT3bE fFjqmTI/3rrKZiO2tPsQn3zvZxkA4uAKqr1Ac= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=98JKnSmBvOmBlwpR9yChEsgCLWYIN1x7HZzzxiJaQzU=; b=Y9THImffG70j+W7/iPPHPEM4GhKkfjnaazASxi4FmNg0BFAARnJ5ZUNzaJigtnsFBJ AzQjxGU3agkuyxpR7TgXpljKGpM5j5e4mkNHAehw+fQT6r2l5N9uHBR/9YsmwGyKgkA1 gf+C+iZ6jZaalV9Pt8q5Y2TzQWeFTS2OD+frcdd6J+CAVnRqJHWqq1hp/cSBL2KGbxy7 JwkN1sOUbd6J+xRmgf5fYYAltjPOZ3bBsYbGu+EeQeqWHNDi4am8tVjAzC4LyFG4q3o8 AvvS849HxdNgDphqBehLOV2KjB+MXkGwq+woieJd8Xz+ttOmSbCipMUeYknqGzHhJMTz 7h3A== X-Gm-Message-State: ALoCoQlRKv6O2id9CqgnatN/42yd5UkThqqNAjyG4EeS0y9Uas2I/aIzZc8a9xARI4819hvO4NLxT2ZuVSqLU1zmjyEWUCngK16Phmyuvs7EKAkmyECong6UbC4+T6UaXguRWT7Gqb8F3Y1nkEPyKP0aEjjvos/CLQ== X-Received: by 10.58.170.69 with SMTP id ak5mr1394037vec.28.1394045221441; Wed, 05 Mar 2014 10:47:01 -0800 (PST) X-Received: by 10.58.170.69 with SMTP id ak5mr1394032vec.28.1394045221323; Wed, 05 Mar 2014 10:47:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Mar 2014 10:46:41 -0800 (PST) In-Reply-To: <7D278CFE-3EF1-4274-A1B8-3F0E8A0B74CE@checkpoint.com> References: <53bf7ac99fb17e4f9333d42fea20505c.squirrel@www.trepanning.net> <7D278CFE-3EF1-4274-A1B8-3F0E8A0B74CE@checkpoint.com> From: Yutaka OIWA Date: Thu, 6 Mar 2014 03:46:41 +0900 Message-ID: To: Yoav Nir , Dan Harkins Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/zRUB816lt1GliKnVkiyIfyRDjts Cc: "http-auth@ietf.org" Subject: Re: [http-auth] [Cfrg] Another PAKE question X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:47:11 -0000 I'm deeply sorry Dan and Yoav for my missed reading of your reply. I understood the feeling difficulty on the Figure 5 by its complexity. I will make a clearer description for those states, either on mailing list or in the final draft. Actually, there is a few conditional parameters in this state machine, and the Figure 5 is something like a "value-expanded" version of that. For example, the left part of the figure (states 2, 3, 4) is corresponding to the "first" HTTP request for a given user request, and is corresponding one-to-one with the states in the right part (7, 8, 9), which are for "non-first" requests. Only the difference is whether normal responses are valid (2,3,4) or invalid (7,8,9). So, if we introduce a one-bit flag about this, we can reduce the number of states to the half. My intention for this "expanded" description was that for security-novice implementers, following exactly the specified behavior is much easier than following the compacted directions where important decisions are implied in the English texts. However, I also understand the deep concern from the security community about its complexity at the same time. Thank you very much for making attention on this and I will find some way of description to achieve well-understoodness for both communities. 2014-01-10 3:57 GMT+09:00 Yoav Nir : > Another reply > > On Jan 9, 2014, at 9:25 AM, Dan Harkins wrote: > > [snipped a question about where the algorithm draft was] > >> >> Also, figure 5 seems almost like a joke. Is this protocol _really_ >> that complicated? A security protocol that complicated seems like >> a recipe for disaster. >> >> regards, >> >> Dan. > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Wed Mar 5 11:14:35 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377B91A0162 for ; Wed, 5 Mar 2014 11:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 PbbF_QUTqHWT for ; Wed, 5 Mar 2014 11:14:29 -0800 (PST) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 63C221A021A for ; Wed, 5 Mar 2014 11:14:25 -0800 (PST) Received: from mail-ve0-f174.google.com ([209.85.128.174]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUxd3jYwTRUAuaR+/HqwAhJNk8+VEHjyU@postini.com; Wed, 05 Mar 2014 11:14:22 PST Received: by mail-ve0-f174.google.com with SMTP id oz11so1500187veb.19 for ; Wed, 05 Mar 2014 11:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=V4F74+TOF5Gx5MnwsXRVgtPW/RjF9oLzyNGjJLyfeZ0=; b=gaXhitEQN5cZFHQvH5n2ds8aqxO6w9sLz3od2xnT9i6uQ4vP6QyA4/gs09VXOwQJII mtdP+AFfpywtg3vx8K00EycVFhUf0Mf+UeLXUutI/fH5n8vLghexwyiSyXeEGREIcvNi E3KzawBaxIgZBBaVJ1laxv+Sj5PujrD2qcIPU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V4F74+TOF5Gx5MnwsXRVgtPW/RjF9oLzyNGjJLyfeZ0=; b=LK/YRLNqitHiMwXXIG9//tH6E+AJ7EzMsPAgqe6wbdnAYOPYKi4I5ZkeJlA1C4t2sE yz2iu7dfG+itk+omI7uq6pnJNbUQVamTp22QNrT61iydUhM+6hHwB7U/eoWOFZGz/dXa uPyY3PBvwzN/AYYlZfn+xCt2WncDKAzHMCMTXqBXACliEpd+LhpfAFgQvsZraZYKBRfF KDTGKGZ/anO/K0Gb8k79pC/+mxNgyauu/PIP9er15CPCWK3yo3aYdk4OuIlq9nI7l2Ok /s9t/0Tceiqa8IuUZRkJXXlXe00QjZY9+gOnITpmO+WendoZTwahg7uruA5KC+Ot/uia Qr1w== X-Gm-Message-State: ALoCoQnzh2Oql3cTeEOwK9RxqWycWy3bGt9SL1jrvLB3ojxJTNQerYzM4OFg563P1cvGU3NHT0sN+x2GYXpzgCqcPs6f1W7K23YwcFzkfR24OhKTHT+xCgvJAO8PisIK5koIS8vt/6JWwGmifCt67leW5/7EoQzN4A== X-Received: by 10.52.247.231 with SMTP id yh7mr1872036vdc.34.1394046861213; Wed, 05 Mar 2014 11:14:21 -0800 (PST) X-Received: by 10.52.247.231 with SMTP id yh7mr1872029vdc.34.1394046861109; Wed, 05 Mar 2014 11:14:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Mar 2014 11:14:01 -0800 (PST) In-Reply-To: <20140305175706.GV3070@sentinelchicken.org> References: <20140305175706.GV3070@sentinelchicken.org> From: Yutaka OIWA Date: Thu, 6 Mar 2014 04:14:01 +0900 Message-ID: To: Tim Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/iLZXZNUVoO4qWmChHIRcIP3WJ0U Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 19:14:32 -0000 Dear Tim, Thank you very much for the information. It's very interesting. I'll read the paper and how it can be used for benefit on our proposal... # long-while expiring draft is an issue, indeed... # to use it, someone should take care of that. 2014-03-06 2:57 GMT+09:00 Tim : > >> * Which function, possibly other than PBKDF2, will be the best >> choice for the hardened password hash function? >> I currently chose PBKDF2 just because there is an RFC. > > I'm currently fond of scrypt, since it can be made memory-hard in > addition to computationally hard. There was an attempt to standardize > it, but it appears the draft has expired: > https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-01 > > I believe scrypt is used as the work-factor function in several > crypto-currencies, so it certainly does receive some scrutiny, > security-wise. I'm not sure how difficult it would be to integrate > this into your protocol... > > tim -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Thu Mar 6 20:57:13 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455D31A00B2 for ; Thu, 6 Mar 2014 20:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 Jym4yoeH6Cpf for ; Thu, 6 Mar 2014 20:57:07 -0800 (PST) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id F3B901A00A5 for ; Thu, 6 Mar 2014 20:57:06 -0800 (PST) Received: from mail-vc0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKUxlRnqHU0h9t316LPjmtvbGOwJmGkKsW@postini.com; Thu, 06 Mar 2014 20:57:03 PST Received: by mail-vc0-f179.google.com with SMTP id ij19so3178678vcb.24 for ; Thu, 06 Mar 2014 20:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EKERpcFfZXimDS05T4oVCB7VFh85kPVKJgOKl3jZgK4=; b=ZY5KoX0mplbgkqWMcTZ8k5skeswaJE0HAOnPuy2J4IOFm1iS5b4mlwv8Kfk+2b3e0O 5ZmCMbwNkumxToHXXphkBX+SGAIXpnDrq5K+nYkXio6r/3geFsue8WRVifbGjBfwJanv nTgOaISno114ACiM6ZIGQAoOW3r7EzWHK+WeY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EKERpcFfZXimDS05T4oVCB7VFh85kPVKJgOKl3jZgK4=; b=KsG7xoOPB5ihex4Bvi/q6OYcGAG4S+ksOl87UbolJ0MHnOb6JC80kispmdrUfT2d5+ o+wxdbIXnbqvveDkXXDdqNaViEPW61f1jJcUZp3VW/HdxoNe8jvmhMPwxwe9pGjuiJyG k4IF1QGbPflBxG1zTe7Ppi8h65tQbiFRjEN0lQ7/53ErGfowOw/mNhMNEpxRD4AXRaTG 7CvnuETW+w0TTX7rCN145yvBLgH1nErjleC4Kd5ZMHK12XR5IcHY4aVgMtBZiwCzC/Nt QRgLP7eNEqpRui4Sf/z7QvsaXWFmk0j1Z5B5N8S+Axfv65eKOHAVLANi3LO0KumN45Z/ ukjg== X-Gm-Message-State: ALoCoQlz/l9ul1hMqMB3bxlOBRMp/ZnEE15uUu4L6NAzdA0nd8OXGT7kJloOuuLGyCglZRxXpBPDc6vAoNrM3KZiMsAag7Px0g7yuiSCAm2TnTlPfc54CLtx93Cj3h7dqDGHtgE6ZI4+335oZdfjTGYHLNWbIP3a2w== X-Received: by 10.220.133.80 with SMTP id e16mr8350457vct.13.1394168222235; Thu, 06 Mar 2014 20:57:02 -0800 (PST) X-Received: by 10.220.133.80 with SMTP id e16mr8350441vct.13.1394168222117; Thu, 06 Mar 2014 20:57:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Thu, 6 Mar 2014 20:56:42 -0800 (PST) In-Reply-To: References: From: Yutaka OIWA Date: Fri, 7 Mar 2014 13:56:42 +0900 Message-ID: To: Yoav Nir , Watson Ladd Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/tTna1oG8C4HLb6S1iIfzUJWB0ro Cc: "http-auth@ietf.org" , cfrg@irtf.org Subject: Re: [http-auth] Fwd: [Cfrg] Another PAKE question X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 04:57:09 -0000 Dear Watson and all, I received a private communication from internal colleagues and would like to update my description. What Watson has mentioned seems to be the one in Section 11.2 of the main draft . VK_c and VK_s contain the log of the transactions K_c1 and K_s1 into the calculation. These values were already included in the original cryptographic primitives, and is treated as a "common" structure among primitives in the drafts (that's why it is in the main draft, instead of the algo draft). # Do you think we need more to be embedded, such as # session IDs into consideration? I think this makes a correct answer to the question, and I'd like to update the specs so that it becomes more clearer to the readers in the cryptographic community and future designers of additional algorithms. Thank you very much again for informative comments. 2014-03-06 3:30 GMT+09:00 Yutaka OIWA : > Watson, Sorry, I completely missed this mail in the pile of unread mails. > > # Thanks Yoav, your comment in WG reminds me and help finding out of this. > > AFAIK, putting the transaction history into the calculation is > already embedded as the values t_1 and t_2 described in > the algorithm in > , > Sections 2.2 and 2.3. > Isn't this t_1 and t_2 (put into the calculation of z) suffice for the purpose? > > My understanding is that the functionality what Watson mentioned is a > fundamental requirements for all PAKE primitives, and > is already embedded in the specification of such primitives' layer. > If this assumption is not, or if we need to protect more values than > the values appear in the cryptographic primitives, I agree that the > functionality > should be again implemented in the layer of the "HTTP Mutual authentication". > In such case I will do it with our cryptographer colleagues. > > Sorry for the very late reply, but I'm very happy if you can help me > better understanding of this issue. > > > 2014-01-10 0:24 GMT+09:00 Yoav Nir : >> Hi. >> >> CFRG has recently had some discussion about PAKEs in general. I have asked >> them to take a look at MutualAuth. This is one of the replies that we got. >> >> Yoav >> >> Begin forwarded message: >> >> From: Watson Ladd >> Subject: Re: [Cfrg] Another PAKE question >> Date: January 9, 2014 4:57:19 PM GMT+02:00 >> To: Yoav Nir >> >> Why is this protocol secure? >> I would recommend taking the z, and computing a hash of z and the >> transcript of the protocol. In >> this way under the ROM, the computed value doesn't reveal information. >> It ensures that any >> manipulation of the messages leads to different z values. >> >> I'll try to think of ways to make a proof given that change. >> Sincerely, >> Watson Ladd >> >> >> On Wed, Jan 8, 2014 at 10:09 PM, Yoav Nir wrote: >> >> Hi >> >> I almost feel like I'm asking for trouble after the roast that Dan went >> through, but some on this list might want to consider another PAKE going >> through an IETF working group. >> >> HTTP-Auth is making experimental authentication mechanisms for the HTTP >> layer. One of those is a PAKE. If people here on the CFRG list would like to >> comment on it, that would be great. We can have some discussion here, but >> ultimately, comments criticisms and suggestions should go to the HTTP-auth >> list (details below). >> >> The draft in question is called "Mutual Authentication Protocol for HTTP". >> >> Link: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01 >> >> Yoav >> co-chair of HTTP-Auth >> >> Mailing list details: >> * http-auth List Information: >> https://www.ietf.org/mailman/listinfo/http-auth >> * http-auth List Archives: >> http://www.ietf.org/mail-archive/web/http-auth/current/maillist.html >> * http-auth Posting Address (requires registration): http-auth@ietf.org >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> >> >> >> >> -- >> "Those who would give up Essential Liberty to purchase a little >> Temporary Safety deserve neither Liberty nor Safety." >> -- Benjamin Franklin >> >> >> Email secured by Check Point >> >> >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> > > > > -- > Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group > Research Institute for Secure Systems (RISEC) > National Institute of Advanced Industrial Science and Technology (AIST) > Mail addresses: , > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Fri Mar 7 02:23:52 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7221C1A0242 for ; Fri, 7 Mar 2014 02:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 FPMmn0ZVwKa7 for ; Fri, 7 Mar 2014 02:23:44 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id 222B81A018A for ; Fri, 7 Mar 2014 02:23:44 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id B6AF24008; Fri, 7 Mar 2014 12:23:38 +0200 (EET) Date: Fri, 7 Mar 2014 12:23:38 +0200 From: Ilari Liusvaara To: Yutaka OIWA Message-ID: <20140307102338.GA16889@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/SXh1JgGctQ6JSK4uhDcgmSRKvAw Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:23:47 -0000 On Thu, Mar 06, 2014 at 01:46:56AM +0900, Yutaka OIWA wrote: > Following the discussion in the HTTPAUTH WG sessions in > several previous meeting, > I believe it is a good thing to introduce a password hardening > into the current MutualAuth draft. I actually had the same idea (but didn't post it to the list). > In Section 11.2 (Default Functions for Algorithms), > > ---OLD--- > pi = INT(H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) > | VS(ph(password)))). > --- > will be replaced with > ---NEW--- > pi = INT(PBKDF2(HMAC-H, > ph(password), > VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username), > 2048, dkLen)) > > where > > o HMAC-H be the HMAC function [RFC2104] composed from the hash > function H, and > o dkLen shall be the length of hash H, counted in octets. > --- > > The open issues for the above change are: > > * Which function, possibly other than PBKDF2, will be the best > choice for the hardened password hash function? > I currently chose PBKDF2 just because there is an RFC. Basically, there are two kinds of "slow" password derivation: - Ones that burns CPU. - Ones that burn both CPU and memory. The latter are meant as anti-GPU, as otherwise one can use GPUs for high-performance password cracking. Unfortunately, while using fair amount of memory previously made GPU performance really fall off the cliff, that doesn't really happen anymore, but it still limits paralelism on GPU nicely. I think someone mentioned scrypt (or was it bcrypt)? Those both are well-known memory-burning password stretching functions. I don't think either has an RFC. > * What number of iterations are to be used? > Fixing it to 2048 makes sense? Or it should be a security parameter? As someone else said, 2048 for PBKDF2 is vastly insufficient (but for some other algorithms, iterations may be vastly more expensive). I would guess that the iteration counts for PBKDF2 nowadays would be in hundreds of thoursands or even millions. But that's just guessing (I have done some homebrew password stretching functions, those have iteration counts in millions). > * What is the best value for dkLen? > It is an output length of the hardened password hash in octets. > > Hereafter assume SHA-256 hash and 2048-bit DL key exchange are used. > The above definition lead to the value 256/8 = 32. > It is easy to make it larger, up to 1792/8 = 224 (1792 = 2048 - 256). > The cryptographically best values are either 2046/8, or > more precisely some irrational number 2046.99999..../8 (*), but > to achieve it, we need to modify/update PBKDF2 itself. > (*) 2046.99999... is log_2 r, where r is a number of mathmatically > possible elements (size of the generated group) for the passwords-equivalent. On the last point, if one wanted to hash to group order, the standard method is to generate slightly larger number of bits (NIST says at least 64, I would say at least 100), interpret the number as integer and then take modulo r. (or modulo (r - 1) + 1) This tends to be bit slow with larger groups, especially if the order is not near-power-of-two (IIRC, NIST P-224, NIST P-521, all E-series and all M-series elliptic curves do, NIST P-256 and P-384 don't). I think there was some RFC that described how to use hash function to stretch input... I don't know if hashing to group order is needed or not. I know SRP does not do it, it just takes 256 (or whatever) bit hash function value and uses that as an exponent. -Ilari From nobody Fri Mar 7 04:13:21 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC131A0242 for ; Fri, 7 Mar 2014 04:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 iynfoc0jV3NO for ; Fri, 7 Mar 2014 04:13:13 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id C25BE1A0218 for ; Fri, 7 Mar 2014 04:13:12 -0800 (PST) Received: from mail-ve0-f175.google.com ([209.85.128.175]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUxm31Ltvj2WA4cmeMxGbye8V74OamyGG@postini.com; Fri, 07 Mar 2014 04:13:09 PST Received: by mail-ve0-f175.google.com with SMTP id oz11so4085254veb.34 for ; Fri, 07 Mar 2014 04:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7918MJmUyhH0S9CkZYxCMDKsLm0ReT9GpfSl9geKYTg=; b=WHd4aekaXgyOnYOgoJg2UYucDS/mpynNUsDWvZyq2GmD7uYOQ8NL8r56PfBL2Bsmxh Wyr/vKHAuEpF5J4RZO2CTdcUr7G6YyEpyA3pMj0XlTglecaVctjKkkFSLMTLk6ADnxTc awEvUk4Cf+dzOezTk54j3B9KC0vItM2PniPe0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7918MJmUyhH0S9CkZYxCMDKsLm0ReT9GpfSl9geKYTg=; b=OX9/TKv1qRIYX5o1PROB1VC+GMrPDJRBMeUXsX8IOMhyS+G1WwZ3Ug4rw3pJJx9MmX /6utCXHOwftxY2iwkAXZtaIEY7g+RzAROKsZPhpzVlTPrgOjSgQ0p4TcPZcdcqOaobmq PDP0EVueaPWGvGBy+Js0E0VGY5jFxMt9zP7YaS86GiCNaTkkRMu23gIcVxZ5+Y9WLxsy 2FO2tzD6Ki0oQUcMfsYvmwZ6CbFjSOmiGDzidROyiXtQliJmvjVQoZhkTGtnLPp4KGW1 I1vBX2nYQXZaSL7aHUybZFPOyMxrQs4RnDatl3KaLEtRY54AyghNcRoholZban2Vifsb XNJw== X-Gm-Message-State: ALoCoQk86FYw5y9oGadkaBcrRcupI49jJUw/hj279F0B95rKL5/ERdMwP+AUmkhYw0MDemmuu0N7s91outv5KuQPzoCJDwSeLfEC6j5KwMZV7Z4NIib8cHsAYYMThTB5slofvNWDS+a+yH5OKfCNCfQd4ARIrUt5hw== X-Received: by 10.52.3.129 with SMTP id c1mr649746vdc.37.1394194388017; Fri, 07 Mar 2014 04:13:08 -0800 (PST) X-Received: by 10.52.3.129 with SMTP id c1mr649741vdc.37.1394194387899; Fri, 07 Mar 2014 04:13:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Fri, 7 Mar 2014 04:12:47 -0800 (PST) In-Reply-To: <20140307102338.GA16889@LK-Perkele-VII> References: <20140307102338.GA16889@LK-Perkele-VII> From: Yutaka OIWA Date: Fri, 7 Mar 2014 21:12:47 +0900 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/XBFknpOXDdJVUqS_UlKvfnhDVjM Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 12:13:19 -0000 Dear Ilari, thank you very much for the really valuable comment. For the iteration numbers: Hmm, very insightful, really. I feel that we need some compromise around there, as introduction of this is just a mitigation and also an additional caution measure. In other words, we're not strongly depending on the hash strength of password for the whole security. One million of iterations sounds a bit too many for me, I feel. I will also compare it with the computation time needed for modular/EC-field exponentiation, which is also needed for reversing the server-stolen password tokens. Scrypt is also mentioned by another people, and is very interesting for me. I'm reading the paper for that now. However, to use it we see some hurdles ahead of us, provided that pbkdf is available as RFC now and is well verified. Choosing a good security parameter seems to be important to get benefit from it, too. My current feeling for this is that one possibility might be to start a study about next standards for general password strengthening including scrypt, possibly with other area's people as well. Once it is accepted, we may add it as a new "ciphersuite". If more people are interested to do it starting now, it's interesting for me. Hash lengths: I think situation is exactly the same as SRP (In other words, we only accept cryptographic primitives which has the same properties). So, your comment pushes me from the behind to take just a 256-bit value as a password-equivalent. Thank you very much. 2014-03-07 19:23 GMT+09:00 Ilari Liusvaara : > On Thu, Mar 06, 2014 at 01:46:56AM +0900, Yutaka OIWA wrote: >> Following the discussion in the HTTPAUTH WG sessions in >> several previous meeting, >> I believe it is a good thing to introduce a password hardening >> into the current MutualAuth draft. > > I actually had the same idea (but didn't post it to the list). > >> In Section 11.2 (Default Functions for Algorithms), >> >> ---OLD--- >> pi = INT(H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) >> | VS(ph(password)))). >> --- >> will be replaced with >> ---NEW--- >> pi = INT(PBKDF2(HMAC-H, >> ph(password), >> VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username), >> 2048, dkLen)) >> >> where >> >> o HMAC-H be the HMAC function [RFC2104] composed from the hash >> function H, and >> o dkLen shall be the length of hash H, counted in octets. >> --- >> >> The open issues for the above change are: >> >> * Which function, possibly other than PBKDF2, will be the best >> choice for the hardened password hash function? >> I currently chose PBKDF2 just because there is an RFC. > > Basically, there are two kinds of "slow" password derivation: > - Ones that burns CPU. > - Ones that burn both CPU and memory. > > The latter are meant as anti-GPU, as otherwise one can use GPUs for > high-performance password cracking. > > Unfortunately, while using fair amount of memory previously made GPU > performance really fall off the cliff, that doesn't really happen anymore, > but it still limits paralelism on GPU nicely. > > I think someone mentioned scrypt (or was it bcrypt)? Those both are > well-known memory-burning password stretching functions. I don't > think either has an RFC. > >> * What number of iterations are to be used? >> Fixing it to 2048 makes sense? Or it should be a security parameter? > > As someone else said, 2048 for PBKDF2 is vastly insufficient (but for > some other algorithms, iterations may be vastly more expensive). > > I would guess that the iteration counts for PBKDF2 nowadays would be in > hundreds of thoursands or even millions. But that's just guessing > (I have done some homebrew password stretching functions, those have > iteration counts in millions). > >> * What is the best value for dkLen? >> It is an output length of the hardened password hash in octets. >> >> Hereafter assume SHA-256 hash and 2048-bit DL key exchange are used. >> The above definition lead to the value 256/8 = 32. >> It is easy to make it larger, up to 1792/8 = 224 (1792 = 2048 - 256). >> The cryptographically best values are either 2046/8, or >> more precisely some irrational number 2046.99999..../8 (*), but >> to achieve it, we need to modify/update PBKDF2 itself. >> (*) 2046.99999... is log_2 r, where r is a number of mathmatically >> possible elements (size of the generated group) for the passwords-equivalent. > > On the last point, if one wanted to hash to group order, the standard method > is to generate slightly larger number of bits (NIST says at least 64, I would > say at least 100), interpret the number as integer and then take modulo r. > (or modulo (r - 1) + 1) > > This tends to be bit slow with larger groups, especially if the order is not > near-power-of-two (IIRC, NIST P-224, NIST P-521, all E-series and all M-series > elliptic curves do, NIST P-256 and P-384 don't). > > I think there was some RFC that described how to use hash function to stretch > input... > > I don't know if hashing to group order is needed or not. I know SRP does > not do it, it just takes 256 (or whatever) bit hash function value and uses > that as an exponent. > > > -Ilari -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Fri Mar 7 10:07:34 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486DE1A00EC for ; Fri, 7 Mar 2014 10:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 w3-eGm0RiEVS for ; Fri, 7 Mar 2014 10:07:30 -0800 (PST) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C81A0274 for ; Fri, 7 Mar 2014 10:07:28 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 483B2699C7; Fri, 7 Mar 2014 20:07:23 +0200 (EET) Date: Fri, 7 Mar 2014 20:07:23 +0200 From: Ilari Liusvaara To: Yutaka OIWA Message-ID: <20140307180722.GA22828@LK-Perkele-VII> References: <20140307102338.GA16889@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/JD_-duv533kgHXgpT_9KJ8_WgRI Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 18:07:32 -0000 On Fri, Mar 07, 2014 at 09:12:47PM +0900, Yutaka OIWA wrote: > > Hmm, very insightful, really. > In other words, we're not strongly depending on the > hash strength of password for the whole security. For me, this kind of strenghening only makes sense for schemes secure against active attacks. > One million of iterations sounds a bit too many for me, I feel. > I will also compare it with the computation time needed for > modular/EC-field exponentiation, which is also > needed for reversing the server-stolen password tokens. At least when comparing fast EC curves (~256-bit) with targets I tune password stretching functions to (and I have heard some using even slower targets), EC curves are faster by multiple orders of magitude. -Ilari From nobody Sat Mar 8 06:50:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4941A0268 for ; Sat, 8 Mar 2014 06:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 B7bctF26j8-2 for ; Sat, 8 Mar 2014 06:50:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 846C31A0267 for ; Sat, 8 Mar 2014 06:50:11 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0272A4045D; Sat, 8 Mar 2014 07:50:06 -0700 (MST) Message-ID: <531B2E1E.8000207@stpeter.im> Date: Sat, 08 Mar 2014 07:50:06 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <531A09C7.7070904@stpeter.im> In-Reply-To: <531A09C7.7070904@stpeter.im> X-Forwarded-Message-Id: <531A09C7.7070904@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/8RymW7gpLL90gY_AknhQinS4Q8c Subject: [http-auth] Fwd: [precis] usernames in PRECIS and http-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 14:50:13 -0000 FYI. Please discuss on the precis@ietf.org list. -------- Original Message -------- Subject: [precis] usernames in PRECIS and http-auth Date: Fri, 07 Mar 2014 11:02:47 -0700 From: Peter Saint-Andre To: precis@ietf.org As promised at IETF 89, I have compared the username definitions from draft-oiwa-precis-httpauthprep-00 and draft-ietf-precis-saslprepbis-06, with the purpose of perhaps harmonizing the two approaches so that we can avoid multiplying PRECIS profiles beyond necessity. (I am writing this email on the flight home, and I neglected to load up the meeting minutes before leaving, so I might not address all of the relevant points in this message.) First, let's look at the syntax definitions. draft-ietf-precis-saslprepbis-06 states that a username can (a) consist of one of more userparts, or (b) can be of the form userpart@domainpart. The ABNF definition is: username = userpart [1*(1*SP userpart)] / userpart ’@’ domainpart userpart = 1*(idpoint) domainpart = IP-literal / IPv4address / ifqdn ifqdn = 1*1023(domainpoint) Where: * an "idpoint" is a UTF-8 encoded Unicode code point that conforms to the PRECIS "IdentifierClass" * an "IPv4address" is as defined in RFC 3986 * an "IP-literal" is as defined in RFC 3986 * a "domainpoint" is a UTF-8 encoded Unicode code point that conforms to RFC 5890 By contrast, draft-oiwa-precis-httpauthprep states that a username consists of one or more UTF-8 encoded Unicode code points that conform to the PRECIS "IdentifierClass". The ABNF definition is: userpart = 1*(idpoint) We quickly see that an http-auth username is a legal PRECIS username, since 1*(idpoint) is simply a userpart as defined in draft-ietf-precis-saslprepbis-06, and a PRECIS username can consist of only one userpart. Therefore, in this respect, I think the httpauthprep text (whether it appears in a standalone document or elsewhere) can simply state that for purposes of HTTP authentication a username is a userpart as defined in draft-ietf-precis-saslprepbis. Second, let's look at the string preparation method. Here, too, draft-oiwa-precis-httpauthprep-00 is a subset of draft-ietf-precis-saslprepbis-06. The preparation method in draft-ietf-precis-saslprepbis-06 is: 1. The base string class is the "IdentifierClass" specified in [I-D.ietf-precis-framework]. 2. Fullwidth and halfwidth characters MUST be mapped to their decomposition equivalents. 3. So-called additional mappings MAY be applied, such as those defined in [I-D.ietf-precis-mappings]. 4. Uppercase and titlecase characters might be mapped to their lowercase equivalents (see Section 4.2.1 below). 5. Unicode Normalization Form C (NFC) MUST be applied to all characters. By contrast, the preparation method in draft-oiwa-precis-httpauthprep-00 is: 1. Fullwidth and halfwidth characters MUST be mapped to their decomposition equivalents. 2. Additional mappings SHOULD NOT be applied, such as those defined in [I-D.ietf-precis-mappings], unless there are implementation- dependent reasons to do so, or these are exceptionally required by specific authentication schemes. 3. Case mapping is not applied. 4. Unicode Normalization Form C (NFC) MUST be applied to all characters.o These two defnitions agree on the width mapping and normalization rules described in the PRECIS framework. They appear to differ slightly with regard to the additional mapping and case mapping rules. However, draft-oiwa-precis-httpauthprep-00 is merely a bit more restrictive with regard to matters that are purely optional according to draft-ietf-precis-saslprepbis-06. For example, the option of saying that "case mapping is not applied" is allowed by the text "uppercase and titlecase characters might be mapped to their lowercase equivalents". To make this clearer, I suggest that we modify the advice in draft-oiwa-precis-httpauthprep-00 so that it no longer defines its own PRECIS profile. Instead, I suggest that we phrase the httpauthprep text in terms of the username profile in draft-ietf-precis-saslprepbis-06. To my mind, something like this would work: ### For the purposes of HTTP authentication, a username conforms to the syntax definition and preparation methods specified in [I.D-draft-ietf-precis-saslprepbis], with the following limitations: * a username conforms to the "userpart" construction from [I-D.draft-ietf-precis-saslprepbis] * case mapping is not applied * delimiter mappings, special mappings, and other so-called additional mappings [I-D.draft-ietf-precis-mappings] are not applied ### As far as I can see, this simplifies the httpautheprep text quite a bit. (By the way, draft-oiwa-precis-httpauthprep-00 also seems to copy the password profile verbatim from draft-ietf-precis-saslprepbis. I think this text can be removed entirely, so that the httpauthprep text can simply reference draft-ietf-precis-saslprepbis.) Yutaka and Alexey (and others), let me know what you think about what I have written here. Thanks, Peter _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis From nobody Sat Mar 8 08:40:16 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0471A02C7 for ; Sat, 8 Mar 2014 08:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 H_XUCrxnizwe for ; Sat, 8 Mar 2014 08:40:11 -0800 (PST) Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) by ietfa.amsl.com (Postfix) with ESMTP id 62CFD1A02B8 for ; Sat, 8 Mar 2014 08:40:11 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( egs 8.14.5/8.14.5) with ESMTP id s28Ge6bS026242 for ; Sat, 8 Mar 2014 08:40:06 -0800 Received: from vpn-135-70-103-20.vpn.swst.att.com ([135.70.103.20]) by maillennium.att.com (mailgw1) with ESMTP id <20140308164005gw100j0c5ee>; Sat, 8 Mar 2014 16:40:05 +0000 X-Originating-IP: [135.70.103.20] Message-ID: <531B47E4.2090901@att.com> Date: Sat, 08 Mar 2014 11:40:04 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: http-auth@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/fN5N0AZeBcjZe-tpzAL0OqZYWOE Subject: [http-auth] a review of draft-ietf-httpauth-scram-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 16:40:15 -0000 I just recently finished an implementation of SCRAM support in another protocol that is almost identical to HTTP, so my wounds there are rather fresh. This is a review of Salted Challenge Response (SCRAM) HTTP Authentication Mechanism, draft-ietf-httpauth-scram-auth. (In what follows, I'll refer to this version of SCRAM as "HTTP SCRAM" and that in RFC 5802 as "SASL SCRAM".) In the following, I raise a large number of points about this draft in particular, along with some points related to HTTP auth in general. Tony Hansen As I was re-reading this draft, my thoughts kept getting drawn to these questions: 1) what is different in HTTP SCRAM from the original SASL SCRAM documented in RFC 5802? 2) hash agility 3) method agility 1. What is different in HTTP SCRAM from the original SASL SCRAM documented in RFC 5802? When a new version of a spec is created by copying such a large portion of another protocol document, as this document was from RFC 5802, someone who has implemented the earlier protocol or who has a library that implements the earlier protocol needs to be concerned about the differences between this new incarnation and the previous incarnation. If you do a diff between this draft and RFC 5802 (such as using tools.ietf.org/rfcdiff), you will see many gratuitous differences (eg "left side" vs "left-side", "that" vs "which") whose very quantity could hide the actual differences. First off, get rid of the gratuitous differences! If the copied text is going to be kept, make it easy to diff the two. Now note: actual differences do exist. In particular, I noted several specific differences, although I may have missed some: a) The specification of the gs2 header is different. It has been "adjusted" to match the name=value format of www-authenticate's 1#challenge. In addition, the use of authzid has been lost. For example, in SASL SCRAM the gs2-header uses "p=channel,authzid," and in HTTP SCRAM, gs2-header uses "g=p=channel," with no way to specify authzid. b) The handling of white space and double quotes. The consequence of these substantive differences is that existing implementations of SASL SCRAM can NOT be used to implement HTTP SCRAM. Personally I think that this is a bad consequence. There are two fixes for going forward: A) Accept that there are differences. If we do this, I feel that there MUST MUST MUST be a serious WARNING section added for implementers to let them know that current SASL SCRAM libraries can NOT be used. B) Get rid of these differences. See below. Regarding the handling of white space, one of the hardest parts to get right with SCRAM is getting the inputs into the hash algorithms exactly right, on BOTH sides. For example, if one side includes a space and the other side does not, then the hashes will not match. If you look at the ABNF for "challenge" (HTTP-P7, HTTP-P1) and the ABNF for the elements for the name=value pairs in HTTP SCRAM, you will find that they are not compatible. The HTTP definition is a superset in that it allows for the use of quoted strings and allows for white space to be included in various locations, neither of which are allowed by the ABNF for the SCRAM-specific elements. I don't think that the ABNF for auth-param is compatible at all with gs2-header p= option because token68 does not allow an "=". The examples all use copious white space both between parameters and beginnings and ends of multiple lines, as well as the line breaks themselves. At a minimum, there need to be a note about this difference, as well as a requirement that all white space must be stripped before doing any hashing. Or see my note below on eliminating the differences. As for the quotation marks, there are a couple possibilities. The most correct would be to change the ABNF for ALL of the SCRAM elements to be compatible with the ABNF for "challenge". This is also required to satisfy the gs2-header issue mentioned above. Or see my note below on eliminating the differences. The loss of authz is potentially troublesome. I know that HTTP hasn't included this concept before, so anyone who has needed this concept has had to implement it below HTTP or using a non-standard HTTP header. There is discussion of the use of authz elsewhere on the httpauth list. One way to correct this is to provide a new "z=" parameter (to pick that is allowed as part of gs2-header. NOTE: this further breaks compatibility with stock SCRAM implementations. Or see my note below on eliminating the differences. There is no ABNF for the sid value or any constraints on it. 2) Hash agility HTTP SCRAM is defining a >family< of authentication schemes whose names all start with "SCRAM-" and end with a hash value. a) The ABNF for challenge-scram and credentials-scram are wrong. They both specify "SCRAM-SHA-1" as the only string that can be used. Instead they should say something like: challenge-scram = scram-name 1*SP 1#auth-param credentials-scram = scram-name 1*SP 1#auth-param scram-name = "SCRAM-SHA-1" / other-scram-name ; SCRAM-SHA-1 is registered by this RFC other-scram-name = "SCRAM-" hash-name ; hash-name is a capitalized form of names from IANA "Hash Function Textual Names" registry. ; Additional SCRAM names must be registered in both the IANA "SASL mechanisms" registry ; and the IANA "authentication scheme" registry. The comments about sasl name and hash name registry come from RFC 5802. It MIGHT be worth mentioning the potential use of SCRAM-SHA-256 in the future, but I'm not going to get hung up on this. Actually, the ABNF shown in section 5 and aboe is incorrect as shown because auth-param is actually optional when there is no realm. A better description might be challenge-scram = scram-name (1*SP 1#auth-param) credentials-scram = scram-name (1*SP 1#auth-param) 3) method agility Unless I'm totally mistaken, the issues with method agility are associated with the protocol exchange example shown in section 5 is incorrect with respect to the realm and the description of the original 401 Unauthorized challenge along with subsequent descriptions of the realm. I think it's worth showing a *complete* example 401 challenge exchange, filling in the "server might have returned 401 Unauthorized first" comment. THIS is where the server might provide one or more realm names as part of its challenge. For example, you might see: WWW-Authenticate: Basic Digest realm="realm1" Digest realm="realm2" Digest realm="realm3" SCRAM-SHA-1 realm="realm3" SCRAM-SHA-1 realm="realm4" In this example, the user may authenticate using Basic with no realm, using Digest in realms 1, 2 or 3, and using SCRAM-SHA-1 using realms 3 or 4. The first client response that includes a WWW-Authenticate header then specifies the authentication scheme along with the optional realm that's been chosen and any additional parameters needed for the specific authentication scheme. The interesting new thing about SCRAM-SHA1 as an authentication scheme is that it is the first one that has multiple rounds. The server challenge that comes back from an authentication scheme that requires such multiple rounds should NOT specify the realm parameter again, nor should subsequent client responses include the realm parameter again. [...The server might have returned 401 Unauthorized first...] S: WWW-Authenticate: Basic Digest realm="realm1@host.com" Digest realm="realm2@host.com" Digest realm="realm3@host.com" SCRAM-SHA-1 realm="realm3@host.com" SCRAM-SHA-1 realm="testrealm@host.com" S: [...] C: GET /resource HTTP/1.1 C: Host: server.example.com C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL C: [...] S: HTTP/1.1 401 Unauthorized S: WWW-Authenticate: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92, i=4096 S: [...] C: GET /resource HTTP/1.1 C: Host: server.example.com C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= C: [...] S: HTTP/1.1 200 Ok S: Authentication-Info: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, v=rmF9pqV8S7suAoZWja4dJRkFsKQ= S: [...Other header fields and resource body...] The description of the realm parameter(s) need to be adjusted to reflect when the server and client send it/them. It might be worth introducing SOMEWHERE the terms "challenge #0" as the server challenge that lists the acceptable authentication schemes and their optional realms, and then the client response is "response #1" followed by "challenge #1", and counting up from there. In general terms, challenge #0 always lists the available authentication schemes and their optional realms (along with any other initial parameters that need to be passed along with that authentication scheme). Response #1 specifies the next round of parameters for the given authentication scheme chosen by the client. Challenge #1 either returns the 200 with an optional Authorization-Info or another 401 Unauthorized with a WWW-Authenticate header. If this is an authentication scheme that allows another round to be used for additional information, Challenge #1 would also include a sid= parameter (or WWW-Authentication-Sid header as has been suggested elsewhere). Subsequent Responses (#2 and beyond) then use the same sid=/WWW-Authentication-Sid value to tie the challenges and response together. I'm not sure where SOMEWHERE should be. Is it too late to get this into HTTP BIS P7? Getting Rid of the Differences with SASL SCRAM Now I'm going to present an alternative way of fixing some of the problems above. The basic idea is to say that the SCRAM-SHA-1 payloads are exactly as specified in RFC 5802, but are base64-encoded for use within HTTP. This is exactly the SASL authentication split that is used by all other application protocols that use SASL: the SASL mechanism specifies what information needs to be included in any given round of exchange and the application protocol specifies how that information is wrapped for transmission within the application protocol. For example, an application protocol could use base64 encoding of that data (as suggested here), or could use run-length-encoding if it's binary, or could use quoted-printable or hex or whatever. The important thing is that is a strict separation of responsibility. The application protocol doesn't care what the data is and what is included within it; it just has some mechanism for getting that data across the protocol boundary safely. The application protocol restores that data back to its octet form and passes that data into the authentication mechanism. The response from the authentication mechanism is then encoded for the application-layer response. How does this look for HTTP SCRAM? I'm going to use the word "payload" to represent the parameter that holds the SCRAM-SHA-1 payload. Each challenge and response becomes 1) the scram name, 2) either the realm or sid value, and then 3) the payload value. (I don't care what the parameter name is called.) In ABNF, this would be something like this: challenge-scram = scram-name WS realm-or-sid BWS "," OWS "payload=" payload-value credentials-scram = scram-name WS realm-or-sid BWS "," OWS "payload=" payload-value realm-or-sid = ( "realm=" realm-value / "sid=" sid-value ) payload-value = 1*base64 / DQUOTE 1*base64 DQUOTE If "sid=" were moved out to a different header, then the above would become challenge-scram = scram-name WS [realm BWS ","] OWS "payload=" payload-value credentials-scram = scram-name WS [realm BWS ","] OWS "payload=" payload-value realm-spec = "realm=" realm-value payload-value = 1*base64 / DQUOTE 1*base64 DQUOTE session-id-header = "WWW-Authentication-ID:" *SP session-id session-id = token All of the rest of the document that provides details on what is included within that payload would be removed and replaced with a reference to RFC 5802 and a small section on how HTTP authentication credentials map into the SASL concepts of authentication id, authorization id, etc. The document would still only register SCRAM-SHA-1. Generalizing Just a Bit Further An interesting consequence of this modification is that it is extremely close to what would be needed to generalize HTTP authentication to using any given SASL mechanism that is duly registered and supported by the server. The first editing step is to change the ABNF names used above from scram-name to sasl-name. The only other required change is noting somewhere that challenge#0 MAY include an optional payload if that particular authentication mechanism has a payload value that is to be sent first from the server to the client. (Just as Digest has a variety of parameters that are transmitted along with challenge#0.) There might be a constraint placed on the non-use of SASL security layers and restricting the set of SASL mechanisms only to those that do not require a security layer to be used. And I think that that's it. I hope this is of use. Tony Hansen From nobody Tue Mar 11 09:43:52 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7601A0769 for ; Tue, 11 Mar 2014 09:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 jkdGPj62qQjS for ; Tue, 11 Mar 2014 09:43:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id A278E1A076A for ; Tue, 11 Mar 2014 09:43:45 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LkgAG-1Wve7d1cOa-00aYqe; Tue, 11 Mar 2014 17:43:01 +0100 Message-ID: <531F3D12.3020502@gmx.de> Date: Tue, 11 Mar 2014 17:42:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Manu Sporny , "http-auth@ietf.org" References: <52ED42C9.2070809@digitalbazaar.com> <52ED42C9.2070809@digitalbazaar.com> <52EFC691.9060304@gmx.de> <52F2A970.10605@digitalbazaar.com> In-Reply-To: <52F2A970.10605@digitalbazaar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9GO8p9DaGoeL3wjq1L6kF/3+U+TGldlWpfVnzWBh/r2tqLnmHxo bBWr1oxQNfAcMXQsomkEks+tfrZTkBq3gsZQb3HL3OyagrF9sXjUyPbNq5Zp8nFD+2kVHq7 lm4U0tiqtvqQicXlAvxYRQchybEHXXrRHh2jpstvkb5SSQDSSuk5V/nrgMoX78D6OqC9vC3 5ZHec0KztroDOJEQCH+Lw== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/z6Du1AAkJN33_69Mtn0uSVJMDzA Cc: public-webpayments@w3.org Subject: Re: [http-auth] HTTP Signatures specification updated X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:43:51 -0000 On 2014-02-05 22:13, Manu Sporny wrote: > On 02/03/2014 11:40 AM, Julian Reschke wrote: >> find below my feedback: > > Hi Julian, thanks for the feedback, responses to you feedback with some > additional questions below. > >> 1) The spec seems to be confused about whether it defines an HTTP >> authentication scheme or not. If it does, it needs to follow the >> requirements in >> > >> if it does not, it shouldn't use the "Authorization" header field. > > The specification started out as a way for clients to authenticate > themselves to the origin. We've had a few requests to use the same > general approach for the origin to authenticate certain parts of the > HTTP message back to the client (which can be useful over non-TLS > connections, or if you want to have extra security on top of TLS for > Pervasive Monitoring scenarios). > > If we wanted to use the mechanism for both client-to-origin signatures > and origin-to-client signatures, what would you suggest that we do? We > could introduce a new header "Signature", that can be used by both > clients and origins, but didn't know if that would be the proper > approach. Thoughts? Not at this point :-) > For the time being, I think I've followed the requirements in the > draft-ietf-httpbis-p7-auth-25 spec. It's unclear exactly how I should > specify the registration. The registry doesn't exist yet. So I've added > an IANA Considerations appendix noting the requirement for a > registration to be made if the spec makes it through the IETF process: > > https://web-payments.org/specs/source/http-signatures/#appendix-d In the meantime the registry does exist; your registration looks right to me, although I'd make the "Reference" entry just say "Section 2 of this document" (and make the Section # an actual link). > It would be helpful if the text in ietf-httpbis-p7-auth-25 gave an > example of how one does this, or linked to an RFC that describes how to > do this. You got it right, so the text appears to be sufficient. (note we are at -26 in the meantime). >> 2) REQUIRED. The `algorithm` parameter is used if the client and >> server agree on a non-standard digital signature algorithm. The full >> list of supported signature mechanisms is listed below. >> >> - This should be aligned with other IETF specs using algorithm >> names. > > The algorithm names are aligned w/ RFC6376: > > http://tools.ietf.org/html/rfc6376 > > JOSE chose to use different algorithm names. Which IETF specs should we > align with, they're both current, no? Dunno. The security experts should know the answer. > ... >> - for request-line, just pick a name that is guaranteed not to >> conflict (such as "(request-line)"). That being said, the request >> line is gone from HTTP/2, and it might be good to break the >> information down into components that are more generic. > > Would still calling it "(request-line)" be fine and the state that for > HTTP2, the request line is built using the method, path, and the string > "HTTP/2"? For example: > > GET /foo HTTP/2 > > would be the request line generated for creating and validating signatures? (a) Why do you need the protocol name? (b) Wouldn't it be wiser to use the full effective request URI? > ... >> 6) 1. If the header name is not `request-line` then append the >> lowercased header name followed with an ASCII colon `:` and an ASCII >> space ` `. >> >> - And the field value? > > Fixed: > > https://web-payments.org/specs/source/http-signatures/#canonicalization > >> - Also: what if there are multiple instances of a given field name? > > Added guidance if there are multiple instances: > > http://sites.local/web-payments.org/specs/source/http-signatures/#canonicalization Concatenated with no delimiter? >> - What about leading and trailing whitespace in the header field >> value? > > They are preserved, we want to stay as far away from canonicalizing the > headers as we can. If a library, client, proxy, or server adds/removes > whitespace, then the application is screwed. Canonicalization of header > field values is something we do not want to specify, even if it means > that signatures in some environments will fail. I believe this is going to break with many libraries. It would be wiser to leave out leading/trailing whitespace. > ... >> Editorial: >> >> - In the boilerplate, please say where to send feedback. > > Done: > > https://github.com/web-payments/web-payments.org/commit/0da85e2066011ab7e9eb8595ecd136affb6a5346 Looks good. > Although, I don't know if I added the note in the right way. The W3C > spec tool allows you to modify the Status section, I couldn't find out > how to do that w/ the xml2rfc tool. You can't change the status. >> - Please cite the HTTPbis drafts instead of RFC 2616. > > Fixed: > > https://github.com/web-payments/web-payments.org/commit/83c9cba2a3fc99bef0e71bd0fadeb058b7576966 ...should be in the References section. >> - Please do not cite RFC 2617 except when talking about Basic and >> Digest > > Done: > > https://github.com/web-payments/web-payments.org/commit/6f97a12df79619b8eb264db8ce209ef149c30598 > >> - s/header/header field/ > > Fixed: > > https://github.com/web-payments/web-payments.org/commit/e8c14fa0b2fdc291473f1aa7302281e4915ee66e > >> - please use symbolic references (xml2rfc PI symrefs="yes") > > I thought I was, but the xml2rfc tool doesn't seem to be picking it up? > > https://github.com/web-payments/web-payments.org/blob/6f97a12df79619b8eb264db8ce209ef149c30598/specs/source/http-signatures/index.xml#L17 Because you don't have any references at all it seems :-) See . > ... > It would be great to hear your thoughts on whether this spec should > continue to use the Authorization header or if it should try to do > origin-to-client authentication as well. We'd like to do the latter if > there is a simple, clean way to do it. It would be nice if the HTTP > message information passed back from the financial servers that would be > using this spec could be digitally signed as well. Answers to the other > questions asked would also be greatly appreciated. :) > ... I know little about the use cases. You really ought to solicit feedback of the httpauth working group. Best regards, Julian From nobody Mon Mar 31 14:47:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD481A797C for ; Mon, 31 Mar 2014 14:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ymEc5DOgLqZN for ; Mon, 31 Mar 2014 14:47:18 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1601A08D8 for ; Mon, 31 Mar 2014 14:47:18 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id q5so4111414wiv.16 for ; Mon, 31 Mar 2014 14:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rCR9sJq0n2ckSVC5MPS47mgxhAkuzMtZyR/YWO/yvKk=; b=AxVnf/2e6icOJQ1cyx+Vc9VKq98h4dAdVmVGtJd+rmBnRSx5+TqqJo+ciXSqUYsqIP +yY9XGfWs5JUcTfscw6ZZ9KQgX0UIKOngGINlDXeyhyTXitZIIdUp13SYLPa3Vt7hQnD OWuOFJiFfB9lb1XM3yq7rHGmoa4A9Qohmtsqkm3/TmvAVVvZIVOnWYCSNdRuIeFA8qZB ANTLiVwWIBHQWj+/G1MktJyD/K2VGJ6WWym//vXFgzBJ43KaPEw9ZaMNMPYBr/3ouJDx inq+UV5MgzmsH43WNLo4JQSqnI57Sbp6kMWBn02K4Wpz2LMwD/d0Kvo727k7530sWOZ5 aJrw== MIME-Version: 1.0 X-Received: by 10.180.78.200 with SMTP id d8mr15290187wix.34.1396302432549; Mon, 31 Mar 2014 14:47:12 -0700 (PDT) Received: by 10.217.120.194 with HTTP; Mon, 31 Mar 2014 14:47:12 -0700 (PDT) Date: Mon, 31 Mar 2014 17:47:12 -0400 Message-ID: From: Matthew Lepinski To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=f46d0435c0507dc92604f5edfefd Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/il8Ii2W0Z4_FHk8rCZecIM_efC0 Subject: [http-auth] Draft Minutes Posted for IETF 89 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 21:47:20 -0000 --f46d0435c0507dc92604f5edfefd Content-Type: text/plain; charset=ISO-8859-1 The draft minutes for the HTTPAUTH session have been posted to the proceedings tool. The draft minutes can be found here: http://www.ietf.org/proceedings/89/minutes/minutes-89-httpauth If you identify any corrections that need to be made in the minutes, please send them to the list. - Yoav and Matt --f46d0435c0507dc92604f5edfefd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The draft minutes for the HTTPAUTH session have been poste= d to the proceedings tool.=A0

The draft minutes can be f= ound here:=A0

If you identify any corrections that need to be made in= the minutes, please send them to the list.

- Yoav a= nd Matt
--f46d0435c0507dc92604f5edfefd--