From nobody Wed Nov 5 06:21:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10401A8915 for ; Wed, 5 Nov 2014 06:21:49 -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 8HesliqcAZbY for ; Wed, 5 Nov 2014 06:21:48 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9E51A891D for ; Wed, 5 Nov 2014 06:21:47 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id pv20so734080lab.39 for ; Wed, 05 Nov 2014 06:21: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=FptPZjA7/NHBEPc8iV8tuCuqhyCeBh1mnT3tBijH2us=; b=iwgYZ5AmnACTMeD+YaZ9xnMzcFUFpV0WC81xrsI1j+e5VwA56qjXeF4JwjgPmYtgSI 64P7FYaB2ZJqRXsaFMkJtYdDYwyRH4tJ5LPWE0861zBsmCxsWHDGgXjqZX2nitj+/zQw 3ZA3pIFvcd2qWwQ+aMMoO7EB187DChuceza39h1O+7O8MTRevhj84gRd2++AvuWZ63iH JhPuHB7ZZKF81QFVpfVjIxRqWQfpuc0BabUw2HLlcH+IFDF0G9kJ0zrbP/3Jy6ZX3vGE WrmIn0wu2LuNG90p+8rsH6Sk2Z4Xu8VLSVk0GGjFd/JpdO9RXIf9l/c64LugaP+LCJ2N LKeg== MIME-Version: 1.0 X-Received: by 10.152.36.33 with SMTP id n1mr1619689laj.6.1415197306124; Wed, 05 Nov 2014 06:21:46 -0800 (PST) Received: by 10.25.217.9 with HTTP; Wed, 5 Nov 2014 06:21:46 -0800 (PST) In-Reply-To: <5447B26C.1080002@isode.com> References: <5447B26C.1080002@isode.com> Date: Wed, 5 Nov 2014 09:21:46 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Alexey Melnikov Content-Type: multipart/alternative; boundary=089e0158b7eab8005605071d4c5b Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/9ahoTjCZMsu4Cufo61kavs_ZI-Y Cc: IETF HTTP Auth Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-digest-08 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:21:50 -0000 --089e0158b7eab8005605071d4c5b Content-Type: text/plain; charset=ISO-8859-1 Hi Alexey, Thanks for the review and for your comments. Sorry, for the late response on this; for some reason I completely missed this email. Please, see my reply inline... Regards, Rifaat On Wed, Oct 22, 2014 at 9:34 AM, Alexey Melnikov wrote: > Hi, > Some notes/comments from reviewing the document. > > The definition of "stale" says: > > The server should only set stale to > TRUE if it receives a request for which the nonce is invalid but > with a valid digest for that nonce (indicating that the client > knows the correct username/password). > > I think this is encouraging DoS on servers. I think it would be better if > the check for staleness is done without computing the hash on the server > side. > The text around that is not normative and uses "should" for the server's operation. Are you suggesting that we remove the "but with a valid digest for that nonce (indicating that the client knows the correct username/password)"? > The notation unq(X) means the value of the quoted-string X without > the surrounding quotes. > > "Without the quotes" or "without the quotes and with quoting slashes > removed"? I.e., what is used for a value "abc\"def"? > Sorry, I am not clear on this. Can you please elaborate on "quoting slashes"? > In 3.4.2 - is the definition of A1 for "MD5-sess" backward compatible with > RFC 2617? > I believe it does; do you see anything to the contrary? > > > Nonce-prime/cnonce-prime - are these limited to the same TCP connection? > I am not sure that I understand the question. Can you please elaborate? > > > Should RFC 5198 (Net Unicode) be recommended for use on top of NFC? For > example, it discourages use of Unicode Control characters. > > Is it Ok to fail authentication if a username is not in NFC? If yes, it > would be good to mention how the server should respond in such case. > My character encoding knowledge is very limited, so I would have to defer to the experts on this one. Regards, Rifaat > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e0158b7eab8005605071d4c5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

Thanks for the review and fo= r your comments.
Sorry, for the late response on this; for some r= eason I completely missed this email.

Please, see = my reply inline...

Regards,
=A0Rifaat


On Wed, Oct 22, 2014 at 9:34 AM, Alexey Melnikov <alexey.melnikov= @isode.com> wrote:
Hi,
Some notes/comments from reviewing the document.

The definition of "stale" says:

=A0 =A0 =A0 The server should only set stale to
=A0 =A0 =A0 TRUE if it receives a request for which the nonce is invalid bu= t
=A0 =A0 =A0 with a valid digest for that nonce (indicating that the client<= br> =A0 =A0 =A0 knows the correct username/password).

I think this is encouraging DoS on servers. I think it would be better if t= he check for staleness is done without computing the hash on the server sid= e.

The text around that is not normativ= e and uses "should" for the server's operation.
Are= you suggesting that we remove the "but=A0with a valid digest for that nonce (ind= icating that the client=A0knows the correct username/password)"?<= /div>



=A0 =A0 =A0 The notation unq(X) means the value of the quoted-string X with= out
=A0 =A0 =A0 the surrounding quotes.

"Without the quotes" or "without the quotes and with quoting= slashes removed"? I.e., what is used for a value "abc\"def&= quot;?

Sorry, I am not clear on this. C= an you please elaborate on "quoting slashes"?
=A0
=


In 3.4.2 - is the definition of A1 for "MD5-sess" backward compat= ible with RFC 2617?

I believe it does; = do you see anything to the contrary?

=A0


Nonce-prime/cnonce-prime - are these limited to the same TCP connection?

I am not sure that I understand the quest= ion. Can you please elaborate?

=A0


Should RFC 5198 (Net Unicode) be recommended for use on top of NFC? For exa= mple, it discourages use of Unicode Control characters.

Is it Ok to fail authentication if a username is not in NFC? If yes, it wou= ld be good to mention how the server should respond in such case.

My character encoding knowledge is very limited,= so I would have to defer to the experts on this one.

<= div>Regards,
=A0Rifaat

=A0

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

--089e0158b7eab8005605071d4c5b-- From nobody Wed Nov 5 07:23:48 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C6D1A892A for ; Wed, 5 Nov 2014 07:23:46 -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 mBxtrhTS-aCu for ; Wed, 5 Nov 2014 07:23:44 -0800 (PST) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529E61A8928 for ; Wed, 5 Nov 2014 07:23:44 -0800 (PST) Received: by mail-qg0-f43.google.com with SMTP id f51so12200916qge.2 for ; Wed, 05 Nov 2014 07:23:43 -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=aXHasyzMUqje2XmyHjl6NpEisaQ2fk8RB6erU16BW60=; b=R4N9hlyakGYZ3jesmqSm8on1/45Cun0GIevYsU07NKKMU140OI+iJ/EyWByVEmeOmR lcQkYkd1JuhGs3SbmoVp8X6lc1mU2rFiBu3ZK3SBDQBAmtO4VUtlxt6m5o00rPs9czlc gqfhDiPU5vN4ZhNrQNkHid9PgbaGRsv37/SDmnJFeHdAUDFZO8I30060zNpfQZjI20V8 mmHGt/u9cqNwkDUVjnrLvyNH/TqLkcQHUnNmwqQeVKWKRXc2iieN+BiFY+44KRWK1Ipt FyERMTu5N3pTg9TOL9CBAEaW/fJdqLC7RmBkwKLpxvdjhrv3ER15eoqmRQQMYJFv1/PF Db0A== X-Gm-Message-State: ALoCoQkoggCoSk7jXZOjvKVwLpTf+Ed9C6vKXl81vnCDOc3a4WRX8D3PFwNX3pIMzEyjlehlupZ6 X-Received: by 10.140.93.195 with SMTP id d61mr80621676qge.28.1415201023582; Wed, 05 Nov 2014 07:23:43 -0800 (PST) From: Brett Tate References: <5447B26C.1080002@isode.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJdORlN0CqTjC1mNzo7yjyJII6XzAD1zlt8my/084A= Date: Wed, 5 Nov 2014 10:23:43 -0500 Message-ID: To: Rifaat Shekh-Yusef , Alexey Melnikov , IETF HTTP Auth Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/KVlWl2ThdGRRukuLvGXHbwP1iro Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-digest-08 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:23:46 -0000 >>> The notation unq(X) means the value of the >>> quoted-string X without the surrounding quotes. >> >> "Without the quotes" or "without the quotes and with quoting >> slashes removed"? I.e., what is used for a value "abc\"def"? > > Sorry, I am not clear on this. Can you please elaborate on > "quoting slashes"? He is attempting to understand how the following RFC 7230 section 3.2.6 snippet impacts the calculation. "The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string and comment constructs. " I assume that calculations are performed with the backslashes removed (if used for single-octet quoting). Thus his example would use (abc"def) within the calculation. If the example was "abc\\def", I assume that "abc\def" would be used within the calculation. Thanks, Brett From nobody Wed Nov 5 10:55:24 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108421A9122 for ; Wed, 5 Nov 2014 10:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] 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 aWpyvEd8JXiO for ; Wed, 5 Nov 2014 10:55:20 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id A57D11ABD3B for ; Wed, 5 Nov 2014 10:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1415213718; d=isode.com; s=selector; i=@isode.com; bh=pGIv7+boemQ57jfQJENntUJhWhrZQa1Aoy587SqedZ0=; 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=rs1WLNZoHAwQi/aiEYojF11lA3tFKY4l1r5AcJkLgU01oD8Jxjj6WyNTSVcOF3DE9EzcIy xnAPEjD1zEN7qiwFtv/MW7igjw/1zbH4m80kFKj+aA2dERk4qbhOPLOgdt3pmorwpM91ht Pmc0Wg/QZFLevxgK7vTqU4Cu2BxWG8I=; 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 ; Wed, 5 Nov 2014 18:55:18 +0000 Message-ID: <545A7288.8070301@isode.com> Date: Wed, 05 Nov 2014 18:55:04 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Rifaat Shekh-Yusef References: <5447B26C.1080002@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000404020201080000050003" Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/AzCj7gvS35WnrjGY-o4JuWvChII Cc: IETF HTTP Auth Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-digest-08 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 18:55:22 -0000 --------------000404020201080000050003 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Rifaat, On 05/11/2014 14:21, Rifaat Shekh-Yusef wrote: > Hi Alexey, > > Thanks for the review and for your comments. > Sorry, for the late response on this; for some reason I completely > missed this email. > > Please, see my reply inline... > > Regards, > Rifaat > > > On Wed, Oct 22, 2014 at 9:34 AM, Alexey Melnikov > > wrote: > > Hi, > Some notes/comments from reviewing the document. > > The definition of "stale" says: > > The server should only set stale to > TRUE if it receives a request for which the nonce is invalid but > with a valid digest for that nonce (indicating that the client > knows the correct username/password). > > I think this is encouraging DoS on servers. I think it would be > better if the check for staleness is done without computing the > hash on the server side. > > > The text around that is not normative and uses "should" for the > server's operation. > Are you suggesting that we remove the "but with a valid digest for > that nonce (indicating that the client knows the correct > username/password)"? Yes. > > > The notation unq(X) means the value of the quoted-string X > without > the surrounding quotes. > > "Without the quotes" or "without the quotes and with quoting > slashes removed"? I.e., what is used for a value "abc\"def"? > > > Sorry, I am not clear on this. Can you please elaborate on "quoting > slashes"? If you have a username with quote or slash character in it, do you add an extra slash to escape ("without the quotes") it or not ("without the quotes and with quoting slashes removed")? I think you want the latter, but the text is not very clear on that. > > > In 3.4.2 - is the definition of A1 for "MD5-sess" backward > compatible with RFC 2617? > > > I believe it does; do you see anything to the contrary? Ok, it looks like. Never mind, I thought I saw some differences. > > > Nonce-prime/cnonce-prime - are these limited to the same TCP > connection? > > > I am not sure that I understand the question. Can you please elaborate? The description says: "It uses the server nonce from that challenge, herin called nonce-prime, and the first client nonce value to construct A1, herin called cnonce-prime as follows:" The first where? On the same TCP connection? When used to authenticate as a particular user (whether on the same connection or not). I found the definition confusing. > > Should RFC 5198 (Net Unicode) be recommended for use on top of > NFC? For example, it discourages use of Unicode Control characters. > > Is it Ok to fail authentication if a username is not in NFC? If > yes, it would be good to mention how the server should respond in > such case. > > > My character encoding knowledge is very limited, so I would have to > defer to the experts on this one. I am not expert enough in this, but I believe the answer to both of these should be "yes". --------------000404020201080000050003 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Hi Rifaat,

On 05/11/2014 14:21, Rifaat Shekh-Yusef wrote:
Hi Alexey,

Thanks for the review and for your comments.
Sorry, for the late response on this; for some reason I completely missed this email.

Please, see my reply inline...

Regards,
=A0Rifaat


On Wed, Oct 22, 2014 at 9:34 AM, Alexey Melnikov <= alexey.melnikov@isode.com> wrote:
Hi,
Some notes/comments from reviewing the document.

The definition of "stale" says:

=A0 =A0 =A0 The server should only set stale to
=A0 =A0 =A0 TRUE if it receives a request for which the nonce = is invalid but
=A0 =A0 =A0 with a valid digest for that nonce (indicating tha= t the client
=A0 =A0 =A0 knows the correct username/password).

I think this is encouraging DoS on servers. I think it would be better if the check for staleness is done without computing the hash on the server side.

The text around that is not normative and uses "should" for the server's operation.
Are you suggesting that we remove the "= but=A0with a valid digest for that nonce (indicating that the client=A0<= span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">knows the correct username/password)"?
Yes.


=A0 =A0 =A0 The notation unq(X) means the value of the quoted-string X without
=A0 =A0 =A0 the surrounding quotes.

"Without the quotes" or "without the quotes and with quoting slashes removed"? I.e., what is used for a value "abc\"def"?

Sorry, I am not clear on this. Can you please elaborate on "quoting slashes"?
If you have a username with quote or slash character in it, do you add an extra slash to escape ("without the quotes") it or not ("without the quotes and with quoting slashes removed")? I think you want the latter, but the text is not very clear on that.

In 3.4.2 - is the definition of A1 for "MD5-sess" backward compatible with RFC 2617?

I believe it does; do you see anything to the contrary?
Ok, it looks like. Never mind, I thought I saw some differences.
=A0

Nonce-prime/cnonce-prime - are these limited to the same TCP connection?

I am not sure that I understand the question. Can you please elaborate?
The description says:

"It uses the server nonce from that challenge, herin called nonce-prime, and the first client nonce value to construct A1, herin called cnonce-prime as follows:"

The first where? On the same TCP connection? When used to authenticate as a particular user (whether on the same connection or not). I found the definition confusing.
=A0
Should RFC 5198 (Net Unicode) be recommended for use on top of NFC? For example, it discourages use of Unicode Control characters.

Is it Ok to fail authentication if a username is not in NFC? If yes, it would be good to mention how the server should respond in such case.

My character encoding knowledge is very limited, so I would have to defer to the experts on this one.
I am not expert enough in this, but I believe the answer to both of these should be "yes".

--------------000404020201080000050003-- From nobody Wed Nov 5 12:44:25 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1C71ACD39 for ; Wed, 5 Nov 2014 12:44:22 -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 vITkxNpQfkOE for ; Wed, 5 Nov 2014 12:44:19 -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 225851A896B for ; Wed, 5 Nov 2014 12:44:19 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id q1so1450172lam.10 for ; Wed, 05 Nov 2014 12:44: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; bh=ZbVjTG0ms83vxWieFgBqMv5cxAKu5HzXoBqBSnLN7NI=; b=xZ4NRFsamnb++N5IoOTVt2WJO6Hk/st7/LAzrAtfcfqnOHEYBQ5Ecr32jIsqlBt+MN PKd8y011hs04+7EXMoMN46kO78zOYMY27U0qvNeLxlWK0PTWq2Z6fCzLdUxPgC532SmS gMWwD6jqWivFiqxPS06nVASNzWvsacDDYbppNBJluk3MUoyYYetrjT6NRMojBABPBOAA OQNl08H+CAYrQYAOMA0rRyunzngwLmc2z4pE+EAtkOBS091uHa8uqtlefCBcXjLsX6H1 JXku9x5FEmgayPvYQQfmA7GfP7y9LAxdTvaUKDh1NbjH3VeTEwajnFEhoUqIvxw/xbHl t5wQ== MIME-Version: 1.0 X-Received: by 10.112.148.161 with SMTP id tt1mr71961270lbb.67.1415220257574; Wed, 05 Nov 2014 12:44:17 -0800 (PST) Received: by 10.25.217.9 with HTTP; Wed, 5 Nov 2014 12:44:17 -0800 (PST) In-Reply-To: <545A7288.8070301@isode.com> References: <5447B26C.1080002@isode.com> <545A7288.8070301@isode.com> Date: Wed, 5 Nov 2014 15:44:17 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Alexey Melnikov Content-Type: multipart/alternative; boundary=047d7b3a829abb571f050722a44e Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/pukEArALcnmduFpIiEneTUueBD8 Cc: IETF HTTP Auth Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-digest-08 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 20:44:22 -0000 --047d7b3a829abb571f050722a44e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 5, 2014 at 1:55 PM, Alexey Melnikov wrote: > Hi Rifaat, > > On 05/11/2014 14:21, Rifaat Shekh-Yusef wrote: > > Hi Alexey, > > Thanks for the review and for your comments. > Sorry, for the late response on this; for some reason I completely missed > this email. > > Please, see my reply inline... > > Regards, > Rifaat > > > On Wed, Oct 22, 2014 at 9:34 AM, Alexey Melnikov < > alexey.melnikov@isode.com> wrote: > >> Hi, >> Some notes/comments from reviewing the document. >> >> The definition of "stale" says: >> >> The server should only set stale to >> TRUE if it receives a request for which the nonce is invalid but >> with a valid digest for that nonce (indicating that the client >> knows the correct username/password). >> >> I think this is encouraging DoS on servers. I think it would be better if >> the check for staleness is done without computing the hash on the server >> side. >> > > The text around that is not normative and uses "should" for the server's > operation. > Are you suggesting that we remove the "but with a valid digest for that > nonce (indicating that the client knows the correct username/password)"? > > Yes. > I am ok with this. Any objection to this change? > > > >> The notation unq(X) means the value of the quoted-string X without >> the surrounding quotes. >> >> "Without the quotes" or "without the quotes and with quoting slashes >> removed"? I.e., what is used for a value "abc\"def"? >> > > Sorry, I am not clear on this. Can you please elaborate on "quoting > slashes"? > > If you have a username with quote or slash character in it, do you add an > extra slash to escape ("without the quotes") it or not ("without the quotes > and with quoting slashes removed")? I think you want the latter, but the > text is not very clear on that. > Ok. I will clarify that. > > >> In 3.4.2 - is the definition of A1 for "MD5-sess" backward compatible >> with RFC 2617? >> > > I believe it does; do you see anything to the contrary? > > Ok, it looks like. Never mind, I thought I saw some differences. > > > >> >> Nonce-prime/cnonce-prime - are these limited to the same TCP connection? >> > > I am not sure that I understand the question. Can you please elaborate? > > The description says: > > "It uses the server nonce from that challenge, herin called nonce-prime, > and the first client nonce value to construct A1, herin called cnonce-prime > as follows:" > > The first where? On the same TCP connection? When used to authenticate as > a particular user (whether on the same connection or not). I found the > definition confusing. > Yes, on the same TCP connection used by the first request and the following challenge and response for a particular user. The nonce-prime and cnonce-prime were introduced in one of the previous versions of this document to try to clarify this A1 calculation. I thought the original text was clear enough, but I guess it was not clear enough for everybody. We have few options here: 1. Revert back to the original text, without the nonce-prime/cnonce-prime 2. Keep the nonce-prime/cnonce-prime, but reword the current text. 3. Suggest new text Do you have a preference? > > > >> Should RFC 5198 (Net Unicode) be recommended for use on top of NFC? For >> example, it discourages use of Unicode Control characters. >> >> Is it Ok to fail authentication if a username is not in NFC? If yes, it >> would be good to mention how the server should respond in such case. >> > > My character encoding knowledge is very limited, so I would have to > defer to the experts on this one. > > I am not expert enough in this, but I believe the answer to both of these > should be "yes". > Ok. Let's discuss this next week in Honolulu. Regards, Rifaat --047d7b3a829abb571f050722a44e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Nov 5, 2014 at 1:55 PM, Alexey Melnikov <alexey.melnikov@i= sode.com> wrote:
=20 =20 =20
Hi Rifaat,

On 05/11/2014 14:21, Rifaat Shekh-Yusef wrote:
Hi Alexey,

Thanks for the review and for your comments.
Sorry, for the late response on this; for some reason I completely missed this email.

Please, see my reply inline...

Regards,
=A0Rifaat


On Wed, Oct 22, 2014 at 9:34 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
Hi,
Some notes/comments from reviewing the document.

The definition of "stale" says:

=A0 =A0 =A0 The server should only set stale to
=A0 =A0 =A0 TRUE if it receives a request for which the nonce= is invalid but
=A0 =A0 =A0 with a valid digest for that nonce (indicating th= at the client
=A0 =A0 =A0 knows the correct username/password).

I think this is encouraging DoS on servers. I think it would be better if the check for staleness is done without computing the hash on the server side.

The text around that is not normative and uses "shoul= d" for the server's operation.
Are you suggesting that we remove the "but=A0with a valid digest for that nonce (indicating that the client=A0= knows the correct username/password)"?
 Yes.

I am ok with this. Any objec= tion to this change?

=A0



=A0 =A0 =A0 The notation unq(X) means the value of the quoted-string X without
=A0 =A0 =A0 the surrounding quotes.

"Without the quotes" or "without the quotes an= d with quoting slashes removed"? I.e., what is used for a value "abc\"def"?

Sorry, I am not clear on this. Can you please elaborate on "quoting slashes"?
 If you have a username with quote or slash character in it, do you add an extra slash to escape ("without the quotes") it or not ("without the quotes and with quoting slashes removed")? I th= ink you want the latter, but the text is not very clear on that.

Ok. I will clarify that.

= =A0


In 3.4.2 - is the definition of A1 for "MD5-sess" b= ackward compatible with RFC 2617?

I believe it does; do you see anything to the contrary?
Ok, it looks like. Never mind, I thought I saw some differences.<= br>
=A0

Nonce-prime/cnonce-prime - are these limited to the same TCP connection?

I am not sure that I understand the question. Can you please elaborate?
 The description says:

"It uses the server nonce from that challenge, herin called nonce-prime, and the first client nonce value to construct A1, herin called cnonce-prime as follows:"

The first where? On the same TCP connection? When used to authenticate as a particular user (whether on the same connection or not). I found the definition confusing.

Yes, on the same TCP connection used by the first request and the fo= llowing challenge and response for a particular user.

<= div>The nonce-prime and cnonce-prime were introduced in one of the previous= versions of this document to try to clarify this A1 calculation.
I thought the original text was clear enough, but I guess it was not clear= enough for everybody.

We have few options here:
1. Revert back to the original text, without the nonce-prime/c= nonce-prime
2. Keep the nonce-prime/cnonce-prime, but reword the = current text.
3. Suggest new text

Do you= have a preference?

=A0

=A0
Should RFC 5198 (Net Unicode) be recommended for use on top of NFC? For example, it discourages use of Unicode Control characters.

Is it Ok to fail authentication if a username is not in NFC? If yes, it would be good to mention how the server should respond in such case.

My character encoding knowledge is very limited, so I would have to defer to the experts on this one.
 I am not expert enough in this, but I believe the answer to both of these should be "yes".

<= div>Ok. Let's discuss this next week in Honolulu.=A0


Regards,
=A0Rifaat


--047d7b3a829abb571f050722a44e-- From nobody Fri Nov 7 11:14:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689281A01F2 for ; Fri, 7 Nov 2014 11:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RoVZhDpMzApC for ; Fri, 7 Nov 2014 11:14:48 -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 4FDF91A01FA for ; Fri, 7 Nov 2014 11:14:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx02.posteo.de (Postfix) with ESMTP id 359B425B17CA; Fri, 7 Nov 2014 20:14:43 +0100 (CET) X-Virus-Scanned: amavisd-new at posteo.de Received: from posteo.de ([10.125.125.178]) (using TLS) by localhost (amavis1.posteo.de [10.125.125.165]) (amavisd-new, port 10026) with ESMTPS id xkWRwJONFC-y; Fri, 7 Nov 2014 20:14:31 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by mail.posteo.de (Postfix) with ESMTPSA id A40DE2C010D; Fri, 7 Nov 2014 20:14:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Sophie Bremer In-Reply-To: Date: Fri, 7 Nov 2014 20:14:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <78357702-0176-4A19-A82C-DDA839995351@netzkonform.de> References: <5447B26C.1080002@isode.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/n1-vlEPSTz_1zinsJEEKUIUMFsE Cc: IETF HTTP Auth Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-digest-08 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 19:14:50 -0000 Hello, > Should RFC 5198 (Net Unicode) be recommended for use on top of NFC? = For example, it discourages use of Unicode Control characters. >=20 > Is it Ok to fail authentication if a username is not in NFC? If yes, = it would be good to mention how the server should respond in such case. In my opinion it should be recommend, but fail should not be a = requirement. If the server does not accept banished characters, the = response should be HTTP status code 401. The problem lies in hashed user names. In this case the server does not = know automatically, if characters are Net Unicode. So for the sake of = compatibility and interoperability it may be ignored. Also RFC 5198 (3) says "... except in very unusual circumstances, all = Net-Unicode strings be transmitted in normalized form. Recognition of = the fact that some implementations of applications may rely on operating = system libraries over which they have little control and adherence to = the robustness principle suggests that receivers of such strings should = be prepared to receive unnormalized ones and to not react to that in = excessive ways." Regards, Sophie= From nobody Mon Nov 10 15:00:02 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CD71ACF8B; Mon, 10 Nov 2014 14:59:57 -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 GY0JYIXzLD7f; Mon, 10 Nov 2014 14:59:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB561ACF92; Mon, 10 Nov 2014 14:59:49 -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.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141110225949.28761.60179.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 14:59:49 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/v1pUFMPCeAzdpar9wdNkB6-HOEA Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-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: Mon, 10 Nov 2014 22:59:57 -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 : Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Author : Alexey Melnikov Filename : draft-ietf-httpauth-scram-auth-04.txt Pages : 21 Date : 2014-11-10 Abstract: The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the HTTP Digest challenge response mechanism presently on the standards track failed widespread deployment, and have had success only in limited use. This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for application protocol authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-scram-auth-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 Wed Nov 12 16:29:39 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B702A1A01C6; Wed, 12 Nov 2014 16:29:30 -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 UglDg-VX3fOB; Wed, 12 Nov 2014 16:29:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6311A0154; Wed, 12 Nov 2014 16:29:28 -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.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113002928.3210.71287.idtracker@ietfa.amsl.com> Date: Wed, 12 Nov 2014 16:29:28 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/4ILdi1JGyVx-se7ptSXnyGI4JSs Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-melnikov-httpbis-scram-auth-01.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, 13 Nov 2014 00:29:31 -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 : Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Author : Alexey Melnikov Filename : draft-melnikov-httpbis-scram-auth-01.txt Pages : 17 Date : 2014-11-12 Abstract: The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the HTTP Digest challenge response mechanism presently on the standards track failed widespread deployment, and have had success only in limited use. This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses security concerns with HTTP Digest and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for HTTP authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-melnikov-httpbis-scram-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-melnikov-httpbis-scram-auth-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-melnikov-httpbis-scram-auth-01 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 Nov 12 16:44:13 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA871A0163 for ; Wed, 12 Nov 2014 16:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] 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 oThGFnjO6yOc for ; Wed, 12 Nov 2014 16:44:05 -0800 (PST) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F93A1A0151 for ; Wed, 12 Nov 2014 16:44:05 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id sAD0i2eU006087 for ; Wed, 12 Nov 2014 16:44:04 -0800 Received: from vpn-135-70-97-201.vpn.swst.att.com ([135.70.97.201]) by maillennium.att.com (mailgw1) with ESMTP id <20141113004401gw100r93h9e>; Thu, 13 Nov 2014 00:44:02 +0000 X-Originating-IP: [135.70.97.201] Message-ID: <5463FECD.9070302@att.com> Date: Wed, 12 Nov 2014 19:43:57 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: http-auth@ietf.org References: <20141113002928.3210.71287.idtracker@ietfa.amsl.com> In-Reply-To: <20141113002928.3210.71287.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060507070203020602030706" Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/fQPo2yVuQpT3XBCYvPn6J9oKQ3A Subject: Re: [http-auth] I-D Action: draft-melnikov-httpbis-scram-auth-01.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: Thu, 13 Nov 2014 00:44:09 -0000 This is a multi-part message in MIME format. --------------060507070203020602030706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/12/14, 7:29 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. > > Title : Salted Challenge Response (SCRAM) HTTP Authentication Mechanism > Author : Alexey Melnikov > Filename : draft-melnikov-httpbis-scram-auth-01.txt Hey Alexey, glad to see the updated draft. I took a quick look and like where things are going. I have one comment I wanted to get out quickly. In the examples, you have things like data=base64(n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL) I think this would be much better written as data=biwsbj11c2VyLHI9ZnlrbytkMmxiYkZnT05Sdjlxa3hkYXdMCgo= and then put in a comment saying that the data string decodes as "n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL". (The above pattern recurs multiple times.) I'm afraid of naive implementers who would literally create headers that say "data=base64(....)" instead of realizing that they should base64 the data and use the results within the headers. (But but but, "I was just copying the example." :-( ) Tony Hansen --------------060507070203020602030706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/12/14, 7:29 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

        Title           : Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
        Author          : Alexey Melnikov
	Filename        : draft-melnikov-httpbis-scram-auth-01.txt

Hey Alexey, glad to see the updated draft. I took a quick look and like where things are going. I have one comment I wanted to get out quickly.

In the examples, you have things like

    data=base64(n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL)

I think this would be much better written as

    data=biwsbj11c2VyLHI9ZnlrbytkMmxiYkZnT05Sdjlxa3hkYXdMCgo=

and then put in a comment saying that the data string decodes as "n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL".

(The above pattern recurs multiple times.)

I'm afraid of naive implementers who would literally create headers that say "data=base64(....)" instead of realizing that they should base64 the data and use the results within the headers. (But but but, "I was just copying the example." :-( )

    Tony Hansen
--------------060507070203020602030706-- From nobody Wed Nov 12 16:46:26 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700E91A00FA for ; Wed, 12 Nov 2014 16:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594] 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 z20fZx7lYmAP for ; Wed, 12 Nov 2014 16:46:21 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 63A341A01E1 for ; Wed, 12 Nov 2014 16:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1415839576; d=isode.com; s=selector; i=@isode.com; bh=EaZSD/x7JH5cwWsHGoHTjjyUSYzbEeBzVCADLdcJ4OM=; 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=rlg/BSL1T2MShW2thUEVm4/IbHPjFKSwJmn1xlJ8YdaDjHSItDAauidj1tpS32Twr+gBym /SFiyrTpUO40gs7QH+DnRQghTrTlrCnws+IstASs2zLu47telZiCR0PtojAkQuqllUmt+b yDoNoxmC20FSHEOU2KExbWkpEuS79Fw=; Received: from [31.133.164.168] (dhcp-a4a8.meeting.ietf.org [31.133.164.168]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 13 Nov 2014 00:46:15 +0000 Message-ID: <5463FF59.6010409@isode.com> Date: Thu, 13 Nov 2014 00:46:17 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: IETF HTTP Auth MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/B8ccvfd9R8rtLQ5c38i2lVRgVI4 Subject: [http-auth] SCRAM 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: Thu, 13 Nov 2014 00:46:24 -0000 Hi, I submitted draft-ietf-httpauth-scram-auth-04 and draft-melnikov-httpbis-scram-auth-01. They are largely identical, the main difference between the two is that the latter is encapsulating SCRAM messages from RFC 5802 inside base64-encoded attribute called "data" (and is referencing RFC 5802 for SCRAM attribute definition), while the former is still trying to make each SCRAM attribute to be a proper HTTP SCRAM attribute. The advantage of the latter approach is that SCRAM implementations written for use in other application protocols can be used as-is in HTTP. Let me know which version you prefer and I will post WG's -05 based on it. Best Regards, Alexey From nobody Wed Nov 12 19:29:10 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DE01A1B36 for ; Wed, 12 Nov 2014 19:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] 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 ut4DNPL5Evv5 for ; Wed, 12 Nov 2014 19:29:05 -0800 (PST) Received: from egssmtp01.att.com (egssmtp01.att.com [144.160.112.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F531A1B02 for ; Wed, 12 Nov 2014 19:29:05 -0800 (PST) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id sAD3T3m2000366 for ; Wed, 12 Nov 2014 21:29:04 -0600 Received: from vpn-135-70-97-201.vpn.swst.att.com ([135.70.97.201]) by maillennium.att.com (mailgw1) with ESMTP id <20141113032903gw100r93hee>; Thu, 13 Nov 2014 03:29:03 +0000 X-Originating-IP: [135.70.97.201] Message-ID: <5464257A.6000201@att.com> Date: Wed, 12 Nov 2014 22:28:58 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF HTTP Auth References: <5463FF59.6010409@isode.com> In-Reply-To: <5463FF59.6010409@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/MgTdsw9GF22cRpu0xSmq08yvZTE Subject: Re: [http-auth] SCRAM 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: Thu, 13 Nov 2014 03:29:09 -0000 On 11/12/14, 7:46 PM, Alexey Melnikov wrote: > Hi, > I submitted draft-ietf-httpauth-scram-auth-04 and > draft-melnikov-httpbis-scram-auth-01. They are largely identical, the > main difference between the two is that the latter is encapsulating > SCRAM messages from RFC 5802 inside base64-encoded attribute called > "data" (and is referencing RFC 5802 for SCRAM attribute definition), > while the former is still trying to make each SCRAM attribute to be a > proper HTTP SCRAM attribute. The advantage of the latter approach is > that SCRAM implementations written for use in other application > protocols can be used as-is in HTTP. > > Let me know which version you prefer and I will post WG's -05 based on > it. I prefer the base64-encoded encapsulation, as in draft-melnikov-httpbis-scram-auth-01. I think that being able to reuse existing SCRAM libraries is important to interoperability. Tony Hansen From nobody Fri Nov 14 17:59:09 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6691A014C for ; Fri, 14 Nov 2014 17:59:07 -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 xPU-9P-qEe41 for ; Fri, 14 Nov 2014 17:59:06 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D111A00D7 for ; Fri, 14 Nov 2014 17:59:05 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so1076485wiw.7 for ; Fri, 14 Nov 2014 17:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=0iIIGdD/Tf9a5XC/fVBrxBFlchWcLu+/fwnqc/Oy5oI=; b=jnsWsi5rEKNK3UlWvtjUTzV/YU9FVw+rcIMa/UBAQQw/Qk6cKrVixPRr4BHmWZ2rsH fOwbbSo6vUtTRUJtsh8u2MUtAw1Mwx1czIJBKWokYLV/Mvq9cksoupphuezdxGIDIxnL V9SwmQ70n3oZ67aUv7QZIAvqoJI1kJpaBYTZjG27AsAvl1A48mUdxkJTNXMtKSqvkYxZ 44PTjahBL50A2BIVKMgjpzSIQlLXSU4IaUFuV1WzowuGVHZVnsKnSm96qs9AiwXx5yXk X28RvGeDdeZxm/+sPrO4ib5TyH2ow9rAb5ClB4G7NNKNeGPopTsJl3R2SzbA8OMCayIa kxMQ== X-Received: by 10.180.84.167 with SMTP id a7mr12338572wiz.39.1416016744532; Fri, 14 Nov 2014 17:59:04 -0800 (PST) Received: from dhcp-a75f.meeting.ietf.org (dhcp-a75f.meeting.ietf.org. [31.133.167.95]) by mx.google.com with ESMTPSA id y5sm5432493wix.9.2014.11.14.17.59.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 17:59:03 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 14 Nov 2014 15:59:00 -1000 To: IETF HTTP Auth Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/HgKtXTOxRZasl9-IIsPFvz8SKBE Subject: [http-auth] Allowed Characters in usernames and passwords 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, 15 Nov 2014 01:59:07 -0000 Hi An issue that has been discussed on the list has been what characters = are allowed for usernames and passwords in the Basic and Digest = documents (this probably also applies to other specification, = specifically MutualAuth, but that is not the issue in this message). So the precis working group is creating the saslprepbis ([1]) document = that should be published soon (as soon as the end of this year). That = contains a profile for characters that are and aren=E2=80=99t = recommended for use in username and passwords. So the proposal that reflects the consensus of the people in today=E2=80=99= s session is as follows: Both the Basic and Digest drafts will mandate that supporting servers = MUST support usernames and passwords that conform to the saslprepbis = specification, and MAY support non-conforming ones. The rationale is = that we have to have a MAY there, because we can=E2=80=99t prohibit = stuff that works today. Both documents will add text with these MUST and = MAY. The room was unanimous in supporting this direction. If you disagree, = please comment to the list by Monday 24-Nov-2014. Since we had a strong = hum for in the room, we will take silence as consensus Thanks Matt & Yoav [1] https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-09= From nobody Fri Nov 14 18:01:19 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3171A01E5 for ; Fri, 14 Nov 2014 18:01:17 -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 dHsw06UWO8Z8 for ; Fri, 14 Nov 2014 18:01:16 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372E51A014C for ; Fri, 14 Nov 2014 18:01:16 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so1083009wib.5 for ; Fri, 14 Nov 2014 18:01:15 -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=AzyuNVPvjJwlhai7U4I2buUQ1j2UKv8kn7rVq6tkS+8=; b=O/Mi1VWI+roLcHYP/IvyIdh020wlfL2Q0O4208SRiQlAPsd7UjbwadEdZncoheADiM v2psd3xtVOAnjq9zIEoOkSTbb0V6mhx/4jFRSemfxEehfLUhULruxXypxCJeLDe8yZHC H8ZUnw3ypYLNXJpxkVQAA/vkzHUmVBLrtOnbAaHkPhhHHdUsVuquqzePmA059CDB4sKQ rH3mgw9Ne3isfrbSGAWOFsn+rBXlsrYZ7wAsj1ve9VB08mL4zjffcjxPIe5TKl27imQk tca+TZdlC9nDOoTj/cFqz3L2tLcM2RG6yAZnCVCMvDA5fgz0c5J1BrUVY00uudf6MEs5 2Vpg== X-Received: by 10.194.81.6 with SMTP id v6mr18682435wjx.39.1416016875025; Fri, 14 Nov 2014 18:01:15 -0800 (PST) Received: from t2001067c03700160bc7d047157ae7dc4.wireless.v6.meeting.ietf.org (t2001067c03700160bc7d047157ae7dc4.wireless.v6.meeting.ietf.org. [2001:67c:370:160:bc7d:471:57ae:7dc4]) by mx.google.com with ESMTPSA id q10sm41647184wjq.35.2014.11.14.18.01.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 18:01:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: Date: Fri, 14 Nov 2014 16:01:10 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> References: To: IETF HTTP Auth X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Lx8nxsU4o9CsBxqDv438HLSaBc0 Subject: Re: [http-auth] Allowed Characters in usernames and passwords 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, 15 Nov 2014 02:01:18 -0000 So of course I forgot something. Additionally, the Basic and Digest documents will refer to the precis = document, and not specify acceptable characters themselves, except where = there is a unique requirement, such as the requirements around colons in = usernames or passwords in Basic. In all other cases, saslprepbis will be = our normative reference. Yoav > On Nov 14, 2014, at 3:59 PM, Yoav Nir wrote: >=20 > Hi >=20 > An issue that has been discussed on the list has been what characters = are allowed for usernames and passwords in the Basic and Digest = documents (this probably also applies to other specification, = specifically MutualAuth, but that is not the issue in this message). >=20 > So the precis working group is creating the saslprepbis ([1]) document = that should be published soon (as soon as the end of this year). That = contains a profile for characters that are and aren=E2=80=99t = recommended for use in username and passwords. >=20 > So the proposal that reflects the consensus of the people in today=E2=80= =99s session is as follows: >=20 > Both the Basic and Digest drafts will mandate that supporting servers = MUST support usernames and passwords that conform to the saslprepbis = specification, and MAY support non-conforming ones. The rationale is = that we have to have a MAY there, because we can=E2=80=99t prohibit = stuff that works today. Both documents will add text with these MUST and = MAY. >=20 > The room was unanimous in supporting this direction. If you disagree, = please comment to the list by Monday 24-Nov-2014. Since we had a strong = hum for in the room, we will take silence as consensus >=20 > Thanks >=20 > Matt & Yoav >=20 > [1] https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-09 From nobody Fri Nov 14 18:04:25 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5461A01E5 for ; Fri, 14 Nov 2014 18:04:23 -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 A1WTZCwblHwR for ; Fri, 14 Nov 2014 18:04:21 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3131A00AD for ; Fri, 14 Nov 2014 18:04:21 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id y10so21040973wgg.2 for ; Fri, 14 Nov 2014 18:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=AaBVLxJPNGEvU+6nADUjw/qMgeli1uWMZNrG23eA9tw=; b=SgqZOXVi/Ia7+XMlDOPy+L4K07quvoIuYbPQwGYEpzcwAQ8l6AUIlmhc4B2eQViNQG ZGnmVg3tmVkLrPE5ZjVa2t9yhFXr1mS388LXE6HSUK08Euoq8ejon0PtF5+UAeh5BiSc CNnqCcOZEcfsB9wm/5KHRiKheBIukVhCO5Qi7C+tYUZ+Wlg3Lti3bmApFKr+mhDDTw3F EhhwBzAtVg+BBwJ1NdYfbdn6FunS8MyG1c5uNpeu4jFeEN7zsEEWXLo/kc6hAVazK4up 6LXd7dLFUfwYkl4YU+JwQu16Z2twAOBtujDfEvEcUBMf/lrt/fcsRzriFBasr6pZe4Rz TCTw== X-Received: by 10.180.98.169 with SMTP id ej9mr12474859wib.1.1416017060069; Fri, 14 Nov 2014 18:04:20 -0800 (PST) Received: from dhcp-a75f.meeting.ietf.org (dhcp-a75f.meeting.ietf.org. [31.133.167.95]) by mx.google.com with ESMTPSA id dm10sm5418961wib.18.2014.11.14.18.04.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 18:04:19 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 14 Nov 2014 16:04:15 -1000 To: IETF HTTP Auth Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/_wxDhvaBHoCfA1g3jaDeSUJbzuo Subject: [http-auth] Consensus call about normalization 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, 15 Nov 2014 02:04:23 -0000 Hi There was a discussion in the room about normalization. Here=E2=80=99s a proposal. Please respond to the list if it=E2=80=99s = acceptable: Clients MUST normalize input (both userid and passwords) to NFC Server MAY normalize with old clients (clients that don=E2=80=99t send = the charset attribute) Question to the group: what should a server do with a non-normalized = userid/password, where the client is new (i.e. sends =E2=80=9Ccharset=E2=80= =9D) - this is a broken client. Please respond to the list within the next two weeks. Thanks Matt & Yoav From nobody Fri Nov 14 20:26:01 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22011A1A2C for ; Fri, 14 Nov 2014 20:25:58 -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 Rv5-LU-Ia488 for ; Fri, 14 Nov 2014 20:25:56 -0800 (PST) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E231A0AF1 for ; Fri, 14 Nov 2014 20:25:56 -0800 (PST) Received: from mail-vc0-f174.google.com ([209.85.220.174]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKVGbV04HLUsMlDW8ZdFh8fTEUC7Zq7xaF@postini.com; Fri, 14 Nov 2014 20:25:56 PST Received: by mail-vc0-f174.google.com with SMTP id la4so5594899vcb.5 for ; Fri, 14 Nov 2014 20:25:55 -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:content-transfer-encoding; bh=wPJS4yYnRmskYvMcuIU1CZPvaHNs2CyHVKF+kPPaMQQ=; b=wXwHyerzSxNJS9nLDPcHIrQGENBLodOJ3LlnhP4bNOo8z4l6z4fgbFgakhbO7mHA+1 1YbVaLGeQbsRvQ1SfUkXnqbuP84fVSl955sP7NXGwKzMppP1sTJ/v8hg4nlE8d/iIUuI JIT3wV60zFCGvN5eMPJzKn8Sq5/Gg0qMzjY5I= 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=wPJS4yYnRmskYvMcuIU1CZPvaHNs2CyHVKF+kPPaMQQ=; b=G/VxVeZlT2yILUovUEOIGRq2MGsM3mRzpw6scbeG/itT/8UouTemBiDBUUBa8wkBPf LLDSnEotTlIzx0+L5okKRHqnhALym8PE4Mh1UX+ZsXthJU0Rrh7q5VVaOUwHyYhirCLJ 4NdIyLtw2zqlX3gP2l8y4exTDWbE2ahiBEjPs0sKUT3LuXSzvG1kkr11tOnhBJpyipaj JZrSNyowjGUaO8WMg70Azqjm+6wPcIA0H85IW3FZV/qD7/F6kWqFNu7GQ5jhtgT+7Qah idgPwbjYzWT/YlRRVtXf6zyHSLdSZtZUqAbYODwJGlKf3NKn/zjDOEk7OfG+2hI1XR3Q jtew== X-Gm-Message-State: ALoCoQlMzwC9Ks66ZomaOIP9ayjS6qsFnObjYw0iM6idIkOVvR4AsjaMlbfTO4W8J6+TaS+ZZJBYr7Ar9jJBs9wbBuOaWuaLhqJjGUoa+OzUXDjD2NXW0ymS/vguQeP/YbE85uIynK+sdjTgT77+CIjioWAa/E6GYQ== X-Received: by 10.52.117.51 with SMTP id kb19mr8314134vdb.24.1416025555161; Fri, 14 Nov 2014 20:25:55 -0800 (PST) X-Received: by 10.52.117.51 with SMTP id kb19mr8314131vdb.24.1416025555098; Fri, 14 Nov 2014 20:25:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.134.70 with HTTP; Fri, 14 Nov 2014 20:25:34 -0800 (PST) In-Reply-To: References: From: Yutaka OIWA Date: Sat, 15 Nov 2014 13:25:34 +0900 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/gdCusmMr0G8Zhv7UzY4LzycljnE Cc: IETF HTTP Auth Subject: Re: [http-auth] Consensus call about normalization 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, 15 Nov 2014 04:25:59 -0000 > Server MAY normalize with old clients (clients that don=E2=80=99t send th= e charset attribute) For Basic, yes +1. For other schema, I prefer dropping it or append something like "if applicable/possible/reasonable". I personally don't like specs to say "you MAY do what you can't actually do" unless it was an April-fool RFC. > Question to the group: what should a server do with a non-normalized user= id/password, where the client is new (i.e. sends =E2=80=9Ccharset=E2=80=9D)= - this is a broken client. Servers MAY do almost whatever they want: 1) it MAY reject the clients as an invalid attempt, or 2) it MAY normalize the input (only when plaintext username and passwords are available, like Basic), or 3) it MAY process it without normalization. (Verbosely written: the text can be simpler than this.) The rationale is that the specification should not require servers to understand complex Unicode NFC rules (both checking and processing), i.e. it should not require servers to reject such an input. Also note that Digest with userhash option can do nothing but processing it as-is, even when charset is specified. The clause 2) can be dropped, but I personally think that we have no reason to disallow this, if we allow it for legacy inputs. --=20 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= ] 2014-11-15 11:04 GMT+09:00 Yoav Nir : > Hi > > There was a discussion in the room about normalization. > > Here=E2=80=99s a proposal. Please respond to the list if it=E2=80=99s acc= eptable: > > Clients MUST normalize input (both userid and passwords) to NFC > > Server MAY normalize with old clients (clients that don=E2=80=99t send th= e charset attribute) > > Question to the group: what should a server do with a non-normalized user= id/password, where the client is new (i.e. sends =E2=80=9Ccharset=E2=80=9D)= - this is a broken client. > > Please respond to the list within the next two weeks. > > Thanks > > Matt & Yoav > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Sat Nov 15 11:54:55 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E581A1BC3 for ; Sat, 15 Nov 2014 11:54:53 -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 Vg1OiD4ibbat for ; Sat, 15 Nov 2014 11:54:51 -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 7B1791A1B9B for ; Sat, 15 Nov 2014 11:54:51 -0800 (PST) Received: from [10.140.204.47] ([88.128.80.47]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Ld0E0-1YFxRh0tqi-00iFZQ; Sat, 15 Nov 2014 20:54:49 +0100 Message-ID: <5467AF81.8070109@gmx.de> Date: Sat, 15 Nov 2014 20:54:41 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Yoav Nir , IETF HTTP Auth References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:jZIGfsBkEaqgWxFcJIVJMMaPd33rES+N2xUFOHx09K8BkjZeiqE gk83WQeK73vMEyNbCmfV61Qoohqto+/bgxaOYn6RFBiGea0JUmJRqelrbiEcV+8vm4XFVY/ 6DeLda4vVkAW1FDoLCnK1msrVoxkbntFhQJej+lvZe6+8T8UkgIDH8ZtKIzKgu9JIwuA3uW nVkiLQwC5DOqG9SNuoVcQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/6qmuXA6ETnh21wbWi-Pe_tvE53o Subject: Re: [http-auth] Consensus call about normalization 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, 15 Nov 2014 19:54:53 -0000 On 2014-11-15 03:04, Yoav Nir wrote: > Hi > > There was a discussion in the room about normalization. > > Here’s a proposal. Please respond to the list if it’s acceptable: > > Clients MUST normalize input (both userid and passwords) to NFC When charset is "UTF8", right? > Server MAY normalize with old clients (clients that don’t send the charset attribute) I don't think we need to state this. > Question to the group: what should a server do with a non-normalized userid/password, where the client is new (i.e. sends “charset”) - this is a broken client. In HTTPbis, we usually did not make any normative requirements for broken messages, unless there was a security concern connected to it. So I would leave this unspecified. > Please respond to the list within the next two weeks. I still think that this is something implementers just won't do. Unless I'm missing something here there is potential pain, but little gain. Bets regards, Julian From nobody Sun Nov 16 04:02:38 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C411A8029 for ; Sun, 16 Nov 2014 04:02:34 -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 mxYef6Tn8vQ1 for ; Sun, 16 Nov 2014 04:02:32 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BF71A6FD8 for ; Sun, 16 Nov 2014 04:02:31 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so1254132wgh.30 for ; Sun, 16 Nov 2014 04:02:30 -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=5w4XGp4hXG95WfgbpSVCHYB9qDwo0zZUlB564efcYKc=; b=U+9aRe1ml4TWp5pWX6ZuRzSWxuy2+Q76fCme6dlSiLOloyASOl7DQ9KIOnXmovXQku Cs917okDU99Eqrdp/ViTnkTRMMwk1sXWmJ3zssYrx46J2/eI1CdU5zlahdyNTlwN1p7N jWgkd71uleV6ni+3wIiX0wOO+VvgikxIVrVkw+Eez8VdvgW0llPd3gRMwmeTwS78VENo Zit6UI5/nkyXoOq9rIS4RXZY1oXq6nPL71bMqkQS138je0NzDuDCYjMW2rcXdJeCFp5c cPBfr466eIY7nj8d/taJ8liujBYIk74N5wmHTeUZ8pA1W791gDNDFrZNQbK1uWClamBy IIUQ== X-Received: by 10.180.212.5 with SMTP id ng5mr23390273wic.50.1416139350657; Sun, 16 Nov 2014 04:02:30 -0800 (PST) Received: from [192.168.1.103] (IGLD-84-228-17-54.inter.net.il. [84.228.17.54]) by mx.google.com with ESMTPSA id ji10sm10802008wid.7.2014.11.16.04.02.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Nov 2014 04:02:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <21948A23EC4B7390EA2656F1@JcK-HP8200.jck.com> Date: Sun, 16 Nov 2014 14:02:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7AE781EA-7193-4C6D-9CBA-5D1A5D1E06AE@gmail.com> References: <5466B3D6.9080105@andyet.net> <21948A23EC4B7390EA2656F1@JcK-HP8200.jck.com> To: IETF HTTP Auth X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/wiJ-dfrhrbQwfSlTZOYJORcDE58 Subject: Re: [http-auth] [precis] Allowed Characters in usernames and passwords 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, 16 Nov 2014 12:02:35 -0000 > On Nov 15, 2014, at 7:03 AM, John C Klensin wrote: > > > --On Friday, November 14, 2014 19:00 -0700 Peter Saint-Andre - > &yet wrote: > >> FYI. >> >> >> -------- Original Message -------- >> Subject: [http-auth] Allowed Characters in usernames and >> passwords >> Date: Fri, 14 Nov 2014 15:59:00 -1000 >> From: Yoav Nir >> To: IETF HTTP Auth >> >> Hi >> >> An issue that has been discussed on the list has been what >> characters are allowed for usernames and passwords in the >> Basic and Digest documents (this probably also applies to >> other specification, specifically MutualAuth, but that is not >> the issue in this message). >> >> So the precis working group is creating the saslprepbis ([1]) >> document that should be published soon (as soon as the end of >> this year). That contains a profile for characters that are >> and aren't recommended for use in username and passwords. >> >> So the proposal that reflects the consensus of the people in >> today's session is as follows: >> >> Both the Basic and Digest drafts will mandate that supporting >> servers MUST support usernames and passwords that conform to >> the saslprepbis specification, and MAY support non-conforming >> ones. The rationale is that we have to have a MAY there, >> because we can't prohibit stuff that works today. Both >> documents will add text with these MUST and MAY. >> >> The room was unanimous in supporting this direction. If you >> disagree, please comment to the list by Monday 24-Nov-2014. >> Since we had a strong hum for in the room, we will take >> silence as consensus > > Peter, Yoav, > > Given my ongoing mini-campaign to reduce the number of profiles > and sets of rules to an absolute minimum because users won't be > able to keep track of different ones and will only be astonished > and confused, this is exceptionally good news. Two comments: > > (1) While the assertion that you "can't prohibit stuff that > works" is probably true, you are not thereby limited to MAY. It > would be entirely consistent with IETF practices in the past to > say "MUST support ... that conform and SHOULD avoid > non-conforming ones except when the latter are justified by > compatibility with existing implementations". That still > doesn't _prohibit_ the existing practices, but makes the desired > compatibility norm somewhat more clear. > > (2) I assume there are recommendations coming out of WHATWG > and/or W3C that might interact with whatever HTTP-AUTH has to > say. If that is the case, I expect that the HTTP-AUTH > recommendation will either be consistent with them or will > identify and explain the differences. > > It would be reasonable for you to assume that both comments > above will, if necessary, be repeated during IETF Last Call. > > best, > john From nobody Sun Nov 16 06:44:12 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3221A3BA9 for ; Sun, 16 Nov 2014 06:44: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, 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 Qv6LjnrlIbPG for ; Sun, 16 Nov 2014 06:44:09 -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 B6CA31A00AF for ; Sun, 16 Nov 2014 06:44:08 -0800 (PST) Received: from [192.168.2.160] ([84.187.50.251]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MUCTO-1XQCjU0mqA-00QzR7; Sun, 16 Nov 2014 15:44:06 +0100 Message-ID: <5468B830.1070207@gmx.de> Date: Sun, 16 Nov 2014 15:44:00 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Yoav Nir , IETF HTTP Auth References: <5466B3D6.9080105@andyet.net> <21948A23EC4B7390EA2656F1@JcK-HP8200.jck.com> <7AE781EA-7193-4C6D-9CBA-5D1A5D1E06AE@gmail.com> In-Reply-To: <7AE781EA-7193-4C6D-9CBA-5D1A5D1E06AE@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:CWC6+1OVRB2x16Bl/nbgfDxOq43lJisLTGNfWyIznhjfo/vL4HU lMG1zhxatkT+CumkvNwu79kI+weZ7cSJZZMhseHyht/AkPtz9BHfyaUCwQ+7y8pzjtlieLW WOcCor4xUSSpyNtQGaBaOkx6ZTzpoyZIlb1KQT5RMSNis7E14mnyOYG8BZcWyBH82JV3opb /ceeWsEHHflMd/+TP9g9g== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/w6o4eNxxNV2OFnkFFCfUpmrzrjw Subject: Re: [http-auth] [precis] Allowed Characters in usernames and passwords 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, 16 Nov 2014 14:44:10 -0000 On 2014-11-16 13:02, Yoav Nir wrote: >> On Nov 15, 2014, at 7:03 AM, John C Klensin wrote: > ... >> Given my ongoing mini-campaign to reduce the number of profiles >> and sets of rules to an absolute minimum because users won't be >> able to keep track of different ones and will only be astonished >> and confused, this is exceptionally good news. Two comments: >> >> (1) While the assertion that you "can't prohibit stuff that >> works" is probably true, you are not thereby limited to MAY. It >> would be entirely consistent with IETF practices in the past to >> say "MUST support ... that conform and SHOULD avoid >> non-conforming ones except when the latter are justified by >> compatibility with existing implementations". That still >> doesn't _prohibit_ the existing practices, but makes the desired >> compatibility norm somewhat more clear. HTTP Authentication Schemes deal with getting credentials over the wire, not with the way they are generated or stored. The set of allowable characters thus is sort of out-of-scope for a scheme definition, in particular when it has been in use for over a decade already. I'm ok with "MUST support" (for the case when we're talking about the new charset=UTF8 world). However the "SHOULD avoid" doesn't make any sense to me. No real-world implementation will do this if there's a slim chance that it will prevent a user from logging into an existing system. >> (2) I assume there are recommendations coming out of WHATWG >> and/or W3C that might interact with whatever HTTP-AUTH has to >> say. If that is the case, I expect that the HTTP-AUTH >> recommendation will either be consistent with them or will >> identify and explain the differences. Concrete pointers, please. >> It would be reasonable for you to assume that both comments >> above will, if necessary, be repeated during IETF Last Call. >> >> best, >> john Best regards, Julian From nobody Mon Nov 17 09:29:20 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EF81A86F0 for ; Mon, 17 Nov 2014 09:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 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_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 FEu4VZ9LaDf3 for ; Mon, 17 Nov 2014 09:29:16 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D961A86EF for ; Mon, 17 Nov 2014 09:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1416245355; x=2280158955; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pYx5HrkXCF4NMScBJ5sHpn49gq4X1LbGm3T2UCw+UkQ=; b=rbFuV3MyCK3JidZijyAOn0VPAsqgKFLsciH1c+lwuDoeiyLRr2k5GVo7NY7rs9Hc V2hevWcDw4U8NqTEiwS0Ktpp11ndwi1IVGTvTRNmznEO3MMJfFq0GiR1Tlplmd/a PwEjG2PC08UuAkgc71Mw5iuME7ZObbLNfiReSV+i84JJOHpJEY8yF/YsQrT+90MK 3incOf9rqDhtHY/dYqTI06NfPif+g9BW69xfUyBF3Uz2vEtl7ooZzDUyMKXz0V8y Phd1tG8GiG1w/20fzKAuaNC72bGaAp4qBEERXuD+kG0SvkHHilqxH+bSNIB3jItk 436RPFDTgzVNJFwUz8Ji0Q==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 22.44.09658.A603A645; Mon, 17 Nov 2014 09:29:15 -0800 (PST) X-AuditID: 11973e16-f79aa6d0000025ba-fa-546a306a0c63 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 6A.66.05775.7503A645; Mon, 17 Nov 2014 09:28:55 -0800 (PST) Received: from [17.153.63.201] (unknown [17.153.63.201]) by sesame.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NF700D5F1WOU710@sesame.apple.com> for http-auth@ietf.org; Mon, 17 Nov 2014 09:29:14 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: text/plain; charset=utf-8 From: Michael Sweet In-reply-to: Date: Mon, 17 Nov 2014 12:29:11 -0500 Content-transfer-encoding: quoted-printable Message-id: References: To: Yoav Nir X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FAYpZttkBViMGkuk8WH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsX7Rf7aCzZwVmw//Zm1gvMbexcjJISFgItF6ZiMbhC0mceHe ejBbSGAvo0TrDy6YmhtHH7N0MXIBxfuYJG5OfcoCUTSJSWLT3mwQW1jAWmLdk/+MIDavgJ5E 05PHTF2MHBzMAuoSU6bkgoTZBNQkfk/qYwWxOQVsJV4+mgq2i0VAVWLfpx3MIDZI+fIpL6Bs bYkn7y6wQoy0kdgw5T0jxFobiXX/t4DdLyKgJHH4yldmiDtlJf5dPMMOcqeEwFtWic1/njJO YBSeheSkWQgnzUKyYgEj8ypGodzEzBzdzDxzvcSCgpxUveT83E2MoBCebie2g/HhKqtDjAIc jEo8vDuyM0OEWBPLiitzDzFKc7AoifNa/8oIERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBo vsKjbbH8yp4GU0Pl70dNxHMmrFr7JtwucL//8f9dBQvMHBPfsR5+/j3U5lzgztyypNkHHqh/ e7T6rFCSpeJbGc5Xh04Uzjl4kM0+VDHXZu2dQs/TEx1YP1UfeBL/9PWDX1V/NxYvye98vtXA 7mJI+sy8dXEOGxhbJ0wvLX1T01a1ylBGkfGTEktxRqKhFnNRcSIAoEa510ICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDcoBtukBVicG2ngMWH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsX7Rf7aCzZwVmw//Zm1gvMbexcjJISFgInHj6GMWCFtM4sK9 9WxdjFwcQgJ9TBI3pz4FSwgJTGKS2LQ3G8QWFrCWWPfkPyOIzSugJ9H05DFTFyMHB7OAusSU KbkgYTYBNYnfk/pYQWxOAVuJl4+msoHYLAKqEvs+7WAGsUHKl095AWVrSzx5d4EVYqSNxIYp 7xkh1tpIrPu/BexOEQElicNXvjJD3Ckr8e/iGfYJjAKzkFwxC+GKWUimLmBkXsUoUJSak1hp ppdYUJCTqpecn7uJERx0hVE7GBuWWx1iFOBgVOLh3ZGdGSLEmlhWXJl7iFGCg1lJhLdEPytE iDclsbIqtSg/vqg0J7X4EKM0B4uSOO+3TKBqgfTEktTs1NSC1CKYLBMHp1QD47RLX7MP3y7z jd9g+sPjQuLvu4pV1pLmzxb+9NgfNa13w424/sbFx1TcVTYXLKgMdt7zxHKm4JGo6uf6M1JO aHFYvPmy5N2k/DT+Gwn9ifmdJV06f9b9FLH8slphqs/S415B/Dt5YjpMV4XEr2Jun3jiuhvj Pb2nWva5mbECLUy1YTPf/PK1UGIpzkg01GIuKk4EAItEQVk2AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/__GxKs2RbITpiQUsVHOOyOUp5ho Cc: IETF HTTP Auth Subject: Re: [http-auth] Consensus call about normalization 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, 17 Nov 2014 17:29:18 -0000 Yoav, I'm OK with a Client requirement when using UTF-8. For the server any normalization is an implementation detail, for both = UTF-8 and legacy stuff, so I don't think we want to say anything there. > On Nov 14, 2014, at 9:04 PM, Yoav Nir wrote: >=20 > Hi >=20 > There was a discussion in the room about normalization. >=20 > Here=E2=80=99s a proposal. Please respond to the list if it=E2=80=99s = acceptable: >=20 > Clients MUST normalize input (both userid and passwords) to NFC >=20 > Server MAY normalize with old clients (clients that don=E2=80=99t send = the charset attribute) >=20 > Question to the group: what should a server do with a non-normalized = userid/password, where the client is new (i.e. sends =E2=80=9Ccharset=E2=80= =9D) - this is a broken client. >=20 > Please respond to the list within the next two weeks. >=20 > Thanks >=20 > Matt & Yoav >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Mon Nov 17 09:53:56 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF041A8700 for ; Mon, 17 Nov 2014 09:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, 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 lj_K8ljcW3Kz for ; Mon, 17 Nov 2014 09:53:54 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F2CA31A8706 for ; Mon, 17 Nov 2014 09:53:52 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id B993B67C06E for ; Mon, 17 Nov 2014 09:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kKJhmgsmdeLaQLk6uacIgKWjlxU=; b=nlSpFwbxsIJ PTuPNeqTuaFwZH2+vt3P+JMMJaPzuiE36JKOHflu6pY5tMjb6Un3lh3ad0F4J3Ul ZtFkDtp0SMuGzVAP8ANjgyX2eAXQ0UoOdatCZPIcRxgfE/h4HqhFyg+GKi/nPOtx DY0HMCBCaWNiq1aJ5FzYCdTWTLnHN9b8= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 9004667C06D for ; Mon, 17 Nov 2014 09:53:52 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so6442719wid.15 for ; Mon, 17 Nov 2014 09:53:51 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.218.133 with SMTP id pg5mr19381706wic.70.1416246831454; Mon, 17 Nov 2014 09:53:51 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 17 Nov 2014 09:53:51 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Nov 2014 11:53:51 -0600 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/iKTP3Jqsk8bIT5d9XXmsutvLtVo Cc: IETF HTTP Auth Subject: Re: [http-auth] Consensus call about normalization 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, 17 Nov 2014 17:53:56 -0000 On Fri, Nov 14, 2014 at 8:04 PM, Yoav Nir wrote: > Here=E2=80=99s a proposal. Please respond to the list if it=E2=80=99s acc= eptable: > > Clients MUST normalize input (both userid and passwords) to NFC > > Server MAY normalize with old clients (clients that don=E2=80=99t send th= e charset attribute) > > Question to the group: what should a server do with a non-normalized user= id/password, where the client is new (i.e. sends =E2=80=9Ccharset=E2=80=9D)= - this is a broken client. Whenever possible it's best to use normalization-insensitive string comparison. Whenever a password has to get fed through a PBKDF or similar transformation, of course, it has to be in canonical form; for Basic auth there's no such need, while for DIGEST there is. Regardless, some node has to have Unicode normalization support of some sort, and since clients tend to have to have it (see above), it might as well be the client that normalizes. But I prefer the normalization-insensitivity formulation because sometimes decomposed forms leak, mostly courtesy of HFS+ decomposing filenames on create. That should mostly not be a problem here, so on the whole I'm OK with the proposal. Note though that when there's a need to digest a password then the canonical form has to specify at least normalization, and as much as stringprep profiles commonly do (e.g., additional mappings, prohibitions, ...). Nico -- From nobody Mon Nov 17 12:51:02 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF8A1A9164 for ; Mon, 17 Nov 2014 12:50:59 -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 vmBMUE3Nj2Sk for ; Mon, 17 Nov 2014 12:50:58 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B21961A916C for ; Mon, 17 Nov 2014 12:50:58 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 8A55920047B86; Mon, 17 Nov 2014 12:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=references :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id:cc:from:subject:date:to; s=gbiv.com; bh=frCvutBK0xQC VwFkzkj37PRqh3A=; b=lMykpdKvSEV+8wsrg4rfmcOrnQC/pJgMYH0hIh1Ihvv9 IqhJ69JXbWo21HQPWP2I0BbHhvaPDs/sQXGqkJ5bj3EeGq6F/8mFUqTacKfJO9N/ bYUvh5fHgX4J3ZKzcZ2DJMuu59ANCiZBz/BXRLgXYaNGrQEwr4wASNb2gTaKPQc= Received: from [192.168.1.10] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 7B39820047B84; Mon, 17 Nov 2014 12:50:58 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5C33B0EA-037B-4930-A89F-106872C71F59@gbiv.com> X-Mailer: iPhone Mail (11D257) From: "Roy T. Fielding" Date: Mon, 17 Nov 2014 12:50:54 -0800 To: Yoav Nir Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/jcxUEEUp3b2duKJIAFkgqija6R8 Cc: IETF HTTP Auth Subject: Re: [http-auth] Consensus call about normalization 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, 17 Nov 2014 20:51:00 -0000 No. Normalization added to older auth mechanisms will not work. What currently works is consistency: users tend to use the same character co= mposition mechanism when they access an account as they did when they create= d the account. IOW, the characters match by habit rather than normalization.= Normalization defined for new not yet deployed auth mechanisms is fine. ....Roy > On Nov 14, 2014, at 6:04 PM, Yoav Nir wrote: >=20 > Hi >=20 > There was a discussion in the room about normalization. >=20 > Here=E2=80=99s a proposal. Please respond to the list if it=E2=80=99s acce= ptable: >=20 > Clients MUST normalize input (both userid and passwords) to NFC >=20 > Server MAY normalize with old clients (clients that don=E2=80=99t send the= charset attribute) >=20 > Question to the group: what should a server do with a non-normalized useri= d/password, where the client is new (i.e. sends =E2=80=9Ccharset=E2=80=9D) -= this is a broken client. >=20 > Please respond to the list within the next two weeks. >=20 > Thanks >=20 > Matt & Yoav >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Tue Nov 25 11:57:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BDB1A6FB4 for ; Tue, 25 Nov 2014 11:56:31 -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 8nKcBdAsAGUB for ; Tue, 25 Nov 2014 11:56:28 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75ADC1A0367 for ; Tue, 25 Nov 2014 11:56:28 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so2663844wiv.13 for ; Tue, 25 Nov 2014 11:56:27 -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=VYS60qTn6w0HGrT0RkiYGhmvzJx32KZz9Wy+4U3T5MA=; b=KtHowFgZ5aJdDOo7GBhJyCkmGp2+K/GXX4HHn2gJ/tJnu2LvwALVVtXlFAO2otE+Zi ErEdeJZftEyW8E2m41csv9PkaISKjhzjXMitrHTcvMMbEJvyfB8oc4zJlu4fEvRfuPbI pQ2pSduJ4cncHePovwn8C44SuR1A+BUvZxskMhd7ww8ErsCbbkiPw9uA70c7mAj7NVsX Ab0Dc6HH88aE8xO0ofYmSTJDGlXvFeZwz3Ex0mvSVut+VEHTQSoL36Qi/a+92LENRVeY 8VY80yZvGRbxLExST8lHmXbT1WES/rD5+AEanx48s9P1Ospuh65oeMzTTv/htLNsznF5 SkXg== X-Received: by 10.180.98.233 with SMTP id el9mr34139558wib.3.1416945386938; Tue, 25 Nov 2014 11:56:26 -0800 (PST) Received: from [192.168.1.103] (IGLD-84-228-139-23.inter.net.il. [84.228.139.23]) by mx.google.com with ESMTPSA id l10sm17840961wif.20.2014.11.25.11.56.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 11:56:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> Date: Tue, 25 Nov 2014 21:56:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> To: IETF HTTP Auth X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/iWrUs-QA6tq6SHg61bi9UoYeA_Y Subject: Re: [http-auth] Allowed Characters in usernames and passwords 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, 25 Nov 2014 19:56:31 -0000 Hi Julian and Rifaat. To re-summarize, the proposal was that servers MUST support usernames = and passwords compliant with saslprepbis, and MAY support non-compliant = characters (except for specialized requirements such as those around = colon). The room was unanimous on this, and confirming on the list yielded one = objection to the =E2=80=9CMAY=E2=80=9D preferring =E2=80=9CSHOULD NOT=E2=80= =9D for non-compliant characters. However, there was no support for this = and as Julian said, we have no control over existing (or future!) = user/password databases, and no sane implementation will block a valid = user name just because it doesn=E2=80=99t comply with saslprepbis. Please add text to your drafts reflecting this, and reference = saslprepbis as a normative reference. Julian: once you do that and publish a revision we can go to WGLC. Matt & Yoav > On Nov 15, 2014, at 4:01 AM, Yoav Nir wrote: >=20 > So of course I forgot something. >=20 > Additionally, the Basic and Digest documents will refer to the precis = document, and not specify acceptable characters themselves, except where = there is a unique requirement, such as the requirements around colons in = usernames or passwords in Basic. In all other cases, saslprepbis will be = our normative reference. >=20 > Yoav >=20 >> On Nov 14, 2014, at 3:59 PM, Yoav Nir wrote: >>=20 >> Hi >>=20 >> An issue that has been discussed on the list has been what characters = are allowed for usernames and passwords in the Basic and Digest = documents (this probably also applies to other specification, = specifically MutualAuth, but that is not the issue in this message). >>=20 >> So the precis working group is creating the saslprepbis ([1]) = document that should be published soon (as soon as the end of this = year). That contains a profile for characters that are and aren=E2=80=99t = recommended for use in username and passwords. >>=20 >> So the proposal that reflects the consensus of the people in = today=E2=80=99s session is as follows: >>=20 >> Both the Basic and Digest drafts will mandate that supporting servers = MUST support usernames and passwords that conform to the saslprepbis = specification, and MAY support non-conforming ones. The rationale is = that we have to have a MAY there, because we can=E2=80=99t prohibit = stuff that works today. Both documents will add text with these MUST and = MAY. >>=20 >> The room was unanimous in supporting this direction. If you disagree, = please comment to the list by Monday 24-Nov-2014. Since we had a strong = hum for in the room, we will take silence as consensus >>=20 >> Thanks >>=20 >> Matt & Yoav >>=20 >> [1] https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-09 >=20 From nobody Tue Nov 25 12:03:25 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57871A87BD for ; Tue, 25 Nov 2014 12:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 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, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, 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 Tqfq7E5aMK_2 for ; Tue, 25 Nov 2014 12:02:05 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BF2761A875C for ; Tue, 25 Nov 2014 12:02:05 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 7CABB59406B for ; Tue, 25 Nov 2014 12:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZYYSUinHnJql9HCyvEg3 Se2kbe0=; b=E0v4q3F8HY81NMhO/lSRcgJ/8voX/mWhUvaypkdAMgXrHDqXrgFN qLoLwgMvaElzK8qZZ2uDyfnl7dVbSwfpMqQ4XkUmyRApDLrcxX9ighiijmueOWv5 yHH5eLR1Cc2eTEzMrtv+AEgSPxtchLhAmB+o9LSLg2dKzBPJKokCpSU= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 55AA1594069 for ; Tue, 25 Nov 2014 12:02:05 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l2so1839717wgh.41 for ; Tue, 25 Nov 2014 12:02:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.104.234 with SMTP id gh10mr34208184wib.3.1416945724257; Tue, 25 Nov 2014 12:02:04 -0800 (PST) Received: by 10.216.32.136 with HTTP; Tue, 25 Nov 2014 12:02:04 -0800 (PST) In-Reply-To: References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> Date: Tue, 25 Nov 2014 14:02:04 -0600 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/sQBKddD0K40dq6OZ2TJLaXhG5tQ Cc: IETF HTTP Auth Subject: Re: [http-auth] Allowed Characters in usernames and passwords 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, 25 Nov 2014 20:02:07 -0000 On Tue, Nov 25, 2014 at 1:56 PM, Yoav Nir wrote: > To re-summarize, the proposal was that servers MUST support usernames and passwords compliant with saslprepbis, and MAY support non-compliant characters (except for specialized requirements such as those around colon). What does this mean? That the client MAY/SHOULD/MUST prep the thing? How would the server know if the thing is prep'ed with saslprepbis (if not by applying the prep itself)? What would it mean for the server to not "support usernames and passwords compliant with saslprepbis"? Nico -- From nobody Tue Nov 25 12:09:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E161A879D for ; Tue, 25 Nov 2014 12:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, 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 HqVuWvoB_6p7 for ; Tue, 25 Nov 2014 12:08:05 -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 3255E1A875C for ; Tue, 25 Nov 2014 12:08:05 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 0B2183B805B for ; Tue, 25 Nov 2014 12:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=+kvrjwf/dkWLRbWKDH4N W/N7asg=; b=vMshDbaA0Dp9tiOR0aB60miYIbNX+sXpHSMIaqvNua7/T2PCVss1 13g30gi2nCO7nrzLRcDS6VNVqEDI/DiZXARhuabvW0kYOeAiq1uO6CciH6DieBJa qI8ISlP3J4U/1QGjOE38HSSSxzplZ2A9ltd35m3wObcMag0CVM12OSI= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id D90033B8005 for ; Tue, 25 Nov 2014 12:08:04 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so2711908wiw.4 for ; Tue, 25 Nov 2014 12:08:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.104.234 with SMTP id gh10mr34256910wib.3.1416946083780; Tue, 25 Nov 2014 12:08:03 -0800 (PST) Received: by 10.216.32.136 with HTTP; Tue, 25 Nov 2014 12:08:03 -0800 (PST) In-Reply-To: <5C33B0EA-037B-4930-A89F-106872C71F59@gbiv.com> References: <5C33B0EA-037B-4930-A89F-106872C71F59@gbiv.com> Date: Tue, 25 Nov 2014 14:08:03 -0600 Message-ID: From: Nico Williams To: "Roy T. Fielding" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/PIz0fhEf6csIIshNt9dKTfq4VlE Cc: IETF HTTP Auth Subject: Re: [http-auth] Consensus call about normalization 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, 25 Nov 2014 20:08:09 -0000 On Mon, Nov 17, 2014 at 2:50 PM, Roy T. Fielding wrote: > No. Normalization added to older auth mechanisms will not work. Asking that clients that don't normalize start to is asking for trouble, yes. Asking that servers do normalization-insensitive matching of usernames is asking for much less trouble (since presumably there shouldn't be very many existing and semantically distinct usernames that alias each other under normalization-insensitive string comparison!). For Basic that also works for passwords. For Digest things get tricky. > What currently works is consistency: users tend to use the same character composition mechanism when they access an account as they did when they created the account. IOW, the characters match by habit rather than normalization. Yes. > Normalization defined for new not yet deployed auth mechanisms is fine. Or for old ones when there is an indication that the new thing is expected. Nico -- From nobody Tue Nov 25 12:11:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387881A8887 for ; Tue, 25 Nov 2014 12:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_42=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 AdvYO6JHtyPw for ; Tue, 25 Nov 2014 12:10:01 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBD11A889D for ; Tue, 25 Nov 2014 12:08:40 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so10336155wiw.14 for ; Tue, 25 Nov 2014 12:08:38 -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=QsgIoiGhnQqhFoOJa56LPGFbcuEhwBYBMSbN+xZJfT8=; b=VUdhXEe379lg/bF3Li+kMyfl2PxAAMD9lxHQka8JcvLnZqeKvw7pt5oOzIRs2UX+V3 fJA0U7XticXHB1PSutXETJQvJFy9d+eWYNmLTwd4bcTVxMjzhl2GIQb/jwCdMDG4jZUc 4P/uYtKCuaz1uCE4VAYG6gd8cjCtaWrwxgE7VzABlKz0GQ1iGT/KFrrqGq9mj6eKL7ij YCflpTwDiTNdeTs/8k3LgDOJMaOMcd7ZzePljq7LaLnBaM40Fsq81fSVfj1Q+mBRy8mF 0GHYq46e0QES0gCNypEabfeSZoynCYEhFkJBEWK3WOV7mj6qIgmTcmpoRAN3tDlX3aVi vSPQ== X-Received: by 10.181.11.169 with SMTP id ej9mr34162846wid.75.1416946118854; Tue, 25 Nov 2014 12:08:38 -0800 (PST) Received: from [192.168.1.103] (IGLD-84-228-139-23.inter.net.il. [84.228.139.23]) by mx.google.com with ESMTPSA id dx8sm4266445wib.2.2014.11.25.12.08.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 12:08:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Tue, 25 Nov 2014 22:08:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> To: Nico Williams X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/BNQT_zY7xDWv7awmmW9BBaUMFCU Cc: IETF HTTP Auth Subject: Re: [http-auth] Allowed Characters in usernames and passwords 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, 25 Nov 2014 20:10:02 -0000 > On Nov 25, 2014, at 10:02 PM, Nico Williams = wrote: >=20 > On Tue, Nov 25, 2014 at 1:56 PM, Yoav Nir wrote: >> To re-summarize, the proposal was that servers MUST support usernames = and passwords compliant with saslprepbis, and MAY support non-compliant = characters (except for specialized requirements such as those around = colon). >=20 > What does this mean? That the client MAY/SHOULD/MUST prep the thing? > How would the server know if the thing is prep'ed with saslprepbis (if > not by applying the prep itself)? What would it mean for the server > to not "support usernames and passwords compliant with saslprepbis=E2=80= =9D? The discussion was about the profiles for usernames and passwords in = sections 3.2 and 4.2 respectively of = https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-10 . We are not talking about the prep process (which the client should do), = only about the result. We are saying that the server MUST support = usernames and passwords that conform to those rules. Yoav From nobody Sun Nov 30 14:27:11 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3471A1AA3 for ; Sun, 30 Nov 2014 14:27:10 -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_42=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 XnTjBkiWeH15 for ; Sun, 30 Nov 2014 14:27:09 -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 DCB861A1AA0 for ; Sun, 30 Nov 2014 14:27:08 -0800 (PST) Received: from [192.168.2.160] ([84.187.39.147]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MH07e-1XhThE2SSA-00DpJW; Sun, 30 Nov 2014 23:27:05 +0100 Message-ID: <547B99AC.4060109@gmx.de> Date: Sun, 30 Nov 2014 23:26:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Yoav Nir , Nico Williams References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Y4X2BjpnlrLLgc8rb3ad7TOwhI6AawF3v/mgMMCFi4Ylim4rnPh 0EEbFaCqcx6YIjx8W+Oo697UsTbaosZlOjM8N0qTooDkW+O4A28t0oXQUlspx0/7YGB+9Nt DPjpxUoBMuruxfefYBDBoVn7CALf+quSmjFzvnt4wL2FNbrL1ATuQ/ZygDd6kd/i45QRGLB v+j4LjEh++9xnSr3TH1BA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/TgTMGfkv3hd7dR2gMbYigO0KyxA Cc: IETF HTTP Auth , Peter Saint-Andre Subject: Re: [http-auth] Allowed Characters in usernames and passwords 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, 30 Nov 2014 22:27:10 -0000 On 2014-11-25 21:08, Yoav Nir wrote: > >> On Nov 25, 2014, at 10:02 PM, Nico Williams wrote: >> >> On Tue, Nov 25, 2014 at 1:56 PM, Yoav Nir wrote: >>> To re-summarize, the proposal was that servers MUST support usernames and passwords compliant with saslprepbis, and MAY support non-compliant characters (except for specialized requirements such as those around colon). >> >> What does this mean? That the client MAY/SHOULD/MUST prep the thing? >> How would the server know if the thing is prep'ed with saslprepbis (if >> not by applying the prep itself)? What would it mean for the server >> to not "support usernames and passwords compliant with saslprepbis”? > > The discussion was about the profiles for usernames and passwords in sections 3.2 and 4.2 respectively of https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-10 . In draft-11, there's a choice of "UsernameCaseMapped" and "UsernameCasePreserved" - I assume we'll choose the latter... Best regards, Julian From nobody Sun Nov 30 14:32:06 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192871A1AA7 for ; Sun, 30 Nov 2014 14:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, 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 IkhptLvDtWiy for ; Sun, 30 Nov 2014 14:32:02 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2230D1A1AA4 for ; Sun, 30 Nov 2014 14:32:02 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so8490995iga.2 for ; Sun, 30 Nov 2014 14:32:01 -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=5ELDD7X4B7zco6tsHG0/XOlxFbDL/csTyN7cjGo84F4=; b=WPDaCazjN1WXHY6XhJgEbs5C1P6JWbcX8EAw77mb4LdXI9kJTZWciu+6IWQpG2glZ4 Dq+lt8/noMbXO39BO5LH8OQtYVqe7EJa/LGp+qQBwCOtZjgXk8bOi0xwa1XwnEZjoTsN nOj3OMM9AV9SHm0oEPdz3O2xHgfJ88MvaZTiCaksc4a9T+tyMCzhEW8GamIkmT8gYI6U vZ7uC+s/pCw81fVU4MF3aqPZuLpcTeJtKs/sH7yBbpGdWNaL2t/vtr8I+I0Qbj5BwyFV wM+10ptTTaitJFWp6iyhCcPWsi74oIHQY3uanx7v9J81JxOk+A2D9dfYC9C3C34QmtB4 kVXQ== X-Gm-Message-State: ALoCoQkCaSMWKMIrua6xLDuvCszLQoc1C5bzXWlYykj2kw07fzuYhPLVEVDAyR4iV58jTTi4IzyT X-Received: by 10.50.66.200 with SMTP id h8mr28028865igt.20.1417386721590; Sun, 30 Nov 2014 14:32:01 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id kw5sm9272190igb.20.2014.11.30.14.32.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Nov 2014 14:32:00 -0800 (PST) Message-ID: <547B9AE0.4030301@andyet.net> Date: Sun, 30 Nov 2014 15:32:00 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke , Yoav Nir , Nico Williams References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> <547B99AC.4060109@gmx.de> In-Reply-To: <547B99AC.4060109@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/8OnsM2axdx4sJWaXSbTJrERooak Cc: IETF HTTP Auth , Peter Saint-Andre Subject: Re: [http-auth] Allowed Characters in usernames and passwords 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, 30 Nov 2014 22:32:04 -0000 On 11/30/14, 3:26 PM, Julian Reschke wrote: > On 2014-11-25 21:08, Yoav Nir wrote: >> >>> On Nov 25, 2014, at 10:02 PM, Nico Williams >>> wrote: >>> >>> On Tue, Nov 25, 2014 at 1:56 PM, Yoav Nir wrote: >>>> To re-summarize, the proposal was that servers MUST support >>>> usernames and passwords compliant with saslprepbis, and MAY support >>>> non-compliant characters (except for specialized requirements such >>>> as those around colon). >>> >>> What does this mean? That the client MAY/SHOULD/MUST prep the thing? >>> How would the server know if the thing is prep'ed with saslprepbis (if >>> not by applying the prep itself)? What would it mean for the server >>> to not "support usernames and passwords compliant with saslprepbis”? >> >> The discussion was about the profiles for usernames and passwords in >> sections 3.2 and 4.2 respectively of >> https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-10 . > > In draft-11, there's a choice of "UsernameCaseMapped" and > "UsernameCasePreserved" Yes, I added the options so that we'd all have definitive options (and so that UsernameCaseMapped wasn't defined in an XMPP specification). > - I assume we'll choose the latter... Probably. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sun Nov 30 15:01:04 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7743D1A1AB4 for ; Sun, 30 Nov 2014 15:01:02 -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_42=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 E6t0Qhege9Qi for ; Sun, 30 Nov 2014 15:01:01 -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 DE51D1A1AA8 for ; Sun, 30 Nov 2014 15:01:00 -0800 (PST) Received: from [192.168.2.160] ([84.187.39.147]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M0Ppl-1YBNpA2wWr-00udQ8; Mon, 01 Dec 2014 00:00:56 +0100 Message-ID: <547BA19B.7010707@gmx.de> Date: Mon, 01 Dec 2014 00:00:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Yoav Nir , Nico Williams References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> <547B99AC.4060109@gmx.de> <547B9AE0.4030301@andyet.net> In-Reply-To: <547B9AE0.4030301@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:L8SbELCLyujx221mavsSaNOPQ7x+Xhvw1FJ42ajd7W+qM9ekBo5 YgbYEv3umijBwbp5pHxaoJPxpYrBpxkG8uAn7RL7WE8v3QbqGO9MV/EgukOA8XJb+3HCo/D zjq0qCDL3s1YHFnT5s9pJ1QQLJ8+McUJHMO1vCmMT0aOsRrZnYZ+LJ5lmwGTkFpw9gjoROV KlsHQyYOyH44JK3RDtCGw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/OG7tfI87pGjaxuQq12m1pn_olFQ Cc: IETF HTTP Auth , Peter Saint-Andre Subject: Re: [http-auth] Allowed Characters in usernames and passwords 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, 30 Nov 2014 23:01:02 -0000 On 2014-11-30 23:32, Peter Saint-Andre - &yet wrote: > On 11/30/14, 3:26 PM, Julian Reschke wrote: >> On 2014-11-25 21:08, Yoav Nir wrote: >>> >>>> On Nov 25, 2014, at 10:02 PM, Nico Williams >>>> wrote: >>>> >>>> On Tue, Nov 25, 2014 at 1:56 PM, Yoav Nir wrote: >>>>> To re-summarize, the proposal was that servers MUST support >>>>> usernames and passwords compliant with saslprepbis, and MAY support >>>>> non-compliant characters (except for specialized requirements such >>>>> as those around colon). >>>> >>>> What does this mean? That the client MAY/SHOULD/MUST prep the thing? >>>> How would the server know if the thing is prep'ed with saslprepbis (if >>>> not by applying the prep itself)? What would it mean for the server >>>> to not "support usernames and passwords compliant with saslprepbis”? >>> >>> The discussion was about the profiles for usernames and passwords in >>> sections 3.2 and 4.2 respectively of >>> https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-10 . >> >> In draft-11, there's a choice of "UsernameCaseMapped" and >> "UsernameCasePreserved" > > Yes, I added the options so that we'd all have definitive options (and > so that UsernameCaseMapped wasn't defined in an XMPP specification). > >> - I assume we'll choose the latter... > > Probably. > > Peter OK, for now I have this change - note that it only applies for the case where the server has advertised UTF-8 support using the charset parameter. Are we ok with this -- that is, can I submit a new draft and declare victory? Best regards, Julian From nobody Sun Nov 30 15:24:05 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8681A1ABB for ; Sun, 30 Nov 2014 15:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, 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 Crj5aKGVkXY4 for ; Sun, 30 Nov 2014 15:24:00 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338F31A1AB4 for ; Sun, 30 Nov 2014 15:23:59 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so7956835igd.7 for ; Sun, 30 Nov 2014 15:23:59 -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=S+ezWxMB5XgYlLdLjBwgo1XT06oSenPHTiEiVXJuGLY=; b=X8BQ5QhvHMyKWD6STyn3o94BNIVcuRE3HCdBbtmUZcbj/gCfLytiBs2e8Jzs8tk0MW TrsWAY1NnrGJRkUCnzivf5DzGDnlK7k89nyHr+C90Ugn2WbJpWlB2yU8aDaUMdbcbCPf LbRLuPNlTCoG32c8eDWcFm7r2LzSMGu7TZ5ciwgiobeNhDGMmoFozFu7BYCyvv5Sp+XO X/naMQbLKD7FMVHP0kPy55Ihq2VlZJ0kg60idQRrXvWcmw4hvPRuqsblB6MyRqeOSCgi xZC/yjX7dTHqf3Ir/FIbBXUXTRx4K98uWbHJ5wVWwL5znZk46WUmlbuBTzA6xSiIvR5V +tFg== X-Gm-Message-State: ALoCoQmxrpT7ylmsbNnu5geYrA+PA5MEWB8HjTgna9gm74Dx3UxTda+gv1/+l47ZFZWN0tVDIQ03 X-Received: by 10.107.156.211 with SMTP id f202mr1307820ioe.15.1417389839308; Sun, 30 Nov 2014 15:23:59 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id oq6sm14401678igb.2.2014.11.30.15.23.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Nov 2014 15:23:58 -0800 (PST) Message-ID: <547BA70D.8060208@andyet.net> Date: Sun, 30 Nov 2014 16:23:57 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke , Yoav Nir , Nico Williams References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> <547B99AC.4060109@gmx.de> <547B9AE0.4030301@andyet.net> <547BA19B.7010707@gmx.de> In-Reply-To: <547BA19B.7010707@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/kP08feLbjqbTO-CWC_dCrZx8Qio Cc: IETF HTTP Auth Subject: Re: [http-auth] Allowed Characters in usernames and passwords 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, 30 Nov 2014 23:24:02 -0000 On 11/30/14, 4:00 PM, Julian Reschke wrote: > On 2014-11-30 23:32, Peter Saint-Andre - &yet wrote: >> On 11/30/14, 3:26 PM, Julian Reschke wrote: >>> On 2014-11-25 21:08, Yoav Nir wrote: >>>> >>>>> On Nov 25, 2014, at 10:02 PM, Nico Williams >>>>> wrote: >>>>> >>>>> On Tue, Nov 25, 2014 at 1:56 PM, Yoav Nir wrote: >>>>>> To re-summarize, the proposal was that servers MUST support >>>>>> usernames and passwords compliant with saslprepbis, and MAY support >>>>>> non-compliant characters (except for specialized requirements such >>>>>> as those around colon). >>>>> >>>>> What does this mean? That the client MAY/SHOULD/MUST prep the thing? >>>>> How would the server know if the thing is prep'ed with saslprepbis (if >>>>> not by applying the prep itself)? What would it mean for the server >>>>> to not "support usernames and passwords compliant with saslprepbis”? >>>> >>>> The discussion was about the profiles for usernames and passwords in >>>> sections 3.2 and 4.2 respectively of >>>> https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-10 . >>> >>> In draft-11, there's a choice of "UsernameCaseMapped" and >>> "UsernameCasePreserved" >> >> Yes, I added the options so that we'd all have definitive options (and >> so that UsernameCaseMapped wasn't defined in an XMPP specification). >> >>> - I assume we'll choose the latter... >> >> Probably. >> >> Peter > > OK, for now I have this change > - note > that it only applies for the case where the server has advertised UTF-8 > support using the charset parameter. Yes, I had always assumed so. > Are we ok with this -- that is, can I submit a new draft and declare > victory? I think so. [1] Thanks for your patience and persistence! Peter [1] It is possible that we might try to consolidate or harmonize some of the profiles of the PRECIS FreeformClass, as we have done for profiles of the IdentifierClass. However, I expect that won't change the substance of the Password profile.