From nobody Wed Apr 1 05:23:20 2015 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 30A251A8A7D for ; Wed, 1 Apr 2015 05:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 XWaCP2lVYUM4 for ; Wed, 1 Apr 2015 05:23:17 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BDE1A8A25 for ; Wed, 1 Apr 2015 05:23:17 -0700 (PDT) Received: by obbec2 with SMTP id ec2so75385855obb.3 for ; Wed, 01 Apr 2015 05:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/+Kp8wfbJ4AtU63XxkN2nJ/bl/uTU4kuIm5DZNEer6E=; b=0E+ufxDtkl7qorZSxKhvw293ASLmOfZgSLFGROZl8W1AYRz5OZf+RTn7ylfrxsGUV7 TajADwJyt4rQEYHIxz/WpbXVHFN6TwZHylQE7RcYg2j+saVH55RlmpNan4mAqJz0AmaM uApCTkRlLYJXMnUwzw3RcG6YCWIKB3qfywl7KbeUYc09t5544B6VDATF2Wkcyj8QQoVU HlGL/82P+DfaN/uo0BrIxVsRPzd7W7EdiTCvagFTXdo/FneLxy+ZXx9A+7bXXdig+rip xypArIvxQ3uT26iERNQYEPJz9s4DlmQgVvW5exqJdwbLYVoDofsdKgA5Fq6Kovm7C28r 1RYg== MIME-Version: 1.0 X-Received: by 10.60.131.37 with SMTP id oj5mr24470853oeb.77.1427890996279; Wed, 01 Apr 2015 05:23:16 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Wed, 1 Apr 2015 05:23:16 -0700 (PDT) In-Reply-To: <1C678126-8B1F-4E12-B74A-E5CD79BAD3CB@gmail.com> References: <349AF075-CD98-4BC1-9316-60364E28011A@gmail.com> <5514D71B.5070206@aist.go.jp> <55157AAB.30508@gmail.com> <03BCD0E7-0550-47EB-852E-9F5E20D32954@netzkonform.de> <688820D9-D02D-428A-86C3-7429D7727C00@netzkonform.de> <59778922-72D2-42C1-9DE4-1703E9BD72AB@gmail.com> <2F8A2498-6C3D-45F1-AF28-F7D1E67FC715@netzkonform.de> <594726DE-0C87-464D-9CD7-94BA00B43450@gmail.com> <1905F537-BBC0-4EF6-AA85-F874BA5D292F@gmail.com> <1C678126-8B1F-4E12-B74A-E5CD79BAD3CB@gmail.com> Date: Wed, 1 Apr 2015 08:23:16 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Yoav Nir Content-Type: multipart/alternative; boundary=089e013cb9cc9c7ef20512a8c759 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - A1 with Salted Hash 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, 01 Apr 2015 12:23:19 -0000 --089e013cb9cc9c7ef20512a8c759 Content-Type: text/plain; charset=ISO-8859-1 For the *transition period*, where the system wants to support both salted and non-salted clients, the server could store both the salted password and the non-salted password. Regards, Rifaat On Tue, Mar 31, 2015 at 3:54 PM, Yoav Nir wrote: > The difference is that to use a salted hash, you need a salted database. > Once the database is salted, you can't use plain digest. This means that > your server cannot support both old and new clients. It's either a salted > database and new clients, or an unsalted database and both kinds of > clients, but no salt. There is no smooth transition. > > Yoav > > On Mar 31, 2015, at 9:27 PM, Rifaat Shekh-Yusef > wrote: > > Yoav, > > To take advantage of any of the new functionalities defined in this draft > you need new software in the client and the server. > How is salted hash any different? > > Regards, > Rifaat > > > On Mon, Mar 30, 2015 at 1:15 PM, Yoav Nir wrote: > >> >> > On Mar 30, 2015, at 6:01 PM, Rifaat Shekh-Yusef >> wrote: >> > >> > Yoav, >> > >> > This would be addressed by indicating that the algorithms in the >> registry might have a salted variant, similar to the -sess variant. >> > Existing clients will always select non-salted variants, while new >> clients should be able to select salted variants if they support it. >> >> Sure, but -sess variants have been there since forever. "-salt" would >> require a new client and a new server, and a server can't support both >> "-salt" and non-"-salt" (because if the database is salted, you can do >> Basic, but you can't do regular Digest). >> >> So if the database requires a new client and new software on the server, >> we might as well choose something more modern than Digest. >> >> Yoav >> >> >> > > --089e013cb9cc9c7ef20512a8c759 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For the *transition period*, where the system wants to sup= port both salted and non-salted clients, the server could store both the sa= lted password and the non-salted password.

Regards,=
 Rifaat



On Tue, Mar 31, 2015 = at 3:54 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
The differenc= e is that to use a salted hash, you need a salted database. Once the databa= se is salted, you can’t use plain digest. This means that your server= cannot support both old and new clients. It’s either a salted databa= se and new clients, or an unsalted database and both kinds of clients, but = no salt. There is no smooth transition.

Yoav
<= div>
On Mar 31, 2015, at 9:27 PM, Ri= faat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Yo= av,

To take advantage of any of the new functionalities = defined in this draft you need new software in the client and the server.
How is salted hash any different?

Regards= ,
 Rifaat


On Mon, Mar 30, 2015 at 1:15 PM, Yoav Nir= <ynir.ietf@gmail.com> wrote:

> On Mar 30, 2015, at 6:01 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrot= e:
>
> Yoav,
>
> This would be addressed by indicating that the algorithms in the regis= try might have a salted variant, similar to the -sess variant.
> Existing clients will always select non-salted variants, while new cli= ents should be able to select salted variants if they support it.

Sure, but -sess variants have been there since forever. “-salt= ” would require a new client and a new server, and a server can&rsquo= ;t support both “-salt” and non-“-salt” (because if= the database is salted, you can do Basic, but you can’t do regular D= igest).

So if the database requires a new client and new software on the server, we= might as well choose something more modern than Digest.

Yoav





--089e013cb9cc9c7ef20512a8c759-- From nobody Wed Apr 1 06:03:17 2015 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 763071A8BB4 for ; Wed, 1 Apr 2015 06:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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 4qQcgHkTATAJ for ; Wed, 1 Apr 2015 06:03:14 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB771A1A04 for ; Wed, 1 Apr 2015 06:03:13 -0700 (PDT) Received: by wiaa2 with SMTP id a2so65447986wia.0 for ; Wed, 01 Apr 2015 06:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=plPqSNXt02odFxKohqwNV92kvL0Edtj9t6LtetaMzIs=; b=iYgRuX/dCNtj7m8USuO9S4nrmX0e6tPyuRFO4cAGwJM5DpuhG2McIhLjK7hWnu6A/T BhDfBwQ+K76B45g74//R3u+RsOd2WZhqky9usjcpwD3FOpj3FeM/TTZPK6pbKEHjOnfw GPD1onvbaE8nm8iJP6pcavcwLBVlS4jBKMc9bC7CQvrjG/81J7zsKHG6pqkGC3J+kB// 1bq/UkbMbNGplsXIzqr1QrEkUH1hZoFZaG9Z/p8aY6bQuVuK0iAIj/oRBByvzc8EeF3l +WHvfS3knnJ1sFqFI3yY1NB0ntWBxd3Iq+NnTSKrVIS9amNlhAIqBkotxfpjGOrJlAap DfWA== X-Received: by 10.194.63.172 with SMTP id h12mr82246002wjs.48.1427893392416; Wed, 01 Apr 2015 06:03:12 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id a10sm2645047wjy.0.2015.04.01.06.03.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 06:03:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_18C96E35-0B87-41B3-B929-E5973FDC4B72" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Wed, 1 Apr 2015 16:03:09 +0300 Message-Id: References: <349AF075-CD98-4BC1-9316-60364E28011A@gmail.com> <5514D71B.5070206@aist.go.jp> <55157AAB.30508@gmail.com> <03BCD0E7-0550-47EB-852E-9F5E20D32954@netzkonform.de> <688820D9-D02D-428A-86C3-7429D7727C00@netzkonform.de> <59778922-72D2-42C1-9DE4-1703E9BD72AB@gmail.com> <2F8A2498-6C3D-45F1-AF28-F7D1E67FC715@netzkonform.de> <594726DE-0C87-464D-9CD7-94BA00B43450@gmail.com> <1905F537-BBC0-4EF6-AA85-F874BA5D292F@gmail.com> <1C678126-8B1F-4E12-B74A-E5CD79BAD3CB@gmail.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - A1 with Salted Hash 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, 01 Apr 2015 13:03:15 -0000 --Apple-Mail=_18C96E35-0B87-41B3-B929-E5973FDC4B72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Or, they could keep two versions of the database, one that works with = the old Digest, and another that works with MutualAuth. I just don=92t see the advantage in having a slight improvement to = Digest that requires as much effort and disruption as rolling out a more = modern authentication scheme. Yoav > On Apr 1, 2015, at 3:23 PM, Rifaat Shekh-Yusef = wrote: >=20 > For the *transition period*, where the system wants to support both = salted and non-salted clients, the server could store both the salted = password and the non-salted password. >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Tue, Mar 31, 2015 at 3:54 PM, Yoav Nir > wrote: > The difference is that to use a salted hash, you need a salted = database. Once the database is salted, you can=92t use plain digest. = This means that your server cannot support both old and new clients. = It=92s either a salted database and new clients, or an unsalted database = and both kinds of clients, but no salt. There is no smooth transition. >=20 > Yoav >=20 >> On Mar 31, 2015, at 9:27 PM, Rifaat Shekh-Yusef = > wrote: >>=20 >> Yoav, >>=20 >> To take advantage of any of the new functionalities defined in this = draft you need new software in the client and the server. >> How is salted hash any different? >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> On Mon, Mar 30, 2015 at 1:15 PM, Yoav Nir > wrote: >>=20 >> > On Mar 30, 2015, at 6:01 PM, Rifaat Shekh-Yusef = > wrote: >> > >> > Yoav, >> > >> > This would be addressed by indicating that the algorithms in the = registry might have a salted variant, similar to the -sess variant. >> > Existing clients will always select non-salted variants, while new = clients should be able to select salted variants if they support it. >>=20 >> Sure, but -sess variants have been there since forever. =93-salt=94 = would require a new client and a new server, and a server can=92t = support both =93-salt=94 and non-=93-salt=94 (because if the database is = salted, you can do Basic, but you can=92t do regular Digest). >>=20 >> So if the database requires a new client and new software on the = server, we might as well choose something more modern than Digest. >>=20 >> Yoav >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_18C96E35-0B87-41B3-B929-E5973FDC4B72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Or, they could keep two versions of the database, one that = works with the old Digest, and another that works with MutualAuth.

I just don=92t see the = advantage in having a slight improvement to Digest that requires as much = effort and disruption as rolling out a more modern authentication = scheme.

Yoav

On Apr 1, 2015, at 3:23 PM, = Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

For the *transition period*, where the system wants to = support both salted and non-salted clients, the server could store both = the salted password and the non-salted password.

Regards,
 Rifaat



On Tue, = Mar 31, 2015 at 3:54 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
The difference is that to use = a salted hash, you need a salted database. Once the database is salted, = you can=92t use plain digest. This means that your server cannot support = both old and new clients. It=92s either a salted database and new = clients, or an unsalted database and both kinds of clients, but no salt. = There is no smooth transition.

Yoav

On Mar 31, 2015, at 9:27 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Yoav,

To take advantage of any of the new = functionalities defined in this draft you need new software in the = client and the server.
How is salted hash any = different?

Regards,
 Rifaat


On Mon, Mar 30, 2015 at 1:15 PM, = Yoav Nir <ynir.ietf@gmail.com> wrote:

> On Mar 30, 2015, at 6:01 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
>
> Yoav,
>
> This would be addressed by indicating that the algorithms in the = registry might have a salted variant, similar to the -sess variant.
> Existing clients will always select non-salted variants, while new = clients should be able to select salted variants if they support it.

Sure, but -sess variants have been there since forever. =93-salt=94= would require a new client and a new server, and a server can=92t = support both =93-salt=94 and non-=93-salt=94 (because if the database is = salted, you can do Basic, but you can=92t do regular Digest).

So if the database requires a new client and new software on the server, = we might as well choose something more modern than Digest.

Yoav






= --Apple-Mail=_18C96E35-0B87-41B3-B929-E5973FDC4B72-- From nobody Wed Apr 1 12:05:37 2015 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 6117D1A88A7; Wed, 1 Apr 2015 12:05:36 -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] 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 C6zlUpkmAiLy; Wed, 1 Apr 2015 12:05:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3868B1A88B6; Wed, 1 Apr 2015 12:05:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150401190530.18413.50068.idtracker@ietfa.amsl.com> Date: Wed, 01 Apr 2015 12:05:30 -0700 From: IETF Secretariat Archived-At: Subject: [http-auth] ID Tracker State Update Notice: 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: Wed, 01 Apr 2015 19:05:36 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ From nobody Wed Apr 1 13:15:59 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8CA761A8827; Wed, 1 Apr 2015 11:45:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBF01A8826 for ; Wed, 1 Apr 2015 11:45:29 -0700 (PDT) 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, MISSING_HEADERS=1.021] 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 P538q5lPCODN for ; Wed, 1 Apr 2015 11:45:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7CA1A8821 for ; Wed, 1 Apr 2015 11:45:28 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:39530 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdNdn-0007qj-J7 for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 01 Apr 2015 11:45:27 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t31IjL0P025584; Wed, 1 Apr 2015 18:45:21 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id BE3D5C207B6; Wed, 1 Apr 2015 18:45:21 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814285 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 01 Apr 2015 18:45:21 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150401184528.1C7CA1A8821@ietfa.amsl.com> Resent-Date: Wed, 1 Apr 2015 11:45:28 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 13:15:57 -0700 Cc: draft-ietf-httpauth-digest.all@tools.ietf.org, iesg@ietf.org Subject: [http-auth] [IANA #814285] Last Call: (HTTP Digest Access Authentication) to Proposed Standard X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:45:29 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-httpauth-digest-15. Please see the review below and report any inaccuracies as soon as possible. IANA's reviewer has a question about the action requested in the IANA Considerations section of this document. QUESTION: Where should the new registry be located? Should it be created at a new URL? If so, should it be listed under an existing category at http://www.iana.org/protocols, or a new one? If the latter, what should be the name of the category? Should the webpage have the same title? (This is typically, but not always, the case.) IANA understands that, upon approval of this document, there are two actions which IANA must complete. First, IANA will create the HTTP Digest Hash Algorithms registry at a location to be determined (see above). The registry will be maintained via the Specification Required policy defined in RFC 5226. Initial registrations: +----------------+-------------+----------------+ | Hash Algorithm | Digest Size | Reference | +----------------+-------------+----------------+ | MD5 | 128 | [ RFC-to-be ] | | SHA-512-256 | 256 | [ RFC-to-be ] | | SHA-256 | 256 | [ RFC-to-be ] | +----------------+-------------+----------------+ Second, in the HTTP Authentication Schemes registry at https://www.iana.org/assignments/http-authschemes/ a new scheme will be registered as follows: Authentication Scheme Name: Digest Reference: [ RFC-to-be ] Notes: Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Amanda Baber IANA Request Specialist ICANN (END IANA LAST CALL COMMENTS) On Thu Mar 19 20:15:43 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Hypertext Transfer Protocol > Authentication WG (httpauth) to consider the following document: > - 'HTTP Digest Access Authentication' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-04-02. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that can be used with the HTTP > authentication mechanism. > > Editorial Note (To be removed by RFC Editor before publication) > > Discussion of this draft takes place on the HTTPAuth working group > mailing list (http-auth@ietf.org), which is archived at [1]. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Wed Apr 1 13:16:00 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BB4A01A8A5E; Wed, 1 Apr 2015 12:47:02 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9599F1A88A1 for ; Wed, 1 Apr 2015 12:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 T8MQ4_ZFr_oS for ; Wed, 1 Apr 2015 12:47:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5181A8A10 for ; Wed, 1 Apr 2015 12:46:57 -0700 (PDT) Received: from mail-ob0-x22a.google.com ([2607:f8b0:4003:c01::22a]:34499) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdObI-00046v-Mi for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 01 Apr 2015 12:46:57 -0700 Received: by obbgh1 with SMTP id gh1so90596099obb.1 for ; Wed, 01 Apr 2015 12:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XGrCKL2EAQSpGHtqNtyZ17nUL7RFSs5g1WhMl5gE8A8=; b=qqA8iKiQ9xzGS86mQGzWu3NKwUFXj6YqLL9Mg56FK3vgDWqyrXYOt2fM3M55Yzp4Fg a2AJ5OgsPndjebhhiqyEezQH1rltwxwgnfdNyLJuiNe2N3GZgWkLhzn7ubhqstW+Gy8F FtXb1B+YG27H21DMeKMJvN0+lB1GQUFRVfg+676H1UK/Rid+KRH7pFLvVywdA7QT/OO6 sTXN5KgOCgkWVCEaXoQINQQTzQG9WGXd+iwt6JDkGrDzXinbgUixHeWnrZRghcr/ttRU QCT3fobWfcNKr5bZfT7AGPCXq97fCArf099Tbsm924OsuDkJ8S449ou73SPwDb8T0BA1 MP8A== MIME-Version: 1.0 X-Received: by 10.182.227.132 with SMTP id sa4mr42836397obc.40.1427917609462; Wed, 01 Apr 2015 12:46:49 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Wed, 1 Apr 2015 12:46:49 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Wed, 1 Apr 2015 15:46:49 -0400 Message-ID: From: Rifaat Shekh-Yusef To: drafts-lastcall@iana.org Content-Type: multipart/alternative; boundary=001a11c2ee9ee172f70512aef961 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::22a X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150401194700.CA5181A8A10@ietfa.amsl.com> Resent-Date: Wed, 1 Apr 2015 12:46:57 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 13:15:58 -0700 Cc: draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG Subject: Re: [http-auth] [IANA #814285] Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 01 Apr 2015 19:47:02 -0000 --001a11c2ee9ee172f70512aef961 Content-Type: text/plain; charset=ISO-8859-1 Please, see inline for my opinion on what should be done with the registry, but I would like to hear what others, with more experience with this, have to say about it. On Wed, Apr 1, 2015 at 2:45 PM, Amanda Baber via RT < drafts-lastcall@iana.org> wrote: > (BEGIN IANA LAST CALL COMMENTS) > > IESG/Authors/WG Chairs: > > IANA has reviewed draft-ietf-httpauth-digest-15. Please see the review > below and report any inaccuracies as soon as possible. > > IANA's reviewer has a question about the action requested in the IANA > Considerations section of this document. > > QUESTION: Where should the new registry be located? Should it be created > at a new URL? I think new URL is needed. > If so, should it be listed under an existing category at > http://www.iana.org/protocols, or a new one? I think new category is needed; I could not find a category close enough to cover what we want with this registry. > If the latter, what should be the name of the category? "HTTP Digest Hash Algorithms" > Should the webpage have the same title? (This is typically, but not > always, the case.) > > Yes. > IANA understands that, upon approval of this document, there are two > actions which IANA must complete. > > First, IANA will create the HTTP Digest Hash Algorithms registry at a > location to be determined (see above). The registry will be maintained via > the Specification Required policy defined in RFC 5226. > > Initial registrations: > > +----------------+-------------+----------------+ > | Hash Algorithm | Digest Size | Reference | > +----------------+-------------+----------------+ > | MD5 | 128 | [ RFC-to-be ] | > | SHA-512-256 | 256 | [ RFC-to-be ] | > | SHA-256 | 256 | [ RFC-to-be ] | > +----------------+-------------+----------------+ > > Second, in the HTTP Authentication Schemes registry at > > https://www.iana.org/assignments/http-authschemes/ > > a new scheme will be registered as follows: > > There is already an existing entry for Digest, so I think the action here is just to point to the new RFC-to-be. Regards, Rifaat > Authentication Scheme Name: Digest > Reference: [ RFC-to-be ] > Notes: > > Note: The actions requested in this document will not be completed until > the document has been approved for publication as an RFC. This message is > only to confirm what actions will be performed. > > Thanks, > > Amanda Baber > IANA Request Specialist > ICANN > > (END IANA LAST CALL COMMENTS) > > > On Thu Mar 19 20:15:43 2015, iesg-secretary@ietf.org wrote: > > > > The IESG has received a request from the Hypertext Transfer Protocol > > Authentication WG (httpauth) to consider the following document: > > - 'HTTP Digest Access Authentication' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2015-04-02. Exceptionally, comments may > be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > HTTP provides a simple challenge-response authentication mechanism > > that may be used by a server to challenge a client request and by a > > client to provide authentication information. This document defines > > the HTTP Digest Authentication scheme that can be used with the HTTP > > authentication mechanism. > > > > Editorial Note (To be removed by RFC Editor before publication) > > > > Discussion of this draft takes place on the HTTPAuth working group > > mailing list (http-auth@ietf.org), which is archived at [1]. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > --001a11c2ee9ee172f70512aef961 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please, see inline for my opinion on what should be done w= ith the registry, but I would like to hear what others, with more experienc= e with this, have to say about it.


<= div class=3D"gmail_quote">On Wed, Apr 1, 2015 at 2:45 PM, Amanda Baber via = RT <drafts-lastcall@iana.org> wrote:
(BEGIN IANA LAST CALL COMMENTS)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpauth-digest-15.=A0 Please see the review b= elow and report any inaccuracies as soon as possible.

IANA's reviewer has a question about the action requested in the IANA C= onsiderations section of this document.

QUESTION: Where should the new registry be located? Should it be created at= a new URL?

I think new URL is needed.

=A0
If so, should it be listed = under an existing category at http://www.iana.org/protocols, or a new one?=A0

I think new category is needed; I could not find a= category close enough to cover what we want with this registry.
=
=A0
If the latter, what should be = the name of the category? 

Hash Algorithms"

=A0
Should the webpage have the same title? (This is typically, = but not always, the case.)


Yes.

=A0
IANA understands that, upon approval of this document, there are two action= s which IANA must complete.

First, IANA will create the HTTP Digest Hash Algorithms registry at a locat= ion to be determined (see above). The registry will be maintained via the S= pecification Required policy defined in RFC 5226.

Initial registrations:

+----------------+-------------+----------------+
| Hash Algorithm | Digest Size | Reference |
+----------------+-------------+----------------+
| MD5 | 128 | [ RFC-to-be ] |
| SHA-512-256 | 256 | [ RFC-to-be ] |
| SHA-256 | 256 | [ RFC-to-be ] |
+----------------+-------------+----------------+

Second, in the HTTP Authentication Schemes registry at

https://www.iana.org/assignments/http-authschemes/

a new scheme will be registered as follows:


There is already an existing entry for= Digest, so I think the action here is just to point to the new RFC-to-be.<= /div>

Regards,
=A0Rifaat

<= div>=A0
Authentication Scheme Name: Digest
Reference: [ RFC-to-be ]
Notes:

Note:=A0 The actions requested in this document will not be completed until= the document has been approved for publication as an RFC. This message is = only to confirm what actions will be performed.

Thanks,

Amanda Baber
IANA Request Specialist
ICANN

(END IANA LAST CALL COMMENTS)


On Thu Mar 19 20:15:43 2015, ies= g-secretary@ietf.org wrote:
>
> The IESG has received a request from the Hypertext Transfer Protocol > Authentication WG (httpauth) to consider the following document:
> - 'HTTP Digest Access Authentication'
>=A0 =A0<draft-ietf-httpauth-digest-15.txt> as Proposed Standard >
> The IESG plans to make a decision in the next few weeks, and solicits<= br> > final comments on this action. Please send substantive comments to the=
> ietf@ietf.org mailing lists by 20= 15-04-02. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In= either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>=A0 =A0 HTTP provides a simple challenge-response authentication mechan= ism
>=A0 =A0 that may be used by a server to challenge a client request and = by a
>=A0 =A0 client to provide authentication information.=A0 This document = defines
>=A0 =A0 the HTTP Digest Authentication scheme that can be used with the= HTTP
>=A0 =A0 authentication mechanism.
>
> Editorial Note (To be removed by RFC Editor before publication)
>
>=A0 =A0 Discussion of this draft takes place on the HTTPAuth working gr= oup
>=A0 =A0 mailing list (http-auth@i= etf.org), which is archived at [1].
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-httpauth-dig= est/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-httpa= uth-digest/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>




--001a11c2ee9ee172f70512aef961-- From nobody Wed Apr 1 13:16:02 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 574D01A8A83; Wed, 1 Apr 2015 12:58:05 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369241A8AA3 for ; Wed, 1 Apr 2015 12:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] 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 3O4C1Z0H4ofp for ; Wed, 1 Apr 2015 12:58:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A3E1A8A6D for ; Wed, 1 Apr 2015 12:58:04 -0700 (PDT) Received: from mail-ie0-x231.google.com ([2607:f8b0:4001:c03::231]:36012) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdOm3-0005iF-9Q for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 01 Apr 2015 12:58:03 -0700 Received: by iedm5 with SMTP id m5so52813063ied.3 for ; Wed, 01 Apr 2015 12:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aiU7jWwrmExtQwT7XXjqsLWaoRxUcDYB0ThM1ANV8QY=; b=H/CeW+eVGZ4Pf9RqL8PsImsuO7bb4N79pccV4usdeucNKHBIWG/IjaDtMuoiDOdVXA 8hDeLgohxy9AEm/NkGEtJEQFc/eVcB2D2ayc/1yIYPeOCT+w/R/nSIc0eXZTjONqDoVs Eoc88LidXV6tON6Z+6atuBVZdUhbYYnN/WqNPHuRQT4++rGd0HUv23Fndi8bl92d8tqd duKRgmDiAX3Aeid47bhMeOtMOsuEZFmCCK7TmRP6/se+MvcApaasrYuXo/mh99HqC5tT f62N7M+wvcQPZjvHv2nlLDZmqNMeKoT+Wo3mw18Zxc7ij+khVRpTcmxLXMjSsy92zJX+ nwjQ== MIME-Version: 1.0 X-Received: by 10.107.3.17 with SMTP id 17mr24050627iod.60.1427918276044; Wed, 01 Apr 2015 12:57:56 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Wed, 1 Apr 2015 12:57:55 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Wed, 1 Apr 2015 15:57:55 -0400 X-Google-Sender-Auth: DNpWZ_pe253_Aae2jU6H-BDHwrE Message-ID: From: Barry Leiba To: Rifaat Shekh-Yusef Content-Type: text/plain; charset=ISO-8859-1 X-SA-Exim-Connect-IP: 2607:f8b0:4001:c03::231 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: barryleiba@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150401195804.13A3E1A8A6D@ietfa.amsl.com> Resent-Date: Wed, 1 Apr 2015 12:58:04 -0700 (PDT) Resent-From: barryleiba@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 13:15:57 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG Subject: Re: [http-auth] [IANA #814285] Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 01 Apr 2015 19:58:05 -0000 >> QUESTION: Where should the new registry be located? Should it be created >> at a new URL? > > I think new URL is needed. > >> If so, should it be listed under an existing category at >> http://www.iana.org/protocols, or a new one? > > I think new category is needed; I could not find a category close enough to > cover what we want with this registry. > >> If the latter, what should be the name of the category? > > "HTTP Digest Hash Algorithms" I'm confused. Can you tell me why the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" category isn't "close enough to cover" this? And how does this registry fundamentally differ from the registry that's already there, "HTTP Digest Algorithm Values"? Barry From nobody Wed Apr 1 13:16:03 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3F8D51A9041; Wed, 1 Apr 2015 13:08:06 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5CC1A9022 for ; Wed, 1 Apr 2015 13:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 aEzjfiW5AMD5 for ; Wed, 1 Apr 2015 13:08:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E433F1A8A83 for ; Wed, 1 Apr 2015 13:08:04 -0700 (PDT) Received: from mail-ob0-x22b.google.com ([2607:f8b0:4003:c01::22b]:36242) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdOvk-0001Kx-39 for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 01 Apr 2015 13:08:04 -0700 Received: by obbec2 with SMTP id ec2so96393617obb.3 for ; Wed, 01 Apr 2015 13:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lV0FlWcatvq7VSF6Jvu2ykD6V4OytF+wNTuhl5qmOz0=; b=Z9sliYAdl54cCE2hN6AeU0fczLor7iYRElbUjlNWZykapmkHy65AVodr4Bsyio4B4b KNuWXDuBZT/DG0Rd+6O+1/aY6FwRRaKaSo5h1vSUnueGJoH4ZcuuZAJU5yWr4zIbLskh 2amXGrxhy6aThIN67gOsrPTKwRq2Zl8QK/QmC0RPztqYFdsL+xcVqybNl4+EQIM42Sh1 Nbe7g7kzzzs9ryBo9IgpTbB+ylAGty+QekXM9p2UzJ2SvNyMFK3Snf9ya4ZnZgJaXhG7 HTMPPdL8wz4F8wJ1C53ONx7PlOdTqHIVpFKZE6jNYFWTb50COh4LT7vuijXTxCVeHTgN ylbw== MIME-Version: 1.0 X-Received: by 10.182.48.231 with SMTP id p7mr10354501obn.19.1427918878208; Wed, 01 Apr 2015 13:07:58 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Wed, 1 Apr 2015 13:07:58 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Wed, 1 Apr 2015 16:07:58 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b67440080f7100512af4551 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::22b X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150401200804.E433F1A8A83@ietfa.amsl.com> Resent-Date: Wed, 1 Apr 2015 13:08:04 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 13:15:58 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG Subject: Re: [http-auth] [IANA #814285] Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 01 Apr 2015 20:08:06 -0000 --047d7b67440080f7100512af4551 Content-Type: text/plain; charset=ISO-8859-1 Hi Barry, Thanks for your response. I see two differences: the purpose is different (as defined in rfc3230), and the output is defined as base64. Regards, Rifaat On Wed, Apr 1, 2015 at 3:57 PM, Barry Leiba wrote: > >> QUESTION: Where should the new registry be located? Should it be created > >> at a new URL? > > > > I think new URL is needed. > > > >> If so, should it be listed under an existing category at > >> http://www.iana.org/protocols, or a new one? > > > > I think new category is needed; I could not find a category close enough > to > > cover what we want with this registry. > > > >> If the latter, what should be the name of the category? > > > > "HTTP Digest Hash Algorithms" > > I'm confused. Can you tell me why the "Hypertext Transfer Protocol > (HTTP) Digest Algorithm Values" category isn't "close enough to cover" > this? And how does this registry fundamentally differ from the > registry that's already there, "HTTP Digest Algorithm Values"? > > Barry > --047d7b67440080f7100512af4551 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Barry,

Thanks for your re= sponse.
I see two differences: the purpose is different (as defin= ed in rfc3230), and the output is defined as base64.

Regards,
=A0Rifaat


On Wed, Apr 1, 2015 at 3:57 PM= , Barry Leiba <barryleiba@computer.org> wrote:
>> QUESTION: Where should= the new registry be located? Should it be created
>> at a new URL?
>
> I think new URL is needed.
>
>> If so, should it be listed under an existing category at
>> http:/= /www.iana.org/protocols, or a new one?
>
> I think new category is needed; I could not find a category close enou= gh to
> cover what we want with this registry.
>
>> If the latter, what should be the name of the category?
>
> "HTTP Digest Hash Algorithms"

I'm confused.=A0 Can you tell me why the "Hypertext Transfe= r Protocol
(HTTP) Digest Algorithm Values" category isn't "close enough = to cover"
this?=A0 And how does this registry fundamentally differ from the
registry that's already there, "HTTP Digest Algorithm Values"= ?

Barry

--047d7b67440080f7100512af4551-- From nobody Wed Apr 1 13:16:04 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EC3591A906C; Wed, 1 Apr 2015 13:12:44 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76A61A8F4C for ; Wed, 1 Apr 2015 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] 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 meHxqNzehr9t for ; Wed, 1 Apr 2015 13:12:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB4A1A8825 for ; Wed, 1 Apr 2015 13:12:43 -0700 (PDT) Received: from mail-ig0-x22a.google.com ([2607:f8b0:4001:c05::22a]:38080) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdP0E-0002mY-JS for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 01 Apr 2015 13:12:43 -0700 Received: by igbqf9 with SMTP id qf9so56280469igb.1 for ; Wed, 01 Apr 2015 13:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I5vkKI3s7v5Z9uu+UHkAVuj6kI+TT0YHSlPTvmJkmsQ=; b=DgXEG4e6AHHxwnZA0kGWCtZUsa+eOOo/u0VXrtTZ1k4aD5nFoZmI1BBBmsp8EyOWFB qUfC0YLC78ONs6Ut+GmQQztRQS++hFefX91nbIY4esy+JzF1HmlGTht2ZkiHAhu2H9XQ fwivynSKfOopqU/7eQ73lgUKO1D6QXHp1ipe2hLtIuhtSGaqP4aaTzlFurThe9mW2y4m HOYppxO4dT7aUt4HuEqqIzRfd7JLbr3XR1E2Bvnb1s9aSNfXHOEvhfrYsUoEhxeV26vg WET1ze2EwsulziWjSGrlVwWl848QYXBC+KITvI/tqOeG3pKZZJheL1IgQazHlA3hMJs1 dEMA== MIME-Version: 1.0 X-Received: by 10.42.119.202 with SMTP id c10mr76240500icr.4.1427919156975; Wed, 01 Apr 2015 13:12:36 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Wed, 1 Apr 2015 13:12:36 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Wed, 1 Apr 2015 16:12:36 -0400 X-Google-Sender-Auth: XEoRi9f0B8jezxJKngnJy_MEOxY Message-ID: From: Barry Leiba To: Rifaat Shekh-Yusef Content-Type: text/plain; charset=ISO-8859-1 X-SA-Exim-Connect-IP: 2607:f8b0:4001:c05::22a X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: barryleiba@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150401201243.DBB4A1A8825@ietfa.amsl.com> Resent-Date: Wed, 1 Apr 2015 13:12:43 -0700 (PDT) Resent-From: barryleiba@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 13:15:58 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG Subject: Re: [http-auth] [IANA #814285] Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 01 Apr 2015 20:12:45 -0000 > I see two differences: the purpose is different (as defined in rfc3230), and > the output is defined as base64. That's a reason that you can't put this registry on the same page as the other, when they're both intended for HTTP Digest? b > On Wed, Apr 1, 2015 at 3:57 PM, Barry Leiba wrote: >> >> >> QUESTION: Where should the new registry be located? Should it be >> >> created >> >> at a new URL? >> > >> > I think new URL is needed. >> > >> >> If so, should it be listed under an existing category at >> >> http://www.iana.org/protocols, or a new one? >> > >> > I think new category is needed; I could not find a category close enough >> > to >> > cover what we want with this registry. >> > >> >> If the latter, what should be the name of the category? >> > >> > "HTTP Digest Hash Algorithms" >> >> I'm confused. Can you tell me why the "Hypertext Transfer Protocol >> (HTTP) Digest Algorithm Values" category isn't "close enough to cover" >> this? And how does this registry fundamentally differ from the >> registry that's already there, "HTTP Digest Algorithm Values"? >> >> Barry > > From nobody Wed Apr 1 14:22:44 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D59D61ABB1A; Wed, 1 Apr 2015 13:53:48 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60C01A9302 for ; Wed, 1 Apr 2015 13:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] 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 sFIpTtFgY7Vf for ; Wed, 1 Apr 2015 13:53:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82441A9244 for ; Wed, 1 Apr 2015 13:53:41 -0700 (PDT) Received: from mail-ig0-x230.google.com ([2607:f8b0:4001:c05::230]:37119) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdPdt-0002jb-2r for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 01 Apr 2015 13:53:41 -0700 Received: by igcxg11 with SMTP id xg11so57546820igc.0 for ; Wed, 01 Apr 2015 13:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+XYViB2EK/4/8AcTSUS1D8QNaoefA967c++L2Om6Ko0=; b=F0aD1VM54ssgNMXno24JAdp/N/T1MXe+l3eyLTGVJ55f0MkS8ToST4EJnpdd+NXEYi OTZ74m7mhEUaWHGOfLBmQYT69+gjdbjYchX/WmYpZRsV0nKjc/PXtHA5yTc7FG/u893W proZ5egmlQTwsEPiCE3zWzlJGyju6uOISO1HZViRQWan6YAPm3K5fx2ZhXCVKYTNl7l1 jl36ICBPoHx+5spNEUtLsojPhUSKAW8dYY9yRAULoT2jwJBu2tXG3JWB9reCdvNkv7XM OBi5bT5u3+RLWorA7NEnMPjq1kFW13xC3+s38T4Tr/kMtHqgIvcSAFSKQLRruq87IInx o2NQ== MIME-Version: 1.0 X-Received: by 10.50.35.195 with SMTP id k3mr15184765igj.11.1427921614811; Wed, 01 Apr 2015 13:53:34 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Wed, 1 Apr 2015 13:53:34 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Wed, 1 Apr 2015 16:53:34 -0400 X-Google-Sender-Auth: p1WzPgjrpGOWzRCoD2_WGvSTZn4 Message-ID: From: Barry Leiba To: Rifaat Shekh-Yusef Content-Type: text/plain; charset=ISO-8859-1 X-SA-Exim-Connect-IP: 2607:f8b0:4001:c05::230 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: barryleiba@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150401205341.E82441A9244@ietfa.amsl.com> Resent-Date: Wed, 1 Apr 2015 13:53:41 -0700 (PDT) Resent-From: barryleiba@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 14:22:19 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG Subject: Re: [http-auth] [IANA #814285] Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 01 Apr 2015 20:53:49 -0000 > I do not know; that is the reason I mentioned that I would like to hear the > opinion of people that have a better understanding of the registry. > I have no problem with using the same registry if that is possible and does > not cause any confusion. > > So, can you please explain how should we go about doing that? Not the same registry. The same category. How you go about doing that is by changing your answers to Pearl's questions (but then see below): >> QUESTION: Where should the new registry be located? Should it be created >> at a new URL? > > I think new URL is needed. It can go as a second registry on this URL: http://www.iana.org/assignments/http-dig-alg/ >> If so, should it be listed under an existing category at >> http://www.iana.org/protocols, or a new one? > > I think new category is needed; I could not find a category close enough to > cover what we want with this registry. It will go fine as a second registry in the existing category "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values". -- Now, the problem is that this registry is *so* similar to the existing "HTTP Digest Algorithm Values" registry that people will be confused. That's one reason I want to put them on the same page -- so it's easier to make the differences obvious. First, the existing registry is poorly named, especially considering that HTTP digest authentication existed when that registry -- which has to do with creating a hash digest of the content, not with authentication -- was created. We can't fix that now, but we can add an explanation of its purpose to the registry in order to clarify things for people who are poking around. And we can also change the name of your registry to make things clearer as well. So, I suggest the following, in addition to putting them in the same category and on the same web page: 1. Change the name of your registry to "Hash Algorithms for HTTP Digest Authentication", to make it clear that this has to do with HTTP Digest Authentication. The order of the words is important, to make sure it's clear that "Authentication" is tightly bound to "HTTP Digest" here. 2. Add a brief description to the new registry's header that says that this registry lists the hash algorithms that can be used in HTTP Digest Authentication. 3. Add a brief description to the existing "HTTP Digest Algorithm Values" registry that says that this registry lists the algorithms that can be used when creating digests of an HTTP message body, as specified in RFC 3230. I think that will adequately distinguish these two registries, and avoid confusion between them. What do you think? Barry From nobody Wed Apr 1 14:22:45 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 04A461A90A6; Wed, 1 Apr 2015 13:16:32 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5D1A906C for ; Wed, 1 Apr 2015 13:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 lsM-ac-tY94D for ; Wed, 1 Apr 2015 13:16:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06181A90A6 for ; Wed, 1 Apr 2015 13:16:30 -0700 (PDT) Received: from mail-ob0-x234.google.com ([2607:f8b0:4003:c01::234]:35106) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdP3u-0008Co-11 for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 01 Apr 2015 13:16:30 -0700 Received: by obbfy7 with SMTP id fy7so12601901obb.2 for ; Wed, 01 Apr 2015 13:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bWwpE2RO8U6oWtYR4VIJ2UrLbxHZpmJH29iR1hxI4mk=; b=MSSdtWaHrt/WkCKfZoooJ5FBxz8K1FLxbXFZBS9k+w+B1+GRqR/awxHolymalvsxZ3 /XTG2wUS60GurJdAChabgwVFzPu8Baro48JqyFcH5sTU9lprZnK8yss6rFUEu9hRiIWS tCS0W+s6A8qqcdSEYys3j05kv4v86xelswi+Tx/DaDmDS51oK5BRr7461Uklt0oWoESC 2ld/Pi25wid/XPoJ04LHj65+o7amsi9wXqo+0QEeXSNB5pnV77sjaxJB/iBuOxjScScV 2J3vM4apOkJJ2UQToM5Zv2JP3EbMbBRJid73bErmkh1Lhr4SklosrENjLye/XsuCM6AS U5ww== MIME-Version: 1.0 X-Received: by 10.60.134.199 with SMTP id pm7mr6643983oeb.36.1427919383524; Wed, 01 Apr 2015 13:16:23 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Wed, 1 Apr 2015 13:16:23 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Wed, 1 Apr 2015 16:16:23 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b41cd349f7a730512af6374 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::234 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150401201630.E06181A90A6@ietfa.amsl.com> Resent-Date: Wed, 1 Apr 2015 13:16:30 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 14:22:21 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG Subject: Re: [http-auth] [IANA #814285] Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 01 Apr 2015 20:16:33 -0000 --047d7b41cd349f7a730512af6374 Content-Type: text/plain; charset=ISO-8859-1 I do not know; that is the reason I mentioned that I would like to hear the opinion of people that have a better understanding of the registry. I have no problem with using the same registry if that is possible and does not cause any confusion. So, can you please explain how should we go about doing that? Regards, Rifaat On Wed, Apr 1, 2015 at 4:12 PM, Barry Leiba wrote: > > I see two differences: the purpose is different (as defined in rfc3230), > and > > the output is defined as base64. > > That's a reason that you can't put this registry on the same page as > the other, when they're both intended for HTTP Digest? > > b > > > > On Wed, Apr 1, 2015 at 3:57 PM, Barry Leiba > wrote: > >> > >> >> QUESTION: Where should the new registry be located? Should it be > >> >> created > >> >> at a new URL? > >> > > >> > I think new URL is needed. > >> > > >> >> If so, should it be listed under an existing category at > >> >> http://www.iana.org/protocols, or a new one? > >> > > >> > I think new category is needed; I could not find a category close > enough > >> > to > >> > cover what we want with this registry. > >> > > >> >> If the latter, what should be the name of the category? > >> > > >> > "HTTP Digest Hash Algorithms" > >> > >> I'm confused. Can you tell me why the "Hypertext Transfer Protocol > >> (HTTP) Digest Algorithm Values" category isn't "close enough to cover" > >> this? And how does this registry fundamentally differ from the > >> registry that's already there, "HTTP Digest Algorithm Values"? > >> > >> Barry > > > > > --047d7b41cd349f7a730512af6374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I do not know; that is the reason I mentioned that I would= like to hear the opinion of people that have a better understanding of the= registry.
I have no problem with using the same registry if that is po= ssible and does not cause any confusion.

So, can y= ou please explain how should we go about doing that?

Regards,
=A0Rifaat


On Wed, Apr 1, 2015 at 4:12 PM, Ba= rry Leiba <barryleiba@computer.org> wrote:
> I see two differences: the pur= pose is different (as defined in rfc3230), and
> the output is defined as base64.

That's a reason that you can't put this registry on the same= page as
the other, when they're both intended for HTTP Digest?

b


> On Wed, Apr 1, 2015 at 3:57 PM, Barry Leiba <barryleiba@computer.org> wrote:
>>
>> >> QUESTION: Where should the new registry be located? Shoul= d it be
>> >> created
>> >> at a new URL?
>> >
>> > I think new URL is needed.
>> >
>> >> If so, should it be listed under an existing category at<= br> >> >> http://www.iana.org/protocols, or a new one?
>> >
>> > I think new category is needed; I could not find a category c= lose enough
>> > to
>> > cover what we want with this registry.
>> >
>> >> If the latter, what should be the name of the category? >> >
>> > "HTTP Digest Hash Algorithms"
>>
>> I'm confused.=A0 Can you tell me why the "Hypertext Trans= fer Protocol
>> (HTTP) Digest Algorithm Values" category isn't "clos= e enough to cover"
>> this?=A0 And how does this registry fundamentally differ from the<= br> >> registry that's already there, "HTTP Digest Algorithm Val= ues"?
>>
>> Barry
>
>

--047d7b41cd349f7a730512af6374-- From nobody Wed Apr 1 14:22:46 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 149321A1AB2; Wed, 1 Apr 2015 14:20:24 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE35B1A0199 for ; Wed, 1 Apr 2015 14:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 kQfHl5TW8P9L for ; Wed, 1 Apr 2015 14:20:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AFD11A1A32 for ; Wed, 1 Apr 2015 14:20:21 -0700 (PDT) Received: from mail-ob0-x232.google.com ([2607:f8b0:4003:c01::232]:33843) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdQ3g-0003wT-1M for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 01 Apr 2015 14:20:21 -0700 Received: by obbgh1 with SMTP id gh1so94265030obb.1 for ; Wed, 01 Apr 2015 14:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p0t3jqogwt0lE4wpG+OU8FMzJesayzBHs71Yh656J5o=; b=oe/EBNbbyL+BFHX+3bxCqQN2fx9PavrOw4DM18hLQ/b3zLEZovrZr/AnDePKAOm00i CC7udGUIPNjzTAoQg4DMyqtGnaLBs8Ghxj43wGn49JUouRFCtDI1tu3xbqv33sSg0nL7 ysF0cZmeyH9H1TNDiyQwNhfZpx2IWfvvPyic5FaCXBeYi3NRJZRm5t2FfpB63mqoJCWX okbW3ymCyiX4//jF6abYjrN/qWNr3J+0Gsd/484VCq04e5jErrgO2Xx6fIXBF0E4TDNN leJlo/JseBEOVXjx5li30OCUL5cIOky05lj3Za1naqdxOXQgSfwiivpzS1eb/2upkqK3 sipg== MIME-Version: 1.0 X-Received: by 10.182.246.163 with SMTP id xx3mr43126195obc.83.1427923211977; Wed, 01 Apr 2015 14:20:11 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Wed, 1 Apr 2015 14:20:11 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Wed, 1 Apr 2015 17:20:11 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c1ee46d122870512b047fa X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::232 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150401212021.5AFD11A1A32@ietfa.amsl.com> Resent-Date: Wed, 1 Apr 2015 14:20:21 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 14:22:23 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG Subject: Re: [http-auth] [IANA #814285] Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 01 Apr 2015 21:20:24 -0000 --001a11c1ee46d122870512b047fa Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba wrote: > > I do not know; that is the reason I mentioned that I would like to hear > the > > opinion of people that have a better understanding of the registry. > > I have no problem with using the same registry if that is possible and > does > > not cause any confusion. > > > > So, can you please explain how should we go about doing that? > > Not the same registry. The same category. > Ah, that makes more sense now. > > How you go about doing that is by changing your answers to Pearl's > questions (but then see below): > > >> QUESTION: Where should the new registry be located? Should it be created > >> at a new URL? > > > > I think new URL is needed. > > It can go as a second registry on this URL: > http://www.iana.org/assignments/http-dig-alg/ > > >> If so, should it be listed under an existing category at > >> http://www.iana.org/protocols, or a new one? > > > > I think new category is needed; I could not find a category close enough > to > > cover what we want with this registry. > > It will go fine as a second registry in the existing category > "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values". > > -- > Now, the problem is that this registry is *so* similar to the existing > "HTTP Digest Algorithm Values" registry that people will be confused. > That's one reason I want to put them on the same page -- so it's > easier to make the differences obvious. > > First, the existing registry is poorly named, especially considering > that HTTP digest authentication existed when that registry -- which > has to do with creating a hash digest of the content, not with > authentication -- was created. We can't fix that now, but we can add > an explanation of its purpose to the registry in order to clarify > things for people who are poking around. > > And we can also change the name of your registry to make things > clearer as well. So, I suggest the following, in addition to putting > them in the same category and on the same web page: > > 1. Change the name of your registry to "Hash Algorithms for HTTP > Digest Authentication", to make it clear that this has to do with HTTP > Digest Authentication. The order of the words is important, to make > sure it's clear that "Authentication" is tightly bound to "HTTP > Digest" here. > > 2. Add a brief description to the new registry's header that says that > this registry lists the hash algorithms that can be used in HTTP > Digest Authentication. > > 3. Add a brief description to the existing "HTTP Digest Algorithm > Values" registry that says that this registry lists the algorithms > that can be used when creating digests of an HTTP message body, as > specified in RFC 3230. > > I think that will adequately distinguish these two registries, and > avoid confusion between them. > > What do you think? > Sounds reasonable to me. I appreciate your help with this, Barry! Regards, Rifaat > > Barry > --001a11c1ee46d122870512b047fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba <barryleiba@computer= .org> wrote:
> I do not know; that is the reason I mentioned that I would like to = hear the
> opinion of people that have a better understanding of the registry. > I have no problem with using the same registry if that is possible and= does
> not cause any confusion.
>
> So, can you please explain how should we go about doing that?

Not the same registry.=A0 The same category.
Ah, that makes more sense now.

=A0

How you go about doing that is by changing your answers to Pearl's
questions (but then see below):

>> QUESTION: Where should the new registry be located? Should it be c= reated
>> at a new URL?
>
> I think new URL is needed.

It can go as a second registry on this URL:
=A0 =A0http://www.iana.org/assignments/http-dig-alg/

>> If so, should it be listed under an existing category at
>> http:/= /www.iana.org/protocols, or a new one?
>
> I think new category is needed; I could not find a category close enou= gh to
> cover what we want with this registry.

It will go fine as a second registry in the existing category
"Hypertext Transfer Protocol (HTTP) Digest Algorithm Values".

--
Now, the problem is that this registry is *so* similar to the existing
"HTTP Digest Algorithm Values" registry that people will be confu= sed.
That's one reason I want to put them on the same page -- so it's easier to make the differences obvious.

First, the existing registry is poorly named, especially considering
that HTTP digest authentication existed when that registry -- which
has to do with creating a hash digest of the content, not with
authentication -- was created.=A0 We can't fix that now, but we can add=
an explanation of its purpose to the registry in order to clarify
things for people who are poking around.

And we can also change the name of your registry to make things
clearer as well.=A0 So, I suggest the following, in addition to putting
them in the same category and on the same web page:

1. Change the name of your registry to "Hash Algorithms for HTTP
Digest Authentication", to make it clear that this has to do with HTTP=
Digest Authentication.=A0 The order of the words is important, to make
sure it's clear that "Authentication" is tightly bound to &qu= ot;HTTP
Digest" here.

2. Add a brief description to the new registry's header that says that<= br> this registry lists the hash algorithms that can be used in HTTP
Digest Authentication.

3. Add a brief description to the existing "HTTP Digest Algorithm
Values" registry that says that this registry lists the algorithms
that can be used when creating digests of an HTTP message body, as
specified in RFC 3230.

I think that will adequately distinguish these two registries, and
avoid confusion between them.

What do you think?

Sounds reasonable to= me.=A0

I appreciate your help with this, Barry!

Regards,
=A0Rifaat

=A0

Barry

--001a11c1ee46d122870512b047fa-- From nobody Thu Apr 2 00:09:10 2015 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 24CF51B2B8E; Thu, 2 Apr 2015 00:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 akOZOWkggeCb; Thu, 2 Apr 2015 00:09:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 166D41B2B7B; Thu, 2 Apr 2015 00:08:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150402070858.6894.56835.idtracker@ietfa.amsl.com> Date: Thu, 02 Apr 2015 00:08:58 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [http-auth] Last Call Expired: 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: Thu, 02 Apr 2015 07:09:02 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Apr 2 00:31:08 2015 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 A48A41B2B97; Thu, 2 Apr 2015 00:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 LXvIzDLfbgbu; Thu, 2 Apr 2015 00:31:06 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86A01B2B89; Thu, 2 Apr 2015 00:31:02 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so94686887wib.1; Thu, 02 Apr 2015 00:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KEDh+EC8taBo2T7rLwfe/6IXKVNZygtiZnIMQYHa9Xw=; b=LBMotkh6Q8ItgcGyluILSBMq1eA2rMQhkdNn+vJnudu5p2YgdoIEhIZjXoz3PjibS7 w/djqdmiJd9ej38V3xMKzVIEPDIJhap/mqjOBDxtNWw9Q1aJnjuWe1JthKchJlzCnOcB 10mdmkqKWHHNg6AOCVefF2WmjC6b2FgTPac2xWfMa/PRCyYK9C9gFizRlfNXVlB7rwGg An/QkJRZu+qsCxRaplHaahyD2TzI1637cHtTRYlfybjqRLZueF1OzCQDrMMjK3DYiP/i JmhpKFLWXqT9/VFjh2bF4P3Ia9kCnwscudrHZO0916ULG6OH2lApoiBLXGtVrdFRPSdS 7WJw== X-Received: by 10.194.122.196 with SMTP id lu4mr91874079wjb.154.1427959861616; Thu, 02 Apr 2015 00:31:01 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id lx10sm5972608wjb.17.2015.04.02.00.31.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 00:31:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <20150402070858.6894.56835.idtracker@ietfa.amsl.com> Date: Thu, 2 Apr 2015 10:30:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5CE14E57-A401-4D6F-BA3F-D1C37FAF50F9@gmail.com> References: <20150402070858.6894.56835.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: httpauth mailing list , draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Last Call Expired: 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: Thu, 02 Apr 2015 07:31:07 -0000 Hi, Kathleen The only responses I=E2=80=99ve seen to this IETF last call was the = thread that stemmed from Rifaat=E2=80=99s idea from the TRAM working = group to add a salt to Digest. I don=E2=80=99t think there is consensus in the group to pull the = document back into the working group and add this parameter, so IMO the = document can proceed as is. Thanks Yoav=20 (with document shepherd and WG chair hat on) > On Apr 2, 2015, at 10:08 AM, DraftTracker Mail System = wrote: >=20 >=20 > Please DO NOT reply to this email. >=20 > I-D: > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >=20 > IETF Last Call has ended, and the state has been changed to > Waiting for AD Go-Ahead. >=20 From nobody Fri Apr 3 11:45:11 2015 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 96F001AD01E; Fri, 3 Apr 2015 11:45:08 -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] 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 SpFLmZCc11nr; Fri, 3 Apr 2015 11:45:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE011ACF18; Fri, 3 Apr 2015 11:45:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150403184507.31435.40509.idtracker@ietfa.amsl.com> Date: Fri, 03 Apr 2015 11:45:07 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-16.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: Fri, 03 Apr 2015 18:45:08 -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 : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-16.txt Pages : 30 Date : 2015-04-03 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPAuth working group mailing list (http-auth@ietf.org), which is archived at [1]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-16 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 Fri Apr 3 11:45:13 2015 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 5B48F1ACF58; Fri, 3 Apr 2015 11:45:10 -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] 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 VKZyL447NBD0; Fri, 3 Apr 2015 11:45:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BC01ACF5B; Fri, 3 Apr 2015 11:45:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150403184507.31435.41468.idtracker@ietfa.amsl.com> Date: Fri, 03 Apr 2015 11:45:07 -0700 Archived-At: Subject: [http-auth] New Version Notification - draft-ietf-httpauth-digest-16.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: Fri, 03 Apr 2015 18:45:10 -0000 A new version (-16) has been submitted for draft-ietf-httpauth-digest: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-digest-16.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-16 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. IETF Secretariat. From nobody Fri Apr 3 20:09:35 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EF8001A8835; Fri, 3 Apr 2015 04:07:02 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0DD1A8823 for ; Fri, 3 Apr 2015 04:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 n9XYe9t9hWwW for ; Fri, 3 Apr 2015 04:07:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6761A8826 for ; Fri, 3 Apr 2015 04:07:00 -0700 (PDT) Received: from mail-ob0-x22e.google.com ([2607:f8b0:4003:c01::22e]:32835) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdzR4-0006h2-Ca for draft-ietf-httpauth-digest.all@tools.ietf.org; Fri, 03 Apr 2015 04:06:59 -0700 Received: by obvd1 with SMTP id d1so167771946obv.0 for ; Fri, 03 Apr 2015 04:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=elcxg2X75+eGpUi5aSphbdJMXTApIMwtkvyi/k3bvzM=; b=IDzyfDiAfXvjPYkEM8iNKccoqq+4seIww29dBlJpmIUAOK0NuqiQ/f9y6f6CjpEakf lXIhYdllDdjTJFSuCKaFMDnbJ+eOn+XJS+XLjoM0UvSEwRnJgn5ImAotgOFFLMGJJ/nA P+AKE0XI7uejyYs+xgApxB81BmBFiPTlJieCdCQzaSGyb66zOlmzgie46lcL0BrP9Ffj nFZydipxG7iUhpu0eS9nRdhZ1nZX1Sn2ztbdxDZXhytUj0+PiETgkJzF3CQsqx9SHMl8 8PIKEyM8xl79L1b3SDE5GJOu13shPKC2EUljHWKrr1C2zL5kLVtAsLOtFnbzeVr2iUcP 52AQ== MIME-Version: 1.0 X-Received: by 10.60.131.37 with SMTP id oj5mr2267840oeb.77.1428059202599; Fri, 03 Apr 2015 04:06:42 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Fri, 3 Apr 2015 04:06:42 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Fri, 3 Apr 2015 07:06:42 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Barry Leiba Content-Type: multipart/alternative; boundary=089e013cb9cc7d403f0512cff19f X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::22e X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150403110700.AF6761A8826@ietfa.amsl.com> Resent-Date: Fri, 3 Apr 2015 04:07:00 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 20:09:31 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG Subject: Re: [http-auth] [IANA #814285] Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 03 Apr 2015 11:07:03 -0000 --089e013cb9cc7d403f0512cff19f Content-Type: text/plain; charset=ISO-8859-1 Pearl, Does this address all of your questions? Thanks, Rifaat On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef wrote: > > > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba > wrote: > >> > I do not know; that is the reason I mentioned that I would like to hear >> the >> > opinion of people that have a better understanding of the registry. >> > I have no problem with using the same registry if that is possible and >> does >> > not cause any confusion. >> > >> > So, can you please explain how should we go about doing that? >> >> Not the same registry. The same category. >> > > Ah, that makes more sense now. > > > >> >> How you go about doing that is by changing your answers to Pearl's >> questions (but then see below): >> >> >> QUESTION: Where should the new registry be located? Should it be >> created >> >> at a new URL? >> > >> > I think new URL is needed. >> >> It can go as a second registry on this URL: >> http://www.iana.org/assignments/http-dig-alg/ >> >> >> If so, should it be listed under an existing category at >> >> http://www.iana.org/protocols, or a new one? >> > >> > I think new category is needed; I could not find a category close >> enough to >> > cover what we want with this registry. >> >> It will go fine as a second registry in the existing category >> "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values". >> >> -- >> Now, the problem is that this registry is *so* similar to the existing >> "HTTP Digest Algorithm Values" registry that people will be confused. >> That's one reason I want to put them on the same page -- so it's >> easier to make the differences obvious. >> >> First, the existing registry is poorly named, especially considering >> that HTTP digest authentication existed when that registry -- which >> has to do with creating a hash digest of the content, not with >> authentication -- was created. We can't fix that now, but we can add >> an explanation of its purpose to the registry in order to clarify >> things for people who are poking around. >> >> And we can also change the name of your registry to make things >> clearer as well. So, I suggest the following, in addition to putting >> them in the same category and on the same web page: >> >> 1. Change the name of your registry to "Hash Algorithms for HTTP >> Digest Authentication", to make it clear that this has to do with HTTP >> Digest Authentication. The order of the words is important, to make >> sure it's clear that "Authentication" is tightly bound to "HTTP >> Digest" here. >> >> 2. Add a brief description to the new registry's header that says that >> this registry lists the hash algorithms that can be used in HTTP >> Digest Authentication. >> >> 3. Add a brief description to the existing "HTTP Digest Algorithm >> Values" registry that says that this registry lists the algorithms >> that can be used when creating digests of an HTTP message body, as >> specified in RFC 3230. >> >> I think that will adequately distinguish these two registries, and >> avoid confusion between them. >> >> What do you think? >> > > Sounds reasonable to me. > > I appreciate your help with this, Barry! > > Regards, > Rifaat > > > >> >> Barry >> > > --089e013cb9cc7d403f0512cff19f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Pearl,

Does this address all of your qu= estions?

Thanks,
=A0Rifaat

On Wed, Apr 1, 2= 015 at 5:20 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:


On Wed, Ap= r 1, 2015 at 4:53 PM, Barry Leiba <barryleiba@computer.org> wrote:
> I do not know; th= at is the reason I mentioned that I would like to hear the
> opinion of people that have a better understanding of the registry. > I have no problem with using the same registry if that is possible and= does
> not cause any confusion.
>
> So, can you please explain how should we go about doing that?

Not the same registry.=A0 The same category.
Ah, that makes more sense now.

=A0

How you go about doing that is by changing your answers to Pearl's
questions (but then see below):

>> QUESTION: Where should the new registry be located? Should it be c= reated
>> at a new URL?
>
> I think new URL is needed.

It can go as a second registry on this URL:
=A0 =A0http://www.iana.org/assignments/http-dig-alg/

>> If so, should it be listed under an existing category at
>> http:/= /www.iana.org/protocols, or a new one?
>
> I think new category is needed; I could not find a category close enou= gh to
> cover what we want with this registry.

It will go fine as a second registry in the existing category
"Hypertext Transfer Protocol (HTTP) Digest Algorithm Values".

--
Now, the problem is that this registry is *so* similar to the existing
"HTTP Digest Algorithm Values" registry that people will be confu= sed.
That's one reason I want to put them on the same page -- so it's easier to make the differences obvious.

First, the existing registry is poorly named, especially considering
that HTTP digest authentication existed when that registry -- which
has to do with creating a hash digest of the content, not with
authentication -- was created.=A0 We can't fix that now, but we can add=
an explanation of its purpose to the registry in order to clarify
things for people who are poking around.

And we can also change the name of your registry to make things
clearer as well.=A0 So, I suggest the following, in addition to putting
them in the same category and on the same web page:

1. Change the name of your registry to "Hash Algorithms for HTTP
Digest Authentication", to make it clear that this has to do with HTTP=
Digest Authentication.=A0 The order of the words is important, to make
sure it's clear that "Authentication" is tightly bound to &qu= ot;HTTP
Digest" here.

2. Add a brief description to the new registry's header that says that<= br> this registry lists the hash algorithms that can be used in HTTP
Digest Authentication.

3. Add a brief description to the existing "HTTP Digest Algorithm
Values" registry that says that this registry lists the algorithms
that can be used when creating digests of an HTTP message body, as
specified in RFC 3230.

I think that will adequately distinguish these two registries, and
avoid confusion between them.

What do you think?

Sounds r= easonable to me.=A0

I appreciate your help with th= is, Barry!

Regards,
=A0Rifaat
=
=A0

Barry


--089e013cb9cc7d403f0512cff19f-- From nobody Fri Apr 3 20:09:36 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F014F1ACD53; Fri, 3 Apr 2015 09:40:04 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDD51ACD50 for ; Fri, 3 Apr 2015 09:40:04 -0700 (PDT) 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, MISSING_HEADERS=1.021] 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 T4Z_7ez47s62 for ; Fri, 3 Apr 2015 09:40:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE421ACD2E for ; Fri, 3 Apr 2015 09:40:03 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:37854 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ye4dW-0002wQ-AL for draft-ietf-httpauth-digest.all@tools.ietf.org; Fri, 03 Apr 2015 09:40:03 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t33GdXpK020355; Fri, 3 Apr 2015 16:39:33 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 984D5C2081D; Fri, 3 Apr 2015 16:39:33 +0000 (UTC) RT-Owner: Nobody From: "Pearl Liang via RT" In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #817019 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 03 Apr 2015 16:39:33 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150403164003.4BE421ACD2E@ietfa.amsl.com> Resent-Date: Fri, 3 Apr 2015 09:40:03 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 20:09:30 -0700 Cc: liang@icann.org, draft-ietf-httpauth-digest.all@tools.ietf.org, iesg@ietf.org, barryleiba@computer.org Subject: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 16:40:05 -0000 Rifaat, On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote: > Pearl, > > Does this address all of your questions? > Are you planning to submit a new version to include Barry's suggested revisions? I however have a new question. If it has been addressed, apologies in advance. It is about section 6.2 for the Digest scheme. Are you intended to replace the existing reference 'RFC2617 section 3' with this draft for the existing entry 'Digest'? If so, the current text in section 6.2 is unclear or inaccurate: /snip/ 6.2. Digest Scheme Registration This specification registers the Digest scheme with the Authentication Scheme Registry. /snip/ Thanks, ~pl Pearl Liang ICANN > Thanks, > Rifaat > > > On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef > wrote: > > > > > > > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba > > wrote: > > > >> > I do not know; that is the reason I mentioned that I would like to hear > >> the > >> > opinion of people that have a better understanding of the registry. > >> > I have no problem with using the same registry if that is possible and > >> does > >> > not cause any confusion. > >> > > >> > So, can you please explain how should we go about doing that? > >> > >> Not the same registry. The same category. > >> > > > > Ah, that makes more sense now. > > > > > > > >> > >> How you go about doing that is by changing your answers to Pearl's > >> questions (but then see below): > >> > >> >> QUESTION: Where should the new registry be located? Should it be > >> created > >> >> at a new URL? > >> > > >> > I think new URL is needed. > >> > >> It can go as a second registry on this URL: > >> http://www.iana.org/assignments/http-dig-alg/ > >> > >> >> If so, should it be listed under an existing category at > >> >> http://www.iana.org/protocols, or a new one? > >> > > >> > I think new category is needed; I could not find a category close > >> enough to > >> > cover what we want with this registry. > >> > >> It will go fine as a second registry in the existing category > >> "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values". > >> > >> -- > >> Now, the problem is that this registry is *so* similar to the existing > >> "HTTP Digest Algorithm Values" registry that people will be confused. > >> That's one reason I want to put them on the same page -- so it's > >> easier to make the differences obvious. > >> > >> First, the existing registry is poorly named, especially considering > >> that HTTP digest authentication existed when that registry -- which > >> has to do with creating a hash digest of the content, not with > >> authentication -- was created. We can't fix that now, but we can add > >> an explanation of its purpose to the registry in order to clarify > >> things for people who are poking around. > >> > >> And we can also change the name of your registry to make things > >> clearer as well. So, I suggest the following, in addition to putting > >> them in the same category and on the same web page: > >> > >> 1. Change the name of your registry to "Hash Algorithms for HTTP > >> Digest Authentication", to make it clear that this has to do with HTTP > >> Digest Authentication. The order of the words is important, to make > >> sure it's clear that "Authentication" is tightly bound to "HTTP > >> Digest" here. > >> > >> 2. Add a brief description to the new registry's header that says that > >> this registry lists the hash algorithms that can be used in HTTP > >> Digest Authentication. > >> > >> 3. Add a brief description to the existing "HTTP Digest Algorithm > >> Values" registry that says that this registry lists the algorithms > >> that can be used when creating digests of an HTTP message body, as > >> specified in RFC 3230. > >> > >> I think that will adequately distinguish these two registries, and > >> avoid confusion between them. > >> > >> What do you think? > >> > > > > Sounds reasonable to me. > > > > I appreciate your help with this, Barry! > > > > Regards, > > Rifaat > > > > > > > >> > >> Barry > >> > > > > From nobody Fri Apr 3 20:09:38 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BEDF41AD06A; Fri, 3 Apr 2015 11:51:15 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD3A1AD049 for ; Fri, 3 Apr 2015 11:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 gvoEInppcowC for ; Fri, 3 Apr 2015 11:51:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBFD1AD068 for ; Fri, 3 Apr 2015 11:51:10 -0700 (PDT) Received: from mail-ob0-x236.google.com ([2607:f8b0:4003:c01::236]:35104) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ye6gO-0002tx-D0 for draft-ietf-httpauth-digest.all@tools.ietf.org; Fri, 03 Apr 2015 11:51:10 -0700 Received: by obbfy7 with SMTP id fy7so96135562obb.2 for ; Fri, 03 Apr 2015 11:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ftjNEFBjv73p8rnnXc8G47IugAkj48Mv5iU1z38fZE=; b=GUi/j9GMpImmaUx2LFikR9gFJjZFGwHL+Wul2gSUP31ppImdqOjbJKZn7k4AY0IPSy tVuHwgG/xCYuETqm3zS8pIJhakUVaGBa1Ua//o/7ZZjK8iVRvM9v/aqZNmwghZAUzlnp aITbyjGJBB3rDZ5NPHiApWk8jl/zYq42cqkpPl/8Rmq1dhpKtz4Q5SIxbuQB3JEofpZT CR3NYJNKUe0AiWyCvsX0jHx6exLTuii0GEbOK6ZAcgIKcik3a07touQflWKZbT4Cqq0c KBTX7IfwpVjvELIXSxh+nuOvUlB/PaV4JRdaaGozEE+ZNY+vz0P9077X2JS7f3ZYL8Y/ gbbQ== MIME-Version: 1.0 X-Received: by 10.182.48.231 with SMTP id p7mr4480651obn.19.1428087062077; Fri, 03 Apr 2015 11:51:02 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Fri, 3 Apr 2015 11:51:01 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Fri, 3 Apr 2015 14:51:01 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Pearl Liang via RT Content-Type: multipart/alternative; boundary=047d7b6744000b24b30512d66e14 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::236 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150403185110.8DBFD1AD068@ietfa.amsl.com> Resent-Date: Fri, 3 Apr 2015 11:51:10 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 20:09:31 -0700 Cc: draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG , Barry Leiba , liang@icann.org Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 03 Apr 2015 18:51:15 -0000 --047d7b6744000b24b30512d66e14 Content-Type: text/plain; charset=ISO-8859-1 Hi Pearl, I have just submitted a new version, v16, that addresses both kathleen's comment and Barry's suggestions. I also adjusted the text in section 6.2 to indicate that we should only update the registry. Please, let me know if you have any further comments. Regards, Rifaat On Fri, Apr 3, 2015 at 12:39 PM, Pearl Liang via RT < drafts-lastcall@iana.org> wrote: > Rifaat, > > > On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote: > > Pearl, > > > > Does this address all of your questions? > > > > Are you planning to submit a new version to include Barry's suggested > revisions? > > I however have a new question. If it has been addressed, apologies in > advance. > It is about section 6.2 for the Digest scheme. Are you intended to replace > the existing reference 'RFC2617 section 3' with this draft for the > existing entry > 'Digest'? If so, the current text in section 6.2 is unclear or inaccurate: > > /snip/ > 6.2. Digest Scheme Registration > > This specification registers the Digest scheme with the > Authentication Scheme Registry. > > /snip/ > > Thanks, > ~pl > > Pearl Liang > ICANN > > > > > > > Thanks, > > Rifaat > > > > > > On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com> > > wrote: > > > > > > > > > > > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba > > > wrote: > > > > > >> > I do not know; that is the reason I mentioned that I would like to > hear > > >> the > > >> > opinion of people that have a better understanding of the registry. > > >> > I have no problem with using the same registry if that is possible > and > > >> does > > >> > not cause any confusion. > > >> > > > >> > So, can you please explain how should we go about doing that? > > >> > > >> Not the same registry. The same category. > > >> > > > > > > Ah, that makes more sense now. > > > > > > > > > > > >> > > >> How you go about doing that is by changing your answers to Pearl's > > >> questions (but then see below): > > >> > > >> >> QUESTION: Where should the new registry be located? Should it be > > >> created > > >> >> at a new URL? > > >> > > > >> > I think new URL is needed. > > >> > > >> It can go as a second registry on this URL: > > >> http://www.iana.org/assignments/http-dig-alg/ > > >> > > >> >> If so, should it be listed under an existing category at > > >> >> http://www.iana.org/protocols, or a new one? > > >> > > > >> > I think new category is needed; I could not find a category close > > >> enough to > > >> > cover what we want with this registry. > > >> > > >> It will go fine as a second registry in the existing category > > >> "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values". > > >> > > >> -- > > >> Now, the problem is that this registry is *so* similar to the existing > > >> "HTTP Digest Algorithm Values" registry that people will be confused. > > >> That's one reason I want to put them on the same page -- so it's > > >> easier to make the differences obvious. > > >> > > >> First, the existing registry is poorly named, especially considering > > >> that HTTP digest authentication existed when that registry -- which > > >> has to do with creating a hash digest of the content, not with > > >> authentication -- was created. We can't fix that now, but we can add > > >> an explanation of its purpose to the registry in order to clarify > > >> things for people who are poking around. > > >> > > >> And we can also change the name of your registry to make things > > >> clearer as well. So, I suggest the following, in addition to putting > > >> them in the same category and on the same web page: > > >> > > >> 1. Change the name of your registry to "Hash Algorithms for HTTP > > >> Digest Authentication", to make it clear that this has to do with HTTP > > >> Digest Authentication. The order of the words is important, to make > > >> sure it's clear that "Authentication" is tightly bound to "HTTP > > >> Digest" here. > > >> > > >> 2. Add a brief description to the new registry's header that says that > > >> this registry lists the hash algorithms that can be used in HTTP > > >> Digest Authentication. > > >> > > >> 3. Add a brief description to the existing "HTTP Digest Algorithm > > >> Values" registry that says that this registry lists the algorithms > > >> that can be used when creating digests of an HTTP message body, as > > >> specified in RFC 3230. > > >> > > >> I think that will adequately distinguish these two registries, and > > >> avoid confusion between them. > > >> > > >> What do you think? > > >> > > > > > > Sounds reasonable to me. > > > > > > I appreciate your help with this, Barry! > > > > > > Regards, > > > Rifaat > > > > > > > > > > > >> > > >> Barry > > >> > > > > > > > > > --047d7b6744000b24b30512d66e14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pearl,

I have just submitted a new v= ersion, v16, that addresses both=A0kathleen's comment and Barry's s= uggestions.
I also adjusted the text in section 6.2 to indicate t= hat we should only update the registry.

Please, le= t me know if you have any further comments.

Regard= s,
=A0Rifaat




On Fri, = Apr 3, 2015 at 12:39 PM, Pearl Liang via RT <drafts-lastcall@iana= .org> wrote:
Rifaat,


On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote:
> Pearl,
>
> Does this address all of your questions?
>

Are you planning to submit a new version to include Barry's sugg= ested revisions?

I however have a new question.=A0 If it has been addressed, apologies in ad= vance.
It is about section 6.2 for the Digest scheme.=A0 Are you intended to repla= ce
the existing reference 'RFC2617 section 3' with this draft for the = existing entry
'Digest'?=A0 If so, the current text in section 6.2 is unclear or i= naccurate:

/snip/
6.2.=A0 Digest Scheme Registration

=A0 =A0This specification registers the Digest scheme with the
=A0 =A0Authentication Scheme Registry.

/snip/

Thanks,
~pl

Pearl Liang
ICANN





> Thanks,
>=A0 Rifaat
>
>
> On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> > wrote:
>
> >
> >
> > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba <barryleiba@computer.org>=
> > wrote:
> >
> >> > I do not know; that is the reason I mentioned that I wou= ld like to hear
> >> the
> >> > opinion of people that have a better understanding of th= e registry.
> >> > I have no problem with using the same registry if that i= s possible and
> >> does
> >> > not cause any confusion.
> >> >
> >> > So, can you please explain how should we go about doing = that?
> >>
> >> Not the same registry.=A0 The same category.
> >>
> >
> > Ah, that makes more sense now.
> >
> >
> >
> >>
> >> How you go about doing that is by changing your answers to Pe= arl's
> >> questions (but then see below):
> >>
> >> >> QUESTION: Where should the new registry be located? = Should it be
> >> created
> >> >> at a new URL?
> >> >
> >> > I think new URL is needed.
> >>
> >> It can go as a second registry on this URL:
> >>=A0 =A0 http://www.iana.org/assignments/http-dig-alg/
> >>
> >> >> If so, should it be listed under an existing categor= y at
> >> >> http://www.iana.org/protocols, or a new one?
> >> >
> >> > I think new category is needed; I could not find a categ= ory close
> >> enough to
> >> > cover what we want with this registry.
> >>
> >> It will go fine as a second registry in the existing category=
> >> "Hypertext Transfer Protocol (HTTP) Digest Algorithm Val= ues".
> >>
> >> --
> >> Now, the problem is that this registry is *so* similar to the= existing
> >> "HTTP Digest Algorithm Values" registry that people= will be confused.
> >> That's one reason I want to put them on the same page -- = so it's
> >> easier to make the differences obvious.
> >>
> >> First, the existing registry is poorly named, especially cons= idering
> >> that HTTP digest authentication existed when that registry --= which
> >> has to do with creating a hash digest of the content, not wit= h
> >> authentication -- was created.=A0 We can't fix that now, = but we can add
> >> an explanation of its purpose to the registry in order to cla= rify
> >> things for people who are poking around.
> >>
> >> And we can also change the name of your registry to make thin= gs
> >> clearer as well.=A0 So, I suggest the following, in addition = to putting
> >> them in the same category and on the same web page:
> >>
> >> 1. Change the name of your registry to "Hash Algorithms = for HTTP
> >> Digest Authentication", to make it clear that this has t= o do with HTTP
> >> Digest Authentication.=A0 The order of the words is important= , to make
> >> sure it's clear that "Authentication" is tightl= y bound to "HTTP
> >> Digest" here.
> >>
> >> 2. Add a brief description to the new registry's header t= hat says that
> >> this registry lists the hash algorithms that can be used in H= TTP
> >> Digest Authentication.
> >>
> >> 3. Add a brief description to the existing "HTTP Digest = Algorithm
> >> Values" registry that says that this registry lists the = algorithms
> >> that can be used when creating digests of an HTTP message bod= y, as
> >> specified in RFC 3230.
> >>
> >> I think that will adequately distinguish these two registries= , and
> >> avoid confusion between them.
> >>
> >> What do you think?
> >>
> >
> > Sounds reasonable to me.
> >
> > I appreciate your help with this, Barry!
> >
> > Regards,
> >=A0 Rifaat
> >
> >
> >
> >>
> >> Barry
> >>
> >
> >



--047d7b6744000b24b30512d66e14-- From nobody Fri Apr 3 20:09:39 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A0F501A1AB4; Fri, 3 Apr 2015 13:31:19 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401291A1AB1 for ; Fri, 3 Apr 2015 13:31:19 -0700 (PDT) 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, MISSING_HEADERS=1.021] 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 4RVj1MC7DO1x for ; Fri, 3 Apr 2015 13:31:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889071A1A8F for ; Fri, 3 Apr 2015 13:31:17 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:44577 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ye8FH-0001e1-T9 for draft-ietf-httpauth-digest.all@tools.ietf.org; Fri, 03 Apr 2015 13:31:17 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t33KV7lj030511; Fri, 3 Apr 2015 20:31:07 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id D3049C20818; Fri, 3 Apr 2015 20:31:07 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #817019 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 03 Apr 2015 20:31:07 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150403203117.889071A1A8F@ietfa.amsl.com> Resent-Date: Fri, 3 Apr 2015 13:31:17 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 20:09:30 -0700 Cc: barryleiba@computer.org, draft-ietf-httpauth-digest.all@tools.ietf.org, liang@icann.org, iesg@ietf.org Subject: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:31:19 -0000 Hi Rifaat, and Barry: Barry, we have a question for you. Thank you for the prompt reply. Section 6.2 in version -16 looks good. We understood that the new created registry will be added to the registry "HTTP Digest Algorithm Values". Barry, can you please confirm if the following text will be needed to document in the IC section of this draft? - Add a brief description to the existing "HTTP Digest Algorithm Values" registry (http://www.iana.org/assignments/http-dig-alg): Note: This registry lists the algorithms that can be used when creating digests of an HTTP message body, as specified in RFC 3230. Other than, we do not have further questions. Thanks, ~pl On Fri Apr 03 18:51:24 2015, rifaat.ietf@gmail.com wrote: > Hi Pearl, > > I have just submitted a new version, v16, that addresses both > kathleen's > comment and Barry's suggestions. > I also adjusted the text in section 6.2 to indicate that we should > only > update the registry. > > Please, let me know if you have any further comments. > > Regards, > Rifaat > > > > > On Fri, Apr 3, 2015 at 12:39 PM, Pearl Liang via RT < > drafts-lastcall@iana.org> wrote: > > > Rifaat, > > > > > > On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote: > > > Pearl, > > > > > > Does this address all of your questions? > > > > > > > Are you planning to submit a new version to include Barry's suggested > > revisions? > > > > I however have a new question. If it has been addressed, apologies > > in > > advance. > > It is about section 6.2 for the Digest scheme. Are you intended to > > replace > > the existing reference 'RFC2617 section 3' with this draft for the > > existing entry > > 'Digest'? If so, the current text in section 6.2 is unclear or > > inaccurate: > > > > /snip/ > > 6.2. Digest Scheme Registration > > > > This specification registers the Digest scheme with the > > Authentication Scheme Registry. > > > > /snip/ > > > > Thanks, > > ~pl > > > > Pearl Liang > > ICANN > > > > > > > > > > > > > Thanks, > > > Rifaat > > > > > > > > > On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef < > > rifaat.ietf@gmail.com> > > > wrote: > > > > > > > > > > > > > > > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba > > > > > > > > wrote: > > > > > > > >> > I do not know; that is the reason I mentioned that I would > > > >> > like to > > hear > > > >> the > > > >> > opinion of people that have a better understanding of the > > > >> > registry. > > > >> > I have no problem with using the same registry if that is > > > >> > possible > > and > > > >> does > > > >> > not cause any confusion. > > > >> > > > > >> > So, can you please explain how should we go about doing that? > > > >> > > > >> Not the same registry. The same category. > > > >> > > > > > > > > Ah, that makes more sense now. > > > > > > > > > > > > > > > >> > > > >> How you go about doing that is by changing your answers to > > > >> Pearl's > > > >> questions (but then see below): > > > >> > > > >> >> QUESTION: Where should the new registry be located? Should it > > > >> >> be > > > >> created > > > >> >> at a new URL? > > > >> > > > > >> > I think new URL is needed. > > > >> > > > >> It can go as a second registry on this URL: > > > >> http://www.iana.org/assignments/http-dig-alg/ > > > >> > > > >> >> If so, should it be listed under an existing category at > > > >> >> http://www.iana.org/protocols, or a new one? > > > >> > > > > >> > I think new category is needed; I could not find a category > > > >> > close > > > >> enough to > > > >> > cover what we want with this registry. > > > >> > > > >> It will go fine as a second registry in the existing category > > > >> "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values". > > > >> > > > >> -- > > > >> Now, the problem is that this registry is *so* similar to the > > > >> existing > > > >> "HTTP Digest Algorithm Values" registry that people will be > > > >> confused. > > > >> That's one reason I want to put them on the same page -- so it's > > > >> easier to make the differences obvious. > > > >> > > > >> First, the existing registry is poorly named, especially > > > >> considering > > > >> that HTTP digest authentication existed when that registry -- > > > >> which > > > >> has to do with creating a hash digest of the content, not with > > > >> authentication -- was created. We can't fix that now, but we > > > >> can add > > > >> an explanation of its purpose to the registry in order to > > > >> clarify > > > >> things for people who are poking around. > > > >> > > > >> And we can also change the name of your registry to make things > > > >> clearer as well. So, I suggest the following, in addition to > > > >> putting > > > >> them in the same category and on the same web page: > > > >> > > > >> 1. Change the name of your registry to "Hash Algorithms for HTTP > > > >> Digest Authentication", to make it clear that this has to do > > > >> with HTTP > > > >> Digest Authentication. The order of the words is important, to > > > >> make > > > >> sure it's clear that "Authentication" is tightly bound to "HTTP > > > >> Digest" here. > > > >> > > > >> 2. Add a brief description to the new registry's header that > > > >> says that > > > >> this registry lists the hash algorithms that can be used in HTTP > > > >> Digest Authentication. > > > >> > > > >> 3. Add a brief description to the existing "HTTP Digest > > > >> Algorithm > > > >> Values" registry that says that this registry lists the > > > >> algorithms > > > >> that can be used when creating digests of an HTTP message body, > > > >> as > > > >> specified in RFC 3230. > > > >> > > > >> I think that will adequately distinguish these two registries, > > > >> and > > > >> avoid confusion between them. > > > >> > > > >> What do you think? > > > >> > > > > > > > > Sounds reasonable to me. > > > > > > > > I appreciate your help with this, Barry! > > > > > > > > Regards, > > > > Rifaat > > > > > > > > > > > > > > > >> > > > >> Barry > > > >> > > > > > > > > > > > > > > From nobody Fri Apr 3 20:09:40 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C2B541A1AC9; Fri, 3 Apr 2015 14:56:39 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987221A1AC2 for ; Fri, 3 Apr 2015 14:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 jm9iCsDyBext for ; Fri, 3 Apr 2015 14:56:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6411A1ABF for ; Fri, 3 Apr 2015 14:56:37 -0700 (PDT) Received: from mail-ob0-x229.google.com ([2607:f8b0:4003:c01::229]:33918) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ye9Zr-0007BZ-0k for draft-ietf-httpauth-digest.all@tools.ietf.org; Fri, 03 Apr 2015 14:56:36 -0700 Received: by obbgh1 with SMTP id gh1so178277757obb.1 for ; Fri, 03 Apr 2015 14:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I2VXciHE5NsgdZS3eHqMlQrDy/u9RTtg1b6S+g7CIFA=; b=vvAPMr0E7lsGaL4In3E1S6Uw79QOyFztxLRykfkaf+woJu3W1bZxC7woeVgM/KGoas aDh6mET126Hj5iBbImb8YplGEWVy6tCwCQDXwrTlvYbEdUfQXyqgSbrIKAneOUEZAQOn wL5AXqW5sw0DUi/Bwro6Yeo11YQC9+ZDG58DwVRiM+9NwZqKfdqNKyKR+CJk+KKCmcpl rcMAcx6tepxKdgfZWTzAew6kprqyOeQpaIgZ5pIIMJ5eU4S0Sc1DzwXonHDsUPTSsCXS JwqsiMZUHi5Dt/OpoaauLdOyIQ3Cv/UO+TwjYXhA+OpWBmPFikg51D5WeKytzYT3Isg8 tc3Q== MIME-Version: 1.0 X-Received: by 10.182.181.72 with SMTP id du8mr5104780obc.71.1428098188242; Fri, 03 Apr 2015 14:56:28 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Fri, 3 Apr 2015 14:56:28 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Fri, 3 Apr 2015 17:56:28 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Pearl Liang via RT Content-Type: multipart/alternative; boundary=089e013a17ba3705630512d905a7 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::229 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150403215637.0F6411A1ABF@ietfa.amsl.com> Resent-Date: Fri, 3 Apr 2015 14:56:37 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 20:09:31 -0700 Cc: Barry Leiba , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG , liang@icann.org Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 03 Apr 2015 21:56:39 -0000 --089e013a17ba3705630512d905a7 Content-Type: text/plain; charset=ISO-8859-1 Hi Pearl, That comment should go into the existing "HTTP Digest Algorithm Values" registry, as it does not apply to the new "Hash Algorithms for HTTP Digest Authentication" registry. So the comment you quoted cannot go into this document. Regards, Rifaat On Fri, Apr 3, 2015 at 4:31 PM, Pearl Liang via RT wrote: > Hi Rifaat, and Barry: > > Barry, we have a question for you. > > Thank you for the prompt reply. Section 6.2 in version -16 looks good. > We understood that the new created registry will be added to the registry > "HTTP Digest Algorithm Values". > > Barry, can you please confirm if the following text will be needed to > document > in the IC section of this draft? > > - Add a brief description to the existing "HTTP Digest Algorithm > Values" registry (http://www.iana.org/assignments/http-dig-alg): > > Note: This registry lists the algorithms that can be used when creating > digests > of an HTTP message body, as specified in RFC 3230. > > Other than, we do not have further questions. > > Thanks, > ~pl > > > On Fri Apr 03 18:51:24 2015, rifaat.ietf@gmail.com wrote: > > Hi Pearl, > > > > I have just submitted a new version, v16, that addresses both > > kathleen's > > comment and Barry's suggestions. > > I also adjusted the text in section 6.2 to indicate that we should > > only > > update the registry. > > > > Please, let me know if you have any further comments. > > > > Regards, > > Rifaat > > > > > > > > > > On Fri, Apr 3, 2015 at 12:39 PM, Pearl Liang via RT < > > drafts-lastcall@iana.org> wrote: > > > > > Rifaat, > > > > > > > > > On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote: > > > > Pearl, > > > > > > > > Does this address all of your questions? > > > > > > > > > > Are you planning to submit a new version to include Barry's suggested > > > revisions? > > > > > > I however have a new question. If it has been addressed, apologies > > > in > > > advance. > > > It is about section 6.2 for the Digest scheme. Are you intended to > > > replace > > > the existing reference 'RFC2617 section 3' with this draft for the > > > existing entry > > > 'Digest'? If so, the current text in section 6.2 is unclear or > > > inaccurate: > > > > > > /snip/ > > > 6.2. Digest Scheme Registration > > > > > > This specification registers the Digest scheme with the > > > Authentication Scheme Registry. > > > > > > /snip/ > > > > > > Thanks, > > > ~pl > > > > > > Pearl Liang > > > ICANN > > > > > > > > > > > > > > > > > > > Thanks, > > > > Rifaat > > > > > > > > > > > > On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef < > > > rifaat.ietf@gmail.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba > > > > > > > > > > wrote: > > > > > > > > > >> > I do not know; that is the reason I mentioned that I would > > > > >> > like to > > > hear > > > > >> the > > > > >> > opinion of people that have a better understanding of the > > > > >> > registry. > > > > >> > I have no problem with using the same registry if that is > > > > >> > possible > > > and > > > > >> does > > > > >> > not cause any confusion. > > > > >> > > > > > >> > So, can you please explain how should we go about doing that? > > > > >> > > > > >> Not the same registry. The same category. > > > > >> > > > > > > > > > > Ah, that makes more sense now. > > > > > > > > > > > > > > > > > > > >> > > > > >> How you go about doing that is by changing your answers to > > > > >> Pearl's > > > > >> questions (but then see below): > > > > >> > > > > >> >> QUESTION: Where should the new registry be located? Should it > > > > >> >> be > > > > >> created > > > > >> >> at a new URL? > > > > >> > > > > > >> > I think new URL is needed. > > > > >> > > > > >> It can go as a second registry on this URL: > > > > >> http://www.iana.org/assignments/http-dig-alg/ > > > > >> > > > > >> >> If so, should it be listed under an existing category at > > > > >> >> http://www.iana.org/protocols, or a new one? > > > > >> > > > > > >> > I think new category is needed; I could not find a category > > > > >> > close > > > > >> enough to > > > > >> > cover what we want with this registry. > > > > >> > > > > >> It will go fine as a second registry in the existing category > > > > >> "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values". > > > > >> > > > > >> -- > > > > >> Now, the problem is that this registry is *so* similar to the > > > > >> existing > > > > >> "HTTP Digest Algorithm Values" registry that people will be > > > > >> confused. > > > > >> That's one reason I want to put them on the same page -- so it's > > > > >> easier to make the differences obvious. > > > > >> > > > > >> First, the existing registry is poorly named, especially > > > > >> considering > > > > >> that HTTP digest authentication existed when that registry -- > > > > >> which > > > > >> has to do with creating a hash digest of the content, not with > > > > >> authentication -- was created. We can't fix that now, but we > > > > >> can add > > > > >> an explanation of its purpose to the registry in order to > > > > >> clarify > > > > >> things for people who are poking around. > > > > >> > > > > >> And we can also change the name of your registry to make things > > > > >> clearer as well. So, I suggest the following, in addition to > > > > >> putting > > > > >> them in the same category and on the same web page: > > > > >> > > > > >> 1. Change the name of your registry to "Hash Algorithms for HTTP > > > > >> Digest Authentication", to make it clear that this has to do > > > > >> with HTTP > > > > >> Digest Authentication. The order of the words is important, to > > > > >> make > > > > >> sure it's clear that "Authentication" is tightly bound to "HTTP > > > > >> Digest" here. > > > > >> > > > > >> 2. Add a brief description to the new registry's header that > > > > >> says that > > > > >> this registry lists the hash algorithms that can be used in HTTP > > > > >> Digest Authentication. > > > > >> > > > > >> 3. Add a brief description to the existing "HTTP Digest > > > > >> Algorithm > > > > >> Values" registry that says that this registry lists the > > > > >> algorithms > > > > >> that can be used when creating digests of an HTTP message body, > > > > >> as > > > > >> specified in RFC 3230. > > > > >> > > > > >> I think that will adequately distinguish these two registries, > > > > >> and > > > > >> avoid confusion between them. > > > > >> > > > > >> What do you think? > > > > >> > > > > > > > > > > Sounds reasonable to me. > > > > > > > > > > I appreciate your help with this, Barry! > > > > > > > > > > Regards, > > > > > Rifaat > > > > > > > > > > > > > > > > > > > >> > > > > >> Barry > > > > >> > > > > > > > > > > > > > > > > > > > > > > --089e013a17ba3705630512d905a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pearl,

That comment should go into t= he existing "HTTP Digest Algorithm Values" registry, as it does n= ot apply to the new "Hash= Algorithms for HTTP=A0= Digest Authentication" registry.
So the comment you q= uoted cannot go into this document.

Regards,
=
=A0Rifaat


On Fri, Apr 3, 2015 at 4:31 PM, Pearl Liang via RT = <drafts-lastcall@iana.org> wrote:
Hi Rifaat, and Barry:

Barry, we have a question for you.

Thank you for the prompt reply.=A0 Section 6.2 in version -16 looks good. We understood that the new created registry will be added to the registry "HTTP Digest Algorithm Values".

Barry, can you please confirm if the following text will be needed to docum= ent
in the IC section of this draft?

- Add a brief description to the existing "HTTP Digest Algorithm
Values" registry (http://www.iana.org/assignments/http-dig-alg<= /a>):

Note: This registry lists the algorithms that can be used when creating dig= ests
of an HTTP message body, as specified in RFC 3230.

Other than, we do not have further questions.

Thanks,
~pl


On Fri Apr 03 18:51:24 2015, rifaa= t.ietf@gmail.com wrote:
> Hi Pearl,
>
> I have just submitted a new version, v16, that addresses both
> kathleen's
> comment and Barry's suggestions.
> I also adjusted the text in section 6.2 to indicate that we should
> only
> update the registry.
>
> Please, let me know if you have any further comments.
>
> Regards,
>=A0 Rifaat
>
>
>
>
> On Fri, Apr 3, 2015 at 12:39 PM, Pearl Liang via RT <
> drafts-lastcall@iana.org> wrote:
>
> > Rifaat,
> >
> >
> > On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote:
> > > Pearl,
> > >
> > > Does this address all of your questions?
> > >
> >
> > Are you planning to submit a new version to include Barry's s= uggested
> > revisions?
> >
> > I however have a new question.=A0 If it has been addressed, apolo= gies
> > in
> > advance.
> > It is about section 6.2 for the Digest scheme.=A0 Are you intende= d to
> > replace
> > the existing reference 'RFC2617 section 3' with this draf= t for the
> > existing entry
> > 'Digest'?=A0 If so, the current text in section 6.2 is un= clear or
> > inaccurate:
> >
> > /snip/
> > 6.2.=A0 Digest Scheme Registration
> >
> > This specification registers the Digest scheme with the
> > Authentication Scheme Registry.
> >
> > /snip/
> >
> > Thanks,
> > ~pl
> >
> > Pearl Liang
> > ICANN
> >
> >
> >
> >
> >
> > > Thanks,
> > >=A0 Rifaat
> > >
> > >
> > > On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef <
> > rifaat.ietf@gmail.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba
> > > > <barrylei= ba@computer.org>
> > > > wrote:
> > > >
> > > >> > I do not know; that is the reason I mentioned = that I would
> > > >> > like to
> > hear
> > > >> the
> > > >> > opinion of people that have a better understan= ding of the
> > > >> > registry.
> > > >> > I have no problem with using the same registry= if that is
> > > >> > possible
> > and
> > > >> does
> > > >> > not cause any confusion.
> > > >> >
> > > >> > So, can you please explain how should we go ab= out doing that?
> > > >>
> > > >> Not the same registry.=A0 The same category.
> > > >>
> > > >
> > > > Ah, that makes more sense now.
> > > >
> > > >
> > > >
> > > >>
> > > >> How you go about doing that is by changing your ans= wers to
> > > >> Pearl's
> > > >> questions (but then see below):
> > > >>
> > > >> >> QUESTION: Where should the new registry be= located? Should it
> > > >> >> be
> > > >> created
> > > >> >> at a new URL?
> > > >> >
> > > >> > I think new URL is needed.
> > > >>
> > > >> It can go as a second registry on this URL:
> > > >>=A0 =A0 http://www.iana.org/assignments/http-dig-al= g/
> > > >>
> > > >> >> If so, should it be listed under an existi= ng category at
> > > >> >> http://www.iana.org/protocols, or a new one?
> > > >> >
> > > >> > I think new category is needed; I could not fi= nd a category
> > > >> > close
> > > >> enough to
> > > >> > cover what we want with this registry.
> > > >>
> > > >> It will go fine as a second registry in the existin= g category
> > > >> "Hypertext Transfer Protocol (HTTP) Digest Alg= orithm Values".
> > > >>
> > > >> --
> > > >> Now, the problem is that this registry is *so* simi= lar to the
> > > >> existing
> > > >> "HTTP Digest Algorithm Values" registry t= hat people will be
> > > >> confused.
> > > >> That's one reason I want to put them on the sam= e page -- so it's
> > > >> easier to make the differences obvious.
> > > >>
> > > >> First, the existing registry is poorly named, espec= ially
> > > >> considering
> > > >> that HTTP digest authentication existed when that r= egistry --
> > > >> which
> > > >> has to do with creating a hash digest of the conten= t, not with
> > > >> authentication -- was created.=A0 We can't fix = that now, but we
> > > >> can add
> > > >> an explanation of its purpose to the registry in or= der to
> > > >> clarify
> > > >> things for people who are poking around.
> > > >>
> > > >> And we can also change the name of your registry to= make things
> > > >> clearer as well.=A0 So, I suggest the following, in= addition to
> > > >> putting
> > > >> them in the same category and on the same web page:=
> > > >>
> > > >> 1. Change the name of your registry to "Hash A= lgorithms for HTTP
> > > >> Digest Authentication", to make it clear that = this has to do
> > > >> with HTTP
> > > >> Digest Authentication.=A0 The order of the words is= important, to
> > > >> make
> > > >> sure it's clear that "Authentication"= is tightly bound to "HTTP
> > > >> Digest" here.
> > > >>
> > > >> 2. Add a brief description to the new registry'= s header that
> > > >> says that
> > > >> this registry lists the hash algorithms that can be= used in HTTP
> > > >> Digest Authentication.
> > > >>
> > > >> 3. Add a brief description to the existing "HT= TP Digest
> > > >> Algorithm
> > > >> Values" registry that says that this registry = lists the
> > > >> algorithms
> > > >> that can be used when creating digests of an HTTP m= essage body,
> > > >> as
> > > >> specified in RFC 3230.
> > > >>
> > > >> I think that will adequately distinguish these two = registries,
> > > >> and
> > > >> avoid confusion between them.
> > > >>
> > > >> What do you think?
> > > >>
> > > >
> > > > Sounds reasonable to me.
> > > >
> > > > I appreciate your help with this, Barry!
> > > >
> > > > Regards,
> > > >=A0 Rifaat
> > > >
> > > >
> > > >
> > > >>
> > > >> Barry
> > > >>
> > > >
> > > >
> >
> >
> >



--089e013a17ba3705630512d905a7-- From nobody Fri Apr 3 20:09:42 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7823A1A6F1E; Fri, 3 Apr 2015 15:38:06 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3C61A1AC2 for ; Fri, 3 Apr 2015 15:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 Yf_W64rq2SWe for ; Fri, 3 Apr 2015 15:38:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CC11A6F07 for ; Fri, 3 Apr 2015 15:38:01 -0700 (PDT) Received: from mail-la0-f46.google.com ([209.85.215.46]:36309) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YeADv-00035A-ON for draft-ietf-httpauth-digest.all@tools.ietf.org; Fri, 03 Apr 2015 15:38:01 -0700 Received: by lagv1 with SMTP id v1so11002889lag.3 for ; Fri, 03 Apr 2015 15:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n1MkX8EVBBxMsQ2nkle672Lc/NyJj4MF7r/Rci467T8=; b=Ec1b4m2HA6fkR7KK84YJMJxzctLAHyVtMaSSTnkwDjxKFCUdtwu99uQuB0mEH/BvDH vjTcvv23erfpgKqL9C3BOkXikQvv4ZamD/R0DDaX980L6p/T657NM1MT9VCeox7MHsdK jNRKpGjgVBD+OxithLj1XfsA8epdc8eHQqaMJjks7Eq4KWuENLnNJ1hGHUP0Zs6d0XoU Ea9SrsE5YpYaP8kjuYIxsL0nO855Eu05mN4Y9Sh/qqWklkmG6+yxhqs7zTsAeqDmLPiI 4Gh0w3Vqv3P4wr0woWZwG/M73qcTldkdYIoKA/vlos81yKXoyrhNgFgm0vnwAVLljPtm jznw== MIME-Version: 1.0 X-Received: by 10.152.37.202 with SMTP id a10mr3996681lak.0.1428100668233; Fri, 03 Apr 2015 15:37:48 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Fri, 3 Apr 2015 15:37:48 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Fri, 3 Apr 2015 18:37:48 -0400 Message-ID: From: Kathleen Moriarty To: Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary=089e01494056089de80512d999d3 X-SA-Exim-Connect-IP: 209.85.215.46 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: kathleen.moriarty.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150403223801.56CC11A6F07@ietfa.amsl.com> Resent-Date: Fri, 3 Apr 2015 15:38:01 -0700 (PDT) Resent-From: kathleen.moriarty.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 20:09:30 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG , Barry Leiba , liang@icann.org Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 03 Apr 2015 22:38:06 -0000 --089e01494056089de80512d999d3 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 2:51 PM, Rifaat Shekh-Yusef wrote: > Hi Pearl, > > I have just submitted a new version, v16, that addresses both kathleen's > comment and Barry's suggestions. > I also adjusted the text in section 6.2 to indicate that we should only > update the registry. > Thank you for adding in my comments and Barry for the helpful advice to distinguish the 2 registries. > > Please, let me know if you have any further comments. > > Regards, > Rifaat > > > > > On Fri, Apr 3, 2015 at 12:39 PM, Pearl Liang via RT < > drafts-lastcall@iana.org> wrote: > >> Rifaat, >> >> >> On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote: >> > Pearl, >> > >> > Does this address all of your questions? >> > >> >> Are you planning to submit a new version to include Barry's suggested >> revisions? >> >> I however have a new question. If it has been addressed, apologies in >> advance. >> It is about section 6.2 for the Digest scheme. Are you intended to >> replace >> the existing reference 'RFC2617 section 3' with this draft for the >> existing entry >> 'Digest'? If so, the current text in section 6.2 is unclear or >> inaccurate: >> >> /snip/ >> 6.2. Digest Scheme Registration >> >> This specification registers the Digest scheme with the >> Authentication Scheme Registry. >> >> /snip/ >> >> Thanks, >> ~pl >> >> Pearl Liang >> ICANN >> >> >> >> >> >> > Thanks, >> > Rifaat >> > >> > >> > On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef < >> rifaat.ietf@gmail.com> >> > wrote: >> > >> > > >> > > >> > > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba >> > > wrote: >> > > >> > >> > I do not know; that is the reason I mentioned that I would like to >> hear >> > >> the >> > >> > opinion of people that have a better understanding of the registry. >> > >> > I have no problem with using the same registry if that is possible >> and >> > >> does >> > >> > not cause any confusion. >> > >> > >> > >> > So, can you please explain how should we go about doing that? >> > >> >> > >> Not the same registry. The same category. >> > >> >> > > >> > > Ah, that makes more sense now. >> > > >> > > >> > > >> > >> >> > >> How you go about doing that is by changing your answers to Pearl's >> > >> questions (but then see below): >> > >> >> > >> >> QUESTION: Where should the new registry be located? Should it be >> > >> created >> > >> >> at a new URL? >> > >> > >> > >> > I think new URL is needed. >> > >> >> > >> It can go as a second registry on this URL: >> > >> http://www.iana.org/assignments/http-dig-alg/ >> > >> >> > >> >> If so, should it be listed under an existing category at >> > >> >> http://www.iana.org/protocols, or a new one? >> > >> > >> > >> > I think new category is needed; I could not find a category close >> > >> enough to >> > >> > cover what we want with this registry. >> > >> >> > >> It will go fine as a second registry in the existing category >> > >> "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values". >> > >> >> > >> -- >> > >> Now, the problem is that this registry is *so* similar to the >> existing >> > >> "HTTP Digest Algorithm Values" registry that people will be confused. >> > >> That's one reason I want to put them on the same page -- so it's >> > >> easier to make the differences obvious. >> > >> >> > >> First, the existing registry is poorly named, especially considering >> > >> that HTTP digest authentication existed when that registry -- which >> > >> has to do with creating a hash digest of the content, not with >> > >> authentication -- was created. We can't fix that now, but we can add >> > >> an explanation of its purpose to the registry in order to clarify >> > >> things for people who are poking around. >> > >> >> > >> And we can also change the name of your registry to make things >> > >> clearer as well. So, I suggest the following, in addition to putting >> > >> them in the same category and on the same web page: >> > >> >> > >> 1. Change the name of your registry to "Hash Algorithms for HTTP >> > >> Digest Authentication", to make it clear that this has to do with >> HTTP >> > >> Digest Authentication. The order of the words is important, to make >> > >> sure it's clear that "Authentication" is tightly bound to "HTTP >> > >> Digest" here. >> > >> >> > >> 2. Add a brief description to the new registry's header that says >> that >> > >> this registry lists the hash algorithms that can be used in HTTP >> > >> Digest Authentication. >> > >> >> > >> 3. Add a brief description to the existing "HTTP Digest Algorithm >> > >> Values" registry that says that this registry lists the algorithms >> > >> that can be used when creating digests of an HTTP message body, as >> > >> specified in RFC 3230. >> > >> >> > >> I think that will adequately distinguish these two registries, and >> > >> avoid confusion between them. >> > >> >> > >> What do you think? >> > >> >> > > >> > > Sounds reasonable to me. >> > > >> > > I appreciate your help with this, Barry! >> > > >> > > Regards, >> > > Rifaat >> > > >> > > >> > > >> > >> >> > >> Barry >> > >> >> > > >> > > >> >> >> > -- Best regards, Kathleen --089e01494056089de80512d999d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 3, 2015 at 2:51 PM, Rifaat Shekh-Yusef &l= t;rifaat.ietf@gm= ail.com> wrote:
Hi Pearl,

I have just submitted a new version, v16= , that addresses both=C2=A0kathleen's comment and Barry's suggestio= ns.
I also adjusted the text in section 6.2 to indicate that we s= hould only update the registry.

Thank you for adding in my comments and Barry for the helpful advice to di= stinguish the 2 registries.=C2=A0

Please, let me know if you have any further= comments.

Regards,
=C2=A0Rifaat




On Fri, Apr 3, = 2015 at 12:39 PM, Pearl Liang via RT <drafts-lastcall@iana.org&= gt; wrote:
Rifaat,


On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote:
> Pearl,
>
> Does this address all of your questions?
>

Are you planning to submit a new version to include Barry's sugg= ested revisions?

I however have a new question.=C2=A0 If it has been addressed, apologies in= advance.
It is about section 6.2 for the Digest scheme.=C2=A0 Are you intended to re= place
the existing reference 'RFC2617 section 3' with this draft for the = existing entry
'Digest'?=C2=A0 If so, the current text in section 6.2 is unclear o= r inaccurate:

/snip/
6.2.=C2=A0 Digest Scheme Registration

=C2=A0 =C2=A0This specification registers the Digest scheme with the
=C2=A0 =C2=A0Authentication Scheme Registry.

/snip/

Thanks,
~pl

Pearl Liang
ICANN





> Thanks,
>=C2=A0 Rifaat
>
>
> On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> > wrote:
>
> >
> >
> > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba <barryleiba@computer.org>=
> > wrote:
> >
> >> > I do not know; that is the reason I mentioned that I wou= ld like to hear
> >> the
> >> > opinion of people that have a better understanding of th= e registry.
> >> > I have no problem with using the same registry if that i= s possible and
> >> does
> >> > not cause any confusion.
> >> >
> >> > So, can you please explain how should we go about doing = that?
> >>
> >> Not the same registry.=C2=A0 The same category.
> >>
> >
> > Ah, that makes more sense now.
> >
> >
> >
> >>
> >> How you go about doing that is by changing your answers to Pe= arl's
> >> questions (but then see below):
> >>
> >> >> QUESTION: Where should the new registry be located? = Should it be
> >> created
> >> >> at a new URL?
> >> >
> >> > I think new URL is needed.
> >>
> >> It can go as a second registry on this URL:
> >>=C2=A0 =C2=A0 http://www.iana.org/assignments/http-dig-alg/
> >>
> >> >> If so, should it be listed under an existing categor= y at
> >> >> http://www.iana.org/protocols, or a new one?
> >> >
> >> > I think new category is needed; I could not find a categ= ory close
> >> enough to
> >> > cover what we want with this registry.
> >>
> >> It will go fine as a second registry in the existing category=
> >> "Hypertext Transfer Protocol (HTTP) Digest Algorithm Val= ues".
> >>
> >> --
> >> Now, the problem is that this registry is *so* similar to the= existing
> >> "HTTP Digest Algorithm Values" registry that people= will be confused.
> >> That's one reason I want to put them on the same page -- = so it's
> >> easier to make the differences obvious.
> >>
> >> First, the existing registry is poorly named, especially cons= idering
> >> that HTTP digest authentication existed when that registry --= which
> >> has to do with creating a hash digest of the content, not wit= h
> >> authentication -- was created.=C2=A0 We can't fix that no= w, but we can add
> >> an explanation of its purpose to the registry in order to cla= rify
> >> things for people who are poking around.
> >>
> >> And we can also change the name of your registry to make thin= gs
> >> clearer as well.=C2=A0 So, I suggest the following, in additi= on to putting
> >> them in the same category and on the same web page:
> >>
> >> 1. Change the name of your registry to "Hash Algorithms = for HTTP
> >> Digest Authentication", to make it clear that this has t= o do with HTTP
> >> Digest Authentication.=C2=A0 The order of the words is import= ant, to make
> >> sure it's clear that "Authentication" is tightl= y bound to "HTTP
> >> Digest" here.
> >>
> >> 2. Add a brief description to the new registry's header t= hat says that
> >> this registry lists the hash algorithms that can be used in H= TTP
> >> Digest Authentication.
> >>
> >> 3. Add a brief description to the existing "HTTP Digest = Algorithm
> >> Values" registry that says that this registry lists the = algorithms
> >> that can be used when creating digests of an HTTP message bod= y, as
> >> specified in RFC 3230.
> >>
> >> I think that will adequately distinguish these two registries= , and
> >> avoid confusion between them.
> >>
> >> What do you think?
> >>
> >
> > Sounds reasonable to me.
> >
> > I appreciate your help with this, Barry!
> >
> > Regards,
> >=C2=A0 Rifaat
> >
> >
> >
> >>
> >> Barry
> >>
> >
> >






--

Best regards,
Kath= leen
--089e01494056089de80512d999d3-- From nobody Mon Apr 6 05:35:55 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BA8A81A8858; Mon, 6 Apr 2015 05:33:58 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9114C1A8857 for ; Mon, 6 Apr 2015 05:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 nw32S1iE3DAZ for ; Mon, 6 Apr 2015 05:33:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35301A8852 for ; Mon, 6 Apr 2015 05:33:55 -0700 (PDT) Received: from mail-ob0-x236.google.com ([2607:f8b0:4003:c01::236]:34192) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yf6Dy-00045y-Eb for draft-ietf-httpauth-digest.all@tools.ietf.org; Mon, 06 Apr 2015 05:33:55 -0700 Received: by obbgh1 with SMTP id gh1so37848330obb.1 for ; Mon, 06 Apr 2015 05:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lAuRdWd7Mq/ooRGLI7TjhQ5jx8LjG/vJnmU5UpRJUyo=; b=kG4qsTf9CNIpBekNfyvqnJ9QFL+tr+Vq4LVT2151gnPlDfxEb6R8bG+aFPCfneycem 0HqpbMLIWuazmr4TEjeSLchWmaAyxDWj/Ym64fR53Hlwy6MhF9hm2I/P00U41R6vtlAt XKcWV3NVS/nX/KMzQtgx0Wsb7YwpyIvJKrTOJ0Y8WFjd8rlMNltb4hyUeuEaigI6A7rx K4PZZ+mw56SKKx9cL7nuo4/K+/n9tczMnCTufxc3zDQ/DQJrGeNh8dTn4NaJ07m0o9Sn cb86ax9zi0RnN4xxltNm3nA3ToSD8BnBwQ3CeGL6XWAlQ4xR27Mh/5VqUSjZ3ss2b8Ju nG2Q== MIME-Version: 1.0 X-Received: by 10.60.63.39 with SMTP id d7mr18185444oes.72.1428323626407; Mon, 06 Apr 2015 05:33:46 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Mon, 6 Apr 2015 05:33:46 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Mon, 6 Apr 2015 08:33:46 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Pearl Liang via RT Content-Type: multipart/alternative; boundary=001a11c21ff060806305130d8215 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::236 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150406123355.F35301A8852@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 05:33:55 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 05:35:53 -0700 Cc: Barry Leiba , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG , liang@icann.org Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 06 Apr 2015 12:33:58 -0000 --001a11c21ff060806305130d8215 Content-Type: text/plain; charset=ISO-8859-1 Hi Pearl, Did we address all you questions with the last email below? Regards, Rifaat On Fri, Apr 3, 2015 at 5:56 PM, Rifaat Shekh-Yusef wrote: > Hi Pearl, > > That comment should go into the existing "HTTP Digest Algorithm Values" > registry, as it does not apply to the new "Hash Algorithms for HTTP Digest > Authentication" registry. > So the comment you quoted cannot go into this document. > > Regards, > Rifaat > > > On Fri, Apr 3, 2015 at 4:31 PM, Pearl Liang via RT < > drafts-lastcall@iana.org> wrote: > >> Hi Rifaat, and Barry: >> >> Barry, we have a question for you. >> >> Thank you for the prompt reply. Section 6.2 in version -16 looks good. >> We understood that the new created registry will be added to the registry >> "HTTP Digest Algorithm Values". >> >> Barry, can you please confirm if the following text will be needed to >> document >> in the IC section of this draft? >> >> - Add a brief description to the existing "HTTP Digest Algorithm >> Values" registry (http://www.iana.org/assignments/http-dig-alg): >> >> Note: This registry lists the algorithms that can be used when creating >> digests >> of an HTTP message body, as specified in RFC 3230. >> >> Other than, we do not have further questions. >> >> Thanks, >> ~pl >> >> >> On Fri Apr 03 18:51:24 2015, rifaat.ietf@gmail.com wrote: >> > Hi Pearl, >> > >> > I have just submitted a new version, v16, that addresses both >> > kathleen's >> > comment and Barry's suggestions. >> > I also adjusted the text in section 6.2 to indicate that we should >> > only >> > update the registry. >> > >> > Please, let me know if you have any further comments. >> > >> > Regards, >> > Rifaat >> > >> > >> > >> > >> > On Fri, Apr 3, 2015 at 12:39 PM, Pearl Liang via RT < >> > drafts-lastcall@iana.org> wrote: >> > >> > > Rifaat, >> > > >> > > >> > > On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote: >> > > > Pearl, >> > > > >> > > > Does this address all of your questions? >> > > > >> > > >> > > Are you planning to submit a new version to include Barry's suggested >> > > revisions? >> > > >> > > I however have a new question. If it has been addressed, apologies >> > > in >> > > advance. >> > > It is about section 6.2 for the Digest scheme. Are you intended to >> > > replace >> > > the existing reference 'RFC2617 section 3' with this draft for the >> > > existing entry >> > > 'Digest'? If so, the current text in section 6.2 is unclear or >> > > inaccurate: >> > > >> > > /snip/ >> > > 6.2. Digest Scheme Registration >> > > >> > > This specification registers the Digest scheme with the >> > > Authentication Scheme Registry. >> > > >> > > /snip/ >> > > >> > > Thanks, >> > > ~pl >> > > >> > > Pearl Liang >> > > ICANN >> > > >> > > >> > > >> > > >> > > >> > > > Thanks, >> > > > Rifaat >> > > > >> > > > >> > > > On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef < >> > > rifaat.ietf@gmail.com> >> > > > wrote: >> > > > >> > > > > >> > > > > >> > > > > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba >> > > > > >> > > > > wrote: >> > > > > >> > > > >> > I do not know; that is the reason I mentioned that I would >> > > > >> > like to >> > > hear >> > > > >> the >> > > > >> > opinion of people that have a better understanding of the >> > > > >> > registry. >> > > > >> > I have no problem with using the same registry if that is >> > > > >> > possible >> > > and >> > > > >> does >> > > > >> > not cause any confusion. >> > > > >> > >> > > > >> > So, can you please explain how should we go about doing that? >> > > > >> >> > > > >> Not the same registry. The same category. >> > > > >> >> > > > > >> > > > > Ah, that makes more sense now. >> > > > > >> > > > > >> > > > > >> > > > >> >> > > > >> How you go about doing that is by changing your answers to >> > > > >> Pearl's >> > > > >> questions (but then see below): >> > > > >> >> > > > >> >> QUESTION: Where should the new registry be located? Should it >> > > > >> >> be >> > > > >> created >> > > > >> >> at a new URL? >> > > > >> > >> > > > >> > I think new URL is needed. >> > > > >> >> > > > >> It can go as a second registry on this URL: >> > > > >> http://www.iana.org/assignments/http-dig-alg/ >> > > > >> >> > > > >> >> If so, should it be listed under an existing category at >> > > > >> >> http://www.iana.org/protocols, or a new one? >> > > > >> > >> > > > >> > I think new category is needed; I could not find a category >> > > > >> > close >> > > > >> enough to >> > > > >> > cover what we want with this registry. >> > > > >> >> > > > >> It will go fine as a second registry in the existing category >> > > > >> "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values". >> > > > >> >> > > > >> -- >> > > > >> Now, the problem is that this registry is *so* similar to the >> > > > >> existing >> > > > >> "HTTP Digest Algorithm Values" registry that people will be >> > > > >> confused. >> > > > >> That's one reason I want to put them on the same page -- so it's >> > > > >> easier to make the differences obvious. >> > > > >> >> > > > >> First, the existing registry is poorly named, especially >> > > > >> considering >> > > > >> that HTTP digest authentication existed when that registry -- >> > > > >> which >> > > > >> has to do with creating a hash digest of the content, not with >> > > > >> authentication -- was created. We can't fix that now, but we >> > > > >> can add >> > > > >> an explanation of its purpose to the registry in order to >> > > > >> clarify >> > > > >> things for people who are poking around. >> > > > >> >> > > > >> And we can also change the name of your registry to make things >> > > > >> clearer as well. So, I suggest the following, in addition to >> > > > >> putting >> > > > >> them in the same category and on the same web page: >> > > > >> >> > > > >> 1. Change the name of your registry to "Hash Algorithms for HTTP >> > > > >> Digest Authentication", to make it clear that this has to do >> > > > >> with HTTP >> > > > >> Digest Authentication. The order of the words is important, to >> > > > >> make >> > > > >> sure it's clear that "Authentication" is tightly bound to "HTTP >> > > > >> Digest" here. >> > > > >> >> > > > >> 2. Add a brief description to the new registry's header that >> > > > >> says that >> > > > >> this registry lists the hash algorithms that can be used in HTTP >> > > > >> Digest Authentication. >> > > > >> >> > > > >> 3. Add a brief description to the existing "HTTP Digest >> > > > >> Algorithm >> > > > >> Values" registry that says that this registry lists the >> > > > >> algorithms >> > > > >> that can be used when creating digests of an HTTP message body, >> > > > >> as >> > > > >> specified in RFC 3230. >> > > > >> >> > > > >> I think that will adequately distinguish these two registries, >> > > > >> and >> > > > >> avoid confusion between them. >> > > > >> >> > > > >> What do you think? >> > > > >> >> > > > > >> > > > > Sounds reasonable to me. >> > > > > >> > > > > I appreciate your help with this, Barry! >> > > > > >> > > > > Regards, >> > > > > Rifaat >> > > > > >> > > > > >> > > > > >> > > > >> >> > > > >> Barry >> > > > >> >> > > > > >> > > > > >> > > >> > > >> > > >> >> >> > --001a11c21ff060806305130d8215 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pearl,

Did we address all you questi= ons with the last email below?

Regards,
= =A0Rifaat


On Fri, Apr 3, 2015 at 5:56 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi Pearl,

That comment should go in= to the existing "HTTP Digest Algorithm Values" registry, as it do= es not apply to the new "= Hash Algorithms for HTTP=A0Digest Authentication" registry.
So the comment y= ou quoted cannot go into this document.

Regards,
=A0Rifaat


On Fri,= Apr 3, 2015 at 4:31 PM, Pearl Liang via RT <drafts-lastcall@iana= .org> wrote:
Hi Rifaat, and= Barry:

Barry, we have a question for you.

Thank you for the prompt reply.=A0 Section 6.2 in version -16 looks good. We understood that the new created registry will be added to the registry "HTTP Digest Algorithm Values".

Barry, can you please confirm if the following text will be needed to docum= ent
in the IC section of this draft?

- Add a brief description to the existing "HTTP Digest Algorithm
Values" registry (http://www.iana.org/assignments/http-dig-alg<= /a>):

Note: This registry lists the algorithms that can be used when creating dig= ests
of an HTTP message body, as specified in RFC 3230.

Other than, we do not have further questions.

Thanks,
~pl


On Fri Apr 03 18:51:24 2015, rifaat.ietf@gmail.com wrote:
> Hi Pearl,
>
> I have just submitted a new version, v16, that addresses both
> kathleen's
> comment and Barry's suggestions.
> I also adjusted the text in section 6.2 to indicate that we should
> only
> update the registry.
>
> Please, let me know if you have any further comments.
>
> Regards,
>=A0 Rifaat
>
>
>
>
> On Fri, Apr 3, 2015 at 12:39 PM, Pearl Liang via RT <
> drafts-l= astcall@iana.org> wrote:
>
> > Rifaat,
> >
> >
> > On Fri Apr 03 11:07:04 2015, rifaat.ietf@gmail.com wrote:
> > > Pearl,
> > >
> > > Does this address all of your questions?
> > >
> >
> > Are you planning to submit a new version to include Barry's s= uggested
> > revisions?
> >
> > I however have a new question.=A0 If it has been addressed, apolo= gies
> > in
> > advance.
> > It is about section 6.2 for the Digest scheme.=A0 Are you intende= d to
> > replace
> > the existing reference 'RFC2617 section 3' with this draf= t for the
> > existing entry
> > 'Digest'?=A0 If so, the current text in section 6.2 is un= clear or
> > inaccurate:
> >
> > /snip/
> > 6.2.=A0 Digest Scheme Registration
> >
> > This specification registers the Digest scheme with the
> > Authentication Scheme Registry.
> >
> > /snip/
> >
> > Thanks,
> > ~pl
> >
> > Pearl Liang
> > ICANN
> >
> >
> >
> >
> >
> > > Thanks,
> > >=A0 Rifaat
> > >
> > >
> > > On Wed, Apr 1, 2015 at 5:20 PM, Rifaat Shekh-Yusef <
> > rifaat= .ietf@gmail.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > On Wed, Apr 1, 2015 at 4:53 PM, Barry Leiba
> > > > <barryleiba@computer.org>
> > > > wrote:
> > > >
> > > >> > I do not know; that is the reason I mentioned = that I would
> > > >> > like to
> > hear
> > > >> the
> > > >> > opinion of people that have a better understan= ding of the
> > > >> > registry.
> > > >> > I have no problem with using the same registry= if that is
> > > >> > possible
> > and
> > > >> does
> > > >> > not cause any confusion.
> > > >> >
> > > >> > So, can you please explain how should we go ab= out doing that?
> > > >>
> > > >> Not the same registry.=A0 The same category.
> > > >>
> > > >
> > > > Ah, that makes more sense now.
> > > >
> > > >
> > > >
> > > >>
> > > >> How you go about doing that is by changing your ans= wers to
> > > >> Pearl's
> > > >> questions (but then see below):
> > > >>
> > > >> >> QUESTION: Where should the new registry be= located? Should it
> > > >> >> be
> > > >> created
> > > >> >> at a new URL?
> > > >> >
> > > >> > I think new URL is needed.
> > > >>
> > > >> It can go as a second registry on this URL:
> > > >>=A0 =A0 http://www.iana.org/assignments/http-dig-al= g/
> > > >>
> > > >> >> If so, should it be listed under an existi= ng category at
> > > >> >> http://www.iana.org/protocols, or a new one?
> > > >> >
> > > >> > I think new category is needed; I could not fi= nd a category
> > > >> > close
> > > >> enough to
> > > >> > cover what we want with this registry.
> > > >>
> > > >> It will go fine as a second registry in the existin= g category
> > > >> "Hypertext Transfer Protocol (HTTP) Digest Alg= orithm Values".
> > > >>
> > > >> --
> > > >> Now, the problem is that this registry is *so* simi= lar to the
> > > >> existing
> > > >> "HTTP Digest Algorithm Values" registry t= hat people will be
> > > >> confused.
> > > >> That's one reason I want to put them on the sam= e page -- so it's
> > > >> easier to make the differences obvious.
> > > >>
> > > >> First, the existing registry is poorly named, espec= ially
> > > >> considering
> > > >> that HTTP digest authentication existed when that r= egistry --
> > > >> which
> > > >> has to do with creating a hash digest of the conten= t, not with
> > > >> authentication -- was created.=A0 We can't fix = that now, but we
> > > >> can add
> > > >> an explanation of its purpose to the registry in or= der to
> > > >> clarify
> > > >> things for people who are poking around.
> > > >>
> > > >> And we can also change the name of your registry to= make things
> > > >> clearer as well.=A0 So, I suggest the following, in= addition to
> > > >> putting
> > > >> them in the same category and on the same web page:=
> > > >>
> > > >> 1. Change the name of your registry to "Hash A= lgorithms for HTTP
> > > >> Digest Authentication", to make it clear that = this has to do
> > > >> with HTTP
> > > >> Digest Authentication.=A0 The order of the words is= important, to
> > > >> make
> > > >> sure it's clear that "Authentication"= is tightly bound to "HTTP
> > > >> Digest" here.
> > > >>
> > > >> 2. Add a brief description to the new registry'= s header that
> > > >> says that
> > > >> this registry lists the hash algorithms that can be= used in HTTP
> > > >> Digest Authentication.
> > > >>
> > > >> 3. Add a brief description to the existing "HT= TP Digest
> > > >> Algorithm
> > > >> Values" registry that says that this registry = lists the
> > > >> algorithms
> > > >> that can be used when creating digests of an HTTP m= essage body,
> > > >> as
> > > >> specified in RFC 3230.
> > > >>
> > > >> I think that will adequately distinguish these two = registries,
> > > >> and
> > > >> avoid confusion between them.
> > > >>
> > > >> What do you think?
> > > >>
> > > >
> > > > Sounds reasonable to me.
> > > >
> > > > I appreciate your help with this, Barry!
> > > >
> > > > Regards,
> > > >=A0 Rifaat
> > > >
> > > >
> > > >
> > > >>
> > > >> Barry
> > > >>
> > > >
> > > >
> >
> >
> >




--001a11c21ff060806305130d8215-- From nobody Mon Apr 6 05:45:11 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DA7441A8860; Mon, 6 Apr 2015 05:44:16 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B731A885F for ; Mon, 6 Apr 2015 05:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] 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 zsSSXf_GgcU3 for ; Mon, 6 Apr 2015 05:44:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E9E1A885B for ; Mon, 6 Apr 2015 05:44:16 -0700 (PDT) Received: from mail-ig0-x229.google.com ([2607:f8b0:4001:c05::229]:34677) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yf6Ny-0005yD-SQ for draft-ietf-httpauth-digest.all@tools.ietf.org; Mon, 06 Apr 2015 05:44:15 -0700 Received: by iget9 with SMTP id t9so294038ige.1 for ; Mon, 06 Apr 2015 05:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gR3B7PHSYyqGgPPoliUBGlV5vTNhqtDxFOkwIZLkLu0=; b=vortf+FIL0/mTMM4lJII2cN3UFT40rFX+GRGBrENLjItZr+QMuk8Sed8DRlS26IGu9 WfrdBglGHLhC9q7E/iaLFtST3HBvm/ilH2VQYQvfAt+2oUDVPtvm0jDsQaf7XJL+W67n qzs3ZBKCQoVdqj1weCXMueCgcLtJ4xluZaMM+23KAXG/nqTraEzTCTCB08fJcqAKEEXs coAwyfSUjOzs3Yq2xkt6WyZZb25yI3JXVa2D7G9nqD5ViXlyK9axY235NavYNKil/BsD acwrNkeh+RsnLi9p4OYW2QfIPHnALzr7CWQnBjZbLBboFp0DigFasyMMQj/CHUX6bDGl ih4A== MIME-Version: 1.0 X-Received: by 10.107.3.17 with SMTP id 17mr21554442iod.60.1428324247614; Mon, 06 Apr 2015 05:44:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Mon, 6 Apr 2015 05:44:07 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Mon, 6 Apr 2015 08:44:07 -0400 X-Google-Sender-Auth: jQsvVs816fuy8l96yObEyfwTyZY Message-ID: From: Barry Leiba To: Rifaat Shekh-Yusef Content-Type: text/plain; charset=ISO-8859-1 X-SA-Exim-Connect-IP: 2607:f8b0:4001:c05::229 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: barryleiba@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150406124416.02E9E1A885B@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 05:44:16 -0700 (PDT) Resent-From: barryleiba@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 05:45:10 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG , "liang@icann.org" Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 06 Apr 2015 12:44:17 -0000 > Did we address all you questions with the last email below? Actually, I meant to reply to this, but seder stuff got in the way. Sorry... >> That comment should go into the existing "HTTP Digest Algorithm Values" >> registry, as it does not apply to the new "Hash Algorithms for HTTP Digest >> Authentication" registry. >> So the comment you quoted cannot go into this document. I think it's perfectly reasonable for you to put the update to the existing registry into this document, in the IANA Considerations section. Something like this: NEW To clarify the purpose of the existing registry and to avoid confusion between the two registries, IANA is asked to add the following description to the existing "HTTP Digest Algorithm Values" registry: This registry lists the algorithms that can be used when creating digests of an HTTP message body, as specified in RFC 3230. END I think you can do that without including a reference to RFC 3230 in your document, because you're just providing text for IANA, and not actually making any real reference (and if anyone questions that, I'll be happy to discuss it with them). Barry From nobody Mon Apr 6 06:03:52 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 324D11A887B; Mon, 6 Apr 2015 05:58:03 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBEF1A887A for ; Mon, 6 Apr 2015 05:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 jYvPFk1xO9gM for ; Mon, 6 Apr 2015 05:58:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA561A8879 for ; Mon, 6 Apr 2015 05:58:02 -0700 (PDT) Received: from mail-ob0-x22b.google.com ([2607:f8b0:4003:c01::22b]:35019) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yf6bI-0000hC-Hh for draft-ietf-httpauth-digest.all@tools.ietf.org; Mon, 06 Apr 2015 05:58:01 -0700 Received: by obbfy7 with SMTP id fy7so38656322obb.2 for ; Mon, 06 Apr 2015 05:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qlYilm79tvnUWciyrZDSp8bLxMXK0gnNKZApwPUpLFc=; b=ag2p9aTkPtR4NNusTy/AckUFvnZYwS+2ofqlq3q50MasC5P1gi5iDMrzmcQKTRER0V mnh9zXkIg2w+nOXCshRRVWCgLSg2pKlQaejUPD75J12D7KUloiehK5WIlZB/qvz4YXbb hF5MJsaiMcqVeE330uaLi/5QvGuj5uk/tU5xyJ638WV/PoKGwpTDsK4iWQnj7onYnuBy WqqO16gOhd7bOb70C/78ddnJTlzlVUASkllvVJedHVONXgmUZe/sIJ/Avmd/vgyqeqap sNSQKwX02Oo28Fe5WNDJj+MBMX+Jl36bmWXxVgtSwUBGdMmhi9Qr0G/KoJTeG43t1UUN VwhA== MIME-Version: 1.0 X-Received: by 10.60.133.176 with SMTP id pd16mr18333214oeb.78.1428325074433; Mon, 06 Apr 2015 05:57:54 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Mon, 6 Apr 2015 05:57:54 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Mon, 6 Apr 2015 08:57:54 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b472876af7bb405130dd8a9 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::22b X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150406125802.0AA561A8879@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 05:58:02 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 06:03:49 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG , "liang@icann.org" Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 06 Apr 2015 12:58:03 -0000 --047d7b472876af7bb405130dd8a9 Content-Type: text/plain; charset=ISO-8859-1 Hmmm, this seems odd to me,but I have no problem of doing that. Kathleen, Are you ok with this? Rgards, Rifaat On Mon, Apr 6, 2015 at 8:44 AM, Barry Leiba wrote: > > Did we address all you questions with the last email below? > > Actually, I meant to reply to this, but seder stuff got in the way. > Sorry... > > >> That comment should go into the existing "HTTP Digest Algorithm Values" > >> registry, as it does not apply to the new "Hash Algorithms for HTTP > Digest > >> Authentication" registry. > >> So the comment you quoted cannot go into this document. > > I think it's perfectly reasonable for you to put the update to the > existing registry into this document, in the IANA Considerations > section. Something like this: > > NEW > To clarify the purpose of the existing registry and to avoid confusion > between the two registries, IANA is asked to add the following > description to the existing "HTTP Digest Algorithm Values" registry: > > This registry lists the algorithms that can be used when creating > digests of an HTTP message body, as specified in RFC 3230. > > END > > I think you can do that without including a reference to RFC 3230 in > your document, because you're just providing text for IANA, and not > actually making any real reference (and if anyone questions that, I'll > be happy to discuss it with them). > > Barry > --047d7b472876af7bb405130dd8a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hmmm, this seems odd to me,but I have no problem of d= oing that.


Kathleen,
=
Are you ok with this?

Rgards,
=
=A0Rifaat


On Mon, Apr 6, 2015 at 8:44 AM, Barry Leiba <barryleiba@computer.org> wrote:
> Did we address all you questions with the last = email below?

Actually, I meant to reply to this, but seder stuff got in the way.= =A0 Sorry...

>> That comment should go into the existing "HTTP Digest Algorit= hm Values"
>> registry, as it does not apply to the new "Hash Algorithms fo= r HTTP Digest
>> Authentication" registry.
>> So the comment you quoted cannot go into this document.

I think it's perfectly reasonable for you to put the update to t= he
existing registry into this document, in the IANA Considerations
section.=A0 Something like this:

NEW
To clarify the purpose of the existing registry and to avoid confusion
between the two registries, IANA is asked to add the following
description to the existing "HTTP Digest Algorithm Values" regist= ry:

=A0 =A0This registry lists the algorithms that can be used when creating =A0 =A0digests of an HTTP message body, as specified in RFC 3230.

END

I think you can do that without including a reference to RFC 3230 in
your document, because you're just providing text for IANA, and not
actually making any real reference (and if anyone questions that, I'll<= br> be happy to discuss it with them).

Barry

--047d7b472876af7bb405130dd8a9-- From nobody Mon Apr 6 06:03:53 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2489C1A888B; Mon, 6 Apr 2015 06:03:07 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085F31A888A for ; Mon, 6 Apr 2015 06:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] 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 ebczCJGdP9j4 for ; Mon, 6 Apr 2015 06:03:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EEE1A8888 for ; Mon, 6 Apr 2015 06:03:05 -0700 (PDT) Received: from mail-ig0-x229.google.com ([2607:f8b0:4001:c05::229]:36661) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yf6gC-00021I-3k for draft-ietf-httpauth-digest.all@tools.ietf.org; Mon, 06 Apr 2015 06:03:05 -0700 Received: by igblo3 with SMTP id lo3so20212862igb.1 for ; Mon, 06 Apr 2015 06:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YebMURD9b5X+RpBLZEaYX4RDX0idv5X/dTMp/qQbwMU=; b=uPV0LybSvYt4KxOHWdH28fI2dKiwA7z53rOLgiRaZ4DoBaLCAqik9OVQJVbiBCMLm7 lN+aTA4OlFLLBLUWRRRchyArfC52L0Z0k6LMu1SfHUem91C+/4srWMS/NM9WZeAuNV08 2xOU0Uctlhvz7lge3FDGPev60/mKR4cNyXLbIioMeV+oI6dji3qdbkU0crZ1XrmidEVJ atL3IHQFfCYhEOua7+SctOUqq5RcvB2qM3caMtmy2JkjqsfHJD7jbAQaeahHGPv/D5Uq gFKnfkrjfUMpBy//KD/x9w3UoJAMHKC2KDu4/iCzFsX91UIHVSE5z2QsAQpvsheB+flt ahUA== MIME-Version: 1.0 X-Received: by 10.107.29.21 with SMTP id d21mr22665393iod.11.1428325378042; Mon, 06 Apr 2015 06:02:58 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Mon, 6 Apr 2015 06:02:57 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Mon, 6 Apr 2015 09:02:57 -0400 X-Google-Sender-Auth: suFGk-PPtxL-skq_nlrSKb5XHFM Message-ID: From: Barry Leiba To: Rifaat Shekh-Yusef Content-Type: text/plain; charset=ISO-8859-1 X-SA-Exim-Connect-IP: 2607:f8b0:4001:c05::229 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: barryleiba@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150406130305.67EEE1A8888@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 06:03:05 -0700 (PDT) Resent-From: barryleiba@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 06:03:49 -0700 Cc: Pearl Liang via RT , draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG , "liang@icann.org" Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 06 Apr 2015 13:03:07 -0000 > Hmmm, this seems odd to me,but I have no problem of doing that. Clarifying the reason: IANA likes to have the changes they're asked to make recorded (documented) somewhere, and I think it's better to have it in the draft than to just have it in this email thread. That said, I'm fine with however IANA agrees to do it. b From nobody Mon Apr 6 11:01:06 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 78C1F1A9075; Mon, 6 Apr 2015 10:59:32 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504631A9073 for ; Mon, 6 Apr 2015 10:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.515 X-Spam-Level: X-Spam-Status: No, score=0.515 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, SPF_SOFTFAIL=0.665] 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 UUSu2aIDjGlT for ; Mon, 6 Apr 2015 10:59:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F631A906E for ; Mon, 6 Apr 2015 10:59:31 -0700 (PDT) Received: from givry.fdupont.fr ([2001:41d0:1:6d55:211:5bff:fe98:d51e]:14562) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfBJ3-0001nn-VA for draft-ietf-httpauth-digest.all@tools.ietf.org; Mon, 06 Apr 2015 10:59:31 -0700 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id t36HwgRi005964; Mon, 6 Apr 2015 19:58:42 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201504061758.t36HwgRi005964@givry.fdupont.fr> From: Francis Dupont To: gen-art@ietf.org Date: Mon, 06 Apr 2015 19:58:42 +0200 Sender: Francis.Dupont@fdupont.fr X-SA-Exim-Connect-IP: 2001:41d0:1:6d55:211:5bff:fe98:d51e X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: Francis.Dupont@fdupont.fr X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150406175931.53F631A906E@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 10:59:31 -0700 (PDT) Resent-From: Francis.Dupont@fdupont.fr Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 11:01:05 -0700 Cc: draft-ietf-httpauth-digest.all@tools.ietf.org Subject: [http-auth] review of draft-ietf-httpauth-digest-15.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: Mon, 06 Apr 2015 17:59:32 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-httpauth-digest-15.txt Reviewer: Francis Dupont Review Date: 20150402 IETF LC End Date: 20150402 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: I reviewed the 15 version but I can see the 16 one is already available so I'll try to update my comments. - first I was a bit surprised nobody just asked to jump to HTTPS (or HSTS) but reading the document it seems there are still good use of the digest authentication scheme... - 3.3 page 5: IMHO the "opaque" field is clearly a nonce (i.e., more a nonce than the "nonce" field) but I understand this was inherited from RFC 2617... - 3.3 page 7 (algorithm, twice) and some other places: e.g. -> e.g., - 3.3 page 7 (algorithm): I noted the algo protocol is still a keyed one vs. HMAC (cf. AH which switched from keyed to HMAC between RFC 1826 and RFC 2402) but I believed you have a good reason to do this (and the secdir will say if it is OK anyway). - 3.4.2 page 11: e.g. -> e.g., (again but this one is at the end of a line) - 3.4.2 page 11: cnounce -> cnonce - 3.4.2 page 11: the presentation of this definition is very misleading: A1 = H( unq(username) ":" unq(realm) ":" passwd ) ":" unq(nonce-prime) ":" unq(cnonce-prime) I strongly suggest something like: A1 = H( unq(username) ":" unq(realm) ":" passwd ) ":" unq(nonce-prime) ":" unq(cnonce-prime) - 3.4.2 page 11: the server need only use ^ needs - 3.5 page 14: affects -> effects - 5.2 page 21: this information need not be decrypted ^ needs - 6.1 page 27: can you instantiate the RFC XXX: MD5: RFC 1321 SHA-256: FIPS 180-2 SHA-512/256: FIPS 180-4? - A page 30: negotitation -> negotiation Regards Francis.Dupont@fdupont.fr From nobody Mon Apr 6 13:10:37 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 46B721A910A; Mon, 6 Apr 2015 13:01:31 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219171A9109 for ; Mon, 6 Apr 2015 13:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 q3945EKr1ObY for ; Mon, 6 Apr 2015 13:01:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912FD1A9108 for ; Mon, 6 Apr 2015 13:01:29 -0700 (PDT) Received: from mail-ob0-x230.google.com ([2607:f8b0:4003:c01::230]:36675) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfDD6-0005IS-8i for draft-ietf-httpauth-digest.all@tools.ietf.org; Mon, 06 Apr 2015 13:01:29 -0700 Received: by obbec2 with SMTP id ec2so57063687obb.3 for ; Mon, 06 Apr 2015 13:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fkGdR5F/JA5IaCbjBOY+iJwhteK1f+SuaFPD98hzl+Y=; b=UetxTOVqxPterFwIPIq7d+hFhDNSjjw/qOoa3LoFuWyetCyD6aZJRA31KpM9F1CAzQ EeeFK14t8x6IvLNhoeZD+85/H6/QiwFOrkxJxxJkUqCypfm0ctuwU121djViwBQlIoZm zo8i/WTJCwt4OVvklC0N+lk7BQwXyn1KgWoUHxBC+Fg5eCZyREP7Z8eA4M5rK3JJM04k oNk3eMu8eccCo9tm38iFwMchPBjc3kttMl6bKtr7hxoRejAbEJG4QppIZjuwHL1Il5vq azWdp28mNff/DkdZiHjuGgT14rleh3Z9qYzwV2C6P/DV/OLMEL3M9reobB+doS6WlI7O tiyw== MIME-Version: 1.0 X-Received: by 10.182.227.132 with SMTP id sa4mr20823253obc.40.1428350482593; Mon, 06 Apr 2015 13:01:22 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Mon, 6 Apr 2015 13:01:22 -0700 (PDT) In-Reply-To: <201504061758.t36HwgRi005964@givry.fdupont.fr> References: <201504061758.t36HwgRi005964@givry.fdupont.fr> Date: Mon, 6 Apr 2015 16:01:22 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Francis Dupont Content-Type: multipart/alternative; boundary=001a11c2ee9e213a65051313c3f9 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::230 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150406200129.912FD1A9108@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 13:01:29 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 13:10:35 -0700 Cc: "gen-art@ietf.org" , draft-ietf-httpauth-digest.all@tools.ietf.org Subject: Re: [http-auth] review of draft-ietf-httpauth-digest-15.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: Mon, 06 Apr 2015 20:01:31 -0000 --001a11c2ee9e213a65051313c3f9 Content-Type: text/plain; charset=ISO-8859-1 Hi Francis, Thanks for your review and comments. I will address the nits in the next version of the draft. Please, see my reply to some of your comments inline... Regards, Rifaat On Mon, Apr 6, 2015 at 1:58 PM, Francis Dupont wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-httpauth-digest-15.txt > Reviewer: Francis Dupont > Review Date: 20150402 > IETF LC End Date: 20150402 > IESG Telechat date: unknown > > Summary: Ready > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > I reviewed the 15 version but I can see the 16 one is already available > so I'll try to update my comments. > > - first I was a bit surprised nobody just asked to jump to HTTPS (or > HSTS) but reading the document it seems there are still good use > of the digest authentication scheme... > > - 3.3 page 5: IMHO the "opaque" field is clearly a nonce > (i.e., more a nonce than the "nonce" field) but I understand this > was inherited from RFC 2617... > > - 3.3 page 7 (algorithm, twice) and some other places: > e.g. -> e.g., > > - 3.3 page 7 (algorithm): I noted the algo protocol is still > a keyed one vs. HMAC (cf. AH which switched from keyed to HMAC > between RFC 1826 and RFC 2402) but I believed you have a good > reason to do this (and the secdir will say if it is OK anyway). > > Good question. Using HMAC would impact the H(A1) calculation and the KD function, but it would definitely work. If there is interest and support for adding HMAC, I would be happy to do that. > - 3.4.2 page 11: e.g. -> e.g., (again but this one is at the end of a > line) > > - 3.4.2 page 11: cnounce -> cnonce > > - 3.4.2 page 11: the presentation of this definition is very > misleading: > > A1 = H( unq(username) ":" unq(realm) > ":" passwd ) > ":" unq(nonce-prime) ":" unq(cnonce-prime) > > I strongly suggest something like: > > A1 = H( unq(username) ":" unq(realm) ":" passwd ) > ":" unq(nonce-prime) ":" unq(cnonce-prime) > > Sure. > - 3.4.2 page 11: the server need only use > ^ needs > > - 3.5 page 14: affects -> effects > > - 5.2 page 21: this information need not be decrypted > ^ needs > > - 6.1 page 27: can you instantiate the RFC XXX: > MD5: RFC 1321 > SHA-256: FIPS 180-2 > SHA-512/256: FIPS 180-4? > > The RFC used in the table should point to the current draft which does not have an RFC # yet. Kathleen has already raised an issue about this and she suggested a text that was added to v16. Regards, Rifaat > - A page 30: negotitation -> negotiation > > Regards > > Francis.Dupont@fdupont.fr > --001a11c2ee9e213a65051313c3f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Francis,

Thanks for your review and = comments. I will address the nits in the next version of the draft.
Please, see my reply to some of your comments inline...

Regards,
=A0Rifaat


On Mon, Apr 6, 2015 at 1:58 PM, Fr= ancis Dupont <Francis.Dupont@fdupont.fr> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">I am the assigned Gen-ART reviewer for this d= raft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&= gt;.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-httpauth-digest-15.txt
Reviewer: Francis Dupont
Review Date: 20150402
IETF LC End Date: 20150402
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
=A0I reviewed the 15 version but I can see the 16 one is already available<= br> so I'll try to update my comments.

=A0- first I was a bit surprised nobody just asked to jump to HTTPS (or
=A0 HSTS) but reading the document it seems there are still good use
=A0 of the digest authentication scheme...

=A0-=A0 3.3 page 5: IMHO the "opaque" field is clearly a nonce =A0 (i.e., more a nonce than the "nonce" field) but I understand = this
=A0 was inherited from RFC 2617...

=A0- 3.3 page 7 (algorithm, twice) and some other places:
=A0 e.g. -> e.g.,

=A0- 3.3 page 7 (algorithm): I noted the algo protocol is still
=A0 a keyed one vs. HMAC (cf. AH which switched from keyed to HMAC
=A0 between RFC 1826 and RFC 2402) but I believed you have a good
=A0 reason to do this (and the secdir will say if it is OK anyway).


Good question.
Using HMAC wo= uld impact the H(A1) calculation and the KD function, but it would definite= ly work.
If there is interest and support for adding HMAC, I woul= d be happy to do that.

=A0
=A0- 3.4.2 page 11: e.g. -> e.g., (again but this one is at the end of a= line)

=A0- 3.4.2 page 11: cnounce -> cnonce

=A0- 3.4.2 page 11: the presentation of this definition is very
=A0misleading:

=A0 =A0 =A0 =A0 =A0A1=A0 =A0 =A0 =A0=3D H( unq(username) ":" unq(= realm)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ":" passwd )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ":" unq(nonce-pri= me) ":" unq(cnonce-prime)

=A0 I strongly suggest something like:

=A0 =A0 =A0 =A0 =A0A1=A0 =A0 =A0 =A0=3D H( unq(username) ":" unq(= realm) ":" passwd )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ":" unq(nonce-pri= me) ":" unq(cnonce-prime)


Sure.

=A0
=A0- 3.4.2 page 11: the server need only use
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^ needs<= br>
=A0- 3.5 page 14: affects -> effects

=A0- 5.2 page 21: this information need not be decrypted
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= ^ needs

=A0- 6.1 page 27: can you instantiate the RFC XXX:
=A0 MD5: RFC 1321
=A0 SHA-256: FIPS 180-2
=A0 SHA-512/256: FIPS 180-4?


The RFC used in the table should point= to the current draft which does not have an RFC # yet.
Kathleen = has already raised an issue about this and she suggested a text that was ad= ded to v16.

Regards,
=A0Rifaat

=A0
=A0- A page 30: negotitation -> negotiation

Regards

Francis.Dupo= nt@fdupont.fr

--001a11c2ee9e213a65051313c3f9-- From nobody Mon Apr 6 22:01:33 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D73E21B2EA9; Mon, 6 Apr 2015 20:21:43 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B637E1B2EA7 for ; Mon, 6 Apr 2015 20:21:43 -0700 (PDT) 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, MISSING_HEADERS=1.021] 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 zGJWUAnbn8aA for ; Mon, 6 Apr 2015 20:21:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0985F1B2E9D for ; Mon, 6 Apr 2015 20:21:43 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:39454 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfK57-0006uz-UX for draft-ietf-httpauth-digest.all@tools.ietf.org; Mon, 06 Apr 2015 20:21:42 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t373LYpr031515; Tue, 7 Apr 2015 03:21:34 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 67CB9C2081D; Tue, 7 Apr 2015 03:21:34 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #817019 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 07 Apr 2015 03:21:34 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150407032143.0985F1B2E9D@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 20:21:43 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 22:01:33 -0700 Cc: barryleiba@computer.org, draft-ietf-httpauth-digest.all@tools.ietf.org Subject: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 03:21:44 -0000 Hi all, I think Barry's suggested text for the registry is very useful. It gives guidelines to future users (and authors). As Barry mentioned, we need to be able to point people to a source of the text. If this draft is indeed not an appropriate place, I think we just need an "Okay" from ADs before we can add the Note in the registry. Barry, does this sound right? Thanks ~pl On Mon Apr 06 13:03:19 2015, barryleiba@computer.org wrote: > > Hmmm, this seems odd to me,but I have no problem of doing that. > > Clarifying the reason: IANA likes to have the changes they're asked to > make recorded (documented) somewhere, and I think it's better to have > it in the draft than to just have it in this email thread. > > That said, I'm fine with however IANA agrees to do it. > > b > From nobody Tue Apr 7 05:23:22 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BFDB11A8741; Tue, 7 Apr 2015 05:22:51 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20201A873E for ; Tue, 7 Apr 2015 05:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 DX5sTRz_YI27 for ; Tue, 7 Apr 2015 05:22:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E151A873B for ; Tue, 7 Apr 2015 05:22:50 -0700 (PDT) Received: from mail-ob0-x22c.google.com ([2607:f8b0:4003:c01::22c]:34511) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfSWn-0004eL-0h for draft-ietf-httpauth-digest.all@tools.ietf.org; Tue, 07 Apr 2015 05:22:50 -0700 Received: by obbgh1 with SMTP id gh1so83343464obb.1 for ; Tue, 07 Apr 2015 05:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8QJTGwmqb/HV8QaEOR9I+m1LhITQHZhqqkAsGu3Gmto=; b=lqlnYxXxPb4J+iypuiuP8X1fv/knq53yaqLDRjmDnmz0buu+NdXli83yKPcROTVgrK AuMaNSL0RFmzPgJSrWhTKuwOEnTWd+QLOTd8yTyNZnnQkl+btkOHywAPAuBjyW1MN5QR EYeOkWUMo5thDSf6sFB8MaAVlJqqXqxbWsWRNi3U3wcCGDgoi2nSOihP//xZZcvhSxDZ UfqFfc2hoeQ9JjOy9MZT1E6f5cZTq0sEh0GysCbF1ywdrL/1zhSGyZzwT4jbzF5cOs0a rh9s99v/oKSm/amHKsKw8cJ3cySGj5WbmuHGb52Ci4GyBRHO752oxFYECQDVVFNe3PVv c7hA== MIME-Version: 1.0 X-Received: by 10.182.19.167 with SMTP id g7mr24807476obe.75.1428409361322; Tue, 07 Apr 2015 05:22:41 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Tue, 7 Apr 2015 05:22:41 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Tue, 7 Apr 2015 08:22:41 -0400 Message-ID: From: Rifaat Shekh-Yusef To: iana-issues@iana.org Content-Type: multipart/alternative; boundary=001a11c2ea20935886051321782c X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::22c X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150407122250.76E151A873B@ietfa.amsl.com> Resent-Date: Tue, 7 Apr 2015 05:22:50 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 05:23:21 -0700 Cc: Barry Leiba , draft-ietf-httpauth-digest.all@tools.ietf.org Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 07 Apr 2015 12:22:51 -0000 --001a11c2ea20935886051321782c Content-Type: text/plain; charset=ISO-8859-1 I do not have a strong opinion about this, so I can go either way. If I do not hear any objection from the ADs today, I will spin another version with the proposed change from Barry. Regards, Rifaat On Mon, Apr 6, 2015 at 11:21 PM, Pearl Liang via RT wrote: > Hi all, > > I think Barry's suggested text for the registry is very useful. It gives > guidelines > to future users (and authors). As Barry mentioned, we need to be able to > point > people to a source of the text. If this draft is indeed not an > appropriate place, > I think we just need an "Okay" from ADs before we can add the Note in the > registry. > Barry, does this sound right? > > Thanks > ~pl > > > On Mon Apr 06 13:03:19 2015, barryleiba@computer.org wrote: > > > Hmmm, this seems odd to me,but I have no problem of doing that. > > > > Clarifying the reason: IANA likes to have the changes they're asked to > > make recorded (documented) somewhere, and I think it's better to have > > it in the draft than to just have it in this email thread. > > > > That said, I'm fine with however IANA agrees to do it. > > > > b > > > > > --001a11c2ea20935886051321782c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I do not have a strong opinion about this, so I can go eit= her way.
If I do not hear any objection from the ADs today, I will spin= another version with the proposed change from Barry.

<= div>Regards,
=A0Rifaat


On Mon, Apr 6, 2015 at 11:21 PM, = Pearl Liang via RT <iana-issues@iana.org> wrote:
Hi all,

I think Barry's suggested text for the registry is very useful.=A0 It g= ives guidelines
to future users (and authors).=A0 As Barry mentioned, we need to be able to= point
people to a source of the text.=A0 If this draft is indeed not an appropria= te place,
I think we just need an "Okay" from ADs before we can add the Not= e in the registry.
Barry, does this sound right?

Thanks
~pl


On Mon Apr 06 13:03:19 2015, bar= ryleiba@computer.org wrote:
> > Hmmm, this seems odd to me,but I have no problem of doing that. >
> Clarifying the reason: IANA likes to have the changes they're aske= d to
> make recorded (documented) somewhere, and I think it's better to h= ave
> it in the draft than to just have it in this email thread.
>
> That said, I'm fine with however IANA agrees to do it.
>
> b
>



--001a11c2ea20935886051321782c-- From nobody Tue Apr 7 16:29:36 2015 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 747321AC3AB; Tue, 7 Apr 2015 16:29:32 -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] 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 SUBvgjuTPZQo; Tue, 7 Apr 2015 16:29:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C95251ABD3F; Tue, 7 Apr 2015 16:29:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407232930.26315.53316.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 16:29:30 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-17.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, 07 Apr 2015 23:29:32 -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 : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-17.txt Pages : 30 Date : 2015-04-07 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPAuth working group mailing list (http-auth@ietf.org), which is archived at [1]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-17 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 Apr 7 16:29:38 2015 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 AED011AC398; Tue, 7 Apr 2015 16:29:33 -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] 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 pDmzVKeVSxMG; Tue, 7 Apr 2015 16:29:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C921AC39F; Tue, 7 Apr 2015 16:29:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407232930.26315.15551.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 16:29:30 -0700 Archived-At: Subject: [http-auth] New Version Notification - draft-ietf-httpauth-digest-17.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, 07 Apr 2015 23:29:33 -0000 A new version (-17) has been submitted for draft-ietf-httpauth-digest: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-digest-17.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-17 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. IETF Secretariat. From nobody Tue Apr 7 20:41:01 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CD8C41AC3DB; Tue, 7 Apr 2015 16:32:26 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23F11ABD3F for ; Tue, 7 Apr 2015 16:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 wuADCapcHR1b for ; Tue, 7 Apr 2015 16:32:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0E21AC3D8 for ; Tue, 7 Apr 2015 16:32:25 -0700 (PDT) Received: from mail-ob0-x231.google.com ([2607:f8b0:4003:c01::231]:34346) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yfcyn-0006nD-1l for draft-ietf-httpauth-digest.all@tools.ietf.org; Tue, 07 Apr 2015 16:32:25 -0700 Received: by obbgh1 with SMTP id gh1so108836670obb.1 for ; Tue, 07 Apr 2015 16:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=by5f3W/FHizyUeSuPeB5wUmF2/CkTA3cdsnf6bbXzDw=; b=VdXwDNOL8g18Evc2OeCOdVOuWmZpbevpeFRnmXzVIrkQsY/AoofAFv6lwcShpVPJxk T3ZG+R3qKzLeqNb2+eorUNUPS3VZyx/wrfuG/tnXa+Isnj99BGM0XzN8ErPVoCwobMpr 2KHXs2Ea+PkfEnwiqul/3SWLSMGX9Gx56FLIGHX7Hq1PeyiWFoAu3qy8XgbBxUpVlbbp t6sSWchoUxBVS33vZ5OYkqbLhkw52FK8whujnfR/KXHoX+k4Ahe5lRoqSECyrUKxggoI surkHo/2eNw4HqvL4Ucp/T3HrufOp3W6iwLKy+NLwvMnFD/Xas1vPmumRv+7EADQPKBL tquA== MIME-Version: 1.0 X-Received: by 10.60.134.199 with SMTP id pm7mr28384034oeb.36.1428449537756; Tue, 07 Apr 2015 16:32:17 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Tue, 7 Apr 2015 16:32:17 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Tue, 7 Apr 2015 19:32:17 -0400 Message-ID: From: Rifaat Shekh-Yusef To: iana-issues@iana.org Content-Type: multipart/alternative; boundary=047d7b41cd3447118105132ad38e X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::231 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150407233225.BB0E21AC3D8@ietfa.amsl.com> Resent-Date: Tue, 7 Apr 2015 16:32:25 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 20:41:00 -0700 Cc: Barry Leiba , draft-ietf-httpauth-digest.all@tools.ietf.org Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 07 Apr 2015 23:32:27 -0000 --047d7b41cd3447118105132ad38e Content-Type: text/plain; charset=ISO-8859-1 Hi Pearl, Please, take a look at v17 and let me know if that addresses all your concerns. Regards, Rifaat On Mon, Apr 6, 2015 at 11:21 PM, Pearl Liang via RT wrote: > Hi all, > > I think Barry's suggested text for the registry is very useful. It gives > guidelines > to future users (and authors). As Barry mentioned, we need to be able to > point > people to a source of the text. If this draft is indeed not an > appropriate place, > I think we just need an "Okay" from ADs before we can add the Note in the > registry. > Barry, does this sound right? > > Thanks > ~pl > > > On Mon Apr 06 13:03:19 2015, barryleiba@computer.org wrote: > > > Hmmm, this seems odd to me,but I have no problem of doing that. > > > > Clarifying the reason: IANA likes to have the changes they're asked to > > make recorded (documented) somewhere, and I think it's better to have > > it in the draft than to just have it in this email thread. > > > > That said, I'm fine with however IANA agrees to do it. > > > > b > > > > > --047d7b41cd3447118105132ad38e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pearl,

Please, take a look at v17 an= d let me know if that addresses all your concerns.

Regards,
=A0Rifaat


On Mon, Apr 6, 2015 at 11:21 PM, Pea= rl Liang via RT <iana-issues@iana.org> wrote:
Hi all,

I think Barry's suggested text for the registry is very useful.=A0 It g= ives guidelines
to future users (and authors).=A0 As Barry mentioned, we need to be able to= point
people to a source of the text.=A0 If this draft is indeed not an appropria= te place,
I think we just need an "Okay" from ADs before we can add the Not= e in the registry.
Barry, does this sound right?

Thanks
~pl


On Mon Apr 06 13:03:19 2015, bar= ryleiba@computer.org wrote:
> > Hmmm, this seems odd to me,but I have no problem of doing that. >
> Clarifying the reason: IANA likes to have the changes they're aske= d to
> make recorded (documented) somewhere, and I think it's better to h= ave
> it in the draft than to just have it in this email thread.
>
> That said, I'm fine with however IANA agrees to do it.
>
> b
>



--047d7b41cd3447118105132ad38e-- From nobody Wed Apr 8 10:35:27 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8372F1B330D; Wed, 8 Apr 2015 09:00:36 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3521B339F for ; Wed, 8 Apr 2015 09:00:36 -0700 (PDT) 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, MISSING_HEADERS=1.021] 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 1ltKT98GJur3 for ; Wed, 8 Apr 2015 09:00:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0191B330C for ; Wed, 8 Apr 2015 08:57:57 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:53006 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfsMW-0008JB-PU for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 08 Apr 2015 08:57:57 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t38FvnRA015634; Wed, 8 Apr 2015 15:57:49 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 73BA1C20819; Wed, 8 Apr 2015 15:57:49 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #817019 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 08 Apr 2015 15:57:49 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150408155757.8A0191B330C@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 08:57:57 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 10:35:26 -0700 Cc: barryleiba@computer.org, draft-ietf-httpauth-digest.all@tools.ietf.org Subject: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 16:00:36 -0000 Hi Rifaat, Thank you. This version looks okay. Barry, please chime if we missed anything else. Regards, ~pl On Tue Apr 07 23:32:40 2015, rifaat.ietf@gmail.com wrote: > Hi Pearl, > > Please, take a look at v17 and let me know if that addresses all your > concerns. > > Regards, > Rifaat > > > On Mon, Apr 6, 2015 at 11:21 PM, Pearl Liang via RT > wrote: > > > Hi all, > > > > I think Barry's suggested text for the registry is very useful. It gives > > guidelines > > to future users (and authors). As Barry mentioned, we need to be able to > > point > > people to a source of the text. If this draft is indeed not an > > appropriate place, > > I think we just need an "Okay" from ADs before we can add the Note in the > > registry. > > Barry, does this sound right? > > > > Thanks > > ~pl > > > > > > On Mon Apr 06 13:03:19 2015, barryleiba@computer.org wrote: > > > > Hmmm, this seems odd to me,but I have no problem of doing that. > > > > > > Clarifying the reason: IANA likes to have the changes they're asked to > > > make recorded (documented) somewhere, and I think it's better to have > > > it in the draft than to just have it in this email thread. > > > > > > That said, I'm fine with however IANA agrees to do it. > > > > > > b > > > > > > > > > From nobody Wed Apr 8 11:19:35 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 25F9D1A8A77; Wed, 8 Apr 2015 11:18:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027671A8A6E for ; Wed, 8 Apr 2015 11:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] 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 Blks6EickGLT for ; Wed, 8 Apr 2015 11:18:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286E31A8A4D for ; Wed, 8 Apr 2015 11:17:10 -0700 (PDT) Received: from mail-ie0-x235.google.com ([2607:f8b0:4001:c03::235]:36086) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfuXF-0007Y9-04 for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 08 Apr 2015 11:17:10 -0700 Received: by iebrs15 with SMTP id rs15so81598105ieb.3 for ; Wed, 08 Apr 2015 11:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oUra2xyKICMA3exq9jElyMGcaNAg2zTiJFOiI8BiMpE=; b=r+INAZ7ggGO/GxLr1eVcJy/hpucueODVShdd2gztMG+M07+1qbmKhRkxU5xXYCg0SH R2Z/JXw1k7uM5W8Qv6gBBUxT4D5ZJr9B3YW4lPrxLMIQR6/gkzm4EjUCHuZvq26XKhYg v2YSmx3JWg9n/Y1JXHtjrP8Mz7eonJ2JDe3TkxFBwozKdBKKo5duwjLStrMTEVU+C/hZ cwpqzL92pP306zjtEiZUAvIYWmoDe3hp8PGqbiMWbXZzIPols6J6ihvg02Cni4UEZPta aiQtoOVXby8gRoYTVXtUrLc+/bMbyGbxcO3aMmwV6pKMDwA7Y2z9wmMxmv9kES2GV8Dm 7Fow== MIME-Version: 1.0 X-Received: by 10.50.30.130 with SMTP id s2mr14109235igh.11.1428517021627; Wed, 08 Apr 2015 11:17:01 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 11:17:01 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Wed, 8 Apr 2015 14:17:01 -0400 X-Google-Sender-Auth: Q0fqKosyIsdmqsg4vooRGQWUZhs Message-ID: From: Barry Leiba To: "iana-issues@iana.org" Content-Type: text/plain; charset=ISO-8859-1 X-SA-Exim-Connect-IP: 2607:f8b0:4001:c03::235 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: barryleiba@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150408181710.286E31A8A4D@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 11:17:10 -0700 (PDT) Resent-From: barryleiba@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 11:19:33 -0700 Cc: draft-ietf-httpauth-digest.all@tools.ietf.org Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 08 Apr 2015 18:18:55 -0000 > Thank you. This version looks okay. Barry, please chime if we missed anything > else. It looks good to me. Thanks, Rifaat. Barry From nobody Wed Apr 8 11:43:50 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 81A4F1A8AB7; Wed, 8 Apr 2015 11:19:40 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615611A8A6C for ; Wed, 8 Apr 2015 11:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 1J0zDw0NTJTg for ; Wed, 8 Apr 2015 11:19:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59FB1A8A6D for ; Wed, 8 Apr 2015 11:18:53 -0700 (PDT) Received: from mail-ob0-x230.google.com ([2607:f8b0:4003:c01::230]:35585) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfuYu-0006WE-J5 for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 08 Apr 2015 11:18:53 -0700 Received: by obbfy7 with SMTP id fy7so151532584obb.2 for ; Wed, 08 Apr 2015 11:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zxG0AmVRtm3f3Bm4M17IBT+hIViekMSRlgIxmQmxZvY=; b=vYSz4084QeXZbpU1DIU4xz0Mz0AsKBmV38tYpe64LCverZl+XTYPKydJKS33PCSMtG cVZRaF0Jk6EvuK6VI8iXmcJXwcs9yv7Do+Wt9GC/wjzpdnF2N9RsqLDS2hBq/fkGlIHu +t8DZ+8CbEs5aAXzmXDvcl5zkaOi8GvzOVqo+CCG6OdcN8LZUwAiephtwHGbrRLjuFqW CBxDMnuezAIFJjbgxj0ZzBfoHeuFY2e9MgDVwLyFy/7npGAgoLEdGiG00yria/AlKFJd GSVGYmiHJmCG038Z+UsfOwuYAK2DjwvWNvNBCYsiJDmQRg5e/vBcNZZeNf9a5J0n8huA skkQ== MIME-Version: 1.0 X-Received: by 10.182.246.163 with SMTP id xx3mr33880362obc.83.1428517126619; Wed, 08 Apr 2015 11:18:46 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Wed, 8 Apr 2015 11:18:46 -0700 (PDT) In-Reply-To: References: <20150319201517.19099.10375.idtracker@ietfa.amsl.com> Date: Wed, 8 Apr 2015 14:18:46 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c1ee46e3454005133a8ff8 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::230 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150408181853.D59FB1A8A6D@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 11:18:53 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 11:43:49 -0700 Cc: draft-ietf-httpauth-digest.all@tools.ietf.org, "iana-issues@iana.org" Subject: Re: [http-auth] [IANA #817019] Re: Last Call: (HTTP Digest Access Authentication) to Proposed Standard 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, 08 Apr 2015 18:19:40 -0000 --001a11c1ee46e3454005133a8ff8 Content-Type: text/plain; charset=ISO-8859-1 Thanks for your help with this, Barry. Much appreciated. Regards, Rifaat On Wed, Apr 8, 2015 at 2:17 PM, Barry Leiba wrote: > > Thank you. This version looks okay. Barry, please chime if we missed > anything > > else. > > It looks good to me. Thanks, Rifaat. > > Barry > --001a11c1ee46e3454005133a8ff8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for your help with this, Barry. Much appreciated.

Regards,
=A0Rifaat


On Wed, = Apr 8, 2015 at 2:17 PM, Barry Leiba <barryleiba@computer.org>= wrote:
> Than= k you.=A0 This version looks okay.=A0 Barry, please chime if we missed anyt= hing
> else.

It looks good to me.=A0 Thanks, Rifaat.

Barry

--001a11c1ee46e3454005133a8ff8-- From nobody Wed Apr 8 17:34:38 2015 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 B694F1A92FE; Wed, 8 Apr 2015 17:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 NxzMJrojCaJP; Wed, 8 Apr 2015 17:34:35 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1441ABD39; Wed, 8 Apr 2015 17:34:34 -0700 (PDT) Received: by labbd9 with SMTP id bd9so66831834lab.2; Wed, 08 Apr 2015 17:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nQGzbZ7hvQF5Pkw2xacN4nwPRZLuXSCmEttqYc7/sDs=; b=frSgO5FHCuUHmBI37PL6j7V4VoxKH4WXeC55D6chOG0orUUzZhoqdR46D/Q1PzX3yk SDofKXAw7T/KTGM0CQ/pyTbweiDc4Q/Bf0Vriev5I9CPkLGgVYPHgFebMmfXYHqo5xzj 7N75NFiscZKu4nuMft7ZxfUOdIhWMOJ3oJjGCDM25fGeVLlJEQr9IjyZTg+/eVlCLV1y I95d636ZcwN3c4gpO7PDSUgKcQShNG0+mW1pu6IniqK+zXmdlnrpYdTt4dmXHaHyJD0x RLD9lghL0nG+xa7ehBs3kRRt7cxgItxIzsksTNXNN82/WK/H+q3SfRGItKGmJlYAmmAY rjgw== MIME-Version: 1.0 X-Received: by 10.112.188.227 with SMTP id gd3mr26297969lbc.0.1428539673237; Wed, 08 Apr 2015 17:34:33 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Wed, 8 Apr 2015 17:34:33 -0700 (PDT) In-Reply-To: <5CE14E57-A401-4D6F-BA3F-D1C37FAF50F9@gmail.com> References: <20150402070858.6894.56835.idtracker@ietfa.amsl.com> <5CE14E57-A401-4D6F-BA3F-D1C37FAF50F9@gmail.com> Date: Wed, 8 Apr 2015 20:34:33 -0400 Message-ID: From: Kathleen Moriarty To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c36aa8c55ddf05133fcf58 Archived-At: Cc: httpauth mailing list , draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Last Call Expired: 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: Thu, 09 Apr 2015 00:34:36 -0000 --001a11c36aa8c55ddf05133fcf58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav, Thank you. I see the Gen-art review and SecDIr review have both come in and the SecDir review does raise a few good points that need to be addressed. I'll put this on the next telechat, but will wait to add the ballot until the SecDir review is addressed and an update is provided, assuming that can be turned around by sometime next week. Thank you. On Thu, Apr 2, 2015 at 3:30 AM, Yoav Nir wrote: > Hi, Kathleen > > The only responses I=E2=80=99ve seen to this IETF last call was the threa= d that > stemmed from Rifaat=E2=80=99s idea from the TRAM working group to add a s= alt to > Digest. > > I don=E2=80=99t think there is consensus in the group to pull the documen= t back > into the working group and add this parameter, so IMO the document can > proceed as is. > > Thanks > > Yoav > (with document shepherd and WG chair hat on) > > > On Apr 2, 2015, at 10:08 AM, DraftTracker Mail System < > iesg-secretary@ietf.org> wrote: > > > > > > Please DO NOT reply to this email. > > > > I-D: > > ID Tracker URL: > http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > > > IETF Last Call has ended, and the state has been changed to > > Waiting for AD Go-Ahead. > > > > --=20 Best regards, Kathleen --001a11c36aa8c55ddf05133fcf58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yoav,

Thank you.=C2=A0 I see the Gen= -art review and SecDIr review have both come in and the SecDir review does = raise a few good points that need to be addressed.=C2=A0 I'll put this = on the next telechat, but will wait to add the ballot until the SecDir revi= ew is addressed and an update is provided, assuming that can be turned arou= nd by sometime next week.

Thank you.

On Thu, Apr 2, 2015= at 3:30 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi, Kathleen

The only responses I=E2=80=99ve seen to this IETF last call was the thread = that stemmed from Rifaat=E2=80=99s idea from the TRAM working group to add = a salt to Digest.

I don=E2=80=99t think there is consensus in the group to pull the document = back into the working group and add this parameter, so IMO the document can= proceed as is.

Thanks

Yoav
(with document shepherd and WG chair hat on)

> On Apr 2, 2015, at 10:08 AM, DraftTracker Mail System <iesg-secretary@ietf.org> wrote:
>
>
> Please DO NOT reply to this email.
>
> I-D: <draft-ietf-httpauth-digest-15.txt>
> ID Tracker URL: http://datatracker.ietf.org/doc/draft-i= etf-httpauth-digest/
>
> IETF Last Call has ended, and the state has been changed to
> Waiting for AD Go-Ahead.
>




--
=

Best regards,
Kathleen
--001a11c36aa8c55ddf05133fcf58-- From nobody Wed Apr 8 17:35:06 2015 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 58A701AC3B3; Wed, 8 Apr 2015 17:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 pNtIuhh2v-oO; Wed, 8 Apr 2015 17:35:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A55011ABD3D; Wed, 8 Apr 2015 17:35:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409003501.27819.70900.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 17:35:01 -0700 From: IETF Secretariat Archived-At: Subject: [http-auth] Telechat update notice: 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: Thu, 09 Apr 2015 00:35:03 -0000 Placed on agenda for telechat - 2015-04-23 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ From nobody Thu Apr 9 00:48:23 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7F65E1A9237; Wed, 8 Apr 2015 16:05:26 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644CE1A9172 for ; Wed, 8 Apr 2015 16:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_41=0.6] 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 VUA-LW8CvMa3 for ; Wed, 8 Apr 2015 16:05:25 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5F71A9231 for ; Wed, 8 Apr 2015 16:05:24 -0700 (PDT) Received: from out01.mta.xmission.com ([166.70.13.231]:50755) by merlot.tools.ietf.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84) (envelope-from ) id 1Yfz25-0000vT-SC for draft-ietf-httpauth-digest.all@tools.ietf.org; Thu, 09 Apr 2015 01:05:22 +0200 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Yfz1H-00016e-98; Wed, 08 Apr 2015 17:04:27 -0600 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1Yfz1G-0004AB-C3; Wed, 08 Apr 2015 17:04:27 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id t38N49Pe016520; Wed, 8 Apr 2015 17:04:09 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id t38N48Ga016518; Wed, 8 Apr 2015 17:04:08 -0600 Date: Wed, 8 Apr 2015 17:04:08 -0600 Message-Id: <201504082304.t38N48Ga016518@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org X-XM-AID: U2FsdGVkX19IgXMXHGciIYGgpcTYHcN+ X-SA-Exim-Connect-IP: 166.70.13.231 X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: hilarie@purplestreak.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150408230524.9F5F71A9231@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 16:05:24 -0700 (PDT) Resent-From: hilarie@purplestreak.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 00:48:22 -0700 Cc: draft-ietf-httpauth-digest.all@tools.ietf.org, secdir@ietf.org Subject: [http-auth] Review of draft-ietf-httpauth-digest-15 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:05:26 -0000 Security review of HTTP Digest Access Authentication draft-ietf-httpauth-digest-15 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. HTTP authentication can be done via username and password. This document defines two hash function based methods for sending a binding between the password, username, and other information. The password can be verified on a server by checking the hash using the recorded password and the current information. The method defines the use of newer hash functions but keeps backwards compatibility with MD5. "Section 3.1 Overall Operation .... The security of this protocol is critically dependent on the randomness of the randomly chosen parameters, such as client and server nonces. These should be generated by a strong random or properly seeded pseudorandom source (see [RFC4086])." The above seems to be something that should go into the noticeably absent "Security Considerations" section. Page 5, discussions the "nonce". The "secret-data" is what requires the high-quality randomness mentioned in section 3.1. This should be explicitly noted. There should be some guidance on the minimum acceptable length of the secret-data ... 128 bits seems reasonable to me. The maximum length should also be specified, and I would recommend that it be no more than 512 bits at most. I would further recommend that the secret data be generated explicitly for digest authentication and not copied from some other random value used by the server for other security purposes. Further, the "secret-data" should be changed periodically, not just on server restart. "Also, IP address spoofing is not that hard." would be better stated as "Source IP addresses are no guarantee of end-to-end integrity." Page 5, "opaque" data string. What is the minimum acceptable length? 16 bytes? Maximum? There should be a maximum. Page 6 " algorithm A string indicating a pair of algorithms used to produce the digest and a checksum. If this is not present it is assumed to be "MD5". " How is "MD5" a pair of algorithms? Is "MD5,MD5" a pair? Or is the there actually a single algorithm that will be used in two ways (keyed and unkeyed digest)? It would be helpful to note that "KD" means "Keyed digest". It would be better to use HMAC than the concatenation shown. Rather than "checksum", it would be more appropriate to say "digest" or "unkeyed digest". E.g, "to produce a keyed digest and an unkeyed digest." Page 8, what is the minimum acceptable length for cnonce? Maximum length? Page 10, "cnounce" should be "cnonce". I would recommend that the keyed digest be done in the following way: K = H(password) C = concatenation of a bunch of non-secret stuff KD(K, C) = HMAC(K, C) = H(K, H(K, C)) For the H-ness calculations, C' = unq(username) ":" unq(realm) ":" unq(nonce-prime) ":" unq(cnonce-prime) A1 = HMAC(K, C') and then KD ( A1, C ) = HMAC(A1, C) = H(A2, H(A1, C)) Hilarie From nobody Thu Apr 9 00:48:24 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-digest.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9DEAF1ACD18; Wed, 8 Apr 2015 17:56:50 -0700 (PDT) X-Original-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-digest.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811291ACCFC for ; Wed, 8 Apr 2015 17:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_41=0.6, SPF_SOFTFAIL=0.665] 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 d5IIEEfTouFF for ; Wed, 8 Apr 2015 17:56:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0681ACD05 for ; Wed, 8 Apr 2015 17:56:48 -0700 (PDT) Received: from mail-ob0-x22c.google.com ([2607:f8b0:4003:c01::22c]:36303) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yg0ly-0005aM-O3 for draft-ietf-httpauth-digest.all@tools.ietf.org; Wed, 08 Apr 2015 17:56:48 -0700 Received: by obbeb7 with SMTP id eb7so89109597obb.3 for ; Wed, 08 Apr 2015 17:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MZ07QGiXu4CEoIGBlmC9K0PlCUCpPQCSFjSt7/YQT/Q=; b=MS9tT8qeCr8iowqm4YfROl2RxdIdQLuw5of89lCCWPr7tS5o/nb1MLblaeOaKoQQCC kTMWjVDChn8i8rks+PJ7OZ+XObXFtaE/SK6A0HsWjYAmDQYzVjypTMqcPh+6lhccIax8 PxyDQRI1JtfgLUWrRGUx2VWXSUfEb/Wrr1OGb7/Xl8RA+Rm9u4Co652GAl4FCNKvPWP/ xGDTQ5ScCzY3dkSPdnVBMTI6mIWHPQVHaVqH8Ts/QFj8C1R/+xfL6h2S5NABFaCI6kFv S4ej2NxcFtifZjh+YYmzG0XsSHHezvdYP2l8d08DwiU59BQPmwczKq7fa0+KaSSeNf2I ZWyw== MIME-Version: 1.0 X-Received: by 10.182.255.195 with SMTP id as3mr35617592obd.56.1428540999430; Wed, 08 Apr 2015 17:56:39 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Wed, 8 Apr 2015 17:56:39 -0700 (PDT) In-Reply-To: <201504082304.t38N48Ga016518@sylvester.rhmr.com> References: <201504082304.t38N48Ga016518@sylvester.rhmr.com> Date: Wed, 8 Apr 2015 20:56:39 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Hilarie Orman Content-Type: multipart/alternative; boundary=001a1134a616d1779f0513401e2e X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::22c X-SA-Exim-Rcpt-To: draft-ietf-httpauth-digest.all@tools.ietf.org X-SA-Exim-Mail-From: rifaat.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-httpauth-digest.all@ietf.org Resent-Message-Id: <20150409005648.7C0681ACD05@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 17:56:48 -0700 (PDT) Resent-From: rifaat.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 00:48:22 -0700 Cc: draft-ietf-httpauth-digest.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [http-auth] Review of draft-ietf-httpauth-digest-15 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: Thu, 09 Apr 2015 00:56:50 -0000 --001a1134a616d1779f0513401e2e Content-Type: text/plain; charset=ISO-8859-1 Hi Hilarie, Thanks for your review and comments. Please, see my reply inline... Regards, Rifaat On Wed, Apr 8, 2015 at 7:04 PM, Hilarie Orman wrote: > Security review of > HTTP Digest Access Authentication > draft-ietf-httpauth-digest-15 > > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. > > HTTP authentication can be done via username and password. This > document defines two hash function based methods for sending a binding > between the password, username, and other information. The password > can be verified on a server by checking the hash using the recorded > password and the current information. The method defines the use of > newer hash functions but keeps backwards compatibility with MD5. > > "Section 3.1 Overall Operation > .... > The security of this protocol is critically dependent on the > randomness of the randomly chosen parameters, such as client and > server nonces. These should be generated by a strong random or > properly seeded pseudorandom source (see [RFC4086])." > > The above seems to be something that should go into the noticeably > absent "Security Considerations" section. > > Hmmm, did you miss section 5? > Page 5, discussions the "nonce". The "secret-data" is what requires > the high-quality randomness mentioned in section 3.1. This should be > explicitly noted. There should be some guidance on the minimum > acceptable length of the secret-data ... 128 bits seems reasonable to > me. The maximum length should also be specified, and I would > recommend that it be no more than 512 bits at most. > > I would further recommend that the secret data be generated explicitly > for digest authentication and not copied from some other random value > used by the server for other security purposes. Further, the > "secret-data" should be changed periodically, not just on server > restart. > > The document explicitly states that "The contents of the nonce are implementation dependent". The text was copied from RFC2617, and unless there is a good chance that people would be interested in implementing these new ideas, I would rather we keep it as is. Also, can you explain why do you recommend 128 bits as minimum and 512 bits as maximum? > "Also, IP address spoofing is not that hard." would be better stated > as "Source IP addresses are no guarantee of end-to-end integrity." > > Well, the existing text at least states why you should not rely on IP address. With your proposed text, you state something but do not explain what is that the case. > Page 5, "opaque" data string. What is the minimum acceptable length? > 16 bytes? Maximum? There should be a maximum. > > Again, this is implementation dependent. > Page 6 > " algorithm > > A string indicating a pair of algorithms used to produce the > digest and a checksum. If this is not present it is assumed to be > "MD5". > " > > How is "MD5" a pair of algorithms? Is "MD5,MD5" a pair? Or is the > there actually a single algorithm that will be used in two ways (keyed > and unkeyed digest)? > > This is the way it was stated in RFC2617. It is the same algorithm used to hash different things. I will fix it. > It would be helpful to note that "KD" means "Keyed digest". Ok. > It would > be better to use HMAC than the concatenation shown. > > Yeah, as I mentioned in a response to a previous review, and I would be happy to do that if there is interest and support for adding HMAC support. > Rather than "checksum", it would be more appropriate to say "digest" > or "unkeyed digest". E.g, "to produce a keyed digest and an unkeyed > digest." > > Ok. > Page 8, what is the minimum acceptable length for cnonce? Maximum length? > > This is implementation dependent. > Page 10, "cnounce" should be "cnonce". > > Ok > I would recommend that the keyed digest be done in the following way: > > K = H(password) > C = concatenation of a bunch of non-secret stuff > KD(K, C) = HMAC(K, C) = H(K, H(K, C)) > > For the H-ness calculations, > > C' = unq(username) ":" unq(realm) ":" unq(nonce-prime) ":" > unq(cnonce-prime) > > A1 = HMAC(K, C') > > and then > > KD ( A1, C ) = HMAC(A1, C) = H(A2, H(A1, C)) > > Let's first see if there is support for the idea of adding HMAC support; after that we will deal with these details. Regards, Rifaat > Hilarie > --001a1134a616d1779f0513401e2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hilarie,

Thanks for your review and = comments.
Please, see my reply inline...

Regards,
=A0Rifaat


On Wed, Apr 8, 2015 at 7:04 PM, Hilarie Or= man <hilarie@purplestreak.com> wrote:
Security review of
HTTP Digest Access Authentication
draft-ietf-httpauth-digest-15

Do not be alarmed.=A0 I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.=A0 These comments were written primarily
for the benefit of the security area directors.=A0 Document editors and
WG chairs should treat these comments just like any other last call
comments.

HTTP authentication can be done via username and password.=A0 This
document defines two hash function based methods for sending a binding
between the password, username, and other information.=A0 The password
can be verified on a server by checking the hash using the recorded
password and the current information.=A0 The method defines the use of
newer hash functions but keeps backwards compatibility with MD5.

"Section 3.1 Overall Operation
=A0 =A0....
=A0 =A0The security of this protocol is critically dependent on the
=A0 =A0randomness of the randomly chosen parameters, such as client and
=A0 =A0server nonces.=A0 These should be generated by a strong random or =A0 =A0properly seeded pseudorandom source (see [RFC4086])."

The above seems to be something that should go into the noticeably
absent "Security Considerations" section.


Hmmm, did you miss section 5?


=A0
Page 5, discussions the "nonce".=A0 The "secret-data" i= s what requires
the high-quality randomness mentioned in section 3.1.=A0 This should be
explicitly noted.=A0 There should be some guidance on the minimum
acceptable length of the secret-data ... 128 bits seems reasonable to
me.=A0 The maximum length should also be specified, and I would
recommend that it be no more than 512 bits at most.

I would further recommend that the secret data be generated explicitly
for digest authentication and not copied from some other random value
used by the server for other security purposes.=A0 Further, the
"secret-data" should be changed periodically, not just on server<= br> restart.


The document explicitly states th= at "The contents of the nonce are implementation dependent".
The text was copied from RFC2617, and unless there is a good ch= ance that people would be interested in implementing these new ideas, I wou= ld rather we keep it as is.
Also, can you explain why do you reco= mmend 128 bits as minimum and 512 bits as maximum?

=A0
"Also, IP address spoofing is not that hard." would be better sta= ted
as "Source IP addresses are no guarantee of end-to-end integrity."= ;


Well, the existing text at least state= s why you should not rely on IP address. With your proposed text, you state= something but do not explain what is that the case.

=A0
Page 5, "opaque" data string.=A0 What is the minimum acceptable l= ength?
16 bytes?=A0 Maximum?=A0 There should be a maximum.


Again, this is implementation dependen= t.

=A0
Page 6
" algorithm

=A0 =A0 =A0 A string indicating a pair of algorithms used to produce the =A0 =A0 =A0 digest and a checksum.=A0 If this is not present it is assumed = to be
=A0 =A0 =A0 "MD5".
"

How is "MD5" a pair of algorithms?=A0 Is "MD5,MD5" a pa= ir?=A0 Or is the
there actually a single algorithm that will be used in two ways (keyed
and unkeyed digest)?


This is the way it was stated in RFC26= 17. It is the same algorithm used to hash different things. I will fix it.<= /div>

=A0
It would be helpful to note that "KD" means "Keyed digest&qu= ot;.

Ok.

=A0
It would
be better to use HMAC than the concatenation shown.


Yeah, as I mentioned in a response to = a previous review, and I would be happy to do that if there is interest and= support for adding HMAC support.

=A0
Rather than "checksum", it would be more appropriate to say "= ;digest"
or "unkeyed digest".=A0 E.g, "to produce a keyed digest and = an unkeyed
digest."


Ok.

=A0
=
Page 8, what is the minimum acceptable length for cnonce?=A0 Maximum length= ?


This is implementation dependent.

=A0
Page 10, "cnounce" should be "cnonce".


Ok

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> I would recommend that the keyed digest be done in the following way:

K =3D H(password)
C =3D concatenation of a bunch of non-secret stuff
KD(K, C) =3D HMAC(K, C) =3D H(K, H(K, C))

For the H-ness calculations,

C' =3D unq(username) ":" unq(realm) ":" unq(nonce-p= rime) ":" unq(cnonce-prime)

=A0A1 =3D HMAC(K, C')

and then

=A0KD ( A1, C ) =3D HMAC(A1, C) =3D H(A2, H(A1, C))


Let's first see if there is support for the idea of adding HMAC s= upport; after that we will deal with these details.

Regards,
=A0Rifaat



Hilarie

--001a1134a616d1779f0513401e2e-- From nobody Fri Apr 10 01:28:10 2015 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 9E9111B2B0A for ; Fri, 10 Apr 2015 01:28:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=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 i6dGOPl3C3Dq for ; Fri, 10 Apr 2015 01:28:02 -0700 (PDT) Received: from APAC01-HK1-obe.outbound.protection.outlook.com (mail-hk1on0088.outbound.protection.outlook.com [134.170.140.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21B41B2AFC for ; Fri, 10 Apr 2015 01:28:01 -0700 (PDT) Received: from dhcp147167.a01.aist.go.jp (150.29.147.167) by TY1PR01MB0237.jpnprd01.prod.outlook.com (25.161.135.148) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 10 Apr 2015 08:27:57 +0000 Message-ID: <55278982.8030603@aist.go.jp> Date: Fri, 10 Apr 2015 17:27:46 +0900 From: Hajime Watanabe User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [150.29.147.167] X-ClientProxiedBy: CO1PR06CA045.namprd06.prod.outlook.com (10.242.160.35) To TY1PR01MB0237.jpnprd01.prod.outlook.com (25.161.135.148) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=h-watanabe@aist.go.jp; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0237; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(279900001)(19625305001)(42186005)(59896002)(23746002)(87976001)(19580395003)(65816999)(92566002)(107886001)(83506001)(65956001)(229853001)(40100003)(450100001)(77156002)(122386002)(117636001)(36756003)(66066001)(15975445007)(47776003)(74482002)(99136001)(62966003)(50986999)(110136001)(87266999)(226693001)(50466002)(65806001)(54356999)(46102003)(64126003)(86362001)(2351001)(7099025)(62816006); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR01MB0237; H:dhcp147167.a01.aist.go.jp; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5002010)(5005006); SRVR:TY1PR01MB0237; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0237; X-Forefront-PRVS: 054231DC40 Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2015 08:27:57.5283 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0237 Archived-At: Subject: [http-auth] Mutual Auth: Experimental implementations are available! 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, 10 Apr 2015 08:28:05 -0000 Hi, all, Sorry for our late announcement. We have released an experimental browser implementation and an experimental server implementation based on the latest (04-)drafts of Mutual Auth protocol: * Firefox 35.0a1 based browser, MutualTestFox (for Windows, Linux and Mac OS X) * Diff from the Mozilla source code * WEBrick server kit (in Ruby) You can get them from our project Web page: https://www.rcis.aist.go.jp/special/MutualAuth/ You can access the server using MutualTestFox via: http://mutualtest.rcis.jp:8004/wg-draft04/ Any feedback is welcome, thanks. Best regards, Hajime (an author of Mutual I-Ds) From nobody Fri Apr 10 17:26:00 2015 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 B6A521A88EC; Fri, 10 Apr 2015 17:25:58 -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] 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 r6DNE0d7-NsW; Fri, 10 Apr 2015 17:25:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7151F1A8742; Fri, 10 Apr 2015 17:25:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150411002557.26329.43992.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 17:25:57 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-18.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: Sat, 11 Apr 2015 00:25:58 -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 : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-18.txt Pages : 30 Date : 2015-04-10 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPAuth working group mailing list (http-auth@ietf.org), which is archived at [1]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-18 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 Fri Apr 10 17:26:10 2015 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 079171A875D; Fri, 10 Apr 2015 17:26:00 -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] 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 jBn9zaMKvDK0; Fri, 10 Apr 2015 17:25:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE411A8763; Fri, 10 Apr 2015 17:25:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150411002557.26329.12472.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 17:25:57 -0700 Archived-At: Subject: [http-auth] New Version Notification - draft-ietf-httpauth-digest-18.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: Sat, 11 Apr 2015 00:26:00 -0000 A new version (-18) has been submitted for draft-ietf-httpauth-digest: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-digest-18.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-18 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. IETF Secretariat. From nobody Fri Apr 10 17:35:58 2015 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 2881A1A89F5 for ; Fri, 10 Apr 2015 17:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 g_5SpgljIzJl for ; Fri, 10 Apr 2015 17:35:55 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1D71A89C5 for ; Fri, 10 Apr 2015 17:35:54 -0700 (PDT) Received: by qkgx75 with SMTP id x75so53152490qkg.1 for ; Fri, 10 Apr 2015 17:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xHudNuVhYzZ8dZsNa7BSD9WU3MRxybBuaXgFS9APL/E=; b=XN5LOZx/JZLQK0fWdd1Cvbe0wH3F+F4zlJvZhgSSmC3e8AYSP0g9Em4IIZrKQSDCus tXQxZ1Jyu/F+l0tlbuCABmZkM66SoSODV52Xyl0x9fKFhLA7v3xRux+xlJI8vt2fkWAa cX9aw6ngjm0sZym48rLuhVqUe3e6nHsmM+Io/JQtehWjfwi1GsuB7ZXChO9DsfB4ZTdF yXvTe7u0QyMabXeN2yaLUo5n3RAvIdWUsCOtLxPjPtUkKDefJyjg4RiimbsHGJUGyZkk JEevf13T32RJPpvPrWm7KxLn+48uk6QUkUnsCCxfukPJD8vV6Gl2i9d8uYPHziZdp4hx Ul2g== MIME-Version: 1.0 X-Received: by 10.182.75.194 with SMTP id e2mr4631735obw.17.1428712553911; Fri, 10 Apr 2015 17:35:53 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Fri, 10 Apr 2015 17:35:53 -0700 (PDT) In-Reply-To: <20150411002557.26329.43992.idtracker@ietfa.amsl.com> References: <20150411002557.26329.43992.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 20:35:53 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1eac64318a605136810e7 Archived-At: Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-18.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: Sat, 11 Apr 2015 00:35:57 -0000 --001a11c1eac64318a605136810e7 Content-Type: text/plain; charset=ISO-8859-1 This new version addresses the comments received so far based on my responses to the reviews. I did not add HMAC support yet; if there is interest, and support from the ADs, I would be happy to do that. Regards, Rifaat On Fri, Apr 10, 2015 at 8:25 PM, 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 : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-18.txt > Pages : 30 > Date : 2015-04-10 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that can be used with the HTTP > authentication mechanism. > > Editorial Note (To be removed by RFC Editor before publication) > > Discussion of this draft takes place on the HTTPAuth working group > mailing list (http-auth@ietf.org), which is archived at [1]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-18 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-18 > > > 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/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c1eac64318a605136810e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This new version addresses the comments received so far ba= sed on my responses to the reviews.
I did not add HMAC support yet; if = there is interest, and support from the ADs, I would be happy to do that.

Regards,=A0
=A0 Rifaat


On Fri, A= pr 10, 2015 at 8:25 PM, <internet-drafts@ietf.org> w= rote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 =A0: HTTP Digest Access Authentica= tion
=A0 =A0 =A0 =A0 Authors=A0 =A0 =A0 =A0 =A0: Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-httpauth-digest-18.txt=
=A0 =A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 =A0: 30
=A0 =A0 =A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2015-04-10

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information.=A0 This document defin= es
=A0 =A0the HTTP Digest Authentication scheme that can be used with the HTTP=
=A0 =A0authentication mechanism.

Editorial Note (To be removed by RFC Editor before publication)

=A0 =A0Discussion of this draft takes place on the HTTPAuth working group =A0 =A0mailing list (http-auth@ietf.o= rg), which is archived at [1].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest= /

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-18
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-18


Please note that it may take a couple of minutes from the time of submissio= n
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/

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

--001a11c1eac64318a605136810e7-- From nobody Mon Apr 13 11:32:32 2015 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 DE67F1B2A78 for ; Mon, 13 Apr 2015 11:32:30 -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 HdpGgoz5VppI for ; Mon, 13 Apr 2015 11:32:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B61F1B2A79 for ; Mon, 13 Apr 2015 11:32:27 -0700 (PDT) Received: from [192.168.2.177] ([93.217.72.127]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MfVYB-1Z2QQv29cJ-00P7pj for ; Mon, 13 Apr 2015 20:32:25 +0200 Message-ID: <552C0BB1.60406@gmx.de> Date: Mon, 13 Apr 2015 20:32:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <20150413174628.15118.17945.idtracker@ietfa.amsl.com> In-Reply-To: <20150413174628.15118.17945.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150413174628.15118.17945.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:p0zHWZe5ghtDvJgA5tZTkKir7KNfr4972YvUUoR0Wy0hIFvymzi IAiQZukneFAw0xkreCbtjp+/2gZEaEWdqDAMNZWOsyRdtkDD819Mp707m93pb4V2M4gl7Gw qQp5TSGWBobcCaeve3G3fLfI/MwRPmtnomCFtZOnsghOZn/V9Ql/rnVBWwNv4Zy8LjaMwEf P5NX4cVNJDPuz/9dkh3qQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [http-auth] Fwd: Protocol Action: 'The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy- Authentication-Info Response Header Fields' to Proposed Standard (draft-ietf-httpbis-auth-info-05.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: Mon, 13 Apr 2015 18:32:31 -0000 (FYI) -------- Forwarded Message -------- Subject: Protocol Action: 'The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy- Authentication-Info Response Header Fields' to Proposed Standard (draft-ietf-httpbis-auth-info-05.txt) Date: Mon, 13 Apr 2015 10:46:28 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: httpbis chair , httpbis mailing list , RFC Editor The IESG has approved the following document: - 'The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy- Authentication-Info Response Header Fields' (draft-ietf-httpbis-auth-info-05.txt) as Proposed Standard This document is the product of the Hypertext Transfer Protocol Working Group. The IESG contact person is Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-httpbis-auth-info/ Technical Summary This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields, for use in HTTP authentication schemes that need to return information once the client's authentication credentials have been accepted. Review and Consensus This document separates the definition of the "Authentication-Info" and "Proxy-Authentication-Info" HTTP header fields from RFC2617, so that they can be used by other HTTP authentication schemes (including some being actively developed). As such, the header fields have already enjoyed implementation and deployment; this merely re-specifies them for more generic use. Other Working Groups depend upon this specification to progress their work items. The specification has been reviewed, and its content has been uncontroversial. Personnel The document shepherd is Mark Nottingham; the responsible Area Director is Barry Leiba. From nobody Sun Apr 19 21:41:29 2015 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 A52CF1ACD01; Sun, 19 Apr 2015 21:41:28 -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] 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 AjsPLedoMr9G; Sun, 19 Apr 2015 21:41:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B6A1ACCFD; Sun, 19 Apr 2015 21:41:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420044127.11067.30459.idtracker@ietfa.amsl.com> Date: Sun, 19 Apr 2015 21:41:27 -0700 Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, httpauth-chairs@ietf.org, http-auth@ietf.org, draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: [http-auth] Joel Jaeggli's No Objection on draft-ietf-httpauth-digest-18: (with COMMENT) 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: Mon, 20 Apr 2015 04:41:28 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-httpauth-digest-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- testrealm.com is of course a domain that actually exists... testrealm.example.org/com would seem fine. From nobody Mon Apr 20 05:02:44 2015 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 4FA311A032D; Mon, 20 Apr 2015 05:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 xGzQLSZIyOoB; Mon, 20 Apr 2015 05:02:40 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A191A0369; Mon, 20 Apr 2015 05:02:34 -0700 (PDT) Received: by oblw8 with SMTP id w8so117288828obl.0; Mon, 20 Apr 2015 05:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pcfzztWAniGZG6omkO3BRlPL9v0raxYkN61cVhKf7FA=; b=H35koPQE4o8+TaWsSN2cQV6qz38ZkISj6E9xnYPiMjG+9u5PMMjFrE2FUddmopb8SW 29ueHujO7FY7voLpEua9CwGKnlwEuxC+HktOQ54v5OkukTGGFiTmtsQiDMT+Auag/ap0 1bjkCCvxPkhNTX169cgQrAC+ocgvyyRe87c01iHF8SAYJ0NKS8BPP1CX6kHWLhfhflya kqN6mN14egUPJD5wKmvDDZ+NNkQCnJcHGYfDvK5ZRsFPjzAsOailxZ9g8qVlzQFZGzPI m6Pusv3l57NWpd8FYvJse3xcvvsRp0/dBfxkDSFBvZqeZl4jic3sVsJgAGEL8n8E4fYu t5HA== MIME-Version: 1.0 X-Received: by 10.60.133.176 with SMTP id pd16mr13980035oeb.78.1429531354269; Mon, 20 Apr 2015 05:02:34 -0700 (PDT) Received: by 10.202.75.149 with HTTP; Mon, 20 Apr 2015 05:02:34 -0700 (PDT) In-Reply-To: <20150420044127.11067.30459.idtracker@ietfa.amsl.com> References: <20150420044127.11067.30459.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 08:02:34 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Joel Jaeggli Content-Type: multipart/alternative; boundary=047d7b472876910ca9051426b41e Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, "http-auth@ietf.org" , httpauth-chairs@ietf.org, The IESG , draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Joel Jaeggli's No Objection on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 20 Apr 2015 12:02:42 -0000 --047d7b472876910ca9051426b41e Content-Type: text/plain; charset=ISO-8859-1 Hi Joel, Thanks for your review and comment. I will change the domain in the next version of the draft. Regards, Rifaat On Mon, Apr 20, 2015 at 12:41 AM, Joel Jaeggli wrote: > Joel Jaeggli has entered the following ballot position for > draft-ietf-httpauth-digest-18: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > testrealm.com is of course a domain that actually exists... > > testrealm.example.org/com would seem fine. > > > --047d7b472876910ca9051426b41e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joel,

Thanks for your review and com= ment.
I will change the domain in the next version of the draft.<= /div>

Regards,
=A0Rifaat



On Mon, Apr 20, 2015 at 12:41 AM, Joel Jaeggli <joelja@b= ogus.com> wrote:
Joel Jae= ggli has entered the following ballot position for
draft-ietf-httpauth-digest-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/<= /a>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

testrealm.com is of = course a domain that actually exists...

testrealm.ex= ample.org/com would seem fine.



--047d7b472876910ca9051426b41e-- From nobody Tue Apr 21 09:58:05 2015 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 8C6131AD367; Tue, 21 Apr 2015 09:58:04 -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] 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 mPnQVqObg2bI; Tue, 21 Apr 2015 09:58:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E341AD34F; Tue, 21 Apr 2015 09:58:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150421165802.18601.71351.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 09:58:02 -0700 Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, httpauth-chairs@ietf.org, http-auth@ietf.org, draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 21 Apr 2015 16:58:04 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-httpauth-digest-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a yes on this, not because it's great technology (it just isn't;-), but because it is a valiant effort to do responsible updates to a scheme that is used somewhat. Thanks for doing the work. - The intro could usefully say that this extends but is generally backwards compatible with 2617 if you don't use any new stuff and include a pointer to appendix A as well. - p5, "nonce": "data string" is an odd combination - p6, "stale": Is "TRUE" the literal value? What if it's "1" or "y" - just wondering in case current code does something there. Section 3.3 (and elsewhere) uses "true" and "false" which aren't the same as TRUE and FALSE (or are they?) It'd be good to be consistent or to say that we're not being consistent, presumably for historical reasons. - end of 3.4: is there a specific section of 7234 that's most relevant? If so, good to say so. - 5.3, you could maybe add a reference to RFC7486 at the end of the 1st para (that is blatent self-advertisement, but I couldn't resist:-) - 5.6, is the "note" about Basic still true? I thought Julian or someone tested it and found it not quite so bad? - I think something went wrong with the secdir review [1] but I'd also encourage us to try to bottom out on Hilarie's comments. There may be something there that could be used, without any damage to backwards compatibility, which would be interesting. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05621.html From nobody Tue Apr 21 14:43:43 2015 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 222181B2BAE; Tue, 21 Apr 2015 14:28:06 -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] 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 yXZYk-RQy6fq; Tue, 21 Apr 2015 14:28:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E884F1B2BA6; Tue, 21 Apr 2015 14:28:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150421212803.25333.50559.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 14:28:03 -0700 Archived-At: X-Mailman-Approved-At: Tue, 21 Apr 2015 14:43:43 -0700 Cc: draft-ietf-httpauth-digest.ad@ietf.org, httpauth-chairs@ietf.org, http-auth@ietf.org, draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: [http-auth] Ben Campbell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 21 Apr 2015 21:28:06 -0000 Ben Campbell has entered the following ballot position for draft-ietf-httpauth-digest-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a few minor comments: 3.3, domain: "If the URI is an abs_path..." Should that be "path-absolute", in keeping with the reference to 3986? 3.6, paragraph 4: "Because the client is REQUIRED to return..." The use of a 2119 keyword in a dependent clause seems odd. 5.1: "Digest authentication SHOULD be used over a secure channel like HTTPS" Does this mean that, if you have a secure channel you should use digest, or if you use digest you should use a a secure channel? I assume the second, but the sentence can be parsed either way. From nobody Wed Apr 22 14:09:00 2015 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 C4F8A1A896E; Wed, 22 Apr 2015 14:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 QMvtESgjOhd4; Wed, 22 Apr 2015 14:08:56 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4D51A8928; Wed, 22 Apr 2015 14:08:50 -0700 (PDT) Received: by oift201 with SMTP id t201so191692777oif.3; Wed, 22 Apr 2015 14:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=avRQAJfFEZE/iwfIFPswLtHdEoEBLMo1MLXfhC/N1hQ=; b=eNuvRtGvlIOAO9TNJ4dWwBIowKpUFh+TOkeQt6ThxCX5CrKNCW6At+0HLDDFrDIxvS 9RZcTnwIiDVHVzE5Pk7hJxhaZSx8L4anFRoqTX6ZSqWEoXnkpHz/Ily1T53+JS9jPJfK RkzQ38uFLsEXnJAAk/xH4KDZEbWR9h2Qs7B65n+e9cVj9Oxt0DG3nSyFD2C83SEEFBaU mAq7jY97l17MZdH1cZ/7BVR03nIDQugD13AFAGs8g8xPTzsxUvTTsIJiF4QNyFgcQbad w+boHLcIOxXML/YoVrSuCxNgGAD0XKM75zRd+W0SL3+UgsOURo6olxzOU6DdxSY/l7M5 zXTw== MIME-Version: 1.0 X-Received: by 10.202.95.198 with SMTP id t189mr23826479oib.105.1429736930101; Wed, 22 Apr 2015 14:08:50 -0700 (PDT) Received: by 10.202.75.149 with HTTP; Wed, 22 Apr 2015 14:08:50 -0700 (PDT) In-Reply-To: <20150421165802.18601.71351.idtracker@ietfa.amsl.com> References: <20150421165802.18601.71351.idtracker@ietfa.amsl.com> Date: Wed, 22 Apr 2015 17:08:50 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113ccfa6d751e40514569156 Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, "http-auth@ietf.org" , httpauth-chairs@ietf.org, The IESG , draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 22 Apr 2015 21:08:59 -0000 --001a113ccfa6d751e40514569156 Content-Type: text/plain; charset=ISO-8859-1 Hi Stephen, Thanks for your review and comments. Please, see my reply inline... Regards, Rifaat On Tue, Apr 21, 2015 at 12:58 PM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-httpauth-digest-18: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm a yes on this, not because it's great > technology (it just isn't;-), but because it is a > valiant effort to do responsible updates to a > scheme that is used somewhat. Thanks for doing > the work. > > - The intro could usefully say that this extends > but is generally backwards compatible with 2617 > if you don't use any new stuff and include a > pointer to appendix A as well. > Ok > > - p5, "nonce": "data string" is an odd > combination > > I will change it to "string" > - p6, "stale": Is "TRUE" the literal value? What > if it's "1" or "y" - just wondering in case > current code does something there. Section 3.3 > (and elsewhere) uses "true" and "false" which > aren't the same as TRUE and FALSE (or are they?) > It'd be good to be consistent or to say that > we're not being consistent, presumably for > historical reasons. > > I will change it to "true" and "false". > - end of 3.4: is there a specific section of 7234 > that's most relevant? If so, good to say so. > > Will look into that. > - 5.3, you could maybe add a reference to RFC7486 > at the end of the 1st para (that is blatent > self-advertisement, but I couldn't resist:-) > > Sure. > - 5.6, is the "note" about Basic still true? I > thought Julian or someone tested it and found it > not quite so bad? > > You are right; I will remove that note. > - I think something went wrong with the secdir > review [1] but I'd also encourage us to try to > bottom out on Hilarie's comments. There may be > something there that could be used, without any > damage to backwards compatibility, which would be > interesting. > > I did reply to that review. Do you have something specific that you think we should address? it is the HMAC comment? Regards, Rifaat > [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05621.html > > > --001a113ccfa6d751e40514569156 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thanks for your review and = comments.
Please, see my reply inline...

Regards,
=A0Rifaat


On Tue, Apr 21, 2015 at 12:58 PM, Stephen = Farrell <stephen.farrell@cs.tcd.ie> wrote:
Stephen Farrell has entered the following ballot p= osition for
draft-ietf-httpauth-digest-18: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/<= /a>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a yes on this, not because it's great
technology (it just isn't;-), but because it is a
valiant effort to do responsible updates to a
scheme that is used somewhat. Thanks for doing
the work.

- The intro could usefully say that this extends
but is generally backwards compatible with 2617
if you don't use any new stuff and include a
pointer to appendix A as well.

Ok
=

=A0

- p5, "nonce": "data string" is an odd
combination


I will change it to "string"= =A0

=A0
- p6, "stale": Is "TRUE" the literal value? What
if it's "1" or "y" - just wondering in case
current code does something there. Section 3.3
(and elsewhere) uses "true" and "false" which
aren't the same as TRUE and FALSE (or are they?)
It'd be good to be consistent or to say that
we're not being consistent, presumably for
historical reasons.


I will change it to "true" a= nd "false".

=A0
- end of 3.4: is there a specific section of 7234
that's most relevant? If so, good to say so.


Will look into that.
 --001a113ccfa6d751e40514569156-- From nobody Wed Apr 22 14:10:22 2015 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 F10211A897D; Wed, 22 Apr 2015 14:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 kRmVoq-q7AA0; Wed, 22 Apr 2015 14:10:19 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B7A1A8983; Wed, 22 Apr 2015 14:10:07 -0700 (PDT) Received: by oblw8 with SMTP id w8so181224836obl.0; Wed, 22 Apr 2015 14:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tZ/Eg0E+N0PvuXGCrA08B+2X/F4ePqMv472qmJBtVrI=; b=O8QaCgK2raRyEy8SMcFP18YnCxEfYZyznGB+0TVHHephj0UXevhYYQWOOq57cD93al wvPVdGLj7p5cf0R4JJLsgIx9jF1ZLRC7vb2ubbqlv0YvBJXmHWvyK3vqUs1r9kxlKYl6 PcKDLeP3BX9OjBXWp2WxZEJwHkJnYug9e38C6xzekugBx5CXYnx39db/k4m3RyJ4zgYz LQpa/NvrecXmNAniUa4riujtj7WAkHPQqkUTb/uNN+Uw8VUcJq+Mxcgk1FPfpxQpH0ld dlnE+otkY2dijohjw6OmhHWByHokulCnKy3/CN+E+tfjFTTGa1+BAKpzrLPLL+Hmhln4 VBqQ== MIME-Version: 1.0 X-Received: by 10.202.56.86 with SMTP id f83mr19949497oia.42.1429737006586; Wed, 22 Apr 2015 14:10:06 -0700 (PDT) Received: by 10.202.75.149 with HTTP; Wed, 22 Apr 2015 14:10:06 -0700 (PDT) In-Reply-To: <20150421212803.25333.50559.idtracker@ietfa.amsl.com> References: <20150421212803.25333.50559.idtracker@ietfa.amsl.com> Date: Wed, 22 Apr 2015 17:10:06 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Ben Campbell Content-Type: multipart/alternative; boundary=001a113cc1146663f805145696af Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, "http-auth@ietf.org" , httpauth-chairs@ietf.org, The IESG , draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Ben Campbell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 22 Apr 2015 21:10:21 -0000 --001a113cc1146663f805145696af Content-Type: text/plain; charset=ISO-8859-1 Hi Ben, Thanks for your review and comments. I will address these in the next version of the draft. Regards, Rifaat On Tue, Apr 21, 2015 at 5:28 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-httpauth-digest-18: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Just a few minor comments: > > 3.3, domain: "If the URI is an abs_path..." > > Should that be "path-absolute", in keeping with the reference to 3986? > > 3.6, paragraph 4: "Because the client is REQUIRED to return..." > > The use of a 2119 keyword in a dependent clause seems odd. > > 5.1: "Digest authentication SHOULD be used over a secure channel like > HTTPS" > > Does this mean that, if you have a secure channel you should use digest, > or if you use digest you should use a a secure channel? I assume the > second, but the sentence can be parsed either way. > > > --001a113cc1146663f805145696af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks for your review and comm= ents.
I will address these in the next version of the draft.

Regards,
=A0Rifaat


On Tue, Apr 21, = 2015 at 5:28 PM, Ben Campbell <ben@nostrum.com> wrote:
Ben Campbell has entered the following ballot po= sition for
draft-ietf-httpauth-digest-18: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/<= /a>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just a few minor comments:

3.3, domain: "If the URI is an abs_path..."

Should that be "path-absolute", in keeping with the reference to = 3986?

3.6, paragraph 4: "Because the client is REQUIRED to return..."
The use of a 2119 keyword in a dependent clause seems odd.

5.1:=A0 "Digest authentication SHOULD be used over a secure channel li= ke
HTTPS"

Does this mean that, if you have a secure channel you should use digest, or if you use digest you should use a a secure channel? I assume the
second, but the sentence can be parsed either way.



--001a113cc1146663f805145696af-- From nobody Wed Apr 22 14:17:11 2015 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 701361A8A60; Wed, 22 Apr 2015 14:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 sicTBgtfbDo7; Wed, 22 Apr 2015 14:17:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72D61A8A56; Wed, 22 Apr 2015 14:17:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 10ECEBEDF; Wed, 22 Apr 2015 22:17:06 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAaLW9ajkI1j; Wed, 22 Apr 2015 22:17:05 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2132BEDE; Wed, 22 Apr 2015 22:17:04 +0100 (IST) Message-ID: <55380FCE.40103@cs.tcd.ie> Date: Wed, 22 Apr 2015 22:17:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20150421165802.18601.71351.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 22 Apr 2015 21:17:10 -0000 On 22/04/15 22:08, Rifaat Shekh-Yusef wrote: >> > >> > > I did reply to that review. You did. > Do you have something specific that you think > we should address? it is the HMAC comment? I guess we ought just check again. It looked like the reviewer didn't get the backwards compatibility constraints under which this work is being done, but I wasn't entirely clear whether or not the suggested improvements would or would not break those constraints. It'd be good to check. Cheers, S. From nobody Thu Apr 23 16:52:03 2015 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 1105D1AD369; Thu, 23 Apr 2015 16:52:02 -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] 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 1coOKzNck3k2; Thu, 23 Apr 2015 16:52:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 662721A87ED; Thu, 23 Apr 2015 16:51:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150423235154.28153.27081.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 16:51:54 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-19.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: Thu, 23 Apr 2015 23:52:02 -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 : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-19.txt Pages : 30 Date : 2015-04-23 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPAuth working group mailing list (http-auth@ietf.org), which is archived at [1]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-19 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 Fri Apr 24 13:28:50 2015 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 546AF1A700E; Fri, 24 Apr 2015 13:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 E3ZcrDYt0ZRE; Fri, 24 Apr 2015 13:28:45 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959B61A6FED; Fri, 24 Apr 2015 13:28:44 -0700 (PDT) Received: by lagv1 with SMTP id v1so43350867lag.3; Fri, 24 Apr 2015 13:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cccebjB7S3h2m/XHzNyHnw2zNiunQxHnXcjnYtUCAp4=; b=qjCM1GzCwSpgKizGIKRKuYtRCog8MSo2omHjOcn5jc8cxZvETZfz5j3DVO4O/UYDSG JmfhV30x43tnc7d0RPiMWfgvbi7+5lFRtaS4LqCvQuzROYZlJoVNcz3B5OEFc4cODIn3 hWxPh5vuvTJdbb+8DoCg+GYh1x8io99YCZMAuRFR1NBy/0QojAmLzoDBs0HpENS0ROed Do3K5qDaHm/f0D9SVVrG8BFnbjwZoSKAhQNPkDHh11gWWgucJdl4HpYwpRNWRiAVQJ5z QTCqlrGVj3g1D4pHyDv4Jx+flIeNeywHsmqjJCdI4+TyDyJeAR4d8W1zlPzlVcC71vSQ HOsA== MIME-Version: 1.0 X-Received: by 10.112.166.37 with SMTP id zd5mr130398lbb.75.1429907323134; Fri, 24 Apr 2015 13:28:43 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Fri, 24 Apr 2015 13:28:42 -0700 (PDT) In-Reply-To: <55380FCE.40103@cs.tcd.ie> References: <20150421165802.18601.71351.idtracker@ietfa.amsl.com> <55380FCE.40103@cs.tcd.ie> Date: Fri, 24 Apr 2015 16:28:42 -0400 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c382d00ea5ec05147e3e66 Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 24 Apr 2015 20:28:46 -0000 --001a11c382d00ea5ec05147e3e66 Content-Type: text/plain; charset=UTF-8 Hi, It appears all of Stephen's comments have been addressed int he correct revision (as well as all of the AD comments). I see that Rifaat responded to Hilary, but there was no follow up (that I can find). Was there a result from the HMAC comment in her review? Thanks, Kathleen On Wed, Apr 22, 2015 at 5:17 PM, Stephen Farrell wrote: > > > On 22/04/15 22:08, Rifaat Shekh-Yusef wrote: > >> > > >> > > > I did reply to that review. > > You did. > > > Do you have something specific that you think > > we should address? it is the HMAC comment? > > I guess we ought just check again. It looked like the > reviewer didn't get the backwards compatibility constraints > under which this work is being done, but I wasn't entirely > clear whether or not the suggested improvements would or > would not break those constraints. It'd be good to check. > > Cheers, > S. > > -- Best regards, Kathleen --001a11c382d00ea5ec05147e3e66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

It appears all of Stephen's com= ments have been addressed int he correct revision (as well as all of the AD= comments).=C2=A0 I see that Rifaat responded to Hilary, but there was no f= ollow up (that I can find).=C2=A0 Was there a result from the HMAC comment = in her review?

Thanks,
Kathleen =C2=A0

On Wed,= Apr 22, 2015 at 5:17 PM, Stephen Farrell <stephen.farrell@cs.tcd.= ie> wrote:


On 22/04/15 22:08, Rifaat Shekh-Yusef wrote:
>> >
>> >
> I did reply to that review.

You did.

> Do you have something specific that you think
> we should address? it is the HMAC comment?

I guess we ought just check again. It looked like the
reviewer didn't get the backwards compatibility constraints
under which this work is being done, but I wasn't entirely
clear whether or not the suggested improvements would or
would not break those constraints. It'd be good to check.

Cheers,
S.




--

Best regards,
Kath= leen
--001a11c382d00ea5ec05147e3e66-- From nobody Fri Apr 24 13:56:14 2015 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 6DB021A895D; Fri, 24 Apr 2015 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 SmUprvf44keI; Fri, 24 Apr 2015 13:56:12 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEED1A1A2E; Fri, 24 Apr 2015 13:56:11 -0700 (PDT) Received: by oift201 with SMTP id t201so50385890oif.3; Fri, 24 Apr 2015 13:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fpPOSBrVe7+/olpHr0e8ZjHTCjUTJyprs8ubj7+5AwM=; b=xE4/Tx+/vJQ5OGfCp+/UtzgJM3hzfOAmkD5sLYtS2yLqyXQMMV2pbeiScMzmJzmV0b Ij1nZKQxJkqLh03UQF4goljzFj11yw3K6hnsE6W56UyYKTP0DjTYo2nGskFTbWnkEdGO rTrTRmlvDrTzMKa7wnzK07coR29YRoMP+njt3DQ/fiU6E+llulG9Z2Y2PwMfR7tQz64O JiAv6DmgMCn5VC+nl+P2BmCo23MIOR1xlR3Ho9bkdAUUAE6UyxhrFZIw+yX47rEgjQKJ iYSg2nWfO+wirezxDHt6E0iHqEP09X0WCRvR97njHGfjxlQz3p/CPufQQLTcHxLY83Ka cuYw== MIME-Version: 1.0 X-Received: by 10.202.84.135 with SMTP id i129mr263194oib.114.1429908971270; Fri, 24 Apr 2015 13:56:11 -0700 (PDT) Received: by 10.202.75.149 with HTTP; Fri, 24 Apr 2015 13:56:11 -0700 (PDT) In-Reply-To: References: <20150421165802.18601.71351.idtracker@ietfa.amsl.com> <55380FCE.40103@cs.tcd.ie> Date: Fri, 24 Apr 2015 16:56:11 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a113d23844b37fb05147ea0f2 Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 24 Apr 2015 20:56:13 -0000 --001a113d23844b37fb05147ea0f2 Content-Type: text/plain; charset=ISO-8859-1 HMAC was mentioned by both Francis (Gen-ART review) and Hilarie (SecDir review). As I mentioned before if it is ok with the ADs and the WG, I would be happy to start a discussion and put a proposal to address that. Is that acceptable at this stage? or maybe we should try to address HMAC and Salted hash (request from STUNbis team) in a separate document? Regards, Rifaat On Fri, Apr 24, 2015 at 4:28 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi, > > It appears all of Stephen's comments have been addressed int he correct > revision (as well as all of the AD comments). I see that Rifaat responded > to Hilary, but there was no follow up (that I can find). Was there a > result from the HMAC comment in her review? > > Thanks, > Kathleen > > On Wed, Apr 22, 2015 at 5:17 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> >> On 22/04/15 22:08, Rifaat Shekh-Yusef wrote: >> >> > >> >> > >> > I did reply to that review. >> >> You did. >> >> > Do you have something specific that you think >> > we should address? it is the HMAC comment? >> >> I guess we ought just check again. It looked like the >> reviewer didn't get the backwards compatibility constraints >> under which this work is being done, but I wasn't entirely >> clear whether or not the suggested improvements would or >> would not break those constraints. It'd be good to check. >> >> Cheers, >> S. >> >> > > > -- > > Best regards, > Kathleen > --001a113d23844b37fb05147ea0f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HMAC was mentioned by both Francis (Gen-ART review) and Hi= larie (SecDir review).
As I mentioned before if it is ok with the ADs a= nd the WG, I would be happy to start a discussion and put a proposal to add= ress that.
Is that acceptable at this stage? or maybe we should t= ry to address HMAC and Salted hash (request from STUNbis team) in a separat= e document?

Regards,
=A0Rifaat


= On Fri, Apr 24, 2015 at 4:28 PM, Kathleen Moriarty <kathlee= n.moriarty.ietf@gmail.com> wrote:
Hi,

It appears all of Stephen= 9;s comments have been addressed int he correct revision (as well as all of= the AD comments).=A0 I see that Rifaat responded to Hilary, but there was = no follow up (that I can find).=A0 Was there a result from the HMAC comment= in her review?

Thanks,
Kathleen =A0

On Wed, Apr 22, 2015 at 5:17 PM, Stephen Farrell <st= ephen.farrell@cs.tcd.ie> wrote:


On 22/04/15 22:08, Rifaat Shekh-Yusef wrote:
>> >
>> >
> I did reply to that review.

You did.

> Do you have something specific that you think
> we should address? it is the HMAC comment?

I guess we ought just check again. It looked like the
reviewer didn't get the backwards compatibility constraints
under which this work is being done, but I wasn't entirely
clear whether or not the suggested improvements would or
would not break those constraints. It'd be good to check.

Cheers,
S.




--

Best regards,
Kathleen

--001a113d23844b37fb05147ea0f2-- From nobody Fri Apr 24 14:10:13 2015 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 C94551AC3E5; Fri, 24 Apr 2015 14:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 S7UO2tF9TAU9; Fri, 24 Apr 2015 14:10:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053FC1AC3DB; Fri, 24 Apr 2015 14:10:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 79B5BBE56; Fri, 24 Apr 2015 22:10:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuPHQcbXR1U5; Fri, 24 Apr 2015 22:10:06 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 663B9BE49; Fri, 24 Apr 2015 22:10:03 +0100 (IST) Message-ID: <553AB128.9050100@cs.tcd.ie> Date: Fri, 24 Apr 2015 22:10:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , Kathleen Moriarty References: <20150421165802.18601.71351.idtracker@ietfa.amsl.com> <55380FCE.40103@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 24 Apr 2015 21:10:12 -0000 On 24/04/15 21:56, Rifaat Shekh-Yusef wrote: > Is that acceptable at this stage? or maybe we should try to address HMAC > and Salted hash (request from STUNbis team) in a separate document? I think a separate document may be correct, if there's a liklihood that it'd be implemented in browsers or some other HTTP clients and servers and if the httpauth WG wanted to process that. If any of the above are negative, then I suspect it's probably better to consider this idea as a reasonable road-not-followed. S. From nobody Fri Apr 24 14:17:36 2015 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 41E851AC3F6; Fri, 24 Apr 2015 14:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 fp9CuvZMAu7U; Fri, 24 Apr 2015 14:17:34 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38B91AC3F3; Fri, 24 Apr 2015 14:17:33 -0700 (PDT) Received: by oign205 with SMTP id n205so50743795oig.2; Fri, 24 Apr 2015 14:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o36yoGCy3L5me7TU4NFTsxy+SoSrjvkd9qsd+XHVnf4=; b=v2KyONDFuW2uj2yN75Md00tcD+AGi+jckbPYhIfvty3shoFFR/b2ELxSfDoN/WLRdc PZJ1Hi1ZgKO1Xa4fqaq4CtkkLlEK8r/DMGONITjeN4Heu/tgzxHOu1nVS0IqqoHdpQ+K FXMPqPZ0q37iCOrPe4zYYnDZJBi8F7fz7S/LEzA0JPynVjX7Rczvm3F8LmXJ5LbFdu73 AqXGjPcS2TyoGZl/i/zEdYw5SHnHbjy56iWm+Fyq5Rr+M2wKRqrEywpJLSe4emMZIxgy KI7nSMNQpgsXIyLZECZ/6PSQaZMk0fo4a3djgfxy4gPwNPG1GVqCRDe/MIIsOTi9F2hM KY8Q== MIME-Version: 1.0 X-Received: by 10.60.133.176 with SMTP id pd16mr355125oeb.78.1429910253549; Fri, 24 Apr 2015 14:17:33 -0700 (PDT) Received: by 10.202.75.149 with HTTP; Fri, 24 Apr 2015 14:17:33 -0700 (PDT) In-Reply-To: <553AB128.9050100@cs.tcd.ie> References: <20150421165802.18601.71351.idtracker@ietfa.amsl.com> <55380FCE.40103@cs.tcd.ie> <553AB128.9050100@cs.tcd.ie> Date: Fri, 24 Apr 2015 17:17:33 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b472876b93ebe05147eec6a Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 24 Apr 2015 21:17:35 -0000 --047d7b472876b93ebe05147eec6a Content-Type: text/plain; charset=ISO-8859-1 Ok. Let's then let this draft progress and I will start a separate discussion about HMAC & Salted hash. Regards, Rifaat On Fri, Apr 24, 2015 at 5:10 PM, Stephen Farrell wrote: > > > On 24/04/15 21:56, Rifaat Shekh-Yusef wrote: > > Is that acceptable at this stage? or maybe we should try to address HMAC > > and Salted hash (request from STUNbis team) in a separate document? > > I think a separate document may be correct, if there's a liklihood > that it'd be implemented in browsers or some other HTTP clients and > servers and if the httpauth WG wanted to process that. If any of the > above are negative, then I suspect it's probably better to consider > this idea as a reasonable road-not-followed. > > S. > --047d7b472876b93ebe05147eec6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok. Let's then let this draft progress and I will star= t a separate discussion about HMAC & Salted hash.

Re= gards,
=A0Rifaat


On Fri, Apr 24, 2015 at 5:1= 0 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wr= ote:


On 24/04/15 21:56, Rifaat Shekh-Yusef wrote:
> Is that acceptable at this stage? or maybe we should try to address HM= AC
> and Salted hash (request from STUNbis team) in a separate document?
I think a separate document may be correct, if there's a likliho= od
that it'd be implemented in browsers or some other HTTP clients and
servers and if the httpauth WG wanted to process that. If any of the
above are negative, then I suspect it's probably better to consider
this idea as a reasonable road-not-followed.

S.

--047d7b472876b93ebe05147eec6a-- From nobody Fri Apr 24 15:03:02 2015 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 79CC51ACEF9; Fri, 24 Apr 2015 15:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 XmDa42an3yGD; Fri, 24 Apr 2015 15:02:51 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647191ACE8F; Fri, 24 Apr 2015 15:02:44 -0700 (PDT) Received: by labbd9 with SMTP id bd9so44653007lab.2; Fri, 24 Apr 2015 15:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GIQYsC/sfJr/5kfFknH9cVgH2jjZTu9WeUK3MLvw1xk=; b=s9T/ix4sbm9J5X1y8cfog+TqHvXZ7vLM+qHyfiyAXDLWbmuKUvJVFJknaUFoXfR0fX F3/jhUxmeEKW0UgwLMa/006ELkpekqEHE4n+nq7PHSUZo6059vcboEb5ICuZod3XelsG q+FqxwFlVhjvLF5V0i1Vhsm++1OZJ55hBtXwn9yf6h4NIFmTr3TAZ/F86k5dO+y07Eas n8JXc5R0+QEYaq6Yi5zlLqQ5fXTv/52++k9m5mfSH+2TKaNLJrkrQX6V/k24pi2akM4q H6N4neEg0gJQJwSnX5Z41Ib+C5Yu8v71m+hM6zAiVHadtIwRQ5mPe9so4weS3Gi7X37c cxWg== MIME-Version: 1.0 X-Received: by 10.112.166.37 with SMTP id zd5mr380895lbb.75.1429912962990; Fri, 24 Apr 2015 15:02:42 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Fri, 24 Apr 2015 15:02:42 -0700 (PDT) In-Reply-To: References: <20150421165802.18601.71351.idtracker@ietfa.amsl.com> <55380FCE.40103@cs.tcd.ie> <553AB128.9050100@cs.tcd.ie> Date: Fri, 24 Apr 2015 18:02:42 -0400 Message-ID: From: Kathleen Moriarty To: Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary=001a11c382d038057f05147f8e24 Archived-At: Cc: draft-ietf-httpauth-digest.ad@ietf.org, httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-digest.shepherd@ietf.org, draft-ietf-httpauth-digest@ietf.org Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-digest-18: (with COMMENT) 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, 24 Apr 2015 22:02:55 -0000 --001a11c382d038057f05147f8e24 Content-Type: text/plain; charset=UTF-8 Excellent, thank you. On Fri, Apr 24, 2015 at 5:17 PM, Rifaat Shekh-Yusef wrote: > Ok. Let's then let this draft progress and I will start a separate > discussion about HMAC & Salted hash. > > Regards, > Rifaat > > > On Fri, Apr 24, 2015 at 5:10 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> >> On 24/04/15 21:56, Rifaat Shekh-Yusef wrote: >> > Is that acceptable at this stage? or maybe we should try to address HMAC >> > and Salted hash (request from STUNbis team) in a separate document? >> >> I think a separate document may be correct, if there's a liklihood >> that it'd be implemented in browsers or some other HTTP clients and >> servers and if the httpauth WG wanted to process that. If any of the >> above are negative, then I suspect it's probably better to consider >> this idea as a reasonable road-not-followed. >> >> S. >> > > -- Best regards, Kathleen --001a11c382d038057f05147f8e24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Excellent, thank you. =C2=A0

On Fri, Apr 24, 2015 at 5:17 PM, Rifaat S= hekh-Yusef <rifaat.ietf@gmail.com> wrote:
Ok. Let's then let this draft prog= ress and I will start a separate discussion about HMAC & Salted hash.
Regards,
=C2=A0Rifaat

=

On Fri, Apr 24, 2015 at 5:10 PM, Stephen= Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 24/04/15 21:56, Rifaat Shekh-Yusef wrote:
> Is that acceptable at this stage? or maybe we should try to address HM= AC
> and Salted hash (request from STUNbis team) in a separate document?
I think a separate document may be correct, if there's a likliho= od
that it'd be implemented in browsers or some other HTTP clients and
servers and if the httpauth WG wanted to process that. If any of the
above are negative, then I suspect it's probably better to consider
this idea as a reasonable road-not-followed.

S.




--
=

Best regards,
Kathleen
--001a11c382d038057f05147f8e24-- From nobody Mon Apr 27 13:23:53 2015 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 CDFE91A01D5; Mon, 27 Apr 2015 13:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 eBdE5UItlord; Mon, 27 Apr 2015 13:23:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A09751A88FE; Mon, 27 Apr 2015 13:23:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150427202348.7412.77388.idtracker@ietfa.amsl.com> Date: Mon, 27 Apr 2015 13:23:48 -0700 Archived-At: Cc: httpauth mailing list , httpauth chair , RFC Editor Subject: [http-auth] Protocol Action: 'HTTP Digest Access Authentication' to Proposed Standard (draft-ietf-httpauth-digest-19.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: Mon, 27 Apr 2015 20:23:52 -0000 The IESG has approved the following document: - 'HTTP Digest Access Authentication' (draft-ietf-httpauth-digest-19.txt) as Proposed Standard This document is the product of the Hypertext Transfer Protocol Authentication Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ Technical Summary HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. The combination of this document with the definition of the "Basic" authentication scheme [BASIC], "The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-Authentication-Info Response Header Fields" [AUTHINFO], and [RFC7235] obsolete [RFC2617]. Working Group Summary There is WG consensus for this draft. For the most part it describes existing practice, with the addition of a few things: o New algorithms: SHA2-256 and SHA2-512/256. o Internationalized character set support. o username hashing for enhanced privacy, While the working group was chartered to add the new algorithms and internationalization support, the addition of user name hashing is not in the charter. The group was specifically polled about whether they wanted to add features to a legacy protocol that is anyway vulnerable to dictionary attacks. The group consensus was that this should be done. With version -15 it is the consensus of the HTTP-Auth working group that this document is fit to be published as a standards-track RFC. Document Quality There are no implementations that include these updates yet. Personnel The Document Shepherd is Yoav Nir and the Responsible Area Director is Kathleen Moriarty. IANA Note This draft creates a registry using the 5226 "Specification Required" registration policy. IANA maintains the registry of HTTP Authentication Schemes ([RFC7235]) at and the entry for the "Digest" Authentication Scheme is to be added with a pointer to this specification. From nobody Mon Apr 27 15:02:24 2015 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 3EA0D1A1BFA for ; Mon, 27 Apr 2015 15:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Gy1sm_XwhAKj for ; Mon, 27 Apr 2015 15:02:18 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09881A006D for ; Mon, 27 Apr 2015 15:02:17 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so94241381wic.1 for ; Mon, 27 Apr 2015 15:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ohL49rYGyJtK/XRbIds2E8ghaa+g/8YXzNxMTHRdtso=; b=w7GBRsEMJYP5w2AGAyRI2O1AnbzcIg3XD5BfyzQN1gA/EPzzRHrFXEAkCxBJAClTWG 2dZGaNLL2/QFHY/pE6y4jZMCE0F0Sl/yVHbQNJ8uzglWiiZd468jJCfGVtaxsYtK/3M/ XxbgO++/qVD+1xHI0+L52GL2JFuMXvJ0+JKWEkruvH2FvIiFWvLhSz+58Q9QhEDZ5KhQ q6zLkILvBjGe3D6D5SnzW9NAohcfMwCkRmLOEbAKVtpTJV64/ymKszRv7XkPZK7O/3Vm n2CRenVnKOgytb9KHkIvJCoAMBDZL3GYk//ZCK625lUGguUJegbzmCd2rq2xNGg0/SzT T3CA== X-Received: by 10.195.18.103 with SMTP id gl7mr25775146wjd.34.1430172136131; Mon, 27 Apr 2015 15:02:16 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id fs9sm31206686wjc.34.2015.04.27.15.02.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 15:02:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <20150427202348.7412.77388.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 01:02:14 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <20150427202348.7412.77388.idtracker@ietfa.amsl.com> To: httpauth mailing list X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [http-auth] Protocol Action: 'HTTP Digest Access Authentication' to Proposed Standard (draft-ietf-httpauth-digest-19.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: Mon, 27 Apr 2015 22:02:22 -0000 Congratulations to Rifaat, David and Sophie. And thanks to everyone in the group who participated. Yoav & Matt > On Apr 27, 2015, at 11:23 PM, The IESG wrote: > > The IESG has approved the following document: > - 'HTTP Digest Access Authentication' > (draft-ietf-httpauth-digest-19.txt) as Proposed Standard > > This document is the product of the Hypertext Transfer Protocol > Authentication Working Group. > > The IESG contact persons are Stephen Farrell and Kathleen Moriarty. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > > > > > Technical Summary > > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that can be used with the HTTP > authentication mechanism. > > The combination of this document with the definition of the "Basic" > authentication scheme [BASIC], "The Hypertext Transfer Protocol > (HTTP) Authentication-Info and Proxy-Authentication-Info Response > Header Fields" [AUTHINFO], and [RFC7235] obsolete [RFC2617]. > > Working Group Summary > > There is WG consensus for this draft. For the most part it describes > existing practice, with the addition of a few things: > o New algorithms: SHA2-256 and SHA2-512/256. > o Internationalized character set support. > o username hashing for enhanced privacy, > > While the working group was chartered to add the new algorithms and > internationalization support, the addition of user name hashing is > not in the charter. The group was specifically polled about whether > they wanted to add features to a legacy protocol that is anyway > vulnerable to dictionary attacks. The group consensus was that this > should be done. > > With version -15 it is the consensus of the HTTP-Auth working group > that this document is fit to be published as a standards-track RFC. > > Document Quality > > There are no implementations that include these updates yet. > > Personnel > > The Document Shepherd is Yoav Nir and the > Responsible Area Director is Kathleen Moriarty. > > IANA Note > > This draft creates a registry using the 5226 "Specification Required" > registration policy. > > IANA maintains the registry of HTTP Authentication Schemes > ([RFC7235]) at > and the entry for the "Digest" Authentication Scheme is to be added with > a pointer to this specification. > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth