From nobody Mon Feb 2 04:22:16 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 7A3D11A0275 for ; Mon, 2 Feb 2015 04:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8qKomEQX4Vh3 for ; Mon, 2 Feb 2015 04:22:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 F352C1A026F for ; Mon, 2 Feb 2015 04:22:10 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MO77c-1YLZvo20fs-005V3Z for ; Mon, 02 Feb 2015 13:22:08 +0100 Message-ID: <54CF6BE5.8050009@gmx.de> Date: Mon, 02 Feb 2015 13:21:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <20150202051736.1978.38813.idtracker@ietfa.amsl.com> In-Reply-To: <20150202051736.1978.38813.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150202051736.1978.38813.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:+/UzF/cxX1jLP9Vkd6zIAiXZRIoHXVComuOdN4phCxDF0//3LUs Pgl6V9sO6vYm4ByCSO5pDpKmk5zVpg2m8UEp0kP5QiaZMLeyMbewJuGs9wHhMr7B5FT/Xov q1+5dx2G10bUy6J996glZLYOxWBsA+iLGbP4tMN+mxfUs24kpjEG1729h6z6jVcGkJFjPUK QYmLgwZuCT/NElMWDOGrA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [http-auth] Fwd: New Version Notification for draft-ietf-httpbis-auth-info-00.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, 02 Feb 2015 12:22:14 -0000 FYI - this is no a draft in the HTTPbis Working Group. Best regards, Julian -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-httpbis-auth-info-00.txt Date: Sun, 01 Feb 2015 21:17:36 -0800 From: internet-drafts@ietf.org To: Julian F. Reschke , Julian F. Reschke A new version of I-D, draft-ietf-httpbis-auth-info-00.txt has been successfully submitted by Julian F. Reschke and posted to the IETF repository. Name: draft-ietf-httpbis-auth-info Revision: 00 Title: The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy- Authentication-Info Response Header Fields Document date: 2015-01-30 Group: httpbis Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-ietf-httpbis-auth-info-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-httpbis-auth-info/ Htmlized: http://tools.ietf.org/html/draft-ietf-httpbis-auth-info-00 Abstract: This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP authentication schemes which need to return additional information during or after authentication. 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. The IETF Secretariat From nobody Mon Feb 2 04:46:52 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 036BC1A037D for ; Mon, 2 Feb 2015 04:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 V3zqWnRXEEHY for ; Mon, 2 Feb 2015 04:46:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 7A8AF1A037C for ; Mon, 2 Feb 2015 04:46:48 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMCFR-1YJ5D90YIv-007z2G for ; Mon, 02 Feb 2015 13:46:46 +0100 Message-ID: <54CF71AA.8020406@gmx.de> Date: Mon, 02 Feb 2015 13:46:34 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <20150202051736.1978.38813.idtracker@ietfa.amsl.com> <54CF6BE5.8050009@gmx.de> In-Reply-To: <54CF6BE5.8050009@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:M3QmQguJFENgVnYR4q0aPLHwdKSMyrSaNYbhZ/C0YeRxG7aH8Hv DG+KYR61OYSYOYHPmZmD0o50G5lhFH5a6lwXzktjjzANnNaUTYPeps8bspf0bI3wDyz8Qex Pr1A0W4VCyshfbyFqrLw6ZWRJgC2iUobz+afFz6wcnsY+QtosuG3t5XyuHN0qdinn2yljUM UPbvkIaGE7M/sOE5QNhEQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [http-auth] Fwd: New Version Notification for draft-ietf-httpbis-auth-info-00.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, 02 Feb 2015 12:46:51 -0000 On 2015-02-02 13:21, Julian Reschke wrote: > FYI - this is no a draft in the HTTPbis Working Group. > > Best regards, Julian > ... Oh well. s/no/now/ Best regards, Julian From nobody Mon Feb 2 06:10: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 3E0FE1A1B62 for ; Mon, 2 Feb 2015 06:10:01 -0800 (PST) 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 QE_E_J_KB3s5 for ; Mon, 2 Feb 2015 06:09:50 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1132F1A1A83 for ; Mon, 2 Feb 2015 06:08:19 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id l61so39191400wev.8 for ; Mon, 02 Feb 2015 06:08:17 -0800 (PST) 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=uqSKKoXcubEoqAGQBcHANvomWMS8qJIqigNAjZee9JI=; b=Nica/aHS+T+5B9ke+UnG694fnJm6KI1Fz7b+r1WZzKI2gnHWZGNPF9+EqznkJa1WUI Nm2iAgG5E8UlpBKM8H4yV19Z3fiNhJSOtFObq8t6gVIvfVkse0Ye8wRvkZ5JGin0+IXz 2BBFxH6309I5iS+JtvbYE74UWnyLAGISokIqUAbYgXwWYAJt6kp4k8LcxJ5twzjKdKb2 gcmKAiIe1k4Fnt7q5x7mHQNIrm1eGLNNX2hqdxTwGR91o3kYON0iAN6/Ha5ei9oWhtWb SwEJBzTpDGeoyf1zkOmJIWIlcXNh9rN4oW6hiLVreWf4DM/8NWk3hNHM5TP6oA6aOLqf IFug== X-Received: by 10.180.88.103 with SMTP id bf7mr25120678wib.21.1422886097607; Mon, 02 Feb 2015 06:08:17 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id gm10sm19991316wib.19.2015.02.02.06.08.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Feb 2015 06:08:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <54CF6BE5.8050009@gmx.de> Date: Mon, 2 Feb 2015 16:08:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150202051736.1978.38813.idtracker@ietfa.amsl.com> <54CF6BE5.8050009@gmx.de> To: Julian Reschke , Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] New Version Notification for draft-ietf-httpbis-auth-info-00.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, 02 Feb 2015 14:10:01 -0000 Thanks, Julian Rifaat: Can you create a new version of the Digest draft that replaces = the text of 3.5 (but not 3.5.1!) with a reference to this draft? Then we can start a second WGLC for Digest. Thanks Yoav > On Feb 2, 2015, at 2:21 PM, Julian Reschke = wrote: >=20 > FYI - this is no a draft in the HTTPbis Working Group. >=20 > Best regards, Julian >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-ietf-httpbis-auth-info-00.txt > Date: Sun, 01 Feb 2015 21:17:36 -0800 > From: internet-drafts@ietf.org > To: Julian F. Reschke , Julian F. = Reschke >=20 >=20 > A new version of I-D, draft-ietf-httpbis-auth-info-00.txt > has been successfully submitted by Julian F. Reschke and posted to the > IETF repository. >=20 > Name: draft-ietf-httpbis-auth-info > Revision: 00 > Title: The Hypertext Transfer Protocol (HTTP) = Authentication-Info and Proxy- Authentication-Info Response Header = Fields > Document date: 2015-01-30 > Group: httpbis > Pages: 6 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-httpbis-auth-info-00.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-httpbis-auth-info/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-httpbis-auth-info-00 >=20 >=20 > Abstract: > This specification defines the "Authentication-Info" and "Proxy- > Authentication-Info" response header fields for use in HTTP > authentication schemes which need to return additional information > during or after authentication. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Mon Feb 2 06:11:35 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 022CC1A1A48 for ; Mon, 2 Feb 2015 06:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 koKP2FQVRPpw for ; Mon, 2 Feb 2015 06:11:30 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA8A1A1B34 for ; Mon, 2 Feb 2015 06:09:33 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ge10so41221962lab.10 for ; Mon, 02 Feb 2015 06:09:32 -0800 (PST) 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=C77iRQJkJqqnhUkthxpyLA4EeBEsfisuRXdkSJw7Fis=; b=IUYXphnFkdsvQ065D+Zs7knauxJOIuqJIij/JRYBmR3kMlAK8DgA0UNajKWgBp2JLE n0x8p2UiL9SfQ+inc0PDALBs4NjyI8ToSU4G9VKbmJF9/b+lBrzCltuUkh6mzDrASOOc U26cjwHBWDZ/0kfCYYoFZ6apkytVUV9Khu9U57P7YjAHFp5Rb/+NLeXlFxj6moIqqyLv bE7cS5psFsi4RZgjpdLEF8Fqww7ZSPJPxyL9Y4nYWFPjUURYreEoM/ll8tQMqCJ18PI+ XaE27zuN/l+i9jGrmjjqokl/XTQ0Zjul+jz1kyZ+1GMfSEjmz97TcE9vV8k2Homypb3X wFCQ== MIME-Version: 1.0 X-Received: by 10.152.4.200 with SMTP id m8mr19730204lam.2.1422886172481; Mon, 02 Feb 2015 06:09:32 -0800 (PST) Received: by 10.114.27.162 with HTTP; Mon, 2 Feb 2015 06:09:32 -0800 (PST) In-Reply-To: References: <20150202051736.1978.38813.idtracker@ietfa.amsl.com> <54CF6BE5.8050009@gmx.de> Date: Mon, 2 Feb 2015 09:09:32 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Yoav Nir Content-Type: multipart/alternative; boundary=089e013d1152dddf14050e1b807e Archived-At: Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] New Version Notification for draft-ietf-httpbis-auth-info-00.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, 02 Feb 2015 14:11:33 -0000 --089e013d1152dddf14050e1b807e Content-Type: text/plain; charset=ISO-8859-1 Sure. On Mon, Feb 2, 2015 at 9:08 AM, Yoav Nir wrote: > Thanks, Julian > > Rifaat: Can you create a new version of the Digest draft that replaces the > text of 3.5 (but not 3.5.1!) with a reference to this draft? > > Then we can start a second WGLC for Digest. > > Thanks > > Yoav > > > On Feb 2, 2015, at 2:21 PM, Julian Reschke > wrote: > > > > FYI - this is no a draft in the HTTPbis Working Group. > > > > Best regards, Julian > > > > -------- Forwarded Message -------- > > Subject: New Version Notification for draft-ietf-httpbis-auth-info-00.txt > > Date: Sun, 01 Feb 2015 21:17:36 -0800 > > From: internet-drafts@ietf.org > > To: Julian F. Reschke , Julian F. Reschke > > > > > > > A new version of I-D, draft-ietf-httpbis-auth-info-00.txt > > has been successfully submitted by Julian F. Reschke and posted to the > > IETF repository. > > > > Name: draft-ietf-httpbis-auth-info > > Revision: 00 > > Title: The Hypertext Transfer Protocol (HTTP) > Authentication-Info and Proxy- Authentication-Info Response Header Fields > > Document date: 2015-01-30 > > Group: httpbis > > Pages: 6 > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-httpbis-auth-info-00.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-httpbis-auth-info/ > > Htmlized: > http://tools.ietf.org/html/draft-ietf-httpbis-auth-info-00 > > > > > > Abstract: > > This specification defines the "Authentication-Info" and "Proxy- > > Authentication-Info" response header fields for use in HTTP > > authentication schemes which need to return additional information > > during or after authentication. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > --089e013d1152dddf14050e1b807e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sure.

On Mon, Feb 2, 2015 at 9:08 AM, Yoav Nir <<= a href=3D"mailto:ynir.ietf@gmail.com" target=3D"_blank">ynir.ietf@gmail.com= > wrote:
Thanks, Julian

Rifaat: Can you create a new version of the Digest draft that replaces the = text of 3.5 (but not 3.5.1!) with a reference to this draft?

Then we can start a second WGLC for Digest.

Thanks

Yoav

> On Feb 2, 2015, at 2:21 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> FYI - this is no a draft in the HTTPbis Working Group.
>
> Best regards, Julian
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-ietf-httpbis-auth-info-00.= txt
> Date: Sun, 01 Feb 2015 21:17:36 -0800
> From: internet-drafts@ietf= .org
> To: Julian F. Reschke <julian.reschke@greenbytes.de>, Julian F. Reschke <julian.reschke@greenbytes.de> >
>
> A new version of I-D, draft-ietf-httpbis-auth-info-00.txt
> has been successfully submitted by Julian F. Reschke and posted to the=
> IETF repository.
>
> Name:=A0 =A0 =A0 =A0 =A0draft-ietf-httpbis-auth-info
> Revision:=A0 =A0 =A000
> Title:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The Hypertext Transfer Protocol = (HTTP) Authentication-Info and Proxy- Authentication-Info Response Header F= ields
> Document date:=A0 =A0 =A0 =A0 2015-01-30
> Group:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 httpbis
> Pages:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6
> URL: http://www.ietf.org/internet-drafts/dr= aft-ietf-httpbis-auth-info-00.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-= httpbis-auth-info/
> Htmlized:=A0 =A0 =A0 =A0http://tools.ietf.org/html/draft= -ietf-httpbis-auth-info-00
>
>
> Abstract:
>=A0 =A0This specification defines the "Authentication-Info" a= nd "Proxy-
>=A0 =A0Authentication-Info" response header fields for use in HTTP=
>=A0 =A0authentication schemes which need to return additional informati= on
>=A0 =A0during or after authentication.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth


--089e013d1152dddf14050e1b807e-- From nobody Mon Feb 2 16:43: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 EFA441A87ED; Mon, 2 Feb 2015 16:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK2KA1KZmURI; Mon, 2 Feb 2015 16:43:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC041A8747; Mon, 2 Feb 2015 16:43:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150203004341.18601.84363.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 16:43:41 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-13.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, 03 Feb 2015 00:43:43 -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-13.txt Pages : 29 Date : 2015-02-02 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-13 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 Mon Feb 2 16:45: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 2CA5E1A1ADD for ; Mon, 2 Feb 2015 16:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 QoTbZXil8Rz6 for ; Mon, 2 Feb 2015 16:45:53 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD6B1A07BE for ; Mon, 2 Feb 2015 16:45:52 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id hv19so46495913lab.13 for ; Mon, 02 Feb 2015 16:45:51 -0800 (PST) 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=WkJkQtcCY2s1fj9lG4TiPs5vfOEXR6ascACY0A2uzuU=; b=HDXyltli8TwEN2R226CSkXwW7rXlWpGgL8kq64S5luCsX9qsZTP0KyqErWUnGRjhMk 8w5K3d2tU5pFNe5GKHRY4zkbHi4foLCYuiP3vg8RtEfKei6+Slw8tAxJDVZWxFdhaAMj aOFNiUA0PgrwVug5nHKQJ73B2HX/DjUQuce8TQzjpLfhaeM/PTR5PcqrJ99IAuv8vHxv RxGWz8d/BIYMigI202Ey5U4GNoLX/787xr+dZQIea4JxDS5QxVGVKjQ5nBVKXmnuPlM8 xumXgW8xHCYkd1Ru1zJbq0VwgpF3mgOro9omGrywMclmnvTglJREVrxlp6ebvPPw6LJR hZ7A== MIME-Version: 1.0 X-Received: by 10.152.4.200 with SMTP id m8mr22221226lam.2.1422924351373; Mon, 02 Feb 2015 16:45:51 -0800 (PST) Received: by 10.114.27.162 with HTTP; Mon, 2 Feb 2015 16:45:51 -0800 (PST) In-Reply-To: References: <20150202051736.1978.38813.idtracker@ietfa.amsl.com> <54CF6BE5.8050009@gmx.de> Date: Mon, 2 Feb 2015 19:45:51 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Yoav Nir Content-Type: multipart/alternative; boundary=089e013d1152818621050e246405 Archived-At: Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] New Version Notification for draft-ietf-httpbis-auth-info-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 00:45:55 -0000 --089e013d1152818621050e246405 Content-Type: text/plain; charset=ISO-8859-1 Done. On Mon, Feb 2, 2015 at 9:08 AM, Yoav Nir wrote: > Thanks, Julian > > Rifaat: Can you create a new version of the Digest draft that replaces the > text of 3.5 (but not 3.5.1!) with a reference to this draft? > > Then we can start a second WGLC for Digest. > > Thanks > > Yoav > > > On Feb 2, 2015, at 2:21 PM, Julian Reschke > wrote: > > > > FYI - this is no a draft in the HTTPbis Working Group. > > > > Best regards, Julian > > > > -------- Forwarded Message -------- > > Subject: New Version Notification for draft-ietf-httpbis-auth-info-00.txt > > Date: Sun, 01 Feb 2015 21:17:36 -0800 > > From: internet-drafts@ietf.org > > To: Julian F. Reschke , Julian F. Reschke > > > > > > > A new version of I-D, draft-ietf-httpbis-auth-info-00.txt > > has been successfully submitted by Julian F. Reschke and posted to the > > IETF repository. > > > > Name: draft-ietf-httpbis-auth-info > > Revision: 00 > > Title: The Hypertext Transfer Protocol (HTTP) > Authentication-Info and Proxy- Authentication-Info Response Header Fields > > Document date: 2015-01-30 > > Group: httpbis > > Pages: 6 > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-httpbis-auth-info-00.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-httpbis-auth-info/ > > Htmlized: > http://tools.ietf.org/html/draft-ietf-httpbis-auth-info-00 > > > > > > Abstract: > > This specification defines the "Authentication-Info" and "Proxy- > > Authentication-Info" response header fields for use in HTTP > > authentication schemes which need to return additional information > > during or after authentication. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > --089e013d1152818621050e246405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Done.

On Mon, Feb 2, 2015 at 9:08 AM, Yoav Nir <<= a href=3D"mailto:ynir.ietf@gmail.com" target=3D"_blank">ynir.ietf@gmail.com= > wrote:
Thanks, Julian

Rifaat: Can you create a new version of the Digest draft that replaces the = text of 3.5 (but not 3.5.1!) with a reference to this draft?

Then we can start a second WGLC for Digest.

Thanks

Yoav

> On Feb 2, 2015, at 2:21 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> FYI - this is no a draft in the HTTPbis Working Group.
>
> Best regards, Julian
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-ietf-httpbis-auth-info-00.= txt
> Date: Sun, 01 Feb 2015 21:17:36 -0800
> From: internet-drafts@ietf= .org
> To: Julian F. Reschke <julian.reschke@greenbytes.de>, Julian F. Reschke <julian.reschke@greenbytes.de> >
>
> A new version of I-D, draft-ietf-httpbis-auth-info-00.txt
> has been successfully submitted by Julian F. Reschke and posted to the=
> IETF repository.
>
> Name:=A0 =A0 =A0 =A0 =A0draft-ietf-httpbis-auth-info
> Revision:=A0 =A0 =A000
> Title:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The Hypertext Transfer Protocol = (HTTP) Authentication-Info and Proxy- Authentication-Info Response Header F= ields
> Document date:=A0 =A0 =A0 =A0 2015-01-30
> Group:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 httpbis
> Pages:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6
> URL: http://www.ietf.org/internet-drafts/dr= aft-ietf-httpbis-auth-info-00.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-= httpbis-auth-info/
> Htmlized:=A0 =A0 =A0 =A0http://tools.ietf.org/html/draft= -ietf-httpbis-auth-info-00
>
>
> Abstract:
>=A0 =A0This specification defines the "Authentication-Info" a= nd "Proxy-
>=A0 =A0Authentication-Info" response header fields for use in HTTP=
>=A0 =A0authentication schemes which need to return additional informati= on
>=A0 =A0during or after authentication.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth


--089e013d1152818621050e246405-- From nobody Tue Feb 3 11:22: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 DFA831A8860 for ; Tue, 3 Feb 2015 11:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 vXZ7fNEMrYza for ; Tue, 3 Feb 2015 11:22:48 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B821A886B for ; Tue, 3 Feb 2015 11:22:48 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id w55so41525318wes.5 for ; Tue, 03 Feb 2015 11:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=it+aMn4Sl6Ah0tqPxi9VnkB3IWeew3rQP4v1cD764kE=; b=su4OBTXRin/oNBsRaHK1NH1QHstevZaQqDpR3rTWRvmpC7PXp4te0aPX54cRRrGiM/ OsFexjWRJA0+BTHpFOqjxW5buO4ZsGY3akP0OaFxBNSbAVYdCXgYmJ78DS1KPn1H7g9R Dy3AhBY+MS6RKNuBsARvzyfq5gHL59v5DKbB4r0TjSNWMFsTlk+Sk/ddI9gKHvBO1j+Y iTVthrJW5665CAc6y1mSHeg/OfSUoLThMsuoGuLMUOXlD8vr2N5v2P/wQnex7UYuiBV/ ZBPGXIc5w58WUin7of1so9MzojCbghvWhbw6/1su1QuVl3QEbPzUPCatN6sRUjp9fBfE bN+Q== X-Received: by 10.180.35.42 with SMTP id e10mr37094337wij.11.1422991367025; Tue, 03 Feb 2015 11:22:47 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id a20sm25822832wic.16.2015.02.03.11.22.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 11:22:46 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_2B38FB53-43DD-4970-B645-02A1083900E7" Message-Id: <080852A1-AC04-4AD4-AC08-0EBAF1CB8816@gmail.com> Date: Tue, 3 Feb 2015 21:22:44 +0200 To: IETF HTTP Auth Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [http-auth] WGLC (take II) for draft-ietf-httpauth-digest 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, 03 Feb 2015 19:22:51 -0000 --Apple-Mail=_2B38FB53-43DD-4970-B645-02A1083900E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all Following the many changes made after the previous WGLC, this begins = another two-week Working Group Last Call for the Digest draft. Please read the document [1] and send comments as a reply to this = message. =E2=80=9CLooks OK. Ship it.=E2=80=9D is a fine reply, but = =E2=80=9Cnot ready=E2=80=9D should be accompanies by an explanation. WGLC ends EOD Tuesday 17-Feb-2015. Thanks Matt & Yoav [1] https://tools.ietf.org/html/draft-ietf-httpauth-digest = --Apple-Mail=_2B38FB53-43DD-4970-B645-02A1083900E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all

Following the many changes made after the previous WGLC, this = begins another two-week Working Group Last Call for the Digest = draft.

Please = read the document [1] and send comments as a reply to this message. = =E2=80=9CLooks OK. Ship it.=E2=80=9D is a fine reply, but =E2=80=9Cnot = ready=E2=80=9D should be accompanies by an explanation.

WGLC ends EOD Tuesday = 17-Feb-2015.

Thanks

Matt & Yoav
 [1] https://tools.ietf.org/html/draft-ietf-httpauth-digest


= --Apple-Mail=_2B38FB53-43DD-4970-B645-02A1083900E7-- From nobody Tue Feb 3 18:03: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 141FF1A1BA9 for ; Tue, 3 Feb 2015 18:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fIju6hmXL_z for ; Tue, 3 Feb 2015 18:02:59 -0800 (PST) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD751A1B6C for ; Tue, 3 Feb 2015 18:02:58 -0800 (PST) Received: from mail-la0-f49.google.com ([209.85.215.49]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKVNF90a70CyXaFaRnf+OoYlH88fiqQ62a@postini.com; Tue, 03 Feb 2015 18:02:58 PST Received: by mail-la0-f49.google.com with SMTP id gf13so55491836lab.8 for ; Tue, 03 Feb 2015 18:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8qHGtia/vYB0bqs0ankG/Jj88kceO8pP+5GV39CguRc=; b=s/HtuMkLmDZYp439ByWVIQQ9P656w/y4TkC+UTJO+XaCuA9O818yz03DBwMcBaMAl7 iPF5qmMMNSj2bH3yvvt8rIkptb8H2ZvX8DSR+XGU0c82rV7m+FZirg818eC8pBGWBg9m blWzelarU4aWP3XOKfd5jc+WS0Q5GFFvGGsNA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8qHGtia/vYB0bqs0ankG/Jj88kceO8pP+5GV39CguRc=; b=WtVHy3cxGUoc64GbBSrAmWVa+Vu9EdfplGTBL/9gyMQ+Bs682I2KPuGf+TYaVOP8L4 6Elocs/p1v0D5Vtcf/C2iM6Sg1PZXxjhMqsKRzT6Ty1UbX8v2FXNV5IMoYwBV2BiBLu2 o9CJgOhIjdQpaXy1pGrZw8FkkCjfkTKFD8iNfu0V+jXFHmn1ZHT0tzrweTvKRIDaUf9T eRjOOZBXifcUhVLOxoSZD6RDnUrHaKnpDyoXd7Pmd5lmIaiGyGzDf4WofDs0A65E9f1o Y2VF4SXp4TsvsQAwp1QhZ0Xa2/AxrAI5udlqAWXN8gp2O4uJtD27Y2ic1aOhTt5BTol8 pVkw== X-Gm-Message-State: ALoCoQmMGfVTdyGE2wah4fI4MK+4qwbGlLElC3TUEE6FkYtrcLb4dmiRKhyvqSgg7RXicM4dLIKMiqv404DX5zl+fiqayfnbu6i7JygM/Vp5uyXUCHPrYnd//g1RoZLeC/dgtpNzKuW/3hwRJG8jFRSIIMGoInqlDQ== X-Received: by 10.152.5.41 with SMTP id p9mr10423750lap.7.1423015376565; Tue, 03 Feb 2015 18:02:56 -0800 (PST) X-Received: by 10.152.5.41 with SMTP id p9mr10423745lap.7.1423015376476; Tue, 03 Feb 2015 18:02:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.83.203 with HTTP; Tue, 3 Feb 2015 18:02:35 -0800 (PST) In-Reply-To: <54CF6BE5.8050009@gmx.de> References: <20150202051736.1978.38813.idtracker@ietfa.amsl.com> <54CF6BE5.8050009@gmx.de> From: Yutaka OIWA Date: Wed, 4 Feb 2015 11:02:35 +0900 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: New Version Notification for draft-ietf-httpbis-auth-info-00.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: Wed, 04 Feb 2015 02:03:01 -0000 Great! I'll update my drafts in several days (before the expiry date). I'll also incorporate the following changes into the drafts: * adopt draft-ietf-precis-saslprepbis (my draft-oiwa-precis-httpauthprep profiles are merged into it) * adopt RFC5987 (safe UTF-8 encoding in HTTP headers) * and, adopt draft-ietf-httpbis-auth-info! 2015-02-02 21:21 GMT+09:00 Julian Reschke : > FYI - this is no a draft in the HTTPbis Working Group. > > Best regards, Julian > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-ietf-httpbis-auth-info-00.txt > Date: Sun, 01 Feb 2015 21:17:36 -0800 > From: internet-drafts@ietf.org > To: Julian F. Reschke , Julian F. Reschke > > > > A new version of I-D, draft-ietf-httpbis-auth-info-00.txt > has been successfully submitted by Julian F. Reschke and posted to the > IETF repository. > > Name: draft-ietf-httpbis-auth-info > Revision: 00 > Title: The Hypertext Transfer Protocol (HTTP) Authentication-Info > and Proxy- Authentication-Info Response Header Fields > Document date: 2015-01-30 > Group: httpbis > Pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-ietf-httpbis-auth-info-00.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-httpbis-auth-info/ > Htmlized: http://tools.ietf.org/html/draft-ietf-httpbis-auth-info-00 > > > Abstract: > This specification defines the "Authentication-Info" and "Proxy- > Authentication-Info" response header fields for use in HTTP > authentication schemes which need to return additional information > during or after authentication. > > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Tue Feb 3 18:18:33 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 107491A1B8E for ; Tue, 3 Feb 2015 18:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zrw4caDg4J6V for ; Tue, 3 Feb 2015 18:18:31 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (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 EAA591A1A39 for ; Tue, 3 Feb 2015 18:18:30 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id b16so970326igk.1 for ; Tue, 03 Feb 2015 18:18:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pjfWF8cXMz6izMxus39evwaXbAi3M49/lpVccL/gEyQ=; b=ToXWBVihxHWGRL1taQrn8uVHvfPp5Q/wsH6e5B/BttqVQ7yqWCTAuUA4WGy9Kbijvr /d/YtqQe9RGbYDLiqXM85InHd2EYp169Od2FvOW2Lpb+c0VgSGJ/vD4/gG9sXjlGbLMN zdb9DAZXMXFYfDc7I79yjxReOQdp11iBMUpZU3XKwnBKR3xMLmJnQHYyfDKC74l5orvy e63lPjUzGPShunUudlGvp4nTUWm4khla+0lAOBgzZcMQM+9A1q+DJRPnbjVjio0j7LvP vDlR2MkV8PpFJ160YGto/qKiubhzYnmAVFeLwyNnN74XWj+7UQcCLSJ1z1FeK6+tdecH K8ow== X-Gm-Message-State: ALoCoQkxoGTeM3U7U0VHA3vtWBhwf50HR1q67xJHxr217a5QzBrpZoi3VFSWanPTeVnoX3h35WHQ X-Received: by 10.50.171.170 with SMTP id av10mr1878679igc.28.1423016310418; Tue, 03 Feb 2015 18:18:30 -0800 (PST) Received: from aither.local ([2601:1:8202:a280:7cab:ce95:63:d0bd]) by mx.google.com with ESMTPSA id l20sm212281iol.25.2015.02.03.18.18.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Feb 2015 18:18:29 -0800 (PST) Message-ID: <54D18174.1070104@andyet.net> Date: Tue, 03 Feb 2015 19:18:28 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yutaka OIWA , Julian Reschke References: <20150202051736.1978.38813.idtracker@ietfa.amsl.com> <54CF6BE5.8050009@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: New Version Notification for draft-ietf-httpbis-auth-info-00.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: Wed, 04 Feb 2015 02:18:32 -0000 On 2/3/15 7:02 PM, Yutaka OIWA wrote: > Great! > > I'll update my drafts in several days (before the expiry date). > I'll also incorporate the following changes into the drafts: > > * adopt draft-ietf-precis-saslprepbis > (my draft-oiwa-precis-httpauthprep profiles are merged into it) > * adopt RFC5987 (safe UTF-8 encoding in HTTP headers) > * and, adopt draft-ietf-httpbis-auth-info! Excellent, I'll review your revised I-Ds for sure. Peter From nobody Wed Feb 4 04:35:21 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 42B061A0084 for ; Wed, 4 Feb 2015 04:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 Db-pQ7EMAAFl for ; Wed, 4 Feb 2015 04:35:18 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (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 A8DFA1A007B for ; Wed, 4 Feb 2015 04:35:18 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id l6so868030qcy.13 for ; Wed, 04 Feb 2015 04:35:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=0bNPwXrLqWOA/Ncse51CvGq0u5mjupB4HvxbRhvOXw4=; b=DzSuSJnDa0KM3hwtAEou8iyKhjpeUKoCJBJmkKS/WA8X515QATB9K9JXnq4PVyc2op aEUrcFDW8O4vHIGz++ks2+3Xv6AOX0jaVEXeXXFHP94OSHsz06+TL2cmF4QVwNxoT8lZ +mOKMF7XY6qSRdbHDYlg4kLyfy1wXiAoCc9Inw892Ag+p4g+pDq+1lWh5vvd+TMNprZ4 +VgU9XftFZ3l1Md/M0IIXftQOyEsGAiYmj2WgcvM4oO4HKpPP64d0JZe19Rg9eQ7syXB iEr7OWrn/a/I+T1657CVEV5PFCRSt1Xv/7clhinLGa9Xsk+KTb2CNH3vi39cPftJpdTI QW+w== X-Gm-Message-State: ALoCoQnD9OXJFOgFF74TNuY0i2gPkRg3pLndoQ6lSPZLGERmBtitKoKLmKwpeRuLqzAl70T1NNU3 X-Received: by 10.140.91.201 with SMTP id z67mr15182849qgd.27.1423053317924; Wed, 04 Feb 2015 04:35:17 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBAdwVbix97iZ30SISa9Da8hT21+w== Date: Wed, 4 Feb 2015 07:35:16 -0500 Message-ID: <4370d62f23eb579bb7ad1fd9d5203518@mail.gmail.com> To: draft-ietf-httpauth-digest@tools.ietf.org, http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [http-auth] draft-ietf-httpauth-digest-12: comments 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, 04 Feb 2015 12:35:20 -0000 Hi, The following are some comments concerning draft-ietf-httpauth-digest-12. Thanks, Brett ----- Section 3.4.5: The realm example is missing the mandatory quotes. Section 9.3 paragraph 1: The http://www.example.org/dir/index.html is shown with close quote without open quote. Section 9.3 first Authorization header: As mentioned within section 3.4, the URI must be within quotes. From nobody Wed Feb 4 07:12:55 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 C8AE81A8A8E for ; Wed, 4 Feb 2015 07:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 Ptc1zixdE8MC for ; Wed, 4 Feb 2015 07:12:46 -0800 (PST) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (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 866451A8A61 for ; Wed, 4 Feb 2015 07:12:22 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id j5so1567583qga.9 for ; Wed, 04 Feb 2015 07:12:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=/lLUcX0FldDfPaz+625vzhvpvDNksuRXvFHVmsA8XeI=; b=lltQB+G80ykpXn6+7EA+k1k2Q/pkBTQ1kWWXMiEBe54BiRKTXR6xsgGqE+3LBjxaqO FQWe+wtMbKlBMHCL/yCgkifej1RbYKqB/TwqEJD3/blLwTv0ESrofSqgTWvdj4tz4AKG z5FThgLlZe33yfzPyooXjMQbFepVuGWQktuHWPF7msyTMl/hNlzuaOU1z6PQUOCki3sW 9KP8J+CI6bI0VR0KNi3A2NZndJjSlW4mhCEeewO0CY+kBhBYWtAgKnXrPbkDhFSRW2px bcZ6z9SB0dntfHjqzwxZcY00a8FuVrI/OZ9ipk34/QkPDE4l4tzlBhuWm/IB3SUG7lEz 8RQg== X-Gm-Message-State: ALoCoQmcWb7S6WES1jGM42I8UFAok8oTidzTv0qZocMaMuoUyPPWc2Lhz/wJZttEsyNMSstADcXY X-Received: by 10.224.29.137 with SMTP id q9mr65240316qac.95.1423062741619; Wed, 04 Feb 2015 07:12:21 -0800 (PST) From: Brett Tate References: 4370d62f23eb579bb7ad1fd9d5203518@mail.gmail.com In-Reply-To: 4370d62f23eb579bb7ad1fd9d5203518@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBAdwVbix97iZ30SISa9Da8hT21+wAFQYUQ Date: Wed, 4 Feb 2015 10:12:20 -0500 Message-ID: <30725f7bd890c0568b8af7837512834d@mail.gmail.com> To: draft-ietf-httpauth-digest@tools.ietf.org, http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [http-auth] draft-ietf-httpauth-digest-12: comments 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, 04 Feb 2015 15:12:51 -0000 You can disregard this email since it inadvertently reflects version 12. (The draft version 13 option disappeared as being the latest when I switched to earlier draft version and switched back to latest version shown within list on the drafts tools page.) Sorry about the noise. I'll resend with version 13 comments. > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Wednesday, February 04, 2015 7:35 AM > To: 'draft-ietf-httpauth-digest@tools.ietf.org'; 'http-auth@ietf.org' > Subject: draft-ietf-httpauth-digest-12: comments > > Hi, > > The following are some comments concerning draft-ietf-httpauth-digest-12. > > Thanks, > Brett > > ----- > > Section 3.4.5: The realm example is missing the mandatory quotes. > > Section 9.3 paragraph 1: The http://www.example.org/dir/index.html is shown > with close quote without open quote. > > Section 9.3 first Authorization header: As mentioned within section 3.4, the > URI must be within quotes. From nobody Wed Feb 4 08:01: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 DEE3C1A8ACE for ; Wed, 4 Feb 2015 08:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 6HTrexxC9c0a for ; Wed, 4 Feb 2015 08:00:59 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (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 DA35E1A8AC3 for ; Wed, 4 Feb 2015 08:00:58 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id m20so1892763qcx.4 for ; Wed, 04 Feb 2015 08:00:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=4FLioeAV/jhDh09tFPnYn3+kNLyC3ChMZytg2Mn4IUY=; b=dUXurEOBCXQ5RnRxq4dmvwEtL+NuGpyQfSkTcGS8JxS9NovzSYYQM8V5g1jhDKbAnk GGt7ZzCAyw+ESSX1m09tPmjCxroGsbNEYh2KXb1dv3GlzqH0yAJnRa//b/yQURbw/XPt qRYv3RvFADcINmL+y3bZ2/E1lcKCkFIQPIAkjQt0J1ODwmpLED4tAGPSySrs3TFgTDVN ZeOGpDun72NXMO+e7Z6N5Qi9rMNM2KMjTpghx3ahTsw+w/SE3eMa16Hs1XoN59qWfu8g dpS1g2WL1bwfnN0HD0ETW3iYsOzvc8rx5aekb+5ZrzKmVcA/S9ieY0lhXZVk6SlXeipt fhVg== X-Gm-Message-State: ALoCoQnWpg7DOMVUlBRtJZnbur2JCHwaE5zlugUMaDQyqDEBQmYlrrWSInh3YIRXD7XIdgERwwJ1 X-Received: by 10.224.10.201 with SMTP id q9mr64101748qaq.48.1423065657583; Wed, 04 Feb 2015 08:00:57 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBAk7XuAFBFtrhiTN2L2oeEI8RTKw== Date: Wed, 4 Feb 2015 11:00:56 -0500 Message-ID: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> To: draft-ietf-httpauth-digest@tools.ietf.org, http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [http-auth] draft-ietf-httpauth-digest-13: comments 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, 04 Feb 2015 16:01:01 -0000 Hi, The following are some comments concerning draft-ietf-httpauth-digest-13. Thanks, Brett ----- Section 3.4 username: Does sending "username*" instead of "username" introduce a relevant backward compatibility issue with RFC 2617 devices (such as proxies)? Section 3.4.5: The realm example is missing the mandatory quotes. Section 3.9.1 paragraph 1: The http://www.example.org/dir/index.html is shown with close quote without open quote. Section 3.9.1 first Authorization header: As mentioned within section 3.4, the URI must be within quotes. Section 3.9.2 WWW-Authenticate header: As mentioned within section 3.3, the qop value must be within quotes. From nobody Wed Feb 4 10:18:31 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 785321A1A3E for ; Wed, 4 Feb 2015 10:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 CTymGVg9Aszo for ; Wed, 4 Feb 2015 10:18:21 -0800 (PST) Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF081A1AF6 for ; Wed, 4 Feb 2015 10:18:21 -0800 (PST) Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id 8ED4925A213E; Wed, 4 Feb 2015 19:18:17 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3kcrjc5Fqqz5vMr; Wed, 4 Feb 2015 19:18:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Sophie Bremer In-Reply-To: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> Date: Wed, 4 Feb 2015 19:18:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> References: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> To: Brett Tate X-Mailer: Apple Mail (2.1085) Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-digest@tools.ietf.org Subject: Re: [http-auth] draft-ietf-httpauth-digest-13: comments 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, 04 Feb 2015 18:18:27 -0000 Hi Brett, > Section 3.4 username: Does sending "username*" instead of "username" > introduce a relevant backward compatibility issue with RFC 2617 = devices > (such as proxies)? Yes, but no. A proxy sends an Authentication Response, it can serve. And = the client sends "username*" only, if the proxy indicates support of = UTF-8 username without userhash. > Section 3.9.1 first Authorization header: As mentioned within section = 3.4, > the URI must be within quotes. Please further specify, where it is mentioned. Maybe this is mistaken = with the domain parameter in the Authentication Response? > Section 3.9.2 WWW-Authenticate header: As mentioned within section = 3.3, > the qop value must be within quotes. Thanks, will be fixed. Best Regards, Sophie= From nobody Wed Feb 4 10:32:34 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 06C831A1A64 for ; Wed, 4 Feb 2015 10:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1L-0GVz17QLu for ; Wed, 4 Feb 2015 10:32:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A4CE41A00F3 for ; Wed, 4 Feb 2015 10:32:31 -0800 (PST) Received: from [192.168.2.175] ([84.187.34.103]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MUYnD-1Y9tpE1Hk3-00RLPO; Wed, 04 Feb 2015 19:31:59 +0100 Message-ID: <54D2658D.4000400@gmx.de> Date: Wed, 04 Feb 2015 19:31:41 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sophie Bremer , Brett Tate References: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> In-Reply-To: <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZQuoZQ++ioUGcoI5UauK4GVaN9fTD4GHOYLruLR8W8by6DQnAGb 1qMXPdU7LLEw/uuSnOD0OyVN3QB6WpX8aI2uW+F/zWsggEbVkrlImAxXU3x49dlaQ+BjxhE J43GIrsCKzE5PBwS5UbvvT6B3Pg4aJf0PsMFSQYRcZO2hL6pR7wSk/pkAwmdtLYwxM8Dtcb v1/1MU9DoVfa3wtQW87XQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-digest@tools.ietf.org Subject: Re: [http-auth] draft-ietf-httpauth-digest-13: comments 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, 04 Feb 2015 18:32:33 -0000 On 2015-02-04 19:18, Sophie Bremer wrote: > Hi Brett, > >> Section 3.4 username: Does sending "username*" instead of "username" >> introduce a relevant backward compatibility issue with RFC 2617 devices >> (such as proxies)? > > Yes, but no. A proxy sends an Authentication Response, it can serve. And the client sends "username*" only, if the proxy indicates support of UTF-8 username without userhash. How does it indicate that? By adding the charset parameter? It might be a good idea to make that clearer... Best regards, Julian From nobody Wed Feb 4 10:54:12 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 ABD561A0673 for ; Wed, 4 Feb 2015 10:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 Na5VWGQVNLpu for ; Wed, 4 Feb 2015 10:54:05 -0800 (PST) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (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 3B1681A1AE3 for ; Wed, 4 Feb 2015 10:54:05 -0800 (PST) Received: by mail-qg0-f46.google.com with SMTP id j5so2682934qga.5 for ; Wed, 04 Feb 2015 10:54:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=2piigTIsYUWPn3VVknYGqZQiqoaAYkmsUsMlssfC7wQ=; b=jjkrICqEWnt5cD1iYWBDbH9EPoAksAhmFbIBLnsDDPUnJQsWqm6d+TevclHhZpO33A Jm5/tktT4s+JR6C0s0TDZ/PhGA5VLLdZ3D7RnG9BM9DndanZ1mP80rlOylhNzNazKDM4 /I7yxhF/63jpRJddXTIKlBeGnVbNlIzUj7t7ZWJCalgKRn7LyZrI3gU0Gm9q4PUPcPzA RG3VJ49YqFl/71ir1kX5Tz3RNkGcBLgIHu+ZizffwgYzFO4DfXudG5Q9ws5CkMybWtR2 d3LojR9ZujtvrXA5P1DtiZDR8uOZqDUMSlLJ27zOQzlnmdx25IWyOIzucgEJiW8E7J+b BAeQ== X-Gm-Message-State: ALoCoQkqjmwYuPeP2ICaJlrzsP7+lG7elI40QbufPPOz/l0keC25TPgc6WDztK9YXAWMYRqhmdHt X-Received: by 10.140.88.48 with SMTP id s45mr63640515qgd.28.1423076038209; Wed, 04 Feb 2015 10:53:58 -0800 (PST) From: Brett Tate References: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> In-Reply-To: <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGR9/Vhp0ulF1WdmI1a2nEAUyCtUQIaP5/JnUyMmqA= Date: Wed, 4 Feb 2015 13:53:57 -0500 Message-ID: <09a78bcd31bbca139477878443a98c82@mail.gmail.com> To: draft-ietf-httpauth-digest@tools.ietf.org, http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [http-auth] draft-ietf-httpauth-digest-13: comments 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, 04 Feb 2015 18:54:10 -0000 Hi, Thanks for the response; reply is inline. > > Section 3.4 username: Does sending "username*" instead > > of "username" introduce a relevant backward compatibility > > issue with RFC 2617 devices (such as proxies)? > > Yes, but no. A proxy sends an Authentication Response, it can > serve. And the client sends "username*" only, if the proxy > indicates support of UTF-8 username without userhash. Consider client->proxy1->proxy2->server situation where all except proxy1 is draft compliant. If proxy1 parses the Authorization and/or Proxy-Authorization header, it may consider the header to be malformed. > > Section 3.9.1 first Authorization header: As mentioned > > within section 3.4, the URI must be within quotes. > > Please further specify, where it is mentioned. Maybe this > is mistaken with the domain parameter in the Authentication > Response? If you were asking about section 3.4 reference... "For historical reasons, a sender MUST only generate the quoted-string syntax for the following parameters: username, realm, nonce, uri, response, cnonce, and opaque." If were asking about RFC 2617 reference to make above true, see RFC 2617 errata 2600. If you were asking about Authorization header's URI reference missing quoted value, the uri=/dir/index.html should be uri="/dir/index.html". From nobody Wed Feb 4 11:35: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 4115D1A1BC5 for ; Wed, 4 Feb 2015 11:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 wtI6O9dfQJat for ; Wed, 4 Feb 2015 11:35:07 -0800 (PST) Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494091A1B4F for ; Wed, 4 Feb 2015 11:35:06 -0800 (PST) Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id 09FB825A3DD4; Wed, 4 Feb 2015 20:35:04 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3kctQJ2ksmz5vMr; Wed, 4 Feb 2015 20:35:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Sophie Bremer In-Reply-To: <09a78bcd31bbca139477878443a98c82@mail.gmail.com> Date: Wed, 4 Feb 2015 20:35:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> <09a78bcd31bbca139477878443a98c82@mail.gmail.com> To: Brett Tate X-Mailer: Apple Mail (2.1085) Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] draft-ietf-httpauth-digest-13: comments 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, 04 Feb 2015 19:35:09 -0000 >>> Section 3.4 username: Does sending "username*" instead >>> of "username" introduce a relevant backward compatibility >>> issue with RFC 2617 devices (such as proxies)? >>=20 >> Yes, but no. A proxy sends an Authentication Response, it can >> serve. And the client sends "username*" only, if the proxy >> indicates support of UTF-8 username without userhash. >=20 > Consider client->proxy1->proxy2->server situation where all except = proxy1 > is draft compliant. If proxy1 parses the Authorization and/or > Proxy-Authorization header, it may consider the header to be = malformed. Which nodes add Authentication options in the header? If proxy1 does not = add an Authentication option, why does it parses Authorization headers? >>> Section 3.9.1 first Authorization header: As mentioned >>> within section 3.4, the URI must be within quotes. >>=20 >> Please further specify, where it is mentioned. Maybe this >> is mistaken with the domain parameter in the Authentication >> Response? >=20 > If you were asking about section 3.4 reference... >=20 > "For historical reasons, a sender MUST only generate the quoted-string > syntax for the following parameters: username, realm, nonce, uri, > response, cnonce, and opaque." >=20 > If were asking about RFC 2617 reference to make above true, see RFC = 2617 > errata 2600. >=20 > If you were asking about Authorization header's URI reference missing > quoted value, the uri=3D/dir/index.html should be = uri=3D"/dir/index.html". Thank you, got it.= From nobody Wed Feb 4 12:11:16 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 2BE871A1B72 for ; Wed, 4 Feb 2015 12:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 dvyyd4iYZ36X for ; Wed, 4 Feb 2015 12:11:12 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (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 AA3451A1B4F for ; Wed, 4 Feb 2015 12:11:12 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id p6so3214217qcv.1 for ; Wed, 04 Feb 2015 12:11:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=iSSM4kWqATAjEb4idDA6o3ZJxQwj3mhMnaj0mf3bRFA=; b=DcN+gBZrBDySjrTAjoLHdV5Dt71CWmWGB0+qlOnqZqGUmgQfXzo0w4SrrE4vUvM/86 th6wuNa8u6bhwWy/Sp3GAO2vvAaxdEs0M4RPCeOb3AoiMwJA4uONWCyZHueNhmmFd101 ZAY1uLTHcYfU81ygLc737RU7UbUEHaFyeB6mQUZBSnsD93yRJO+bpkXbnnaYLcTx1dfO bhCKpCmF3Br01bxGLR/IToc2wJ+SCzygW8pL76KE3tExGll9DFSn1kNewzGNK7Pf+uy1 ya3bMxM/CVvF4BinbOJq8XWIlAh6+6HF7ymEfWD9q9Oc8GCX1wuBd38rjAvliEoReYtS Sefw== X-Gm-Message-State: ALoCoQk+CKdiYm7V4TJcRVJygWo49KUlCPVYwh3qzzeY6PXkh2C5Jwp4wiBxLVNN+G07/mKcnqcz X-Received: by 10.140.106.100 with SMTP id d91mr278567qgf.18.1423080671941; Wed, 04 Feb 2015 12:11:11 -0800 (PST) From: Brett Tate References: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> <09a78bcd31bbca139477878443a98c82@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGR9/Vhp0ulF1WdmI1a2nEAUyCtUQIaP5/JAUO7zuYBTGLbsZ04Hzfw Date: Wed, 4 Feb 2015 15:11:11 -0500 Message-ID: <8014f6257d63d6be9a18f259a435ba7f@mail.gmail.com> To: Sophie Bremer , http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [http-auth] draft-ietf-httpauth-digest-13: comments 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, 04 Feb 2015 20:11:14 -0000 Hi, Thanks for the response; reply is inline. > >>> Section 3.4 username: Does sending "username*" instead > >>> of "username" introduce a relevant backward compatibility > >>> issue with RFC 2617 devices (such as proxies)? > >> > >> Yes, but no. A proxy sends an Authentication Response, it > >> can serve. And the client sends "username*" only, if the > >> proxy indicates support of UTF-8 username without userhash. > > > > Consider client->proxy1->proxy2->server situation where all > > except proxy1 is draft compliant. If proxy1 parses the > > Authorization and/or Proxy-Authorization header, it may > > consider the header to be malformed. > > Which nodes add Authentication options in the header? Proxy-Authenticate was added by proxy1 and proxy2; WWW-Authenticate was added by the server. > If proxy1 does not add an Authentication option, why does it > parses Authorization headers? It would parse Proxy-Authorization headers. It may or may not attempt to parse Authorization header. I'm not familiar enough with the http RFCs to know if there is a recommendation concerning if a malformed header should cause 1) rejecting request, 2) removing header, 3) removing malformed portion of the header, or 4) relaying header. From nobody Thu Feb 5 06:46:35 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 698591A8866; Thu, 5 Feb 2015 06:46:33 -0800 (PST) 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 IIJ_8CkMvQYB; Thu, 5 Feb 2015 06:46:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 833E61A884B; Thu, 5 Feb 2015 06:46:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-basicauth-update.all@ietf.org, http-auth@ietf.org, httpauth-chairs@ietf.org, ynir.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205144632.3949.21630.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 06:46:32 -0800 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: Thu, 05 Feb 2015 14:46:33 -0000 IESG state changed to Last Call Requested from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Thu Feb 5 06:46:36 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 988491A8867; Thu, 5 Feb 2015 06:46:33 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698591A8866; Thu, 5 Feb 2015 06:46:33 -0800 (PST) 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 IIJ_8CkMvQYB; Thu, 5 Feb 2015 06:46:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 833E61A884B; Thu, 5 Feb 2015 06:46:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-basicauth-update.all@ietf.org, http-auth@ietf.org, httpauth-chairs@ietf.org, ynir.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205144632.3949.21630.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 06:46:32 -0800 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: Thu, 05 Feb 2015 14:46:33 -0000 IESG state changed to Last Call Requested from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Thu Feb 5 06:52:49 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 6718E1A889C for ; Thu, 5 Feb 2015 06:52:47 -0800 (PST) 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 DczmZeoEhE0v for ; Thu, 5 Feb 2015 06:52:46 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 C42891A885C for ; Thu, 5 Feb 2015 06:52:38 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id p9so7987255lbv.4 for ; Thu, 05 Feb 2015 06:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=95weZNhg2KDn6T/e3auBs/I0MV5SYDx7yvzWep0bNrE=; b=H6vrgu/rlIn9TjMD7gijUj2PIESDazAqBp6oHqucdgJ0rd6XmymeivOtxP37NhSNaD i4O2tlUlee+P32yarywxIsymbK6bW42xNYGKjbJo+4egDvoXqJMItbzWTvwxR6GslUFC JqkXX8qjG/PCGYROYI21moi858mv62rUYXffZMHhDK3CD45FiLfBrKMENkuyrC2nhAEA 5gr3JYzd4cv40jCpbD3+4xHUlMZgFO1Y+cQG1ZzwrD1ZqEg7YoFRXh8lILs6O6xJYhKO JQGYlqR0YzB2I+w+mQ1K/VYULRExZ3PUx9JanDyvra8d4XabWABiT/25vLdC9ZwsHtOO vxhQ== MIME-Version: 1.0 X-Received: by 10.152.42.133 with SMTP id o5mr440467lal.113.1423147957300; Thu, 05 Feb 2015 06:52:37 -0800 (PST) Received: by 10.112.167.134 with HTTP; Thu, 5 Feb 2015 06:52:37 -0800 (PST) Date: Thu, 5 Feb 2015 09:52:37 -0500 Message-ID: From: Kathleen Moriarty To: "http-auth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [http-auth] draft-ietf-httpauth-basicauth-update 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, 05 Feb 2015 14:52:47 -0000 Hello, I reviewed and requested that IETF Last Call is initiated on draft-ietf-httpauth-basicauth-update. Thanks to all for your work writing and reviewing this draft! I have no additional comments from my previous review, except that I appreciate the work that went into this draft and the detailed security considerations section. Would anyone object to me putting this draft on the telechat in 2 weeks? This might mean that any comments received in last call get addressed in an update after the IESG review. The document looks pretty solid to me, so I don't think this would be an issue. I can put this on the next telechat, 2 weeks from today and wait to issue the ballot until next Friday. If there are a lot of comments to address, I can bump out the draft to the following telechat. The advantage of getting this on the next one is that there will be two more before the Dallas IETF and it is usually best to avoid the last one as it is typically overloaded with drafts (meaning - good to avoid). Thanks. -- Best regards, Kathleen From nobody Thu Feb 5 07:06: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 D1DF91A88B1 for ; Thu, 5 Feb 2015 07:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iqZQyrn0wPBl for ; Thu, 5 Feb 2015 07:06:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 D28D11A8861 for ; Thu, 5 Feb 2015 07:06:27 -0800 (PST) Received: from [192.168.2.175] ([84.187.34.103]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MQ6oB-1YEB4k1Ryd-005J6E; Thu, 05 Feb 2015 16:06:25 +0100 Message-ID: <54D386E2.7050502@gmx.de> Date: Thu, 05 Feb 2015 16:06:10 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty , "http-auth@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jrtg92DZ9hdKjCIyyZ0IkhUG61Ypr8XpTuokLjL9XE/8FM3W1Rm 3zAOKGj6McktWzguJks7QPaMubqZtHLLZGSSga70kvAuNei/rIgmg3ZkAMZDcXWVfq8wDJt wn5jDAYbPvzScXnuKcoP9Bg40HNtuBE9cCFlwx4M7i8NwxsFwml6Vuc/X7UBpKrKPGRtQZn H/3R/lzr1gCxkY6pxOTsw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [http-auth] draft-ietf-httpauth-basicauth-update 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, 05 Feb 2015 15:06:37 -0000 On 2015-02-05 15:52, Kathleen Moriarty wrote: > Hello, > > I reviewed and requested that IETF Last Call is initiated on > draft-ietf-httpauth-basicauth-update. Thanks to all for your work > writing and reviewing this draft! I have no additional comments from > my previous review, except that I appreciate the work that went into > this draft and the detailed security considerations section. > > Would anyone object to me putting this draft on the telechat in 2 > weeks? This might mean that any comments received in last call get > addressed in an update after the IESG review. The document looks > pretty solid to me, so I don't think this would be an issue. > > I can put this on the next telechat, 2 weeks from today and wait to > issue the ballot until next Friday. If there are a lot of comments to > address, I can bump out the draft to the following telechat. The > advantage of getting this on the next one is that there will be two > more before the Dallas IETF and it is usually best to avoid the last > one as it is typically overloaded with drafts (meaning - good to > avoid). > > Thanks. Sounds good to me! Best regards, Julian From nobody Thu Feb 5 07:07: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 6B4181A8861 for ; Thu, 5 Feb 2015 07:07:12 -0800 (PST) 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 qiYSzV0a77c3 for ; Thu, 5 Feb 2015 07:07:10 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 3302D1A88C2 for ; Thu, 5 Feb 2015 07:07:10 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id n3so11148166wiv.3 for ; Thu, 05 Feb 2015 07:07:08 -0800 (PST) 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=v17+hr5k/isQR47P7wi4IlxvnmmrZeYMjP/UpzSC6mo=; b=yxFyQL7pJmT8s4VG45jIQCorn0RDeIyUSFOcrKX7MMDBab/xNlpVwq+nIh6yjalD+6 mParEyFfJrcmkP8xjHrErYa4H1fiFfT4AX7GjQAgW49Z0S99tFL9caAo6Eulw5llMXhK Lh8w83Ffdkw/bVhFKaaJWwHtEcXT3hm6ngAMjXI6Du35XBqkbmGQfG9zhaEyLPfXCG+K lPaMBjoz6N/Js0Gtwi40pOGrcShPqMD9hGJ3TyaFXM5V9WeXuiv2JEW9189zHhCBCUhL nIH8mH7Ir7OINtbowfF1OBYY8p9gPQBwM81QIyFizBTlHjX1rOYfRC7aEWYMONfkfpnV cknA== X-Received: by 10.194.58.141 with SMTP id r13mr8312924wjq.144.1423148828870; Thu, 05 Feb 2015 07:07:08 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id g8sm8279694wiy.6.2015.02.05.07.07.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 07:07:08 -0800 (PST) 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: Date: Thu, 5 Feb 2015 17:07:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-basicauth-update 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, 05 Feb 2015 15:07:12 -0000 Speaking on behalf of nobody but myself, I=E2=80=99m fine with it being = on the telechat on the 19th. Yoav > On Feb 5, 2015, at 4:52 PM, Kathleen Moriarty = wrote: >=20 > Hello, >=20 > I reviewed and requested that IETF Last Call is initiated on > draft-ietf-httpauth-basicauth-update. Thanks to all for your work > writing and reviewing this draft! I have no additional comments from > my previous review, except that I appreciate the work that went into > this draft and the detailed security considerations section. >=20 > Would anyone object to me putting this draft on the telechat in 2 > weeks? This might mean that any comments received in last call get > addressed in an update after the IESG review. The document looks > pretty solid to me, so I don't think this would be an issue. >=20 > I can put this on the next telechat, 2 weeks from today and wait to > issue the ballot until next Friday. If there are a lot of comments to > address, I can bump out the draft to the following telechat. The > advantage of getting this on the next one is that there will be two > more before the Dallas IETF and it is usually best to avoid the last > one as it is typically overloaded with drafts (meaning - good to > avoid). >=20 > Thanks. >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Thu Feb 5 07:09:25 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 4177D1A88B1 for ; Thu, 5 Feb 2015 07:09:21 -0800 (PST) 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 nrQRqrN29PfH for ; Thu, 5 Feb 2015 07:09:19 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 0B2001A88D3 for ; Thu, 5 Feb 2015 07:09:19 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id b6so8132883lbj.11 for ; Thu, 05 Feb 2015 07:09:17 -0800 (PST) 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:content-transfer-encoding; bh=8g8Ko22pmC/77bADIN2B8o6wc+FGwCSjaC3JcaCMDlU=; b=I+59gjzwbTNE4vGKydb5wGtcvEUDpElmhfQod2AWp4kyB3HknaSbm1mI45vQwhh0zd DHOc6qA2doKuS18w6fnKAaqSRacF1WiPyXGGuwtYYBXgOo+toAKvlCrshiG1Z9Y36zg9 KqTjcVXLXzqkMA4p3cs0Q/ZHcxoCEpiU2pHpplPwshADVU5RADto0qqReKKQC6QFutge BzrXuPAZ/3KdfQcElXRr5oKJSLkRG1NbHj90dGd42d2yOWOWyQ+14IOqqLtYXmbwT+iL mdg3ZsuvheErLl3GFYx3nfycjlKqCX0od9ACB5y9xZo3WxK6PfFC3GpcXb+95518+4vr 2zRg== MIME-Version: 1.0 X-Received: by 10.112.98.99 with SMTP id eh3mr4049966lbb.32.1423148957540; Thu, 05 Feb 2015 07:09:17 -0800 (PST) Received: by 10.112.167.134 with HTTP; Thu, 5 Feb 2015 07:09:17 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2015 10:09:17 -0500 Message-ID: From: Kathleen Moriarty To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-basicauth-update 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, 05 Feb 2015 15:09:21 -0000 Great, having the editor and shepherd on board with this plan is essential, thank you both. On Thu, Feb 5, 2015 at 10:07 AM, Yoav Nir wrote: > Speaking on behalf of nobody but myself, I=E2=80=99m fine with it being o= n the telechat on the 19th. > > Yoav > >> On Feb 5, 2015, at 4:52 PM, Kathleen Moriarty wrote: >> >> Hello, >> >> I reviewed and requested that IETF Last Call is initiated on >> draft-ietf-httpauth-basicauth-update. Thanks to all for your work >> writing and reviewing this draft! I have no additional comments from >> my previous review, except that I appreciate the work that went into >> this draft and the detailed security considerations section. >> >> Would anyone object to me putting this draft on the telechat in 2 >> weeks? This might mean that any comments received in last call get >> addressed in an update after the IESG review. The document looks >> pretty solid to me, so I don't think this would be an issue. >> >> I can put this on the next telechat, 2 weeks from today and wait to >> issue the ballot until next Friday. If there are a lot of comments to >> address, I can bump out the draft to the following telechat. The >> advantage of getting this on the next one is that there will be two >> more before the Dallas IETF and it is usually best to avoid the last >> one as it is typically overloaded with drafts (meaning - good to >> avoid). >> >> Thanks. >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > --=20 Best regards, Kathleen From nobody Thu Feb 5 08:05:04 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 280821A01D8 for ; Thu, 5 Feb 2015 08:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 3wddoYERLzgX for ; Thu, 5 Feb 2015 08:04:57 -0800 (PST) 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 29FD81A8761 for ; Thu, 5 Feb 2015 08:04:57 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id x69so7151876oia.10 for ; Thu, 05 Feb 2015 08:04:56 -0800 (PST) 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=Tk3QLH7dXN+C8CdBO3MB+5q9jaN+xtoVIHu+ueiVK4s=; b=TnkHw+tEJDI0OauiC7CEbiV93jcKwKVwnA/KNUdVJhbUC628na7Fmy2ZD8Zie2xefi I5JQCuNLMEL1ZjTFWU3/n6PEAjH6VAw9jvnSTebJInF3UxGVqrle+mYxf/5SlY2uAhvb 0wrSr4AdR8ma5MzBjWIpJ96EstIKuoCh/rv3EVUolpo3g9gBn9ut3sbbzX/C4U3CtKGZ DLq58HcuD/7LfA3i0qBxNNwyXBPa4vAmVCfehTcYBWVkvRZlQQQiKhdXfanOo4MKC4lT HhV8VvCY2G3Nn/2y9fwMQL7PGXFYDeobRB2Ps4kHonTIHwEIfo/o38ei8Pzq3cq6hN0W 8lXA== MIME-Version: 1.0 X-Received: by 10.60.155.195 with SMTP id vy3mr2882711oeb.62.1423152296475; Thu, 05 Feb 2015 08:04:56 -0800 (PST) Received: by 10.202.135.17 with HTTP; Thu, 5 Feb 2015 08:04:56 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2015 11:04:56 -0500 Message-ID: From: Matthew Lepinski To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=089e0102dc3217c1d3050e597727 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-basicauth-update 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, 05 Feb 2015 16:05:03 -0000 --089e0102dc3217c1d3050e597727 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The plan sounds good. Please feel free to pull the trigger. - Matt Lepinski On Thu, Feb 5, 2015 at 10:09 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Great, having the editor and shepherd on board with this plan is > essential, thank you both. > > On Thu, Feb 5, 2015 at 10:07 AM, Yoav Nir wrote: > > Speaking on behalf of nobody but myself, I=E2=80=99m fine with it being= on the > telechat on the 19th. > > > > Yoav > > > >> On Feb 5, 2015, at 4:52 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> > >> Hello, > >> > >> I reviewed and requested that IETF Last Call is initiated on > >> draft-ietf-httpauth-basicauth-update. Thanks to all for your work > >> writing and reviewing this draft! I have no additional comments from > >> my previous review, except that I appreciate the work that went into > >> this draft and the detailed security considerations section. > >> > >> Would anyone object to me putting this draft on the telechat in 2 > >> weeks? This might mean that any comments received in last call get > >> addressed in an update after the IESG review. The document looks > >> pretty solid to me, so I don't think this would be an issue. > >> > >> I can put this on the next telechat, 2 weeks from today and wait to > >> issue the ballot until next Friday. If there are a lot of comments to > >> address, I can bump out the draft to the following telechat. The > >> advantage of getting this on the next one is that there will be two > >> more before the Dallas IETF and it is usually best to avoid the last > >> one as it is typically overloaded with drafts (meaning - good to > >> avoid). > >> > >> Thanks. > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > >> > >> _______________________________________________ > >> http-auth mailing list > >> http-auth@ietf.org > >> https://www.ietf.org/mailman/listinfo/http-auth > > > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e0102dc3217c1d3050e597727 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The plan sounds good. Please feel free to pull the trigger= .

- Matt Lepinski
=
On Thu, Feb 5, 2015 at 10:09 AM, Kathleen Mo= riarty <kathleen.moriarty.ietf@gmail.com> wro= te:
Great, having the editor and shepherd= on board with this plan is
essential, thank you both.

On Thu, Feb 5, 2015 at 10:07 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> Speaking on behalf of nobody but myself, I=E2=80=99m fine with it bein= g on the telechat on the 19th.
>
> Yoav
>
>> On Feb 5, 2015, at 4:52 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>= ; wrote:
>>
>> Hello,
>>
>> I reviewed and requested that IETF Last Call is initiated on
>> draft-ietf-httpauth-basicauth-update.=C2=A0 Thanks to all for your= work
>> writing and reviewing this draft!=C2=A0 I have no additional comme= nts from
>> my previous review, except that I appreciate the work that went in= to
>> this draft and the detailed security considerations section.
>>
>> Would anyone object to me putting this draft on the telechat in 2<= br> >> weeks?=C2=A0 This might mean that any comments received in last ca= ll get
>> addressed in an update after the IESG review.=C2=A0 The document l= ooks
>> pretty solid to me, so I don't think this would be an issue. >>
>> I can put this on the next telechat, 2 weeks from today and wait t= o
>> issue the ballot until next Friday.=C2=A0 If there are a lot of co= mments to
>> address, I can bump out the draft to the following telechat.=C2=A0= The
>> advantage of getting this on the next one is that there will be tw= o
>> more before the Dallas IETF and it is usually best to avoid the la= st
>> one as it is typically overloaded with drafts (meaning - good to >> avoid).
>>
>> Thanks.
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> http-auth mailing list
>> http-auth@ietf.org
>> https://www.ietf.org/mailman/listinfo/http-auth
>



--

Best regards,
Kathleen

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

--089e0102dc3217c1d3050e597727-- From nobody Thu Feb 5 08:07:07 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 1A8431A884C for ; Thu, 5 Feb 2015 08:07:05 -0800 (PST) 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 f9jx4rH9-8C4 for ; Thu, 5 Feb 2015 08:07:03 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 3FAA41A87A9 for ; Thu, 5 Feb 2015 08:07:00 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id b6so8767282lbj.11 for ; Thu, 05 Feb 2015 08:06:58 -0800 (PST) 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:content-transfer-encoding; bh=Alb7ZwukyDLyzaUGT8UXFRGCzgKa3MnAwNPxDfQcAFc=; b=n/ACyoC5iSArtV7SbspE/YprbD9cbZW0+3S3hF6xAu1GZrfTPuDBvgO9TstgVALD5+ 6xsz0utmOSkXJ58XZlzYRjjUTLakZMY2yQ3bkvQEJ509FN1B4HY6TKDagNyBKbLYB80p WoMEPki56vo6/v8+iml5P59VDGG2Fa/V8XLiO8Udan2+Q9qeo78Ptki0m4kYyp+9My0j eP9kqEC81yZuR3vFSSVMrrNXUtOhLNCtdTlx7cXp59m273x5pKczKeoRFQI7jKgjxz8H mdOXgxeUYR/ej/p6sK9vJzbZs3Wtyq3gw5bnoiqyVvC4cxxf1ST3/LBVhZr4BbCf9nQi sqnQ== MIME-Version: 1.0 X-Received: by 10.152.42.133 with SMTP id o5mr971840lal.113.1423152418744; Thu, 05 Feb 2015 08:06:58 -0800 (PST) Received: by 10.112.167.134 with HTTP; Thu, 5 Feb 2015 08:06:58 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2015 11:06:58 -0500 Message-ID: From: Kathleen Moriarty To: Matthew Lepinski Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-basicauth-update 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, 05 Feb 2015 16:07:05 -0000 Thank you, all. Kathleen On Thu, Feb 5, 2015 at 11:04 AM, Matthew Lepinski wrote: > The plan sounds good. Please feel free to pull the trigger. > > - Matt Lepinski > > On Thu, Feb 5, 2015 at 10:09 AM, Kathleen Moriarty > wrote: >> >> Great, having the editor and shepherd on board with this plan is >> essential, thank you both. >> >> On Thu, Feb 5, 2015 at 10:07 AM, Yoav Nir wrote: >> > Speaking on behalf of nobody but myself, I=E2=80=99m fine with it bein= g on the >> > telechat on the 19th. >> > >> > Yoav >> > >> >> On Feb 5, 2015, at 4:52 PM, Kathleen Moriarty >> >> wrote: >> >> >> >> Hello, >> >> >> >> I reviewed and requested that IETF Last Call is initiated on >> >> draft-ietf-httpauth-basicauth-update. Thanks to all for your work >> >> writing and reviewing this draft! I have no additional comments from >> >> my previous review, except that I appreciate the work that went into >> >> this draft and the detailed security considerations section. >> >> >> >> Would anyone object to me putting this draft on the telechat in 2 >> >> weeks? This might mean that any comments received in last call get >> >> addressed in an update after the IESG review. The document looks >> >> pretty solid to me, so I don't think this would be an issue. >> >> >> >> I can put this on the next telechat, 2 weeks from today and wait to >> >> issue the ballot until next Friday. If there are a lot of comments t= o >> >> address, I can bump out the draft to the following telechat. The >> >> advantage of getting this on the next one is that there will be two >> >> more before the Dallas IETF and it is usually best to avoid the last >> >> one as it is typically overloaded with drafts (meaning - good to >> >> avoid). >> >> >> >> Thanks. >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> >> >> >> _______________________________________________ >> >> http-auth mailing list >> >> http-auth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/http-auth >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > --=20 Best regards, Kathleen From nobody Thu Feb 5 08:07:27 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 88D9B1A8934; Thu, 5 Feb 2015 08:07:24 -0800 (PST) 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 GnS_nGMQNUlX; Thu, 5 Feb 2015 08:07:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA871A88A4; Thu, 5 Feb 2015 08:07:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: http-auth@ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, ynir.ietf@gmail.com, httpauth-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205160723.8270.67081.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 08:07:23 -0800 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, 05 Feb 2015 16:07:24 -0000 Placed on agenda for telechat - 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Thu Feb 5 08:07:32 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B23991A893E; Thu, 5 Feb 2015 08:07:24 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D9B1A8934; Thu, 5 Feb 2015 08:07:24 -0800 (PST) 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 GnS_nGMQNUlX; Thu, 5 Feb 2015 08:07:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA871A88A4; Thu, 5 Feb 2015 08:07:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: http-auth@ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, ynir.ietf@gmail.com, httpauth-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205160723.8270.67081.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 08:07:23 -0800 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, 05 Feb 2015 16:07:25 -0000 Placed on agenda for telechat - 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Thu Feb 5 08:11: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 E39281A8934; Thu, 5 Feb 2015 08:10:55 -0800 (PST) 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 nvJKsegriA_n; Thu, 5 Feb 2015 08:10:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD441A88E3; Thu, 5 Feb 2015 08:10:49 -0800 (PST) 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: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 08:10:49 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) to Proposed Standard X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:10:56 -0000 The IESG has received a request from the Hypertext Transfer Protocol Authentication WG (httpauth) to consider the following document: - 'The 'Basic' HTTP Authentication Scheme' 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-02-19. 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 This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme, which transmits credentials as userid/password pairs, obfuscated by the use of Base64 encoding. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Feb 5 08:11:12 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 1995F1A89B9; Thu, 5 Feb 2015 08:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diXyEYH6rXU9; Thu, 5 Feb 2015 08:11:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A0F1A89A7; Thu, 5 Feb 2015 08:10:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-basicauth-update.all@ietf.org, http-auth@ietf.org, httpauth-chairs@ietf.org, ynir.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205161050.4222.87057.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 08:10:50 -0800 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: Thu, 05 Feb 2015 16:11:10 -0000 Last call has been made for draft-ietf-httpauth-basicauth-update and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Thu Feb 5 08:11:14 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6E1EE1A89C4; Thu, 5 Feb 2015 08:11:10 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1995F1A89B9; Thu, 5 Feb 2015 08:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diXyEYH6rXU9; Thu, 5 Feb 2015 08:11:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A0F1A89A7; Thu, 5 Feb 2015 08:10:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-basicauth-update.all@ietf.org, http-auth@ietf.org, httpauth-chairs@ietf.org, ynir.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205161050.4222.87057.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 08:10:50 -0800 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: Thu, 05 Feb 2015 16:11:10 -0000 Last call has been made for draft-ietf-httpauth-basicauth-update and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Thu Feb 5 10:31:52 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 8F9E51A1B25 for ; Thu, 5 Feb 2015 10:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 lZbMfrzVexfq for ; Thu, 5 Feb 2015 10:31:47 -0800 (PST) Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4C71A1A7D for ; Thu, 5 Feb 2015 10:31:46 -0800 (PST) Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id 78F1725B17C9; Thu, 5 Feb 2015 19:31:44 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3kdSyl6KnNz5vMp; Thu, 5 Feb 2015 19:31:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Sophie Bremer In-Reply-To: <8014f6257d63d6be9a18f259a435ba7f@mail.gmail.com> Date: Thu, 5 Feb 2015 19:32:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44BBFF8D-1BFE-48BE-ADFC-87A82A69BB94@netzkonform.de> References: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> <09a78bcd31bbca139477878443a98c82@mail.gmail.com> <8014f6257d63d6be9a18f259a435ba7f@mail.gmail.com> To: Brett Tate X-Mailer: Apple Mail (2.1085) Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] draft-ietf-httpauth-digest-13: comments 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, 05 Feb 2015 18:31:49 -0000 >>>>> Section 3.4 username: Does sending "username*" instead >>>>> of "username" introduce a relevant backward compatibility >>>>> issue with RFC 2617 devices (such as proxies)? >>>>=20 >>>> Yes, but no. A proxy sends an Authentication Response, it >>>> can serve. And the client sends "username*" only, if the >>>> proxy indicates support of UTF-8 username without userhash. >>>=20 >>> Consider client->proxy1->proxy2->server situation where all >>> except proxy1 is draft compliant. If proxy1 parses the >>> Authorization and/or Proxy-Authorization header, it may >>> consider the header to be malformed. >>=20 >> Which nodes add Authentication options in the header? >=20 > Proxy-Authenticate was added by proxy1 and proxy2; WWW-Authenticate = was > added by the server. Thanks, now it is clear. >> If proxy1 does not add an Authentication option, why does it >> parses Authorization headers? >=20 > It would parse Proxy-Authorization headers. It may or may not attempt = to > parse Authorization header. >=20 > I'm not familiar enough with the http RFCs to know if there is a > recommendation concerning if a malformed header should cause 1) = rejecting > request, 2) removing header, 3) removing malformed portion of the = header, > or 4) relaying header. The draft describes in "3.7. Security Protocol Negotiation" the hash = negotiation of the server with the help of multiple WWW-Authenticate = header options. Your case is in some way the opposite. A client sends multiple = Proxy-Authorization header options and involved proxies have to pick the = right one. In your example the first proxy has to expect picking up the wrong = Proxy-Authorization option, so for me it is likely that proxy1 ignores = the "malformed" ones. Nevertheless it is possible, that the proxy rejects the request as a = security feature. I agree that this is something the draft has to deal = with. How should this be covered? In "3.8. Proxy-Authenticate and = Proxy-Authorization" it could be mentioned as a side note at the end, = but is this enough? What do you think? Best Regards, Sophie= From nobody Thu Feb 5 10:42: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 01BA41A1BC7 for ; Thu, 5 Feb 2015 10:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 o_cbrACC--N7 for ; Thu, 5 Feb 2015 10:41:58 -0800 (PST) Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC8B1A1A95 for ; Thu, 5 Feb 2015 10:41:58 -0800 (PST) Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id 2C71A25B17C8; Thu, 5 Feb 2015 19:41:56 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3kdTBW174Zz5vN5; Thu, 5 Feb 2015 19:41:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Sophie Bremer In-Reply-To: <54D2658D.4000400@gmx.de> Date: Thu, 5 Feb 2015 19:42:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FDCEDF4-42E5-47EF-995F-04908E927E5B@netzkonform.de> References: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> <54D2658D.4000400@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1085) Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-digest@tools.ietf.org Subject: Re: [http-auth] draft-ietf-httpauth-digest-13: comments 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, 05 Feb 2015 18:42:01 -0000 Hi Julian, On 2015-02-04 19:31, Julian Reschke wrote: > On 2015-02-04 19:18, Sophie Bremer wrote: >> Hi Brett, >>=20 >>> Section 3.4 username: Does sending "username*" instead of "username" >>> introduce a relevant backward compatibility issue with RFC 2617 = devices >>> (such as proxies)? >>=20 >> Yes, but no. A proxy sends an Authentication Response, it can serve. = And the client sends "username*" only, if the proxy indicates support of = UTF-8 username without userhash. >=20 > How does it indicate that? By adding the charset parameter? It might = be a good idea to make that clearer... 3.4. says username The user's name in the specified realm. If the username contains characters not allowed inside the ABNF token or quoted-string forms, it can be sent in a "username*" parameter instead, using the encoding defined in [RFC5987]. Sending both "username" and "username*" MUST be treated as error. Is this not clear? How about: username The user's name in the specified realm. If the charset parameter is set and userhash is not possible, the username MAY contain characters not allowed inside the ABNF token or quoted-string. In this case it can be sent as "username*" parameter instead, = using the encoding defined in [RFC5987]. Sending both "username" and "username*" MUST be treated as error. Best Regards, Sophie= From nobody Thu Feb 5 11:07:21 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 53DA91A6F7A for ; Thu, 5 Feb 2015 11:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 8bPsYHUrXHJ6 for ; Thu, 5 Feb 2015 11:07:18 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (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 261F51A1A95 for ; Thu, 5 Feb 2015 11:07:18 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id w7so7956419qcr.10 for ; Thu, 05 Feb 2015 11:07:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=a4bAKP6JRHjl2vQyqkpfCK53/kxPHPSzB5A/01YLeb4=; b=FXY9avs2qbstEqmNkR689a17Uk2GDjdOo/BTL2sNTLsnOKVuiDE2+AsHZJ6zpNeMva i3aUi8+vtsRI59SqWccR5uZ0wwIysiTQZLXppbzTaHlJkkVv4sVPD3RxOXbK5X/0WC4Y ETfx/nGl0SQoISMvw2W3PX7wL+Nyr2kS4ipuyGXUh5RAWIxPzCY+JDX09TpI8j7J9jUT adJryQbjlecnfBW0pESmtES5RM4ZSswAZ3jWSVBrDHxch27QiiCQUQ5EfaiB2yH3jrDt FzPCvhXa8VBseYmiqZQaubXEEt0aRKhP+qWr278oXlaalriKIDDSh/aTEyZitGC9RkRT FtLg== X-Gm-Message-State: ALoCoQlfFkL10lQDib/1lCnr8ABNwTa9yxS3/uFgmCKqe5UXHjmCSuFQSiBFBYh0eR2ejjqNtS0c X-Received: by 10.140.21.48 with SMTP id 45mr10563775qgk.87.1423163237406; Thu, 05 Feb 2015 11:07:17 -0800 (PST) From: Brett Tate References: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> <09a78bcd31bbca139477878443a98c82@mail.gmail.com> <8014f6257d63d6be9a18f259a435ba7f@mail.gmail.com> <44BBFF8D-1BFE-48BE-ADFC-87A82A69BB94@netzkonform.de> In-Reply-To: <44BBFF8D-1BFE-48BE-ADFC-87A82A69BB94@netzkonform.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 thread-index: AQGR9/Vhp0ulF1WdmI1a2nEAUyCtUQIaP5/JAUO7zuYBTGLbsQDS2lxOAYq682ydJraggA== Date: Thu, 5 Feb 2015 14:08:07 -0500 Message-ID: To: Sophie Bremer , http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [http-auth] draft-ietf-httpauth-digest-13: comments 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, 05 Feb 2015 19:07:19 -0000 > How should this be covered? In "3.8. Proxy-Authenticate > and Proxy-Authorization" it could be mentioned as a side > note at the end, but is this enough? What do you think? A potential option would be to modify section 3.4 username paragraph to allow both "username" and "username*". If both are present, the "username*" is used. The "username" parameter is present for historical reasons and would be ignored by draft compliant devices. I guess based upon the realm (maybe something else), the client assumes acceptable to send/use "username*". Since the draft doesn't really discuss "third party authentication service", I'll assume that there is no related issue. From nobody Thu Feb 5 14:49:21 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 4EA5B1A8757; Thu, 5 Feb 2015 14:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 16lqfWSJfhLa; Thu, 5 Feb 2015 14:49:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 4DEB11A710C; Thu, 5 Feb 2015 14:49:06 -0800 (PST) Received: from netb ([89.204.135.27]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LnkiR-1XiEfB2DhH-00hvmF; Thu, 05 Feb 2015 23:49:04 +0100 From: Bjoern Hoehrmann To: ietf@ietf.org Date: Thu, 05 Feb 2015 23:49:04 +0100 Message-ID: References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> In-Reply-To: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:IxeAv9WfYXC1ncjs3Cp3FVtT3WPrXslF8yczsfke3Qt/CDufcMq Hvk2aJSi43Y7DRYZpt4YfTCXGwXGLWrNWPT6UyX9f73g/Z6JOmP/DozqhpFc/O7l9vn9CDl md1BLNNVr+rZfcQakkOniUuDyCJR5q/fFFkajoVnTzHPqZoa8x/7gOPTSuWbEQan3Y8n+if ZZL4didr4k5zE54kYsk7w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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: Thu, 05 Feb 2015 22:49:14 -0000 * The IESG wrote: >Abstract > > This document defines the "Basic" Hypertext Transfer Protocol (HTTP) > Authentication Scheme, which transmits credentials as userid/password > pairs, obfuscated by the use of Base64 encoding. I do not think the use of Base64 is intended as obfuscation and it seems misleading to me to describe it as such. (The Introduction has the same problem). In the Introduction: The "Basic" scheme previously was defined in Section 2 of [RFC2617]. This document updates the definition, and also addresses internationalization issues by introducing the "charset" authentication parameter (Section 2.1). I think "updates" is the wrong word considering the document is intended to "obsolete" RFC 2617. In section 2: The "Basic" authentication scheme is based on the model that the client needs to authenticate itself with a user-ID [...] The document switches between "user name", "username", "userid", and "user-ID". I think the "user-ID" forms should be replaced by one of the "name" forms. The realm value is an opaque string which can only be compared for equality with other realms on that server. RFC 7235 says "The realm value is a string, generally assigned by the origin server, that can have additional semantics specific to the authentication scheme." This seems contradictory (perhaps the intent is to say that for the particular case of Basic, the realm value is opaque in contrast to other schemes where it might not be opaque, but that is not clear from the text) and misleading (users make decisions based on the string, which often contains human readable text, so it's not really opaque to them). The original definition of this authentication scheme failed to specify the character encoding scheme used to convert the user-pass into an octet sequence. I think it would be more appropriate to say that it did not do so. That wasn't a particular "failure", sending unlabeled 8bit (and 7bit) content was normal at the time, in part because other system parts also did not know or care about character encodings. There should be an example for "no other authentication parameters are defined -- unknown parameters MUST be ignored by recipients", otherwise such extension points are too easily missed by implementers. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Thu Feb 5 22:44: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 1472F1A1A0C; Thu, 5 Feb 2015 22:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h00QAsmc56sV; Thu, 5 Feb 2015 22:44:09 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 A5E171A1A07; Thu, 5 Feb 2015 22:44:08 -0800 (PST) Received: from [192.168.2.175] ([93.217.112.94]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MAyZg-1YRI8o0Fj2-009wfh; Fri, 06 Feb 2015 07:44:06 +0100 Message-ID: <54D462A6.1030709@gmx.de> Date: Fri, 06 Feb 2015 07:43:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , ietf@ietf.org References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kf6PtbHVAiuEFbytMCQ5jkaZxVN1TlvOxWgFh+OeQzq3fqSa1C2 nLXkirTSqj0xKfYgyY4tzgGnZrOzO85B8/OhHypnFPLAS+RrmhyK4xxGGfmfUSDSO9tCg2i LKT4dvh2f/2Ebcs7wavz4gjt/sBYifqPai538xOWg0kiF2lN8fmewLZDMdgyIjSWc9fHdlD HOYU2vfmhA+hwpIu4kvgg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 06 Feb 2015 06:44:12 -0000 On 2015-02-05 23:49, Bjoern Hoehrmann wrote: > * The IESG wrote: >> Abstract >> >> This document defines the "Basic" Hypertext Transfer Protocol (HTTP) >> Authentication Scheme, which transmits credentials as userid/password >> pairs, obfuscated by the use of Base64 encoding. > > I do not think the use of Base64 is intended as obfuscation and it seems > misleading to me to describe it as such. (The Introduction has the same > problem). I think it was. > In the Introduction: > > The "Basic" scheme previously was defined in Section 2 of [RFC2617]. > This document updates the definition, and also addresses > internationalization issues by introducing the "charset" > authentication parameter (Section 2.1). > > I think "updates" is the wrong word considering the document is intended > to "obsolete" RFC 2617. It does update the definition, no? Also: "Other documents updating RFC 2617 are "Hypertext Transfer Protocol (HTTP/1.1): Authentication" ([RFC7235], defining the authentication framework) and "HTTP Digest Access Authentication" ([DIGEST], updating the definition of the '"Digest" authentication scheme). Taken together, these three documents obsolete RFC 2617." > In section 2: > > The "Basic" authentication scheme is based on the model that the > client needs to authenticate itself with a user-ID [...] > > The document switches between "user name", "username", "userid", and > "user-ID". I think the "user-ID" forms should be replaced by one of the > "name" forms. Good point. I'll have a look. > The realm value is an opaque string > which can only be compared for equality with other realms on that > server. > > RFC 7235 says "The realm value is a string, generally assigned by the > origin server, that can have additional semantics specific to the > authentication scheme." This seems contradictory (perhaps the intent is > to say that for the particular case of Basic, the realm value is opaque > in contrast to other schemes where it might not be opaque, but that is It *is* the definition of the "Basic" scheme. > not clear from the text) and misleading (users make decisions based on > the string, which often contains human readable text, so it's not really > opaque to them). That is true. > The original definition of this authentication scheme failed to > specify the character encoding scheme used to convert the user-pass > into an octet sequence. > > I think it would be more appropriate to say that it did not do so. That > wasn't a particular "failure", sending unlabeled 8bit (and 7bit) content > was normal at the time, in part because other system parts also did not > know or care about character encodings. It's a defect in that specification, no matter when it was written. > There should be an example for "no other authentication parameters are > defined -- unknown parameters MUST be ignored by recipients", otherwise > such extension points are too easily missed by implementers. shows that UAs seem to get at least this correct. I'll think about it. Best regards, Julian From nobody Thu Feb 5 23:58:47 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 ACEEB1A1A4B; Thu, 5 Feb 2015 23:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 iWizcNACli-c; Thu, 5 Feb 2015 23:58:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 C4CEF1A017C; Thu, 5 Feb 2015 23:58:40 -0800 (PST) Received: from netb ([89.204.135.27]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M0tr1-1XUqXL0mw3-00v88Y; Fri, 06 Feb 2015 08:58:39 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Fri, 06 Feb 2015 08:58:37 +0100 Message-ID: References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D462A6.1030709@gmx.de> In-Reply-To: <54D462A6.1030709@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:DBmHZBLJJxMyzyfibu1ex7RZKbumZzq7VDqNUWEzYZGRlliXVY0 6v57+eSE7KuqwIfjJJOc11G5sQuh4UyDVItStwZM7J4q5k0O6TSTKeEIttNkgaIsKvStt0W welIkbbmXK+5YEDzPF9atmUXhWRnsE1SCrfPZ1pIxXi7hqd3kuy+iLIWeWO58jr6yMg+hpL HGPVIiUKh8R7GMl+IOZ4w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, ietf@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 06 Feb 2015 07:58:42 -0000 * Julian Reschke wrote: >On 2015-02-05 23:49, Bjoern Hoehrmann wrote: >> * The IESG wrote: >>> Abstract >>> >>> This document defines the "Basic" Hypertext Transfer Protocol (HTTP) >>> Authentication Scheme, which transmits credentials as userid/password >>> pairs, obfuscated by the use of Base64 encoding. >> >> I do not think the use of Base64 is intended as obfuscation and it seems >> misleading to me to describe it as such. (The Introduction has the same >> problem). > >I think it was. I would take it to mean, in this context, "make difficult to decode", while it's more likely used to "deal with special characters". In any case, if the idea is to note that Base64 is easily reversible, say that instead of "obfuscated". >> In the Introduction: >> >> The "Basic" scheme previously was defined in Section 2 of [RFC2617]. >> This document updates the definition, and also addresses >> internationalization issues by introducing the "charset" >> authentication parameter (Section 2.1). >> >> I think "updates" is the wrong word considering the document is intended >> to "obsolete" RFC 2617. > >It does update the definition, no? Also: "Other documents updating RFC >2617 are "Hypertext Transfer Protocol (HTTP/1.1): Authentication" >([RFC7235], defining the authentication framework) and "HTTP Digest >Access Authentication" ([DIGEST], updating the definition of the >'"Digest" authentication scheme). Taken together, these three documents >obsolete RFC 2617." A better word would be "replaces". >That is true. > >> The original definition of this authentication scheme failed to >> specify the character encoding scheme used to convert the user-pass >> into an octet sequence. >> >> I think it would be more appropriate to say that it did not do so. That >> wasn't a particular "failure", sending unlabeled 8bit (and 7bit) content >> was normal at the time, in part because other system parts also did not >> know or care about character encodings. > >It's a defect in that specification, no matter when it was written. Regardless, I think "did not" would be better than "failed to". -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Fri Feb 6 07:24: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 E8EE11A1B24; Fri, 6 Feb 2015 07:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6BIHRV7_g4bu; Fri, 6 Feb 2015 07:23:59 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 23A451A1B49; Fri, 6 Feb 2015 07:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1423236238; d=isode.com; s=selector; i=@isode.com; bh=ERu9BNvC7HpB0NGmvsKvh6gQa/rBDawS2YTLQj6CkHY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=oTi7L9+Kx6mF7LWxkyXvqS7DNBDKbTZ7v3LGldnzV+1HGp/Rfsjv9eVUW6c7ouEo9GLJIV AGskwUXEbOXpVsDI1XNB7xrJck6K0583N5FRhThumtickVrYthtJL7cwJSkCDYSb1yw8VQ mq3/hKa++HdeZnvBsnk9Rc9mvqO7lm4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 6 Feb 2015 15:23:58 +0000 Message-ID: <54D4DC68.3030507@isode.com> Date: Fri, 06 Feb 2015 15:23:20 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Bjoern Hoehrmann , ietf@ietf.org References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 06 Feb 2015 15:24:02 -0000 Hi Bjoern, On 05/02/2015 22:49, Bjoern Hoehrmann wrote: [snip] > The realm value is an opaque string > which can only be compared for equality with other realms on that > server. > > RFC 7235 says "The realm value is a string, generally assigned by the > origin server, that can have additional semantics specific to the > authentication scheme." This seems contradictory (perhaps the intent is > to say that for the particular case of Basic, the realm value is opaque > in contrast to other schemes where it might not be opaque, but that is > not clear from the text) and misleading (users make decisions based on > the string, which often contains human readable text, so it's not really > opaque to them). I think it is opaque to clients and servers, so they shouldn't try to parse it. > The original definition of this authentication scheme failed to > specify the character encoding scheme used to convert the user-pass > into an octet sequence. > > I think it would be more appropriate to say that it did not do so. That > wasn't a particular "failure", sending unlabeled 8bit (and 7bit) content > was normal at the time, in part because other system parts also did not > know or care about character encodings. I think the current text as specified is accurate, but I don't have a strong opinion. > There should be an example for "no other authentication parameters are > defined -- unknown parameters MUST be ignored by recipients", otherwise > such extension points are too easily missed by implementers. From nobody Fri Feb 6 07:32:18 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 A2DAF1A1B66 for ; Fri, 6 Feb 2015 07:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6S19n14pdsR for ; Fri, 6 Feb 2015 07:31:57 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CDA1A1B6E for ; Fri, 6 Feb 2015 07:31:56 -0800 (PST) Received: from mail-la0-f44.google.com ([209.85.215.44]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKVNTea811mytbxLjafZTBzF8u5QdJOOez@postini.com; Fri, 06 Feb 2015 07:31:56 PST Received: by labgf13 with SMTP id gf13so1855902lab.3 for ; Fri, 06 Feb 2015 07:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=DJ7T3SsJt268taEN8hxi/17KAdPQk/D/dvieXolmMpQ=; b=ifBuopkBq2haZ0UHald+kDYBTNiyq4MwAayECk6hTj5TSPQp2ghiNrOyNzysh/e8zU iApegmDfPD3JgYsT+XLyV2ONj2BnqVITLMYp61sESN2FrwW4aQxOKiJ4vmboGOc2ir4Z 5nLWx6MYjT364zOhGvVafumtQGcdtKlhvJwDs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=DJ7T3SsJt268taEN8hxi/17KAdPQk/D/dvieXolmMpQ=; b=WpS9gZ/1R7HaG7WtXzQVEFUvWx65Suek7sBCn3QVtTLqGKF4VXDsUJD73aqUENnicz WQT3pvecHM/HTFAyusUxRj5dLVs/p9qSbHnGetmcfeDTB+bZH0iLPJiJKCi00nVtmpE8 8Yuxufhsh1eQ41KCWuqpB0JMAsyw/7vTvqK8VH6mJlIRQK+2fb6cCTLbQ06PHVZ2LkiZ XEsbkHzYF3wqPgr/IQ4pqRXojzjSWmBO+HwW07eos5Vgti3Rfn38nf3rTkYu8i+p8VuX DoUAno8TeHmAIDfDajBs5ZGOnOV8GsUBVD4LQDuKfrjXqF8kX5rmS4HuaCC1tDVliTsa ukRA== X-Gm-Message-State: ALoCoQm0jp7dvs/+qsszgZ4yU6+QaxiTxQBCE7pwA/k27LC2zF/f6vLz1l1WoTcO+MB50bh5ifxhPpkpHptQ6JAR02goScmEVdpp+lw2V7QToN1Xlb4nztjAZtFGd4dUnvKTMp2pRNwWK00hAHPIEC2tVG1NGR+hIw== X-Received: by 10.112.148.34 with SMTP id tp2mr3329780lbb.94.1423236714059; Fri, 06 Feb 2015 07:31:54 -0800 (PST) X-Received: by 10.112.148.34 with SMTP id tp2mr3329771lbb.94.1423236713938; Fri, 06 Feb 2015 07:31:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.83.203 with HTTP; Fri, 6 Feb 2015 07:31:33 -0800 (PST) From: Yutaka OIWA Date: Sat, 7 Feb 2015 00:31:33 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [http-auth] (planned) request for comments on Mutual drafts 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, 06 Feb 2015 15:32:00 -0000 Dear all, beside preparing for the next revisions of drafts, we're also preparing a slide set describing some points I'd like to ask for your comments. As some big points are already raised as issue tickets on the tracker (and resolved), my questions will include several niche points such as (for example) choice of keywords, binary encoding schemes or others. I'll post it to the mailing list soon after I update the drafts. We'll really appreciate your comments then. Cheers, Yutaka -- Yutaka OIWA, Ph.D. Senior Researcher, Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Fri Feb 6 07:35:40 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 AF60E1A1B0D; Fri, 6 Feb 2015 07:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 CjaNT5aytick; Fri, 6 Feb 2015 07:35:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 00B511A1B53; Fri, 6 Feb 2015 07:35:22 -0800 (PST) Received: from netb ([89.204.135.61]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M7TQZ-1XO3RQ0uSl-00xLu6; Fri, 06 Feb 2015 16:35:20 +0100 From: Bjoern Hoehrmann To: Alexey Melnikov Date: Fri, 06 Feb 2015 16:35:21 +0100 Message-ID: References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D4DC68.3030507@isode.com> In-Reply-To: <54D4DC68.3030507@isode.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:eu34wdqPuAOYQrALjIYczHY3rCUneTnhMHyAr3K80pLpXO7qyup GwCuA1WD6k57/7mzVW50ZUw6zQFnZcjVygROdSpWzQB9m8TL9Dg3M3mCCN0oG0J2VD5tqmq mZgm3tuUZWWGAKtqemaS3Y6nlX2I5dtrOJsbxHlBheuTIvgxeGF3kxzO2fyw4r/7XQOu52q 0a6xkjutryC1/4o3Xz7KQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, ietf@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 06 Feb 2015 15:35:34 -0000 * Alexey Melnikov wrote: >On 05/02/2015 22:49, Bjoern Hoehrmann wrote: > [snip] >> The realm value is an opaque string >> which can only be compared for equality with other realms on that >> server. >> >> RFC 7235 says "The realm value is a string, generally assigned by the >> origin server, that can have additional semantics specific to the >> authentication scheme." This seems contradictory (perhaps the intent is >> to say that for the particular case of Basic, the realm value is opaque >> in contrast to other schemes where it might not be opaque, but that is >> not clear from the text) and misleading (users make decisions based on >> the string, which often contains human readable text, so it's not really >> opaque to them). > >I think it is opaque to clients and servers, so they shouldn't try to >parse it. A better phrase would be something like "free-form text". -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Fri Feb 6 07:45:39 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 81B551A1BB3; Fri, 6 Feb 2015 07:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 5qSlg91SUoQy; Fri, 6 Feb 2015 07:45:27 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 701E21A1B8A; Fri, 6 Feb 2015 07:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1423237526; d=isode.com; s=selector; i=@isode.com; bh=Npm9CDrWuoH4FDYOIBfvdrZm6q4j/nOGsRY8cUaPK0Y=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WLGkRoQAnubquspW4g7bXWvHXuHPKjfQ/7eCHTRbDn59tx7zAGuMOreIUf7D4670B629cM UThhfKZqadNiZs2XnKavTG/RSMIc68EK6HZIRMi6QzPwd5BJcizaD/GQi+o91eELpL4nmF xoF181DkF+qQoENrsZZT0nvIMMPc020=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 6 Feb 2015 15:45:26 +0000 Message-ID: <54D4E171.4090907@isode.com> Date: Fri, 06 Feb 2015 15:44:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Bjoern Hoehrmann References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D4DC68.3030507@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: http-auth@ietf.org, ietf@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 06 Feb 2015 15:45:30 -0000 On 06/02/2015 15:35, Bjoern Hoehrmann wrote: > * Alexey Melnikov wrote: >> On 05/02/2015 22:49, Bjoern Hoehrmann wrote: >> [snip] >>> The realm value is an opaque string >>> which can only be compared for equality with other realms on that >>> server. >>> >>> RFC 7235 says "The realm value is a string, generally assigned by the >>> origin server, that can have additional semantics specific to the >>> authentication scheme." This seems contradictory (perhaps the intent is >>> to say that for the particular case of Basic, the realm value is opaque >>> in contrast to other schemes where it might not be opaque, but that is >>> not clear from the text) and misleading (users make decisions based on >>> the string, which often contains human readable text, so it's not really >>> opaque to them). >> I think it is opaque to clients and servers, so they shouldn't try to >> parse it. > A better phrase would be something like "free-form text". Maybe something like "free-form text that MUST NOT be interpreted by clients"? I would also like to keep "which can only be compared for equality with other realms on that server", as this is the important part. From nobody Fri Feb 6 08:42: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 03CAC1A6FCF; Fri, 6 Feb 2015 08:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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_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 3lXivMDTgP3E; Fri, 6 Feb 2015 08:41:58 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::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 98E7D1A6FD5; Fri, 6 Feb 2015 08:41:58 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id p6so12727728qcv.1; Fri, 06 Feb 2015 08:41:57 -0800 (PST) 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=+ovdfblj2QVDwYLSFJrQFLrEcHOQfzGHbl7FY+dPc7U=; b=T2j7Dcck09maykiTfJQqAds5sR8V0gsxpL90qvNyQXMkGCTKqlJ34Q2BSl1nbnG2wV EXZQequhE5Nr8w4sSYVdraw9nv1At2rkCIppfU4wbnfELrGMaCuKcVW+jVieV2FnJXha vPJcwP5d6xBNTnGcx3DoxVCBCuWedncmIhdryCGRNHF4Q8HNkb+BPbS2FxB2EyWtLnhS qKajwB1CZ0SE39eclGEoTDwpWS7srp5RG2L+QbC1fLs7AnbR1YkwEmCDwx6GcpLcn19C W9aHkNTjLebgY+RXYxBeYIK3lvo0v9XqCJKOoXgWM4wW+spNp5+LTg69/UGGsV3nKQBB +T+Q== MIME-Version: 1.0 X-Received: by 10.224.30.145 with SMTP id u17mr10069843qac.46.1423240917749; Fri, 06 Feb 2015 08:41:57 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.140.39.163 with HTTP; Fri, 6 Feb 2015 08:41:57 -0800 (PST) In-Reply-To: References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D462A6.1030709@gmx.de> Date: Fri, 6 Feb 2015 11:41:57 -0500 X-Google-Sender-Auth: nHQ4Rz27_DEqnsZGPNUPZ4dwV_8 Message-ID: From: Barry Leiba To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Julian Reschke , http-auth@ietf.org, IETF discussion list Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 06 Feb 2015 16:42:00 -0000 On the "obfuscation" point: >>> I do not think the use of Base64 is intended as obfuscation and it seems >>> misleading to me to describe it as such. (The Introduction has the same >>> problem). >> >>I think it was. > > I would take it to mean, in this context, "make difficult to decode", > while it's more likely used to "deal with special characters". In any > case, if the idea is to note that Base64 is easily reversible, say that > instead of "obfuscated". Obfuscation doesn't have to be hard to decode. The point is that one reason base64 was used was to make it so usernames and passwords don't appear clearly in datastreams and log files. If you know where to find them, they're trivial to decode, of course. But you can't just scan the data and say, "Ah, look, there's a username and password." Barry From nobody Sat Feb 7 23:26:27 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 A29991A1A2E for ; Sat, 7 Feb 2015 23:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 lGGz2iVpNTUE for ; Sat, 7 Feb 2015 23:26:24 -0800 (PST) Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBA11A0143 for ; Sat, 7 Feb 2015 23:26:24 -0800 (PST) Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id 0F40A25AF51C; Sun, 8 Feb 2015 08:26:20 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3kg23Z74Dgz5vN5; Sun, 8 Feb 2015 08:26:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Sophie Bremer In-Reply-To: Date: Sun, 8 Feb 2015 08:26:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9d39bcc732c1d4789b10cc02f12fb8d7@mail.gmail.com> <991DA534-53F1-4A10-8910-B72DD1010DA6@netzkonform.de> <09a78bcd31bbca139477878443a98c82@mail.gmail.com> <8014f6257d63d6be9a18f259a435ba7f@mail.gmail.com> <44BBFF8D-1BFE-48BE-ADFC-87A82A69BB94@netzkonform.de> To: Brett Tate X-Mailer: Apple Mail (2.1085) Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-digest@tools.ietf.org Subject: Re: [http-auth] draft-ietf-httpauth-digest-13: comments 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: Sun, 08 Feb 2015 07:26:26 -0000 Hi Brett, text below. On 2015-02-05 20:08, Brett Tate wrote: >> How should this be covered? In "3.8. Proxy-Authenticate >> and Proxy-Authorization" it could be mentioned as a side >> note at the end, but is this enough? What do you think? >=20 > A potential option would be to modify section 3.4 username paragraph = to > allow both "username" and "username*". If both are present, the > "username*" is used. The "username" parameter is present for = historical > reasons and would be ignored by draft compliant devices. I guess = based > upon the realm (maybe something else), the client assumes acceptable = to > send/use "username*". Since the draft doesn't really discuss "third = party > authentication service", I'll assume that there is no related issue. This is not possible, because "username* is not always in use. For = example, if "userhash=3Dtrue" and "charset=3Dutf-8" are set, username = contains a hash token in base64 without any hint of character encoding. There is also a difference between "charset=3Dutf-8" and the "username*" = parameter itself. "username*" contains the encoding for the header = notation, whereas "charset=3Dutf-8" describes the encoding for hash = calculations. So it is possible to use a different encoding for = "username*" and convert this into UTF-8 for calculations. The whole problem with "username*" has to be made clear in the draft, so = we will cover this in some way. Thank you for the comments! Regards, Sophie= From nobody Tue Feb 10 09:33:40 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 C3FDF1A1B00; Tue, 10 Feb 2015 09:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bPy3VIOYHYGY; Tue, 10 Feb 2015 09:33:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 D92E41A1A98; Tue, 10 Feb 2015 09:33:20 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LzHZ7-1XZEbc41Oz-014Xie; Tue, 10 Feb 2015 18:33:18 +0100 Message-ID: <54DA40DC.7060302@gmx.de> Date: Tue, 10 Feb 2015 18:33:16 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alexey Melnikov , Bjoern Hoehrmann References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D4DC68.3030507@isode.com> <54D4E171.4090907@isode.com> In-Reply-To: <54D4E171.4090907@isode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8dK80eZCsj1Tpfs3RPWfddxklJZW9MJsh/Y2lJAutS9RC6fgBHQ zdwlSK8JXW0PhxG+M469TzYXbsAJQWw1rqQlKZJOW0fNgPudW5x5YTreUP4LLOe1EivXjB4 /6LsxuOUoJyofu2QeSx0w+O8axV6fDcFBY8E//zn/XtFg1pacz481pN21k8QAKXO+ZC27Q0 tuDkgGvxSKJzyEN0EZgGA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, ietf@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 17:33:36 -0000 On 2015-02-06 16:44, Alexey Melnikov wrote: > > On 06/02/2015 15:35, Bjoern Hoehrmann wrote: >> * Alexey Melnikov wrote: >>> On 05/02/2015 22:49, Bjoern Hoehrmann wrote: >>> [snip] >>>> The realm value is an opaque string >>>> which can only be compared for equality with other realms on that >>>> server. >>>> >>>> RFC 7235 says "The realm value is a string, generally assigned by the >>>> origin server, that can have additional semantics specific to the >>>> authentication scheme." This seems contradictory (perhaps the intent is >>>> to say that for the particular case of Basic, the realm value is opaque >>>> in contrast to other schemes where it might not be opaque, but that is >>>> not clear from the text) and misleading (users make decisions based on >>>> the string, which often contains human readable text, so it's not >>>> really >>>> opaque to them). >>> I think it is opaque to clients and servers, so they shouldn't try to >>> parse it. >> A better phrase would be something like "free-form text". > Maybe something like "free-form text that MUST NOT be interpreted by > clients"? > I would also like to keep "which can only be compared for equality with > other realms on that server", as this is the important part. Clarifying: the descriptions of "realm" in RFC 7235 and in this draft are exactly what RFC 2617 said. That being said, I'm ok with replacing "opaque string" by "free-form text" if that makes the participants over here happy. Best regards, Julian From nobody Tue Feb 10 09:38: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 D78E91A1A90; Tue, 10 Feb 2015 09:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UVQELyqPDurR; Tue, 10 Feb 2015 09:38:47 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650851A1A63; Tue, 10 Feb 2015 09:38:47 -0800 (PST) Received: from [192.168.1.26] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id E446B15A0270; Tue, 10 Feb 2015 18:38:45 +0100 (CET) Message-ID: <54DA4225.1020900@greenbytes.de> Date: Tue, 10 Feb 2015 18:38:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , ietf@ietf.org References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D462A6.1030709@gmx.de> In-Reply-To: <54D462A6.1030709@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] ignoring unknown parameters, Re: Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 17:38:49 -0000 On 2015-02-06 07:43, Julian Reschke wrote: > ... >> There should be an example for "no other authentication parameters are >> defined -- unknown parameters MUST be ignored by recipients", otherwise >> such extension points are too easily missed by implementers. > > shows that > UAs seem to get at least this correct. I'll think about it. OK. In my tests I don't see anybody getting *that* wrong, and the new text already is much clearer than RFC 2617 ever was. Thus I don't think we need an example here. Also note that the real challenge (pun intended) is to parse multiple challenges properly; this is something many UAs *do* get wrong despite the prose in both RFC 2617 and RFC 7235. Best regards, Julian From nobody Tue Feb 10 11:57:39 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 1F4671A1F73; Tue, 10 Feb 2015 11:57:32 -0800 (PST) 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 XYu6FDUoSe_u; Tue, 10 Feb 2015 11:57:30 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C401A1BB1; Tue, 10 Feb 2015 11:57:30 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 7a26ad45.0.2209627.00-2308.6115235.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 10 Feb 2015 19:57:30 +0000 (UTC) X-MXL-Hash: 54da62aa03d87b91-55ee1c3a637a4640ed5101984938eba3a36fabee Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1AJvQ19028257; Tue, 10 Feb 2015 14:57:27 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1AJvMio028192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Feb 2015 14:57:24 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 10 Feb 2015 19:57:10 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1AJvAWO015760; Tue, 10 Feb 2015 14:57:10 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1AJv4Pk015339; Tue, 10 Feb 2015 14:57:04 -0500 Received: from azcdtl01sb226e.itservices.sbc.com (azcdtl01sb226e.itservices.sbc.com?[135.110.240.193](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150210195703gw1000ce9ce>; Tue, 10 Feb 2015 19:57:04 +0000 X-Originating-IP: [135.110.240.193] Message-ID: <54DA628E.6030702@att.com> Date: Tue, 10 Feb 2015 14:57:02 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D462A6.1030709@gmx.de> In-Reply-To: <54D462A6.1030709@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=P56NcF8u c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mJp9S24oyUUA:10 a=6IHl18L4XdkA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=mmkSN6yK] X-AnalysisOut: [1PjdJZjVvoMA:9 a=pILNOxqGKmIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 19:57:32 -0000 On 2/6/15 1:43 AM, Julian Reschke wrote: > On 2015-02-05 23:49, Bjoern Hoehrmann wrote: >> * The IESG wrote: >>> Abstract >>> >>> This document defines the "Basic" Hypertext Transfer Protocol (HTTP) >>> Authentication Scheme, which transmits credentials as >>> userid/password >>> pairs, obfuscated by the use of Base64 encoding. >> >> I do not think the use of Base64 is intended as obfuscation and it seems >> misleading to me to describe it as such. (The Introduction has the same >> problem). > > I think it was. I thought the primary reason was so that the credentials would be able to contain arbitrary characters, potentially not otherwise representable within the surrounding protocol. It's an encoding scheme, not an obfuscation scheme. Tony Hansen From nobody Tue Feb 10 13:00:56 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 3EA8F1A1BFB; Tue, 10 Feb 2015 13:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 vmF2bxfkBw2V; Tue, 10 Feb 2015 13:00:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 21C1D1A1BEA; Tue, 10 Feb 2015 13:00:47 -0800 (PST) Received: from netb ([89.204.130.198]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOfQw-1YHQZJ1BKQ-0063OG; Tue, 10 Feb 2015 22:00:44 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Tue, 10 Feb 2015 22:00:44 +0100 Message-ID: References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D462A6.1030709@gmx.de> <54DA4225.1020900@greenbytes.de> In-Reply-To: <54DA4225.1020900@greenbytes.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:JeuXAWo+yv1Dgodg9Y2ImnZsq7+DBjdGCG69tEa8q2dZTFXjIAU jFqlYIpKPvhSBZ4xXvmk1pf9ydtOeE4FwHcfDR1en271yB3mbZOLknRErhJiQsQdYsf3MZy IfcX7U1wlZSo0nSrcB6d7u/strJcQhsMi68O4AiYgeIevdydBmunxLLjKgKPBY7A89GnXfx FXNRBApqj+NKq11wcLeFw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, ietf@ietf.org Subject: Re: [http-auth] ignoring unknown parameters, Re: Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 21:00:51 -0000 * Julian Reschke wrote: >On 2015-02-06 07:43, Julian Reschke wrote: >> ... >>> There should be an example for "no other authentication parameters are >>> defined -- unknown parameters MUST be ignored by recipients", otherwise >>> such extension points are too easily missed by implementers. >> >> shows that >> UAs seem to get at least this correct. I'll think about it. > >OK. In my tests I don't see anybody getting *that* wrong, and the new >text already is much clearer than RFC 2617 ever was. > >Thus I don't think we need an example here. Also note that the real >challenge (pun intended) is to parse multiple challenges properly; this >is something many UAs *do* get wrong despite the prose in both RFC 2617 >and RFC 7235. You cannot really test future implementations. I will survive without an example, but I think it is a bad practise to omit examples demonstrating extension mechanisms like this one. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Tue Feb 10 13:19: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 97F601A6FEF; Tue, 10 Feb 2015 13:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EY06GJw-OYU8; Tue, 10 Feb 2015 13:18:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 883131A6FF0; Tue, 10 Feb 2015 13:18:52 -0800 (PST) Received: from [192.168.2.175] ([93.217.119.132]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M1Wcz-1XSeBM3gwj-00tWDa; Tue, 10 Feb 2015 22:18:50 +0100 Message-ID: <54DA75B6.3050005@gmx.de> Date: Tue, 10 Feb 2015 22:18:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tony Hansen , ietf@ietf.org References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D462A6.1030709@gmx.de> <54DA628E.6030702@att.com> In-Reply-To: <54DA628E.6030702@att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VmJXxHfTRwIoWtw0i/J0xqtEMTgTl5tsPpYEl3K31dtVP7v/6zQ JTCVV0MD+zhr2WlXruquH/Uv7E2ADEnsQvGmElBhTLfPT7SPX1VjfXlDTEyfUf+4oD63RuE H127AlVy4tj8EI7IjA/eRnd4dP1DHHMl04aDg51Yn8ETkjTVySt20eIpJV/dNBqthPuCQ3I 2KRqUSWlStb00OWL53VVg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 21:18:58 -0000 On 2015-02-10 20:57, Tony Hansen wrote: > > On 2/6/15 1:43 AM, Julian Reschke wrote: >> On 2015-02-05 23:49, Bjoern Hoehrmann wrote: >>> * The IESG wrote: >>>> Abstract >>>> >>>> This document defines the "Basic" Hypertext Transfer Protocol (HTTP) >>>> Authentication Scheme, which transmits credentials as >>>> userid/password >>>> pairs, obfuscated by the use of Base64 encoding. >>> >>> I do not think the use of Base64 is intended as obfuscation and it seems >>> misleading to me to describe it as such. (The Introduction has the same >>> problem). >> >> I think it was. > > I thought the primary reason was so that the credentials would be able > to contain arbitrary characters, potentially not otherwise representable > within the surrounding protocol. It's an encoding scheme, not an > obfuscation scheme. How is the intent actually relevant here? Best regards, Julian From nobody Tue Feb 10 13:36: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 181E31A6FE7 for ; Tue, 10 Feb 2015 13:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 pKdEkuNZsZFp for ; Tue, 10 Feb 2015 13:36:24 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4991A1A2E for ; Tue, 10 Feb 2015 13:36:24 -0800 (PST) X-AuditID: 12074423-f79066d0000058b8-86-54da79d6fca0 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id DE.FB.22712.7D97AD45; Tue, 10 Feb 2015 16:36:23 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t1ALaM5k013420; Tue, 10 Feb 2015 16:36:22 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1ALaJ94024370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Feb 2015 16:36:20 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1ALaJFo016659; Tue, 10 Feb 2015 16:36:19 -0500 (EST) Date: Tue, 10 Feb 2015 16:36:18 -0500 (EST) From: Benjamin Kaduk To: draft-ietf-httpauth-basicauth-update@tools.ietf.org In-Reply-To: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> Message-ID: References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixG6nrnu98laIwd4tXBZbthxgsfiwfw6T A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWx6ddZloJmjoq5zy4zNzAeYuti5OSQEDCR 2HZnOzuELSZx4d56oDgXh5DAYiaJXU9uskA4Gxklup4uZIdwDjFJvH58B6qsgVHiwL/7jCD9 LALaEpvOnQOz2QRUJGa+2Qi2Q0TAXGLDyZlgcWagHS+m/mcFaRYWmMgo8eLhfSaQBKeAo8T0 3atYQGxeAQeJluOvwY4SArLX9s0Bs0UFdCRW758CVSMocXLmExaIoVoSy6dvY5nAKDgLSWoW ktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6uZkleqkppZsYweHqoryD8c9BpUOMAhyM Sjy8BYk3Q4RYE8uKK3MPMUpyMCmJ8maV3QoR4kvKT6nMSCzOiC8qzUktPsQowcGsJMLrHw+U 401JrKxKLcqHSUlzsCiJ8276wRciJJCeWJKanZpakFoEk5Xh4FCS4LWuAGoULEpNT61Iy8wp QUgzcXCCDOcBGu5TDjK8uCAxtzgzHSJ/ilFRSpw3AqRZACSRUZoH1wtLJ68YxYFeEeaNB6ni AaYiuO5XQIOZgAYXFNwAGVySiJCSamA0qlJI4jj05t1ebpMLZ67k7HdgePZi6xq1qjP7f53r /tO8QnNF4Ou5P9llLhTN/5aj18et+zuuWq7jpP/3i7VX5ra82flk/m0N/T3aatOEk14zleT6 cwmqFV3Q/v9dsYLzae89L8GO7UbCb9zEbiWJzHz79bf4pJ9Bzn8e/kxg6o/zO/oz8IOZEktx RqKhFnNRcSIA5g24xQIDAAA= Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 21:36:27 -0000 On Thu, 5 Feb 2015, The IESG wrote: > > The IESG has received a request from the Hypertext Transfer Protocol > Authentication WG (httpauth) to consider the following document: > - 'The 'Basic' HTTP Authentication Scheme' > 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-02-19. 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 > > > This document defines the "Basic" Hypertext Transfer Protocol (HTTP) > Authentication Scheme, which transmits credentials as userid/password > pairs, obfuscated by the use of Base64 encoding. I forget if this was already mentioned, but "local-specific encoding" in section 2 should probably use "locale" instead of "local". -Ben From nobody Tue Feb 10 13:46:31 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 EA48C1A86FF; Tue, 10 Feb 2015 13:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 Qt2amhT50Hn2; Tue, 10 Feb 2015 13:46:27 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 BF62F1A8701; Tue, 10 Feb 2015 13:46:26 -0800 (PST) Received: from netb ([89.204.130.198]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lwarz-1XXXIC24X1-018NFs; Tue, 10 Feb 2015 22:46:21 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Tue, 10 Feb 2015 22:46:19 +0100 Message-ID: References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D462A6.1030709@gmx.de> <54DA628E.6030702@att.com> <54DA75B6.3050005@gmx.de> In-Reply-To: <54DA75B6.3050005@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:etW6E9I2WbfH2i/xLEmsAR5BOG7/c2gWjIda+uorsXKHvku08W8 A2xNpHaINBfT8XrBId6y6WqA7WZcY/4xpPFnRkGpUs0uFQN+VGNullH14hhKXY8zQKXoz5t 9z88wvFqpA5Yc3+dWsSdWA2dB6byy1QLv0GyUCHW1zay8X0TBucpSwlpUNTqX2OIrXT51Lb Ep7leWD7JlMB7roMFN4Jw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, ietf@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 21:46:29 -0000 * Julian Reschke wrote: >On 2015-02-10 20:57, Tony Hansen wrote: >> On 2/6/15 1:43 AM, Julian Reschke wrote: >>> On 2015-02-05 23:49, Bjoern Hoehrmann wrote: >>>> * The IESG wrote: >>>>> Abstract >>>>> >>>>> This document defines the "Basic" Hypertext Transfer Protocol (HTTP) >>>>> Authentication Scheme, which transmits credentials as >>>>> userid/password >>>>> pairs, obfuscated by the use of Base64 encoding. >How is the intent actually relevant here? According to the Abstract the intent is obfuscation. If the intent is not relevant, then the Abstract should not draw attention to it. That is pretty much why I brought this up. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Tue Feb 10 13:54:42 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 6FBF01A00B8 for ; Tue, 10 Feb 2015 13:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 zJ8Nk0JFWtkS for ; Tue, 10 Feb 2015 13:54:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 CD4511A005C for ; Tue, 10 Feb 2015 13:54:33 -0800 (PST) Received: from netb ([89.204.130.198]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LdHLB-1XvHcL3b8r-00iSk2; Tue, 10 Feb 2015 22:54:29 +0100 From: Bjoern Hoehrmann To: Benjamin Kaduk Date: Tue, 10 Feb 2015 22:54:30 +0100 Message-ID: <57vkdahdj5a4h3lj90k9f0rs63q4vv9uc1@hive.bjoern.hoehrmann.de> References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:5N6FR9FZPewZv2Un31WJuzCX5pdmIG1riX6oyJhO78DEGbJNVl2 MXN/aRuHcJIlVtk+W0kZS8J2kSkR/M2ocgZ1Li5Dbn+Z0uysw+F1PDtQ91w0jJAi2d46f7p idqlSNX50XFKefS9QB7h9rGLCw21L4eR3kyfpwwBdByw7be/0j7QuLGLZ1wun+REFB1769B WtFnRU80OG5+PSJx9/Vsg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 21:54:37 -0000 * Benjamin Kaduk wrote: >I forget if this was already mentioned, but "local-specific encoding" in >section 2 should probably use "locale" instead of "local". The text in question is "In practice, most implementations chose either a local-specific encoding such as ISO-8859-1 ([ISO-8859-1]), or UTF-8 ([RFC3629])." Now ISO-8859-1 is not really specific to any "locale" and I would rather not suggest that implementations typically derive the encoding from `LC_CTYPE` or some such setting. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Tue Feb 10 13:55: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 838CF1A005C for ; Tue, 10 Feb 2015 13:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 uxs2HDuG2tZo for ; Tue, 10 Feb 2015 13:55:54 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182A71A00B8 for ; Tue, 10 Feb 2015 13:55:54 -0800 (PST) X-AuditID: 1209190d-f792d6d000001fc7-56-54da7e6868ac Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 00.EC.08135.86E7AD45; Tue, 10 Feb 2015 16:55:52 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t1ALtqkU005686; Tue, 10 Feb 2015 16:55:52 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1ALtnxn031351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Feb 2015 16:55:51 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1ALtn58019136; Tue, 10 Feb 2015 16:55:49 -0500 (EST) Date: Tue, 10 Feb 2015 16:55:49 -0500 (EST) From: Benjamin Kaduk To: Bjoern Hoehrmann In-Reply-To: <57vkdahdj5a4h3lj90k9f0rs63q4vv9uc1@hive.bjoern.hoehrmann.de> Message-ID: References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <57vkdahdj5a4h3lj90k9f0rs63q4vv9uc1@hive.bjoern.hoehrmann.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrZtRdyvEYEe7qcWhVf3MFh/2z2Fy YPJYvGk/m8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI2dDawF2xhrVg4cw9TA+MWli5GTg4JAROJ dX+3MUPYYhIX7q1n62Lk4hASWMwksfzpN1YIZyOjxI9Da6CcQ0wSXRvfMUE4DUCZ9g1gs1gE tCUWXPrCCGKzCahIzHyzkQ3EFhHQkHi67DDYDmagHS+m/gebJCwwkVHixcP7TCAJTgEviQWz 77CC2LwCDhJNO/czQmzYzCjx+epVsEmiAjoSq/dPYYEoEpQ4OfMJC8RULYnl07exTGAUnIUk NQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdI73czBK91JTSTYzggJXk3cH47qDSIUYB DkYlHt6CxJshQqyJZcWVuYcYJTmYlER5s8puhQjxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4fWP B8rxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwLqwFahQsSk1PrUjL zClBSDNxcIIM5wEang1Sw1tckJhbnJkOkT/FqMuxoH3/TCYhlrz8vFQpcd4QkCIBkKKM0jy4 ObBE84pRHOgtYV5hkCoeYJKCm/QKaAkT0JKCghsgS0oSEVJSDYxaVx49qNzFuEVyptu3+Xtk vohrTI2+Ly15msvqF5/ro++Ns7ZOT330xr76/dzrpiqPxXj/T1h50FZlvc9x31Xnpjx41+60 tGzCFrOPwen7U9T+bTm9/M6k3TLap9a4668J6Xm94laVrsp0xrKN/DaMSyyuvvzz7FHDxA2r hJfdvb9/vuijg109/5VYijMSDbWYi4oTAeuDRSsPAwAA Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 21:55:56 -0000 On Tue, 10 Feb 2015, Bjoern Hoehrmann wrote: > * Benjamin Kaduk wrote: > >I forget if this was already mentioned, but "local-specific encoding" in > >section 2 should probably use "locale" instead of "local". > > The text in question is "In practice, most implementations chose either > a local-specific encoding such as ISO-8859-1 ([ISO-8859-1]), or UTF-8 > ([RFC3629])." Now ISO-8859-1 is not really specific to any "locale" and > I would rather not suggest that implementations typically derive the > encoding from `LC_CTYPE` or some such setting. Can you tell me then what exactly a "local-specific encoding" is? Because the phrase is currently meaningless to me. -Ben From nobody Tue Feb 10 14:00: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 93D1C1A1A52; Tue, 10 Feb 2015 14:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mCZq6dHgQoG1; Tue, 10 Feb 2015 14:00:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 9B3E41A1A75; Tue, 10 Feb 2015 13:59:38 -0800 (PST) Received: from [192.168.2.175] ([93.217.119.132]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LxxKu-1Xa1G80bci-015J8M; Tue, 10 Feb 2015 22:59:36 +0100 Message-ID: <54DA7F45.8080608@gmx.de> Date: Tue, 10 Feb 2015 22:59:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D462A6.1030709@gmx.de> <54DA628E.6030702@att.com> <54DA75B6.3050005@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EESD0y25dZt7FRNUuypSWs462eeKkeVblxWH5RUlq7oIRbdaLHb Nuy80db0Sae29T8EKnbOHqV5TfhrW33/5rz7eNhWRvAJfX+qvmM1SaWCJSRJDpo1jmwKiL0 Po2/dKVstRiBUs3omJEarWU8cobh32uNtec5T6WBnNNxPE7bVM0uC3jduoY5hqQSHvSxWeg YhR7kuKKpexsR1S5mESVA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, ietf@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 22:00:04 -0000 On 2015-02-10 22:46, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> On 2015-02-10 20:57, Tony Hansen wrote: >>> On 2/6/15 1:43 AM, Julian Reschke wrote: >>>> On 2015-02-05 23:49, Bjoern Hoehrmann wrote: >>>>> * The IESG wrote: >>>>>> Abstract >>>>>> >>>>>> This document defines the "Basic" Hypertext Transfer Protocol (HTTP) >>>>>> Authentication Scheme, which transmits credentials as >>>>>> userid/password >>>>>> pairs, obfuscated by the use of Base64 encoding. > >> How is the intent actually relevant here? > > According to the Abstract the intent is obfuscation. If the intent is > not relevant, then the Abstract should not draw attention to it. That > is pretty much why I brought this up. I don't see anything about intent here. It's simply a statement of facts. Best regards, Julian From nobody Tue Feb 10 14:03: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 822AA1A6FF7 for ; Tue, 10 Feb 2015 14:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bOmN42Fs9-BS for ; Tue, 10 Feb 2015 14:03:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 4E16B1A870F for ; Tue, 10 Feb 2015 14:03:49 -0800 (PST) Received: from [192.168.2.175] ([93.217.119.132]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LtUHA-1XeNS4013c-010wc4; Tue, 10 Feb 2015 23:03:40 +0100 Message-ID: <54DA8039.3030108@gmx.de> Date: Tue, 10 Feb 2015 23:03:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benjamin Kaduk , draft-ietf-httpauth-basicauth-update@tools.ietf.org References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:m6G8ggEnxuqq4iZuXzZjZtZC2VEqJcl51pHHR9VOF77jZKzJshf IJz7CnY2oN4o8y65f/GjWyJdMNrNsZs67nWTmbClzGVJ6ACn6AVh6jjVEmBe6h5ooLn+fMQ 5EyXjzjKo6822HRb9D452+P4+3YZd0lkXS3/fWYM1ghOCfjWqzSsJnMIzhefj6ylgzxsDUm oRhv851tBpEInkEB5LxAg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 22:03:56 -0000 On 2015-02-10 22:36, Benjamin Kaduk wrote: > On Thu, 5 Feb 2015, The IESG wrote: > >> >> The IESG has received a request from the Hypertext Transfer Protocol >> Authentication WG (httpauth) to consider the following document: >> - 'The 'Basic' HTTP Authentication Scheme' >> 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-02-19. 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 >> >> >> This document defines the "Basic" Hypertext Transfer Protocol (HTTP) >> Authentication Scheme, which transmits credentials as userid/password >> pairs, obfuscated by the use of Base64 encoding. > > I forget if this was already mentioned, but "local-specific encoding" in > section 2 should probably use "locale" instead of "local". No, it wasn't. Thanks! From nobody Tue Feb 10 14:06:21 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 029731A037D for ; Tue, 10 Feb 2015 14:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 H4ZMzLPGGtVK for ; Tue, 10 Feb 2015 14:06:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 427D81A0130 for ; Tue, 10 Feb 2015 14:06:18 -0800 (PST) Received: from [192.168.2.175] ([93.217.119.132]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M3vCA-1XTtHJ3GEs-00rbHQ; Tue, 10 Feb 2015 23:06:15 +0100 Message-ID: <54DA80D5.6070300@gmx.de> Date: Tue, 10 Feb 2015 23:06:13 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benjamin Kaduk , Bjoern Hoehrmann References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <57vkdahdj5a4h3lj90k9f0rs63q4vv9uc1@hive.bjoern.hoehrmann.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:H/GU/jaVYKi8m21HXPoJztqLv9P3Pawa3wV3wtMiuocrxC1nRJT PIXAN/T0R4Xk1xzmGY8iF/1J+P/EojGKpx5ddAnkcdiqX3x63trvXS7TP47Bn8S0Gv5XxfA a0PO/QLB5W0zHBn15nRVmARQ8DqNbNdUfqu0u8LlrcVOqVb8rSPSJTRtnMG58X/mHJZvL4o u5ccLKJEOS5vmd43nXIpw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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, 10 Feb 2015 22:06:20 -0000 On 2015-02-10 22:55, Benjamin Kaduk wrote: > On Tue, 10 Feb 2015, Bjoern Hoehrmann wrote: > >> * Benjamin Kaduk wrote: >>> I forget if this was already mentioned, but "local-specific encoding" in >>> section 2 should probably use "locale" instead of "local". >> >> The text in question is "In practice, most implementations chose either >> a local-specific encoding such as ISO-8859-1 ([ISO-8859-1]), or UTF-8 >> ([RFC3629])." Now ISO-8859-1 is not really specific to any "locale" and >> I would rather not suggest that implementations typically derive the >> encoding from `LC_CTYPE` or some such setting. > > Can you tell me then what exactly a "local-specific encoding" is? > Because the phrase is currently meaningless to me. > > -Ben An encoding that depends on the locale of the UA. I really don't know how to say it differently :-) Best regards, Julian From nobody Wed Feb 11 17:25: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 731361A89A6; Wed, 11 Feb 2015 17:24:47 -0800 (PST) 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 iIJ_cTIY1P-r; Wed, 11 Feb 2015 17:24:37 -0800 (PST) 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 7E30D1A8994; Wed, 11 Feb 2015 17:24:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 40652BF07; Thu, 12 Feb 2015 01:25:08 +0000 (GMT) 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 aCgbQgAljB-Z; Thu, 12 Feb 2015 01:25:07 +0000 (GMT) Received: from [172.16.29.97] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 634D6BEEE; Thu, 12 Feb 2015 01:25:06 +0000 (GMT) Message-ID: <54DC00D0.2050900@cs.tcd.ie> Date: Thu, 12 Feb 2015 01:24:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "saag@ietf.org" , "kitten@ietf.org" , "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [http-auth] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "kitten@ietf.org" List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:24:47 -0000 Hiya, I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's needed for some work in http-auth but doesn't quite fit with any current WG. I plan to start an IETF LC for that shortly, but please do let me know if there are any issues. This was previously discussed on the kitten WG list, so (with the WG chairs' permission) I'd ask that you send any comments there if you've any before I start the IETF LC. (Reply-to is set to the kitten WG list.) Thanks, S. [1] https://tools.ietf.org/html/draft-hansen-scram-sha256 From nobody Thu Feb 12 12:14: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 73CB71A8029; Thu, 12 Feb 2015 12:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 D3litz3h1sGr; Thu, 12 Feb 2015 12:13:51 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 AD7F11A6FE6; Thu, 12 Feb 2015 12:11:43 -0800 (PST) Received: by labpn19 with SMTP id pn19so12315883lab.4; Thu, 12 Feb 2015 12:11:40 -0800 (PST) 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=UUXeA4zE0/P12Q6w3LY19RWunZDI4QWZam1PA2tv6DU=; b=KAxRjfoCSkdu9aLkazc/FtlDUe6ISIzgEdYcZ/CY4QWBpr2Si7cR2rajkL4OUSsVZd eolu9m6MiZ0LCNGi67jLIUR1PKFN5EB12JO+/0JgoqQh7w2LT3fmJS2si3OnCpsWOVYM 3jYlKZHKpDFXywcZYsvvZM+H8vFjD+BTOBdGJ5tR3pg5eT/t0jLa2KZ5rjkDP5WhN2Yy jeWHkVaY7iwW7yRkNqIHo71wZ6UCtceIh6Bzt27EWA6+05LQ4dLffU8uixUn++de7BKm gxDiUYoyOu/sHjuNYbXDGu+i5rdcqvPocxGiTt4GOtsybRr1qXupCrVrH5WJTGLCWn8i RolQ== MIME-Version: 1.0 X-Received: by 10.112.181.41 with SMTP id dt9mr5074676lbc.56.1423771900460; Thu, 12 Feb 2015 12:11:40 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 12 Feb 2015 12:11:40 -0800 (PST) In-Reply-To: <54DA7F45.8080608@gmx.de> References: <20150205161049.4222.88369.idtracker@ietfa.amsl.com> <54D462A6.1030709@gmx.de> <54DA628E.6030702@att.com> <54DA75B6.3050005@gmx.de> <54DA7F45.8080608@gmx.de> Date: Thu, 12 Feb 2015 15:11:40 -0500 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c369865e4339050ee9baaa Archived-At: Cc: "http-auth@ietf.org" , Bjoern Hoehrmann , IETF Subject: Re: [http-auth] Last Call: (The 'Basic' HTTP Authentication Scheme) 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: Thu, 12 Feb 2015 20:14:03 -0000 --001a11c369865e4339050ee9baaa Content-Type: text/plain; charset=UTF-8 On Tue, Feb 10, 2015 at 4:59 PM, Julian Reschke wrote: > On 2015-02-10 22:46, Bjoern Hoehrmann wrote: > >> * Julian Reschke wrote: >> >>> On 2015-02-10 20:57, Tony Hansen wrote: >>> >>>> On 2/6/15 1:43 AM, Julian Reschke wrote: >>>> >>>>> On 2015-02-05 23:49, Bjoern Hoehrmann wrote: >>>>> >>>>>> * The IESG wrote: >>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> This document defines the "Basic" Hypertext Transfer Protocol >>>>>>> (HTTP) >>>>>>> Authentication Scheme, which transmits credentials as >>>>>>> userid/password >>>>>>> pairs, obfuscated by the use of Base64 encoding. >>>>>>> >>>>>> >> How is the intent actually relevant here? >>> >> >> According to the Abstract the intent is obfuscation. If the intent is >> not relevant, then the Abstract should not draw attention to it. That >> is pretty much why I brought this up. >> > > I don't see anything about intent here. It's simply a statement of facts. > With no hat on - I wouldn't call an encoding obfuscation either. It looks like this text is specific to this draft and was not in RFC2617. It doesn't really help anything IMO, could you instead just state that Base64 encoding is used? Thanks, Kathleen > > Best regards, Julian > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Best regards, Kathleen --001a11c369865e4339050ee9baaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 10, 2015 at 4:59 PM, Julian Reschke <<= a href=3D"mailto:julian.reschke@gmx.de" target=3D"_blank">julian.reschke@gm= x.de> wrote:
On 2015-02-10 22:46, Bjoern Hoehrmann wrote:
* Julian Reschke wrote:
On 2015-02-10 20:57, Tony Hansen wrote:
On 2/6/15 1:43 AM, Julian Reschke wrote:
On 2015-02-05 23:49, Bjoern Hoehrmann wrote:
* The IESG wrote:
Abstract

=C2=A0 =C2=A0 This document defines the "Basic" Hypertext Transfe= r Protocol (HTTP)
=C2=A0 =C2=A0 Authentication Scheme, which transmits credentials as
userid/password
=C2=A0 =C2=A0 pairs, obfuscated by the use of Base64 encoding.

How is the intent actually relevant here?

According to the Abstract the intent is obfuscation. If the intent is
not relevant, then the Abstract should not draw attention to it. That
is pretty much why I brought this up.

 I don't see anything about intent here. It's simply a statement of = facts.

With no hat on -=C2=A0
I wouldn't call an encoding obfuscation either.=C2=A0 It looks like th= is text is specific to this draft and was not in RFC2617.=C2=A0 It doesn= 9;t really help anything IMO, could you instead just state that Base64 enco= ding is used?

Thanks,
Kathleen

Best regards, Julian


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



--
=

Best regards,
Kathleen
--001a11c369865e4339050ee9baaa-- From nobody Thu Feb 12 14:16:21 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 7ECBE1A0377; Thu, 12 Feb 2015 14:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj7IHXxvufCW; Thu, 12 Feb 2015 14:16:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1851A0430; Thu, 12 Feb 2015 14:15:49 -0800 (PST) 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.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212221549.22193.18552.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 14:15:49 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-06.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, 12 Feb 2015 22:16:11 -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 : The 'Basic' HTTP Authentication Scheme Author : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-update-06.txt Pages : 15 Date : 2015-02-12 Abstract: This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-06 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 Thu Feb 12 14:16: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 20CFD1A0451; Thu, 12 Feb 2015 14:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68QjCkUwOT5S; Thu, 12 Feb 2015 14:16:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A71A046D; Thu, 12 Feb 2015 14:15:49 -0800 (PST) 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.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212221549.22193.11309.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 14:15:49 -0800 Archived-At: Subject: [http-auth] New Version Notification - draft-ietf-httpauth-basicauth-update-06.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, 12 Feb 2015 22:16:17 -0000 X-List-Received-Date: Thu, 12 Feb 2015 22:16:17 -0000 A new version (-06) has been submitted for draft-ietf-httpauth-basicauth-update: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-basicauth-update-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-06 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 Thu Feb 12 14:16:44 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 238431A1A37; Thu, 12 Feb 2015 14:16:18 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CFD1A0451; Thu, 12 Feb 2015 14:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68QjCkUwOT5S; Thu, 12 Feb 2015 14:16:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A71A046D; Thu, 12 Feb 2015 14:15:49 -0800 (PST) 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.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212221549.22193.11309.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 14:15:49 -0800 Archived-At: Subject: [http-auth] New Version Notification - draft-ietf-httpauth-basicauth-update-06.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, 12 Feb 2015 22:16:19 -0000 A new version (-06) has been submitted for draft-ietf-httpauth-basicauth-update: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-basicauth-update-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-06 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 Thu Feb 12 23:58:15 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 0A9231A1B42 for ; Thu, 12 Feb 2015 23:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 S71WXEDtwtpR for ; Thu, 12 Feb 2015 23:58:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B82A21A1B62 for ; Thu, 12 Feb 2015 23:58:11 -0800 (PST) Received: from [192.168.2.175] ([84.187.55.253]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lubnw-1Xe4uX1VUe-00zopx for ; Fri, 13 Feb 2015 08:58:09 +0100 Message-ID: <54DDAE8D.5040504@gmx.de> Date: Fri, 13 Feb 2015 08:58:05 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <20150212221549.22193.11309.idtracker@ietfa.amsl.com> In-Reply-To: <20150212221549.22193.11309.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7n1dnioxqBb3p9YOMi1olFNRHEc/dDDUzaQWNLk+IYYKYhoXoM/ oDdDa3LwWs5tml7cQB0lurRytyZ5rTxz53sfmpv6MV/7inKQFuF++LlY9yHnRybD8pjSGVw g/G37wyVGoztd4q/f7qQq5WrWjXGdyX/wQREo5FAH19MDpdRYSyPkS/Bij9L2KN1IsRzy42 +iYw4N0znTM+dFm5CQwsw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [http-auth] New Version Notification - draft-ietf-httpauth-basicauth-update-06.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: Fri, 13 Feb 2015 07:58:14 -0000 On 2015-02-12 23:15, internet-drafts@ietf.org wrote: > > A new version (-06) has been submitted for draft-ietf-httpauth-basicauth-update: > http://www.ietf.org/internet-drafts/draft-ietf-httpauth-basicauth-update-06.txt > ... Hi there. This draft addresses most of the feedback received so far; I posted it so the the IESG doesn't have to re-report things. Best regards, Julian From nobody Fri Feb 13 01:29: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 797D31A1E0B for ; Fri, 13 Feb 2015 01:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jhyLCqBOZIaf for ; Fri, 13 Feb 2015 01:29:38 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 44FD61A1EB7 for ; Fri, 13 Feb 2015 01:29:37 -0800 (PST) Received: by lamq1 with SMTP id q1so15168833lam.5 for ; Fri, 13 Feb 2015 01:29:35 -0800 (PST) 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=t8caWA6lFkhX9PIudniGLcU9xRtuwiojh0setYQS7zE=; b=plkh6eQ2956xTJBRwAXbr1UAIiQGUAfgrtgvSYDlvxCQfyOGkLeHPZAzgnj8IDZjxG t0zssCd4pnNrwW1eyeh8NvuBJVXBULtWQO6S85jvCUo3iFaDvW3AxVN9cHxV8whCWsS5 ZTVlhEbQKDONrL0GaDng0FKPPWw3Tw2ECqa1zsnXlQ2SGhN5RJ+LNVJbW4m5JYkbEFfi GbgQTNsvCuKrawe2LoAJ4eREa79rqurFSPDiZj8VhaM4dVzBelehRgw7Qb1EVWl3K85O oLt2GsV/Mn+7rvtlpTHv9FZwiCSKcYR8T7hhnvfq1IlfaclHLnMNMLAYsL6HB8F5SYO9 bsAA== MIME-Version: 1.0 X-Received: by 10.112.9.38 with SMTP id w6mr6925283lba.113.1423819775621; Fri, 13 Feb 2015 01:29:35 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 13 Feb 2015 01:29:35 -0800 (PST) In-Reply-To: <54DDAE8D.5040504@gmx.de> References: <20150212221549.22193.11309.idtracker@ietfa.amsl.com> <54DDAE8D.5040504@gmx.de> Date: Fri, 13 Feb 2015 04:29:35 -0500 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=001a1134deb8f33e97050ef4df87 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] New Version Notification - draft-ietf-httpauth-basicauth-update-06.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: Fri, 13 Feb 2015 09:29:40 -0000 --001a1134deb8f33e97050ef4df87 Content-Type: text/plain; charset=UTF-8 Thank you, Julian. On Fri, Feb 13, 2015 at 2:58 AM, Julian Reschke wrote: > On 2015-02-12 23:15, internet-drafts@ietf.org wrote: > >> >> A new version (-06) has been submitted for draft-ietf-httpauth-basicauth- >> update: >> http://www.ietf.org/internet-drafts/draft-ietf-httpauth- >> basicauth-update-06.txt >> ... >> > > Hi there. > > This draft addresses most of the feedback received so far; I posted it so > the the IESG doesn't have to re-report things. > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Best regards, Kathleen --001a1134deb8f33e97050ef4df87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, Julian.

On Fri, Feb 13, 2015 at 2:58 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
On 2015-02-12 23:15, internet-drafts@ietf.org wrote:

A new version (-06) has been submitted for draft-ietf-httpauth-basicauth-update:
http://www.ietf.org/internet-draf= ts/draft-ietf-httpauth-basicauth-update-06.txt
 ...

Hi there.

This draft addresses most of the feedback received so far; I posted it so t= he the IESG doesn't have to re-report things.

Best regards, Julian

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



--

Best regards,
Kath= leen
--001a1134deb8f33e97050ef4df87-- From nobody Fri Feb 13 12:04: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 64AF31A020B for ; Fri, 13 Feb 2015 12:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 goP-kpfpUYKh for ; Fri, 13 Feb 2015 12:04:02 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7689D1A0248 for ; Fri, 13 Feb 2015 12:04:02 -0800 (PST) Received: from unknown [144.160.229.23] by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) with SMTP id 1b85ed45.0.3007036.00-2018.8337309.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 13 Feb 2015 20:04:02 +0000 (UTC) X-MXL-Hash: 54de58b24256639e-05c1f1c5b556db322c57dbcc5057192298acd14a Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DJWsF1015417 for ; Fri, 13 Feb 2015 14:33:10 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DJWm09013478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 13 Feb 2015 14:32:50 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Fri, 13 Feb 2015 19:32:37 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DJWbbg012665 for ; Fri, 13 Feb 2015 14:32:37 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DJWTG0011998 for ; Fri, 13 Feb 2015 14:32:30 -0500 Received: from txcdtl01ks8671.itservices.sbc.com (txcdtl01ks8671.itservices.sbc.com?[135.110.240.237](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150213193228gw1000cebpe>; Fri, 13 Feb 2015 19:32:29 +0000 X-Originating-IP: [135.110.240.237] Message-ID: <54DE514B.40506@att.com> Date: Fri, 13 Feb 2015 14:32:27 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Reschke References: <20150212221549.22193.11309.idtracker@ietfa.amsl.com> <54DDAE8D.5040504@gmx.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040603010202040508060208" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=ApVZKpBP c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mJp9S24oyUUA:10 a=UZBibCCZedwA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=48vgC7mUAAAA:8 a=3Ax1bbJ9Y] X-AnalysisOut: [AWxzw3y3CMA:9 a=pILNOxqGKmIA:10 a=-74GIUBQk5IyT81U:21 a=No] X-AnalysisOut: [56TQz6L0JTqIEw:21 a=pGLkceISAAAA:8 a=8vzdEilA8ptqiDjtGp4A:] X-AnalysisOut: [9 a=_W_S_7VecoQA:10 a=nrNu-KWm1shQ4FDN:21 a=R8ojLcVm46ES4_] X-AnalysisOut: [_t:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: "http-auth@ietf.org >> IETF HTTP Auth" Subject: Re: [http-auth] New Version Notification - draft-ietf-httpauth-basicauth-update-06.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: Fri, 13 Feb 2015 20:04:05 -0000 This is a multi-part message in MIME format. --------------040603010202040508060208 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2/13/15 4:29 AM, Kathleen Moriarty wrote: > Thank you, Julian. > > On Fri, Feb 13, 2015 at 2:58 AM, Julian Reschke > wrote: > > On 2015-02-12 23:15, internet-drafts@ietf.org > wrote: > > > A new version (-06) has been submitted for > draft-ietf-httpauth-basicauth-update: > http://www.ietf.org/internet-drafts/draft-ietf-httpauth-basicauth-update-06.txt > ... > > > This draft addresses most of the feedback received so far; I > posted it so the the IESG doesn't have to re-report things. > I read the document afresh from the beginning to the end. I consider it ready for publication. Minor nits below. None are showstoppers. Tony Hansen section 2 (add the before user-id, to parallel "the password"): < constructs the user-pass by concatenating user-id, a single colon < (":") character, and the password, -- > constructs the user-pass by concatenating the user-id, a single colon > (":") character, and the password, section 2.1 (change comma to semi-colon): < Note: The 'charset' is only defined on challenges, as "Basic" uses < a single token for credentials ('token68' syntax), thus the < credentials syntax isn't extensible. -- > Note: The 'charset' is only defined on challenges, as "Basic" uses > a single token for credentials ('token68' syntax); thus the > credentials syntax isn't extensible. Section 3 (add "a revision to"): < The "realm" parameter carries data that can be considered textual, < however [RFC7235] does not define a way to reliably transport non-US- < ASCII characters. This is a known issue that would need to be < addressed in that specification. -- > The "realm" parameter carries data that can be considered textual, > however [RFC7235] does not define a way to reliably transport non-US- > ASCII characters. This is a known issue that would need to be > addressed in a revision to that specification. Section 4 (add "other" to better clarify the use of "those sites"): < The owner or administrator of such a < system could therefore expose all users of the system to the risk of < unauthorized access to all those sites if this information is not < maintained in a secure fashion. -- > The owner or administrator of such a > system could therefore expose all users of the system to the risk of > unauthorized access to all those other sites if this information is not > maintained in a secure fashion. Section 4 (we'll soon have more than just Digest, so how about ...): < This type of attack is not possible with Digest < Authentication. -- > This type of attack is not possible with other authentication schemes, such as Digest > Authentication. or > This type of attack is not possible with Digest > Authentication, or other authentication schemes that do not send the credentials > directly. Section 6 (verb usage): < The internationalization problem with respect to the character < encoding scheme used for user-pass has been reported as a Mozilla bug < back in the year 2000 (see -- > The internationalization problem with respect to the character > encoding scheme used for user-pass was reported as a Mozilla bug > back in the year 2000 (see Section B.3 ("what" -> "which"): < Note that sites might even inspect the User-Agent header field < ([RFC7231], Section 5.5.3) to decide what character encoding scheme < to expect from the client. -- > Note that sites might even inspect the User-Agent header field > ([RFC7231], Section 5.5.3) to decide which character encoding scheme > to expect from the client. --------------040603010202040508060208 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 2/13/15 4:29 AM, Kathleen Moriarty wrote:
Thank you, Julian.

On Fri, Feb 13, 2015 at 2:58 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
On 2015-02-12 23:15, internet-drafts@ietf.org wrote:

A new version (-06) has been submitted for draft-ietf-httpauth-basicauth-update:
http://www.ietf.org/internet-drafts/draft-ietf-httpauth-basicauth-update-06.txt
 ...

This draft addresses most of the feedback received so far; I posted it so the the IESG doesn't have to re-report things.

I read the document afresh from the beginning to the end. I consider it ready for publication.

Minor nits below. None are showstoppers.

    Tony Hansen

section 2 (add the before user-id, to parallel "the password"):

< constructs the user-pass by concatenating user-id, a single colon
< (":") character, and the password,
--
> constructs the user-pass by concatenating the user-id, a single colon
> (":") character, and the password,

section 2.1 (change comma to semi-colon):

<      Note: The 'charset' is only defined on challenges, as "Basic" uses
<      a single token for credentials ('token68' syntax), thus the
<      credentials syntax isn't extensible.
--
>      Note: The 'charset' is only defined on challenges, as "Basic" uses
>      a single token for credentials ('token68' syntax); thus the
>      credentials syntax isn't extensible.

Section 3 (add "a revision to"):

<   The "realm" parameter carries data that can be considered textual,
<   however [RFC7235] does not define a way to reliably transport non-US-
<   ASCII characters.  This is a known issue that would need to be
<   addressed in that specification.
--
>   The "realm" parameter carries data that can be considered textual,
>   however [RFC7235] does not define a way to reliably transport non-US-
>   ASCII characters.  This is a known issue that would need to be
>   addressed in a revision to that specification.

Section 4 (add "other" to better clarify the use of "those sites"):

<   The owner or administrator of such a
<   system could therefore expose all users of the system to the risk of
<   unauthorized access to all those sites if this information is not
<   maintained in a secure fashion.
--
>   The owner or administrator of such a
>   system could therefore expose all users of the system to the risk of
>   unauthorized access to all those other sites if this information is not
>   maintained in a secure fashion.

Section 4 (we'll soon have more than just Digest, so how about ...):

<  This type of attack is not possible with Digest
<   Authentication.
--
>  This type of attack is not possible with other authentication schemes, such as Digest
>   Authentication.
or
>  This type of attack is not possible with Digest
>   Authentication, or other authentication schemes that do not send the credentials
>   directly.

Section 6 (verb usage):

<   The internationalization problem with respect to the character
<   encoding scheme used for user-pass has been reported as a Mozilla bug
<   back in the year 2000 (see
--
>   The internationalization problem with respect to the character
>   encoding scheme used for user-pass was reported as a Mozilla bug
>   back in the year 2000 (see

Section B.3 ("what" -> "which"):


<   Note that sites might even inspect the User-Agent header field
<   ([RFC7231], Section 5.5.3) to decide what character encoding scheme
<   to expect from the client. 
--
>   Note that sites might even inspect the User-Agent header field
>   ([RFC7231], Section 5.5.3) to decide which character encoding scheme
>   to expect from the client. 
--------------040603010202040508060208-- From nobody Fri Feb 13 13:30: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 893221A1A57 for ; Fri, 13 Feb 2015 13:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fgCOc2ijAoUM for ; Fri, 13 Feb 2015 13:30:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 30DA91A1A14 for ; Fri, 13 Feb 2015 13:30:19 -0800 (PST) Received: from [192.168.2.175] ([84.187.45.172]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LgeFd-1XqsPT1eTN-00ny5e; Fri, 13 Feb 2015 22:30:14 +0100 Message-ID: <54DE6CE0.3000301@gmx.de> Date: Fri, 13 Feb 2015 22:30:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tony Hansen References: <20150212221549.22193.11309.idtracker@ietfa.amsl.com> <54DDAE8D.5040504@gmx.de> <54DE514B.40506@att.com> In-Reply-To: <54DE514B.40506@att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NzQyolKKlVyEB/vd/Mwbj/V9m1DEfs6WSdyRXyBvnxwcFRQ5vLg 1ikz5UJNkZdOSaRVisRJJRVz7lUyHoMnaNqgUgXQFFwrxIxAs/M1evhRO4BF01vb+OrxV3f DQTHvlvZZteZLJEGFqYr0WXbT5579zHfPPyTpqY9+WO2nrVsLBg33xQOPB3f3J0QDA2+tQc do7c5YX9gJnsppKCj/+xw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org >> IETF HTTP Auth" Subject: Re: [http-auth] New Version Notification - draft-ietf-httpauth-basicauth-update-06.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: Fri, 13 Feb 2015 21:30:21 -0000 On 2015-02-13 20:32, Tony Hansen wrote: > On 2/13/15 4:29 AM, Kathleen Moriarty wrote: >> Thank you, Julian. >> >> On Fri, Feb 13, 2015 at 2:58 AM, Julian Reschke > > wrote: >> >> On 2015-02-12 23:15, internet-drafts@ietf.org >> wrote: >> >> >> A new version (-06) has been submitted for >> draft-ietf-httpauth-basicauth-update: >> http://www.ietf.org/internet-drafts/draft-ietf-httpauth-basicauth-update-06.txt >> ... >> >> >> This draft addresses most of the feedback received so far; I >> posted it so the the IESG doesn't have to re-report things. >> > > I read the document afresh from the beginning to the end. I consider it > ready for publication. > > Minor nits below. None are showstoppers. > ... Thanks, Tony! -> From nobody Mon Feb 16 01:48: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 8107A1A879F; Mon, 16 Feb 2015 01:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 uKJvqLYjLIzI; Mon, 16 Feb 2015 01:48:43 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EBC1A1A94; Mon, 16 Feb 2015 01:48:42 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:2999:8dd0:70ed:36a2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1G9mQlW002499 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Feb 2015 10:48:27 +0100 From: Simon Josefsson To: Stephen Farrell References: <54DC00D0.2050900@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150216:saag@ietf.org::Jc2JG4WsjrZNwtiw:BHUR X-Hashcash: 1:22:150216:stephen.farrell@cs.tcd.ie::YPH3Px1gxiJuxrcN:5ofE X-Hashcash: 1:22:150216:kitten@ietf.org::ZDkkZ4ZLrYOkxmVC:NKIr X-Hashcash: 1:22:150216:http-auth@ietf.org::JYW4JhqrwSxgt6go:wIal Date: Mon, 16 Feb 2015 10:48:25 +0100 In-Reply-To: <54DC00D0.2050900@cs.tcd.ie> (Stephen Farrell's message of "Thu, 12 Feb 2015 01:24:32 +0000") Message-ID: <87r3tqqj9y.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] AD sponsoring draft-hansen-scram-sha256 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, 16 Feb 2015 09:48:44 -0000 --=-=-= Content-Type: text/plain Stephen Farrell writes: > Hiya, > > I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's > needed for some work in http-auth but doesn't quite fit with any > current WG. I plan to start an IETF LC for that shortly, but please > do let me know if there are any issues. Since SCRAM was published, we have learned that the tls-unique channel binding is insecure -- it would be nice if we could combine the SHA256 update with another default channel binding type to resolve that problem. In my view, the problem with SCRAM today isn't primarily its use of SHA1 but it's broken channel binding. A suggested (not even mandated) pbkdf iteration count of at least 4096 is unchanged since RFC 5802 -- I'd really like to see that be significantly higher. Back in 2000 an iteration count of 1000 was recommended as the minimum. Surely computational power has increased more than a factor of four since then. /Simon > This was previously discussed on the kitten WG list, so (with > the WG chairs' permission) I'd ask that you send any comments > there if you've any before I start the IETF LC. (Reply-to is > set to the kitten WG list.) > > Thanks, > S. > > [1] https://tools.ietf.org/html/draft-hansen-scram-sha256 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU4bzpAAoJEIYLf7sy+BGdLJMH/2UVm1Cq+WobKXz4gg4SSPnq mm+Bv1cihrz5FF52mQwKyyjMS1Ww3ZqEl0WPr4aBnBYrV5MM2CR5M9DpO4Bpz1YA sGKFULzk6Y+h246VipIKpw370CTUST/hsB0gMf5fzvnlwPfHEttU1zyL/Ct+2l5/ nRnq93aok7q4BySTaZZn4ZsLzY3Y1cssu5+GrUiSZGnkMILpRpjj1P2hJMyY9A0u d7AQiBomHJZgNf5LJz/epkA7psp0cTW5qdxOqOOV9K4WCamlK3Jwf48qfJdDotJF dOjDuHOno0sCwQyloURg928VuYY7IyW+M093I0A5WcQM009nQtDdBAzIKFp0Te0= =aPqw -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 16 02:15:48 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 91C281A887F; Mon, 16 Feb 2015 02:15:44 -0800 (PST) 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 j5g2BK_dJm4i; Mon, 16 Feb 2015 02:15:42 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 ACD631A87A9; Mon, 16 Feb 2015 02:15:41 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so40571463obc.1; Mon, 16 Feb 2015 02:15:41 -0800 (PST) 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=Vo+4Lhm2eqkgleBGICOexNOG5aGtpXcl63DV5Rvgeic=; b=eK95kgCRWN4PB30Ggwu9iN+2jHD2scpX8zRn/zdMpy8YXPFhClF/Zeczc8/3EjVqW/ jbuKwYpy9nuqGlB6UB179onkTCJdEYSbRTc/8NxVKR2Bq5+2sYVGsbT94n2AL1q1f+k8 uZAvw8gDtH0qK5hvjSVXdEZjYQ7kalfsdxjw9dDZhF8MA1A+1dBKiH42RgjO0yZ8alMW b+PD3reDG28r9KKWApi1VWH4qORPOmEHJAy0/1yy3g6UcQb3HVrpS7G0nYMxl4VP4PYj 9um7bIySXjgExeillaoP/VbJOeSPJ2arBuVeV42pYgCSsMNLrdoPxe+13kUr7BwykFa3 WhFw== MIME-Version: 1.0 X-Received: by 10.202.94.197 with SMTP id s188mr13992334oib.94.1424081740941; Mon, 16 Feb 2015 02:15:40 -0800 (PST) Received: by 10.202.225.135 with HTTP; Mon, 16 Feb 2015 02:15:40 -0800 (PST) In-Reply-To: <87r3tqqj9y.fsf@latte.josefsson.org> References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> Date: Mon, 16 Feb 2015 21:15:40 +1100 Message-ID: From: Martin Thomson To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] AD sponsoring draft-hansen-scram-sha256 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, 16 Feb 2015 10:15:44 -0000 On 16 February 2015 at 20:48, Simon Josefsson wrote: > Since SCRAM was published, we have learned that the tls-unique channel > binding is insecure -- it would be nice if we could combine the SHA256 > update with another default channel binding type to resolve that > problem. In my view, the problem with SCRAM today isn't primarily its > use of SHA1 but it's broken channel binding. We have a solution for that: https://tools.ietf.org/html/draft-ietf-tls-session-hash From nobody Mon Feb 16 02:55:26 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 A7A791A0158; Mon, 16 Feb 2015 02:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 Z5iCQbaaK3W7; Mon, 16 Feb 2015 02:55:17 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057FC1A87C6; Mon, 16 Feb 2015 02:55:16 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:2999:8dd0:70ed:36a2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1GAsxsR009139 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Feb 2015 11:55:00 +0100 Date: Mon, 16 Feb 2015 11:54:57 +0100 From: Simon Josefsson To: Martin Thomson Message-ID: <20150216115457.3c16fdbf@latte.josefsson.org> In-Reply-To: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/Cj_a0vmV/eSiOCEMBWO5yhM"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] AD sponsoring draft-hansen-scram-sha256 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, 16 Feb 2015 10:55:18 -0000 --Sig_/Cj_a0vmV/eSiOCEMBWO5yhM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Den Mon, 16 Feb 2015 21:15:40 +1100 skrev Re: [saag] AD sponsoring draft-hansen-scram-sha256: > On 16 February 2015 at 20:48, Simon Josefsson > wrote: > > Since SCRAM was published, we have learned that the tls-unique > > channel binding is insecure -- it would be nice if we could combine > > the SHA256 update with another default channel binding type to > > resolve that problem. In my view, the problem with SCRAM today > > isn't primarily its use of SHA1 but it's broken channel binding. >=20 >=20 > We have a solution for that: > https://tools.ietf.org/html/draft-ietf-tls-session-hash Then SCRAM-SHA256 should normatively references that and require that it is implemented for secure use of SCRAM with channel bindings. There are drawbacks with that approach: it is not widely implemented, not published as an RFC that updates earlier TLS versions, and difficult for SCRAM implementers to validate (usually the TLS stack is opaque to the SCRAM implementer). I could live with that though, as a way of pushing the current security problem down from the IETF protocol layer into the implementation layer. Alternatively, use a new channel binding type that use the extended master secret derivation as described by the document above. I could update draft-josefsson-sasl-tls-cb to describe this approach. /Simon --Sig_/Cj_a0vmV/eSiOCEMBWO5yhM Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU4cyCAAoJEIYLf7sy+BGdc9EH/i0+0+gTBOFj5xqU9u8A3JpA exIv/q/HCpm6c4r9PjM9PA6DdqRPr9+bFl/o9h4UPsDw4Fwjny9WetPCUvzf4WFN eCnRQBzwyWVOoyjQftoWiDVFUVI7wJsEgOY1ynyB/br3uoOHtFueLSa9KIOur8aG +mtyBa8067RedRmMV3nRIQCZ/+x8Ui9A0Bwa0gHJ0QlRG7ZzxMP9cIzRvAMaLkrW dBMS3GQ38eTcOFt4lZYUhMPpa2ei7CtKNb6MNLmm1VtzwDhNt9X2V/gUwoFY/U7H krWO1dozYPta14qRrDsY1+wyWxxlWCYaxdaZRGcSC0XTxoW+9WPizXxWVrtKgrs= =85Yc -----END PGP SIGNATURE----- --Sig_/Cj_a0vmV/eSiOCEMBWO5yhM-- From nobody Mon Feb 16 03:10:26 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 05BE91A876E; Mon, 16 Feb 2015 03:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MQuxtGz1mgH9; Mon, 16 Feb 2015 03:10:13 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3044A1A8794; Mon, 16 Feb 2015 03:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424085006; d=isode.com; s=selector; i=@isode.com; bh=H2M622mg5Pj/fBD/ED7nkJsBaHoEU2Zj4EztCeOSPKg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=JFgBTqFpbCCBnUuEJcTlTPsZdm2TS6HzzndlOjyFEgAQ+wH5Z2OOo0kk2N2ggjd6jvNnk3 iEgrUiq1Irg5jhoeqlMJn3L5v70exejMcE3ZCuR6eyR4BF5rOmncLCuzuMvtoF9/0kLv+l CUnJQB/qKRnvprZ+AxJWPEuiyfA7AEs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Feb 2015 11:10:06 +0000 Message-ID: <54E1D009.2050408@isode.com> Date: Mon, 16 Feb 2015 11:10:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Simon Josefsson , Stephen Farrell References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> In-Reply-To: <87r3tqqj9y.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] AD sponsoring draft-hansen-scram-sha256 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, 16 Feb 2015 11:10:22 -0000 Hi Simon, On 16/02/2015 09:48, Simon Josefsson wrote: [snip] > A suggested (not even mandated) pbkdf iteration count of at least 4096 > is unchanged since RFC 5802 -- I'd really like to see that be > significantly higher. Back in 2000 an iteration count of 1000 was > recommended as the minimum. Surely computational power has increased > more than a factor of four since then. I've heard complains from developers that 4096 with SHA-1 is too high for current Android phones. It would be good to get more information on performance before changing the number. From nobody Mon Feb 16 03:21: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 38F671A882B for ; Mon, 16 Feb 2015 03:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 75gDeH886zQ9 for ; Mon, 16 Feb 2015 03:21:34 -0800 (PST) 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 9396C1A8824 for ; Mon, 16 Feb 2015 03:21:34 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wp4so41122922obc.10 for ; Mon, 16 Feb 2015 03:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wgyXFE5xwyGIhKJiS4fp1H4E3c6EICG4Fgz5lzKMPAw=; b=JjR9sU3mxf3nYJQhDweL0DazRsbcWKsnw0pvph2t8LxRdA7WCfMk9kw+3JMz+gIxZa mE8/usiyrpoR4+fc9uMxMgvQdg2TS8BU8SBoD2OmDp+/prmgoOUva3tNjPpTHoejHFPL Q2OfGOg/UpYQ2wt8/vD2Zi/CE8zevNQUHLT3I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wgyXFE5xwyGIhKJiS4fp1H4E3c6EICG4Fgz5lzKMPAw=; b=L/VlvurQ3wPEXGeo+a8WcuE8MovKQpAwbTFXlO/mqKqbwphW0gCm48NO+7mWAMtyRs vKTRQxOvPWRPR7TbgIK36tL1/hcqq1KzQH9wK6K5R9xVvgrWrcL/oyYhDjQ2eLtVThke WlYmblAuuj4PI7Hh1EWcZuojjQ9xai0GYJkuNiafrK/sHbXsUZ8YVzjjnT8D8OruI4Or o6paOtmCmNipHTVnKq2A+lp4I7jNyc6FOdSwsfQ+gHDPLFzuF2ayKKN47ZQnrviaIv3i FoimoH3yeGQ/UgJ8XIdM7S3xGHPjgSP79k+hQfpwmqAt4IVHy7aq7eTkSeRbFL3BVguo MSSQ== X-Gm-Message-State: ALoCoQmRTXQB7+MChGz/nDyAW77plFXYtvIBa2thH5v9IkjTmWInRw3+27PDMUmLVrU6uOU/AFgv MIME-Version: 1.0 X-Received: by 10.202.52.215 with SMTP id b206mr14131825oia.31.1424085693831; Mon, 16 Feb 2015 03:21:33 -0800 (PST) Received: by 10.60.77.71 with HTTP; Mon, 16 Feb 2015 03:21:33 -0800 (PST) Received: by 10.60.77.71 with HTTP; Mon, 16 Feb 2015 03:21:33 -0800 (PST) In-Reply-To: <54E1D009.2050408@isode.com> References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> Date: Mon, 16 Feb 2015 11:21:33 +0000 Message-ID: From: Dave Cridland To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a113cd412e936aa050f32c9c1 Archived-At: Cc: kitten@ietf.org, Simon Josefsson , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 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, 16 Feb 2015 11:21:36 -0000 --001a113cd412e936aa050f32c9c1 Content-Type: text/plain; charset=UTF-8 On 16 Feb 2015 11:10, "Alexey Melnikov" wrote: > > Hi Simon, > > On 16/02/2015 09:48, Simon Josefsson wrote: > [snip] > >> A suggested (not even mandated) pbkdf iteration count of at least 4096 >> is unchanged since RFC 5802 -- I'd really like to see that be >> significantly higher. Back in 2000 an iteration count of 1000 was >> recommended as the minimum. Surely computational power has increased >> more than a factor of four since then. > > I've heard complains from developers that 4096 with SHA-1 is too high for current Android phones. It would be good to get more information on performance before changing the number. > Worth asking in the XSF, there's likely to be implementation experience from the Android client devs there. However, clients need only do the iterations once, if the salt is stable, at least in principle. > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --001a113cd412e936aa050f32c9c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 Feb 2015 11:10, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:
>
> Hi Simon,
>
> On 16/02/2015 09:48, Simon Josefsson wrote:
> =C2=A0[snip]
>
>> A suggested (not even mandated) pbkdf iteration count of at least = 4096
>> is unchanged since RFC 5802 -- I'd really like to see that be<= br> >> significantly higher.=C2=A0 Back in 2000 an iteration count of 100= 0 was
>> recommended as the minimum.=C2=A0 Surely computational power has i= ncreased
>> more than a factor of four since then.
>
> I've heard complains from developers that 4096 with SHA-1 is too h= igh for current Android phones. It would be good to get more information on= performance before changing the number.
>

Worth asking in the XSF, there's likely to be implementa= tion experience from the Android client devs there.

However, clients need only do the iterations once, if the sa= lt is stable, at least in principle.

>
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.i= etf.org/mailman/listinfo/kitten

--001a113cd412e936aa050f32c9c1-- From nobody Mon Feb 16 03:23: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 8C7051A8824; Mon, 16 Feb 2015 03:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 cGA1zhoDn4xb; Mon, 16 Feb 2015 03:23:06 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AF61A8834; Mon, 16 Feb 2015 03:23:05 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:2999:8dd0:70ed:36a2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1GBMsio012070 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Feb 2015 12:22:55 +0100 From: Simon Josefsson To: Alexey Melnikov References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150216:kitten@ietf.org::EWdwoo552beHa/0b:WT X-Hashcash: 1:22:150216:http-auth@ietf.org::F8s7r/08HLa4mUxC:29gH X-Hashcash: 1:22:150216:saag@ietf.org::uPGbsf7wXCavTt7U:3dcZ X-Hashcash: 1:22:150216:alexey.melnikov@isode.com::/LkbAKUNDiSHfRjc:2A1c X-Hashcash: 1:22:150216:stephen.farrell@cs.tcd.ie::swRGKVSRaHsx72yf:Bmtq Date: Mon, 16 Feb 2015 12:22:53 +0100 In-Reply-To: <54E1D009.2050408@isode.com> (Alexey Melnikov's message of "Mon, 16 Feb 2015 11:10:01 +0000") Message-ID: <87iof2qewi.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] AD sponsoring draft-hansen-scram-sha256 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, 16 Feb 2015 11:23:07 -0000 --=-=-= Content-Type: text/plain Alexey Melnikov writes: > Hi Simon, > > On 16/02/2015 09:48, Simon Josefsson wrote: > [snip] >> A suggested (not even mandated) pbkdf iteration count of at least 4096 >> is unchanged since RFC 5802 -- I'd really like to see that be >> significantly higher. Back in 2000 an iteration count of 1000 was >> recommended as the minimum. Surely computational power has increased >> more than a factor of four since then. > I've heard complains from developers that 4096 with SHA-1 is too high > for current Android phones. It would be good to get more information > on performance before changing the number. You will always hear complaints from developers that security features adds computational and other resource costs. When that happens, I prefer asking myself whether the threat model motivates the cost or not. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU4dMNAAoJEIYLf7sy+BGdIAEH+wQRkqNucW+OSk7yZc6dRTyZ 6xHI/xsD8Vg1PjQ12ED7ixYlgEdpcuFOtUt+tPy9hqgDVQcs/Uojmk8HAIcCLhee Z7n3WQnnbBXIGaKYzZeBZWu6dcmBAiQU+S3bldYXoKGrYoH67l1qhInidqgO4hgs dedmZcFj6RxFnFt3vpO4MZvEy2iQKpQJ+179spNhbMDKa0obgofdwhcWKcOkz5GI G3IUHocYVjJZmrPJp2D5jlsh9y59VoV0sWH5/jP++qgyC81r9bj42fIkl/oQbjBz OrPQAOI9j8ZE4mRMjs37tFO//l4N8l+ixyDpAhWRfYN6NPcPgPD9bgoWfMc2bDo= =kxUe -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 16 17:52:07 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 4C9F81A8963; Mon, 16 Feb 2015 17:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aDLUyMzvu1H; Mon, 16 Feb 2015 17:52:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF891A895E; Mon, 16 Feb 2015 17:52:02 -0800 (PST) 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: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217015202.9887.27442.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 17:52:02 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-basicauth-update-06: (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, 17 Feb 2015 01:52:04 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a pretty crappy auth scheme, but this is a pretty good update and fills a need, thanks for the latter:-) - section 2: is it worth saying somewhere that you can't really have >1 proxy-auth happening even if you transit >1 proxy? - section 2, last para: I assume this is because client and/or server behaviour varies for this? If so, maybe it'd be good to give some guidance or add a reference (if a good one exists). If there's some other reason, it'd be good to say too. - section 4: would it be worth adding some guidance that re-use of e.g. entreprise login/SSO passwords for proxy-auth is particularly dodgy as is not protected via TLS? From nobody Mon Feb 16 17:52:10 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7C4DD1A8967; Mon, 16 Feb 2015 17:52:04 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9F81A8963; Mon, 16 Feb 2015 17:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aDLUyMzvu1H; Mon, 16 Feb 2015 17:52:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF891A895E; Mon, 16 Feb 2015 17:52:02 -0800 (PST) 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: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217015202.9887.27442.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 17:52:02 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-basicauth-update-06: (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, 17 Feb 2015 01:52:04 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a pretty crappy auth scheme, but this is a pretty good update and fills a need, thanks for the latter:-) - section 2: is it worth saying somewhere that you can't really have >1 proxy-auth happening even if you transit >1 proxy? - section 2, last para: I assume this is because client and/or server behaviour varies for this? If so, maybe it'd be good to give some guidance or add a reference (if a good one exists). If there's some other reason, it'd be good to say too. - section 4: would it be worth adding some guidance that re-use of e.g. entreprise login/SSO passwords for proxy-auth is particularly dodgy as is not protected via TLS? From nobody Mon Feb 16 23:34:07 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 AD8B81A872E; Mon, 16 Feb 2015 23:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PDE2tJE_e-0a; Mon, 16 Feb 2015 23:34:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 CA9CC1A8746; Mon, 16 Feb 2015 23:33:58 -0800 (PST) Received: from [192.168.2.175] ([84.187.43.210]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M9fLX-1YHndX22Pf-00CvNT; Tue, 17 Feb 2015 08:33:53 +0100 Message-ID: <54E2EEDE.5050308@gmx.de> Date: Tue, 17 Feb 2015 08:33:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150217015202.9887.27442.idtracker@ietfa.amsl.com> In-Reply-To: <20150217015202.9887.27442.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:we8XK6CYFc5aXg4pVEUBBor+kuUd2hiODINzeaKFruoXy6BBsOZ Ay/cKsG7z8x3RtvkXwDCkQtww06oLHrNvxX1sQFFuHOWaAEAH5wASHX713aYRB0Mt6wHGWS 0RLdtaexVd+oGFzPVki2mG8+zGowQDYrkg2yZPO+O3haWJrTcnG38tNHDoU/EHY+8Nxm06F 9l4nIQCojg58sn0V9c5aA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-basicauth-update-06: (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: Tue, 17 Feb 2015 07:34:06 -0000 On 2015-02-17 02:52, Stephen Farrell wrote: > ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > This is a pretty crappy auth scheme, but this is a pretty > good update and fills a need, thanks for the latter:-) Thanks :-) > - section 2: is it worth saying somewhere that you can't > really have >1 proxy-auth happening even if you transit >1 > proxy? Somewhere yes, but not here. When we do RFC7235bis, I'd like to get the proxy auth parts some attention, and that needs feedback from people who actually do have some experience with it (which I do not). > - section 2, last para: I assume this is because client > and/or server behaviour varies for this? If so, maybe it'd Yes. > be good to give some guidance or add a reference (if a > good one exists). If there's some other reason, it'd be > good to say too. I don't have a reference nor guidance. UAs behave differently and are allowed to do so. I don't think we can say something beyond that. > - section 4: would it be worth adding some guidance that > re-use of e.g. entreprise login/SSO passwords for > proxy-auth is particularly dodgy as is not protected via > TLS? There's a lot of things that can be said about the topic of password choice and re-use. Is it specific to Basic auth? I'm not opposed to add something, but this sounds like an open-ended topic. If you have a concrete proposal for text, I'm all ears :-) Best regards, Julian From nobody Mon Feb 16 23:34:11 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D0A711A8749; Mon, 16 Feb 2015 23:34:06 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8B81A872E; Mon, 16 Feb 2015 23:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PDE2tJE_e-0a; Mon, 16 Feb 2015 23:34:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 CA9CC1A8746; Mon, 16 Feb 2015 23:33:58 -0800 (PST) Received: from [192.168.2.175] ([84.187.43.210]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M9fLX-1YHndX22Pf-00CvNT; Tue, 17 Feb 2015 08:33:53 +0100 Message-ID: <54E2EEDE.5050308@gmx.de> Date: Tue, 17 Feb 2015 08:33:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150217015202.9887.27442.idtracker@ietfa.amsl.com> In-Reply-To: <20150217015202.9887.27442.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:we8XK6CYFc5aXg4pVEUBBor+kuUd2hiODINzeaKFruoXy6BBsOZ Ay/cKsG7z8x3RtvkXwDCkQtww06oLHrNvxX1sQFFuHOWaAEAH5wASHX713aYRB0Mt6wHGWS 0RLdtaexVd+oGFzPVki2mG8+zGowQDYrkg2yZPO+O3haWJrTcnG38tNHDoU/EHY+8Nxm06F 9l4nIQCojg58sn0V9c5aA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-basicauth-update-06: (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: Tue, 17 Feb 2015 07:34:07 -0000 On 2015-02-17 02:52, Stephen Farrell wrote: > ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > This is a pretty crappy auth scheme, but this is a pretty > good update and fills a need, thanks for the latter:-) Thanks :-) > - section 2: is it worth saying somewhere that you can't > really have >1 proxy-auth happening even if you transit >1 > proxy? Somewhere yes, but not here. When we do RFC7235bis, I'd like to get the proxy auth parts some attention, and that needs feedback from people who actually do have some experience with it (which I do not). > - section 2, last para: I assume this is because client > and/or server behaviour varies for this? If so, maybe it'd Yes. > be good to give some guidance or add a reference (if a > good one exists). If there's some other reason, it'd be > good to say too. I don't have a reference nor guidance. UAs behave differently and are allowed to do so. I don't think we can say something beyond that. > - section 4: would it be worth adding some guidance that > re-use of e.g. entreprise login/SSO passwords for > proxy-auth is particularly dodgy as is not protected via > TLS? There's a lot of things that can be said about the topic of password choice and re-use. Is it specific to Basic auth? I'm not opposed to add something, but this sounds like an open-ended topic. If you have a concrete proposal for text, I'm all ears :-) Best regards, Julian From nobody Tue Feb 17 00:06: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 D22221A8728; Tue, 17 Feb 2015 00:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6PWeAruJuzf; Tue, 17 Feb 2015 00:06:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C891A870D; Tue, 17 Feb 2015 00:06:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217080610.12513.81065.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 00:06:10 -0800 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: Tue, 17 Feb 2015 08:06:13 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Tue Feb 17 00:06:15 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F22711A870D; Tue, 17 Feb 2015 00:06:12 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22221A8728; Tue, 17 Feb 2015 00:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6PWeAruJuzf; Tue, 17 Feb 2015 00:06:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C891A870D; Tue, 17 Feb 2015 00:06:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217080610.12513.81065.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 00:06:10 -0800 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: Tue, 17 Feb 2015 08:06:13 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Tue Feb 17 06:47:28 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 790E61A89A1; Tue, 17 Feb 2015 06:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huwhcRUeL96h; Tue, 17 Feb 2015 06:47:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 948311A8879; Tue, 17 Feb 2015 06:47:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217144716.13384.65154.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 06:47:16 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Barry Leiba's Yes on draft-ietf-httpauth-basicauth-update-06: (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, 17 Feb 2015 14:47:25 -0000 Barry Leiba has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 1.1.1 -- This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Where? You do use 5234 as a reference to define CTL characters, so you need the reference. But that sentence can go. -- Section 5 -- The entry for the "Basic" Authentication Scheme shall be updated with a pointer to this specification. IANA might think this means that they should add this spec to the existing reference. It'd be clearer to say it this way, and less likely to result in an error by IANA: NEW The entry for the "Basic" Authentication Scheme shall be updated by replacing the reference with a pointer to this specification. END From nobody Tue Feb 17 06:47:29 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 990F41A89A3; Tue, 17 Feb 2015 06:47:25 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790E61A89A1; Tue, 17 Feb 2015 06:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huwhcRUeL96h; Tue, 17 Feb 2015 06:47:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 948311A8879; Tue, 17 Feb 2015 06:47:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217144716.13384.65154.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 06:47:16 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Barry Leiba's Yes on draft-ietf-httpauth-basicauth-update-06: (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, 17 Feb 2015 14:47:25 -0000 Barry Leiba has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 1.1.1 -- This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Where? You do use 5234 as a reference to define CTL characters, so you need the reference. But that sentence can go. -- Section 5 -- The entry for the "Basic" Authentication Scheme shall be updated with a pointer to this specification. IANA might think this means that they should add this spec to the existing reference. It'd be clearer to say it this way, and less likely to result in an error by IANA: NEW The entry for the "Basic" Authentication Scheme shall be updated by replacing the reference with a pointer to this specification. END From nobody Tue Feb 17 07:10: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 275A11A89F6; Tue, 17 Feb 2015 07:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dg5uAjRv3Km5; Tue, 17 Feb 2015 07:10:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 AE2AD1A89E1; Tue, 17 Feb 2015 07:10:40 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MY7dI-1Y1gfE1PP6-00UvAP; Tue, 17 Feb 2015 16:10:36 +0100 Message-ID: <54E359E9.6070409@gmx.de> Date: Tue, 17 Feb 2015 16:10:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150217144716.13384.65154.idtracker@ietfa.amsl.com> In-Reply-To: <20150217144716.13384.65154.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QqsnhrQpcUdzhinr4/ef1mSL6od+MAbZWSwyRHax+LzJSlMTNNY f2iW2OiC22YTGYyZyN/wyNX62c9E4Zh59RxKBAVs7E93oXc51whMVziWQ4R3sbhn3IyUq8f KR+CLsOA1rI6U4MuDfb7+DchGMo0eyTGcyBB4aTVfYVC1+J43Vx8amEEikWBVZbO24bTEcW kkHJH1pyrsEPShkAZQajg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Barry Leiba's Yes on draft-ietf-httpauth-basicauth-update-06: (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: Tue, 17 Feb 2015 15:10:45 -0000 On 2015-02-17 15:47, Barry Leiba wrote: > ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -- Section 1.1.1 -- > > This specification uses the Augmented Backus-Naur Form (ABNF) > notation of [RFC5234]. > > Where? > You do use 5234 as a reference to define CTL characters, so you need the > reference. But that sentence can go. Good catch. > -- Section 5 -- > > The entry for the "Basic" Authentication Scheme shall be updated with > a pointer to this specification. > > IANA might think this means that they should add this spec to the > existing reference. It'd be clearer to say it this way, and less likely > to result in an error by IANA: > > NEW > The entry for the "Basic" Authentication Scheme shall be updated by > replacing the reference with a pointer to this specification. > END Another good catch; IANA already asked the same question :-) Thanks for the feedback! -> Best regards, Julian From nobody Tue Feb 17 07:10:58 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 481941A89E1; Tue, 17 Feb 2015 07:10:45 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275A11A89F6; Tue, 17 Feb 2015 07:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dg5uAjRv3Km5; Tue, 17 Feb 2015 07:10:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 AE2AD1A89E1; Tue, 17 Feb 2015 07:10:40 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MY7dI-1Y1gfE1PP6-00UvAP; Tue, 17 Feb 2015 16:10:36 +0100 Message-ID: <54E359E9.6070409@gmx.de> Date: Tue, 17 Feb 2015 16:10:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150217144716.13384.65154.idtracker@ietfa.amsl.com> In-Reply-To: <20150217144716.13384.65154.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QqsnhrQpcUdzhinr4/ef1mSL6od+MAbZWSwyRHax+LzJSlMTNNY f2iW2OiC22YTGYyZyN/wyNX62c9E4Zh59RxKBAVs7E93oXc51whMVziWQ4R3sbhn3IyUq8f KR+CLsOA1rI6U4MuDfb7+DchGMo0eyTGcyBB4aTVfYVC1+J43Vx8amEEikWBVZbO24bTEcW kkHJH1pyrsEPShkAZQajg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Barry Leiba's Yes on draft-ietf-httpauth-basicauth-update-06: (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: Tue, 17 Feb 2015 15:10:45 -0000 On 2015-02-17 15:47, Barry Leiba wrote: > ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -- Section 1.1.1 -- > > This specification uses the Augmented Backus-Naur Form (ABNF) > notation of [RFC5234]. > > Where? > You do use 5234 as a reference to define CTL characters, so you need the > reference. But that sentence can go. Good catch. > -- Section 5 -- > > The entry for the "Basic" Authentication Scheme shall be updated with > a pointer to this specification. > > IANA might think this means that they should add this spec to the > existing reference. It'd be clearer to say it this way, and less likely > to result in an error by IANA: > > NEW > The entry for the "Basic" Authentication Scheme shall be updated by > replacing the reference with a pointer to this specification. > END Another good catch; IANA already asked the same question :-) Thanks for the feedback! -> Best regards, Julian From nobody Tue Feb 17 08:26:25 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 8EDB51A8AC9; Tue, 17 Feb 2015 08:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 P4cEvYvNt-o5; Tue, 17 Feb 2015 08:26:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A621A88A5; Tue, 17 Feb 2015 08:26:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217162621.15373.19851.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 08:26:21 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Spencer Dawkins' No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 17 Feb 2015 16:26:22 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nice job on a specification that is better than the technology it describes (echoing Stephen's ballot)! From nobody Tue Feb 17 08:26:26 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AC0E51A8ACF; Tue, 17 Feb 2015 08:26:22 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDB51A8AC9; Tue, 17 Feb 2015 08:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 P4cEvYvNt-o5; Tue, 17 Feb 2015 08:26:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A621A88A5; Tue, 17 Feb 2015 08:26:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217162621.15373.19851.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 08:26:21 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Spencer Dawkins' No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 17 Feb 2015 16:26:22 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nice job on a specification that is better than the technology it describes (echoing Stephen's ballot)! From nobody Tue Feb 17 09:05:21 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 DB8B81A900B; Tue, 17 Feb 2015 09:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Tq4WqunDX4S; Tue, 17 Feb 2015 09:05:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF99B1A8908; Tue, 17 Feb 2015 09:05:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217170507.12007.41425.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 09:05:07 -0800 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: Tue, 17 Feb 2015 17:05:13 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Tue Feb 17 09:05:22 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0CCE61A8908; Tue, 17 Feb 2015 09:05:12 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8B81A900B; Tue, 17 Feb 2015 09:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Tq4WqunDX4S; Tue, 17 Feb 2015 09:05:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF99B1A8908; Tue, 17 Feb 2015 09:05:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217170507.12007.41425.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 09:05:07 -0800 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: Tue, 17 Feb 2015 17:05:13 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Wed Feb 18 08:55:39 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 E5FCB1A1AB6 for ; Wed, 18 Feb 2015 04:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 rMhCVE0g96Ee for ; Wed, 18 Feb 2015 04:58:28 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (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 97A2B1A8749 for ; Wed, 18 Feb 2015 04:58:27 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id f12so556912qad.9 for ; Wed, 18 Feb 2015 04:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qZHGLYKv3Qd4bSALEINcFelyyLSeIqoiShDEAuS/P+w=; b=ydE2EB7HA3zwlQzqPnEGTvdRLu2ohiZ6ARWMBo9Ma/BjI2Bx48Md2XihVVjlgmh+ag eVieU8qIWrwDK9jWkm5FbSi4t1Q+1CLPzBV88gTgIHcTszQgz0/RW/mGowX59hgTNqGc YwrXMGK8D93l/2iqc2T9x0QaU+3fhZH/c4+tA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=qZHGLYKv3Qd4bSALEINcFelyyLSeIqoiShDEAuS/P+w=; b=SZyV1wm93a7fgj+HmNQ3vRHUqkfryU0267IaNhqG8ZU+caAw3Z1ebB3pCejleM5h+C HfBLNt2CjbkgixMJv1jCnPMReVez/tNXV7kAwA/tiYYG+B7SwrcgehIg8V4KP/dQyFTK 6Oxyyq/x79L0yp631CQ0Mhroy4IX2q43wRySbkau/tY6b/kzC0fpnAyrfxt6ovDVb0Lg MHOamLb4diCADxxnbjTHWCCyU+ISYZZnlxgT0ihBj79C5q9u1d2P8/bi1RzaUs+nuGZe L+QXHZD6fqOoPdfwN3TBV55+OSA3/jZTASXR6igiXcJrsply9wjUEDtXVT15KzNEfEUA JpjA== X-Gm-Message-State: ALoCoQkA6Fl4Rsa2v6kJh/pci6DXUG+dI4PFUt+fTT2ZshvR46DBYzB/1RDADwWm5Npvw9tf3iMc X-Received: by 10.229.216.130 with SMTP id hi2mr657282qcb.4.1424264306770; Wed, 18 Feb 2015 04:58:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.22.51 with HTTP; Wed, 18 Feb 2015 04:57:46 -0800 (PST) X-Originating-IP: [75.117.16.85] In-Reply-To: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> From: Sam Whited Date: Wed, 18 Feb 2015 07:57:46 -0500 Message-ID: To: Dave Cridland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 18 Feb 2015 08:55:38 -0800 Cc: kitten@ietf.org, "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 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, 18 Feb 2015 12:58:32 -0000 On Mon, Feb 16, 2015 at 6:21 AM, Dave Cridland wrote: > Worth asking in the XSF, there's likely to be implementation experience f= rom > the Android client devs there. I wrote the SCRAM-SHA-1 implementation in Conversations. While I don't remember actual numbers off the top of my head, I can definitely tell you that there is a noticable delay with a 4096 iteration count (probably a little over half a second) on my HTC m7 (which is fairly beefy as far as phones go). HOWEVER=E2=80=94 > However, clients need only do the iterations once, if the salt is stable,= at > least in principle. =E2=80=94since we then store the session information in an LRU Cache in memory, it's only slow when you first login. I've thought about moving the session info to the database as well to make it even more persistant, but decided it wasn't enough of a problem to bother polluting the database. Best, Sam --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Wed Feb 18 11:47: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 190DF1A016C; Wed, 18 Feb 2015 11:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AS78zpY9_UP; Wed, 18 Feb 2015 11:46:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A13971A015F; Wed, 18 Feb 2015 11:46:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218194656.23776.44631.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 11:46:56 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org, httpauth@ietf.org Subject: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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: Wed, 18 Feb 2015 19:47:00 -0000 Richard Barnes has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: Discuss 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-basicauth-update/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2.2 seems like a significant departure from RFC 2617, which says nothing about the scope of authentication. (1) Did the WG discuss the compatibility impact of this change? Although clients might send the Authorization header preemptively, they should still be prepared to get a 401 response back. (2) Did the WG discuss the possibilities for leakage of credentials due to this change? It's not hard to imagine scenarios where, say, "http://example.com/~user1" and "http://example.com/~user2" are controlled by different entities, and leakage between them would be harmful. (3) At the very least, there needs to be (a) a mention of this change in Appendix A, and (b) a discussion of leakage through unsolicited Authorization headers in the Security Considerations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The current text on the use of TLS is an OK start, but I would prefer if it were refactored so that the recommendation against Basic were general to HTTP and HTTPS. "Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used except over a secure channel such as HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic authentication SHOULD NOT be used to protect sensitive or valuable information." From nobody Wed Feb 18 11:47:04 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 392C41A0177; Wed, 18 Feb 2015 11:47:00 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190DF1A016C; Wed, 18 Feb 2015 11:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AS78zpY9_UP; Wed, 18 Feb 2015 11:46:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A13971A015F; Wed, 18 Feb 2015 11:46:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218194656.23776.44631.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 11:46:56 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org, httpauth@ietf.org Subject: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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: Wed, 18 Feb 2015 19:47:00 -0000 Richard Barnes has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: Discuss 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-basicauth-update/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2.2 seems like a significant departure from RFC 2617, which says nothing about the scope of authentication. (1) Did the WG discuss the compatibility impact of this change? Although clients might send the Authorization header preemptively, they should still be prepared to get a 401 response back. (2) Did the WG discuss the possibilities for leakage of credentials due to this change? It's not hard to imagine scenarios where, say, "http://example.com/~user1" and "http://example.com/~user2" are controlled by different entities, and leakage between them would be harmful. (3) At the very least, there needs to be (a) a mention of this change in Appendix A, and (b) a discussion of leakage through unsolicited Authorization headers in the Security Considerations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The current text on the use of TLS is an OK start, but I would prefer if it were refactored so that the recommendation against Basic were general to HTTP and HTTPS. "Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used except over a secure channel such as HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic authentication SHOULD NOT be used to protect sensitive or valuable information." From nobody Wed Feb 18 11:47:52 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 657E81A015F; Wed, 18 Feb 2015 11:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIQQzuefLybF; Wed, 18 Feb 2015 11:47:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4BB1A0141; Wed, 18 Feb 2015 11:47:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218194749.23802.1910.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 11:47:49 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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: Wed, 18 Feb 2015 19:47:51 -0000 Richard Barnes has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: Discuss 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-basicauth-update/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2.2 seems like a significant departure from RFC 2617, which says nothing about the scope of authentication. (1) Did the WG discuss the compatibility impact of this change? Although clients might send the Authorization header preemptively, they should still be prepared to get a 401 response back. (2) Did the WG discuss the possibilities for leakage of credentials due to this change? It's not hard to imagine scenarios where, say, "http://example.com/~user1" and "http://example.com/~user2" are controlled by different entities, and leakage between them would be harmful. (3) At the very least, there needs to be (a) a mention of this change in Appendix A, and (b) a discussion of leakage through unsolicited Authorization headers in the Security Considerations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The current text on the use of TLS is an OK start, but I would prefer if it were refactored so that the recommendation against Basic were general to HTTP and HTTPS. "Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used except over a secure channel such as HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic authentication SHOULD NOT be used to protect sensitive or valuable information." From nobody Wed Feb 18 11:47:56 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 82C0E1A0162; Wed, 18 Feb 2015 11:47:51 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657E81A015F; Wed, 18 Feb 2015 11:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIQQzuefLybF; Wed, 18 Feb 2015 11:47:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4BB1A0141; Wed, 18 Feb 2015 11:47:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218194749.23802.1910.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 11:47:49 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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: Wed, 18 Feb 2015 19:47:51 -0000 Richard Barnes has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: Discuss 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-basicauth-update/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2.2 seems like a significant departure from RFC 2617, which says nothing about the scope of authentication. (1) Did the WG discuss the compatibility impact of this change? Although clients might send the Authorization header preemptively, they should still be prepared to get a 401 response back. (2) Did the WG discuss the possibilities for leakage of credentials due to this change? It's not hard to imagine scenarios where, say, "http://example.com/~user1" and "http://example.com/~user2" are controlled by different entities, and leakage between them would be harmful. (3) At the very least, there needs to be (a) a mention of this change in Appendix A, and (b) a discussion of leakage through unsolicited Authorization headers in the Security Considerations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The current text on the use of TLS is an OK start, but I would prefer if it were refactored so that the recommendation against Basic were general to HTTP and HTTPS. "Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used except over a secure channel such as HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic authentication SHOULD NOT be used to protect sensitive or valuable information." From nobody Wed Feb 18 11:52:19 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 5530F1A0155; Wed, 18 Feb 2015 11:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JWqglRRxnqGD; Wed, 18 Feb 2015 11:52:12 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B191A0179; Wed, 18 Feb 2015 11:52:12 -0800 (PST) Received: from [192.168.2.175] (unknown [93.217.116.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 2396D15A047B; Wed, 18 Feb 2015 20:52:09 +0100 (CET) Message-ID: <54E4ED66.4040100@greenbytes.de> Date: Wed, 18 Feb 2015 20:52:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Richard Barnes , The IESG References: <20150218194749.23802.1910.idtracker@ietfa.amsl.com> In-Reply-To: <20150218194749.23802.1910.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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, 18 Feb 2015 19:52:15 -0000 On 2015-02-18 20:47, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-httpauth-basicauth-update-06: Discuss > > 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-basicauth-update/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2.2 seems like a significant departure from RFC 2617, which says > nothing about the scope of authentication. It's only a rephrasing of . > (1) Did the WG discuss the compatibility impact of this change? Although > clients might send the Authorization header preemptively, they should > still be prepared to get a 401 response back. > > (2) Did the WG discuss the possibilities for leakage of credentials due > to this change? It's not hard to imagine scenarios where, say, > "http://example.com/~user1" and "http://example.com/~user2" are > controlled by different entities, and leakage between them would be > harmful. > > (3) At the very least, there needs to be (a) a mention of this change in > Appendix A, and (b) a discussion of leakage through unsolicited > Authorization headers in the Security Considerations. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The current text on the use of TLS is an OK start, but I would prefer if > it were refactored so that the recommendation against Basic were general > to HTTP and HTTPS. > > "Because Basic authentication involves the cleartext transmission of > passwords it SHOULD NOT be used except over a secure channel such as > HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic > authentication SHOULD NOT be used to protect sensitive or valuable > information." > > -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From nobody Wed Feb 18 11:52:20 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 755C51A017A; Wed, 18 Feb 2015 11:52:15 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5530F1A0155; Wed, 18 Feb 2015 11:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JWqglRRxnqGD; Wed, 18 Feb 2015 11:52:12 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B191A0179; Wed, 18 Feb 2015 11:52:12 -0800 (PST) Received: from [192.168.2.175] (unknown [93.217.116.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 2396D15A047B; Wed, 18 Feb 2015 20:52:09 +0100 (CET) Message-ID: <54E4ED66.4040100@greenbytes.de> Date: Wed, 18 Feb 2015 20:52:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Richard Barnes , The IESG References: <20150218194749.23802.1910.idtracker@ietfa.amsl.com> In-Reply-To: <20150218194749.23802.1910.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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, 18 Feb 2015 19:52:15 -0000 On 2015-02-18 20:47, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-httpauth-basicauth-update-06: Discuss > > 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-basicauth-update/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2.2 seems like a significant departure from RFC 2617, which says > nothing about the scope of authentication. It's only a rephrasing of . > (1) Did the WG discuss the compatibility impact of this change? Although > clients might send the Authorization header preemptively, they should > still be prepared to get a 401 response back. > > (2) Did the WG discuss the possibilities for leakage of credentials due > to this change? It's not hard to imagine scenarios where, say, > "http://example.com/~user1" and "http://example.com/~user2" are > controlled by different entities, and leakage between them would be > harmful. > > (3) At the very least, there needs to be (a) a mention of this change in > Appendix A, and (b) a discussion of leakage through unsolicited > Authorization headers in the Security Considerations. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The current text on the use of TLS is an OK start, but I would prefer if > it were refactored so that the recommendation against Basic were general > to HTTP and HTTPS. > > "Because Basic authentication involves the cleartext transmission of > passwords it SHOULD NOT be used except over a secure channel such as > HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic > authentication SHOULD NOT be used to protect sensitive or valuable > information." > > -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From nobody Wed Feb 18 12:46: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 567AB1A1AB1 for ; Wed, 18 Feb 2015 12:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 lB6cVgHMAvBN for ; Wed, 18 Feb 2015 12:46:41 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 92FF61A1A8B for ; Wed, 18 Feb 2015 12:46:35 -0800 (PST) Received: by labgf13 with SMTP id gf13so3753983lab.9 for ; Wed, 18 Feb 2015 12:46:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8NwEE33Hr/4a1B6tePW//Vublg1fDsnyPuPt3ze34co=; b=i+dx3bJjCF+dZN5pQKEUMRD2bgHp9ypPUl14QxHMnW1ujCqf29UxGN4G8x4/V0Ndio ByjUM/jtG8Vv7Hxlmp8p4vsYOByEv9z0fwE7aF0ByNKYcfoeieuzLnIzlsopWU/zoqRZ EmlaQG8b3JDQbViAaodV55vXd+a8xnWi2s2G2jFGkHMP9nilJsH/WdjioajJbSJqeoHa 4KegtTj8lcNiHKHzzq3b7pOlY6GU2Ljy19jVCB9XQpzlZLAyd5bkzFC+jciVrmWb24B2 5Xx0OKfOl7p5ymfDQB798hRPjh+NQu3SZn2tETMFwS4qUAEu0mWya7QswpOarQ6+KiyG 8pfw== X-Gm-Message-State: ALoCoQkEBL2uA0V6CO5xIl97lYMKG9gyXBz3VnvhVVOZI7TgG8cCzIYgdxmdMznxgdiuvZ7Pms3B MIME-Version: 1.0 X-Received: by 10.112.65.196 with SMTP id z4mr1240128lbs.28.1424292394085; Wed, 18 Feb 2015 12:46:34 -0800 (PST) Received: by 10.25.135.4 with HTTP; Wed, 18 Feb 2015 12:46:34 -0800 (PST) In-Reply-To: <54E4ED66.4040100@greenbytes.de> References: <20150218194749.23802.1910.idtracker@ietfa.amsl.com> <54E4ED66.4040100@greenbytes.de> Date: Wed, 18 Feb 2015 15:46:34 -0500 Message-ID: From: Richard Barnes To: Julian Reschke Content-Type: multipart/alternative; boundary=001a1136073a34c626050f62ea71 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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, 18 Feb 2015 20:46:43 -0000 --001a1136073a34c626050f62ea71 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 18, 2015 at 2:52 PM, Julian Reschke < julian.reschke@greenbytes.de> wrote: > On 2015-02-18 20:47, Richard Barnes wrote: > >> Richard Barnes has entered the following ballot position for >> draft-ietf-httpauth-basicauth-update-06: Discuss >> >> 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-basicauth-update/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Section 2.2 seems like a significant departure from RFC 2617, which says >> nothing about the scope of authentication. >> > > It's only a rephrasing of webdav/rfc2617.html#rfc.section.2.p.8>. Ah, thank you. The change in wording stymied my efforts to find the comparable text. It still seems like it would be good to mention this leakage risk in the security considerations. But I've moved this to a COMMENT. > > > (1) Did the WG discuss the compatibility impact of this change? Althoug= h >> clients might send the Authorization header preemptively, they should >> still be prepared to get a 401 response back. >> >> (2) Did the WG discuss the possibilities for leakage of credentials due >> to this change? It's not hard to imagine scenarios where, say, >> "http://example.com/~user1" and "http://example.com/~user2" are >> controlled by different entities, and leakage between them would be >> harmful. >> >> (3) At the very least, there needs to be (a) a mention of this change in >> Appendix A, and (b) a discussion of leakage through unsolicited >> Authorization headers in the Security Considerations. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> The current text on the use of TLS is an OK start, but I would prefer if >> it were refactored so that the recommendation against Basic were general >> to HTTP and HTTPS. >> >> "Because Basic authentication involves the cleartext transmission of >> passwords it SHOULD NOT be used except over a secure channel such as >> HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic >> authentication SHOULD NOT be used to protect sensitive or valuable >> information." >> >> >> > > -- > bytes GmbH, Hafenweg 16, D-48155 M=C3=BCnster, Germany > Amtsgericht M=C3=BCnster: HRB5782 > --001a1136073a34c626050f62ea71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 18, 2015 at 2:52 PM, Julian Reschke <<= a href=3D"mailto:julian.reschke@greenbytes.de" target=3D"_blank">julian.res= chke@greenbytes.de> wrote:
= On 2015-02-18 20:47, Richard Barnes wrote:
Richard Barnes has entered the following ballot position for
draft-ietf-httpauth-basicauth-update-06: Discuss

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/discu= ss-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-basicauth-update/



-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------

Section 2.2 seems like a significant departure from RFC 2617, which says nothing about the scope of authentication.

 It's only a rephrasing of <http://greenbytes.de/t= ech/webdav/rfc2617.html#rfc.section.2.p.8>.

Ah, thank you.=C2=A0 The change in wording stymied my= efforts to find the comparable text.

It still seems like= it would be good to mention this leakage risk in the security consideratio= ns.=C2=A0 But I've moved this to a COMMENT.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


(1) Did the WG discuss the compatibility impact of this change?=C2=A0 Altho= ugh
clients might send the Authorization header preemptively, they should
still be prepared to get a 401 response back.

(2) Did the WG discuss the possibilities for leakage of credentials due
to this change?=C2=A0 It's not hard to imagine scenarios where, say, "http://exampl= e.com/~user1" and "http://example.com/~user2" are
controlled by different entities, and leakage between them would be
harmful.

(3) At the very least, there needs to be (a) a mention of this change in Appendix A, and (b) a discussion of leakage through unsolicited
Authorization headers in the Security Considerations.


-------------------------------------------------------------= ---------
COMMENT:
-------------------------------------------------------------= ---------

The current text on the use of TLS is an OK start, but I would prefer if it were refactored so that the recommendation against Basic were general to HTTP and HTTPS.

"Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used except over a secure channel such as
HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic
authentication SHOULD NOT be used to protect sensitive or valuable
information."




--
<green/>bytes GmbH, Hafenweg 16, D-48155 M=C3=BCnster, Germany
Amtsgericht M=C3=BCnster: HRB5782

--001a1136073a34c626050f62ea71-- From nobody Wed Feb 18 12:46:45 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7E9B21A1A8B; Wed, 18 Feb 2015 12:46:43 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1751A1AB2 for ; Wed, 18 Feb 2015 12:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sUMxhhszpFc for ; Wed, 18 Feb 2015 12:46:40 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 8A5F91A1A8A for ; Wed, 18 Feb 2015 12:46:35 -0800 (PST) Received: by lbiz12 with SMTP id z12so3613816lbi.11 for ; Wed, 18 Feb 2015 12:46:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8NwEE33Hr/4a1B6tePW//Vublg1fDsnyPuPt3ze34co=; b=NPL+qL+K9tu8RjzJKIh1J4X0+dw9Oztoj0bd0SqXSKQwiHKb9rc/UvgkUQua0GEjaW kRQMPwUJyNW9CsIddZXTZ1aOMmXkCJppX4TlHpNRC7Vzh2lrhA5St1yX9uOPZ7ANYJzS ZUEfevtzqBXmenCesqPAk8K1q7w9mpIKnTijRQDMUXxskGJPZQ+OYAkgQH+zqcK5PZlK FK3W0DVxi+BrHyIphHRjp8oCnTyaez0EeA2sXwMflopJLoa+OcRpUKhXRL5e72EicUrL /8CLyP0BoQyXB4/9fZk2CVNOAVUStZEIBI078te7Gs9snwGbUVHvWcu20fqsbsNs8Pus M0xg== X-Gm-Message-State: ALoCoQmL2xuVXvoqRTtFj+7NCr8VGI4jPryeItSsBC6WWSj4bR0+RUXvE5XymMZlLKAPB1avGCBF MIME-Version: 1.0 X-Received: by 10.112.65.196 with SMTP id z4mr1240128lbs.28.1424292394085; Wed, 18 Feb 2015 12:46:34 -0800 (PST) Received: by 10.25.135.4 with HTTP; Wed, 18 Feb 2015 12:46:34 -0800 (PST) In-Reply-To: <54E4ED66.4040100@greenbytes.de> References: <20150218194749.23802.1910.idtracker@ietfa.amsl.com> <54E4ED66.4040100@greenbytes.de> Date: Wed, 18 Feb 2015 15:46:34 -0500 Message-ID: From: Richard Barnes To: Julian Reschke Content-Type: multipart/alternative; boundary=001a1136073a34c626050f62ea71 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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, 18 Feb 2015 20:46:43 -0000 --001a1136073a34c626050f62ea71 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 18, 2015 at 2:52 PM, Julian Reschke < julian.reschke@greenbytes.de> wrote: > On 2015-02-18 20:47, Richard Barnes wrote: > >> Richard Barnes has entered the following ballot position for >> draft-ietf-httpauth-basicauth-update-06: Discuss >> >> 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-basicauth-update/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Section 2.2 seems like a significant departure from RFC 2617, which says >> nothing about the scope of authentication. >> > > It's only a rephrasing of webdav/rfc2617.html#rfc.section.2.p.8>. Ah, thank you. The change in wording stymied my efforts to find the comparable text. It still seems like it would be good to mention this leakage risk in the security considerations. But I've moved this to a COMMENT. > > > (1) Did the WG discuss the compatibility impact of this change? Althoug= h >> clients might send the Authorization header preemptively, they should >> still be prepared to get a 401 response back. >> >> (2) Did the WG discuss the possibilities for leakage of credentials due >> to this change? It's not hard to imagine scenarios where, say, >> "http://example.com/~user1" and "http://example.com/~user2" are >> controlled by different entities, and leakage between them would be >> harmful. >> >> (3) At the very least, there needs to be (a) a mention of this change in >> Appendix A, and (b) a discussion of leakage through unsolicited >> Authorization headers in the Security Considerations. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> The current text on the use of TLS is an OK start, but I would prefer if >> it were refactored so that the recommendation against Basic were general >> to HTTP and HTTPS. >> >> "Because Basic authentication involves the cleartext transmission of >> passwords it SHOULD NOT be used except over a secure channel such as >> HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic >> authentication SHOULD NOT be used to protect sensitive or valuable >> information." >> >> >> > > -- > bytes GmbH, Hafenweg 16, D-48155 M=C3=BCnster, Germany > Amtsgericht M=C3=BCnster: HRB5782 > --001a1136073a34c626050f62ea71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 18, 2015 at 2:52 PM, Julian Reschke <<= a href=3D"mailto:julian.reschke@greenbytes.de" target=3D"_blank">julian.res= chke@greenbytes.de> wrote:
= On 2015-02-18 20:47, Richard Barnes wrote:
Richard Barnes has entered the following ballot position for
draft-ietf-httpauth-basicauth-update-06: Discuss

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/discu= ss-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-basicauth-update/



-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------

Section 2.2 seems like a significant departure from RFC 2617, which says nothing about the scope of authentication.

 It's only a rephrasing of <http://greenbytes.de/t= ech/webdav/rfc2617.html#rfc.section.2.p.8>.

Ah, thank you.=C2=A0 The change in wording stymied my= efforts to find the comparable text.

It still seems like= it would be good to mention this leakage risk in the security consideratio= ns.=C2=A0 But I've moved this to a COMMENT.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


(1) Did the WG discuss the compatibility impact of this change?=C2=A0 Altho= ugh
clients might send the Authorization header preemptively, they should
still be prepared to get a 401 response back.

(2) Did the WG discuss the possibilities for leakage of credentials due
to this change?=C2=A0 It's not hard to imagine scenarios where, say, "http://exampl= e.com/~user1" and "http://example.com/~user2" are
controlled by different entities, and leakage between them would be
harmful.

(3) At the very least, there needs to be (a) a mention of this change in Appendix A, and (b) a discussion of leakage through unsolicited
Authorization headers in the Security Considerations.


-------------------------------------------------------------= ---------
COMMENT:
-------------------------------------------------------------= ---------

The current text on the use of TLS is an OK start, but I would prefer if it were refactored so that the recommendation against Basic were general to HTTP and HTTPS.

"Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used except over a secure channel such as
HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic
authentication SHOULD NOT be used to protect sensitive or valuable
information."




--
<green/>bytes GmbH, Hafenweg 16, D-48155 M=C3=BCnster, Germany
Amtsgericht M=C3=BCnster: HRB5782

--001a1136073a34c626050f62ea71-- From nobody Wed Feb 18 13:49: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 A475A1A1B19; Wed, 18 Feb 2015 13:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-E-zL7U4OSB; Wed, 18 Feb 2015 13:49:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A831A1B47; Wed, 18 Feb 2015 13:49:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 13:49:27 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Wed, 18 Feb 2015 21:49:35 -0000 Pete Resnick has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 2: I'd at least like to hear an explanation about why this is unreasonable (if it is): OLD Furthermore, a user-id containing a colon character is invalid, as recipients will split the user-pass at the first occurrence of a colon character. Note that many user agents however will accept a colon in user-id, thereby producing a user-pass string that recipients will likely treat in a way not intended by the user. NEW Furthermore, a user-id MUST NOT contain a colon character, as recipients will split the user-pass at the first occurrence of a colon character. Many user agents will accept a colon in user-id, but this produces a user-pass string that recipients will likely treat in a way not intended by the user. END MUST NOT means that not using a colon is required for interoperation. Which is true. So I don't see why you don't come out and say that. From nobody Wed Feb 18 13:49:45 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C12091A1B47; Wed, 18 Feb 2015 13:49:35 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A475A1A1B19; Wed, 18 Feb 2015 13:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-E-zL7U4OSB; Wed, 18 Feb 2015 13:49:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A831A1B47; Wed, 18 Feb 2015 13:49:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 13:49:27 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Wed, 18 Feb 2015 21:49:35 -0000 Pete Resnick has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 2: I'd at least like to hear an explanation about why this is unreasonable (if it is): OLD Furthermore, a user-id containing a colon character is invalid, as recipients will split the user-pass at the first occurrence of a colon character. Note that many user agents however will accept a colon in user-id, thereby producing a user-pass string that recipients will likely treat in a way not intended by the user. NEW Furthermore, a user-id MUST NOT contain a colon character, as recipients will split the user-pass at the first occurrence of a colon character. Many user agents will accept a colon in user-id, but this produces a user-pass string that recipients will likely treat in a way not intended by the user. END MUST NOT means that not using a colon is required for interoperation. Which is true. So I don't see why you don't come out and say that. From nobody Wed Feb 18 14:27: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 59E121A1B59; Wed, 18 Feb 2015 14:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cUU_BF147dxo; Wed, 18 Feb 2015 14:27:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 782B21A1B56; Wed, 18 Feb 2015 14:27:17 -0800 (PST) Received: from [192.168.2.175] ([93.217.116.45]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M4nM5-1Xcq2J3nTh-00z2bY; Wed, 18 Feb 2015 23:27:15 +0100 Message-ID: <54E511BF.1070503@gmx.de> Date: Wed, 18 Feb 2015 23:27:11 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick , The IESG References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> In-Reply-To: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0SCswiJUmlOo//am8C7/0pctfacq3ePYrpnw1fNHIw/0dYF455M c/Ip+LNBPOzdN7vfZZbShBxlp31UUeZ637SlsTJAs6ptR+lr8xc0sqfws/USbpk49iEYNnJ BRks9XVn/aB7Kk8c0grQUCbgha+jhmvX7aWu/r1NH6DPq+0dxLM7W+FFWw3T3wuoyy/bCzX fJXm+iOENFeq6E3LgeEFA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 22:27:19 -0000 On 2015-02-18 22:49, Pete Resnick wrote: > ... > ----------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 2: I'd at least like to hear an explanation about why this is > unreasonable (if it is): > > OLD > Furthermore, a user-id containing a colon character is invalid, as > recipients will split the user-pass at the first occurrence of a > colon character. Note that many user agents however will accept a > colon in user-id, thereby producing a user-pass string that > recipients will likely treat in a way not intended by the user. > NEW > Furthermore, a user-id MUST NOT contain a colon character, as > recipients will split the user-pass at the first occurrence of a > colon character. Many user agents will accept a colon in user-id, > but this produces a user-pass string that recipients will likely > treat in a way not intended by the user. > END > > MUST NOT means that not using a colon is required for interoperation. > Which is true. So I don't see why you don't come out and say that. > ... I just tested Firefox, Chrome, and IE. All of them accept colons in user ids and do exactly what the spec currently says. It seems pointless to me to say "MUST NOT" when it's widely implemented that way. In a new protocol I'd prefer and mandate "fail early", but this is not a new protocol. Best regards, Julian From nobody Wed Feb 18 14:27:27 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 84B191A1B5A; Wed, 18 Feb 2015 14:27:19 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E121A1B59; Wed, 18 Feb 2015 14:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cUU_BF147dxo; Wed, 18 Feb 2015 14:27:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 782B21A1B56; Wed, 18 Feb 2015 14:27:17 -0800 (PST) Received: from [192.168.2.175] ([93.217.116.45]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M4nM5-1Xcq2J3nTh-00z2bY; Wed, 18 Feb 2015 23:27:15 +0100 Message-ID: <54E511BF.1070503@gmx.de> Date: Wed, 18 Feb 2015 23:27:11 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick , The IESG References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> In-Reply-To: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0SCswiJUmlOo//am8C7/0pctfacq3ePYrpnw1fNHIw/0dYF455M c/Ip+LNBPOzdN7vfZZbShBxlp31UUeZ637SlsTJAs6ptR+lr8xc0sqfws/USbpk49iEYNnJ BRks9XVn/aB7Kk8c0grQUCbgha+jhmvX7aWu/r1NH6DPq+0dxLM7W+FFWw3T3wuoyy/bCzX fJXm+iOENFeq6E3LgeEFA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 22:27:19 -0000 On 2015-02-18 22:49, Pete Resnick wrote: > ... > ----------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 2: I'd at least like to hear an explanation about why this is > unreasonable (if it is): > > OLD > Furthermore, a user-id containing a colon character is invalid, as > recipients will split the user-pass at the first occurrence of a > colon character. Note that many user agents however will accept a > colon in user-id, thereby producing a user-pass string that > recipients will likely treat in a way not intended by the user. > NEW > Furthermore, a user-id MUST NOT contain a colon character, as > recipients will split the user-pass at the first occurrence of a > colon character. Many user agents will accept a colon in user-id, > but this produces a user-pass string that recipients will likely > treat in a way not intended by the user. > END > > MUST NOT means that not using a colon is required for interoperation. > Which is true. So I don't see why you don't come out and say that. > ... I just tested Firefox, Chrome, and IE. All of them accept colons in user ids and do exactly what the spec currently says. It seems pointless to me to say "MUST NOT" when it's widely implemented that way. In a new protocol I'd prefer and mandate "fail early", but this is not a new protocol. Best regards, Julian From nobody Wed Feb 18 14:36:27 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 A696A1A1AF0; Wed, 18 Feb 2015 14:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WHLEv5C4j52; Wed, 18 Feb 2015 14:36:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 992C71A0102; Wed, 18 Feb 2015 14:36:23 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218223623.27728.42097.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 14:36:23 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-14.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: Wed, 18 Feb 2015 22:36:25 -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-14.txt Pages : 30 Date : 2015-02-18 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-14 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 Wed Feb 18 14:38: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 49B691A1AF4; Wed, 18 Feb 2015 14:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 yQ213jWRU6qY; Wed, 18 Feb 2015 14:38:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 778A31A0252; Wed, 18 Feb 2015 14:38:54 -0800 (PST) Received: from netb ([89.204.137.79]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MF9WR-1YMJi922sl-00GFR2; Wed, 18 Feb 2015 23:38:48 +0100 From: Bjoern Hoehrmann To: "Pete Resnick" Date: Wed, 18 Feb 2015 23:38:46 +0100 Message-ID: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> In-Reply-To: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:hED1M2dZxCIJe/OGUMCWYsUgFIFH4z5k20EOtmYMWowFV6Lo5nu 8HgwY7je1b6M/0cBKzW8mSdns8kLXXx+f8m3s1k2pkpq4XlXP95FWBQBZuLQTjXI+1WBVXA 3IXdmlQAgtRzdbSZRd8z/3xZaepgj7BdAlAH3heML5PRkAZDQbYhPmntFCuk3MnoM0S2Qv3 A3syLOwZnb52IioBVy68w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 22:38:56 -0000 * Pete Resnick wrote: >2: I'd at least like to hear an explanation about why this is >unreasonable (if it is): > >OLD > Furthermore, a user-id containing a colon character is invalid, as > recipients will split the user-pass at the first occurrence of a > colon character. Note that many user agents however will accept a > colon in user-id, thereby producing a user-pass string that > recipients will likely treat in a way not intended by the user. >NEW > Furthermore, a user-id MUST NOT contain a colon character, as > recipients will split the user-pass at the first occurrence of a > colon character. Many user agents will accept a colon in user-id, > but this produces a user-pass string that recipients will likely > treat in a way not intended by the user. >END > >MUST NOT means that not using a colon is required for interoperation. >Which is true. So I don't see why you don't come out and say that. The intent is to say that usernames containing colons are not supported by the scheme because first colon in `user:pass` strings separates the username from the password and there is no escaping mechanism. It would be incorrect to phrase that as a "MUST NOT". -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Wed Feb 18 14:39:03 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6F61B1A1B00; Wed, 18 Feb 2015 14:38:56 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B691A1AF4; Wed, 18 Feb 2015 14:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 yQ213jWRU6qY; Wed, 18 Feb 2015 14:38:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 778A31A0252; Wed, 18 Feb 2015 14:38:54 -0800 (PST) Received: from netb ([89.204.137.79]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MF9WR-1YMJi922sl-00GFR2; Wed, 18 Feb 2015 23:38:48 +0100 From: Bjoern Hoehrmann To: "Pete Resnick" Date: Wed, 18 Feb 2015 23:38:46 +0100 Message-ID: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> In-Reply-To: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:hED1M2dZxCIJe/OGUMCWYsUgFIFH4z5k20EOtmYMWowFV6Lo5nu 8HgwY7je1b6M/0cBKzW8mSdns8kLXXx+f8m3s1k2pkpq4XlXP95FWBQBZuLQTjXI+1WBVXA 3IXdmlQAgtRzdbSZRd8z/3xZaepgj7BdAlAH3heML5PRkAZDQbYhPmntFCuk3MnoM0S2Qv3 A3syLOwZnb52IioBVy68w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 22:38:56 -0000 * Pete Resnick wrote: >2: I'd at least like to hear an explanation about why this is >unreasonable (if it is): > >OLD > Furthermore, a user-id containing a colon character is invalid, as > recipients will split the user-pass at the first occurrence of a > colon character. Note that many user agents however will accept a > colon in user-id, thereby producing a user-pass string that > recipients will likely treat in a way not intended by the user. >NEW > Furthermore, a user-id MUST NOT contain a colon character, as > recipients will split the user-pass at the first occurrence of a > colon character. Many user agents will accept a colon in user-id, > but this produces a user-pass string that recipients will likely > treat in a way not intended by the user. >END > >MUST NOT means that not using a colon is required for interoperation. >Which is true. So I don't see why you don't come out and say that. The intent is to say that usernames containing colons are not supported by the scheme because first colon in `user:pass` strings separates the username from the password and there is no escaping mechanism. It would be incorrect to phrase that as a "MUST NOT". -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Wed Feb 18 14:39:07 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 DD1AA1A1B72; Wed, 18 Feb 2015 14:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HMq9tGCkmIu6; Wed, 18 Feb 2015 14:38:57 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 601DC1A0252; Wed, 18 Feb 2015 14:38:57 -0800 (PST) Received: by lbdu14 with SMTP id u14so4235895lbd.1; Wed, 18 Feb 2015 14:38:55 -0800 (PST) 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=JIF+k9oWPnl383Rc3KnFbxBrdNf3rZT6itzxM2n49Qs=; b=sICwHrDdBH8K6gLJP8C8fYu5LlK4WKMDpiqhX7wrVUV7dnQK1PJ1MpfW4EY67DotK3 JQlpgrFDV2VKj6jA3G3A5ja4rhCVtNh98Rki8YWNI8/3nBT9zJhQU/M3xTGwEUI/WGN6 xedvlPSUEwKs14U5XpcZKMD07gjQCI9bGmrJFogKorsKcELTCin0axmviQVsTF50RN9G 62JRQG3iHySK5V7GRUEot7uUl8+N1ShEBBs7ei1rSjoxtBhsYAqtdUCUIxtp3aUPndRG rDSsIg4p3/esIxCuJfTrvCISGzJ8ZpvHX5vcbvZLLnEfurLjrvtrPkFFdR9clHQqisBX ywzg== MIME-Version: 1.0 X-Received: by 10.152.88.4 with SMTP id bc4mr1469361lab.86.1424299135518; Wed, 18 Feb 2015 14:38:55 -0800 (PST) Received: by 10.114.27.166 with HTTP; Wed, 18 Feb 2015 14:38:55 -0800 (PST) In-Reply-To: <20150218223623.27728.42097.idtracker@ietfa.amsl.com> References: <20150218223623.27728.42097.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 17:38:55 -0500 Message-ID: From: Rifaat Shekh-Yusef To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=001a11c365b406cd58050f647cf5 Archived-At: Cc: "http-auth@ietf.org" , i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-14.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: Wed, 18 Feb 2015 22:39:00 -0000 --001a11c365b406cd58050f647cf5 Content-Type: text/plain; charset=ISO-8859-1 Hi, We believe that with this version we have addressed all the comments received during the WGLC. Regards, Rifaat On Wed, Feb 18, 2015 at 5:36 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-14.txt > Pages : 30 > Date : 2015-02-18 > > 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-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-14 > > > 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 > --001a11c365b406cd58050f647cf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We believe that with this version w= e have addressed all the comments received during the WGLC.

<= /div>
Regards,
=A0Rifaat


On Wed, Feb 18, 2015 at 5:3= 6 PM, <internet-drafts@ietf.org> wrote:

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-14.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-02-18

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-14
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-14


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

--001a11c365b406cd58050f647cf5-- From nobody Wed Feb 18 14:46:52 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 5C6201A1B77; Wed, 18 Feb 2015 14:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 5043smjrasGa; Wed, 18 Feb 2015 14:46:46 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA921A1B60; Wed, 18 Feb 2015 14:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1424299606; x=1455835606; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DfqDOCawDiXwWLDQ9PMFAY2P1KPoOkfI51CHXXe1ycc=; b=js8UgOQxQFc13+af9et8ifxdaj/m9CPL7B5KkndFP1FWMkPry4dwJT4u nNOwKtyFO5xG6m0/zx43QsllVGX5mmxzpteJegMgE3F2Qog6x6jQShuL4 9UxrOeCVLRiaRgzOXyNiF7lBFUMxgMnP5skuqtv0ud5lu0N8kNuShe5BC g=; X-IronPort-AV: E=McAfee;i="5600,1067,7716"; a="84291650" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2015 14:46:45 -0800 X-IronPort-AV: E=Sophos;i="5.09,604,1418112000"; d="scan'208";a="843477552" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Feb 2015 14:46:45 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Feb 2015 14:46:44 -0800 Message-ID: <54E51652.4050301@qti.qualcomm.com> Date: Wed, 18 Feb 2015 16:46:42 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> In-Reply-To: <54E511BF.1070503@gmx.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 22:46:48 -0000 On 2/18/15 4:27 PM, Julian Reschke wrote: >> Furthermore, a user-id containing a colon character is invalid, as >> recipients will split the user-pass at the first occurrence of a >> colon character. Note that many user agents however will accept a >> colon in user-id, thereby producing a user-pass string that >> recipients will likely treat in a way not intended by the user. > > I just tested Firefox, Chrome, and IE. All of them accept colons in > user ids and do exactly what the spec currently says. You mean all of them simply take the user-id, add a colon, add the password, and when the server gets it, the server interprets everything before the first colon as the user-id and (almost always) fails? That is to say, user-ids with colons simply don't work? > It seems pointless to me to say "MUST NOT" when it's widely > implemented that way. In a new protocol I'd prefer and mandate "fail > early", but this is not a new protocol. I guess I'm lost on the distinction between: A user-id containing a colon does not work. and A user-id containing a colon MUST NOT be used. They are semantically identical, AFAICT. "MUST NOT" does not mean the Internet Police will come to take you away. "MUST NOT" means "this won't work". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Feb 18 14:46:53 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 80CBB1A1B79; Wed, 18 Feb 2015 14:46:48 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6201A1B77; Wed, 18 Feb 2015 14:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 5043smjrasGa; Wed, 18 Feb 2015 14:46:46 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA921A1B60; Wed, 18 Feb 2015 14:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1424299606; x=1455835606; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DfqDOCawDiXwWLDQ9PMFAY2P1KPoOkfI51CHXXe1ycc=; b=js8UgOQxQFc13+af9et8ifxdaj/m9CPL7B5KkndFP1FWMkPry4dwJT4u nNOwKtyFO5xG6m0/zx43QsllVGX5mmxzpteJegMgE3F2Qog6x6jQShuL4 9UxrOeCVLRiaRgzOXyNiF7lBFUMxgMnP5skuqtv0ud5lu0N8kNuShe5BC g=; X-IronPort-AV: E=McAfee;i="5600,1067,7716"; a="84291650" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2015 14:46:45 -0800 X-IronPort-AV: E=Sophos;i="5.09,604,1418112000"; d="scan'208";a="843477552" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Feb 2015 14:46:45 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Feb 2015 14:46:44 -0800 Message-ID: <54E51652.4050301@qti.qualcomm.com> Date: Wed, 18 Feb 2015 16:46:42 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> In-Reply-To: <54E511BF.1070503@gmx.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 22:46:48 -0000 On 2/18/15 4:27 PM, Julian Reschke wrote: >> Furthermore, a user-id containing a colon character is invalid, as >> recipients will split the user-pass at the first occurrence of a >> colon character. Note that many user agents however will accept a >> colon in user-id, thereby producing a user-pass string that >> recipients will likely treat in a way not intended by the user. > > I just tested Firefox, Chrome, and IE. All of them accept colons in > user ids and do exactly what the spec currently says. You mean all of them simply take the user-id, add a colon, add the password, and when the server gets it, the server interprets everything before the first colon as the user-id and (almost always) fails? That is to say, user-ids with colons simply don't work? > It seems pointless to me to say "MUST NOT" when it's widely > implemented that way. In a new protocol I'd prefer and mandate "fail > early", but this is not a new protocol. I guess I'm lost on the distinction between: A user-id containing a colon does not work. and A user-id containing a colon MUST NOT be used. They are semantically identical, AFAICT. "MUST NOT" does not mean the Internet Police will come to take you away. "MUST NOT" means "this won't work". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Feb 18 14:55: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 845B11A1B59; Wed, 18 Feb 2015 14:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AzBHwA-fRc5c; Wed, 18 Feb 2015 14:55:03 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39261A1B91; Wed, 18 Feb 2015 14:55:03 -0800 (PST) Received: from [192.168.2.175] (unknown [93.217.116.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id A641015A0237; Wed, 18 Feb 2015 23:55:01 +0100 (CET) Message-ID: <54E51843.1050307@greenbytes.de> Date: Wed, 18 Feb 2015 23:54:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> In-Reply-To: <54E51652.4050301@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 22:55:05 -0000 On 2015-02-18 23:46, Pete Resnick wrote: > On 2/18/15 4:27 PM, Julian Reschke wrote: > >>> Furthermore, a user-id containing a colon character is invalid, as >>> recipients will split the user-pass at the first occurrence of a >>> colon character. Note that many user agents however will accept a >>> colon in user-id, thereby producing a user-pass string that >>> recipients will likely treat in a way not intended by the user. >> >> I just tested Firefox, Chrome, and IE. All of them accept colons in >> user ids and do exactly what the spec currently says. > > You mean all of them simply take the user-id, add a colon, add the > password, and when the server gets it, the server interprets everything > before the first colon as the user-id and (almost always) fails? That is > to say, user-ids with colons simply don't work? That's what these UAs do. I don't know why they do it; perhaps it "works" (for some definition of "works") with some servers. >> It seems pointless to me to say "MUST NOT" when it's widely >> implemented that way. In a new protocol I'd prefer and mandate "fail >> early", but this is not a new protocol. > > I guess I'm lost on the distinction between: > > A user-id containing a colon does not work. I don't say "does not work", but "Note that many user agents however will accept a colon in user-id, thereby producing a user-pass string that recipients will likely treat in a way not intended by the user.". I think that's an accurate description of reality. > and > > A user-id containing a colon MUST NOT be used. > > They are semantically identical, AFAICT. > > "MUST NOT" does not mean the Internet Police will come to take you away. > "MUST NOT" means "this won't work". Ahem, no, that's not what "MUST NOT" means. Best regards, Julian From nobody Wed Feb 18 14:55:11 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A3CBA1A1B94; Wed, 18 Feb 2015 14:55:05 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845B11A1B59; Wed, 18 Feb 2015 14:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AzBHwA-fRc5c; Wed, 18 Feb 2015 14:55:03 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39261A1B91; Wed, 18 Feb 2015 14:55:03 -0800 (PST) Received: from [192.168.2.175] (unknown [93.217.116.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id A641015A0237; Wed, 18 Feb 2015 23:55:01 +0100 (CET) Message-ID: <54E51843.1050307@greenbytes.de> Date: Wed, 18 Feb 2015 23:54:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> In-Reply-To: <54E51652.4050301@qti.qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 22:55:05 -0000 On 2015-02-18 23:46, Pete Resnick wrote: > On 2/18/15 4:27 PM, Julian Reschke wrote: > >>> Furthermore, a user-id containing a colon character is invalid, as >>> recipients will split the user-pass at the first occurrence of a >>> colon character. Note that many user agents however will accept a >>> colon in user-id, thereby producing a user-pass string that >>> recipients will likely treat in a way not intended by the user. >> >> I just tested Firefox, Chrome, and IE. All of them accept colons in >> user ids and do exactly what the spec currently says. > > You mean all of them simply take the user-id, add a colon, add the > password, and when the server gets it, the server interprets everything > before the first colon as the user-id and (almost always) fails? That is > to say, user-ids with colons simply don't work? That's what these UAs do. I don't know why they do it; perhaps it "works" (for some definition of "works") with some servers. >> It seems pointless to me to say "MUST NOT" when it's widely >> implemented that way. In a new protocol I'd prefer and mandate "fail >> early", but this is not a new protocol. > > I guess I'm lost on the distinction between: > > A user-id containing a colon does not work. I don't say "does not work", but "Note that many user agents however will accept a colon in user-id, thereby producing a user-pass string that recipients will likely treat in a way not intended by the user.". I think that's an accurate description of reality. > and > > A user-id containing a colon MUST NOT be used. > > They are semantically identical, AFAICT. > > "MUST NOT" does not mean the Internet Police will come to take you away. > "MUST NOT" means "this won't work". Ahem, no, that's not what "MUST NOT" means. Best regards, Julian From nobody Wed Feb 18 15:43:09 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 AC5CB1A1AF4; Wed, 18 Feb 2015 15:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 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, RCVD_IN_DNSWL_LOW=-0.7, 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 3wTIqWa4mGDX; Wed, 18 Feb 2015 15:43:04 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 729D51A0167; Wed, 18 Feb 2015 15:43:00 -0800 (PST) Received: by lams18 with SMTP id s18so4567557lam.11; Wed, 18 Feb 2015 15:42:59 -0800 (PST) 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=ydHVUs8iYXW3lkJXqDo5r8PZ776K18x22zqOCK3fGoc=; b=BmZSIifFOHXSzcCaOy3mP2xAI3FkTpGNakCGYvx/1CQ+yx9wCcEGicWJoooIBCuEai 3u8X0QmdvgaHBSfsu5d2HrOCQSUgaZVhUB6NuU1A0jUpPevbzjbImyb3L0NcVJ7KU0Qk eBeLMP6Eycdk0bXVkkiIH+2x0kv616wdS984I1745Mcs2HFibIxon4tebUhrf2EroDAW JTkVWtrItFKcjBzN8ApR6hAWyGsL9J6kFjeFYXunbM/r18/At1FJKvUEioiajfS5uGZi NvTOUQ6rE71E48Kh/b6T4U9CsfioH/2vA0Qy6FFdNDTUqLVHDUVhje/nPO8v4pK4+FRE ncXQ== MIME-Version: 1.0 X-Received: by 10.112.167.231 with SMTP id zr7mr1448217lbb.123.1424302979038; Wed, 18 Feb 2015 15:42:59 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Wed, 18 Feb 2015 15:42:58 -0800 (PST) In-Reply-To: <54E51843.1050307@greenbytes.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> Date: Wed, 18 Feb 2015 15:42:58 -0800 X-Google-Sender-Auth: kmJ1LCbrn5KgLAd4vnyAE3zU_SQ Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 23:43:05 -0000 >> "MUST NOT" does not mean the Internet Police will come to take you away. >> "MUST NOT" means "this won't work". > > Ahem, no, that's not what "MUST NOT" means. It is, modulo rhetoric. It's an interoperability requirement. "You MUST NOT do ," means that if you do , you will not interoperate -- something will break. It seems to me that that's exactly the case here: If my username is "b:leiba", and a client sends "b:leiba:plugh", many servers will think the username is "b" and the password is "leiba:plugh". That means that allowing ":" in the username breaks interoperability. Whether or not it works sometimes, and whether or not implementations currently *do* this are irrelevant. The point is that the right definition of the protocol is that you "MUST NOT have a colon character in the username." Barry From nobody Wed Feb 18 15:43:10 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CD3971A0167; Wed, 18 Feb 2015 15:43:05 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5CB1A1AF4; Wed, 18 Feb 2015 15:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 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, RCVD_IN_DNSWL_LOW=-0.7, 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 3wTIqWa4mGDX; Wed, 18 Feb 2015 15:43:04 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 729D51A0167; Wed, 18 Feb 2015 15:43:00 -0800 (PST) Received: by lams18 with SMTP id s18so4567557lam.11; Wed, 18 Feb 2015 15:42:59 -0800 (PST) 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=ydHVUs8iYXW3lkJXqDo5r8PZ776K18x22zqOCK3fGoc=; b=BmZSIifFOHXSzcCaOy3mP2xAI3FkTpGNakCGYvx/1CQ+yx9wCcEGicWJoooIBCuEai 3u8X0QmdvgaHBSfsu5d2HrOCQSUgaZVhUB6NuU1A0jUpPevbzjbImyb3L0NcVJ7KU0Qk eBeLMP6Eycdk0bXVkkiIH+2x0kv616wdS984I1745Mcs2HFibIxon4tebUhrf2EroDAW JTkVWtrItFKcjBzN8ApR6hAWyGsL9J6kFjeFYXunbM/r18/At1FJKvUEioiajfS5uGZi NvTOUQ6rE71E48Kh/b6T4U9CsfioH/2vA0Qy6FFdNDTUqLVHDUVhje/nPO8v4pK4+FRE ncXQ== MIME-Version: 1.0 X-Received: by 10.112.167.231 with SMTP id zr7mr1448217lbb.123.1424302979038; Wed, 18 Feb 2015 15:42:59 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Wed, 18 Feb 2015 15:42:58 -0800 (PST) In-Reply-To: <54E51843.1050307@greenbytes.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> Date: Wed, 18 Feb 2015 15:42:58 -0800 X-Google-Sender-Auth: kmJ1LCbrn5KgLAd4vnyAE3zU_SQ Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 18 Feb 2015 23:43:06 -0000 >> "MUST NOT" does not mean the Internet Police will come to take you away. >> "MUST NOT" means "this won't work". > > Ahem, no, that's not what "MUST NOT" means. It is, modulo rhetoric. It's an interoperability requirement. "You MUST NOT do ," means that if you do , you will not interoperate -- something will break. It seems to me that that's exactly the case here: If my username is "b:leiba", and a client sends "b:leiba:plugh", many servers will think the username is "b" and the password is "leiba:plugh". That means that allowing ":" in the username breaks interoperability. Whether or not it works sometimes, and whether or not implementations currently *do* this are irrelevant. The point is that the right definition of the protocol is that you "MUST NOT have a colon character in the username." Barry From nobody Wed Feb 18 17:08:54 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 98EAA1A1BC8; Wed, 18 Feb 2015 17:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 d3TZe2HEjrhe; Wed, 18 Feb 2015 17:08:51 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8067E1A1BBC; Wed, 18 Feb 2015 17:08:51 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 40AC267406A; Wed, 18 Feb 2015 17:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=cTA8zWLxAPKqYS+/KrDWa9xhH0U=; b=ZWQP3uZfVQeBMGeYSjk8BgOtrcNG PjKgaanlYn/SRXGcllUJC0m+yGDVJULtj+fPAlZJIJc29KSzstI3Tn22Tn/ilpdi vqRlBcboPj4de1B4B2iw2XWWUDn3YNzg4FcX5cPTQZPybS5Oih/xhypbWhQOPM2s iD7oFi+n5ngPa7M= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 08FAE674059; Wed, 18 Feb 2015 17:08:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <20150218194656.23776.44631.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 17:08:50 -0800 Content-Transfer-Encoding: 7bit Message-Id: <925022E5-F72D-4973-B262-934E367B76F9@gbiv.com> References: <20150218194656.23776.44631.idtracker@ietfa.amsl.com> To: Richard Barnes X-Mailer: Apple Mail (2.1283) Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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: Thu, 19 Feb 2015 01:08:53 -0000 On Feb 18, 2015, at 11:46 AM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-httpauth-basicauth-update-06: Discuss > > 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-basicauth-update/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2.2 seems like a significant departure from RFC 2617, which says > nothing about the scope of authentication. Please see "http://tools.ietf.org/html/rfc2616#section-14.8" > (1) Did the WG discuss the compatibility impact of this change? Although > clients might send the Authorization header preemptively, they should > still be prepared to get a 401 response back. > > (2) Did the WG discuss the possibilities for leakage of credentials due > to this change? It's not hard to imagine scenarios where, say, > "http://example.com/~user1" and "http://example.com/~user2" are > controlled by different entities, and leakage between them would be > harmful. > > (3) At the very least, there needs to be (a) a mention of this change in > Appendix A, and (b) a discussion of leakage through unsolicited > Authorization headers in the Security Considerations. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The current text on the use of TLS is an OK start, but I would prefer if > it were refactored so that the recommendation against Basic were general > to HTTP and HTTPS. > > "Because Basic authentication involves the cleartext transmission of > passwords it SHOULD NOT be used except over a secure channel such as > HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic > authentication SHOULD NOT be used to protect sensitive or valuable > information." The secure channel would be "such as authenticated TLS", not HTTPS; it doesn't matter what scheme is used. Also, the last sentence is inappropriate and pointless. Historically (and currently), Basic authentication has been necessary for environments where the end authentication mechanism is controlled by a downstream server that uses legacy accounts and passwords. Hence, the Web server (acting as a gateway to that service) needs the actual credentials as plain text in order for the user to be authenticated. However unfortunate that may be in practice, it is an administrative decision and not a protocol one, and the risk of compromise is not much greater than any other mechanism that involves a user typing a secret key into a piece of software that they don't completely control (like a browser dialog). Encouraging admins to use better authentication mechanisms when possible is fine, but that doesn't translate into a general SHOULD NOT use this one. ....Roy From nobody Wed Feb 18 17:09:05 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B8EF11A1C00; Wed, 18 Feb 2015 17:08:53 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EAA1A1BC8; Wed, 18 Feb 2015 17:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 d3TZe2HEjrhe; Wed, 18 Feb 2015 17:08:51 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8067E1A1BBC; Wed, 18 Feb 2015 17:08:51 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 40AC267406A; Wed, 18 Feb 2015 17:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=cTA8zWLxAPKqYS+/KrDWa9xhH0U=; b=ZWQP3uZfVQeBMGeYSjk8BgOtrcNG PjKgaanlYn/SRXGcllUJC0m+yGDVJULtj+fPAlZJIJc29KSzstI3Tn22Tn/ilpdi vqRlBcboPj4de1B4B2iw2XWWUDn3YNzg4FcX5cPTQZPybS5Oih/xhypbWhQOPM2s iD7oFi+n5ngPa7M= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 08FAE674059; Wed, 18 Feb 2015 17:08:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <20150218194656.23776.44631.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 17:08:50 -0800 Content-Transfer-Encoding: 7bit Message-Id: <925022E5-F72D-4973-B262-934E367B76F9@gbiv.com> References: <20150218194656.23776.44631.idtracker@ietfa.amsl.com> To: Richard Barnes X-Mailer: Apple Mail (2.1283) Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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: Thu, 19 Feb 2015 01:08:53 -0000 On Feb 18, 2015, at 11:46 AM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-httpauth-basicauth-update-06: Discuss > > 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-basicauth-update/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2.2 seems like a significant departure from RFC 2617, which says > nothing about the scope of authentication. Please see "http://tools.ietf.org/html/rfc2616#section-14.8" > (1) Did the WG discuss the compatibility impact of this change? Although > clients might send the Authorization header preemptively, they should > still be prepared to get a 401 response back. > > (2) Did the WG discuss the possibilities for leakage of credentials due > to this change? It's not hard to imagine scenarios where, say, > "http://example.com/~user1" and "http://example.com/~user2" are > controlled by different entities, and leakage between them would be > harmful. > > (3) At the very least, there needs to be (a) a mention of this change in > Appendix A, and (b) a discussion of leakage through unsolicited > Authorization headers in the Security Considerations. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The current text on the use of TLS is an OK start, but I would prefer if > it were refactored so that the recommendation against Basic were general > to HTTP and HTTPS. > > "Because Basic authentication involves the cleartext transmission of > passwords it SHOULD NOT be used except over a secure channel such as > HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic > authentication SHOULD NOT be used to protect sensitive or valuable > information." The secure channel would be "such as authenticated TLS", not HTTPS; it doesn't matter what scheme is used. Also, the last sentence is inappropriate and pointless. Historically (and currently), Basic authentication has been necessary for environments where the end authentication mechanism is controlled by a downstream server that uses legacy accounts and passwords. Hence, the Web server (acting as a gateway to that service) needs the actual credentials as plain text in order for the user to be authenticated. However unfortunate that may be in practice, it is an administrative decision and not a protocol one, and the risk of compromise is not much greater than any other mechanism that involves a user typing a secret key into a piece of software that they don't completely control (like a browser dialog). Encouraging admins to use better authentication mechanisms when possible is fine, but that doesn't translate into a general SHOULD NOT use this one. ....Roy From nobody Wed Feb 18 17:16:19 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 797901A2130; Wed, 18 Feb 2015 17:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dOzAceiW4sFa; Wed, 18 Feb 2015 17:16:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 773391A212A; Wed, 18 Feb 2015 17:16:12 -0800 (PST) Received: from netb ([89.204.137.79]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MBZ9u-1YEsKe1mII-00AU3d; Thu, 19 Feb 2015 02:16:02 +0100 From: Bjoern Hoehrmann To: Barry Leiba Date: Thu, 19 Feb 2015 02:15:57 +0100 Message-ID: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ikz6Ohb/nsf9S7gL85/F8zkgcXIwZCkR74QSTvX97CdFq+jhIVy HOsqOGDJJAPRBO+ebl5c+vaI7Y3nzCJFvM06F8kdDjKbujh4HxRfmRzqzA5m8deMDytQlL4 OWfZ839MXyN/8ZfmMD0TKUrHG63yl5O0ZCcGNuKIDCHzNs0s2V5tTIXb+yIP2hFgoTV7gh3 IHTadUqFMDW1OR0XVIzHA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Julian Reschke , Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 01:16:15 -0000 * Barry Leiba wrote: >>> "MUST NOT" does not mean the Internet Police will come to take you away. >>> "MUST NOT" means "this won't work". >> >> Ahem, no, that's not what "MUST NOT" means. > >It is, modulo rhetoric. It's an interoperability requirement. "You >MUST NOT do ," means that if you do , you will not interoperate >-- something will break. It seems to me that that's exactly the case >here: If my username is "b:leiba", and a client sends "b:leiba:plugh", >many servers will think the username is "b" and the password is >"leiba:plugh". That means that allowing ":" in the username breaks >interoperability. Whether or not it works sometimes, and whether or >not implementations currently *do* this are irrelevant. The point is >that the right definition of the protocol is that you "MUST NOT have a >colon character in the username." So, a browser shows a user a prompt like Username: _______________ Password: _______________ User enters Username $user and Password $pass and the browser sends Authorization: Basic base64(utf8_encode(concat($user, ':', $pass))) And then the server interprets that as Username $u and Password $p. A couple of scenarios: a) Browsers abort the process above if $user contains `:` b) Browsers abort the process above if $pass contains `:` c) `Authorization` headers does not conform to the draft if concat($user, ':', $pass) contains more than one colon d) $u != $user e) $p != $pass As it is, the draft does not require a); b) would be non-compliant; c) is false; d) and e) can happen without violating requirements of the specification due to colons alone. The text suggested by Pete Resnick restricts, in the model above, the contents of `$user`, without clear implications for browsers or servers or header field value validity. What is it actually that people want here? Should browsers be required to check user input for colons? Is it okay that the draft requires support for colons in passwords, but does not require servers to interpret `b:leiba:plugh` as having a password of `leiba:plugh`? Perhaps encoded `user:pass` strings in `Basic` headers should be non-conforming if they contain more than one colon? -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Wed Feb 18 17:16:20 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B21DA1A3BA1; Wed, 18 Feb 2015 17:16:15 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797901A2130; Wed, 18 Feb 2015 17:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dOzAceiW4sFa; Wed, 18 Feb 2015 17:16:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 773391A212A; Wed, 18 Feb 2015 17:16:12 -0800 (PST) Received: from netb ([89.204.137.79]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MBZ9u-1YEsKe1mII-00AU3d; Thu, 19 Feb 2015 02:16:02 +0100 From: Bjoern Hoehrmann To: Barry Leiba Date: Thu, 19 Feb 2015 02:15:57 +0100 Message-ID: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ikz6Ohb/nsf9S7gL85/F8zkgcXIwZCkR74QSTvX97CdFq+jhIVy HOsqOGDJJAPRBO+ebl5c+vaI7Y3nzCJFvM06F8kdDjKbujh4HxRfmRzqzA5m8deMDytQlL4 OWfZ839MXyN/8ZfmMD0TKUrHG63yl5O0ZCcGNuKIDCHzNs0s2V5tTIXb+yIP2hFgoTV7gh3 IHTadUqFMDW1OR0XVIzHA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Julian Reschke , Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 01:16:15 -0000 * Barry Leiba wrote: >>> "MUST NOT" does not mean the Internet Police will come to take you away. >>> "MUST NOT" means "this won't work". >> >> Ahem, no, that's not what "MUST NOT" means. > >It is, modulo rhetoric. It's an interoperability requirement. "You >MUST NOT do ," means that if you do , you will not interoperate >-- something will break. It seems to me that that's exactly the case >here: If my username is "b:leiba", and a client sends "b:leiba:plugh", >many servers will think the username is "b" and the password is >"leiba:plugh". That means that allowing ":" in the username breaks >interoperability. Whether or not it works sometimes, and whether or >not implementations currently *do* this are irrelevant. The point is >that the right definition of the protocol is that you "MUST NOT have a >colon character in the username." So, a browser shows a user a prompt like Username: _______________ Password: _______________ User enters Username $user and Password $pass and the browser sends Authorization: Basic base64(utf8_encode(concat($user, ':', $pass))) And then the server interprets that as Username $u and Password $p. A couple of scenarios: a) Browsers abort the process above if $user contains `:` b) Browsers abort the process above if $pass contains `:` c) `Authorization` headers does not conform to the draft if concat($user, ':', $pass) contains more than one colon d) $u != $user e) $p != $pass As it is, the draft does not require a); b) would be non-compliant; c) is false; d) and e) can happen without violating requirements of the specification due to colons alone. The text suggested by Pete Resnick restricts, in the model above, the contents of `$user`, without clear implications for browsers or servers or header field value validity. What is it actually that people want here? Should browsers be required to check user input for colons? Is it okay that the draft requires support for colons in passwords, but does not require servers to interpret `b:leiba:plugh` as having a password of `leiba:plugh`? Perhaps encoded `user:pass` strings in `Basic` headers should be non-conforming if they contain more than one colon? -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Wed Feb 18 17:23: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 C1C661A1AE3; Wed, 18 Feb 2015 17:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 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, RCVD_IN_DNSWL_LOW=-0.7, 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 iDOxfspy18wV; Wed, 18 Feb 2015 17:23:17 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 A9FCD1A2130; Wed, 18 Feb 2015 17:23:16 -0800 (PST) Received: by lbiz11 with SMTP id z11so4737841lbi.5; Wed, 18 Feb 2015 17:23:15 -0800 (PST) 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=aLVw7J7Mr1x2Qg7+MQdGyuZY6FwIQtrhmKMVohIkH+4=; b=bI0uTShqXdJ6vsKyooAd2zkH2mn3IElsDCQtq4A4YPG2wZ+7DbfoPm9Z+LbSKz9Ju3 FfFe4i4ZtJGOuXJiNUFK/7RiHU6hxzyMc8nNunR/hrG4iFRMuXiJqimJ19B7GxI61iCw IL2hyRANIsBqOylHbMvnEPi9HXBxAAkVeayknretxEYGntLSBwtLnlzvenatZxAibz7v XEpOmdqbWL7O7mLpsIeLcY9+XPSihKvpeNprjRRv83r8Ph47sQRjOnTuJCSV9vG0LTfa pqrQ0+69fqAMMIS3dtZ16bw6GGPzqJhPmv1aB5Ro+CkJDwL/TrccSVq59J4NQWDcDGM3 3fsw== MIME-Version: 1.0 X-Received: by 10.152.206.7 with SMTP id lk7mr1722843lac.37.1424308995276; Wed, 18 Feb 2015 17:23:15 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Wed, 18 Feb 2015 17:23:15 -0800 (PST) In-Reply-To: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> Date: Wed, 18 Feb 2015 17:23:15 -0800 X-Google-Sender-Auth: hpL3rLuhwZM-9yUeNKSotq9j18Q Message-ID: From: Barry Leiba To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Julian Reschke , Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 01:23:18 -0000 >>It is, modulo rhetoric. It's an interoperability requirement. "You >>MUST NOT do ," means that if you do , you will not interoperate >>-- something will break. It seems to me that that's exactly the case >>here: If my username is "b:leiba", and a client sends "b:leiba:plugh", >>many servers will think the username is "b" and the password is >>"leiba:plugh". That means that allowing ":" in the username breaks >>interoperability. Whether or not it works sometimes, and whether or >>not implementations currently *do* this are irrelevant. The point is >>that the right definition of the protocol is that you "MUST NOT have a >>colon character in the username." ... > The text suggested by Pete Resnick restricts, in the model above, the > contents of `$user`, without clear implications for browsers or servers > or header field value validity. What is it actually that people want > here? Should browsers be required to check user input for colons? Is it > okay that the draft requires support for colons in passwords, but does > not require servers to interpret `b:leiba:plugh` as having a password of > `leiba:plugh`? Perhaps encoded `user:pass` strings in `Basic` headers > should be non-conforming if they contain more than one colon? The bottom line here is that we aren't police, and there are no consequences for "not conforming". If, in fact, usernames that contain colons cause interop problems, what we *should do* in writing the protocol is to say that usernames MUST NOT contain colons. If, despite that, browsers don't check user input, and send usernames with colons, then the answer is that when they do that they're likely not to get the results they expect, because that's not valid in the protocol. And if someone complains that things broke as a result, everyone can explain why: having the colon in the username is a protocol violation. I don't understand what the argument is about here, because I don't *think* anyone is arguing that colons *should* be allowed. I think the only argument is that sometimes colons *are* sent. I don't see that that matters. Barry From nobody Wed Feb 18 17:23:25 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E1AAE1A3BA2; Wed, 18 Feb 2015 17:23:18 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C661A1AE3; Wed, 18 Feb 2015 17:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 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, RCVD_IN_DNSWL_LOW=-0.7, 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 iDOxfspy18wV; Wed, 18 Feb 2015 17:23:17 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 A9FCD1A2130; Wed, 18 Feb 2015 17:23:16 -0800 (PST) Received: by lbiz11 with SMTP id z11so4737841lbi.5; Wed, 18 Feb 2015 17:23:15 -0800 (PST) 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=aLVw7J7Mr1x2Qg7+MQdGyuZY6FwIQtrhmKMVohIkH+4=; b=bI0uTShqXdJ6vsKyooAd2zkH2mn3IElsDCQtq4A4YPG2wZ+7DbfoPm9Z+LbSKz9Ju3 FfFe4i4ZtJGOuXJiNUFK/7RiHU6hxzyMc8nNunR/hrG4iFRMuXiJqimJ19B7GxI61iCw IL2hyRANIsBqOylHbMvnEPi9HXBxAAkVeayknretxEYGntLSBwtLnlzvenatZxAibz7v XEpOmdqbWL7O7mLpsIeLcY9+XPSihKvpeNprjRRv83r8Ph47sQRjOnTuJCSV9vG0LTfa pqrQ0+69fqAMMIS3dtZ16bw6GGPzqJhPmv1aB5Ro+CkJDwL/TrccSVq59J4NQWDcDGM3 3fsw== MIME-Version: 1.0 X-Received: by 10.152.206.7 with SMTP id lk7mr1722843lac.37.1424308995276; Wed, 18 Feb 2015 17:23:15 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Wed, 18 Feb 2015 17:23:15 -0800 (PST) In-Reply-To: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> Date: Wed, 18 Feb 2015 17:23:15 -0800 X-Google-Sender-Auth: hpL3rLuhwZM-9yUeNKSotq9j18Q Message-ID: From: Barry Leiba To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Julian Reschke , Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 01:23:19 -0000 >>It is, modulo rhetoric. It's an interoperability requirement. "You >>MUST NOT do ," means that if you do , you will not interoperate >>-- something will break. It seems to me that that's exactly the case >>here: If my username is "b:leiba", and a client sends "b:leiba:plugh", >>many servers will think the username is "b" and the password is >>"leiba:plugh". That means that allowing ":" in the username breaks >>interoperability. Whether or not it works sometimes, and whether or >>not implementations currently *do* this are irrelevant. The point is >>that the right definition of the protocol is that you "MUST NOT have a >>colon character in the username." ... > The text suggested by Pete Resnick restricts, in the model above, the > contents of `$user`, without clear implications for browsers or servers > or header field value validity. What is it actually that people want > here? Should browsers be required to check user input for colons? Is it > okay that the draft requires support for colons in passwords, but does > not require servers to interpret `b:leiba:plugh` as having a password of > `leiba:plugh`? Perhaps encoded `user:pass` strings in `Basic` headers > should be non-conforming if they contain more than one colon? The bottom line here is that we aren't police, and there are no consequences for "not conforming". If, in fact, usernames that contain colons cause interop problems, what we *should do* in writing the protocol is to say that usernames MUST NOT contain colons. If, despite that, browsers don't check user input, and send usernames with colons, then the answer is that when they do that they're likely not to get the results they expect, because that's not valid in the protocol. And if someone complains that things broke as a result, everyone can explain why: having the colon in the username is a protocol violation. I don't understand what the argument is about here, because I don't *think* anyone is arguing that colons *should* be allowed. I think the only argument is that sometimes colons *are* sent. I don't see that that matters. Barry From nobody Wed Feb 18 22:27:54 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 7AE4E1A1A0C; Wed, 18 Feb 2015 22:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 qaCB4_9OKB-P; Wed, 18 Feb 2015 22:27:53 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (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 B9E571A1A06; Wed, 18 Feb 2015 22:27:52 -0800 (PST) Received: by wesw55 with SMTP id w55so5335094wes.4; Wed, 18 Feb 2015 22:27:51 -0800 (PST) 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=DUDUobUWn9c6HrpFXa2I6VXYvnW62aIguhIhJpmZ4eo=; b=u/ioJkCWQsJqLAeeTG1F44b4Lzwk0Y5RLr96xY1BvZ4kA7VHoF4atfzeV7UL73+8nA SC3cIyaCRm0YFyLpzXvD8MwjxA87GfHNhxZlYFI29Ams6LclQoBKhcwM4YILJa0ONpd0 hIFbrmQPFZ0vFsLIyyzH6EmON0Nek3mPgodJPMeOFH8EqGdUj+ZKzFnM3FQe6ZPXgcLJ sXD+a8ZauIwlexKeLtMDxwbLbFEBo0ZInZMoOsEGFECOF4jvkGAsIvr2KfhXn+QXd2lV ptKpCvxrA38BMVcVxGac2YqAxmZVKtfW5Oc3pv/CwrZ1vbyZ4naFCZCeJIpJ5BL9msiQ qTgQ== X-Received: by 10.181.13.146 with SMTP id ey18mr3707724wid.84.1424327271522; Wed, 18 Feb 2015 22:27:51 -0800 (PST) Received: from [10.5.8.176] ([80.179.9.7]) by mx.google.com with ESMTPSA id ub1sm35882322wjc.43.2015.02.18.22.27.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Feb 2015 22:27:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <925022E5-F72D-4973-B262-934E367B76F9@gbiv.com> Date: Thu, 19 Feb 2015 08:27:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C7024B5-E15E-400F-8CAF-D4B6DBF1B172@gmail.com> References: <20150218194656.23776.44631.idtracker@ietfa.amsl.com> <925022E5-F72D-4973-B262-934E367B76F9@gbiv.com> To: "Roy T. Fielding" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Richard Barnes , httpauth-chairs@ietf.org, http-auth@ietf.org, The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth@ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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: Thu, 19 Feb 2015 06:27:54 -0000 > On Feb 19, 2015, at 3:08 AM, Roy T. Fielding = wrote: >=20 >> "Because Basic authentication involves the cleartext transmission of >> passwords it SHOULD NOT be used except over a secure channel such as >> HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic >> authentication SHOULD NOT be used to protect sensitive or valuable >> information." >=20 > The secure channel would be "such as authenticated TLS", not HTTPS; > it doesn't matter what scheme is used. Also, the last sentence is > inappropriate and pointless. >=20 > Historically (and currently), Basic authentication has been necessary > for environments where the end authentication mechanism is controlled > by a downstream server that uses legacy accounts and passwords. = Hence, > the Web server (acting as a gateway to that service) needs the actual > credentials as plain text in order for the user to be authenticated. I think it can be argued that this is a better arrangement then placing = a database of passwords or password equivalents directly on a = web-connected server. Yoav From nobody Wed Feb 18 22:28:03 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A866A1A1A06; Wed, 18 Feb 2015 22:27:54 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE4E1A1A0C; Wed, 18 Feb 2015 22:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 qaCB4_9OKB-P; Wed, 18 Feb 2015 22:27:53 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (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 B9E571A1A06; Wed, 18 Feb 2015 22:27:52 -0800 (PST) Received: by wesw55 with SMTP id w55so5335094wes.4; Wed, 18 Feb 2015 22:27:51 -0800 (PST) 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=DUDUobUWn9c6HrpFXa2I6VXYvnW62aIguhIhJpmZ4eo=; b=u/ioJkCWQsJqLAeeTG1F44b4Lzwk0Y5RLr96xY1BvZ4kA7VHoF4atfzeV7UL73+8nA SC3cIyaCRm0YFyLpzXvD8MwjxA87GfHNhxZlYFI29Ams6LclQoBKhcwM4YILJa0ONpd0 hIFbrmQPFZ0vFsLIyyzH6EmON0Nek3mPgodJPMeOFH8EqGdUj+ZKzFnM3FQe6ZPXgcLJ sXD+a8ZauIwlexKeLtMDxwbLbFEBo0ZInZMoOsEGFECOF4jvkGAsIvr2KfhXn+QXd2lV ptKpCvxrA38BMVcVxGac2YqAxmZVKtfW5Oc3pv/CwrZ1vbyZ4naFCZCeJIpJ5BL9msiQ qTgQ== X-Received: by 10.181.13.146 with SMTP id ey18mr3707724wid.84.1424327271522; Wed, 18 Feb 2015 22:27:51 -0800 (PST) Received: from [10.5.8.176] ([80.179.9.7]) by mx.google.com with ESMTPSA id ub1sm35882322wjc.43.2015.02.18.22.27.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Feb 2015 22:27:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <925022E5-F72D-4973-B262-934E367B76F9@gbiv.com> Date: Thu, 19 Feb 2015 08:27:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C7024B5-E15E-400F-8CAF-D4B6DBF1B172@gmail.com> References: <20150218194656.23776.44631.idtracker@ietfa.amsl.com> <925022E5-F72D-4973-B262-934E367B76F9@gbiv.com> To: "Roy T. Fielding" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Richard Barnes , httpauth-chairs@ietf.org, http-auth@ietf.org, The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth@ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and 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: Thu, 19 Feb 2015 06:27:54 -0000 > On Feb 19, 2015, at 3:08 AM, Roy T. Fielding = wrote: >=20 >> "Because Basic authentication involves the cleartext transmission of >> passwords it SHOULD NOT be used except over a secure channel such as >> HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic >> authentication SHOULD NOT be used to protect sensitive or valuable >> information." >=20 > The secure channel would be "such as authenticated TLS", not HTTPS; > it doesn't matter what scheme is used. Also, the last sentence is > inappropriate and pointless. >=20 > Historically (and currently), Basic authentication has been necessary > for environments where the end authentication mechanism is controlled > by a downstream server that uses legacy accounts and passwords. = Hence, > the Web server (acting as a gateway to that service) needs the actual > credentials as plain text in order for the user to be authenticated. I think it can be argued that this is a better arrangement then placing = a database of passwords or password equivalents directly on a = web-connected server. Yoav From nobody Wed Feb 18 23:15:55 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 A1E9F1A8882; Wed, 18 Feb 2015 23:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uPQeyAyv4-Zj; Wed, 18 Feb 2015 23:15:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 AEAD71A870F; Wed, 18 Feb 2015 23:15:52 -0800 (PST) Received: from [192.168.2.175] ([93.217.116.45]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MWCgz-1Y4Ndh3jK5-00XLlv; Thu, 19 Feb 2015 08:15:45 +0100 Message-ID: <54E58D9C.5020207@gmx.de> Date: Thu, 19 Feb 2015 08:15:40 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Barry Leiba , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8jCpegMSNWXoBoGjV0uKT7wfkE34a1WQvnTJQpsW4Rc88BjzvtF XMu2E4MpaTghTVhz0a6fgLRsZOqP5ai9+oxSmtR1bd87sX8Ohaf1eZG90Ys93uNm8svT5rh /5LYZW3chweOKKjVGeCHuGzsZXEa5OG9EJwq40eKGeenqoBBpwwWJq+Vf40RSDP0Vk3kuDo c+mLvDBKRXMTQ90nwxAqQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Pete Resnick , "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 07:15:54 -0000 On 2015-02-19 00:42, Barry Leiba wrote: >>> "MUST NOT" does not mean the Internet Police will come to take you away. >>> "MUST NOT" means "this won't work". >> >> Ahem, no, that's not what "MUST NOT" means. > > It is, modulo rhetoric. It's an interoperability requirement. "You > MUST NOT do ," means that if you do , you will not interoperate > -- something will break. It seems to me that that's exactly the case > here: If my username is "b:leiba", and a client sends "b:leiba:plugh", > many servers will think the username is "b" and the password is > "leiba:plugh". That means that allowing ":" in the username breaks > interoperability. Whether or not it works sometimes, and whether or Allowing colons in usernames when usernames are assigned is a problem. We already say these names are invalid. Requiring UAs to reject them is an entirely different story. If a user id *did* contain the colon, and did "work" for some UA A and server B, implementing the "MUST NOT" in the UA would remove the user's ability to log on to the web site. That's a bigger failure. > not implementations currently *do* this are irrelevant. The point is > that the right definition of the protocol is that you "MUST NOT have a > colon character in the username." They are invalid, and we already say that. Best regards, Julian From nobody Wed Feb 18 23:16:00 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C06FF1A888E; Wed, 18 Feb 2015 23:15:54 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E9F1A8882; Wed, 18 Feb 2015 23:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uPQeyAyv4-Zj; Wed, 18 Feb 2015 23:15:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 AEAD71A870F; Wed, 18 Feb 2015 23:15:52 -0800 (PST) Received: from [192.168.2.175] ([93.217.116.45]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MWCgz-1Y4Ndh3jK5-00XLlv; Thu, 19 Feb 2015 08:15:45 +0100 Message-ID: <54E58D9C.5020207@gmx.de> Date: Thu, 19 Feb 2015 08:15:40 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Barry Leiba , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8jCpegMSNWXoBoGjV0uKT7wfkE34a1WQvnTJQpsW4Rc88BjzvtF XMu2E4MpaTghTVhz0a6fgLRsZOqP5ai9+oxSmtR1bd87sX8Ohaf1eZG90Ys93uNm8svT5rh /5LYZW3chweOKKjVGeCHuGzsZXEa5OG9EJwq40eKGeenqoBBpwwWJq+Vf40RSDP0Vk3kuDo c+mLvDBKRXMTQ90nwxAqQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Pete Resnick , "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@ietf.org, The IESG , httpauth-chairs@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 07:15:54 -0000 On 2015-02-19 00:42, Barry Leiba wrote: >>> "MUST NOT" does not mean the Internet Police will come to take you away. >>> "MUST NOT" means "this won't work". >> >> Ahem, no, that's not what "MUST NOT" means. > > It is, modulo rhetoric. It's an interoperability requirement. "You > MUST NOT do ," means that if you do , you will not interoperate > -- something will break. It seems to me that that's exactly the case > here: If my username is "b:leiba", and a client sends "b:leiba:plugh", > many servers will think the username is "b" and the password is > "leiba:plugh". That means that allowing ":" in the username breaks > interoperability. Whether or not it works sometimes, and whether or Allowing colons in usernames when usernames are assigned is a problem. We already say these names are invalid. Requiring UAs to reject them is an entirely different story. If a user id *did* contain the colon, and did "work" for some UA A and server B, implementing the "MUST NOT" in the UA would remove the user's ability to log on to the web site. That's a bigger failure. > not implementations currently *do* this are irrelevant. The point is > that the right definition of the protocol is that you "MUST NOT have a > colon character in the username." They are invalid, and we already say that. Best regards, Julian From nobody Thu Feb 19 00:09: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 C72581A88E9; Thu, 19 Feb 2015 00:09:37 -0800 (PST) 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 Zj3uajM5hr0j; Thu, 19 Feb 2015 00:09:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 022AA1A88DE; Thu, 19 Feb 2015 00:09:35 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219080935.27783.45133.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 00:09:35 -0800 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, 19 Feb 2015 08:09:38 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Feb 19 00:09:50 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3946F1A88ED; Thu, 19 Feb 2015 00:09:38 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72581A88E9; Thu, 19 Feb 2015 00:09:37 -0800 (PST) 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 Zj3uajM5hr0j; Thu, 19 Feb 2015 00:09:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 022AA1A88DE; Thu, 19 Feb 2015 00:09:35 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219080935.27783.45133.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 00:09:35 -0800 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, 19 Feb 2015 08:09:38 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Feb 19 00:47:57 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 115C91A891B; Thu, 19 Feb 2015 00:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsWAh2xTGh9K; Thu, 19 Feb 2015 00:47:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 479371A8903; Thu, 19 Feb 2015 00:47:54 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219084754.12091.56491.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 00:47:54 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-04.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, 19 Feb 2015 08:47:56 -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 : Mutual Authentication Protocol for HTTP Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-04.txt Pages : 54 Date : 2015-02-19 Abstract: This document specifies a mutual authentication method for the Hyper- text Transfer Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-04 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 Thu Feb 19 00:48: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 625DA1A8930; Thu, 19 Feb 2015 00:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9WUemR46xKs; Thu, 19 Feb 2015 00:48:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D17D21A8906; Thu, 19 Feb 2015 00:48:03 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219084803.12111.9343.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 00:48:03 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-02.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, 19 Feb 2015 08:48: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 : Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-algo-02.txt Pages : 16 Date : 2015-02-19 Abstract: This document specifies some cryptographic algorithms which will be used for the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-algo-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-algo-02 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 Thu Feb 19 00:48:30 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 5CA411A8930; Thu, 19 Feb 2015 00:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73p1kN6cGYRj; Thu, 19 Feb 2015 00:48:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9560A1A8938; Thu, 19 Feb 2015 00:48:19 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219084819.12107.40066.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 00:48:19 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-extension-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 08:48:25 -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 Authentication Extensions for Interactive Clients Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-extension-03.txt Pages : 25 Date : 2015-02-19 Abstract: This document specifies a few extensions of HTTP authentication framework for interactive clients. Recently, fundamental features of HTTP-level authentication is not enough for complex requirements of various Web-based applications. This makes these applications to implement their own authentication frameworks using HTML Forms and other means, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user- agent clients. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility against existing Web and non-Web uses of HTTP authentications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-extension-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-extension-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 19 01:23: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 7D3F71A8969 for ; Thu, 19 Feb 2015 01:23:10 -0800 (PST) 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 rDQ8Nfknohgv for ; Thu, 19 Feb 2015 01:23:09 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 BAFBA1A8966 for ; Thu, 19 Feb 2015 01:23:08 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id l15so46529325wiw.5 for ; Thu, 19 Feb 2015 01:23:07 -0800 (PST) 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=63Arf/mGmIAXffpE8NB3CFEhAain3Sz+Y3wtw5KCYTQ=; b=TBABv1OgqTXCNcmbfrkQQmVieEAMdI8T9Hatt4r2LAZtzozYk89bOWNOKoE/0sRgca L1PJm09rSduqb4uwSNFobGSwVcqjFeHfhAngYhgh5cBG35uPocfy0VuSB0+/Z56rZ2x2 njI5R3CAub+/uXq6yl0m1kfCbxF70p4wPYN9uckK2DzbhS+TVrN/bVk95guO2cM4qafS qzG+Kzloqxf35QXZ0REQA2OcB/vB0TkoC9zi3Z3ZViAsjxl0snj1huzal541l0Ulz8is D5sgY0zL0YOgAeL0ZxFYAvHjcVRtXDz182EQk4/NkhmNa1/CfiMBrmUQwS/0b2qciiQ+ vPtA== X-Received: by 10.180.84.133 with SMTP id z5mr4858412wiy.25.1424337787336; Thu, 19 Feb 2015 01:23:07 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id u6sm31600883wix.12.2015.02.19.01.23.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Feb 2015 01:23:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <20150219084819.12107.40066.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:23:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150219084819.12107.40066.idtracker@ietfa.amsl.com> To: IETF HTTP Auth X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [http-auth] Mutual-Auth Documents 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, 19 Feb 2015 09:23:10 -0000 Hi, There are now new versions of the Mutual-Auth documents submitted. In Dallas we plan to spend almost all of the time on these documents. = Please take the time to read them and even better - post reviews to the = list. This is by no means light reading. The three documents have 95 pages in = combination. However, this is the biggest task remaining for this = working group, and we should be making progress at it. For your convenience, the links are below. Thanks, and see you all in Dallas. Yoav & Matt Mutual Authentication Protocol: = http://tools.ietf.org/html/draft-ietf-httpauth-mutual-04 Cryptographic Algorithms: = http://tools.ietf.org/html/draft-ietf-httpauth-mutual-algo-02 Extensions for Interactive Clients: = http://tools.ietf.org/html/draft-ietf-httpauth-extension-03 From nobody Thu Feb 19 06:20:57 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 D69B71A87AD; Thu, 19 Feb 2015 06:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDgXSKarPSbV; Thu, 19 Feb 2015 06:20:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC8B1A8784; Thu, 19 Feb 2015 06:20:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219142053.3845.48266.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:20:53 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Ted Lemon's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 14:20:55 -0000 Ted Lemon has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Pete's No Objection, and have found the responses unconvincing. I would support this being raised as a DISCUSS rather than a comment, but I'll leave that to Pete. From nobody Thu Feb 19 06:20:59 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 008011A8784; Thu, 19 Feb 2015 06:20:54 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69B71A87AD; Thu, 19 Feb 2015 06:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDgXSKarPSbV; Thu, 19 Feb 2015 06:20:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC8B1A8784; Thu, 19 Feb 2015 06:20:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219142053.3845.48266.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:20:53 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Ted Lemon's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 14:20:55 -0000 Ted Lemon has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: 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-basicauth-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Pete's No Objection, and have found the responses unconvincing. I would support this being raised as a DISCUSS rather than a comment, but I'll leave that to Pete. From nobody Thu Feb 19 08:20:16 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 1553F1A19F8; Thu, 19 Feb 2015 08:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 VGNttRC5_gAm; Thu, 19 Feb 2015 08:20:09 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C6A1A8833; Thu, 19 Feb 2015 08:20:09 -0800 (PST) Received: by labhz20 with SMTP id hz20so630778lab.0; Thu, 19 Feb 2015 08:20:07 -0800 (PST) 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=cyF3II3LWQiVH02rLbscCRTIcJd2jPnhPWETIyiEPZk=; b=aA+nS0TlZB43NKv2sQOSoPPv+ymiTGrS0jd4AQjUdJFExUIWlnztKhPXiQhCA2V0v3 9z0IyFSeYGU3/aYsTbmGM8R/6A8ItOK6rXfqk6SSIXcbYLB9Qb6Tqqx0YoFDYgtijpX7 fXCIFfbLIeo5s8DgYlhJAL2q9XLtDnZuDaS4/vK14z9ezln2zpnVIOAUtHrQQlV3GFDX 0evcKuRJGk5sWVuSUp1nE0Ch/OedMldFWrqMuk3e2TFo7+3Ytk7aT958uEvDFMfFZKqr yGqc5sULRElDjtG0JqHWxPBkuM0e5BcfYF+Kp0Vqw9cN7LggVvRF99iuZCYQ/bMRrpHP 9Plg== MIME-Version: 1.0 X-Received: by 10.152.36.138 with SMTP id q10mr4477334laj.113.1424362807905; Thu, 19 Feb 2015 08:20:07 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 19 Feb 2015 08:20:07 -0800 (PST) In-Reply-To: <54E58D9C.5020207@gmx.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> Date: Thu, 19 Feb 2015 11:20:07 -0500 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=089e0160b922325190050f734f4e Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 16:20:12 -0000 --089e0160b922325190050f734f4e Content-Type: text/plain; charset=UTF-8 Hi, On Thu, Feb 19, 2015 at 2:15 AM, Julian Reschke wrote: > On 2015-02-19 00:42, Barry Leiba wrote: > >> "MUST NOT" does not mean the Internet Police will come to take you away. >>>> "MUST NOT" means "this won't work". >>>> >>> >>> Ahem, no, that's not what "MUST NOT" means. >>> >> >> It is, modulo rhetoric. It's an interoperability requirement. "You >> MUST NOT do ," means that if you do , you will not interoperate >> -- something will break. It seems to me that that's exactly the case >> here: If my username is "b:leiba", and a client sends "b:leiba:plugh", >> many servers will think the username is "b" and the password is >> "leiba:plugh". That means that allowing ":" in the username breaks >> interoperability. Whether or not it works sometimes, and whether or >> > > Allowing colons in usernames when usernames are assigned is a problem. We > already say these names are invalid. > > Requiring UAs to reject them is an entirely different story. If a user id > *did* contain the colon, and did "work" for some UA A and server B, > implementing the "MUST NOT" in the UA would remove the user's ability to > log on to the web site. That's a bigger failure. Pete and Barry are making the point that text in this draft can help clear this issue up going forward. If a user id contained a colon, the user would need a new id if user agents decided this should not work. Since browsers do support this now, there must be some instances where this occurred to change their behavior, moving away from standard specifications to allow this, is that true? I haven't seen user ids with :s in them, but that could just be me being unaware of this practice. I'm not reading this discussion as resolved yet. Thanks, Kathleen > > > not implementations currently *do* this are irrelevant. The point is >> that the right definition of the protocol is that you "MUST NOT have a >> colon character in the username." >> > > They are invalid, and we already say that. > > Best regards, Julian > -- Best regards, Kathleen --089e0160b922325190050f734f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Thu, Feb 19, 2015 at 2:15 AM, Julian Reschke <julian.reschke@gmx= .de> wrote:
On 2015-02-19 00:42, Barry Leiba wrote:
"MUST NOT" does not mean the Internet Police will come to take yo= u away.
"MUST NOT" means "this won't work".

Ahem, no, that's not what "MUST NOT" means.

It is, modulo rhetoric.=C2=A0 It's an interoperability requirement.=C2= =A0 "You
MUST NOT do <x>," means that if you do <x>, you will not i= nteroperate
-- something will break.=C2=A0 It seems to me that that's exactly the c= ase
here: If my username is "b:leiba", and a client sends "b:lei= ba:plugh",
many servers will think the username is "b" and the password is "leiba:plugh".=C2=A0 That means that allowing ":" in th= e username breaks
interoperability.=C2=A0 Whether or not it works sometimes, and whether or

Allowing colons in usernames when usernames are assigned is a problem. We a= lready say these names are invalid.

Requiring UAs to reject them is an entirely different story. If a user id *= did* contain the colon, and did "work" for some UA A and server B= , implementing the "MUST NOT" in the UA would remove the user'= ;s ability to log on to the web site. That's a bigger failure.

Pete and Barry are making the point that text in th= is draft can help clear this issue up going forward.=C2=A0 If a user id con= tained a colon, the user would need a new id if user agents decided this sh= ould not work.=C2=A0 Since browsers do support this now, there must be some= instances where this occurred to change their behavior, moving away from s= tandard specifications to allow this, is that true?=C2=A0 I haven't see= n user ids with :s in them, but that could just be me being unaware of this= practice.

I'm not reading this discussion as = resolved yet.

Thanks,
Kathleen


not implementations currently *do* this are irrelevant.=C2=A0 The point is<= br> that the right definition of the protocol is that you "MUST NOT have a=
colon character in the username."

 They are invalid, and we already say that.

Best regards, Julian



--

Best regards,
Kath= leen
--089e0160b922325190050f734f4e-- From nobody Thu Feb 19 08:20:18 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 34D841A893E; Thu, 19 Feb 2015 08:20:12 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1553F1A19F8; Thu, 19 Feb 2015 08:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 VGNttRC5_gAm; Thu, 19 Feb 2015 08:20:09 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C6A1A8833; Thu, 19 Feb 2015 08:20:09 -0800 (PST) Received: by labhz20 with SMTP id hz20so630778lab.0; Thu, 19 Feb 2015 08:20:07 -0800 (PST) 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=cyF3II3LWQiVH02rLbscCRTIcJd2jPnhPWETIyiEPZk=; b=aA+nS0TlZB43NKv2sQOSoPPv+ymiTGrS0jd4AQjUdJFExUIWlnztKhPXiQhCA2V0v3 9z0IyFSeYGU3/aYsTbmGM8R/6A8ItOK6rXfqk6SSIXcbYLB9Qb6Tqqx0YoFDYgtijpX7 fXCIFfbLIeo5s8DgYlhJAL2q9XLtDnZuDaS4/vK14z9ezln2zpnVIOAUtHrQQlV3GFDX 0evcKuRJGk5sWVuSUp1nE0Ch/OedMldFWrqMuk3e2TFo7+3Ytk7aT958uEvDFMfFZKqr yGqc5sULRElDjtG0JqHWxPBkuM0e5BcfYF+Kp0Vqw9cN7LggVvRF99iuZCYQ/bMRrpHP 9Plg== MIME-Version: 1.0 X-Received: by 10.152.36.138 with SMTP id q10mr4477334laj.113.1424362807905; Thu, 19 Feb 2015 08:20:07 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 19 Feb 2015 08:20:07 -0800 (PST) In-Reply-To: <54E58D9C.5020207@gmx.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> Date: Thu, 19 Feb 2015 11:20:07 -0500 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=089e0160b922325190050f734f4e Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 16:20:12 -0000 --089e0160b922325190050f734f4e Content-Type: text/plain; charset=UTF-8 Hi, On Thu, Feb 19, 2015 at 2:15 AM, Julian Reschke wrote: > On 2015-02-19 00:42, Barry Leiba wrote: > >> "MUST NOT" does not mean the Internet Police will come to take you away. >>>> "MUST NOT" means "this won't work". >>>> >>> >>> Ahem, no, that's not what "MUST NOT" means. >>> >> >> It is, modulo rhetoric. It's an interoperability requirement. "You >> MUST NOT do ," means that if you do , you will not interoperate >> -- something will break. It seems to me that that's exactly the case >> here: If my username is "b:leiba", and a client sends "b:leiba:plugh", >> many servers will think the username is "b" and the password is >> "leiba:plugh". That means that allowing ":" in the username breaks >> interoperability. Whether or not it works sometimes, and whether or >> > > Allowing colons in usernames when usernames are assigned is a problem. We > already say these names are invalid. > > Requiring UAs to reject them is an entirely different story. If a user id > *did* contain the colon, and did "work" for some UA A and server B, > implementing the "MUST NOT" in the UA would remove the user's ability to > log on to the web site. That's a bigger failure. Pete and Barry are making the point that text in this draft can help clear this issue up going forward. If a user id contained a colon, the user would need a new id if user agents decided this should not work. Since browsers do support this now, there must be some instances where this occurred to change their behavior, moving away from standard specifications to allow this, is that true? I haven't seen user ids with :s in them, but that could just be me being unaware of this practice. I'm not reading this discussion as resolved yet. Thanks, Kathleen > > > not implementations currently *do* this are irrelevant. The point is >> that the right definition of the protocol is that you "MUST NOT have a >> colon character in the username." >> > > They are invalid, and we already say that. > > Best regards, Julian > -- Best regards, Kathleen --089e0160b922325190050f734f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Thu, Feb 19, 2015 at 2:15 AM, Julian Reschke <julian.reschke@gmx= .de> wrote:
On 2015-02-19 00:42, Barry Leiba wrote:
"MUST NOT" does not mean the Internet Police will come to take yo= u away.
"MUST NOT" means "this won't work".

Ahem, no, that's not what "MUST NOT" means.

It is, modulo rhetoric.=C2=A0 It's an interoperability requirement.=C2= =A0 "You
MUST NOT do <x>," means that if you do <x>, you will not i= nteroperate
-- something will break.=C2=A0 It seems to me that that's exactly the c= ase
here: If my username is "b:leiba", and a client sends "b:lei= ba:plugh",
many servers will think the username is "b" and the password is "leiba:plugh".=C2=A0 That means that allowing ":" in th= e username breaks
interoperability.=C2=A0 Whether or not it works sometimes, and whether or

Allowing colons in usernames when usernames are assigned is a problem. We a= lready say these names are invalid.

Requiring UAs to reject them is an entirely different story. If a user id *= did* contain the colon, and did "work" for some UA A and server B= , implementing the "MUST NOT" in the UA would remove the user'= ;s ability to log on to the web site. That's a bigger failure.

Pete and Barry are making the point that text in th= is draft can help clear this issue up going forward.=C2=A0 If a user id con= tained a colon, the user would need a new id if user agents decided this sh= ould not work.=C2=A0 Since browsers do support this now, there must be some= instances where this occurred to change their behavior, moving away from s= tandard specifications to allow this, is that true?=C2=A0 I haven't see= n user ids with :s in them, but that could just be me being unaware of this= practice.

I'm not reading this discussion as = resolved yet.

Thanks,
Kathleen


not implementations currently *do* this are irrelevant.=C2=A0 The point is<= br> that the right definition of the protocol is that you "MUST NOT have a=
colon character in the username."

 They are invalid, and we already say that.

Best regards, Julian



--

Best regards,
Kath= leen
--089e0160b922325190050f734f4e-- From nobody Thu Feb 19 08:25: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 AD1891A9175; Thu, 19 Feb 2015 08:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 JeJbAfrWk_dV; Thu, 19 Feb 2015 08:25:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 793DE1A9236; Thu, 19 Feb 2015 08:24:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219162437.7415.35008.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 08:24:37 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Kathleen Moriarty's Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS) 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, 19 Feb 2015 16:25:10 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: Discuss 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-basicauth-update/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to make sure a few comments get addressed and text gets updated from the SecDir review. This should get resolved quickly, but I wanted to make sure there was a placeholder so the comments don't go unaddressed. The author has been very responsive, so I don't think that is an issue. http://www.ietf.org/mail-archive/web/secdir/current/msg05460.html From nobody Thu Feb 19 08:25:20 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C89B21A9240; Thu, 19 Feb 2015 08:25:10 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1891A9175; Thu, 19 Feb 2015 08:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 JeJbAfrWk_dV; Thu, 19 Feb 2015 08:25:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 793DE1A9236; Thu, 19 Feb 2015 08:24:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219162437.7415.35008.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 08:24:37 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-basicauth-update.all@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Kathleen Moriarty's Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS) 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, 19 Feb 2015 16:25:11 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-httpauth-basicauth-update-06: Discuss 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-basicauth-update/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to make sure a few comments get addressed and text gets updated from the SecDir review. This should get resolved quickly, but I wanted to make sure there was a placeholder so the comments don't go unaddressed. The author has been very responsive, so I don't think that is an issue. http://www.ietf.org/mail-archive/web/secdir/current/msg05460.html From nobody Thu Feb 19 08:45:52 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 A6D491A923C; Thu, 19 Feb 2015 08:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LTaZyLXUXR3W; Thu, 19 Feb 2015 08:45:46 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673301A9233; Thu, 19 Feb 2015 08:45:43 -0800 (PST) Received: from [192.168.2.175] (unknown [93.217.98.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 3DA6215A0309; Thu, 19 Feb 2015 17:45:40 +0100 (CET) Message-ID: <54E61331.7080807@greenbytes.de> Date: Thu, 19 Feb 2015 17:45:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 16:45:48 -0000 On 2015-02-19 17:20, Kathleen Moriarty wrote: > Hi, > > On Thu, Feb 19, 2015 at 2:15 AM, Julian Reschke > wrote: > > On 2015-02-19 00:42, Barry Leiba wrote: > > "MUST NOT" does not mean the Internet Police will come > to take you away. > "MUST NOT" means "this won't work". > > > Ahem, no, that's not what "MUST NOT" means. > > > It is, modulo rhetoric. It's an interoperability requirement. "You > MUST NOT do ," means that if you do , you will not > interoperate > -- something will break. It seems to me that that's exactly the > case > here: If my username is "b:leiba", and a client sends > "b:leiba:plugh", > many servers will think the username is "b" and the password is > "leiba:plugh". That means that allowing ":" in the username breaks > interoperability. Whether or not it works sometimes, and whether or > > > Allowing colons in usernames when usernames are assigned is a > problem. We already say these names are invalid. > > Requiring UAs to reject them is an entirely different story. If a > user id *did* contain the colon, and did "work" for some UA A and > server B, implementing the "MUST NOT" in the UA would remove the > user's ability to log on to the web site. That's a bigger failure. > > > Pete and Barry are making the point that text in this draft can help > clear this issue up going forward. If a user id contained a colon, the > user would need a new id if user agents decided this should not work. > Since browsers do support this now, there must be some instances where > this occurred to change their behavior, moving away from standard > specifications to allow this, is that true? I haven't seen user ids > with :s in them, but that could just be me being unaware of this practice. > > I'm not reading this discussion as resolved yet. True. The problem here is the "long tail". We simply have no information about whether these IDs exist in practice. The fact that all UAs I checked indeed accept them at least *hints* that they might be used somewhere. Or none of the implementers ever thought about rejecting them. I don't believe we can find out what the reason for this is. In RFC 2617, the pseudo-ABNF prose production excluded the colon, but no additional prose requirements were present. In the draft, we have replaced that pseudo-ABNF by prose, and that prose not only says "invalid" but also explains what common UAs do, and how that might affect results. I hope everybody agrees that this is an improvement over what we had before. The discussion that we're having is whether "MUST NOT use colons" is better or worse than "colons are invalid". I don't believe it makes a difference. I'll also note that I'm very unhappy to include a "MUST NOT" when we know that current implementations actually do it anyway, and they are extremely unlikely to stop doing that. In the worst case, a user who previously could login now won't, and this might switch to a different UA. (And that's what scares UA implementors most :-). Best regards, Julian From nobody Thu Feb 19 08:45:54 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C6C341A9248; Thu, 19 Feb 2015 08:45:48 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D491A923C; Thu, 19 Feb 2015 08:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LTaZyLXUXR3W; Thu, 19 Feb 2015 08:45:46 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673301A9233; Thu, 19 Feb 2015 08:45:43 -0800 (PST) Received: from [192.168.2.175] (unknown [93.217.98.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 3DA6215A0309; Thu, 19 Feb 2015 17:45:40 +0100 (CET) Message-ID: <54E61331.7080807@greenbytes.de> Date: Thu, 19 Feb 2015 17:45:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 16:45:48 -0000 On 2015-02-19 17:20, Kathleen Moriarty wrote: > Hi, > > On Thu, Feb 19, 2015 at 2:15 AM, Julian Reschke > wrote: > > On 2015-02-19 00:42, Barry Leiba wrote: > > "MUST NOT" does not mean the Internet Police will come > to take you away. > "MUST NOT" means "this won't work". > > > Ahem, no, that's not what "MUST NOT" means. > > > It is, modulo rhetoric. It's an interoperability requirement. "You > MUST NOT do ," means that if you do , you will not > interoperate > -- something will break. It seems to me that that's exactly the > case > here: If my username is "b:leiba", and a client sends > "b:leiba:plugh", > many servers will think the username is "b" and the password is > "leiba:plugh". That means that allowing ":" in the username breaks > interoperability. Whether or not it works sometimes, and whether or > > > Allowing colons in usernames when usernames are assigned is a > problem. We already say these names are invalid. > > Requiring UAs to reject them is an entirely different story. If a > user id *did* contain the colon, and did "work" for some UA A and > server B, implementing the "MUST NOT" in the UA would remove the > user's ability to log on to the web site. That's a bigger failure. > > > Pete and Barry are making the point that text in this draft can help > clear this issue up going forward. If a user id contained a colon, the > user would need a new id if user agents decided this should not work. > Since browsers do support this now, there must be some instances where > this occurred to change their behavior, moving away from standard > specifications to allow this, is that true? I haven't seen user ids > with :s in them, but that could just be me being unaware of this practice. > > I'm not reading this discussion as resolved yet. True. The problem here is the "long tail". We simply have no information about whether these IDs exist in practice. The fact that all UAs I checked indeed accept them at least *hints* that they might be used somewhere. Or none of the implementers ever thought about rejecting them. I don't believe we can find out what the reason for this is. In RFC 2617, the pseudo-ABNF prose production excluded the colon, but no additional prose requirements were present. In the draft, we have replaced that pseudo-ABNF by prose, and that prose not only says "invalid" but also explains what common UAs do, and how that might affect results. I hope everybody agrees that this is an improvement over what we had before. The discussion that we're having is whether "MUST NOT use colons" is better or worse than "colons are invalid". I don't believe it makes a difference. I'll also note that I'm very unhappy to include a "MUST NOT" when we know that current implementations actually do it anyway, and they are extremely unlikely to stop doing that. In the worst case, a user who previously could login now won't, and this might switch to a different UA. (And that's what scares UA implementors most :-). Best regards, Julian From nobody Thu Feb 19 09:55:46 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 40E5B1A1B84; Thu, 19 Feb 2015 09:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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_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 DLep8UIOgNuO; Thu, 19 Feb 2015 09:55:40 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072C31A1B19; Thu, 19 Feb 2015 09:55:39 -0800 (PST) Received: by lbiw7 with SMTP id w7so1373729lbi.9; Thu, 19 Feb 2015 09:55:37 -0800 (PST) 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=A1zkB+sg8pyane2neWKgtu5b28MPJEQxq1TFEEr7I8Q=; b=IhUNexKgPWFTFOd/Qb7YHXkUt3wcMN9Jb+XEgi6/MFMle9+a1BA1BEmX71weAlfLiE zT09uWDBa2kHERWXeQR7CtHBgFeSdsqqyqhhUWuX8IHN+VvuxzY0smspbXuS4Da26kMT 51dFiy/q0Zi+rNlRliJVlOLV5y/0J2pdm1F9S4mo4MgKYKDBBLK335mY9Qt/0GiMbEBH bSRevcUV64ZVDqO8sGWRQdjJ6fThttIQfGZXh06fukJqsIBI3UvieKeowxtkySGGZfo0 T03/cbQYH7MGMwki4IxoLlj4JYGRlUb5Esn5n/WIO+vJarrPdH6yRlHAa8M2Gxp+xNhD wrlQ== MIME-Version: 1.0 X-Received: by 10.112.167.231 with SMTP id zr7mr4941824lbb.123.1424368537372; Thu, 19 Feb 2015 09:55:37 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Thu, 19 Feb 2015 09:55:37 -0800 (PST) In-Reply-To: <54E61331.7080807@greenbytes.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> Date: Thu, 19 Feb 2015 09:55:37 -0800 X-Google-Sender-Auth: rT3Sq7m-z8eDvcS-bcs2bLRj0Ko Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 17:55:42 -0000 A final note form me on this, and then I'm done with the discussion: > The problem here is the "long tail". We simply have no information about > whether these IDs exist in practice. The fact that all UAs I checked indeed > accept them at least *hints* that they might be used somewhere. Or none of > the implementers ever thought about rejecting them. I don't think this matters (but see below). From the point of view of protocol definition, it doesn't matter what's done; it matters what works. If userids with colons don't work when you send them on the wire (because servers don't interpret the userid/password field as intended), then the protocol definition should ban them, even if user agents are, in fact sending them on the wire and will continue to. But... > The discussion that we're having is whether "MUST NOT use colons" is better > or worse than "colons are invalid". I don't believe it makes a difference. I have to admit that I don't either, and that's why I'm done with this discussion. I don't think that changing "X is invalid" to "MUST NOT X" is important enough that it's worth further discussion, and I'm happy to have that left as it is. We might consider slightly altering the text to make it clear that what we say is being done in practice often does not work and is not interoperable (rather than the sort of vague "will likely treat in a way not intended" text that's there now). Meh. I'll leave that up to Julian and Pete to discuss. Julian, thanks for the discussion. Barry From nobody Thu Feb 19 09:55:48 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 675B01A1BFB; Thu, 19 Feb 2015 09:55:42 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E5B1A1B84; Thu, 19 Feb 2015 09:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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_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 DLep8UIOgNuO; Thu, 19 Feb 2015 09:55:40 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072C31A1B19; Thu, 19 Feb 2015 09:55:39 -0800 (PST) Received: by lbiw7 with SMTP id w7so1373729lbi.9; Thu, 19 Feb 2015 09:55:37 -0800 (PST) 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=A1zkB+sg8pyane2neWKgtu5b28MPJEQxq1TFEEr7I8Q=; b=IhUNexKgPWFTFOd/Qb7YHXkUt3wcMN9Jb+XEgi6/MFMle9+a1BA1BEmX71weAlfLiE zT09uWDBa2kHERWXeQR7CtHBgFeSdsqqyqhhUWuX8IHN+VvuxzY0smspbXuS4Da26kMT 51dFiy/q0Zi+rNlRliJVlOLV5y/0J2pdm1F9S4mo4MgKYKDBBLK335mY9Qt/0GiMbEBH bSRevcUV64ZVDqO8sGWRQdjJ6fThttIQfGZXh06fukJqsIBI3UvieKeowxtkySGGZfo0 T03/cbQYH7MGMwki4IxoLlj4JYGRlUb5Esn5n/WIO+vJarrPdH6yRlHAa8M2Gxp+xNhD wrlQ== MIME-Version: 1.0 X-Received: by 10.112.167.231 with SMTP id zr7mr4941824lbb.123.1424368537372; Thu, 19 Feb 2015 09:55:37 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Thu, 19 Feb 2015 09:55:37 -0800 (PST) In-Reply-To: <54E61331.7080807@greenbytes.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> Date: Thu, 19 Feb 2015 09:55:37 -0800 X-Google-Sender-Auth: rT3Sq7m-z8eDvcS-bcs2bLRj0Ko Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 17:55:42 -0000 A final note form me on this, and then I'm done with the discussion: > The problem here is the "long tail". We simply have no information about > whether these IDs exist in practice. The fact that all UAs I checked indeed > accept them at least *hints* that they might be used somewhere. Or none of > the implementers ever thought about rejecting them. I don't think this matters (but see below). From the point of view of protocol definition, it doesn't matter what's done; it matters what works. If userids with colons don't work when you send them on the wire (because servers don't interpret the userid/password field as intended), then the protocol definition should ban them, even if user agents are, in fact sending them on the wire and will continue to. But... > The discussion that we're having is whether "MUST NOT use colons" is better > or worse than "colons are invalid". I don't believe it makes a difference. I have to admit that I don't either, and that's why I'm done with this discussion. I don't think that changing "X is invalid" to "MUST NOT X" is important enough that it's worth further discussion, and I'm happy to have that left as it is. We might consider slightly altering the text to make it clear that what we say is being done in practice often does not work and is not interoperable (rather than the sort of vague "will likely treat in a way not intended" text that's there now). Meh. I'll leave that up to Julian and Pete to discuss. Julian, thanks for the discussion. Barry From nobody Thu Feb 19 11:08:42 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 5E6261A0077; Thu, 19 Feb 2015 11:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xi9tndY6LaJC; Thu, 19 Feb 2015 11:08:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 196071A0040; Thu, 19 Feb 2015 11:08:31 -0800 (PST) Received: from [192.168.2.175] ([93.217.98.69]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MVIva-1Y36810kqk-00Yjq9; Thu, 19 Feb 2015 20:07:59 +0100 Message-ID: <54E6348A.3080606@gmx.de> Date: Thu, 19 Feb 2015 20:07:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Julian Reschke , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> In-Reply-To: <871tllbw2c.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:htzPt/ofMbErKisew9cLGWsP58qdN15F1cCj3xdratn4hg/1Rz9 bwDtHEAFw9uDfrN4kJpv5UmHAMXmxqrN6Om1PsvzMw8rZkM2o3KUU2Mu/5WuCLmxkXC3qsZ 1AdfTliBipWjQ+Ibr46MABUVnv8t7Be2/5Q9DBxsbrXnNiYj2AqufnxlsFX1lX/km9u6p/s 1++KBc8IHNBsKYSEFZf4w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 19 Feb 2015 19:08:36 -0000 On 2015-02-19 19:22, Daniel Kahn Gillmor wrote: > Hi Julian-- > > Thanks for the prompt response! My own are inline below. > > On Wed 2015-02-18 17:18:43 -0500, Julian Reschke wrote: >> On 2015-02-18 09:15, Daniel Kahn Gillmor wrote: >>> ... >>> Should recommend strong password-hashing on the server side >>> ----------------------------------------------------------- >>> >>> The Security Considerations section acknowledges that passwords can be >>> stolen from servers, but does not encourage server operators to hash >>> stored passwords with a reasonable or strong algorithm. This document >>> may not be the place to provide normative guidance on how to store >>> passwords to mitigate the exposure of a password table, but perhaps a >>> brief mention and an informative reference would be useful? Many >>> systems (e.g. modern nginx and apache) use 1000 iterations of salted >>> MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, >>> which are all terrible. >>> >>> https://httpd.apache.org/docs/2.4/misc/password_encryptions.html >>> http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file >>> >>> an informative reference might point to the Password Hashing >>> Competition, which documents sensible rationales for why you should use >>> strong password hashing, and how to know it when you see it: >>> >>> https://password-hashing.net >>> >>> by comparison the digest draft has a lot more about how passwords should >>> be stored (even though Digest auth can offer only weaker protections for >>> the password store compared to Basic auth): >>> >>> https://tools.ietf.org/html/draft-ietf-httpauth-digest-13#section-5.2 >>> ... >> >> I would really like to avoid talking about threads that are generic to >> password-based authentication. Optimally, the security area would have a >> document that discusses exactly these kind of things so that other specs >> can reference that. Does something like this exist? > > These threats aren't generic to password-based authentication. they're > specific to the *type* of password-based authentication used by HTTP > basic auth. For example HTTP Digest and PAKE schemes are both > password-based, but have different properties, different requirements > for the password store, and different threats. > > I don't know if there is an IETF document that describes > password-hashing best-practices or formats. Maybe someone else knows? > >> Or do you want to propose concrete text? > > I don't have the bandwidth to craft something fancy right now, but > here's a first stab that you're welcome to carve up as you see fit, if > no IETF references are forthcoming: > > Servers and proxies requiring Basic Authentication must store user > passwords in some form in order to verify the request's > Authorization: header. These passwords should be stored in such a > way that a leak of the password table doesn't make them trivially > recoverable. This is especially when users are allowed to set their > own passwords, since users are known to choose weak passwords and to > reuse them across authentication realms. While a full discussion of > good password hashing techniques for HTTP Basic Authentication is > beyond the scope of this document, server operators should make an > effort to minimize risks to their users in the event of a password > table leak. For example, servers should not store user passwords in > plaintext or as unsalted digests. For more discussion about modern > password hashing techniques, see [PHC]. > > [PHC] https://password-hashing.net Password Hashing Competition > > (i've used "should not" instead of RFC 2119 "SHOULD NOT" above because > this is not a recommendation about the on-the-wire protocol. If anyone > thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to > see that happen, because this is seriously low-hanging fruit, and i'm > sure there are still operators out there disregarding it. I like the text, and I'm ok with including it or a variation of it. I'm not 100% convinced that the RFC Editor will be ok with the citation. >>> Should recommend constant-time server-side comparisons >>> ------------------------------------------------------ >>> >>> Servers that implement basic auth should not leak information about >>> the stored password via timing of rejections. For example, a server >>> that stored cleartext passwords (which is a bad idea anyway) should >>> mechanically compare the entire string instead of bytewise comparisons. >>> The attack here is an attacker who guesses credentials a byte at a time, >>> by making 256 initial guesses and seeing which of them gets back a >>> rejection faster than the other (and iterates down the list). >>> >>> This might be less of an issue for reasonable (non-cleartext) password >>> storage, but if we're not requiring strong password hashing, we should >>> at least require constant time comparisons. >> >> Do you seriously believe that the time for a string comparison is >> relevant compared to the overhead of two network hops plus encapsulation >> into HTTP messages? > > If the transport framework (network hops plus encapsulation into HTTP > messages) has no jitter, then the ratio of timing between string > comparison and the transport framework overhead is irrelevant; an > attacker just cares about difference, not magnitude. Even with some > small jitter, statistical analyses over many connections could yield > information. > > Do i expect the transport framework to be jitter-free in the real world? > Usually, no. But do you want the security of the scheme to depend on > the transport framework having jitter? > > If this is a security consideration, would you rather say "deploy this > only over jittery transports" or "don't leak timing information when you > compare passwords"? The latter seems simpler and clearer to me. The network exchange will be take milliseconds. The string comparison microseconds. /me not convinced there's a problem here. >>> Should recommend padding the Authorization: response >>> ---------------------------------------------------- >>> >>> When used behind HTTPS as recommended, TLS hides the username and >>> password presented. However, it does not hide the length of the >>> username and password if the other parameters of the HTTPS request are >>> known. >>> >>> An active attacker who wants to learn the length of the victim's >>> username and password together for a particular basic auth realm could >>> force the user's browser to make HTTPS requests to a few different URLs >>> within the realm and see how large the packets are. >>> >>> This could be mitigated by including whitespace padding in the client's >>> Authorization: header itself up to some multiple of a blocksize (perhaps >>> 256B) to obscure the length. >> >> Actually, padding can happen anywhere in the message; it doesn't need to >> be in this header field. > > That's true, but padding the entire HTTP request to a standard blocksize > has different security properties than just padding this field to a > standard blocksize, because parts of the HTTP request could be under > control of the attacker. > > For example, if Alice can make Bob's user agent fetch arbitrary URLs > from https://example.com/, then she can pass steadily increasing URLs to > Bob's user agent (e.g. https://example.com/a https://example.com/aa > https://example.com/aaa) and see at what point the size jumps a quantum. > Restricting the padding to the field that is not under attacker control > in any part should prevent this attack. How would the attacker be able to modify fields in the request? I think it would be great to have a document that describes these threats and how to mitigate them; in particular comparing HTTP/1.1 and 2, but I seriously doubt this document would be the right place to do this. (It seems to be as relevant for cookies, no?) >> It's an interesting idea; have you checked whether existing User Agents >> do this? > > I don't know whether any existing User Agents do this, sorry. > >>> UTF-8 security considerations by reference: is this OK? >>> ------------------------------------------ >>> >>> The Security Considerations section includes the UTF-8 security >>> considerations section by reference, but doesn't call out any specific >>> issues for implementers to be aware of. the NFC canonicalization draft >> >> Intentionally. >> >>> also has Security Considersations section, which is not included by >>> reference: >>> >>> https://tools.ietf.org/html/rfc5198#section-6 >> >> I'll add that. > > cool, thanks! > > >>> Interaction with proxies? >>> ------------------------- >>> >>> There is only a passing mention of Proxy-Authenticate: and >>> Proxy-Authorization: headers, so one assumes that both mechanisms should >>> support this new auth-param. It's not clear to me whether there are any >>> additional security or privacy implications when this is addressed to >>> proxies compared to origin servers. >> >> I'm not aware of any. >> >>> Section 2.2 ("reusing credentials") talks about the URI path (presumably >>> for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the >>> middle of that commentary. It looks to me like "Proxy-Authenticate" is >>> not intended to be scoped by the URI path (there is no mention of "in >>> that space" in the sentence about Proxy-Authenticate in Section 2.2), >>> but this is kind of ambiguous. Clarification would be good. >> >> To be frank, I don't know. My best guess is that it works exactly the >> same, so I'll add "in that space" there as well. > > This ambiguity worries me a bit; should we take this opportunity to > clear it up to match what happens in practice? It seems like we should > have some people with operational experience on this who could provide > clarification here, but i'm not one of them. Nor am I. I do agree that proxy authentication needs better documentation, but that's a problem of RFC 7235, not this spec. >>> Path matching? >>> -------------- >>> >>> Nothing in the security considerations section talks about the threat >>> that motivates path matching for determination of which realm to use. >>> It might be useful to spell this out explicitly: >>> >>> * A user agent that sends the Authorization: header to URLs outside the >>> authentication scope as described in Section 2.2 may leak the user's >>> credentials >> >> That applies to all schemes that use protection spaces and is mentioned >> in >> already. >> >>> User Agent visibility and logout? >>> --------------------------------- >>> >>> Most RFCs don't talk at all about the human interface of the mentioned >>> tools. >>> >>> But this draft refers briefly to interaction between the user and the >>> User Agent (see step 1 on >>> https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06#page-6). >>> However, it provides no other guidance. There are several additional >>> guidelines that make basic authentication more acceptable from a privacy >>> and security point of view for a typical web browser User Agent: >>> >>> * user agents should indicate to the user when they are re-using the >>> user's authentication credentials as described in section 2.2 >>> (indicating the realm, authentication scope, and user-id?) >> >> They don't right now. Do you believe that requiring it will have any >> effect on existing UAs? > > i don't know, but i'd certainly like to see that happen. If it doesn't > happen, perhaps we need to mention in Security Considerations that User > Agents which do not indicate to the user when they are reusing the > user's credentials risk leaking those credentials without the user > knowing that it's happening? We could say that (text welcome), but I seriously doubt it will affect what software does. The current trend is to remove as much UI as possible (or even all on mobile), so asking for this indicator is really wishful thinking. >>> * user agents should not display the user's password anywhere by >>> default >> >> That sounds pretty obvious. > > I agree! Maybe we don't need to say obvious things? > >>> * user agents should make it straightforward for users to clear their >>> credentials for any . >> >> Define "straightforward". > > That probably depends on the type of user agent, no? as a suggestion, > this seems like it could be something that we encourage without > specifying concrete mechanism. Again, we're talking about code that has been written almost 20 years ago. New advice on nice-to-haves will not have any effect on these implementations. >>> https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these >>> guidelines; perhaps this is another include-by-reference? >> >> All security considerations of RFC 7235 apply by definition, as this >> spec is using the framework defined by RFC 7235. I don't believe that we >> need to state this. > > It wasn't immediately obvious to me that all security considerations of > RFC 7235 apply by definition, but now that you say it it makes sense. > > Do you think that an implementor of HTTP basic auth with less experience > reading RFCs is going to understand that? An implementor of this spec will need to read and understand RFC 7235. So, yes. >>> Other Considerations >>> ==================== >>> >>> Deployment chicken-and-egg >>> -------------------------- >>> >>> The server has no way of knowing that the client is trying to obey the >>> charset header. For the servers mentioned in that do user-agent >> >> Actually, it could apply heuristics. I header detection of UTF-8 is >> quire reliable. > > What heuristics should it apply? If there is a standard set of > heuristics we expect servers to use, we should put them in this > document. I don't *expect* servers to use heuristics. That being said, the heuristics are quite simple: try to decode the octets with a strict UTF-8 decoder, and if that doesn't fail the input was likely encoded in UTF-8. >>> sniffing, it's not clear how those servers could ever know to stop >>> relying on the user-agent, since the clients have no way of signalling >>> their intent to use UTF-8 for the Authorization header. If the servers >>> don't know when to start accepting UTF-8 from these clients, then the >>> clients also have no way of knowing when they should switch over >>> themselves. This strikes me as a recipe for stalled adoption, since >>> "user agents in the latter group" (from section B.3) will never use >>> UTF-8, even if they know about it. >> >> I don't see why the server can't just start accepting UTF-8 right away. > > > Because "User agents in the latter group will have to continue to do > what they do today", so the servers will need to interpret the response > in the same way. If you mean to say that 'User agents in the latter > group will have to continue to do what they do today unless the server > has sent charset="UTF-8"' then please say so explicitly. No, that's not what I meant. By "accepting UTF-8" I mean "trying to decode as UTF-8" in addition to what the server is already doing; basically a trial-and-error approach. > And sorry, one more question arises for me on re-read. i'm not sure i > understand what this means: > > Server implementers SHOULD guard against the possibility of this sort > of counterfeiting by gateways or CGI scripts. In particular it is > very dangerous for a server to simply turn over a connection to a > gateway. That gateway can then use the persistent connection > mechanism to engage in multiple transactions with the client while > impersonating the original server in a way that is not detectable by > the client. > > How should the server guard against this attack? what sort does it mean > to "turn over a connection to a gateway"? does "gateway" mean > "transparent HTTP proxy" or does it refer to something else? Sorry if > this is elementary stuff, but the term "gateway" only appears in this > paragraph. That text is present in RFC 2617; I don't understand it completely either. Maybe just drop the second half of the paragraph and only mention the thread itself? Best regards, Julian From nobody Thu Feb 19 11:32:09 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 4AB601A00D8; Thu, 19 Feb 2015 11:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWzCjzARMkiQ; Thu, 19 Feb 2015 11:32:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED82E1A008B; Thu, 19 Feb 2015 11:32:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193205.25150.54262.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:32:05 -0800 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: Thu, 19 Feb 2015 19:32:07 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Thu Feb 19 11:32:10 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 68E6C1A008B; Thu, 19 Feb 2015 11:32:07 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB601A00D8; Thu, 19 Feb 2015 11:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWzCjzARMkiQ; Thu, 19 Feb 2015 11:32:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED82E1A008B; Thu, 19 Feb 2015 11:32:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193205.25150.54262.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:32:05 -0800 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: Thu, 19 Feb 2015 19:32:07 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ From nobody Thu Feb 19 12:25:54 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 315EB1A006F; Thu, 19 Feb 2015 12:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=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 vnGKuHHgZZ1z; Thu, 19 Feb 2015 12:15:46 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7A1A00AE; Thu, 19 Feb 2015 12:15:45 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C3630F984; Thu, 19 Feb 2015 15:15:41 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id CCD091FFDD; Thu, 19 Feb 2015 15:15:38 -0500 (EST) From: Daniel Kahn Gillmor To: Julian Reschke , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org In-Reply-To: <54E6348A.3080606@gmx.de> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 19 Feb 2015 15:15:38 -0500 Message-ID: <87mw49ac9h.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 12:25:52 -0800 Cc: "http-auth@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 19 Feb 2015 20:15:48 -0000 On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: > The network exchange will be take milliseconds. The string comparison > microseconds. /me not convinced there's a problem here. as long as the attacker can measure microseconds, and the network exchange has small or regular-enough jitter to be accounted for with statistical techniques, the size difference between these parts doesn't matter to a timing attack. http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf says: The resolution an attacker can time a remote host depends on how many measurements they can collect. Our simulated attacker using statistical hypothesis testing was able to reliably distinguish a processing time differences as low as 200ns and 30µs with 1,000 measurements on the LAN and WAN respectively with. (See Section 6.) Note that salted, hashed passwords where the attacker doesn't know the salt are resistant to using a timing oracle like this to do byte-by-byte guessing. I still think it's simpler to just recommend that the tests should be constant time. >> That's true, but padding the entire HTTP request to a standard blocksize >> has different security properties than just padding this field to a >> standard blocksize, because parts of the HTTP request could be under >> control of the attacker. >> >> For example, if Alice can make Bob's user agent fetch arbitrary URLs >> from https://example.com/, then she can pass steadily increasing URLs to >> Bob's user agent (e.g. https://example.com/a https://example.com/aa >> https://example.com/aaa) and see at what point the size jumps a quantum. >> Restricting the padding to the field that is not under attacker control >> in any part should prevent this attack. > > How would the attacker be able to modify fields in the request? By changing the length of the requested URL (which is part of the request), as described above. For example, if you visit my website, i can add new elements trying to fetch whatever URLs i want you to fetch. If i can watch your traffic, i can compare the sizes of those requests. > I think it would be great to have a document that describes these > threats and how to mitigate them; in particular comparing HTTP/1.1 and > 2, but I seriously doubt this document would be the right place to do this. > > (It seems to be as relevant for cookies, no?) It does seem relevant for cookies, but this draft isn't about cookies :) If there's no document to point to, we should still acknowledge the concern here, no? > That being said, the heuristics are quite simple: try to decode the > octets with a strict UTF-8 decoder, and if that doesn't fail the input > was likely encoded in UTF-8. Some binary strings are valid in both character encodings, though, right? For example, "c3 a1 62 63" in UTF-8 is "ábc", but in ISO-8859-1, it is "ábc" So if my password is non-ASCII in the first place, it could very well match the UTF-8 encoding even though i've intended another one. So maybe the heuristic should be: even if the UTF-8 decode succeeds, the server could try its fallback decoding mechanism if the UTF-8 version of the password doesn't match. (fwiw, my understanding is that facebook checks common accidental variations on the entered password during their (non-basic-auth) login process. so if my password is b4nanAs, but i type B4NANaS or b5nanAs, facebook might let me in anyway) Is this advisable? What are the risks of testing two variants of the password against the password table? I haven't thought this through fully, but it seems like it would be a relevant consideration. In the absence of a signal from the client about their choice of encoding, documenting these heuristics and recommending them seems like a useful way to facilitate adoption and uniformity among servers implementing this spec. >> And sorry, one more question arises for me on re-read. i'm not sure i >> understand what this means: >> >> Server implementers SHOULD guard against the possibility of this sort >> of counterfeiting by gateways or CGI scripts. In particular it is >> very dangerous for a server to simply turn over a connection to a >> gateway. That gateway can then use the persistent connection >> mechanism to engage in multiple transactions with the client while >> impersonating the original server in a way that is not detectable by >> the client. >> >> How should the server guard against this attack? what sort does it mean >> to "turn over a connection to a gateway"? does "gateway" mean >> "transparent HTTP proxy" or does it refer to something else? Sorry if >> this is elementary stuff, but the term "gateway" only appears in this >> paragraph. > > That text is present in RFC 2617; I don't understand it completely either. > > Maybe just drop the second half of the paragraph and only mention the > thread itself? If we drop the second half, i'd still like to know what kind of steps a server should take to guard against the possibility of counterfeiting. If we don't have any recommendations or external references, an unactionable SHOULD seems troublesome. Regards, --dkg From nobody Thu Feb 19 12: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 994041A0151; Thu, 19 Feb 2015 12:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVYETkzL--cE; Thu, 19 Feb 2015 12:34:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 250B71A0108; Thu, 19 Feb 2015 12:34:31 -0800 (PST) Received: from [192.168.2.175] ([93.217.98.69]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQR3s-1XzCuB179g-00Toe6; Thu, 19 Feb 2015 21:34:07 +0100 Message-ID: <54E648B9.6030606@gmx.de> Date: Thu, 19 Feb 2015 21:34:01 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> In-Reply-To: <87mw49ac9h.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Kvv788L0dmvePF7IlxW5V6BljzNXa8+LYm07fsXe4+ie1uYV5F9 bxmEqVXFqDUWmeShZ42H+7Gw1jm9+tWoaoUO9s8gGdjH/z80BWdAbyPo4AuSpBDkiloNcbE Hon7ZPDx1ZibBEvk01zH3kbXxlUVsVMV2yCBS6/tj7GHhisWx/y/afC3mQ6xV20p+gJ0jO2 zyM8MjiJ1S8b0Q+5nWU6g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 19 Feb 2015 20:34:33 -0000 On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: > On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: >> The network exchange will be take milliseconds. The string comparison >> microseconds. /me not convinced there's a problem here. > > as long as the attacker can measure microseconds, and the network > exchange has small or regular-enough jitter to be accounted for with > statistical techniques, the size difference between these parts doesn't > matter to a timing attack. > > http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf > > says: > > The resolution an attacker can time a remote host depends on how many > measurements they can collect. Our simulated attacker using > statistical hypothesis testing was able to reliably distinguish a > processing time differences as low as 200ns and 30µs with 1,000 > measurements on the LAN and WAN respectively with. (See Section 6.) > > Note that salted, hashed passwords where the attacker doesn't know the > salt are resistant to using a timing oracle like this to do byte-by-byte > guessing. I still think it's simpler to just recommend that the tests > should be constant time. I'm sorry, I'm not convinced. What do others think? >>> That's true, but padding the entire HTTP request to a standard blocksize >>> has different security properties than just padding this field to a >>> standard blocksize, because parts of the HTTP request could be under >>> control of the attacker. >>> >>> For example, if Alice can make Bob's user agent fetch arbitrary URLs >>> from https://example.com/, then she can pass steadily increasing URLs to >>> Bob's user agent (e.g. https://example.com/a https://example.com/aa >>> https://example.com/aaa) and see at what point the size jumps a quantum. >>> Restricting the padding to the field that is not under attacker control >>> in any part should prevent this attack. >> >> How would the attacker be able to modify fields in the request? > > By changing the length of the requested URL (which is part of the > request), as described above. For example, if you visit my website, i > can add new elements trying to fetch whatever URLs i > want you to fetch. If i can watch your traffic, i can compare the sizes > of those requests. But the actual request is still under control of the browser. >> I think it would be great to have a document that describes these >> threats and how to mitigate them; in particular comparing HTTP/1.1 and >> 2, but I seriously doubt this document would be the right place to do this. >> >> (It seems to be as relevant for cookies, no?) > > It does seem relevant for cookies, but this draft isn't about cookies :) > If there's no document to point to, we should still acknowledge the > concern here, no? Well, I'm actually not concerned yet. If this was a problem in practice then we should have evidence, for instance, by finding padding code in user agents. I'm not saying there is none, but I do believe that if you are serious about this you ought to research yourself what the current state of implementations is. >> That being said, the heuristics are quite simple: try to decode the >> octets with a strict UTF-8 decoder, and if that doesn't fail the input >> was likely encoded in UTF-8. > > Some binary strings are valid in both character encodings, though, > right? For example, "c3 a1 62 63" in UTF-8 is "ábc", but in ISO-8859-1, > it is "ábc" So if my password is non-ASCII in the first place, it could > very well match the UTF-8 encoding even though i've intended another > one. Any octet sequence is valid in ISO-8859-1, true. If the server doesn't know whether a certain sequence is UTF-8 or ISO-8859-1, it simply could try both. > So maybe the heuristic should be: even if the UTF-8 decode succeeds, the > server could try its fallback decoding mechanism if the UTF-8 version of > the password doesn't match. (fwiw, my understanding is that facebook > checks common accidental variations on the entered password during their > (non-basic-auth) login process. so if my password is b4nanAs, but i > type B4NANaS or b5nanAs, facebook might let me in anyway) > > Is this advisable? What are the risks of testing two variants of the > password against the password table? I haven't thought this through > fully, but it seems like it would be a relevant consideration. It might. > In the absence of a signal from the client about their choice of ...which we can't have unless we switch to a new auth scheme... > encoding, documenting these heuristics and recommending them seems like > a useful way to facilitate adoption and uniformity among servers > implementing this spec. I'll think about what advice we can give here. >>> And sorry, one more question arises for me on re-read. i'm not sure i >>> understand what this means: >>> >>> Server implementers SHOULD guard against the possibility of this sort >>> of counterfeiting by gateways or CGI scripts. In particular it is >>> very dangerous for a server to simply turn over a connection to a >>> gateway. That gateway can then use the persistent connection >>> mechanism to engage in multiple transactions with the client while >>> impersonating the original server in a way that is not detectable by >>> the client. >>> >>> How should the server guard against this attack? what sort does it mean >>> to "turn over a connection to a gateway"? does "gateway" mean >>> "transparent HTTP proxy" or does it refer to something else? Sorry if >>> this is elementary stuff, but the term "gateway" only appears in this >>> paragraph. >> >> That text is present in RFC 2617; I don't understand it completely either. >> >> Maybe just drop the second half of the paragraph and only mention the >> thread itself? > > If we drop the second half, i'd still like to know what kind of steps a > server should take to guard against the possibility of counterfeiting. > If we don't have any recommendations or external references, an > unactionable SHOULD seems troublesome. I'd just say "Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not possible with other authentication schemes, such as Digest Authentication." and leave it at that. Best regards, Julian From nobody Thu Feb 19 13:49:51 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 4DF321A0270; Thu, 19 Feb 2015 13:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 5xw1SZRWcVes; Thu, 19 Feb 2015 13:49:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 EF8AB1A01FA; Thu, 19 Feb 2015 13:49:47 -0800 (PST) Received: from netb ([89.204.130.64]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lx5hl-1XVv7C0Rtx-016kCT; Thu, 19 Feb 2015 22:49:27 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Thu, 19 Feb 2015 22:49:23 +0100 Message-ID: References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> In-Reply-To: <54E648B9.6030606@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:CD8YhhO+C0BPniJG+IhXnrBF4/jObob23IS3UD8gZ25OYmJKcnT ip6QFn9F/rRZvUXkp/gOWfl5Yz14uiVgVHqoXwZ398vaNSjJ0vkekMsKSRnO/m77PzDqrlX /BiqcKYO/7UaKwvbVl4y5keShMmNY04Fba2SDxTZdWNJELMjt1tgyMtzdKG9/hFtRsHQZlk lx+Y3z9aP/s7sMWBP4OPA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, Daniel Kahn Gillmor , secdir@ietf.org Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 19 Feb 2015 21:49:50 -0000 * Julian Reschke wrote: >On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: >> On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: >>> The network exchange will be take milliseconds. The string comparison >>> microseconds. /me not convinced there's a problem here. >> >> as long as the attacker can measure microseconds, and the network >> exchange has small or regular-enough jitter to be accounted for with >> statistical techniques, the size difference between these parts doesn't >> matter to a timing attack. >> >> http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf >> >> says: >> >> The resolution an attacker can time a remote host depends on how many >> measurements they can collect. Our simulated attacker using >> statistical hypothesis testing was able to reliably distinguish a >> processing time differences as low as 200ns and 30µs with 1,000 >> measurements on the LAN and WAN respectively with. (See Section 6.) >> >> Note that salted, hashed passwords where the attacker doesn't know the >> salt are resistant to using a timing oracle like this to do byte-by-byte >> guessing. I still think it's simpler to just recommend that the tests >> should be constant time. > >I'm sorry, I'm not convinced. What do others think? I would prefer to point to an existing document for considerations such as this one, and I do not think it is entirely obvious for implementers of the scheme that comparison should take time independent of the length of the credentials, so including something brief about this makes sense to me. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Thu Feb 19 14:33:26 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 345A81A0E10; Thu, 19 Feb 2015 14:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 JvGo9P16pAIw; Thu, 19 Feb 2015 14:33:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B64E21A0470; Thu, 19 Feb 2015 14:33:22 -0800 (PST) Received: from netb ([89.204.130.64]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lv8hi-1XOSqG0AiI-010OR0; Thu, 19 Feb 2015 23:33:18 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Thu, 19 Feb 2015 23:33:13 +0100 Message-ID: <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> In-Reply-To: <54E61331.7080807@greenbytes.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:MN8jZV+gb2656LILQGCvu1+MYJavuOplZTrN+5Sz3sXrmnINfCr Q5FCZzROjMoFm+CUoiw+aYpWq8nFucl34PukE6z6YfLyHBeB4gPCaJ1Aoji+jktaVJA9EDO GI8YUjvJZ4kxb9dXaVO8BQf8T8NAGSRnVLKczxsSwJvFAp7u2W0Toer13xwLRTtjuxv7ucp wCn6vxJ6ivAb3c2WLrrCA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 22:33:25 -0000 * Julian Reschke wrote: >The problem here is the "long tail". We simply have no information about >whether these IDs exist in practice. The fact that all UAs I checked >indeed accept them at least *hints* that they might be used somewhere. >Or none of the implementers ever thought about rejecting them. > >I don't believe we can find out what the reason for this is. > >In RFC 2617, the pseudo-ABNF prose production excluded the colon, but no >additional prose requirements were present. > >In the draft, we have replaced that pseudo-ABNF by prose, and that prose >not only says "invalid" but also explains what common UAs do, and how >that might affect results. I hope everybody agrees that this is an >improvement over what we had before. The current text is: Furthermore, a user-id containing a colon character is invalid, as recipients will split the user-pass at the first occurrence of a colon character. Note that many user agents however will accept a colon in user-id, thereby producing a user-pass string that recipients will likely treat in a way not intended by the user. So if the password contains a colon, and the draft requires support for that, then what? Are recipients REQUIRED to split the string at the 1st colon? If so, then I think the current text is not adequate. If not, then it seems wrong to require support for colons in passwords. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Thu Feb 19 14:33:35 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 559041A19EF; Thu, 19 Feb 2015 14:33:25 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345A81A0E10; Thu, 19 Feb 2015 14:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 JvGo9P16pAIw; Thu, 19 Feb 2015 14:33:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B64E21A0470; Thu, 19 Feb 2015 14:33:22 -0800 (PST) Received: from netb ([89.204.130.64]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lv8hi-1XOSqG0AiI-010OR0; Thu, 19 Feb 2015 23:33:18 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Thu, 19 Feb 2015 23:33:13 +0100 Message-ID: <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> In-Reply-To: <54E61331.7080807@greenbytes.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:MN8jZV+gb2656LILQGCvu1+MYJavuOplZTrN+5Sz3sXrmnINfCr Q5FCZzROjMoFm+CUoiw+aYpWq8nFucl34PukE6z6YfLyHBeB4gPCaJ1Aoji+jktaVJA9EDO GI8YUjvJZ4kxb9dXaVO8BQf8T8NAGSRnVLKczxsSwJvFAp7u2W0Toer13xwLRTtjuxv7ucp wCn6vxJ6ivAb3c2WLrrCA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 22:33:25 -0000 * Julian Reschke wrote: >The problem here is the "long tail". We simply have no information about >whether these IDs exist in practice. The fact that all UAs I checked >indeed accept them at least *hints* that they might be used somewhere. >Or none of the implementers ever thought about rejecting them. > >I don't believe we can find out what the reason for this is. > >In RFC 2617, the pseudo-ABNF prose production excluded the colon, but no >additional prose requirements were present. > >In the draft, we have replaced that pseudo-ABNF by prose, and that prose >not only says "invalid" but also explains what common UAs do, and how >that might affect results. I hope everybody agrees that this is an >improvement over what we had before. The current text is: Furthermore, a user-id containing a colon character is invalid, as recipients will split the user-pass at the first occurrence of a colon character. Note that many user agents however will accept a colon in user-id, thereby producing a user-pass string that recipients will likely treat in a way not intended by the user. So if the password contains a colon, and the draft requires support for that, then what? Are recipients REQUIRED to split the string at the 1st colon? If so, then I think the current text is not adequate. If not, then it seems wrong to require support for colons in passwords. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Thu Feb 19 14:35:48 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 424421A19F6; Thu, 19 Feb 2015 14:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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_15=0.6, 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 77NUDb--0pPk; Thu, 19 Feb 2015 14:35:40 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C1C1A19EF; Thu, 19 Feb 2015 14:35:39 -0800 (PST) Received: by labhz20 with SMTP id hz20so2730101lab.0; Thu, 19 Feb 2015 14:35:38 -0800 (PST) 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=SjiFlI5FRJHXqrVp2B//4u/Um62s5AKQTEmwVWtFkU0=; b=snkj+tw1LpiX9/kV7+PSTEVtExGHRuDEUQRAwgXvOty4HQdEElIQASA1j0HjwtT8mQ 3PYKYJ9PHJIjoGKNpJOJpepCJiGeBp5Cil4BE22NEqmOyzVkWvZy5kIKfCAF9lgKfNoT MMbGtqJcaCvBO6nryYgGWwJOYloqYsfS9etEThnr+WVFqBvOydcQbHAOw+004W8zo5nT LIf3wMZRUv8QkuW10R48WhUn6R5B6QS60Mt3+QnDXJgr26ij1db8ie8HfFbaFLnJ+Mua WXSiLjMzlENT6FYF1981y08DCI4wbpHlwQtghsxt41Zcm6j9laSdYVGdQmA6L0/qGj8V o5Qw== MIME-Version: 1.0 X-Received: by 10.152.8.229 with SMTP id u5mr6080432laa.4.1424385338299; Thu, 19 Feb 2015 14:35:38 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 19 Feb 2015 14:35:38 -0800 (PST) In-Reply-To: <54E648B9.6030606@gmx.de> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> Date: Thu, 19 Feb 2015 17:35:38 -0500 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=089e0158ab601cdabc050f788eab Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, "iesg@ietf.org" , Daniel Kahn Gillmor , "secdir@ietf.org" Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 19 Feb 2015 22:35:44 -0000 --089e0158ab601cdabc050f788eab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel, Thanks for much for the detailed review and discussion! It may be helpful to document some of these concerns in another draft and see what we can do to improve going forward. Would you be up for that? Julian, Thanks for the discussion. I think we are close to addressing the concerns raised and that we can let some slip for this draft since it was meant to be an update to address internationalization concerns. It does already say this isn't a secure choice and this review adds more reasons for that concern. The rest is inline. On Thu, Feb 19, 2015 at 3:34 PM, Julian Reschke wrote: > On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: > >> On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: >> >>> The network exchange will be take milliseconds. The string comparison >>> microseconds. /me not convinced there's a problem here. >>> >> >> as long as the attacker can measure microseconds, and the network >> exchange has small or regular-enough jitter to be accounted for with >> statistical techniques, the size difference between these parts doesn't >> matter to a timing attack. >> >> http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf >> >> says: >> >> The resolution an attacker can time a remote host depends on how man= y >> measurements they can collect. Our simulated attacker using >> statistical hypothesis testing was able to reliably distinguish a >> processing time differences as low as 200ns and 30=C2=B5s with 1,000 >> measurements on the LAN and WAN respectively with. (See Section 6.) >> >> Note that salted, hashed passwords where the attacker doesn't know the >> salt are resistant to using a timing oracle like this to do byte-by-byte >> guessing. I still think it's simpler to just recommend that the tests >> should be constant time. >> > > I'm sorry, I'm not convinced. What do others think? I think it's okay to leave out mention of side channel attacks like this timing attack. It might be useful in a follow up draft or if this were earlier in the process. > > > That's true, but padding the entire HTTP request to a standard blocksize >>>> has different security properties than just padding this field to a >>>> standard blocksize, because parts of the HTTP request could be under >>>> control of the attacker. >>>> >>>> For example, if Alice can make Bob's user agent fetch arbitrary URLs >>>> from https://example.com/, then she can pass steadily increasing URLs >>>> to >>>> Bob's user agent (e.g. https://example.com/a https://example.com/aa >>>> https://example.com/aaa) and see at what point the size jumps a >>>> quantum. >>>> Restricting the padding to the field that is not under attacker contro= l >>>> in any part should prevent this attack. >>>> >>> >>> How would the attacker be able to modify fields in the request? >>> >> >> By changing the length of the requested URL (which is part of the >> request), as described above. For example, if you visit my website, i >> can add new elements trying to fetch whatever URLs i >> want you to fetch. If i can watch your traffic, i can compare the sizes >> of those requests. >> > > But the actual request is still under control of the browser. > > I think it would be great to have a document that describes these >>> threats and how to mitigate them; in particular comparing HTTP/1.1 and >>> 2, but I seriously doubt this document would be the right place to do >>> this. >>> >>> (It seems to be as relevant for cookies, no?) >>> >> >> It does seem relevant for cookies, but this draft isn't about cookies :) >> If there's no document to point to, we should still acknowledge the >> concern here, no? >> > > Well, I'm actually not concerned yet. If this was a problem in practice > then we should have evidence, for instance, by finding padding code in us= er > agents. I'm not saying there is none, but I do believe that if you are > serious about this you ought to research yourself what the current state = of > implementations is. I think it's okay to leave this out for now as well, may be material for another draft. Basic is used in lots of places still, so understanding all the bad things about it may help inspire people to switch to something else (says optimistic SecAD). > > > That being said, the heuristics are quite simple: try to decode the >>> octets with a strict UTF-8 decoder, and if that doesn't fail the input >>> was likely encoded in UTF-8. >>> >> >> Some binary strings are valid in both character encodings, though, >> right? For example, "c3 a1 62 63" in UTF-8 is "=C3=A1bc", but in ISO-88= 59-1, >> it is "=C3=83=C2=A1bc" So if my password is non-ASCII in the first place= , it could >> very well match the UTF-8 encoding even though i've intended another >> one. >> > > Any octet sequence is valid in ISO-8859-1, true. > > If the server doesn't know whether a certain sequence is UTF-8 or > ISO-8859-1, it simply could try both. > > So maybe the heuristic should be: even if the UTF-8 decode succeeds, the >> server could try its fallback decoding mechanism if the UTF-8 version of >> the password doesn't match. (fwiw, my understanding is that facebook >> checks common accidental variations on the entered password during their >> (non-basic-auth) login process. so if my password is b4nanAs, but i >> type B4NANaS or b5nanAs, facebook might let me in anyway) >> >> Is this advisable? What are the risks of testing two variants of the >> password against the password table? I haven't thought this through >> fully, but it seems like it would be a relevant consideration. >> > > It might. > > In the absence of a signal from the client about their choice of >> > > ...which we can't have unless we switch to a new auth scheme... Another draft might be good... > > > encoding, documenting these heuristics and recommending them seems like >> a useful way to facilitate adoption and uniformity among servers >> implementing this spec. >> > > I'll think about what advice we can give here. > > And sorry, one more question arises for me on re-read. i'm not sure i >>>> understand what this means: >>>> >>>> Server implementers SHOULD guard against the possibility of this >>>> sort >>>> of counterfeiting by gateways or CGI scripts. In particular it i= s >>>> very dangerous for a server to simply turn over a connection to a >>>> gateway. That gateway can then use the persistent connection >>>> mechanism to engage in multiple transactions with the client whil= e >>>> impersonating the original server in a way that is not detectable >>>> by >>>> the client. >>>> >>>> How should the server guard against this attack? what sort does it me= an >>>> to "turn over a connection to a gateway"? does "gateway" mean >>>> "transparent HTTP proxy" or does it refer to something else? Sorry if >>>> this is elementary stuff, but the term "gateway" only appears in this >>>> paragraph. >>>> >>> >>> That text is present in RFC 2617; I don't understand it completely >>> either. >>> >>> Maybe just drop the second half of the paragraph and only mention the >>> thread itself? >>> >> >> If we drop the second half, i'd still like to know what kind of steps a >> server should take to guard against the possibility of counterfeiting. >> If we don't have any recommendations or external references, an >> unactionable SHOULD seems troublesome. >> > > I'd just say > > "Basic Authentication is also vulnerable to spoofing by counterfeit > servers. If a user can be led to believe that he is connecting to a host > containing information protected by Basic authentication when, in fact, h= e > is connecting to a hostile server or gateway, then the attacker can reque= st > a password, store it for later use, and feign an error. This type of atta= ck > is not possible with other authentication schemes, such as Digest > Authentication." > > and leave it at that. The text proposal looks reasonable. I'll go back through the original review to make sure nothing was missed. Thanks again!! Kathleen > > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --=20 Best regards, Kathleen --089e0158ab601cdabc050f788eab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Daniel,

Thanks for much for the detaile= d review and discussion!=C2=A0 It may be helpful to document some of these = concerns in another draft and see what we can do to improve going forward.= =C2=A0 Would you be up for that? =C2=A0

Julian,

Thanks for the discussion.=C2=A0 I think we are clos= e to addressing the concerns raised and that we can let some slip for this = draft since it was meant to be an update to address internationalization co= ncerns.=C2=A0 It does already say this isn't a secure choice and this r= eview adds more reasons for that concern.

The rest= is inline. =C2=A0

On Thu, Feb 19, 2015 at 3:34 PM, Julian Reschke &l= t;julian.reschke= @gmx.de> wrote:
On 2015-02-19 21:15, Daniel Kahn Gillmor wrote:
On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote:
The network exchange will be take milliseconds. The string comparison
microseconds. /me not convinced there's a problem here.

as long as the attacker can measure microseconds, and the network
exchange has small or regular-enough jitter to be accounted for with
statistical techniques, the size difference between these parts doesn't=
matter to a timing attack.

=C2=A0 =C2=A0http://www.cs.rice.edu/~dwallach/pub/cros= by-timing2009.pdf

says:

=C2=A0 =C2=A0 The resolution an attacker can time a remote host depends on = how many
=C2=A0 =C2=A0 measurements they can collect. Our simulated attacker using =C2=A0 =C2=A0 statistical hypothesis testing was able to reliably distingui= sh a
=C2=A0 =C2=A0 processing time differences as low as 200ns and 30=C2=B5s wit= h 1,000
=C2=A0 =C2=A0 measurements on the LAN and WAN respectively with. (See Secti= on 6.)

Note that salted, hashed passwords where the attacker doesn't know the<= br> salt are resistant to using a timing oracle like this to do byte-by-byte guessing.=C2=A0 I still think it's simpler to just recommend that the t= ests
should be constant time.

 I'm sorry, I'm not convinced. What do others think?

I think it's okay to leave out mention of side channel= attacks like this timing attack.=C2=A0 It might be useful in a follow up d= raft or if this were earlier in the process.=C2=A0


That's true, but padding the entire HTTP request to a standard blocksiz= e
has different security properties than just padding this field to a
standard blocksize, because parts of the HTTP request could be under
control of the attacker.

For example, if Alice can make Bob's user agent fetch arbitrary URLs from https://example.com= /, then she can pass steadily increasing URLs to
Bob's user agent (e.g. https://example.com/a https://example.com/aa
https://example.com/a= aa) and see at what point the size jumps a quantum.
Restricting the padding to the field that is not under attacker control
in any part should prevent this attack.

How would the attacker be able to modify fields in the request?

By changing the length of the requested URL (which is part of the
request), as described above.=C2=A0 For example, if you visit my website, i=
can add new <img src=3D"..."> elements trying to fetch what= ever URLs i
want you to fetch.=C2=A0 If i can watch your traffic, i can compare the siz= es
of those requests.

 But the actual request is still under control of the browser.

I think it would be great to have a document that describes these
threats and how to mitigate them; in particular comparing HTTP/1.1 and
2, but I seriously doubt this document would be the right place to do this.=

(It seems to be as relevant for cookies, no?)

It does seem relevant for cookies, but this draft isn't about cookies := )
If there's no document to point to, we should still acknowledge the
concern here, no?

 Well, I'm actually not concerned yet. If this was a problem in practice= then we should have evidence, for instance, by finding padding code in use= r agents. I'm not saying there is none, but I do believe that if you ar= e serious about this you ought to research yourself what the current state = of implementations is.

I think it's oka= y to leave this out for now as well, may be material for another draft.=C2= =A0 Basic is used in lots of places still, so understanding all the bad thi= ngs about it may help inspire people to switch to something else (says opti= mistic SecAD).
=C2=A0


That being said, the heuristics are quite simple: try to decode the
octets with a strict UTF-8 decoder, and if that doesn't fail the input<= br> was likely encoded in UTF-8.

Some binary strings are valid in both character encodings, though,
right?=C2=A0 For example, "c3 a1 62 63" in UTF-8 is "=C3=A1b= c", but in ISO-8859-1,
it is "=C3=83=C2=A1bc" So if my password is non-ASCII in the firs= t place, it could
very well match the UTF-8 encoding even though i've intended another one.

 Any octet sequence is valid in ISO-8859-1, true.

If the server doesn't know whether a certain sequence is UTF-8 or ISO-8= 859-1, it simply could try both.

So maybe the heuristic should be: even if the UTF-8 decode succeeds, the server could try its fallback decoding mechanism if the UTF-8 version of the password doesn't match.=C2=A0 (fwiw, my understanding is that faceb= ook
checks common accidental variations on the entered password during their (non-basic-auth) login process.=C2=A0 so if my password is b4nanAs, but i type B4NANaS or b5nanAs, facebook might let me in anyway)

Is this advisable?=C2=A0 What are the risks of testing two variants of the<= br> password against the password table?=C2=A0 I haven't thought this throu= gh
fully, but it seems like it would be a relevant consideration.

 It might.

In the absence of a signal from the client about their choice of

 ...which we can't have unless we switch to a new auth scheme...

Another draft might be good...=C2=A0


encoding, documenting these heuristics and recommending them seems like
a useful way to facilitate adoption and uniformity among servers
implementing this spec.

 I'll think about what advice we can give here.

And sorry, one more question arises for me on re-read. i'm not sure i understand what this means:

=C2=A0 =C2=A0 =C2=A0Server implementers SHOULD guard against the possibilit= y of this sort
=C2=A0 =C2=A0 =C2=A0of counterfeiting by gateways or CGI scripts.=C2=A0 In = particular it is
=C2=A0 =C2=A0 =C2=A0very dangerous for a server to simply turn over a conne= ction to a
=C2=A0 =C2=A0 =C2=A0gateway.=C2=A0 That gateway can then use the persistent= connection
=C2=A0 =C2=A0 =C2=A0mechanism to engage in multiple transactions with the c= lient while
=C2=A0 =C2=A0 =C2=A0impersonating the original server in a way that is not = detectable by
=C2=A0 =C2=A0 =C2=A0the client.

How should the server guard against this attack?=C2=A0 what sort does it me= an
to "turn over a connection to a gateway"?=C2=A0 does "gatewa= y" mean
"transparent HTTP proxy" or does it refer to something else?=C2= =A0 Sorry if
this is elementary stuff, but the term "gateway" only appears in = this
paragraph.

That text is present in RFC 2617; I don't understand it completely eith= er.

Maybe just drop the second half of the paragraph and only mention the
thread itself?

If we drop the second half, i'd still like to know what kind of steps a=
server should take to guard against the possibility of counterfeiting.
If we don't have any recommendations or external references, an
unactionable SHOULD seems troublesome.

 I'd just say

"Basic Authentication is also vulnerable to spoofing by counterfeit se= rvers. If a user can be led to believe that he is connecting to a host cont= aining information protected by Basic authentication when, in fact, he is c= onnecting to a hostile server or gateway, then the attacker can request a p= assword, store it for later use, and feign an error. This type of attack is= not possible with other authentication schemes, such as Digest Authenticat= ion."

and leave it at that.

The text proposal loo= ks reasonable. I'll go back through the original review to make sure no= thing was missed.

Thanks again!!

Kathleen
=


Best regards, Julian

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



--
=

Best regards,
Kathleen
--089e0158ab601cdabc050f788eab-- From nobody Thu Feb 19 14:43:27 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 2C4DA1A0097; Thu, 19 Feb 2015 14:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QyEVispAwXVP; Thu, 19 Feb 2015 14:43:24 -0800 (PST) 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 12E7E1A0007; Thu, 19 Feb 2015 14:43:24 -0800 (PST) Received: from [192.168.2.175] ([93.217.98.69]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MAyVY-1YEdf9194G-009xiO; Thu, 19 Feb 2015 23:43:19 +0100 Message-ID: <54E66703.50207@gmx.de> Date: Thu, 19 Feb 2015 23:43:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> In-Reply-To: <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7y1s6ZIw2x1hMpTr/jug+mXuMw4f5OV961+aHgnCq91PZvRKhB/ Nx1Jn2+y/JNvlZbIpQOz/Ke8UIIWzQkF1TJPc0KWXDIx/sI92tL8Ytj/I+0YFysubOBVFwp 6wBRYQF0WZO9Pay2/3YDeMi5PKLSXkgSCS2jeHceGBbmH8d//WaxIfN+nNUHkQ+4Ok8UUD3 +wuJCXZrimPAnFWhn34WQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 22:43:26 -0000 On 2015-02-19 23:33, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> The problem here is the "long tail". We simply have no information about >> whether these IDs exist in practice. The fact that all UAs I checked >> indeed accept them at least *hints* that they might be used somewhere. >> Or none of the implementers ever thought about rejecting them. >> >> I don't believe we can find out what the reason for this is. >> >> In RFC 2617, the pseudo-ABNF prose production excluded the colon, but no >> additional prose requirements were present. >> >> In the draft, we have replaced that pseudo-ABNF by prose, and that prose >> not only says "invalid" but also explains what common UAs do, and how >> that might affect results. I hope everybody agrees that this is an >> improvement over what we had before. > > The current text is: > > Furthermore, a user-id containing a colon character is invalid, as > recipients will split the user-pass at the first occurrence of a > colon character. Note that many user agents however will accept a > colon in user-id, thereby producing a user-pass string that > recipients will likely treat in a way not intended by the user. > > So if the password contains a colon, and the draft requires support for > that, then what? Are recipients REQUIRED to split the string at the 1st > colon? If so, then I think the current text is not adequate. If not, > then it seems wrong to require support for colons in passwords. I think they are required to split on the first colon; why do you think the current text is inadequate? Best regards, Julian From nobody Thu Feb 19 14:43:36 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 55ECF1A00B1; Thu, 19 Feb 2015 14:43:26 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4DA1A0097; Thu, 19 Feb 2015 14:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QyEVispAwXVP; Thu, 19 Feb 2015 14:43:24 -0800 (PST) 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 12E7E1A0007; Thu, 19 Feb 2015 14:43:24 -0800 (PST) Received: from [192.168.2.175] ([93.217.98.69]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MAyVY-1YEdf9194G-009xiO; Thu, 19 Feb 2015 23:43:19 +0100 Message-ID: <54E66703.50207@gmx.de> Date: Thu, 19 Feb 2015 23:43:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> In-Reply-To: <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7y1s6ZIw2x1hMpTr/jug+mXuMw4f5OV961+aHgnCq91PZvRKhB/ Nx1Jn2+y/JNvlZbIpQOz/Ke8UIIWzQkF1TJPc0KWXDIx/sI92tL8Ytj/I+0YFysubOBVFwp 6wBRYQF0WZO9Pay2/3YDeMi5PKLSXkgSCS2jeHceGBbmH8d//WaxIfN+nNUHkQ+4Ok8UUD3 +wuJCXZrimPAnFWhn34WQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 22:43:26 -0000 On 2015-02-19 23:33, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> The problem here is the "long tail". We simply have no information about >> whether these IDs exist in practice. The fact that all UAs I checked >> indeed accept them at least *hints* that they might be used somewhere. >> Or none of the implementers ever thought about rejecting them. >> >> I don't believe we can find out what the reason for this is. >> >> In RFC 2617, the pseudo-ABNF prose production excluded the colon, but no >> additional prose requirements were present. >> >> In the draft, we have replaced that pseudo-ABNF by prose, and that prose >> not only says "invalid" but also explains what common UAs do, and how >> that might affect results. I hope everybody agrees that this is an >> improvement over what we had before. > > The current text is: > > Furthermore, a user-id containing a colon character is invalid, as > recipients will split the user-pass at the first occurrence of a > colon character. Note that many user agents however will accept a > colon in user-id, thereby producing a user-pass string that > recipients will likely treat in a way not intended by the user. > > So if the password contains a colon, and the draft requires support for > that, then what? Are recipients REQUIRED to split the string at the 1st > colon? If so, then I think the current text is not adequate. If not, > then it seems wrong to require support for colons in passwords. I think they are required to split on the first colon; why do you think the current text is inadequate? Best regards, Julian From nobody Thu Feb 19 14:55:04 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 16CA31A00B8; Thu, 19 Feb 2015 14:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 UJOOwunlN0TH; Thu, 19 Feb 2015 14:54:56 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 C339E1A00B1; Thu, 19 Feb 2015 14:54:55 -0800 (PST) Received: by lbjb6 with SMTP id b6so3000746lbj.2; Thu, 19 Feb 2015 14:54:54 -0800 (PST) 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=iczfq9dYapAD2i74vXLIDPtS19CiI2xeJ4O4qzUzgZs=; b=tzzxaEyFzQ3b2CjFcRdikvOTt98gQnEL/2VnZ4H7FZpU7u1j0p2DnxD3a0Fwe+u/qQ pnaOWSKWBkwEr1uDjs+6RCVsu4SVQVhnbblW9KDt7DtfixUupt0SQ0lI+HEWsrM0E/gl GFMam00OrMU8T8aHhO4FmNO3j6QBJDz/nohCY8tI0hnb5J3YfAyIuw3WfR8f/z9n++gL N0wcwf7hOhibzsKGFoB2oDvjMefiB2mQAqz5F0BVRzUCKQaDvAEleQ1bJxB4Y2ECMble WvqtbqBc1LGJJvjMCSn0ph/bvZvQ0JKC77t6Lx6OTJhp6i8/IWslIAabXfPTlPwCg0dQ OViw== MIME-Version: 1.0 X-Received: by 10.152.8.229 with SMTP id u5mr6133221laa.4.1424386493873; Thu, 19 Feb 2015 14:54:53 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 19 Feb 2015 14:54:53 -0800 (PST) In-Reply-To: <54E6348A.3080606@gmx.de> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> Date: Thu, 19 Feb 2015 17:54:53 -0500 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=089e0158ab60fd85ab050f78d2d4 Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, "iesg@ietf.org" , Daniel Kahn Gillmor , "secdir@ietf.org" Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 19 Feb 2015 22:55:03 -0000 --089e0158ab60fd85ab050f78d2d4 Content-Type: text/plain; charset=UTF-8 > > This part of the thread resulted in a few more changes, I'm ok with them as noted below and just want to track this and add an RFC editor note on the reference concern. Thanks! On Thu, Feb 19, 2015 at 2:07 PM, Julian Reschke wrote: > On 2015-02-19 19:22, Daniel Kahn Gillmor wrote: > >> Hi Julian-- >> >> Thanks for the prompt response! My own are inline below. >> >> On Wed 2015-02-18 17:18:43 -0500, Julian Reschke wrote: >> >>> On 2015-02-18 09:15, Daniel Kahn Gillmor wrote: >>> >>>> ... >>>> Should recommend strong password-hashing on the server side >>>> ----------------------------------------------------------- >>>> >>>> The Security Considerations section acknowledges that passwords can be >>>> stolen from servers, but does not encourage server operators to hash >>>> stored passwords with a reasonable or strong algorithm. This document >>>> may not be the place to provide normative guidance on how to store >>>> passwords to mitigate the exposure of a password table, but perhaps a >>>> brief mention and an informative reference would be useful? Many >>>> systems (e.g. modern nginx and apache) use 1000 iterations of salted >>>> MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, >>>> which are all terrible. >>>> >>>> https://httpd.apache.org/docs/2.4/misc/password_encryptions.html >>>> http://nginx.org/en/docs/http/ngx_http_auth_basic_module. >>>> html#auth_basic_user_file >>>> >>>> an informative reference might point to the Password Hashing >>>> Competition, which documents sensible rationales for why you should use >>>> strong password hashing, and how to know it when you see it: >>>> >>>> https://password-hashing.net >>>> >>>> by comparison the digest draft has a lot more about how passwords should >>>> be stored (even though Digest auth can offer only weaker protections for >>>> the password store compared to Basic auth): >>>> >>>> https://tools.ietf.org/html/draft-ietf-httpauth-digest-13# >>>> section-5.2 >>>> ... >>>> >>> >>> I would really like to avoid talking about threads that are generic to >>> password-based authentication. Optimally, the security area would have a >>> document that discusses exactly these kind of things so that other specs >>> can reference that. Does something like this exist? >>> >> >> These threats aren't generic to password-based authentication. they're >> specific to the *type* of password-based authentication used by HTTP >> basic auth. For example HTTP Digest and PAKE schemes are both >> password-based, but have different properties, different requirements >> for the password store, and different threats. >> >> I don't know if there is an IETF document that describes >> password-hashing best-practices or formats. Maybe someone else knows? >> >> Or do you want to propose concrete text? >>> >> >> I don't have the bandwidth to craft something fancy right now, but >> here's a first stab that you're welcome to carve up as you see fit, if >> no IETF references are forthcoming: >> >> Servers and proxies requiring Basic Authentication must store user >> passwords in some form in order to verify the request's >> Authorization: header. These passwords should be stored in such a >> way that a leak of the password table doesn't make them trivially >> recoverable. This is especially when users are allowed to set their >> own passwords, since users are known to choose weak passwords and to >> reuse them across authentication realms. While a full discussion of >> good password hashing techniques for HTTP Basic Authentication is >> beyond the scope of this document, server operators should make an >> effort to minimize risks to their users in the event of a password >> table leak. For example, servers should not store user passwords in >> plaintext or as unsalted digests. For more discussion about modern >> password hashing techniques, see [PHC]. >> >> [PHC] https://password-hashing.net Password Hashing Competition >> >> (i've used "should not" instead of RFC 2119 "SHOULD NOT" above because >> this is not a recommendation about the on-the-wire protocol. If anyone >> thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to >> see that happen, because this is seriously low-hanging fruit, and i'm >> sure there are still operators out there disregarding it. >> > > I like the text, and I'm ok with including it or a variation of it. I'm > not 100% convinced that the RFC Editor will be ok with the citation. OK, this looks good as well, thanks. We'll figure out the reference as we go. I can make an RFC editor note on it so we don't forget to figure it out. > > > Should recommend constant-time server-side comparisons >>>> ------------------------------------------------------ >>>> >>>> Servers that implement basic auth should not leak information about >>>> the stored password via timing of rejections. For example, a server >>>> that stored cleartext passwords (which is a bad idea anyway) should >>>> mechanically compare the entire string instead of bytewise comparisons. >>>> The attack here is an attacker who guesses credentials a byte at a time, >>>> by making 256 initial guesses and seeing which of them gets back a >>>> rejection faster than the other (and iterates down the list). >>>> >>>> This might be less of an issue for reasonable (non-cleartext) password >>>> storage, but if we're not requiring strong password hashing, we should >>>> at least require constant time comparisons. >>>> >>> >>> Do you seriously believe that the time for a string comparison is >>> relevant compared to the overhead of two network hops plus encapsulation >>> into HTTP messages? >>> >> >> If the transport framework (network hops plus encapsulation into HTTP >> messages) has no jitter, then the ratio of timing between string >> comparison and the transport framework overhead is irrelevant; an >> attacker just cares about difference, not magnitude. Even with some >> small jitter, statistical analyses over many connections could yield >> information. >> >> Do i expect the transport framework to be jitter-free in the real world? >> Usually, no. But do you want the security of the scheme to depend on >> the transport framework having jitter? >> >> If this is a security consideration, would you rather say "deploy this >> only over jittery transports" or "don't leak timing information when you >> compare passwords"? The latter seems simpler and clearer to me. >> > > The network exchange will be take milliseconds. The string comparison > microseconds. /me not convinced there's a problem here. > > > > Should recommend padding the Authorization: response >>>> ---------------------------------------------------- >>>> >>>> When used behind HTTPS as recommended, TLS hides the username and >>>> password presented. However, it does not hide the length of the >>>> username and password if the other parameters of the HTTPS request are >>>> known. >>>> >>>> An active attacker who wants to learn the length of the victim's >>>> username and password together for a particular basic auth realm could >>>> force the user's browser to make HTTPS requests to a few different URLs >>>> within the realm and see how large the packets are. >>>> >>>> This could be mitigated by including whitespace padding in the client's >>>> Authorization: header itself up to some multiple of a blocksize (perhaps >>>> 256B) to obscure the length. >>>> >>> >>> Actually, padding can happen anywhere in the message; it doesn't need to >>> be in this header field. >>> >> >> That's true, but padding the entire HTTP request to a standard blocksize >> has different security properties than just padding this field to a >> standard blocksize, because parts of the HTTP request could be under >> control of the attacker. >> >> For example, if Alice can make Bob's user agent fetch arbitrary URLs >> from https://example.com/, then she can pass steadily increasing URLs to >> Bob's user agent (e.g. https://example.com/a https://example.com/aa >> https://example.com/aaa) and see at what point the size jumps a quantum. >> Restricting the padding to the field that is not under attacker control >> in any part should prevent this attack. >> > > How would the attacker be able to modify fields in the request? > > I think it would be great to have a document that describes these threats > and how to mitigate them; in particular comparing HTTP/1.1 and 2, but I > seriously doubt this document would be the right place to do this. > > (It seems to be as relevant for cookies, no?) > > > > It's an interesting idea; have you checked whether existing User Agents >>> do this? >>> >> >> I don't know whether any existing User Agents do this, sorry. >> >> UTF-8 security considerations by reference: is this OK? >>>> ------------------------------------------ >>>> >>>> The Security Considerations section includes the UTF-8 security >>>> considerations section by reference, but doesn't call out any specific >>>> issues for implementers to be aware of. the NFC canonicalization draft >>>> >>> >>> Intentionally. >>> >>> also has Security Considersations section, which is not included by >>>> reference: >>>> >>>> https://tools.ietf.org/html/rfc5198#section-6 >>>> >>> >>> I'll add that. >>> >> >> cool, thanks! >> > Good, thanks for this addition as well. > >> >> Interaction with proxies? >>>> ------------------------- >>>> >>>> There is only a passing mention of Proxy-Authenticate: and >>>> Proxy-Authorization: headers, so one assumes that both mechanisms should >>>> support this new auth-param. It's not clear to me whether there are any >>>> additional security or privacy implications when this is addressed to >>>> proxies compared to origin servers. >>>> >>> >>> I'm not aware of any. >>> >>> Section 2.2 ("reusing credentials") talks about the URI path (presumably >>>> for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the >>>> middle of that commentary. It looks to me like "Proxy-Authenticate" is >>>> not intended to be scoped by the URI path (there is no mention of "in >>>> that space" in the sentence about Proxy-Authenticate in Section 2.2), >>>> but this is kind of ambiguous. Clarification would be good. >>>> >>> >>> To be frank, I don't know. My best guess is that it works exactly the >>> same, so I'll add "in that space" there as well. >>> >> >> This ambiguity worries me a bit; should we take this opportunity to >> clear it up to match what happens in practice? It seems like we should >> have some people with operational experience on this who could provide >> clarification here, but i'm not one of them. >> > > Nor am I. > > I do agree that proxy authentication needs better documentation, but > that's a problem of RFC 7235, not this spec. > > > Path matching? >>>> -------------- >>>> >>>> Nothing in the security considerations section talks about the threat >>>> that motivates path matching for determination of which realm to use. >>>> It might be useful to spell this out explicitly: >>>> >>>> * A user agent that sends the Authorization: header to URLs outside >>>> the >>>> authentication scope as described in Section 2.2 may leak the >>>> user's >>>> credentials >>>> >>> >>> That applies to all schemes that use protection spaces and is mentioned >>> in >>> already. >>> >>> User Agent visibility and logout? >>>> --------------------------------- >>>> >>>> Most RFCs don't talk at all about the human interface of the mentioned >>>> tools. >>>> >>>> But this draft refers briefly to interaction between the user and the >>>> User Agent (see step 1 on >>>> https://tools.ietf.org/html/draft-ietf-httpauth-basicauth- >>>> update-06#page-6). >>>> However, it provides no other guidance. There are several additional >>>> guidelines that make basic authentication more acceptable from a privacy >>>> and security point of view for a typical web browser User Agent: >>>> >>>> * user agents should indicate to the user when they are re-using the >>>> user's authentication credentials as described in section 2.2 >>>> (indicating the realm, authentication scope, and user-id?) >>>> >>> >>> They don't right now. Do you believe that requiring it will have any >>> effect on existing UAs? >>> >> >> i don't know, but i'd certainly like to see that happen. If it doesn't >> happen, perhaps we need to mention in Security Considerations that User >> Agents which do not indicate to the user when they are reusing the >> user's credentials risk leaking those credentials without the user >> knowing that it's happening? >> > > We could say that (text welcome), but I seriously doubt it will affect > what software does. The current trend is to remove as much UI as possible > (or even all on mobile), so asking for this indicator is really wishful > thinking. > > * user agents should not display the user's password anywhere by >>>> default >>>> >>> >>> That sounds pretty obvious. >>> >> >> I agree! Maybe we don't need to say obvious things? >> >> * user agents should make it straightforward for users to clear their >>>> credentials for any . >>>> >>> >>> Define "straightforward". >>> >> >> That probably depends on the type of user agent, no? as a suggestion, >> this seems like it could be something that we encourage without >> specifying concrete mechanism. >> > > Again, we're talking about code that has been written almost 20 years ago. > New advice on nice-to-haves will not have any effect on these > implementations. > > https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these >>>> guidelines; perhaps this is another include-by-reference? >>>> >>> >>> All security considerations of RFC 7235 apply by definition, as this >>> spec is using the framework defined by RFC 7235. I don't believe that we >>> need to state this. >>> >> >> It wasn't immediately obvious to me that all security considerations of >> RFC 7235 apply by definition, but now that you say it it makes sense. >> >> Do you think that an implementor of HTTP basic auth with less experience >> reading RFCs is going to understand that? >> > > An implementor of this spec will need to read and understand RFC 7235. So, > yes. > > Other Considerations >>>> ==================== >>>> >>>> Deployment chicken-and-egg >>>> -------------------------- >>>> >>>> The server has no way of knowing that the client is trying to obey the >>>> charset header. For the servers mentioned in that do user-agent >>>> >>> >>> Actually, it could apply heuristics. I header detection of UTF-8 is >>> quire reliable. >>> >> >> What heuristics should it apply? If there is a standard set of >> heuristics we expect servers to use, we should put them in this >> document. >> > > I don't *expect* servers to use heuristics. > > That being said, the heuristics are quite simple: try to decode the octets > with a strict UTF-8 decoder, and if that doesn't fail the input was likely > encoded in UTF-8. > > sniffing, it's not clear how those servers could ever know to stop >>>> relying on the user-agent, since the clients have no way of signalling >>>> their intent to use UTF-8 for the Authorization header. If the servers >>>> don't know when to start accepting UTF-8 from these clients, then the >>>> clients also have no way of knowing when they should switch over >>>> themselves. This strikes me as a recipe for stalled adoption, since >>>> "user agents in the latter group" (from section B.3) will never use >>>> UTF-8, even if they know about it. >>>> >>> >>> I don't see why the server can't just start accepting UTF-8 right away. >>> >> >> >> Because "User agents in the latter group will have to continue to do >> what they do today", so the servers will need to interpret the response >> in the same way. If you mean to say that 'User agents in the latter >> group will have to continue to do what they do today unless the server >> has sent charset="UTF-8"' then please say so explicitly. >> > > No, that's not what I meant. > > By "accepting UTF-8" I mean "trying to decode as UTF-8" in addition to > what the server is already doing; basically a trial-and-error approach. > > And sorry, one more question arises for me on re-read. i'm not sure i >> understand what this means: >> >> Server implementers SHOULD guard against the possibility of this sort >> of counterfeiting by gateways or CGI scripts. In particular it is >> very dangerous for a server to simply turn over a connection to a >> gateway. That gateway can then use the persistent connection >> mechanism to engage in multiple transactions with the client while >> impersonating the original server in a way that is not detectable by >> the client. >> >> How should the server guard against this attack? what sort does it mean >> to "turn over a connection to a gateway"? does "gateway" mean >> "transparent HTTP proxy" or does it refer to something else? Sorry if >> this is elementary stuff, but the term "gateway" only appears in this >> paragraph. >> > > That text is present in RFC 2617; I don't understand it completely either. > > Maybe just drop the second half of the paragraph and only mention the > thread itself? > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Best regards, Kathleen --089e0158ab60fd85ab050f78d2d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This part of the thread resulted in a few= more changes, I'm ok with them as noted below and just want to track t= his and add an RFC editor note on the reference concern.

Thanks!

On Th= u, Feb 19, 2015 at 2:07 PM, Julian Reschke <julian.reschke@gmx.de&= gt; wrote:
<= div class=3D"h5">On 2015-02-19 19:22, Daniel Kahn Gillmor wrote:
Hi Julian--

Thanks for the prompt response!=C2=A0 My own are inline below.

On Wed 2015-02-18 17:18:43 -0500, Julian Reschke wrote:
On 2015-02-18 09:15, Daniel Kahn Gillmor wrote:
...
Should recommend strong password-hashing on the server side
-----------------------------------------------------------

The Security Considerations section acknowledges that passwords can be
stolen from servers, but does not encourage server operators to hash
stored passwords with a reasonable or strong algorithm.=C2=A0 This document=
may not be the place to provide normative guidance on how to store
passwords to mitigate the exposure of a password table, but perhaps a
brief mention and an informative reference would be useful?=C2=A0 Many
systems (e.g. modern nginx and apache) use 1000 iterations of salted
MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, which are all terrible.

=C2=A0 =C2=A0https://httpd.apache.org/docs/2.4/m= isc/password_encryptions.html
=C2=A0 =C2=A0http://nginx.org/en/docs= /http/ngx_http_auth_basic_module.html#auth_basic_user_file

an informative reference might point to the Password Hashing
Competition, which documents sensible rationales for why you should use
strong password hashing, and how to know it when you see it:

=C2=A0 =C2=A0 ht= tps://password-hashing.net

by comparison the digest draft has a lot more about how passwords should be stored (even though Digest auth can offer only weaker protections for the password store compared to Basic auth):

=C2=A0 =C2=A0https://tools.ietf.org/html/dr= aft-ietf-httpauth-digest-13#section-5.2
...

I would really like to avoid talking about threads that are generic to
password-based authentication. Optimally, the security area would have a document that discusses exactly these kind of things so that other specs can reference that. Does something like this exist?

These threats aren't generic to password-based authentication.=C2=A0 th= ey're
specific to the *type* of password-based authentication used by HTTP
basic auth.=C2=A0 For example HTTP Digest and PAKE schemes are both
password-based, but have different properties, different requirements
for the password store, and different threats.

I don't know if there is an IETF document that describes
password-hashing best-practices or formats.=C2=A0 Maybe someone else knows?=

Or do you want to propose concrete text?

I don't have the bandwidth to craft something fancy right now, but
here's a first stab that you're welcome to carve up as you see fit,= if
no IETF references are forthcoming:

=C2=A0 =C2=A0 Servers and proxies requiring Basic Authentication must store= user
=C2=A0 =C2=A0 passwords in some form in order to verify the request's =C2=A0 =C2=A0 Authorization: header.=C2=A0 These passwords should be stored= in such a
=C2=A0 =C2=A0 way that a leak of the password table doesn't make them t= rivially
=C2=A0 =C2=A0 recoverable.=C2=A0 This is especially when users are allowed = to set their
=C2=A0 =C2=A0 own passwords, since users are known to choose weak passwords= and to
=C2=A0 =C2=A0 reuse them across authentication realms.=C2=A0 While a full d= iscussion of
=C2=A0 =C2=A0 good password hashing techniques for HTTP Basic Authenticatio= n is
=C2=A0 =C2=A0 beyond the scope of this document, server operators should ma= ke an
=C2=A0 =C2=A0 effort to minimize risks to their users in the event of a pas= sword
=C2=A0 =C2=A0 table leak.=C2=A0 For example, servers should not store user = passwords in
=C2=A0 =C2=A0 plaintext or as unsalted digests.=C2=A0 For more discussion a= bout modern
=C2=A0 =C2=A0 password hashing techniques, see [PHC].

=C2=A0 [PHC] htt= ps://password-hashing.net Password Hashing Competition

(i've used "should not" instead of RFC 2119 "SHOULD NOT&= quot; above because
this is not a recommendation about the on-the-wire protocol.=C2=A0 If anyon= e
thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd = be happy to
see that happen, because this is seriously low-hanging fruit, and i'm sure there are still operators out there disregarding it.

I like the text, and I'm ok with including it or a variation of it. I&#= 39;m not 100% convinced that the RFC Editor will be ok with the citation.

OK, this looks good as well, thanks.=C2=A0 W= e'll figure out the reference as we go.=C2=A0 I can make an RFC editor = note on it so we don't forget to figure it out.


Should recommend constant-time server-side comparisons
------------------------------------------------------

Servers that implement basic auth should not leak information about
the stored password via timing of rejections.=C2=A0 For example, a server that stored cleartext passwords (which is a bad idea anyway) should
mechanically compare the entire string instead of bytewise comparisons.
The attack here is an attacker who guesses credentials a byte at a time, by making 256 initial guesses and seeing which of them gets back a
rejection faster than the other (and iterates down the list).

This might be less of an issue for reasonable (non-cleartext) password
storage, but if we're not requiring strong password hashing, we should<= br> at least require constant time comparisons.

Do you seriously believe that the time for a string comparison is
relevant compared to the overhead of two network hops plus encapsulation into HTTP messages?

If the transport framework (network hops plus encapsulation into HTTP
messages) has no jitter, then the ratio of timing between string
comparison and the transport framework overhead is irrelevant; an
attacker just cares about difference, not magnitude.=C2=A0 Even with some small jitter, statistical analyses over many connections could yield
information.

Do i expect the transport framework to be jitter-free in the real world? Usually, no.=C2=A0 But do you want the security of the scheme to depend on<= br> the transport framework having jitter?

If this is a security consideration, would you rather say "deploy this=
only over jittery transports" or "don't leak timing informati= on when you
compare passwords"?=C2=A0 The latter seems simpler and clearer to me.<= br>

The network exchange will be take milliseconds. The string comparison micro= seconds. /me not convinced there's a problem here.



Should recommend padding the Authorization: response
----------------------------------------------------

When used behind HTTPS as recommended, TLS hides the username and
password presented.=C2=A0 However, it does not hide the length of the
username and password if the other parameters of the HTTPS request are
known.

An active attacker who wants to learn the length of the victim's
username and password together for a particular basic auth realm could
force the user's browser to make HTTPS requests to a few different URLs=
within the realm and see how large the packets are.

This could be mitigated by including whitespace padding in the client's=
Authorization: header itself up to some multiple of a blocksize (perhaps 256B) to obscure the length.

Actually, padding can happen anywhere in the message; it doesn't need t= o
be in this header field.

That's true, but padding the entire HTTP request to a standard blocksiz= e
has different security properties than just padding this field to a
standard blocksize, because parts of the HTTP request could be under
control of the attacker.

For example, if Alice can make Bob's user agent fetch arbitrary URLs from https://example.com= /, then she can pass steadily increasing URLs to
Bob's user agent (e.g. https://example.com/a https://example.com/aa
https://example.com/a= aa) and see at what point the size jumps a quantum.
Restricting the padding to the field that is not under attacker control
in any part should prevent this attack.

How would the attacker be able to modify fields in the request?

I think it would be great to have a document that describes these threats a= nd how to mitigate them; in particular comparing HTTP/1.1 and 2, but I seri= ously doubt this document would be the right place to do this.

(It seems to be as relevant for cookies, no?)



It's an interesting idea; have you checked whether existing User Agents=
do this?

I don't know whether any existing User Agents do this, sorry.

UTF-8 security considerations by reference: is this OK?
------------------------------------------

The Security Considerations section includes the UTF-8 security
considerations section by reference, but doesn't call out any specific<= br> issues for implementers to be aware of.=C2=A0 the NFC canonicalization draf= t

Intentionally.

also has Security Considersations section, which is not included by
reference:

=C2=A0 =C2=A0 https://tools.ietf.org/html/rfc5198#section-6

I'll add that.

cool, thanks!

= Good, thanks for this addition as well.=C2=A0


Interaction with proxies?
-------------------------

There is only a passing mention of Proxy-Authenticate: and
Proxy-Authorization: headers, so one assumes that both mechanisms should support this new auth-param.=C2=A0 It's not clear to me whether there a= re any
additional security or privacy implications when this is addressed to
proxies compared to origin servers.

I'm not aware of any.

Section 2.2 ("reusing credentials") talks about the URI path (pre= sumably
for "WWW-Authenticate", but then mixes "Proxy-Authenticate&q= uot; into the
middle of that commentary.=C2=A0 It looks to me like "Proxy-Authentica= te" is
not intended to be scoped by the URI path (there is no mention of "in<= br> that space" in the sentence about Proxy-Authenticate in Section 2.2),<= br> but this is kind of ambiguous.=C2=A0 Clarification would be good.

To be frank, I don't know. My best guess is that it works exactly the same, so I'll add "in that space" there as well.

This ambiguity worries me a bit; should we take this opportunity to
clear it up to match what happens in practice?=C2=A0 It seems like we shoul= d
have some people with operational experience on this who could provide
clarification here, but i'm not one of them.

Nor am I.

I do agree that proxy authentication needs better documentation, but that&#= 39;s a problem of RFC 7235, not this spec.


Path matching?
--------------

Nothing in the security considerations section talks about the threat
that motivates path matching for determination of which realm to use.
It might be useful to spell this out explicitly:

=C2=A0 =C2=A0* A user agent that sends the Authorization: header to URLs ou= tside the
=C2=A0 =C2=A0 =C2=A0authentication scope as described in Section 2.2 may le= ak the user's
=C2=A0 =C2=A0 =C2=A0credentials

That applies to all schemes that use protection spaces and is mentioned
in <http://greenbytes.de/tech/webdav/rfc7235.h= tml#protection.spaces>
already.

User Agent visibility and logout?
---------------------------------

Most RFCs don't talk at all about the human interface of the mentioned<= br> tools.

But this draft refers briefly to interaction between the user and the
User Agent (see step 1 on
https://tools.ietf.org/html/draft-ietf= -httpauth-basicauth-update-06#page-6).
However, it provides no other guidance.=C2=A0 There are several additional<= br> guidelines that make basic authentication more acceptable from a privacy and security point of view for a typical web browser User Agent:

=C2=A0 =C2=A0* user agents should indicate to the user when they are re-usi= ng the
=C2=A0 =C2=A0 =C2=A0user's authentication credentials as described in s= ection 2.2
=C2=A0 =C2=A0 =C2=A0(indicating the realm, authentication scope, and user-i= d?)

They don't right now. Do you believe that requiring it will have any effect on existing UAs?

i don't know, but i'd certainly like to see that happen.=C2=A0 If i= t doesn't
happen, perhaps we need to mention in Security Considerations that User
Agents which do not indicate to the user when they are reusing the
user's credentials risk leaking those credentials without the user
knowing that it's happening?

We could say that (text welcome), but I seriously doubt it will affect what= software does. The current trend is to remove as much UI as possible (or e= ven all on mobile), so asking for this indicator is really wishful thinking= .

=C2=A0 =C2=A0* user agents should not display the user's password anywh= ere by
=C2=A0 =C2=A0 =C2=A0default

That sounds pretty obvious.

I agree!=C2=A0 Maybe we don't need to say obvious things?

=C2=A0 =C2=A0* user agents should make it straightforward for users to clea= r their
=C2=A0 =C2=A0 =C2=A0credentials for any <realm,authentication scope,user= -id>.

Define "straightforward".

That probably depends on the type of user agent, no?=C2=A0 as a suggestion,=
this seems like it could be something that we encourage without
specifying concrete mechanism.

 Again, we're talking about code that has been written almost 20 years a= go. New advice on nice-to-haves will not have any effect on these implement= ations.

https://tools.ietf.org/html/rfc7235#section-6.3 includes some= of these
guidelines; perhaps this is another include-by-reference?

All security considerations of RFC 7235 apply by definition, as this
spec is using the framework defined by RFC 7235. I don't believe that w= e
need to state this.

It wasn't immediately obvious to me that all security considerations of=
RFC 7235 apply by definition, but now that you say it it makes sense.

Do you think that an implementor of HTTP basic auth with less experience reading RFCs is going to understand that?

 An implementor of this spec will need to read and understand RFC 7235. So, = yes.

Other Considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Deployment chicken-and-egg
--------------------------

The server has no way of knowing that the client is trying to obey the
charset header.=C2=A0 For the servers mentioned in that do user-agent

Actually, it could apply heuristics. I header detection of UTF-8 is
quire reliable.

What heuristics should it apply?=C2=A0 If there is a standard set of
heuristics we expect servers to use, we should put them in this
document.

 I don't *expect* servers to use heuristics.

That being said, the heuristics are quite simple: try to decode the octets = with a strict UTF-8 decoder, and if that doesn't fail the input was lik= ely encoded in UTF-8.

sniffing, it's not clear how those servers could ever know to stop
relying on the user-agent, since the clients have no way of signalling
their intent to use UTF-8 for the Authorization header.=C2=A0 If the server= s
don't know when to start accepting UTF-8 from these clients, then the clients also have no way of knowing when they should switch over
themselves.=C2=A0 This strikes me as a recipe for stalled adoption, since "user agents in the latter group" (from section B.3) will never u= se
UTF-8, even if they know about it.

I don't see why the server can't just start accepting UTF-8 right a= way.


Because "User agents in the latter group will have to continue to do what they do today", so the servers will need to interpret the respons= e
in the same way.=C2=A0 If you mean to say that 'User agents in the latt= er
group will have to continue to do what they do today unless the server
has sent charset=3D"UTF-8"' then please say so explicitly.

No, that's not what I meant.

By "accepting UTF-8" I mean "trying to decode as UTF-8"= in addition to what the server is already doing; basically a trial-and-err= or approach.

And sorry, one more question arises for me on re-read. i'm not sure i understand what this means:

=C2=A0 =C2=A0 Server implementers SHOULD guard against the possibility of t= his sort
=C2=A0 =C2=A0 of counterfeiting by gateways or CGI scripts.=C2=A0 In partic= ular it is
=C2=A0 =C2=A0 very dangerous for a server to simply turn over a connection = to a
=C2=A0 =C2=A0 gateway.=C2=A0 That gateway can then use the persistent conne= ction
=C2=A0 =C2=A0 mechanism to engage in multiple transactions with the client = while
=C2=A0 =C2=A0 impersonating the original server in a way that is not detect= able by
=C2=A0 =C2=A0 the client.

How should the server guard against this attack?=C2=A0 what sort does it me= an
to "turn over a connection to a gateway"?=C2=A0 does "gatewa= y" mean
"transparent HTTP proxy" or does it refer to something else?=C2= =A0 Sorry if
this is elementary stuff, but the term "gateway" only appears in = this
paragraph.

 That text is present in RFC 2617; I don't understand it completely eith= er.

Maybe just drop the second half of the paragraph and only mention the threa= d itself?

Best regards, Julian

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



--

Best regards,
Kath= leen
--089e0158ab60fd85ab050f78d2d4-- From nobody Thu Feb 19 15:06:46 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 D43FF1A0398; Thu, 19 Feb 2015 15:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 xv9KREIBfMgs; Thu, 19 Feb 2015 15:06:44 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 117C21A0371; Thu, 19 Feb 2015 15:06:44 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 0CB953B805C; Thu, 19 Feb 2015 15:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=puE9hLU3cluv6aZuUUYHf4gRF4Q=; b=qifJHA2UKDqYdqdSoY/Vw2gyCzdB PpbC4SnqebFQgyeOAb8Xg/ZZMzbObzHwe8WtNoTqMPqtF4u4J19CnTwfnSzyb0cr WLJAo/euxZieNOS+T3jTgX682hndMU0y1wBDMFng534XWsV7c12rFgs8cp8/KsSf SZfrYJCepBHKWzM= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id CD40D3B8059; Thu, 19 Feb 2015 15:06:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: "Roy T. Fielding" In-Reply-To: <54E648B9.6030606@gmx.de> Date: Thu, 19 Feb 2015 15:06:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1283) Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, Daniel Kahn Gillmor , secdir@ietf.org Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 19 Feb 2015 23:06:46 -0000 On Feb 19, 2015, at 12:34 PM, Julian Reschke wrote: > On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: >> On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote: >>> The network exchange will be take milliseconds. The string = comparison >>> microseconds. /me not convinced there's a problem here. >>=20 >> as long as the attacker can measure microseconds, and the network >> exchange has small or regular-enough jitter to be accounted for with >> statistical techniques, the size difference between these parts = doesn't >> matter to a timing attack. >>=20 >> http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf >>=20 >> says: >>=20 >> The resolution an attacker can time a remote host depends on how = many >> measurements they can collect. Our simulated attacker using >> statistical hypothesis testing was able to reliably distinguish a >> processing time differences as low as 200ns and 30=B5s with 1,000 >> measurements on the LAN and WAN respectively with. (See Section = 6.) >>=20 >> Note that salted, hashed passwords where the attacker doesn't know = the >> salt are resistant to using a timing oracle like this to do = byte-by-byte >> guessing. I still think it's simpler to just recommend that the = tests >> should be constant time. >=20 > I'm sorry, I'm not convinced. What do others think? It is possible to run a timing attack on a remote server that uses any form of authentication scheme. However, the likelihood of detecting within the attack a difference of matching N characters vs N+1 = characters is incredibly small (usually less than 1 nanosecond) unless the matching algorithm itself is unusually complicated. In any case, we can't just recommend that the tests should be constant = time. Very few people understand what that means, even in a security = discussion. I don't think we use any matching schemes within Apache that do partial comparison during mid-algorithm -- IIRC, we recreate the hash based on = the complete input and then use a string function to compare the result to = the stored password. Of course, others could extend Apache to do more. A more reasonable thing to say is that any authentication system that allows a client to perform more than three failed authentication = attempts on a single connection, or more than ten on a single account over = multiple connections, is likely to be vulnerable to password guessing attacks. Timing attacks then become completely irrelevant. [...] >>>> And sorry, one more question arises for me on re-read. i'm not sure = i >>>> understand what this means: >>>>=20 >>>> Server implementers SHOULD guard against the possibility of = this sort >>>> of counterfeiting by gateways or CGI scripts. In particular it = is >>>> very dangerous for a server to simply turn over a connection to = a >>>> gateway. That gateway can then use the persistent connection >>>> mechanism to engage in multiple transactions with the client = while >>>> impersonating the original server in a way that is not = detectable by >>>> the client. >>>>=20 >>>> How should the server guard against this attack? what sort does it = mean >>>> to "turn over a connection to a gateway"? does "gateway" mean >>>> "transparent HTTP proxy" or does it refer to something else? Sorry = if >>>> this is elementary stuff, but the term "gateway" only appears in = this >>>> paragraph. >>>=20 >>> That text is present in RFC 2617; I don't understand it completely = either. This is about web server internals. Back in the early days, when HTTP = was limited to one request per connection, there was a thing called NPH = scripts that would allow a script to directly respond to the client instead of = their response being framed by the server; a trivial implementation could hand off the file descriptor to the script and exit. However, that kind of implementation became a potential security hole when persistent = connections were introduced, since the script could redirect the client to a protected space within the same origin (controlled by someone else) and receive the redirected request within the script input, bypassing = the web server's normal request-target hierarchy and collecting the = credentials. The solution is to never delegate message framing. >>>=20 >>> Maybe just drop the second half of the paragraph and only mention = the >>> thread itself? >>=20 >> If we drop the second half, i'd still like to know what kind of steps = a >> server should take to guard against the possibility of = counterfeiting. >> If we don't have any recommendations or external references, an >> unactionable SHOULD seems troublesome. >=20 > I'd just say >=20 > "Basic Authentication is also vulnerable to spoofing by counterfeit = servers. If a user can be led to believe that he is connecting to a host = containing information protected by Basic authentication when, in fact, = he is connecting to a hostile server or gateway, then the attacker can = request a password, store it for later use, and feign an error. This = type of attack is not possible with other authentication schemes, such = as Digest Authentication." Er, it is possible with Digest, but less productive (the credentials are only usable for as long as the nonce works). ....Roy From nobody Thu Feb 19 15:08: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 B82B01A0398; Thu, 19 Feb 2015 15:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 VWG812T0lZOG; Thu, 19 Feb 2015 15:07:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 2ED9C1A0371; Thu, 19 Feb 2015 15:07:53 -0800 (PST) Received: from netb ([89.204.130.64]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MQMBU-1XzAUv1myi-00TnyN; Fri, 20 Feb 2015 00:07:48 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Fri, 20 Feb 2015 00:07:45 +0100 Message-ID: <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> In-Reply-To: <54E66703.50207@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:wbZxUqCUNxW0Q8/kM25/FlO8qI/a6qHxc6eXjHQKH2uR6YqiE2t sG53RsQ3Zt4Itxr5r3rdiZDPy/bn41J78odppO8Xt689yVOyJvu8Zyu+iyZ3F4I4beacauo vW2Tmw1PF2GOmefu6MLx2EoOh0ipbLK+Blk7WB9PoszuZ9o8icAlh2MLYMwXcO04BKDYfTs NjtopK9fIBLg+LZd3UEgQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 23:07:55 -0000 * Julian Reschke wrote: >On 2015-02-19 23:33, Bjoern Hoehrmann wrote: >> The current text is: >> >> Furthermore, a user-id containing a colon character is invalid, as >> recipients will split the user-pass at the first occurrence of a >> colon character. Note that many user agents however will accept a >> colon in user-id, thereby producing a user-pass string that >> recipients will likely treat in a way not intended by the user. >> >> So if the password contains a colon, and the draft requires support for >> that, then what? Are recipients REQUIRED to split the string at the 1st >> colon? If so, then I think the current text is not adequate. If not, >> then it seems wrong to require support for colons in passwords. > >I think they are required to split on the first colon; why do you think >the current text is inadequate? It should be something like The first colon in a user-pass string separates username and password from one another; text after the first colon is part of the password. Usernames containing colons cannot be encoded in user-pass strings. Note that many user agents produce user-pass strings without checking that usernames supplied by users do not contain colons; recipients will then treat part of the username input as part of the password. This would actually define the correct interpretation of the first colon rather than hinting at what recipients will do, avoid the "will likely" speculation, and makes it more clear that colons in usernames are not an option offered by the protocol that then needs to be restricted by a MUST NOT for interoperability reasons, as far as I am concerned. It is also more clear that "user agents accept colons" is an UI issue; with the text in the draft `user-id` is used for both "string entered into username form field" and "value in Authorization header" which can be quite different due to colons. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Thu Feb 19 15:08:01 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E30B81A1A17; Thu, 19 Feb 2015 15:07:55 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82B01A0398; Thu, 19 Feb 2015 15:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 VWG812T0lZOG; Thu, 19 Feb 2015 15:07:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 2ED9C1A0371; Thu, 19 Feb 2015 15:07:53 -0800 (PST) Received: from netb ([89.204.130.64]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MQMBU-1XzAUv1myi-00TnyN; Fri, 20 Feb 2015 00:07:48 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Fri, 20 Feb 2015 00:07:45 +0100 Message-ID: <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> In-Reply-To: <54E66703.50207@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:wbZxUqCUNxW0Q8/kM25/FlO8qI/a6qHxc6eXjHQKH2uR6YqiE2t sG53RsQ3Zt4Itxr5r3rdiZDPy/bn41J78odppO8Xt689yVOyJvu8Zyu+iyZ3F4I4beacauo vW2Tmw1PF2GOmefu6MLx2EoOh0ipbLK+Blk7WB9PoszuZ9o8icAlh2MLYMwXcO04BKDYfTs NjtopK9fIBLg+LZd3UEgQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 23:07:56 -0000 * Julian Reschke wrote: >On 2015-02-19 23:33, Bjoern Hoehrmann wrote: >> The current text is: >> >> Furthermore, a user-id containing a colon character is invalid, as >> recipients will split the user-pass at the first occurrence of a >> colon character. Note that many user agents however will accept a >> colon in user-id, thereby producing a user-pass string that >> recipients will likely treat in a way not intended by the user. >> >> So if the password contains a colon, and the draft requires support for >> that, then what? Are recipients REQUIRED to split the string at the 1st >> colon? If so, then I think the current text is not adequate. If not, >> then it seems wrong to require support for colons in passwords. > >I think they are required to split on the first colon; why do you think >the current text is inadequate? It should be something like The first colon in a user-pass string separates username and password from one another; text after the first colon is part of the password. Usernames containing colons cannot be encoded in user-pass strings. Note that many user agents produce user-pass strings without checking that usernames supplied by users do not contain colons; recipients will then treat part of the username input as part of the password. This would actually define the correct interpretation of the first colon rather than hinting at what recipients will do, avoid the "will likely" speculation, and makes it more clear that colons in usernames are not an option offered by the protocol that then needs to be restricted by a MUST NOT for interoperability reasons, as far as I am concerned. It is also more clear that "user agents accept colons" is an UI issue; with the text in the draft `user-id` is used for both "string entered into username form field" and "value in Authorization header" which can be quite different due to colons. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Thu Feb 19 15:13:12 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 BCA751A1A27; Thu, 19 Feb 2015 15:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 fjmp8kSFZAFe; Thu, 19 Feb 2015 15:13:06 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 96E461A00E2; Thu, 19 Feb 2015 15:13:06 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 767C69405E; Thu, 19 Feb 2015 15:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=De908Y4L1m5lzlz5I6sJ/1n8C6U=; b=zaj6r6QpUW9P3LZkZSWwvIG6d7Pd C8QMvIft5ugJ0+IgqGpF19WP+7n/tFE0jDgWNgOZxlFD3efWNrqH72tXZGdBkCkK qxKaQXuztHK1XcdxL7qSvDHsDp8giL07Ui4AXQUMjfuXxUOASwn3MKT+L2PIh3Z6 tmeLm6DfmIFMsDY= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 461BA9405C; Thu, 19 Feb 2015 15:13:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: "Roy T. Fielding" In-Reply-To: <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> Date: Thu, 19 Feb 2015 15:12:50 -0800 Content-Transfer-Encoding: 7bit Message-Id: <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1283) Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org Auth" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 23:13:07 -0000 On Feb 19, 2015, at 3:07 PM, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> On 2015-02-19 23:33, Bjoern Hoehrmann wrote: >>> The current text is: >>> >>> Furthermore, a user-id containing a colon character is invalid, as >>> recipients will split the user-pass at the first occurrence of a >>> colon character. Note that many user agents however will accept a >>> colon in user-id, thereby producing a user-pass string that >>> recipients will likely treat in a way not intended by the user. >>> >>> So if the password contains a colon, and the draft requires support for >>> that, then what? Are recipients REQUIRED to split the string at the 1st >>> colon? If so, then I think the current text is not adequate. If not, >>> then it seems wrong to require support for colons in passwords. >> >> I think they are required to split on the first colon; why do you think >> the current text is inadequate? > > It should be something like > > The first colon in a user-pass string separates username and password > from one another; text after the first colon is part of the password. > Usernames containing colons cannot be encoded in user-pass strings. > Note that many user agents produce user-pass strings without checking > that usernames supplied by users do not contain colons; recipients > will then treat part of the username input as part of the password. > > This would actually define the correct interpretation of the first colon > rather than hinting at what recipients will do, avoid the "will likely" > speculation, and makes it more clear that colons in usernames are not an > option offered by the protocol that then needs to be restricted by a > MUST NOT for interoperability reasons, as far as I am concerned. It is > also more clear that "user agents accept colons" is an UI issue; with > the text in the draft `user-id` is used for both "string entered into > username form field" and "value in Authorization header" which can be > quite different due to colons. +1 (FYI, Apache httpd does exactly that.) ....Roy From nobody Thu Feb 19 15:13:14 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D8C5B1A1A2D; Thu, 19 Feb 2015 15:13:07 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA751A1A27; Thu, 19 Feb 2015 15:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 fjmp8kSFZAFe; Thu, 19 Feb 2015 15:13:06 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 96E461A00E2; Thu, 19 Feb 2015 15:13:06 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 767C69405E; Thu, 19 Feb 2015 15:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=De908Y4L1m5lzlz5I6sJ/1n8C6U=; b=zaj6r6QpUW9P3LZkZSWwvIG6d7Pd C8QMvIft5ugJ0+IgqGpF19WP+7n/tFE0jDgWNgOZxlFD3efWNrqH72tXZGdBkCkK qxKaQXuztHK1XcdxL7qSvDHsDp8giL07Ui4AXQUMjfuXxUOASwn3MKT+L2PIh3Z6 tmeLm6DfmIFMsDY= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 461BA9405C; Thu, 19 Feb 2015 15:13:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: "Roy T. Fielding" In-Reply-To: <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> Date: Thu, 19 Feb 2015 15:12:50 -0800 Content-Transfer-Encoding: 7bit Message-Id: <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1283) Archived-At: Cc: Julian Reschke , Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org Auth" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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: Thu, 19 Feb 2015 23:13:08 -0000 On Feb 19, 2015, at 3:07 PM, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> On 2015-02-19 23:33, Bjoern Hoehrmann wrote: >>> The current text is: >>> >>> Furthermore, a user-id containing a colon character is invalid, as >>> recipients will split the user-pass at the first occurrence of a >>> colon character. Note that many user agents however will accept a >>> colon in user-id, thereby producing a user-pass string that >>> recipients will likely treat in a way not intended by the user. >>> >>> So if the password contains a colon, and the draft requires support for >>> that, then what? Are recipients REQUIRED to split the string at the 1st >>> colon? If so, then I think the current text is not adequate. If not, >>> then it seems wrong to require support for colons in passwords. >> >> I think they are required to split on the first colon; why do you think >> the current text is inadequate? > > It should be something like > > The first colon in a user-pass string separates username and password > from one another; text after the first colon is part of the password. > Usernames containing colons cannot be encoded in user-pass strings. > Note that many user agents produce user-pass strings without checking > that usernames supplied by users do not contain colons; recipients > will then treat part of the username input as part of the password. > > This would actually define the correct interpretation of the first colon > rather than hinting at what recipients will do, avoid the "will likely" > speculation, and makes it more clear that colons in usernames are not an > option offered by the protocol that then needs to be restricted by a > MUST NOT for interoperability reasons, as far as I am concerned. It is > also more clear that "user agents accept colons" is an UI issue; with > the text in the draft `user-id` is used for both "string entered into > username form field" and "value in Authorization header" which can be > quite different due to colons. +1 (FYI, Apache httpd does exactly that.) ....Roy From nobody Thu Feb 19 16:10:31 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 0648A1A1A7E; Thu, 19 Feb 2015 16:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 e0AwuybIhRF4; Thu, 19 Feb 2015 16:10:23 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6B1A1A78; Thu, 19 Feb 2015 16:10:23 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 2512F77805B; Thu, 19 Feb 2015 16:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=gpkLeCxJC0LT7S9WBv1RU1YjrNE=; b=npG4o/oH1y1bw82ICnlEFRqYUwTV dceqvT09RY5CXiYgRJf1OoGJlCAYXSExkaSaH3mfTL6nfbYQLdlDtzOY6iwoxCNw gUslse4WZIru4WgUkX23urvRK2Wak1fOyMVcThs6+IRkbkx9wJgXEqOHW8vQSrRr VQkKEIW/kWbWozI= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id E6FBA778057; Thu, 19 Feb 2015 16:10:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <877fvda2tp.fsf@alice.fifthhorseman.net> Date: Thu, 19 Feb 2015 16:10:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> <877fvda2tp.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1283) Archived-At: Cc: Julian Reschke , "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 20 Feb 2015 00:10:25 -0000 On Feb 19, 2015, at 3:39 PM, Daniel Kahn Gillmor wrote: > On Thu 2015-02-19 18:06:42 -0500, Roy T. Fielding wrote: >=20 >> I don't think we use any matching schemes within Apache that do = partial >> comparison during mid-algorithm -- IIRC, we recreate the hash based = on the >> complete input and then use a string function to compare the result = to the >> stored password. Of course, others could extend Apache to do more. >=20 > fwiw, apache on windows and netware apparently does support plaintext > password files: >=20 > https://httpd.apache.org/docs/2.4/misc/password_encryptions.html >=20 > it seems likely that this is just strcmp() or the equivalent though i > haven't looked. >=20 > I'm not calling out Apache on this, fwiw -- i think Apache httpd is > usually doing the right thing here, and has clearly indicated that = this > is insecure. Right, these files are typically for storing simple barriers -- like the shared codes you might give out to a family for a picture album. Good enough to block spiders, but not intended to be secure, and = generally admin-defined rather than user-chosen. Apache also supports a variety = of hash algorithms for backwards compatibility with previously stored = accounts. >> A more reasonable thing to say is that any authentication system that >> allows a client to perform more than three failed authentication = attempts >> on a single connection, or more than ten on a single account over = multiple >> connections, is likely to be vulnerable to password guessing attacks. >> Timing attacks then become completely irrelevant. >=20 > This is an interesting suggestion, and should be useful against more > than just timing attacks. How should that filter be applied? It = seems > like it could create some sort of denial of service attack vector if > it's not done judiciously (e.g. Alice tries to lock out Bob by faking > bad logins from Bob). Yes, what I've seen is typically implemented as a temporary lock-out on the order of minutes -- long enough to prevent iterative attack techniques, but short enough that a user wouldn't mind. It is also sometimes combined with an alert to the user. How to implement it correctly depends on the overall web server architecture, such as whether the block is only per-server or covers an entire domain. I don't think we need to describe specifically how to implement it. >>>>>> And sorry, one more question arises for me on re-read. i'm not = sure i >>>>>> understand what this means: >>>>>>=20 >>>>>> Server implementers SHOULD guard against the possibility of = this sort >>>>>> of counterfeiting by gateways or CGI scripts. In particular = it is >>>>>> very dangerous for a server to simply turn over a connection = to a >>>>>> gateway. That gateway can then use the persistent connection >>>>>> mechanism to engage in multiple transactions with the client = while >>>>>> impersonating the original server in a way that is not = detectable by >>>>>> the client. >>>>>>=20 >>>>>> How should the server guard against this attack? what sort does = it mean >>>>>> to "turn over a connection to a gateway"? does "gateway" mean >>>>>> "transparent HTTP proxy" or does it refer to something else? = Sorry if >>>>>> this is elementary stuff, but the term "gateway" only appears in = this >>>>>> paragraph. >>>>>=20 >>>>> That text is present in RFC 2617; I don't understand it completely = either. >>=20 >> This is about web server internals. Back in the early days, when = HTTP was >> limited to one request per connection, there was a thing called NPH = scripts >> that would allow a script to directly respond to the client instead = of their >> response being framed by the server; a trivial implementation could = hand >> off the file descriptor to the script and exit. However, that kind = of >> implementation became a potential security hole when persistent = connections >> were introduced, since the script could redirect the client to a >> protected space within the same origin (controlled by someone else) >> and receive the redirected request within the script input, bypassing = the >> web server's normal request-target hierarchy and collecting the = credentials. >> The solution is to never delegate message framing. >=20 > Thanks for this explanation, it makes much more sense to me with the > context, and the key takeaway (about delegation of message framing) > seems like it's likely to be still relevant. Can we incorporate some = of > this in the draft somehow? Fine with me, ....Roy From nobody Thu Feb 19 20:48:33 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 0991E1A1A48; Thu, 19 Feb 2015 15:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac8m2M3CzNgo; Thu, 19 Feb 2015 15:39:38 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB631A1A45; Thu, 19 Feb 2015 15:39:38 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 1D3B8F984; Thu, 19 Feb 2015 18:39:33 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 04616202F4; Thu, 19 Feb 2015 18:39:31 -0500 (EST) From: Daniel Kahn Gillmor To: "Roy T. Fielding" , Julian Reschke In-Reply-To: <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 19 Feb 2015 18:39:30 -0500 Message-ID: <877fvda2tp.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 20:48:32 -0800 Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 19 Feb 2015 23:39:41 -0000 On Thu 2015-02-19 18:06:42 -0500, Roy T. Fielding wrote: > I don't think we use any matching schemes within Apache that do partial > comparison during mid-algorithm -- IIRC, we recreate the hash based on the > complete input and then use a string function to compare the result to the > stored password. Of course, others could extend Apache to do more. fwiw, apache on windows and netware apparently does support plaintext password files: https://httpd.apache.org/docs/2.4/misc/password_encryptions.html it seems likely that this is just strcmp() or the equivalent though i haven't looked. I'm not calling out Apache on this, fwiw -- i think Apache httpd is usually doing the right thing here, and has clearly indicated that this is insecure. > A more reasonable thing to say is that any authentication system that > allows a client to perform more than three failed authentication attempts > on a single connection, or more than ten on a single account over multiple > connections, is likely to be vulnerable to password guessing attacks. > Timing attacks then become completely irrelevant. This is an interesting suggestion, and should be useful against more than just timing attacks. How should that filter be applied? It seems like it could create some sort of denial of service attack vector if it's not done judiciously (e.g. Alice tries to lock out Bob by faking bad logins from Bob). >>>>> And sorry, one more question arises for me on re-read. i'm not sure i >>>>> understand what this means: >>>>> >>>>> Server implementers SHOULD guard against the possibility of this sort >>>>> of counterfeiting by gateways or CGI scripts. In particular it is >>>>> very dangerous for a server to simply turn over a connection to a >>>>> gateway. That gateway can then use the persistent connection >>>>> mechanism to engage in multiple transactions with the client while >>>>> impersonating the original server in a way that is not detectable by >>>>> the client. >>>>> >>>>> How should the server guard against this attack? what sort does it mean >>>>> to "turn over a connection to a gateway"? does "gateway" mean >>>>> "transparent HTTP proxy" or does it refer to something else? Sorry if >>>>> this is elementary stuff, but the term "gateway" only appears in this >>>>> paragraph. >>>> >>>> That text is present in RFC 2617; I don't understand it completely either. > > This is about web server internals. Back in the early days, when HTTP was > limited to one request per connection, there was a thing called NPH scripts > that would allow a script to directly respond to the client instead of their > response being framed by the server; a trivial implementation could hand > off the file descriptor to the script and exit. However, that kind of > implementation became a potential security hole when persistent connections > were introduced, since the script could redirect the client to a > protected space within the same origin (controlled by someone else) > and receive the redirected request within the script input, bypassing the > web server's normal request-target hierarchy and collecting the credentials. > The solution is to never delegate message framing. Thanks for this explanation, it makes much more sense to me with the context, and the key takeaway (about delegation of message framing) seems like it's likely to be still relevant. Can we incorporate some of this in the draft somehow? --dkg From nobody Fri Feb 20 00:25: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 973131A700E; Fri, 20 Feb 2015 00:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 3JCAUbFaD673; Fri, 20 Feb 2015 00:24:57 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id D466C1A7034; Fri, 20 Feb 2015 00:24:56 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 2A70E32E4A2; Fri, 20 Feb 2015 17:24:11 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2bfe_806d_47d9ec2d_d472_47e9_954c_b2ce2e9bba25; Fri, 20 Feb 2015 17:24:10 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5CCF0BF4DF; Fri, 20 Feb 2015 17:24:10 +0900 (JST) Message-ID: <54E6EF29.6040808@it.aoyama.ac.jp> Date: Fri, 20 Feb 2015 17:24:09 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Reschke , Kathleen Moriarty , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> In-Reply-To: <54E61331.7080807@greenbytes.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 08:24:58 -0000 On 2015/02/20 01:45, Julian Reschke wrote: > The problem here is the "long tail". We simply have no information about > whether these IDs exist in practice. The fact that all UAs I checked > indeed accept them at least *hints* that they might be used somewhere. > Or none of the implementers ever thought about rejecting them. My guess is that the second answer is the correct one. If there are no userids with colons in them, why would the implementers need to reject them? Regards, Martin. From nobody Fri Feb 20 00:25:04 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B59781A70FD; Fri, 20 Feb 2015 00:24:58 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973131A700E; Fri, 20 Feb 2015 00:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 3JCAUbFaD673; Fri, 20 Feb 2015 00:24:57 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id D466C1A7034; Fri, 20 Feb 2015 00:24:56 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 2A70E32E4A2; Fri, 20 Feb 2015 17:24:11 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2bfe_806d_47d9ec2d_d472_47e9_954c_b2ce2e9bba25; Fri, 20 Feb 2015 17:24:10 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5CCF0BF4DF; Fri, 20 Feb 2015 17:24:10 +0900 (JST) Message-ID: <54E6EF29.6040808@it.aoyama.ac.jp> Date: Fri, 20 Feb 2015 17:24:09 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Reschke , Kathleen Moriarty , Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> In-Reply-To: <54E61331.7080807@greenbytes.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Pete Resnick , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 08:24:58 -0000 On 2015/02/20 01:45, Julian Reschke wrote: > The problem here is the "long tail". We simply have no information about > whether these IDs exist in practice. The fact that all UAs I checked > indeed accept them at least *hints* that they might be used somewhere. > Or none of the implementers ever thought about rejecting them. My guess is that the second answer is the correct one. If there are no userids with colons in them, why would the implementers need to reject them? Regards, Martin. From nobody Fri Feb 20 05:32:54 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 9AE731A8ACA; Fri, 20 Feb 2015 05:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.916 X-Spam-Level: * X-Spam-Status: No, score=1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=2.795, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMx8DASgCR1L; Fri, 20 Feb 2015 05:32:52 -0800 (PST) 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 A49551A8A16; Fri, 20 Feb 2015 05:32:51 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M3RVA-1XYD6i2Nxg-00r3ZF; Fri, 20 Feb 2015 14:32:36 +0100 Message-ID: <54E7376C.5070303@gmx.de> Date: Fri, 20 Feb 2015 14:32:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> In-Reply-To: <871tllbw2c.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:FxBtHdFQoQRz5einn3CQUP/I1Xg+hR4Lg47uZ0NiGcZ1jAGmfgL /21WNPOT1VeeZycDk5+PBCBFN5Gxsz864Clp93MV8/UKjnb4xGRxnxVmLX4/JmEvF3GBw1Y MvMOtJKG4uJkAY5hFI0520q7VZy/382T4WEVAta/L6/SRVra7FmaOrLSVS4VLMgwmb8tcPx mxBolQWHnXHXUQNxpxcEA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, Daniel Kahn Gillmor , secdir@ietf.org Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 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, 20 Feb 2015 13:32:53 -0000 On 2015-02-19 19:22, Daniel Kahn Gillmor wrote:> ... > I don't have the bandwidth to craft something fancy right now, but > here's a first stab that you're welcome to carve up as you see fit, if > no IETF references are forthcoming: > > Servers and proxies requiring Basic Authentication must store user > passwords in some form in order to verify the request's > Authorization: header. These passwords should be stored in such a > way that a leak of the password table doesn't make them trivially > recoverable. This is especially when users are allowed to set their > own passwords, since users are known to choose weak passwords and to > reuse them across authentication realms. While a full discussion of > good password hashing techniques for HTTP Basic Authentication is > beyond the scope of this document, server operators should make an > effort to minimize risks to their users in the event of a password > table leak. For example, servers should not store user passwords in > plaintext or as unsalted digests. For more discussion about modern > password hashing techniques, see [PHC]. > > [PHC] https://password-hashing.net Password Hashing Competition > > (i've used "should not" instead of RFC 2119 "SHOULD NOT" above because > this is not a recommendation about the on-the-wire protocol. If anyone > thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to > see that happen, because this is seriously low-hanging fruit, and i'm > sure there are still operators out there disregarding it. > ... I have added very similar text with ): >> Servers and proxies implementing Basic Authentication need to store >> user passwords in some form in order to authenticate a request. >> These passwords ought to be be stored in such a way that a leak of >> the password data doesn't make them trivially recoverable. This is >> especially important when users are allowed to set their own >> passwords, since users are known to choose weak passwords and to >> reuse them across authentication realms. While a full discussion of >> good password hashing techniques is beyond the scope of this >> document, server operators ought to make an effort to minimize risks >> to their users in the event of a password data leak. For example, >> servers ought to avoid storing user passwords in plaintext or as >> unsalted digests. For more discussion about modern password hashing >> techniques, see the "Password Hashing Competition" >> (). Thanks for the proposal! Best regards, Julian From nobody Fri Feb 20 05:53: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 8BFE31A7D81; Fri, 20 Feb 2015 05:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dQEbTaRqC0T2; Fri, 20 Feb 2015 05:53:21 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 104391A710C; Fri, 20 Feb 2015 05:53:21 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lv8hi-1XOpmz22SY-010OSP; Fri, 20 Feb 2015 14:53:00 +0100 Message-ID: <54E73C32.6070108@gmx.de> Date: Fri, 20 Feb 2015 14:52:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> In-Reply-To: <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:moybVFRhPayWO/el3nE88vk+uXPw5ZD0U6//Ghp9yFtblo7CkF5 YoOKtUBgvuSfQj0mpwFyPZkZQiYJ246fD4KYvTuf1SMaWAG+ocEkYpeS2hk6wI28nn58n0j HOL8FI3MGy0XplzO9fVGG2nmdQju5JVP+FviwcJ46Y2x9D2CSHzjrqOqPhd7/1/820CzQWl tKo+AS1SwRnAofJz6m6Iw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "secdir@ietf.org" , "http-auth@ietf.org" , iesg@ietf.org, draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, Daniel Kahn Gillmor Subject: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 - security considerations on counterfeiting attacks 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, 20 Feb 2015 13:53:23 -0000 On 2015-02-20 00:06, Roy T. Fielding wrote: > ... >>>>> And sorry, one more question arises for me on re-read. i'm not sure i >>>>> understand what this means: >>>>> >>>>> Server implementers SHOULD guard against the possibility of this sort >>>>> of counterfeiting by gateways or CGI scripts. In particular it is >>>>> very dangerous for a server to simply turn over a connection to a >>>>> gateway. That gateway can then use the persistent connection >>>>> mechanism to engage in multiple transactions with the client while >>>>> impersonating the original server in a way that is not detectable by >>>>> the client. >>>>> >>>>> How should the server guard against this attack? what sort does it mean >>>>> to "turn over a connection to a gateway"? does "gateway" mean >>>>> "transparent HTTP proxy" or does it refer to something else? Sorry if >>>>> this is elementary stuff, but the term "gateway" only appears in this >>>>> paragraph. >>>> >>>> That text is present in RFC 2617; I don't understand it completely either. > > This is about web server internals. Back in the early days, when HTTP was > limited to one request per connection, there was a thing called NPH scripts > that would allow a script to directly respond to the client instead of their > response being framed by the server; a trivial implementation could hand > off the file descriptor to the script and exit. However, that kind of > implementation became a potential security hole when persistent connections > were introduced, since the script could redirect the client to a > protected space within the same origin (controlled by someone else) > and receive the redirected request within the script input, bypassing the > web server's normal request-target hierarchy and collecting the credentials. > The solution is to never delegate message framing. > ... Thanks for the explanation, Roy. I have changed that paragraph to: > Basic authentication is also vulnerable to spoofing by counterfeit > servers. If a user can be led to believe that she is connecting to a > host containing information protected by Basic authentication when, > in fact, she is connecting to a hostile server or gateway, then the > attacker can request a password, store it for later use, and feign an > error. Server implementers ought to guard against this sort of > counterfeiting; in particular, software components which can take > over control over the message framing on an existing connection (for > instance, "NPH" ("non parsing of headers") scripts) need to be used > carefully or not at all. () Best regards, Julian From nobody Fri Feb 20 06:01: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 453B61A879A; Fri, 20 Feb 2015 06:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1w2gi39ABW2C; Fri, 20 Feb 2015 06:01:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 946801A87E3; Fri, 20 Feb 2015 06:01:01 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M6Ana-1XeEvY1Z1O-00y9uj; Fri, 20 Feb 2015 15:00:34 +0100 Message-ID: <54E73DF9.5050501@gmx.de> Date: Fri, 20 Feb 2015 15:00:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , http-auth@ietf.org References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com> <877fvda2tp.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:f+CNl1Yjj3irXYTUBnIu6nnFWHJB75gFXI3dHJWb4o0Mt4I49eN WgCs/MUYGnDmKdgFygIVGwg0BEr05F2lHR4jtiqzO4mg8ZQrXfbSXbxmjIvHr4msjQb3hLN 2IIRECaVKI/l47nxdn/j4tBrbcp0St9oQjjQr1Yx3yb5POOvWuZBEQ7DYBcbv5ZLNE2xA9k heloIDyY48KYFzu5Nd18g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: secdir@ietf.org, Julian Reschke , "http-auth@ietf.org" , iesg@ietf.org, draft-ietf-httpauth-basicauth-update.all@tools.ietf.org Subject: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 -- security considerations on timing/guessing attacks 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, 20 Feb 2015 14:01:03 -0000 On 2015-02-20 01:10, Roy T. Fielding wrote: > ... >>> A more reasonable thing to say is that any authentication system that >>> allows a client to perform more than three failed authentication attempts >>> on a single connection, or more than ten on a single account over multiple >>> connections, is likely to be vulnerable to password guessing attacks. >>> Timing attacks then become completely irrelevant. >> >> This is an interesting suggestion, and should be useful against more >> than just timing attacks. How should that filter be applied? It seems >> like it could create some sort of denial of service attack vector if >> it's not done judiciously (e.g. Alice tries to lock out Bob by faking >> bad logins from Bob). > > Yes, what I've seen is typically implemented as a temporary lock-out > on the order of minutes -- long enough to prevent iterative attack > techniques, but short enough that a user wouldn't mind. It is also > sometimes combined with an alert to the user. How to implement it > correctly depends on the overall web server architecture, such as > whether the block is only per-server or covers an entire domain. > > I don't think we need to describe specifically how to implement it. > ... As this advice applies is not specific to Basic: how about putting this on our TODO list for RFC 7235bis? Best regards, Julian From nobody Fri Feb 20 06:16:09 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 1C3B51A879A; Fri, 20 Feb 2015 06:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FaCXQlaSFPEV; Fri, 20 Feb 2015 06:16:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 CCABB1A8759; Fri, 20 Feb 2015 06:16:01 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LmbZb-1XovWR3oBf-00aBuC; Fri, 20 Feb 2015 15:15:57 +0100 Message-ID: <54E74195.7010503@gmx.de> Date: Fri, 20 Feb 2015 15:15:49 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> In-Reply-To: <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KM7+voKM8hXuYcmGMPs4PgK+Jbd2uBpxpZVNewydo5lcKCkbYAH 59Il8lTnyHQ9DvLwLDrTohh0dTS9eWFwz2Mg3ZcjGlqVrZ4EF6ezusnnXaYzOW2sgjnJ5W8 9tjZPw1nxMSWq8d/KXq+ukW69kPEIJn7XJzYk8CjnH0dwf2MdGJ+0WLn9eHZPQWNMkOKeR9 jc3YFyFl3G9572ZTq5BAQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org, Pete Resnick Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 14:16:04 -0000 On 2015-02-20 00:12, Roy T. Fielding wrote: > ... >> It should be something like >> >> The first colon in a user-pass string separates username and password >> from one another; text after the first colon is part of the password. >> Usernames containing colons cannot be encoded in user-pass strings. >> Note that many user agents produce user-pass strings without checking >> that usernames supplied by users do not contain colons; recipients >> will then treat part of the username input as part of the password. >> >> This would actually define the correct interpretation of the first colon >> rather than hinting at what recipients will do, avoid the "will likely" >> speculation, and makes it more clear that colons in usernames are not an >> option offered by the protocol that then needs to be restricted by a >> MUST NOT for interoperability reasons, as far as I am concerned. It is >> also more clear that "user agents accept colons" is an UI issue; with >> the text in the draft `user-id` is used for both "string entered into >> username form field" and "value in Authorization header" which can be >> quite different due to colons. > > +1 (FYI, Apache httpd does exactly that.) > > ....Roy > > ... I changed the text to: > Furthermore, a user-id containing a colon character is invalid, as > the first colon in a user-pass string separates user-id and password > from one another; text after the first colon is part of the password. > User-ids containing colons cannot be encoded in user-pass strings. > > Note that many user agents produce user-pass strings without checking > that user-ids supplied by users do not contain colons; recipients > will then treat part of the username input as part of the password. in . Pete, Barry, does this sound good to you? Best regards, Julian From nobody Fri Feb 20 06:16:10 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 416EF1A87A2; Fri, 20 Feb 2015 06:16:04 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3B51A879A; Fri, 20 Feb 2015 06:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FaCXQlaSFPEV; Fri, 20 Feb 2015 06:16:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 CCABB1A8759; Fri, 20 Feb 2015 06:16:01 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LmbZb-1XovWR3oBf-00aBuC; Fri, 20 Feb 2015 15:15:57 +0100 Message-ID: <54E74195.7010503@gmx.de> Date: Fri, 20 Feb 2015 15:15:49 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> In-Reply-To: <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KM7+voKM8hXuYcmGMPs4PgK+Jbd2uBpxpZVNewydo5lcKCkbYAH 59Il8lTnyHQ9DvLwLDrTohh0dTS9eWFwz2Mg3ZcjGlqVrZ4EF6ezusnnXaYzOW2sgjnJ5W8 9tjZPw1nxMSWq8d/KXq+ukW69kPEIJn7XJzYk8CjnH0dwf2MdGJ+0WLn9eHZPQWNMkOKeR9 jc3YFyFl3G9572ZTq5BAQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org, Pete Resnick Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 14:16:04 -0000 On 2015-02-20 00:12, Roy T. Fielding wrote: > ... >> It should be something like >> >> The first colon in a user-pass string separates username and password >> from one another; text after the first colon is part of the password. >> Usernames containing colons cannot be encoded in user-pass strings. >> Note that many user agents produce user-pass strings without checking >> that usernames supplied by users do not contain colons; recipients >> will then treat part of the username input as part of the password. >> >> This would actually define the correct interpretation of the first colon >> rather than hinting at what recipients will do, avoid the "will likely" >> speculation, and makes it more clear that colons in usernames are not an >> option offered by the protocol that then needs to be restricted by a >> MUST NOT for interoperability reasons, as far as I am concerned. It is >> also more clear that "user agents accept colons" is an UI issue; with >> the text in the draft `user-id` is used for both "string entered into >> username form field" and "value in Authorization header" which can be >> quite different due to colons. > > +1 (FYI, Apache httpd does exactly that.) > > ....Roy > > ... I changed the text to: > Furthermore, a user-id containing a colon character is invalid, as > the first colon in a user-pass string separates user-id and password > from one another; text after the first colon is part of the password. > User-ids containing colons cannot be encoded in user-pass strings. > > Note that many user agents produce user-pass strings without checking > that user-ids supplied by users do not contain colons; recipients > will then treat part of the username input as part of the password. in . Pete, Barry, does this sound good to you? Best regards, Julian From nobody Fri Feb 20 06:31:09 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 AAB491A802E; Fri, 20 Feb 2015 06:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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_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 UGkdaiwJjVVM; Fri, 20 Feb 2015 06:31:06 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 4CC361A037A; Fri, 20 Feb 2015 06:31:05 -0800 (PST) Received: by lbjf15 with SMTP id f15so6468362lbj.13; Fri, 20 Feb 2015 06:31:03 -0800 (PST) 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=VdC6IGQ6Whm5M3EKl76hnZosP9xAcSK3vG1qtAFj25s=; b=p5sKsqJa/gyxMLTX1jWh5+5Rk1l82gAcIfNxzX1MmvDms3Ky798YCoWpUXS2aYzU7o 52EIVtmn1dc/Appcm3F1+l7NXEMpHGK8bDVU1i5z79DOWZwgiCS5rBRte9Zg6wBaZXLO KWyCTHAVKOFdZ1iQY24ueSo0yV/eKQ8kcH9q4jidkzOBzlw+IS6N4sLuJjYUN4Yl2CXb EDrb3cTE6eiUp1NC00L679xjLzGAMNXaj0X8BnOfLFBOv1jEc+IDx5Z6vv/R8a8fHfKi NsS5G29uGN20ZNnpOdQ9aH7bnMKlyGu6xhLSrzWFsdAUaWD6j1pfebS5budaEb28bW8Q UHwQ== MIME-Version: 1.0 X-Received: by 10.152.37.138 with SMTP id y10mr8839713laj.88.1424442663821; Fri, 20 Feb 2015 06:31:03 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Fri, 20 Feb 2015 06:31:03 -0800 (PST) In-Reply-To: <54E74195.7010503@gmx.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> Date: Fri, 20 Feb 2015 06:31:03 -0800 X-Google-Sender-Auth: vYKihZ4sklA5tg98Eh-bwTJFLbo Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org, Pete Resnick Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 14:31:07 -0000 > I changed the text to: > >> Furthermore, a user-id containing a colon character is invalid, as >> the first colon in a user-pass string separates user-id and password >> from one another; text after the first colon is part of the password. >> User-ids containing colons cannot be encoded in user-pass strings. >> >> Note that many user agents produce user-pass strings without checking >> that user-ids supplied by users do not contain colons; recipients >> will then treat part of the username input as part of the password. > > > in . > > Pete, Barry, does this sound good to you? That looks lovely to me. Barry From nobody Fri Feb 20 06:31:14 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C88DD1A8AF3; Fri, 20 Feb 2015 06:31:07 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB491A802E; Fri, 20 Feb 2015 06:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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_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 UGkdaiwJjVVM; Fri, 20 Feb 2015 06:31:06 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 4CC361A037A; Fri, 20 Feb 2015 06:31:05 -0800 (PST) Received: by lbjf15 with SMTP id f15so6468362lbj.13; Fri, 20 Feb 2015 06:31:03 -0800 (PST) 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=VdC6IGQ6Whm5M3EKl76hnZosP9xAcSK3vG1qtAFj25s=; b=p5sKsqJa/gyxMLTX1jWh5+5Rk1l82gAcIfNxzX1MmvDms3Ky798YCoWpUXS2aYzU7o 52EIVtmn1dc/Appcm3F1+l7NXEMpHGK8bDVU1i5z79DOWZwgiCS5rBRte9Zg6wBaZXLO KWyCTHAVKOFdZ1iQY24ueSo0yV/eKQ8kcH9q4jidkzOBzlw+IS6N4sLuJjYUN4Yl2CXb EDrb3cTE6eiUp1NC00L679xjLzGAMNXaj0X8BnOfLFBOv1jEc+IDx5Z6vv/R8a8fHfKi NsS5G29uGN20ZNnpOdQ9aH7bnMKlyGu6xhLSrzWFsdAUaWD6j1pfebS5budaEb28bW8Q UHwQ== MIME-Version: 1.0 X-Received: by 10.152.37.138 with SMTP id y10mr8839713laj.88.1424442663821; Fri, 20 Feb 2015 06:31:03 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Fri, 20 Feb 2015 06:31:03 -0800 (PST) In-Reply-To: <54E74195.7010503@gmx.de> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> Date: Fri, 20 Feb 2015 06:31:03 -0800 X-Google-Sender-Auth: vYKihZ4sklA5tg98Eh-bwTJFLbo Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org, Pete Resnick Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 14:31:07 -0000 > I changed the text to: > >> Furthermore, a user-id containing a colon character is invalid, as >> the first colon in a user-pass string separates user-id and password >> from one another; text after the first colon is part of the password. >> User-ids containing colons cannot be encoded in user-pass strings. >> >> Note that many user agents produce user-pass strings without checking >> that user-ids supplied by users do not contain colons; recipients >> will then treat part of the username input as part of the password. > > > in . > > Pete, Barry, does this sound good to you? That looks lovely to me. Barry From nobody Fri Feb 20 06:45: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 B2F9A1A7007; Fri, 20 Feb 2015 06:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 o9vk39TeGwgV; Fri, 20 Feb 2015 06:44:58 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 9D4151A037A; Fri, 20 Feb 2015 06:44:57 -0800 (PST) Received: by lbjf15 with SMTP id f15so6549554lbj.13; Fri, 20 Feb 2015 06:44:56 -0800 (PST) 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=j9OSsQHJxpjIUbUz3S/6UlRQOYQE8AT3kI08WAdwChk=; b=e8JEfDQaMphnQFWW2cent/Y7HzK1FczWZ5H3wErVbT9oS/UdWcDPl83LXd8JdAWBfs raNcJcJ9nwOfx+33W5gs0fiElWi/wBHPVDfE9NMWVQbuXJqZbp+mT6UlLZRiGWZMTJGb W47jJTgbudlHgHktEMgfpqEFHXyKXdAV5crpv2qo2m525HLaWl0fMCpS1MO5Yw3Har0/ VpOrsb6noptoJiqOt02qwofhCGWR4N1fWmCZ9r6T4uftisB8JzVJOsjuX627LclwYSvN ORsi1VDRvPvV/ymRM5xVV0zYiPG8Ewq187ckV4nnl3b1nJImB879/ytk5x+PaKUB7U81 m8Ng== MIME-Version: 1.0 X-Received: by 10.152.87.134 with SMTP id ay6mr8579004lab.75.1424443496153; Fri, 20 Feb 2015 06:44:56 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 20 Feb 2015 06:44:55 -0800 (PST) In-Reply-To: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> Date: Fri, 20 Feb 2015 09:44:55 -0500 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c25e549747b7050f86183a Archived-At: Cc: Julian Reschke , Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org, Pete Resnick Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 14:44:59 -0000 --001a11c25e549747b7050f86183a Content-Type: text/plain; charset=UTF-8 On Fri, Feb 20, 2015 at 9:31 AM, Barry Leiba wrote: > > I changed the text to: > > > >> Furthermore, a user-id containing a colon character is invalid, as > >> the first colon in a user-pass string separates user-id and password > >> from one another; text after the first colon is part of the password. > >> User-ids containing colons cannot be encoded in user-pass strings. > >> > >> Note that many user agents produce user-pass strings without checking > >> that user-ids supplied by users do not contain colons; recipients > >> will then treat part of the username input as part of the password. > > > > > > in . > > > > Pete, Barry, does this sound good to you? > > That looks lovely to me. > Agreed, that looks much better. Thanks, Kathleen > > Barry > -- Best regards, Kathleen --001a11c25e549747b7050f86183a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 20, 2015 at 9:31 AM, Barry Leiba <barryleiba@compute= r.org> wrote:
> I changed the text to:
>
>>=C2=A0 =C2=A0 Furthermore, a user-id containing a colon character i= s invalid, as
>>=C2=A0 =C2=A0 the first colon in a user-pass string separates user-= id and password
>>=C2=A0 =C2=A0 from one another; text after the first colon is part = of the password.
>>=C2=A0 =C2=A0 User-ids containing colons cannot be encoded in user-= pass strings.
>>
>>=C2=A0 =C2=A0 Note that many user agents produce user-pass strings = without checking
>>=C2=A0 =C2=A0 that user-ids supplied by users do not contain colons= ; recipients
>>=C2=A0 =C2=A0 will then treat part of the username input as part of= the password.
>
>
> in <http://trac.tools.ietf.org/wg/httpauth/trac/change= set/128>.
>
> Pete, Barry, does this sound good to you?

That looks lovely to me.

Agreed,= that looks much better. =C2=A0

Thanks,
= Kathleen

Barry



--

Best regards,
Kathleen
--001a11c25e549747b7050f86183a-- From nobody Fri Feb 20 06:45:09 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D21F81A8033; Fri, 20 Feb 2015 06:44:59 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F9A1A7007; Fri, 20 Feb 2015 06:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 o9vk39TeGwgV; Fri, 20 Feb 2015 06:44:58 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 9D4151A037A; Fri, 20 Feb 2015 06:44:57 -0800 (PST) Received: by lbjf15 with SMTP id f15so6549554lbj.13; Fri, 20 Feb 2015 06:44:56 -0800 (PST) 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=j9OSsQHJxpjIUbUz3S/6UlRQOYQE8AT3kI08WAdwChk=; b=e8JEfDQaMphnQFWW2cent/Y7HzK1FczWZ5H3wErVbT9oS/UdWcDPl83LXd8JdAWBfs raNcJcJ9nwOfx+33W5gs0fiElWi/wBHPVDfE9NMWVQbuXJqZbp+mT6UlLZRiGWZMTJGb W47jJTgbudlHgHktEMgfpqEFHXyKXdAV5crpv2qo2m525HLaWl0fMCpS1MO5Yw3Har0/ VpOrsb6noptoJiqOt02qwofhCGWR4N1fWmCZ9r6T4uftisB8JzVJOsjuX627LclwYSvN ORsi1VDRvPvV/ymRM5xVV0zYiPG8Ewq187ckV4nnl3b1nJImB879/ytk5x+PaKUB7U81 m8Ng== MIME-Version: 1.0 X-Received: by 10.152.87.134 with SMTP id ay6mr8579004lab.75.1424443496153; Fri, 20 Feb 2015 06:44:56 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 20 Feb 2015 06:44:55 -0800 (PST) In-Reply-To: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> Date: Fri, 20 Feb 2015 09:44:55 -0500 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c25e549747b7050f86183a Archived-At: Cc: Julian Reschke , Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org, Pete Resnick Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 14:45:00 -0000 --001a11c25e549747b7050f86183a Content-Type: text/plain; charset=UTF-8 On Fri, Feb 20, 2015 at 9:31 AM, Barry Leiba wrote: > > I changed the text to: > > > >> Furthermore, a user-id containing a colon character is invalid, as > >> the first colon in a user-pass string separates user-id and password > >> from one another; text after the first colon is part of the password. > >> User-ids containing colons cannot be encoded in user-pass strings. > >> > >> Note that many user agents produce user-pass strings without checking > >> that user-ids supplied by users do not contain colons; recipients > >> will then treat part of the username input as part of the password. > > > > > > in . > > > > Pete, Barry, does this sound good to you? > > That looks lovely to me. > Agreed, that looks much better. Thanks, Kathleen > > Barry > -- Best regards, Kathleen --001a11c25e549747b7050f86183a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 20, 2015 at 9:31 AM, Barry Leiba <barryleiba@compute= r.org> wrote:
> I changed the text to:
>
>>=C2=A0 =C2=A0 Furthermore, a user-id containing a colon character i= s invalid, as
>>=C2=A0 =C2=A0 the first colon in a user-pass string separates user-= id and password
>>=C2=A0 =C2=A0 from one another; text after the first colon is part = of the password.
>>=C2=A0 =C2=A0 User-ids containing colons cannot be encoded in user-= pass strings.
>>
>>=C2=A0 =C2=A0 Note that many user agents produce user-pass strings = without checking
>>=C2=A0 =C2=A0 that user-ids supplied by users do not contain colons= ; recipients
>>=C2=A0 =C2=A0 will then treat part of the username input as part of= the password.
>
>
> in <http://trac.tools.ietf.org/wg/httpauth/trac/change= set/128>.
>
> Pete, Barry, does this sound good to you?

That looks lovely to me.

Agreed,= that looks much better. =C2=A0

Thanks,
= Kathleen

Barry



--

Best regards,
Kathleen
--001a11c25e549747b7050f86183a-- From nobody Fri Feb 20 07:50: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 052751A8781; Fri, 20 Feb 2015 07:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLRrBy2pR4vE; Fri, 20 Feb 2015 07:50:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 E62941A8547; Fri, 20 Feb 2015 07:50:01 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M7HGA-1Xapi23egY-00x41H; Fri, 20 Feb 2015 16:49:37 +0100 Message-ID: <54E75788.2020809@gmx.de> Date: Fri, 20 Feb 2015 16:49:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , draft-ietf-httpauth-basicauth-update.all@tools.ietf.org References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> In-Reply-To: <87mw49ac9h.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:nybL+O+WEV2E2oNVzXd3cY33aepJfgT07Yvq4oqwF7jfr+B6Y3M cgvgO7JvmjavSGkYaPWC3LlBVbdpz3DwtN9weSTpNnPjmGZPI7SQeo0ErZwqKAteO5/SEPL qGsfOzcF0Qy1RNc3pvsU/6vVy5HPPXgdRQkFUWQLTT0CvsCMTxEbnPG0jQ+uaBKKQXNY/p3 fTtXyHhQJi+zaT+mVuC3g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06 -- transition strategy for charset parameter 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, 20 Feb 2015 15:50:04 -0000 On 2015-02-19 21:15, Daniel Kahn Gillmor wrote: > ... >> That being said, the heuristics are quite simple: try to decode the >> octets with a strict UTF-8 decoder, and if that doesn't fail the input >> was likely encoded in UTF-8. > > Some binary strings are valid in both character encodings, though, > right? For example, "c3 a1 62 63" in UTF-8 is "ábc", but in ISO-8859-1, > it is "ábc" So if my password is non-ASCII in the first place, it could > very well match the UTF-8 encoding even though i've intended another > one. > > So maybe the heuristic should be: even if the UTF-8 decode succeeds, the > server could try its fallback decoding mechanism if the UTF-8 version of > the password doesn't match. (fwiw, my understanding is that facebook > checks common accidental variations on the entered password during their > (non-basic-auth) login process. so if my password is b4nanAs, but i > type B4NANaS or b5nanAs, facebook might let me in anyway) > > Is this advisable? What are the risks of testing two variants of the > password against the password table? I haven't thought this through > fully, but it seems like it would be a relevant consideration. > > In the absence of a signal from the client about their choice of > encoding, documenting these heuristics and recommending them seems like > a useful way to facilitate adoption and uniformity among servers > implementing this spec. > ... I looked at this some more, and it seems that the general question applies to the third paragraph in B.2 (): Finally, origin servers that need to support non-US-ASCII characters and can use the UTF-8 character encoding scheme can opt in as described above. In the worst case, they'll continue to see either broken credentials or no credentials at all (depending on how legacy clients handle characters they cannot encode). I propose to expand the problem description, and to mention that servers that need to support a mix of clients can attempt a "try both" strategy: Finally, origin servers that need to support non-US-ASCII characters and can use the UTF-8 character encoding scheme can opt in by specifying the charset parameter in the authentication challenge. Clients that do understand the charset parameter will then start to use UTF-8, while other clients will continue to send credentials in their default encoding, broken credentials, or no credentials at all. Until all clients are upgraded to support UTF-8, servers are likely to see both UTF-8 and "legacy" encodings in requests. When processing as UTF-8 fails (due to a failure to decode as UTF-8 or a mismatch of user-id/password), a server might try a fallback to the previously supported legacy encoding in order to accomodate these legacy clients. Note that implicit retries need to be done carefully; for instance, some subsystems might detect repeated login failures and treat them as potential credentials guessing attack. (). WDYT? Best regards, Julian PS: slightly related: this section talks about origin servers instead of servers (-> proxy authentication); I'll fix that as well. From nobody Fri Feb 20 07:56: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 7DCCD1A87E9 for ; Fri, 20 Feb 2015 07:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cqdDoGdWCHIn for ; Fri, 20 Feb 2015 07:56:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 A70221A87C9 for ; Fri, 20 Feb 2015 07:55:59 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LtZfc-1XOFUv1HyW-010tzt for ; Fri, 20 Feb 2015 16:55:57 +0100 Message-ID: <54E75907.8040505@gmx.de> Date: Fri, 20 Feb 2015 16:55:51 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:dy7G12g1KanV1YrJEz2VzR7VsPx4GB8RxBflLUeyy7ASHSs9rf2 1xpuT9yMqcLojRki3r+6xrsheOmgLx33ndgq0AtKPX3Wg3N1V7o2+oG/biCFRzaFR6fNqNA Pmdq3MgRU5gJWFwckdKckPurVjNZzXw/qprK/oIzgre9J+iJH+4/FoHa0xpnKrXLdl6F948 ULDPDXlEPZ/6fJRo00oIQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [http-auth] Basic authentication scheme post IETF-LC , secdir, and IESG review updates 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, 20 Feb 2015 15:56:01 -0000 Hi there, I've made a bunch of changes to address IETF-LC, secdif, and IESG feedback. The draft has not been submitted yet, but all changes are in the WG's svn repository (). The changes relative to the IETF LC draft (05) are: The full text is in and ). Feedback welcome! Best regards, Julian From nobody Fri Feb 20 08:09:46 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 4B10E1A0066; Fri, 20 Feb 2015 08:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 RjGGv1DhbaUg; Fri, 20 Feb 2015 08:09:39 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19761A877A; Fri, 20 Feb 2015 08:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1424448574; x=1455984574; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uqYF1wnGfZg5tHz7SfoYoY5ZSmcTbt75+Svn2almAEU=; b=tAPecdqVdntFOK/DFR/pyBNVc10wiRHMhXcXg8nFv2AfU87+hf5vC4m7 2pdeRkiN1S/STgFN766MB+GMEtO51TvAw6gWiDrL7osK/xfTcpUZi4Ud/ IZmYC5KZ1UxMxcZwiwW5gIctPXbLT/m6BmqSIgz551EP51HtKtU2Ko8Ao I=; X-IronPort-AV: E=McAfee;i="5600,1067,7717"; a="104414606" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Feb 2015 08:09:34 -0800 X-IronPort-AV: E=Sophos;i="5.09,615,1418112000"; d="scan'208";a="844866944" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Feb 2015 08:09:34 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 20 Feb 2015 08:09:32 -0800 Message-ID: <54E75C3B.7070605@qti.qualcomm.com> Date: Fri, 20 Feb 2015 10:09:31 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> In-Reply-To: <54E74195.7010503@gmx.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 16:09:41 -0000 On 2/20/15 8:15 AM, Julian Reschke wrote: > I changed the text to: > >> Furthermore, a user-id containing a colon character is invalid, as >> the first colon in a user-pass string separates user-id and password >> from one another; text after the first colon is part of the password. >> User-ids containing colons cannot be encoded in user-pass strings. >> >> Note that many user agents produce user-pass strings without checking >> that user-ids supplied by users do not contain colons; recipients >> will then treat part of the username input as part of the password. > > in . > > Pete, Barry, does this sound good to you? It's fine. I will admit to still being a bit mystified about the reluctance to use the imperative, because really implementations MUST NOT be putting user-ids with colons on the wire if they expect interoperation. But the above defines the syntax just fine, and there's no reading the above and thinking that it's OK to put a colon in the user-id portion of the user-pass string and expect it to work. So go for it. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Feb 20 08:09:47 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6E6D11A854B; Fri, 20 Feb 2015 08:09:41 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B10E1A0066; Fri, 20 Feb 2015 08:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 RjGGv1DhbaUg; Fri, 20 Feb 2015 08:09:39 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19761A877A; Fri, 20 Feb 2015 08:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1424448574; x=1455984574; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uqYF1wnGfZg5tHz7SfoYoY5ZSmcTbt75+Svn2almAEU=; b=tAPecdqVdntFOK/DFR/pyBNVc10wiRHMhXcXg8nFv2AfU87+hf5vC4m7 2pdeRkiN1S/STgFN766MB+GMEtO51TvAw6gWiDrL7osK/xfTcpUZi4Ud/ IZmYC5KZ1UxMxcZwiwW5gIctPXbLT/m6BmqSIgz551EP51HtKtU2Ko8Ao I=; X-IronPort-AV: E=McAfee;i="5600,1067,7717"; a="104414606" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Feb 2015 08:09:34 -0800 X-IronPort-AV: E=Sophos;i="5.09,615,1418112000"; d="scan'208";a="844866944" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Feb 2015 08:09:34 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 20 Feb 2015 08:09:32 -0800 Message-ID: <54E75C3B.7070605@qti.qualcomm.com> Date: Fri, 20 Feb 2015 10:09:31 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> In-Reply-To: <54E74195.7010503@gmx.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 16:09:41 -0000 On 2/20/15 8:15 AM, Julian Reschke wrote: > I changed the text to: > >> Furthermore, a user-id containing a colon character is invalid, as >> the first colon in a user-pass string separates user-id and password >> from one another; text after the first colon is part of the password. >> User-ids containing colons cannot be encoded in user-pass strings. >> >> Note that many user agents produce user-pass strings without checking >> that user-ids supplied by users do not contain colons; recipients >> will then treat part of the username input as part of the password. > > in . > > Pete, Barry, does this sound good to you? It's fine. I will admit to still being a bit mystified about the reluctance to use the imperative, because really implementations MUST NOT be putting user-ids with colons on the wire if they expect interoperation. But the above defines the syntax just fine, and there's no reading the above and thinking that it's OK to put a colon in the user-id portion of the user-pass string and expect it to work. So go for it. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Feb 20 08:52:04 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 6305D1A0366; Fri, 20 Feb 2015 08:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 EbEdcUg_FAv3; Fri, 20 Feb 2015 08:51:58 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 C4B561A0187; Fri, 20 Feb 2015 08:51:57 -0800 (PST) Received: by lbiw7 with SMTP id w7so7382789lbi.10; Fri, 20 Feb 2015 08:51:56 -0800 (PST) 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=HF/+aq3J9xLCjAhwPbIjQPNaUCqBKJ9m8qKw+OXduAw=; b=pg5w1evKr/GNLVvcOiK7lYZwIx5NXXRrs0ycOj5MYe52ukbVOluXWVu8jXTpq/KlHn mn2OiWzOpEstWSSzQevb4qtJRcUmAH8knOr1B/RAV8YaUfPPTaUKiSh7Km4FFbTkyVp8 FUcbL5y0uyR8rBw9dLStJtCMY6ud6WVfGhZzxoJdrb0Absxl6MJtgpWaN/lSE5OwVuLV U33L9U67+WKIkPL86To2ROMRO7Edv5JpzRg2FHxKmgohicGtmhP163n4KEXQb6OtcnGf KnogJaZmzZGqZjU/NIrpe/Vu/J/F43k8hoHQtOoCWCVdSNGAboSB09vk2EdBj54RQRa9 xetw== MIME-Version: 1.0 X-Received: by 10.112.97.106 with SMTP id dz10mr9442604lbb.4.1424451116057; Fri, 20 Feb 2015 08:51:56 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 20 Feb 2015 08:51:55 -0800 (PST) In-Reply-To: <54E75C3B.7070605@qti.qualcomm.com> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> <54E75C3B.7070605@qti.qualcomm.com> Date: Fri, 20 Feb 2015 11:51:55 -0500 Message-ID: From: Kathleen Moriarty To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11345b12c5ca92050f87de75 Archived-At: Cc: Julian Reschke , Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 16:52:00 -0000 --001a11345b12c5ca92050f87de75 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 20, 2015 at 11:09 AM, Pete Resnick wrote: > On 2/20/15 8:15 AM, Julian Reschke wrote: > >> I changed the text to: >> >> Furthermore, a user-id containing a colon character is invalid, as >>> the first colon in a user-pass string separates user-id and password >>> from one another; text after the first colon is part of the password. >>> User-ids containing colons cannot be encoded in user-pass strings. >>> >>> Note that many user agents produce user-pass strings without checking >>> that user-ids supplied by users do not contain colons; recipients >>> will then treat part of the username input as part of the password. >>> >> >> in . >> >> Pete, Barry, does this sound good to you? >> > > It's fine. I will admit to still being a bit mystified about the > reluctance to use the imperative, because really implementations MUST NOT > be putting user-ids with colons on the wire if they expect interoperation. > But the above defines the syntax just fine, and there's no reading the > above and thinking that it's OK to put a colon in the user-id portion of > the user-pass string and expect it to work. So go for it. Pete, Ted supported your stance and I'm fine with the MUST NOT as we are all saying the same thing. This language is better than what was there before and essentially means the same thing as MUST NOT. Julian, is there any reason not to have the MUST NOT as I don't see it. Thanks, Kathleen > > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- Best regards, Kathleen --001a11345b12c5ca92050f87de75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 20, 2015 at 11:09 AM, Pete Resnick <presnick@qti.q= ualcomm.com> wrote:
On 2/20/15 8:15 AM, Julian Reschke wrote:
I changed the text to:

=C2=A0 =C2=A0Furthermore, a user-id containing a colon character is invalid= , as
=C2=A0 =C2=A0the first colon in a user-pass string separates user-id and pa= ssword
=C2=A0 =C2=A0from one another; text after the first colon is part of the pa= ssword.
=C2=A0 =C2=A0User-ids containing colons cannot be encoded in user-pass stri= ngs.

=C2=A0 =C2=A0Note that many user agents produce user-pass strings without c= hecking
=C2=A0 =C2=A0that user-ids supplied by users do not contain colons; recipie= nts
=C2=A0 =C2=A0will then treat part of the username input as part of the pass= word.

in <http://trac.tools.ietf.org/wg/httpauth/trac/chan= geset/128>.

Pete, Barry, does this sound good to you?

 It's fine. I will admit to still being a bit mystified about the reluct= ance to use the imperative, because really implementations MUST NOT be putt= ing user-ids with colons on the wire if they expect interoperation. But the= above defines the syntax just fine, and there's no reading the above a= nd thinking that it's OK to put a colon in the user-id portion of the u= ser-pass string and expect it to work. So go for it.

<= /div>
Pete, Ted supported your stance and I'm fine with the MUST NO= T as we are all saying the same thing. This language is better than what wa= s there before and essentially means the same thing as MUST NOT.=C2=A0 Juli= an, is there any reason not to have the MUST NOT as I don't see it.

Thanks,
Kathleen


pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478




--
=

Best regards,
Kathleen
--001a11345b12c5ca92050f87de75-- From nobody Fri Feb 20 08:52:05 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8F3831A0368; Fri, 20 Feb 2015 08:52:00 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6305D1A0366; Fri, 20 Feb 2015 08:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 EbEdcUg_FAv3; Fri, 20 Feb 2015 08:51:58 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 C4B561A0187; Fri, 20 Feb 2015 08:51:57 -0800 (PST) Received: by lbiw7 with SMTP id w7so7382789lbi.10; Fri, 20 Feb 2015 08:51:56 -0800 (PST) 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=HF/+aq3J9xLCjAhwPbIjQPNaUCqBKJ9m8qKw+OXduAw=; b=pg5w1evKr/GNLVvcOiK7lYZwIx5NXXRrs0ycOj5MYe52ukbVOluXWVu8jXTpq/KlHn mn2OiWzOpEstWSSzQevb4qtJRcUmAH8knOr1B/RAV8YaUfPPTaUKiSh7Km4FFbTkyVp8 FUcbL5y0uyR8rBw9dLStJtCMY6ud6WVfGhZzxoJdrb0Absxl6MJtgpWaN/lSE5OwVuLV U33L9U67+WKIkPL86To2ROMRO7Edv5JpzRg2FHxKmgohicGtmhP163n4KEXQb6OtcnGf KnogJaZmzZGqZjU/NIrpe/Vu/J/F43k8hoHQtOoCWCVdSNGAboSB09vk2EdBj54RQRa9 xetw== MIME-Version: 1.0 X-Received: by 10.112.97.106 with SMTP id dz10mr9442604lbb.4.1424451116057; Fri, 20 Feb 2015 08:51:56 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 20 Feb 2015 08:51:55 -0800 (PST) In-Reply-To: <54E75C3B.7070605@qti.qualcomm.com> References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> <54E75C3B.7070605@qti.qualcomm.com> Date: Fri, 20 Feb 2015 11:51:55 -0500 Message-ID: From: Kathleen Moriarty To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11345b12c5ca92050f87de75 Archived-At: Cc: Julian Reschke , Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , Barry Leiba , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 16:52:00 -0000 --001a11345b12c5ca92050f87de75 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 20, 2015 at 11:09 AM, Pete Resnick wrote: > On 2/20/15 8:15 AM, Julian Reschke wrote: > >> I changed the text to: >> >> Furthermore, a user-id containing a colon character is invalid, as >>> the first colon in a user-pass string separates user-id and password >>> from one another; text after the first colon is part of the password. >>> User-ids containing colons cannot be encoded in user-pass strings. >>> >>> Note that many user agents produce user-pass strings without checking >>> that user-ids supplied by users do not contain colons; recipients >>> will then treat part of the username input as part of the password. >>> >> >> in . >> >> Pete, Barry, does this sound good to you? >> > > It's fine. I will admit to still being a bit mystified about the > reluctance to use the imperative, because really implementations MUST NOT > be putting user-ids with colons on the wire if they expect interoperation. > But the above defines the syntax just fine, and there's no reading the > above and thinking that it's OK to put a colon in the user-id portion of > the user-pass string and expect it to work. So go for it. Pete, Ted supported your stance and I'm fine with the MUST NOT as we are all saying the same thing. This language is better than what was there before and essentially means the same thing as MUST NOT. Julian, is there any reason not to have the MUST NOT as I don't see it. Thanks, Kathleen > > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- Best regards, Kathleen --001a11345b12c5ca92050f87de75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 20, 2015 at 11:09 AM, Pete Resnick <presnick@qti.q= ualcomm.com> wrote:
On 2/20/15 8:15 AM, Julian Reschke wrote:
I changed the text to:

=C2=A0 =C2=A0Furthermore, a user-id containing a colon character is invalid= , as
=C2=A0 =C2=A0the first colon in a user-pass string separates user-id and pa= ssword
=C2=A0 =C2=A0from one another; text after the first colon is part of the pa= ssword.
=C2=A0 =C2=A0User-ids containing colons cannot be encoded in user-pass stri= ngs.

=C2=A0 =C2=A0Note that many user agents produce user-pass strings without c= hecking
=C2=A0 =C2=A0that user-ids supplied by users do not contain colons; recipie= nts
=C2=A0 =C2=A0will then treat part of the username input as part of the pass= word.

in <http://trac.tools.ietf.org/wg/httpauth/trac/chan= geset/128>.

Pete, Barry, does this sound good to you?

 It's fine. I will admit to still being a bit mystified about the reluct= ance to use the imperative, because really implementations MUST NOT be putt= ing user-ids with colons on the wire if they expect interoperation. But the= above defines the syntax just fine, and there's no reading the above a= nd thinking that it's OK to put a colon in the user-id portion of the u= ser-pass string and expect it to work. So go for it.

<= /div>
Pete, Ted supported your stance and I'm fine with the MUST NO= T as we are all saying the same thing. This language is better than what wa= s there before and essentially means the same thing as MUST NOT.=C2=A0 Juli= an, is there any reason not to have the MUST NOT as I don't see it.

Thanks,
Kathleen


pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478




--
=

Best regards,
Kathleen
--001a11345b12c5ca92050f87de75-- From nobody Fri Feb 20 09:27:09 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 9B31A1A1BFA; Fri, 20 Feb 2015 09:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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_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 5AMBhhGT3jhB; Fri, 20 Feb 2015 09:27:03 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 09E7B1A1BB9; Fri, 20 Feb 2015 09:27:03 -0800 (PST) Received: by lbjf15 with SMTP id f15so7523374lbj.13; Fri, 20 Feb 2015 09:27:01 -0800 (PST) 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=gN+A8r+vHIHf5U+eQEAeIA+Rn1tJ1jyEubnfvOR6ymk=; b=Jxzv9KPe/kl92XwekR4EfMxB6rjxcQ3MksDCSHrz/TcpquULDQZLvhP5K5S6/i2/QX t7hRHgK+3nkkDFqCrs35xy5RKUI4+iBT1n/4fo6z1vzilZyq+PKe3I+rjCdQW4oRaFOP zEsxz4Ut7GdBHdKlMhQ4WLb5oqcolM9/1603fkitw4x8jq5viYDpW+nOw5IS3MyUngWr nduWD045haof9ur36YF+5q3DMDMOCvoGEw+C4kZaZBf7mt1EmLHLQRggA9RhFS308D9/ UOwHyrqLA+3a9BeSQeRwVztkSZVd3KC5SeEcMzgCBzocNRaOgGAlCQ5/jOCbCXqG/w2m yCfg== MIME-Version: 1.0 X-Received: by 10.152.23.233 with SMTP id p9mr9406842laf.123.1424453221391; Fri, 20 Feb 2015 09:27:01 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Fri, 20 Feb 2015 09:27:01 -0800 (PST) In-Reply-To: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> <54E75C3B.7070605@qti.qualcomm.com> Date: Fri, 20 Feb 2015 09:27:01 -0800 X-Google-Sender-Auth: SSFicX-jPGxse-uRwo5wZicz34E Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Julian Reschke , Pete Resnick , Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 17:27:04 -0000 > Pete, Ted supported your stance and I'm fine with the MUST NOT as we are all > saying the same thing. This language is better than what was there before > and essentially means the same thing as MUST NOT. Julian, is there any > reason not to have the MUST NOT as I don't see it. Julian's already given his reasons, and I, at least, don't see any point in discussing it further. I think the text is fine, and is, as you say, effectively the same as MUST NOT, so at this point we're just talking about personal preferences in wording... which, at some point, ADs need to let go of. Methinks it's time to let go of it. At some time it might be good to get community consensus on 2119 key words not being "conformance language". I think this isn't that time. Barry From nobody Fri Feb 20 09:27:10 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BD5351A3BA1; Fri, 20 Feb 2015 09:27:04 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B31A1A1BFA; Fri, 20 Feb 2015 09:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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_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 5AMBhhGT3jhB; Fri, 20 Feb 2015 09:27:03 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 09E7B1A1BB9; Fri, 20 Feb 2015 09:27:03 -0800 (PST) Received: by lbjf15 with SMTP id f15so7523374lbj.13; Fri, 20 Feb 2015 09:27:01 -0800 (PST) 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=gN+A8r+vHIHf5U+eQEAeIA+Rn1tJ1jyEubnfvOR6ymk=; b=Jxzv9KPe/kl92XwekR4EfMxB6rjxcQ3MksDCSHrz/TcpquULDQZLvhP5K5S6/i2/QX t7hRHgK+3nkkDFqCrs35xy5RKUI4+iBT1n/4fo6z1vzilZyq+PKe3I+rjCdQW4oRaFOP zEsxz4Ut7GdBHdKlMhQ4WLb5oqcolM9/1603fkitw4x8jq5viYDpW+nOw5IS3MyUngWr nduWD045haof9ur36YF+5q3DMDMOCvoGEw+C4kZaZBf7mt1EmLHLQRggA9RhFS308D9/ UOwHyrqLA+3a9BeSQeRwVztkSZVd3KC5SeEcMzgCBzocNRaOgGAlCQ5/jOCbCXqG/w2m yCfg== MIME-Version: 1.0 X-Received: by 10.152.23.233 with SMTP id p9mr9406842laf.123.1424453221391; Fri, 20 Feb 2015 09:27:01 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Fri, 20 Feb 2015 09:27:01 -0800 (PST) In-Reply-To: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> <54E75C3B.7070605@qti.qualcomm.com> Date: Fri, 20 Feb 2015 09:27:01 -0800 X-Google-Sender-Auth: SSFicX-jPGxse-uRwo5wZicz34E Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Julian Reschke , Pete Resnick , Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 17:27:05 -0000 > Pete, Ted supported your stance and I'm fine with the MUST NOT as we are all > saying the same thing. This language is better than what was there before > and essentially means the same thing as MUST NOT. Julian, is there any > reason not to have the MUST NOT as I don't see it. Julian's already given his reasons, and I, at least, don't see any point in discussing it further. I think the text is fine, and is, as you say, effectively the same as MUST NOT, so at this point we're just talking about personal preferences in wording... which, at some point, ADs need to let go of. Methinks it's time to let go of it. At some time it might be good to get community consensus on 2119 key words not being "conformance language". I think this isn't that time. Barry From nobody Fri Feb 20 09:57:04 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 D89411A89E0; Fri, 20 Feb 2015 09:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 kRwrHm5TuEby; Fri, 20 Feb 2015 09:56:58 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 2965C1A883A; Fri, 20 Feb 2015 09:47:48 -0800 (PST) Received: by labhz20 with SMTP id hz20so7641164lab.0; Fri, 20 Feb 2015 09:47:46 -0800 (PST) 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=u7/2mBTHw7UO300lL/LkTs3XK+s3CFyw24DhP1oY9EQ=; b=POUyb2znxdyqWdiZXcB8fEYhLvVmMcVvSIfxcpkJCSSfyIVNrY0KR5QP6q4vMYEtMy gILmo2zCdqkzopxAxud2Nvulgo2kN0/J37Biaq2oABlkQ27F0jbDKCkYeBNztnqexGYp g2nGpdnzpw7s2QHxIzQMWCX4Vzs7K01CeJwb86MYOw5u/SHyKUcfYR1yU03FsoSgaOiy PfYjRwBl2togyhdu6AuDAfHFiKJos0sp8KeVMnl5mNGkTJwn4Etptp0q9IUgh6ffn/9K LEqr3awu3hGAQN3n/xd6SYnmS++HDBqQgcOi4sn4MvH/fLMomFmLcuEnfF5MVLzaBaCi KfJA== MIME-Version: 1.0 X-Received: by 10.112.90.193 with SMTP id by1mr9295496lbb.113.1424454466613; Fri, 20 Feb 2015 09:47:46 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 20 Feb 2015 09:47:46 -0800 (PST) In-Reply-To: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> <54E75C3B.7070605@qti.qualcomm.com> Date: Fri, 20 Feb 2015 12:47:46 -0500 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=001a1133ae127b3662050f88a6f2 Archived-At: Cc: Julian Reschke , Pete Resnick , Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 17:57:00 -0000 --001a1133ae127b3662050f88a6f2 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 20, 2015 at 12:27 PM, Barry Leiba wrote: > > Pete, Ted supported your stance and I'm fine with the MUST NOT as we are > all > > saying the same thing. This language is better than what was there before > > and essentially means the same thing as MUST NOT. Julian, is there any > > reason not to have the MUST NOT as I don't see it. > > Julian's already given his reasons, and I, at least, don't see any > point in discussing it further. I think the text is fine, and is, as > you say, effectively the same as MUST NOT, so at this point we're just > talking about personal preferences in wording... which, at some point, > ADs need to let go of. Methinks it's time to let go of it. > > At some time it might be good to get community consensus on 2119 key > words not being "conformance language". I think this isn't that time. > OK, just being thorough for Pete's concern. Thanks everyone! > > Barry > -- Best regards, Kathleen --001a1133ae127b3662050f88a6f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 20, 2015 at 12:27 PM, Barry Leiba <barryleiba@comput= er.org> wrote:
> Pete, Ted supported your stance and I'm fine with the MUST N= OT as we are all
> saying the same thing. This language is better than what was there bef= ore
> and essentially means the same thing as MUST NOT.=C2=A0 Julian, is the= re any
> reason not to have the MUST NOT as I don't see it.

Julian's already given his reasons, and I, at least, don't s= ee any
point in discussing it further.=C2=A0 I think the text is fine, and is, as<= br> you say, effectively the same as MUST NOT, so at this point we're just<= br> talking about personal preferences in wording... which, at some point,
ADs need to let go of.=C2=A0 Methinks it's time to let go of it.

At some time it might be good to get community consensus on 2119 key
words not being "conformance language".=C2=A0 I think this isn= 9;t that time.

OK, just being thorough = for Pete's concern.

Thanks everyone!=C2=A0

Barry



--

Best regards,
Kathleen
--001a1133ae127b3662050f88a6f2-- From nobody Fri Feb 20 09:57:05 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 032BD1A8FD7; Fri, 20 Feb 2015 09:56:59 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89411A89E0; Fri, 20 Feb 2015 09:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 kRwrHm5TuEby; Fri, 20 Feb 2015 09:56:58 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 2965C1A883A; Fri, 20 Feb 2015 09:47:48 -0800 (PST) Received: by labhz20 with SMTP id hz20so7641164lab.0; Fri, 20 Feb 2015 09:47:46 -0800 (PST) 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=u7/2mBTHw7UO300lL/LkTs3XK+s3CFyw24DhP1oY9EQ=; b=POUyb2znxdyqWdiZXcB8fEYhLvVmMcVvSIfxcpkJCSSfyIVNrY0KR5QP6q4vMYEtMy gILmo2zCdqkzopxAxud2Nvulgo2kN0/J37Biaq2oABlkQ27F0jbDKCkYeBNztnqexGYp g2nGpdnzpw7s2QHxIzQMWCX4Vzs7K01CeJwb86MYOw5u/SHyKUcfYR1yU03FsoSgaOiy PfYjRwBl2togyhdu6AuDAfHFiKJos0sp8KeVMnl5mNGkTJwn4Etptp0q9IUgh6ffn/9K LEqr3awu3hGAQN3n/xd6SYnmS++HDBqQgcOi4sn4MvH/fLMomFmLcuEnfF5MVLzaBaCi KfJA== MIME-Version: 1.0 X-Received: by 10.112.90.193 with SMTP id by1mr9295496lbb.113.1424454466613; Fri, 20 Feb 2015 09:47:46 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 20 Feb 2015 09:47:46 -0800 (PST) In-Reply-To: References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <54E58D9C.5020207@gmx.de> <54E61331.7080807@greenbytes.de> <1goceat2c0sh1sifsuq6rv7u5bbth190vq@hive.bjoern.hoehrmann.de> <54E66703.50207@gmx.de> <1spceahm85je6hntfufprl183lam06bjgi@hive.bjoern.hoehrmann.de> <9FFC8911-ADD5-41F5-BC9E-5E78BAEB53CE@gbiv.com> <54E74195.7010503@gmx.de> <54E75C3B.7070605@qti.qualcomm.com> Date: Fri, 20 Feb 2015 12:47:46 -0500 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=001a1133ae127b3662050f88a6f2 Archived-At: Cc: Julian Reschke , Pete Resnick , Bjoern Hoehrmann , httpauth-chairs@ietf.org, "http-auth@ietf.org" , The IESG , draft-ietf-httpauth-basicauth-update.all@ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (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, 20 Feb 2015 17:57:00 -0000 --001a1133ae127b3662050f88a6f2 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 20, 2015 at 12:27 PM, Barry Leiba wrote: > > Pete, Ted supported your stance and I'm fine with the MUST NOT as we are > all > > saying the same thing. This language is better than what was there before > > and essentially means the same thing as MUST NOT. Julian, is there any > > reason not to have the MUST NOT as I don't see it. > > Julian's already given his reasons, and I, at least, don't see any > point in discussing it further. I think the text is fine, and is, as > you say, effectively the same as MUST NOT, so at this point we're just > talking about personal preferences in wording... which, at some point, > ADs need to let go of. Methinks it's time to let go of it. > > At some time it might be good to get community consensus on 2119 key > words not being "conformance language". I think this isn't that time. > OK, just being thorough for Pete's concern. Thanks everyone! > > Barry > -- Best regards, Kathleen --001a1133ae127b3662050f88a6f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 20, 2015 at 12:27 PM, Barry Leiba <barryleiba@comput= er.org> wrote:
> Pete, Ted supported your stance and I'm fine with the MUST N= OT as we are all
> saying the same thing. This language is better than what was there bef= ore
> and essentially means the same thing as MUST NOT.=C2=A0 Julian, is the= re any
> reason not to have the MUST NOT as I don't see it.

Julian's already given his reasons, and I, at least, don't s= ee any
point in discussing it further.=C2=A0 I think the text is fine, and is, as<= br> you say, effectively the same as MUST NOT, so at this point we're just<= br> talking about personal preferences in wording... which, at some point,
ADs need to let go of.=C2=A0 Methinks it's time to let go of it.

At some time it might be good to get community consensus on 2119 key
words not being "conformance language".=C2=A0 I think this isn= 9;t that time.

OK, just being thorough = for Pete's concern.

Thanks everyone!=C2=A0

Barry



--

Best regards,
Kathleen
--001a1133ae127b3662050f88a6f2-- From nobody Tue Feb 24 05:56:30 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 741371A1A82; Tue, 24 Feb 2015 05:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, 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 dVO8OZdGVRfH; Tue, 24 Feb 2015 05:56:23 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C05D1A1AE6; Tue, 24 Feb 2015 05:56:23 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 5038ce45.0.4798030.00-2331.13494641.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 24 Feb 2015 13:56:23 +0000 (UTC) X-MXL-Hash: 54ec830719bcac5e-253cd24390c5f32065b2bfebe308a4f61dbb9c7c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODuKB3008578; Tue, 24 Feb 2015 08:56:20 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODuGF1008562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Feb 2015 08:56:18 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 24 Feb 2015 13:56:04 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODu3ZD005610; Tue, 24 Feb 2015 08:56:04 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODtuZ6005177; Tue, 24 Feb 2015 08:55:56 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224135555gw1000ceefe>; Tue, 24 Feb 2015 13:55:56 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54EC82EB.3040705@att.com> Date: Tue, 24 Feb 2015 08:55:55 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=V6DKJ5bi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG] X-AnalysisOut: [9nkA:10 a=KWikpAkKAAAA:8 a=aQeYOMMR6rlqqqAHQZoA:9 a=QEXdDO] X-AnalysisOut: [2ut3YA:10 a=zdbJd93gu_dgrkFV:21 a=MGKYglSutNO77KFl:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: kitten@ietf.org, "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] [kitten] AD sponsoring draft-hansen-scram-sha256 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, 24 Feb 2015 13:56:29 -0000 On 2/18/15 7:57 AM, Sam Whited wrote: > On Mon, Feb 16, 2015 at 6:21 AM, Dave Cridland wrote: >> Worth asking in the XSF, there's likely to be implementation experience from >> the Android client devs there. > I wrote the SCRAM-SHA-1 implementation in Conversations. While I don't > remember actual numbers off the top of my head, I can definitely tell > you that there is a noticable delay with a 4096 iteration count > (probably a little over half a second) on my HTC m7 (which is fairly > beefy as far as phones go). HOWEVER— > >> However, clients need only do the iterations once, if the salt is stable, at >> least in principle. > —since we then store the session information in an LRU Cache in > memory, it's only slow when you first login. I've thought about moving > the session info to the database as well to make it even more > persistant, but decided it wasn't enough of a problem to bother > polluting the database. We have implementations of both SCRAM-SHA-1 and SCRAM-SHA-256 on multiple phone platforms, both Android and iOS. Yes, it can be rather slow. But, as Sam says above, caching does mitigate the issue for subsequent uses. This is why I pushed back when it was suggested before in KITTEN to raise the number higher than 4096. Tony Hansen From nobody Sat Feb 28 09:21:52 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 AEF431A7013; Sat, 28 Feb 2015 09:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLKJFyqh_gIt; Sat, 28 Feb 2015 09:21:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 807711A7007; Sat, 28 Feb 2015 09:21:49 -0800 (PST) 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.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150228172149.20311.92073.idtracker@ietfa.amsl.com> Date: Sat, 28 Feb 2015 09:21:49 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-07.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, 28 Feb 2015 17:21:50 -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 : The 'Basic' HTTP Authentication Scheme Author : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-update-07.txt Pages : 16 Date : 2015-02-28 Abstract: This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-07 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 Sat Feb 28 09:22: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 0EFDC1A7009; Sat, 28 Feb 2015 09:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd1b1lk2S0EJ; Sat, 28 Feb 2015 09:21:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF35B1A7008; Sat, 28 Feb 2015 09:21:49 -0800 (PST) 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.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150228172149.20311.94170.idtracker@ietfa.amsl.com> Date: Sat, 28 Feb 2015 09:21:49 -0800 Archived-At: Subject: [http-auth] New Version Notification - draft-ietf-httpauth-basicauth-update-07.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, 28 Feb 2015 17:21:52 -0000 A new version (-07) has been submitted for draft-ietf-httpauth-basicauth-update: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-basicauth-update-07.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-07 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 Sat Feb 28 09:22:01 2015 Return-Path: X-Original-To: expand-draft-ietf-httpauth-basicauth-update.all@virtual.ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2CA651A7008; Sat, 28 Feb 2015 09:21:52 -0800 (PST) X-Original-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-httpauth-basicauth-update.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFDC1A7009; Sat, 28 Feb 2015 09:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd1b1lk2S0EJ; Sat, 28 Feb 2015 09:21:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF35B1A7008; Sat, 28 Feb 2015 09:21:49 -0800 (PST) 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.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150228172149.20311.94170.idtracker@ietfa.amsl.com> Date: Sat, 28 Feb 2015 09:21:49 -0800 Archived-At: Subject: [http-auth] New Version Notification - draft-ietf-httpauth-basicauth-update-07.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, 28 Feb 2015 17:21:52 -0000 A new version (-07) has been submitted for draft-ietf-httpauth-basicauth-update: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-basicauth-update-07.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-07 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 Sat Feb 28 09:27: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 366CB1A6FDB for ; Sat, 28 Feb 2015 09:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y9YcCzRi__FU for ; Sat, 28 Feb 2015 09:27:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 5F15C1A0364 for ; Sat, 28 Feb 2015 09:27:01 -0800 (PST) Received: from [192.168.2.175] ([93.217.93.228]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Md3li-1YAdij1g2c-00IFQa for ; Sat, 28 Feb 2015 18:26:59 +0100 Message-ID: <54F1FA63.5020505@gmx.de> Date: Sat, 28 Feb 2015 18:26:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <54E75907.8040505@gmx.de> In-Reply-To: <54E75907.8040505@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:owkWVkC6AYxHVLJ9IXeinnKmVCfwZm56m2JBXKwZAw3wRtfbNtf SRbKEOaK6xR69/OD0mykVCbrdgpqyYrH2y2bqbxkd3gC2n5bGAe1hUO2td/lDNwWAldZjca eyuQ3aCF7JYW8MuIE8a55lkXPwwd/KGy4PA1RcmUdDtyEh1I8xXjum0aA5wjNJSFmENBU+v C82Cx9z2x4PWMuuoK24/A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [http-auth] Basic authentication scheme post IETF-LC , secdir, and IESG review updates 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, 28 Feb 2015 17:27:06 -0000 On 2015-02-20 16:55, Julian Reschke wrote: > Hi there, > > I've made a bunch of changes to address IETF-LC, secdif, and IESG > feedback. The draft has not been submitted yet, but all changes are in > the WG's svn repository > (). > > > The changes relative to the IETF LC draft (05) are: > > > > The full text is in > > and > ). > > > Feedback welcome! > > Best regards, Julian I didn't see any feedback, so I went ahead and submitted this as draft -07. Best regards, Julian From nobody Sat Feb 28 09:43:09 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 20EF91A1BF5 for ; Sat, 28 Feb 2015 09:43:09 -0800 (PST) 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 AGwSF59g5aa1 for ; Sat, 28 Feb 2015 09:43:07 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (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 2EAB01A7017 for ; Sat, 28 Feb 2015 09:43:04 -0800 (PST) Received: by wevm14 with SMTP id m14so25911755wev.8 for ; Sat, 28 Feb 2015 09:43:03 -0800 (PST) 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=ijf0Vpml0decNlblqpMpovV47fsDMvFbvB/RA7WLPh4=; b=ycxzYMZM2tD2PIXeP9SEGzJSdBSrMvPhr3uBNUYFq9kjZHc5sQakqJqmGaDLXmpEgS OkyL0TYo3JwBUuwfGPsuGS4ud3ab68shAtv9kkgE7qCg4ufqTH2OGP2BPiDvSg5HRPb0 aY/+VPQpHL2Z4GEcLxM6SRXWDwFi9ZSsL2n8ZKJVgajSq6uygScf7LodrWUAhbg4iDFS 1+O8E4RNRhzSdECtAGlylVkoiPw+aFXxbxoMDY9XsonDWcg94Kc5S9Pm7dagROvaXgVP PDLcxMsGVCd2s2Ih/E4HC7THaTfb5L3nSCXJdA3kbnhK+j9OsP8XuWfUNoh+Xif/6NfB Ne6A== X-Received: by 10.195.12.97 with SMTP id ep1mr41391544wjd.134.1425145383029; Sat, 28 Feb 2015 09:43:03 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id g10sm7876390wic.7.2015.02.28.09.43.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Feb 2015 09:43:02 -0800 (PST) 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: <54F1FA63.5020505@gmx.de> Date: Sat, 28 Feb 2015 19:43:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7CD024DA-1A12-4271-BA90-2FCA650764FC@gmail.com> References: <54E75907.8040505@gmx.de> <54F1FA63.5020505@gmx.de> To: Julian Reschke , Daniel Kahn Gillmor X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Basic authentication scheme post IETF-LC , secdir, and IESG review updates 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, 28 Feb 2015 17:43:09 -0000 Kathleen=E2=80=99s DISCUSS ballot is about the SecDir review. Daniel, are you OK with the changes in version -07? Thanks Yoav > On Feb 28, 2015, at 7:26 PM, Julian Reschke = wrote: >=20 > On 2015-02-20 16:55, Julian Reschke wrote: >> Hi there, >>=20 >> I've made a bunch of changes to address IETF-LC, secdif, and IESG >> feedback. The draft has not been submitted yet, but all changes are = in >> the WG's svn repository >> = (). >>=20 >>=20 >> The changes relative to the IETF LC draft (05) are: >> = >>=20 >>=20 >> The full text is in >> = >> and >> = ). >>=20 >>=20 >> Feedback welcome! >>=20 >> Best regards, Julian >=20 > I didn't see any feedback, so I went ahead and submitted this as draft = -07. >=20 > Best regards, Julian >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth