From nobody Mon Jan 5 08:11:26 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC031A1A59 for ; Mon, 5 Jan 2015 08:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2rnewKposhr for ; Mon, 5 Jan 2015 08:11:13 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FC81A1A3E for ; Mon, 5 Jan 2015 08:10:29 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id b13so17450300qcw.6 for ; Mon, 05 Jan 2015 08:10:29 -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=V2Rq7ECWVBfCEbCOkbey3dKQ+uuQm2l5Rq/KdkEtorE=; b=co1b7/3tPSJ3HVuuvkSYP4D1oxbTwIqFCp4KWpq+vqBXOBz8qCzG/JB6vJFzhoeab4 uCRS9rS6CQQIX9kTKeZlXYQLXv9JFRUbc2mySwdApp2+tJkevcrrHyqk9GuCKDSLTJl+ DaBGRqMucBn6Sm4MHjwIO6NmaRnn+gnZxFtMjcfVey47lYVPKVyUUsZqEeC4fLYmHoGD aX+9N5QeaDEr+8AGDGcWxPQz6cwHkUiFDYFqW8CEf32/fED2OaIKyNrc48A3rJj6R3Hm 4L+tao3KjjZrsyn//ixjbuxN9ZGnWwG9sE1xYPaH+nVtjhqrPQS1s6VfNhyCrorsPDBg xc4w== X-Gm-Message-State: ALoCoQleuygr2YW/Sq7xIXFmw72cgdiTXHBJcvqLrc73GRUFPPjYHQvGG0LqW9HoOKOyhrvnw/e/ X-Received: by 10.229.70.133 with SMTP id d5mr145562411qcj.2.1420474229033; Mon, 05 Jan 2015 08:10:29 -0800 (PST) From: Brett Tate References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGSVmlRjw6lmMHoV78JN3V4yMoSMwKcxgTDANZVfHICVcfQsQF0/olsnPNg00A= Date: Mon, 5 Jan 2015 11:10:27 -0500 Message-ID: <84507cffd01791c6fbc190c05c757d59@mail.gmail.com> To: Rifaat Shekh-Yusef , Julian Reschke , http-auth@ietf.org Content-Type: multipart/alternative; boundary=001a11339006d7200c050be9ed4a Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/rJCjqhbb3FmdzMx31O6BwNscIH0 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:11:19 -0000 --001a11339006d7200c050be9ed4a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Should draft-ietf-httpauth-digest-09 indicate how to remain interoperable (backward compatible) with RFC 2617 compliant devices? It seems like it should. For instance, isn=E2=80=99t that why RFC 7235 section 2.2 indicate= s the following concerning the realm? =E2=80=9CFor historical reasons, a sender MUST only generate the quoted-str= ing syntax.=E2=80=9D However if the working group doesn=E2=80=99t think that it is important, th= e vendors are likely smart enough to look at RFC 2617 if experiencing interoperability issues with older devices. Thanks, Brett *From:* Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] *Sent:* Saturday, December 20, 2014 10:43 AM *To:* Brett Tate *Cc:* Julian Reschke; http-auth@ietf.org *Subject:* Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt Hi Brett, Thanks for your review and comments. Please, see my reply inline... Regards, Rifaat On Mon, Dec 15, 2014 at 8:56 AM, Brett Tate wrote: Hi, Concerning the quoted-string ambiguity, I agree that the ambiguity still exists. Draft-ietf-httpauth-digest-09 did not address my quoted string general comment. http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html Was it not addressed because of working group discussion at IETF 91? If so, I have the same comment. The draft is not clear concerning when quoted strings MUST/SHOULD/MAY be used. For historical reasons, the resolution from a sender perspective should be backward compatible with RFC 2617 which used ABNF to clearly indicate the mandate. Yes, it was discussed. Here is a quote from the minutes: -- Quoted Strings Issue: Julian: I think the slide is probably correctly. However, do we know for sure if this is required for historical reasons? Better not to put edge cases into the spec if we don't need them Additional comments inline. > qop > Indicates what "quality of protection" the client has applied to > the message. Its value MUST be one of the alternatives the server > indicated it supports in the WWW-Authenticate header field. These > values affect the computation of the response. Note that this is a > single token, not a quoted list of alternatives as in WWW- > Authenticate. > > Can it use quoted-string nevertheless? Not if the draft/device wants to remain backward compatible with RFC 2617. Agree --001a11339006d7200c050be9ed4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= ,

=C2=A0=

Should draft-ietf-htt= pauth-digest-09 indicate how to remain interoperable (backward compatible) = with RFC 2617 compliant devices?=C2=A0 It seems like it should.=C2=A0 For i= nstance, isn=E2=80=99t that why RFC 7235 section 2.2 indicates the followin= g concerning the realm?

=C2=A0

=E2=80=9CFor historical reasons, a sender MUST only generate the quoted-st= ring syntax.=E2=80=9D

=C2=A0

H= owever if the working group doesn=E2=80=99t think that it is important, the= vendors are likely smart enough to look at RFC 2617 if experiencing intero= perability issues with older devices.

=C2=A0

Thanks,

Brett

= =C2=A0

From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com]
Sent: Saturday= , December 20, 2014 10:43 AM
To: Brett Tate
Cc: Julian = Reschke; http-auth@ietf.org
Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt=

=C2=A0

Hi Brett,

=C2=A0

Thanks for your review and comments.

Please, see my reply inline...

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Dec 15, 2014 at 8:56 AM, Brett Tate <brett@broadsoft.com> wrote:

Hi,

Concernin= g the quoted-string ambiguity, I agree that the ambiguity still
exists.<= br>
Draft-ietf-httpauth-digest-09 did not address my quoted string gener= al
comment.

http://www.ietf.org/mail-arch= ive/web/http-auth/current/msg01949.html

Was it not addressed bec= ause of working group discussion at IETF 91?=C2=A0 If
so, I have the sam= e comment.=C2=A0 The draft is not clear concerning when
quoted strings M= UST/SHOULD/MAY be used.=C2=A0 For historical reasons, the
resolution fro= m a sender perspective should be backward compatible with
RFC 2617 which= used ABNF to clearly indicate the mandate.

= =C2=A0

Yes, it was discussed.

Here is a quote from the minutes:

=C2=A0

-- Quoted Strings I=
ssue: 
=C2=A0
=C2=A0=C2=A0 Julian: I think the slide is prob= ably correctly. However, do we know for sure if this is required for histor= ical reasons?
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Better not to put edge cases =
into the spec if we don't need them

=C2=A0

=C2=A0

=C2=A0

Addi= tional comments inline.


>=C2=A0 =C2=A0 =C2=A0qop
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Indicates what "quality of protection" t= he client has applied to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the message. It= s value MUST be one of the alternatives the server
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 indicated it supports in the WWW-Authenticate header field. Thes= e
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 values affect the computation of the r= esponse. Note that this is
a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 single t= oken, not a quoted list of alternatives as in WWW-
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Authenticate.
>
> Can it use quoted-string neverthel= ess?

Not if the draft/device wants to remain backward compatible wit= h RFC 2617.

Agree

=C2=A0

=C2=A0

=C2=A0=

--001a11339006d7200c050be9ed4a-- From nobody Mon Jan 5 08:41:05 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68361A03B3 for ; Mon, 5 Jan 2015 08:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlAjIc62Gbas for ; Mon, 5 Jan 2015 08:40:57 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408181A038B for ; Mon, 5 Jan 2015 08:40:57 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so27863381wgg.19 for ; Mon, 05 Jan 2015 08:40:56 -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 :message-id:references:to; bh=hQjX96DYCG12RMN/uT3eAdISLFK2UrqYdVFJvFO1ydM=; b=IhLSLF+H8Ba2lOsfv/wlimkZJlHcOr7T2UglXujpSmMUIPDxs+IttaWV4sER+nuYMs cZuTd2Ho6jJ4b96c8h1g3+jyvir9MMIEfLyZtN86gPXTDjuotvL98ERPaCtjTpsy6LVw pB8PTtNaiwx+m3vfCOHbJIrfdYNGJPBwaCR7zdE9O2BogGc/iZ6glNZiQy0avUIJe+Hq 52nN5K/Gcw9FqUgjekZ7n05ZPATb8AJeUj8fIW2vTNx7DdiBy4mdXtFK+InEWfrJeZED WnXq8pJQJULUe6Dmw1A44q7q6qjpOEIDdT5JlVlJdYVKrfSrLYDbGlzoK5EU3wgSumD8 aSXg== X-Received: by 10.194.188.13 with SMTP id fw13mr176970114wjc.83.1420476055927; Mon, 05 Jan 2015 08:40:55 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.12.145.22]) by mx.google.com with ESMTPSA id dn2sm10540568wib.14.2015.01.05.08.40.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Jan 2015 08:40:55 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C77583AC-75F7-45EE-84FD-B10167C20E3B" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <84507cffd01791c6fbc190c05c757d59@mail.gmail.com> Date: Mon, 5 Jan 2015 18:40:51 +0200 Message-Id: References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> <84507cffd01791c6fbc190c05c757d59@mail.gmail.com> To: Brett Tate X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/c9ZwpzoRCzHzCWCypyA7BfXoktg Cc: Julian Reschke , http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:40:59 -0000 --Apple-Mail=_C77583AC-75F7-45EE-84FD-B10167C20E3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think it=E2=80=99s obvious that backward compatibility is important. = If you are deploying something new with no legacy implementations = around, you are not going to pick Basic or Digest (I hope). The point of = Digest is to keep implementations functioning when the crypto library = removes MD5 and when the password database suddenly contains names and = passwords with non-ASCII characters. Yoav > On Jan 5, 2015, at 6:10 PM, Brett Tate wrote: >=20 > Hi, > =20 > Should draft-ietf-httpauth-digest-09 indicate how to remain = interoperable (backward compatible) with RFC 2617 compliant devices? It = seems like it should. For instance, isn=E2=80=99t that why RFC 7235 = section 2.2 indicates the following concerning the realm? > =20 > =E2=80=9CFor historical reasons, a sender MUST only generate the = quoted-string syntax.=E2=80=9D > =20 > However if the working group doesn=E2=80=99t think that it is = important, the vendors are likely smart enough to look at RFC 2617 if = experiencing interoperability issues with older devices. > =20 > Thanks, > Brett > =20 > From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com = ]=20 > Sent: Saturday, December 20, 2014 10:43 AM > To: Brett Tate > Cc: Julian Reschke; http-auth@ietf.org > Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt > =20 > Hi Brett, > =20 > Thanks for your review and comments. > Please, see my reply inline... > =20 > Regards, > Rifaat > =20 > =20 > On Mon, Dec 15, 2014 at 8:56 AM, Brett Tate > wrote: > Hi, >=20 > Concerning the quoted-string ambiguity, I agree that the ambiguity = still > exists. >=20 > Draft-ietf-httpauth-digest-09 did not address my quoted string general > comment. >=20 > http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html = >=20 > Was it not addressed because of working group discussion at IETF 91? = If > so, I have the same comment. The draft is not clear concerning when > quoted strings MUST/SHOULD/MAY be used. For historical reasons, the > resolution from a sender perspective should be backward compatible = with > RFC 2617 which used ABNF to clearly indicate the mandate. >=20 > =20 > Yes, it was discussed. > Here is a quote from the minutes: > =20 > -- Quoted Strings Issue:=20 > =20 > Julian: I think the slide is probably correctly. However, do we = know for sure if this is required for historical reasons? > Better not to put edge cases into the spec if we don't need = them > =20 > =20 > =20 >> Additional comments inline. >>=20 >>=20 >> > qop >> > Indicates what "quality of protection" the client has = applied to >> > the message. Its value MUST be one of the alternatives the = server >> > indicated it supports in the WWW-Authenticate header field. = These >> > values affect the computation of the response. Note that = this is >> a >> > single token, not a quoted list of alternatives as in WWW- >> > Authenticate. >> > >> > Can it use quoted-string nevertheless? >>=20 >> Not if the draft/device wants to remain backward compatible with RFC = 2617. >>=20 > Agree > =20 > =20 > =20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth --Apple-Mail=_C77583AC-75F7-45EE-84FD-B10167C20E3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <no hats>

I think it=E2=80=99s obvious that backward compatibility is = important. If you are deploying something new with no legacy = implementations around, you are not going to pick Basic or Digest (I = hope). The point of Digest is to keep implementations functioning when = the crypto library removes MD5 and when the password database suddenly = contains names and passwords with non-ASCII characters.

Yoav

On Jan 5, 2015, at 6:10 PM, Brett Tate <brett@broadsoft.com>= wrote:

Hi,

 

Should draft-ietf-httpauth-digest-09 = indicate how to remain interoperable (backward compatible) with RFC 2617 = compliant devices?  It seems like it should.  For instance, = isn=E2=80=99t that why RFC 7235 section 2.2 indicates the following = concerning the realm?

 

=E2=80=9CFor historical reasons, a sender MUST only generate = the quoted-string syntax.=E2=80=9D

 

However if the working group doesn=E2=80=99t= think that it is important, the vendors are likely smart enough to look = at RFC 2617 if experiencing interoperability issues with older = devices.

 

Thanks,
Brett

 

From: Rifaat Shekh-Yusef = [mailto:rifaat.ietf@gmail.com] 
Sent: Saturday, December 20, 2014 = 10:43 AM
To: Brett Tate
Cc: Julian Reschke; http-auth@ietf.org
Subject: Re: [http-auth] I-D Action: = draft-ietf-httpauth-digest-09.txt

 

Hi Brett,

 

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

 

Regards,
 Rifaat

 

 

On Mon, Dec 15, 2014 at 8:56 AM, Brett Tate <brett@broadsoft.com> wrote:

Hi,

Concerning the = quoted-string ambiguity, I agree that the ambiguity still
exists.

Draft-ietf-httpauth-digest-09 did not address my quoted = string general
comment.

http://www.ietf.org/mail-archive/web/http-auth/current/msg01949= .html

Was it not addressed because of = working group discussion at IETF 91?  If
so, I have = the same comment.  The draft is not clear concerning when
quoted strings MUST/SHOULD/MAY be used.  For historical = reasons, the
resolution from a sender perspective should = be backward compatible with
RFC 2617 which used ABNF to = clearly indicate the mandate.

 

Yes, it was discussed.
Here is a quote from the = minutes:

 

-- Quoted Strings Issue: 
 
   =
Julian: I think the slide is probably correctly. However, do we know for =
sure if this is required for historical reasons?
           =
Better not to put edge cases into the spec if we don't need =
them

 

 

 

Additional comments inline.


>     qop
>        Indicates what "quality of = protection" the client has applied to
>    =     the message. Its value MUST be one of the alternatives the = server
>        indicated it = supports in the WWW-Authenticate header field. These
>        values affect the computation = of the response. Note that this is
a
>        single token, not a quoted = list of alternatives as in WWW-
>      =   Authenticate.
>
> Can it use = quoted-string nevertheless?

Not if the = draft/device wants to remain backward compatible with RFC = 2617.

Agree

 

 

 

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

= --Apple-Mail=_C77583AC-75F7-45EE-84FD-B10167C20E3B-- From nobody Mon Jan 5 09:49:02 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CD91A871E; Mon, 5 Jan 2015 09:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 MPQB5Nx7YFSk; Mon, 5 Jan 2015 09:48:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E73421A6F3A; Mon, 5 Jan 2015 09:48:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 09:48:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/8HRnZRRcnjV8jjLKjT3sF_akVZw Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:49:00 -0000 Barry Leiba has entered the following ballot position for draft-ietf-httpauth-hoba-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Point 1: I find the document to be really unclear about who does what with which and to whom and.... I gather that what happens is that the challenge is sent as part of the www-authenticate header, and that the client sends a HOBA-RES back to the server in an authorization header. I don't see the point of the HOBA-TBS at all: it looks like it's that the "sig" in the HOBA-RES is a signed version of the HOBA-TBS, but I don't see anything that says that clearly. This document would benefit from some section somewhere giving a set of clear, numbered steps, saying who sends, who receives, and who does what with what input at each step. I don't find Section 5 to be doing that at all. "the client authenticates by signing a blob of information as described in the previous sections," still leaves me wondering what blob was signed, and sent how. And yes, I see that "blob" is used elsewhere, but it's not a technical term. Some other, easier-to-deal-with things for discussion, some of which might just involve small clarifications (or an explanation to me that results in my slapping my own forehead): -- Section 2 -- In the ABNF for HOBA-TBS, is something supposed to be between the elements? If not, how do I know when the base64 value for nonce ends and the length value for alg begins? -- Section 6.3 -- The server SHOULD also revoke or delete any cookies associated with the session. Why is that not MUST? How good is a "logout" if stolen cookies from that session can still be reused? -- Section 6.4 -- Protocol: does asking for and getting a new challenge affect the session state? The document should be clear about what happens, rather than just saying that the client can ask for a new challenge. Is it like a logout and re-login? Or what? -- Section 8.2 -- I don't think you need to say "a la LinkedIn," and I think it's a bad idea to have us link a company's name to a password compromise forever in an RFC. Especially when it's not necessary. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor editorial nit: you use "a HOBA" fairly consistently, but "an HOBA" appears twice. Oughta fix. The abstract appears to overstate the password issue. It'd be better for the abstract to say that it eliminates the transmission of passwords and their storage on the server, which are really the points. The introduction might expand on that a little, noting that passwords might still be used in the user interfaces, but they would be exclusively client-side things, never transmitted and never seen by servers. Note that the rest of these notes were entered as I read the document from top to bottom. That means that some things got explained later, and that leads to the DISCUSS point about the document's organization and having a clear step-by-step run-through. -- Section 2 -- The definition of "alg" says "the encoding of RSA-SHA256 is 0x30," but the ABNF above says "alg = 1*2DIGIT", which implies "30", not "0x30". As I look at Section 9.3, I think I see the problem and my confusion. I don't think you want "a single octet" here (otherwise, how would you encode 12 or 99? Don't you really want something like this?: OLD o alg: specifies the signature algorithm being used encoded as a single octet as defined in Section 9.3. RSA-SHA256 MUST be supported, RSA-SHA1 MAY be supported. The IANA registered algorithm values are encoded as ASCII numbers; for example, the encoding of RSA-SHA256 is 0x30. NEW o alg: specifies the signature algorithm being used. RSA-SHA256 MUST be supported, RSA-SHA1 MAY be supported. The IANA registered algorithm values (see Section 9.3) are encoded as one- or two-digit ASCII numbers. For example, RSA-SHA256 (number 0) is encoded as the ASCII character "0" (0x30), while a future algorithm registered as number 17 would be encoded as the ASCII characters "17" (0x3137). END For "realm", I can't really make sense of "Recall both sides know when this needs to be there independent of the encoding via a zero length." Can you rephrase and/or repunctuate this (probably without the word "recall")? For "challenge", I'm not completely sure what the SHOULD part of this is meaning to say: The challenge MUST be chosen so that it is infeasible to guess, and SHOULD be indistinguishable from (the base64url encoding of) an at least 128-bit long random string. My guess is that you're saying that, say, "frxM7jEplDq" meets the SHOULD, while "eat my shorts" doesn't (extend to 128 bits in your mind). I get that, but it's dicey, random-wise, because it implies that "eat my shorts" can't come up randomly, and (here's the really dicey part) I should refuse to use it if it does. I wouldn't worry about this but for the SHOULD; with the SHOULD, I'm not sure how I can be sure that I comply with it. This section is really unclear about who does what with which and to whom and.... I gather that what happens is that the challenge is sent as part of the www-authenticate header, and that the client sends a HOBA-RES back to the server in an authorization header. I don't see the point of the HOBA-TBS at all. Perhaps it's that the "sig" in the HOBA-RES is a signed version of the HOBA-TBS, but I don't see anything that says that, anywhere. This document would benefit from some section somewhere giving a set of clear, numbered steps, saying who sends, who receives, and who does what with what input at each step. I don't find Section 5 to be doing that at all. "the client authenticates by signing a blob of information as described in the previous sections," still leaves me wondering what blob was signed, and sent how. And yes, I see that "blob" is used elsewhere, but it's not a technical term. -- Section 3 -- The "realm" attribute MUST NOT appear more than once. Does that mean that "challenge" and max-age can appear more than once? If not, why call it out for "realm" and not for the others? It might be good if the description of "max-age" made it clear that it's for the purpose of allowing multiple uses (multiple sigs). As it is, it looks like it's there to limit the delay before the challenge is answered (once). Maybe just a forward ref to Section 8 is good enough here. -- Section 4 -- The second paragraph starts by saying that localStorage is required, and gives a reference. It ends by saying that localStorage is not required, because IndexedDB works too, and it gives a reference. That's not a disaster, but it's sloppy, and it'd be better to say it all up front. It also makes me wonder whether the security considerations about attacks on localStorage do or don't also apply to IndexedDB. Another very minor point: I would avoid using "a hassle for users" in an international document that non-native speakers are expected to understand. "Difficult for users" seems just as good and more understandable to all. Does the server really use session cookies to navigate around a site? Or does the server give the client a session cookie for the client to use to navigate? -- Section 5.3 -- How Does the server "recognize the CPK"? I can't find anything that tells me how the kid relates to the CPK. I also don't see how the server gets the CPK in the first place. I realize that setting up the user's account isn't part of HOBA, but the setup requirements need to be explained, and I don't think they are. The organization is also very odd, only talking about "joining" the user after it talks about validating the sig. -- Section 6 -- Oh, no wait: the joining is part of the standard. And the subsections here answer the question I asked in 5.3 about how the CPK gets set up. Gaaaaa! PLEASE reorganise this document! -- Section 6.1 -- Why are the fields here not REQUIRED and OPTIONAL, using 2119 words, as is the case in Section 3? -- Section 6.2 -- It seems odd to put the NOT RECOMMENDED mechanism in the middle; I suggest switching sections 6.2.2 and 6.2.3. -- Section 8 -- The first paragraph doesn't say enough to make sense to me. Perhaps a few more words about why? The administrator will most likely want to set the max-age to something that is not too slow on the slowest signing device that is significant for that site. Maybe you mean "not too short"? -- Section 8.2 -- As to the "counter-intuitive" part, see my earlier comment about what the introduction says about not using passwords. -- Section 8.3 -- The chances that a typical user (consider my mother) will know or care about this, much less will "request" anything is vanishingly small. Can you say anything here about what can be done that would have any practical utility? -- Section 9.3 -- Please create a new HOBA signature algorithms registry as follows, with the specification required rule for updates. New HOBA signature algorithms SHOULD be in use with other IETF standards track protocols before being added to this registry. I don't think the SHOULD is really right -- who is the target? This needs to be cast as instructions to the designated expert, perhaps as, "The designated expert will review other uses of requested new HOBA signature algorithms, with particular consideration to their use in other IETF standards track protocols." Perhaps there's also another word or two to say about what the DE should consider? -- Sections 9.4 and 9.5 -- Surely, IANA (or the designated expert) will want to have some idea of how high "small" might reasonably get. Can you put any bound on it, even a non-binding one? And might there be any other advice for the designated expert, anything at all? From nobody Mon Jan 5 11:59:05 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D948F1A894B; Mon, 5 Jan 2015 11:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM5INU1KVDq9; Mon, 5 Jan 2015 11:58:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477511A8A3C; Mon, 5 Jan 2015 11:45:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0E429BEC6; Mon, 5 Jan 2015 19:45:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLBpiDpHhnh1; Mon, 5 Jan 2015 19:45:12 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D4D4BE97; Mon, 5 Jan 2015 19:45:12 +0000 (GMT) Message-ID: <54AAE9C7.8010105@cs.tcd.ie> Date: Mon, 05 Jan 2015 19:45:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> In-Reply-To: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/KlgIpRKuPZjBuEZECGdPCn_poV4 Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 19:58:58 -0000 Hi Barry, (I'm sure it's obvious, but this is me-as-author responding...) On 05/01/15 17:48, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-httpauth-hoba-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Point 1: > I find the document to be really unclear about who does what with which > and to whom and.... That's very odd. We've had a bunch of reviews and an independent implementation (I've not done an interop though) and you're the first to make such a comment I think. The draft assumes familiarity with the HTTP authentication framework (RFC7235) for sure and (100% correctly I'd say) doesn't repeat any of that as any implementer really has to know that before they start. That's stated in the abstract and the very first sentence of section 1 so I'm very unclear what else is needed. And given that the responsible AD for RFC7235 was one Barry Leiba, I'm very very puzzled as to how this is not clear to you. > I gather that what happens is that the challenge is > sent as part of the www-authenticate header, and that the client sends a > HOBA-RES back to the server in an authorization header. That's all as per 7235. > I don't see the > point of the HOBA-TBS at all: it looks like it's that the "sig" in the > HOBA-RES is a signed version of the HOBA-TBS, but I don't see anything > that says that clearly. Section 2: "On receipt of a challenge (and optional realm) from a server, the client marshals an HOBA to-be-signed (TBS) blob that includes a client generated nonce, the web-origin, the realm, an identifier for the CPK and the challenge string; and signs that blob with the private key corresponding to the CPK for that web-origin." I don't see what is not clear there sorry. > > This document would benefit from some section somewhere giving a set of > clear, numbered steps, saying who sends, who receives, and who does what > with what input at each step. That's in RFC 7235. > I don't find Section 5 to be doing that at > all. "the client authenticates by signing a blob of information as > described in the previous sections," still leaves me wondering what blob > was signed, and sent how. And yes, I see that "blob" is used elsewhere, > but it's not a technical term. See above. > > Some other, easier-to-deal-with things for discussion, some of which > might just involve small clarifications (or an explanation to me that > results in my slapping my own forehead): Hopefully, your forehead is already shiny:-) > > -- Section 2 -- > > In the ABNF for HOBA-TBS, is something supposed to be between the > elements? If not, how do I know when the base64 value for nonce ends and > the length value for alg begins? The previous len field tells you. > > -- Section 6.3 -- > > The server SHOULD also revoke or delete any cookies associated with > the session. > > Why is that not MUST? How good is a "logout" if stolen cookies from that > session can still be reused? The issue is that that function (revoke cookie) might not be available to the HOBA code, or it might, depending on the kind of HTTP server implementation. > > -- Section 6.4 -- > > Protocol: does asking for and getting a new challenge affect the session > state? The document should be clear about what happens, rather than just > saying that the client can ask for a new challenge. Is it like a logout > and re-login? Or what? No there's no effect on any other state I think. The point of this is just to get a fresh challenge if the one you had has expired or whatever. > > -- Section 8.2 -- > > I don't think you need to say "a la LinkedIn," and I think it's a bad > idea to have us link a company's name to a password compromise forever in > an RFC. Especially when it's not necessary. Is that really DISCUSS worthy? I don't think it is. Which of the DISCUSS criteria relate to that. Seems like a stylistic thing to me. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Minor editorial nit: you use "a HOBA" fairly consistently, but "an HOBA" > appears twice. Oughta fix. Will check. But RFC editor would fix I'm sure. I'll fix if a -10 is needed now. > > The abstract appears to overstate the password issue. It'd be better for > the abstract to say that it eliminates the transmission of passwords and > their storage on the server, which are really the points. The > introduction might expand on that a little, noting that passwords might > still be used in the user interfaces, but they would be exclusively > client-side things, never transmitted and never seen by servers. I'll take that under advisement. > > Note that the rest of these notes were entered as I read the document > from top to bottom. That means that some things got explained later, and > that leads to the DISCUSS point about the document's organization and > having a clear step-by-step run-through. > > -- Section 2 -- > > The definition of "alg" says "the encoding of RSA-SHA256 is 0x30," but > the ABNF above says "alg = 1*2DIGIT", which implies "30", not "0x30". > As I look at Section 9.3, I think I see the problem and my confusion. I > don't think you want "a single octet" here (otherwise, how would you > encode 12 or 99? Don't you really want something like this?: Yep, I think you're right there. > > OLD > o alg: specifies the signature algorithm being used encoded as a > single octet as defined in Section 9.3. RSA-SHA256 MUST be > supported, RSA-SHA1 MAY be supported. The IANA registered > algorithm values are encoded as ASCII numbers; for example, the > encoding of RSA-SHA256 is 0x30. > NEW > o alg: specifies the signature algorithm being used. RSA-SHA256 > MUST be supported, RSA-SHA1 MAY be supported. The IANA > registered algorithm values (see Section 9.3) are encoded as one- > or two-digit ASCII numbers. For example, RSA-SHA256 (number > 0) is encoded as the ASCII character "0" (0x30), while a future > algorithm registered as number 17 would be encoded as the > ASCII characters "17" (0x3137). Wilko. I have that in my editor copy. > END > > For "realm", I can't really make sense of "Recall both sides know when > this needs to be there independent of the encoding via a zero length." > Can you rephrase and/or repunctuate this (probably without the word > "recall")? Sorry what's not clear? > > For "challenge", I'm not completely sure what the SHOULD part of this is > meaning to say: > > The challenge MUST be chosen > so that it is infeasible to guess, and SHOULD be indistinguishable > from (the base64url encoding of) an at least 128-bit long random > string. The challenge might be shorter, or might be encoded in some other way e.g. double encoding or something. All are reasonable, none affect interop but we wanted to get the "at least" in there. > > My guess is that you're saying that, say, "frxM7jEplDq" meets the SHOULD, > while "eat my shorts" doesn't (extend to 128 bits in your mind). I get > that, but it's dicey, random-wise, because it implies that "eat my > shorts" can't come up randomly, and (here's the really dicey part) I > should refuse to use it if it does. I wouldn't worry about this but for > the SHOULD; with the SHOULD, I'm not sure how I can be sure that I comply > with it. > > This section is really unclear about who does what with which and to whom > and.... I gather that what happens is that the challenge is sent as part > of the www-authenticate header, and that the client sends a HOBA-RES back > to the server in an authorization header. I don't see the point of the > HOBA-TBS at all. Perhaps it's that the "sig" in the HOBA-RES is a signed > version of the HOBA-TBS, but I don't see anything that says that, > anywhere. See RFC7235. > > This document would benefit from some section somewhere giving a set of > clear, numbered steps, saying who sends, who receives, and who does what > with what input at each step. I don't find Section 5 to be doing that at > all. "the client authenticates by signing a blob of information as > described in the previous sections," still leaves me wondering what blob > was signed, and sent how. And yes, I see that "blob" is used elsewhere, > but it's not a technical term. See RFC7235. > > -- Section 3 -- > > The "realm" attribute MUST NOT appear more than once. > > Does that mean that "challenge" and max-age can appear more than once? > If not, why call it out for "realm" and not for the others? I forget TBH. I think it may be some buggy stuff seen with Basic or Digest in the past. Or it might have been me keeping Julian as happy as I could;-) > It might be good if the description of "max-age" made it clear that it's > for the purpose of allowing multiple uses (multiple sigs). As it is, it > looks like it's there to limit the delay before the challenge is answered > (once). Maybe just a forward ref to Section 8 is good enough here. I think it's clear to be honest. > > -- Section 4 -- > > The second paragraph starts by saying that localStorage is required, and > gives a reference. It ends by saying that localStorage is not required, > because IndexedDB works too, and it gives a reference. That's not a > disaster, but it's sloppy, and it'd be better to say it all up front. It > also makes me wonder whether the security considerations about attacks on > localStorage do or don't also apply to IndexedDB. I'll take a look again - localStorage is needed if you do not have WebCrypto. IndexedDB is needed if you do have WebCrypto. > > Another very minor point: I would avoid using "a hassle for users" in an > international document that non-native speakers are expected to > understand. "Difficult for users" seems just as good and more > understandable to all. > > Does the server really use session cookies to navigate around a site? Or > does the server give the client a session cookie for the client to use to > navigate? I think it's clearer as-is to be honest. > > -- Section 5.3 -- > > How Does the server "recognize the CPK"? I can't find anything that > tells me how the kid relates to the CPK. It's not clear how a key identifier (kid) relates to a client public key? (CPK) Really? A kid identifies the CPK in the nominal case. This is crypto 101 though and ought not be there unless there's a specific ambiguity which I don't think is the case. > I also don't see how the server > gets the CPK in the first place. I realize that setting up the user's > account isn't part of HOBA, but the setup requirements need to be > explained, and I don't think they are. The organization is also very > odd, only talking about "joining" the user after it talks about > validating the sig. I don't believe anyone else has had that problem. And explaining the HTTP mechanism first seems appropriate here as that is the core thing. > > -- Section 6 -- > > Oh, no wait: the joining is part of the standard. And the subsections > here answer the question I asked in 5.3 about how the CPK gets set up. > Gaaaaa! PLEASE reorganise this document! Even though nobody else has had that problem? > > -- Section 6.1 -- > > Why are the fields here not REQUIRED and OPTIONAL, using 2119 words, as > is the case in Section 3? Sorry I don't see a problem. > > -- Section 6.2 -- > > It seems odd to put the NOT RECOMMENDED mechanism in the middle; I > suggest switching sections 6.2.2 and 6.2.3. I'm fine with it as-is to be honest. > > -- Section 8 -- > > The first paragraph doesn't say enough to make sense to me. Perhaps a > few more words about why? Will look at it. > > The administrator will most likely > want to set the max-age to something that is not too slow on the > slowest signing device that is significant for that site. > > Maybe you mean "not too short"? Nope. If signing took 2 seconds a 1 second max-age would be a problem. And that can happen with very old JS engines. Will go away over time and is nearly gone now. (Much moreso than when -00 of this was done.) > > -- Section 8.2 -- > > As to the "counter-intuitive" part, see my earlier comment about what the > introduction says about not using passwords. I don't get what you mean to be honest. > > -- Section 8.3 -- > The chances that a typical user (consider my mother) will know or care > about this, much less will "request" anything is vanishingly small. Can > you say anything here about what can be done that would have any > practical utility? This text is for a developer, not a user. And I have been asked about this feature a number of times by people who don't get the not-that-hidden complexities. > > -- Section 9.3 -- > > Please create a new HOBA signature algorithms registry as follows, > with the specification required rule for updates. New HOBA signature > algorithms SHOULD be in use with other IETF standards track protocols > before being added to this registry. > > I don't think the SHOULD is really right -- who is the target? This > needs to be cast as instructions to the designated expert, perhaps as, > "The designated expert will review other uses of requested new HOBA > signature algorithms, with particular consideration to their use in other > IETF standards track protocols." Perhaps there's also another word or > two to say about what the DE should consider? Sorry I don't get what's unclear. The SHOULD is targetted at the DE. The text you suggest(?) in quotes would be less clear I think. > -- Sections 9.4 and 9.5 -- > Surely, IANA (or the designated expert) will want to have some idea of > how high "small" might reasonably get. Can you put any bound on it, even > a non-binding one? And might there be any other advice for the > designated expert, anything at all? Really? Are we seriously worried about there being a bazillion key id algs or device id types in an experimental RFC? I am not. Cheers, S. > > From nobody Mon Jan 5 19:01:38 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E94B1A0E10; Mon, 5 Jan 2015 19:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwd_SlQBX0u6; Mon, 5 Jan 2015 19:01:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31211A038F; Mon, 5 Jan 2015 19:01:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9F32CBEC0; Tue, 6 Jan 2015 03:01:23 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wto_9dOW58kX; Tue, 6 Jan 2015 03:01:20 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8710FBEBC; Tue, 6 Jan 2015 03:01:20 +0000 (GMT) Message-ID: <54AB4FFF.4040402@cs.tcd.ie> Date: Tue, 06 Jan 2015 03:01:19 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> In-Reply-To: <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/hpWETEPLzpHUvO_Z2Ef8TeobDrI Cc: "httpauth-chairs@tools.ietf.org" , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , The IESG , Barry Leiba Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 03:01:31 -0000 On 06/01/15 01:26, Barry Leiba wrote: > (Temporarily responding from my huawei.com address, as China blocks > gmail.) No probs, I'm sure we'll sort this and the gfw delays won't be that much of a deal. > >>> Point 1: I find the document to be really unclear about who does >>> what with which and to whom and.... >> >> That's very odd. We've had a bunch of reviews and an independent >> implementation (I've not done an interop though) and you're the >> first to make such a comment I think. The draft assumes >> familiarity with the HTTP authentication framework (RFC7235) for >> sure and (100% correctly I'd say) doesn't repeat any of that as any >> implementer really has to know that before they start. That's >> stated in the abstract and the very first sentence of section 1 so >> I'm very unclear what else is needed. And given that the >> responsible AD for RFC7235 was one Barry Leiba, I'm very very >> puzzled as to how this is not clear to you. > > I'll take that last sentence as less snarky than it sounds, Not snark, but genuine puzzlement. From my POV you're asking for this document to include crypto101 stuff. Yet we deal with far more complex protocols that use the same (or more complex) constructs all the time without requiring any of that. And wrt the step-by-step stuff there's even a properly referenced framework document that you brought to the IESG only months ago that sets out exactly what your're asking be repeated here (or else 7235 is broken). I just do not get it. Maybe it's hard to be so puzzled without sounding snarky, but I genuinely don't think we have a problem here as I just can't really grok that you'd be asking for these kinds of change in an experimental RFC and that those would really be blocking. > and I'll > point out that I'm not reviewing this based on what Barry Leiba > personally knows and understands, but on whether people reading the > spec can understand it. But it's been independently implemented by the portugal telecom folks without them ever asking (me anyway) a single question. And reviewed by multiple folks so I honestly think you may be the exception here. And see above wrt puzzlement;-) > Let's also keep in mind that people implementing this sort of thing > will have more or less expertise in the HTTP authentication > framework, and the document needs to be understandable to those who > are less expert. 101 != expert. foo-TBS being the signature input really is 101. > Also also remember that we're hoping to get > implementations of this out there, and we're skeptical that it'll > happen. Anything that makes it easier helps that cause. I don't accept that logic (though it's an aside), that'd call for explaining RSA for example, which would be just as wrong (IMO) as re-capitulating 7235 content. (Do you think it would be a good plan for every http-auth WG doc to do that btw? Will you post a DISCUSS position on all of those on that basis? That's not something for HOBA, but maybe worth a ponder.) > For all > that, I think more explanation is important. Clearly. And I think attempt to regurgitate text from a properly referenced framework RFC in this one (and possibly others) would be an error. > > Despite what I know, I really did find myself tripping over things > because there's no overall description of the flow, including things > that are unique to HOBA (such as the HOBA-TBS, and the joining > protocol). For anyone who has implemented any signature based anything HOBA-TBS is utterly obvious and far from unique. There'a >30 year heritage of protocol constructs like that going back (to my knowledge, but I'm sure further) to the 1984 X.400 blue-book which had a couple of pages of text that became the 1988 X.509 that eventually became RFC 5280. The joining protocol is just a simple signed assertion entirely analagous to a PKCS#10 structure (so not quite 30 years old, maybe 20+:-). In my local cache of RFCs (7376 being the hightest numbered) I see 69 RFCs that contain the case-insensitive string TBS btw. Really, there is nothing new here. (And deliberately so, for any new feature that even smelled remotely of novelty I went and tried to find a >20 year old reference.) An implementer who is not aware of that heritage will also not have a problem, or else will have far far worse problems. The younger but not dim implementer will just use openssl or some library that handles this stuff more or less well or badly for the programmer and will find that the text here matches the kinds of example one finds on stackexchange etc fairly closely (since that's where I got my PHP and JS code snippets while coding this and writing this text). Honestly, I'm just genuinely puzzled a lot that any of this is seen as worth asking never mind DISCUSS-worthy. (Could it be that HOBA doesn't have enough complexity and is therefore more amenable to such commentary, say compared to RELOAD which is much more complex cryptographically? Well, if so, I guess that's a good thing in a way:-) > >> Section 2: >> >> "On receipt of a challenge (and optional realm) from a server, the >> client marshals an HOBA to-be-signed (TBS) blob that includes a >> client generated nonce, the web-origin, the realm, an identifier >> for the CPK and the challenge string; and signs that blob with the >> private key corresponding to the CPK for that web-origin." >> >> I don't see what is not clear there sorry. > > There's nothing that I see that explicitly makes that the "sig" item > in the HOBA-RES. See above wrt puzzlement. You're really missing that the output of the "signs" operation is the sig value? >>> This document would benefit from some section somewhere giving a >>> set of clear, numbered steps, saying who sends, who receives, and >>> who does what with what input at each step. >> >> That's in RFC 7235. > > And should be in here, as well, to make it clear how the details of > HOBA fit into the framework. Fully disagree. And the author of 7235 who did review this did not suggest that iirc. This should and does correctly require that the implementer has read or is otherwise familiar with 7235. (What you want would also call for every http-auth WG output to include that kind of regurgitation. It's just a bad idea.) > > I don't think this is a big deal, and I will > > 1. move this to a non-blocking comment, and > > 2. suggest text for you to include. Fair enough. Absent that being better text, I'll likely argue to not change. But I know you might produce better text so we'll see:-) > >>> In the ABNF for HOBA-TBS, is something supposed to be between >>> the elements? If not, how do I know when the base64 value for >>> nonce ends and the length value for alg begins? >> >> The previous len field tells you. > > DOH! Yeh, of course. Sorry. > >>> -- Section 6.3 -- >>> >>> The server SHOULD also revoke or delete any cookies associated >>> with the session. >>> >>> Why is that not MUST? How good is a "logout" if stolen cookies >>> from that session can still be reused? >> >> The issue is that that function (revoke cookie) might not be >> available to the HOBA code, or it might, depending on the kind of >> HTTP server implementation. > > This is something we often struggle with, but I think it's a bad idea > to soften the way we want a protocol to work because we know it will > be difficult for some implementations. We should use MUST or SHOULD > based on what's right, and accept that even MUST will not be complied > with if an implementation can't comply. > > Do we really want this to be a MUST? Perhaps we can waffle slightly > by saying "MUST ... if it is possible to do so in the relevant HTTP > server," or some such? The way I look at this is in the spirit of the just issued RFC 7435. We have little enough chance of this working so we ought (esp at the experimental RFC stage) lean over to make deployment easier and not harder. So I do think SHOULD is right there tbh. > >>> -- Section 6.4 -- >>> >>> Protocol: does asking for and getting a new challenge affect the >>> session state? The document should be clear about what happens, >>> rather than just saying that the client can ask for a new >>> challenge. Is it like a logout and re-login? Or what? >> >> No there's no effect on any other state I think. The point of this >> is just to get a fresh challenge if the one you had has expired or >> whatever. > > OK; discussion has been had on this item. > > Would it be worth adding a few words to say that (and to say that the > session state doesn't change)? That could be worse than now. Since a lot of the client code here will be async code (XHR now and promises soon) we don't actually know that that'll be the case. Other stuff might be going on as one branch of code is refreshing the challenge. > >>> -- Section 8.2 -- >>> >>> I don't think you need to say "a la LinkedIn," and I think it's a >>> bad idea to have us link a company's name to a password >>> compromise forever in an RFC. Especially when it's not >>> necessary. >> >> Is that really DISCUSS worthy? I don't think it is. Which of the >> DISCUSS criteria relate to that. Seems like a stylistic thing to >> me. > > I think it is: I think it's a very bad thing to disparage specific > companies in our RFCs. Its a statement of fact though. That is very different. > That said, if you'd actually discuss Rhetorical fail alert:-) That last use of "discuss" != DISCUSS-worthy. You're ignoring a) that this is a style issue and explicitly not DISCUSS-worthy and b) that I am in fact happy to discus your non-blocking comments. I think it's entirely fair to establish if a point does or does not warrant being blocking before disposing of the detail. (And hey, when did an author not want to demote a DISCUSS to a COMMENT if that is fair-game? Not often.:-) > this with me (why you think it's > important to leave it there), then the discussion will have happened, > and we can move ahead. Facts are much more convincing than abstractions. We could risk a Streisand effect by not naming one of the major breaches of this kind. That one was the most topical at the time that text was first written. A naive reader following up on that will find a plethora of other examples, of real associated costs and of lessons learned none of which would be anywhere near as easily found starting (as a naive reader) from an example.com abstraction (at least afaik example.com have not had a significant password breach so far, maybe we ought engineer one:-). That enough? >>> For "realm", I can't really make sense of "Recall both sides know >>> when this needs to be there independent of the encoding via a >>> zero length." Can you rephrase and/or repunctuate this (probably >>> without the word "recall")? >> >> Sorry what's not clear? > > Sorry, I think I said very clearly what's not clear: I can't make > sense of the sentence. Can you try rephrasing it so maybe I can? Can I bring you a rock? I'm sure you see my problem as well as yours. Yes I can re-phrase of course, but I'm convinced that will not be any sort of real improvement at all, e.g.: "Both sides know when realm is present or missing. Don't be mislead by the zero length encoding required." I think that's worse and not deliberately so. (I admit to not being terribly motivated to disimprove the text or do a sideways-move edit though:-) >>> It might be good if the description of "max-age" made it clear >>> that it's for the purpose of allowing multiple uses (multiple >>> sigs). As it is, it looks like it's there to limit the delay >>> before the challenge is answered (once). Maybe just a forward >>> ref to Section 8 is good enough here. >> >> I think it's clear to be honest. > > I know you do; you wrote it. Might you consider other input? In the > end, all I've asked for is a forward ref to Section 8. This draft is at version -09 now. I think >50% of those revisions were solely due to reviewer input. I resent the implication that I and my co-authors are not open to input. (Not much mind you, but a little:-) I fully accept that I'm impatient with some comments. Yes, your ask is small. But is it a real improvement? >>> Does the server really use session cookies to navigate around a >>> site? Or does the server give the client a session cookie for >>> the client to use to navigate? >> >> I think it's clearer as-is to be honest. > > I don't and I think it's wrong. Fair enough. > >>> -- Section 6.1 -- >>> >>> Why are the fields here not REQUIRED and OPTIONAL, using 2119 >>> words, as is the case in Section 3? >> >> Sorry I don't see a problem. > > It's not a problem, it's a question. Is there a reason you're using > 2119 words in Section 3, and not here? I honestly don't recall. At a guess, I would avoid 2119 terms where possible as they generate pedantic commentary from folks who have a different attitude than I towards 2119, cf. the Pete/Stephen WG chairs lunch show from a couple of years ago:-) But the honest answer again is: I don't recall and don't think it matters. And if there's not a problem, then maybe that's just dandy? > >>> -- Section 6.2 -- >>> >>> It seems odd to put the NOT RECOMMENDED mechanism in the middle; >>> I suggest switching sections 6.2.2 and 6.2.3. >> >> I'm fine with it as-is to be honest. > > At this point, it seems to me that you're just refusing to make > changes because you want to refuse to make changes. Whatever: this > is non-blocking. No, I'm pushing back on what I really see as a frankly odd comment. Your comment to me is like asking that we ensure that other things being equal we order the sections alphanumerically by title. > >>> The administrator will most likely want to set the max-age to >>> something that is not too slow on the slowest signing device that >>> is significant for that site. >>> >>> Maybe you mean "not too short"? >> >> Nope. If signing took 2 seconds a 1 second max-age would be a >> problem. And that can happen with very old JS engines. Will go away >> over time and is nearly gone now. (Much moreso than when -00 of >> this was done.) > > I think you miss my (very minor) point: max-age is a time period, and > is not something that's slow or fast; it's short or long. So I'd say > "not too short for the slowest signing device". But, again, very > minor, so it doesn't really matter. Yep. Your text is 0.0001% better. (Precisely:-) I made the change in my working copy. > >>> -- Section 8.3 -- The chances that a typical user (consider my >>> mother) will know or care about this, much less will "request" >>> anything is vanishingly small. Can you say anything here about >>> what can be done that would have any practical utility? >> >> This text is for a developer, not a user. And I have been asked >> about this feature a number of times by people who don't get the >> not-that-hidden complexities. > > But the text talks about users requesting things, and I don't think > users will understand any of this and request anything. Users will not read this RFC so that is just fine. Yes it talks about, but is not for, users. It is just fine to have this sentence talk about a cucumber even if no cucumber will ever understand this sentence. > Developers > should be making it work for general users. Is there anything they > can do there? If not, well, then not. I'm asking. My opinion of this is that that ought be an OS feature and not an HTTP auth feature. That doesn't mean that will happen of course. And I don't think we need this (again experimental!) RFC to go into all that. > >>> -- Section 9.3 -- >>> >>> Please create a new HOBA signature algorithms registry as >>> follows, with the specification required rule for updates. New >>> HOBA signature algorithms SHOULD be in use with other IETF >>> standards track protocols before being added to this registry. >>> >>> I don't think the SHOULD is really right -- who is the target? >>> This needs to be cast as instructions to the designated expert, >>> perhaps as, "The designated expert will review other uses of >>> requested new HOBA signature algorithms, with particular >>> consideration to their use in other IETF standards track >>> protocols." Perhaps there's also another word or two to say >>> about what the DE should consider? >> >> Sorry I don't get what's unclear. The SHOULD is targetted at the >> DE. The text you suggest(?) in quotes would be less clear I think. > > SHOULD is for describing protocol interoperability issues, not for > giving instructions to DEs. Why? Where's it say that? I think a DE is quite capable of getting the ask here. > But maybe we'll see if Pete has an > opinion here. OMG, that too! :-) Sure. > >>> -- Sections 9.4 and 9.5 -- Surely, IANA (or the designated >>> expert) will want to have some idea of how high "small" might >>> reasonably get. Can you put any bound on it, even a non-binding >>> one? And might there be any other advice for the designated >>> expert, anything at all? >> >> Really? Are we seriously worried about there being a bazillion key >> id algs or device id types in an experimental RFC? I am not. > > I'm not either; Cool then we can move on. > it's just that IANA usually wants boundaries. In any > case, what about the second question: is there any guidance to be > give to the DE here, or does the DE get to do whatever she likes? Sure. As long as its small:-) Cheers, S. > > Barry > From nobody Mon Jan 5 19:36:22 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2271A09C9; Mon, 5 Jan 2015 19:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UySvsKta_bvk; Mon, 5 Jan 2015 19:36:13 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94BB1A07BC; Mon, 5 Jan 2015 19:36:12 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so18667490lbi.10; Mon, 05 Jan 2015 19:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=irxDVu1/pjT+PuCZ+aoB/SsTvtdF7lE2U+28f0Eng2I=; b=Ljtp3F/yCUZUbCLeqzYV0ZbzREhfxHkFM8/hAR+wmBFMGbj+t2kPuyw2+HcHANufuz DGY+B7+Cj4uQnXRLXODmJHtiQ1fpzzzy+A8GcTQgSkJKwJle9l6htn08ptYPDGPvQjPw 9KxNkpzgufO/elLjCQrZVbAMvvSsf49gtyY+aV3QvM4FI16oiPYmNvy/vsnvKZNBF44D 6vPUuSgBLbms9NYYmmUEgb0aRQWaa+S5o9o6qoxCAUtZWbflOaum4O7lf6Xf4Yo/rTvl lGlC97ciPRB3H3i6l6x/ctSWhXe0x1epAUZBzQ0UXY527mJTV42LY1xprBcjlj7/K/Zz LU3A== MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr73034808lbv.21.1420515371045; Mon, 05 Jan 2015 19:36:11 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Mon, 5 Jan 2015 19:36:10 -0800 (PST) In-Reply-To: <54AB4FFF.4040402@cs.tcd.ie> References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> Date: Tue, 6 Jan 2015 11:36:10 +0800 X-Google-Sender-Auth: QsL9mlKCcAWp4EETyPLt-kkpoHk Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/hfqylUXk7UuseQrNKR7yeYxvv7E Cc: Barry Leiba , "httpauth-chairs@tools.ietf.org" , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 03:36:16 -0000 (For now, at least, I've gotten access to gmail through company gateways. We'll see... Adding my huawei.com address in again, just in case.) > Not snark, but genuine puzzlement. Ack; thanks. > And wrt the step-by-step stuff there's even a properly referenced > framework document that you brought to the IESG only months ago > that sets out exactly what your're asking be repeated here (or > else 7235 is broken). No, but there are bits that are unique to HOBA, and I want to make sure that it's very clear how it all fits. > But it's been independently implemented by the portugal telecom > folks without them ever asking (me anyway) a single question. > And reviewed by multiple folks so I honestly think you may be > the exception here. And see above wrt puzzlement;-) Ack. It's certainly possible that I'm being too picky; it's happened befor= e. >> I don't think this is a big deal, and I will >> >> 1. move this to a non-blocking comment, and >> >> 2. suggest text for you to include. > > Fair enough. Absent that being better text, I'll likely argue to > not change. But I know you might produce better text so we'll see:-) OK. BTW, I already changed my ballot, and I'll change it again to reflect this exchange. I'm not having it re-send email, because I don't want to fragment the discussion into separate threads. But you can see the change in the tracker. >>> The issue is that that function (revoke cookie) might not be >>> available to the HOBA code, or it might, depending on the kind of >>> HTTP server implementation. >> >> This is something we often struggle with, but I think it's a bad idea >> to soften the way we want a protocol to work because we know it will >> be difficult for some implementations. We should use MUST or SHOULD >> based on what's right, and accept that even MUST will not be complied >> with if an implementation can't comply. >> >> Do we really want this to be a MUST? Perhaps we can waffle slightly >> by saying "MUST ... if it is possible to do so in the relevant HTTP >> server," or some such? > > The way I look at this is in the spirit of the just issued RFC 7435. > We have little enough chance of this working so we ought (esp at the > experimental RFC stage) lean over to make deployment easier and not > harder. > > So I do think SHOULD is right there tbh. OK; removing that item as well now; thanks. >> Would it be worth adding a few words to say that (and to say that the >> session state doesn't change)? > > That could be worse than now. Since a lot of the client code here will > be async code (XHR now and promises soon) we don't actually know that > that'll be the case. Other stuff might be going on as one branch of > code is refreshing the challenge. OK. >>>> -- Section 8.2 -- >>>> >>>> I don't think you need to say "a la LinkedIn," and I think it's a >>>> bad idea to have us link a company's name to a password >>>> compromise forever in an RFC. Especially when it's not >>>> necessary. >>> >>> Is that really DISCUSS worthy? I don't think it is. Which of the >>> DISCUSS criteria relate to that. Seems like a stylistic thing to >>> me. >> >> I think it is: I think it's a very bad thing to disparage specific >> companies in our RFCs. > > Its a statement of fact though. That is very different. > >> That said, if you'd actually discuss > > Rhetorical fail alert:-) That last use of "discuss" !=3D DISCUSS-worthy. > You're ignoring a) that this is a style issue and explicitly not > DISCUSS-worthy and b) that I am in fact happy to discus your > non-blocking comments. > > I think it's entirely fair to establish if a point does or does not > warrant being blocking before disposing of the detail. (And hey, > when did an author not want to demote a DISCUSS to a COMMENT if that > is fair-game? Not often.:-) > >> this with me (why you think it's >> important to leave it there), then the discussion will have happened, >> and we can move ahead. > > Facts are much more convincing than abstractions. We could risk a > Streisand effect by not naming one of the major breaches of this > kind. That one was the most topical at the time that text was first > written. A naive reader following up on that will find a plethora > of other examples, of real associated costs and of lessons learned > none of which would be anywhere near as easily found starting (as > a naive reader) from an example.com abstraction (at least afaik > example.com have not had a significant password breach so far, > maybe we ought engineer one:-). > > That enough? The fact that there's a plethora of examples really speaks to not calling out one company on this, as well as that it's not necessary to do so. We could just say "the many password exposures that have been well documented in the media," for example. (On the DISCUSS criteria, "This cannot be an exhaustive list, but this set should be taken as exemplary of the common causes for DISCUSSes seen by the IESG in the past." This is a rare situation, so, of course, it's not explicitly listed. I can only say again that I think it's a bad idea to call out specific companies unless there's a strong need to.) >>>> For "realm", I can't really make sense of "Recall both sides know >>>> when this needs to be there independent of the encoding via a >>>> zero length." Can you rephrase and/or repunctuate this (probably >>>> without the word "recall")? >>> >>> Sorry what's not clear? >> >> Sorry, I think I said very clearly what's not clear: I can't make >> sense of the sentence. Can you try rephrasing it so maybe I can? > > Can I bring you a rock? I'm sure you see my problem as well as > yours. Yes I can re-phrase of course, but I'm convinced that will > not be any sort of real improvement at all, e.g.: > > "Both sides know when realm is present or missing. Don't be > mislead by the zero length encoding required." Actually, that helps; now I understand what you were trying to say (and, now that I've seen that text, I understand the original... but I honestly couldn't make sense of the original before). So: NEW Both sides know when this needs to be there, without needing to rely on the zero-length encoding. END I think what I mostly tripped over was the missing comma after "needs to be there", which confused me about the role of "=EFndependent" in the sentence. So if you like the current wording, maybe just add the comma. >>>> It might be good if the description of "max-age" made it clear >>>> that it's for the purpose of allowing multiple uses (multiple >>>> sigs). As it is, it looks like it's there to limit the delay >>>> before the challenge is answered (once). Maybe just a forward >>>> ref to Section 8 is good enough here. > > Yes, your ask is small. But is it a real improvement? I think it is, because it tells the reader where the issue is discussed. But it's non-blocking, so if you really object to that, I've had enough of my say there. >>>> -- Section 6.1 -- >>>> >>>> Why are the fields here not REQUIRED and OPTIONAL, using 2119 >>>> words, as is the case in Section 3? >>> >>> Sorry I don't see a problem. >> >> It's not a problem, it's a question. Is there a reason you're using >> 2119 words in Section 3, and not here? > > I honestly don't recall. At a guess, I would avoid 2119 terms where > possible as they generate pedantic commentary from folks who have > a different attitude than I towards 2119 He-he. Yeh, ack. > But the honest answer again is: I don't recall and don't think it > matters. Yeh, I don't either; it was just a question. Done here. >>>> It seems odd to put the NOT RECOMMENDED mechanism in the middle; >>>> I suggest switching sections 6.2.2 and 6.2.3. ... > No, I'm pushing back on what I really see as a frankly odd > comment. Your comment to me is like asking that we ensure that > other things being equal we order the sections alphanumerically > by title. C'mon, hardly a reasonable comparison. We don't usually mix "good ideas" and "bad ideas" rather arbitrarily: usualy organization puts the good ideas together, and the bad ones together. Anyway, again: done here; do as you think best. >> But the text talks about users requesting things, and I don't think >> users will understand any of this and request anything. > > Users will not read this RFC so that is just fine. > > Yes it talks about, but is not for, users. It is just fine to > have this sentence talk about a cucumber even if no cucumber > will ever understand this sentence. I really didn't want to talk about this further, but I have to respond to this: you're recommending that implementors give users an option that will be useless to almost all users. That's what I'm (minorly) carping on, and (mostly) I'm asking if there's something you can say to implementors that will help them do something that's actually useful to users. That's all. >> Developers >> should be making it work for general users. Is there anything they >> can do there? If not, well, then not. I'm asking. > > My opinion of this is that that ought be an OS feature and > not an HTTP auth feature. That doesn't mean that will happen > of course. And I don't think we need this (again experimental!) > RFC to go into all that. Yeh, probably right. I was asking if there was something useful you could say. "Nothing that comes to mind," is a fair answer to that. >>>> -- Section 9.3 -- >>>> >>>> Please create a new HOBA signature algorithms registry as >>>> follows, with the specification required rule for updates. New >>>> HOBA signature algorithms SHOULD be in use with other IETF >>>> standards track protocols before being added to this registry. >>>> >>>> I don't think the SHOULD is really right -- who is the target? >>>> This needs to be cast as instructions to the designated expert, >>>> perhaps as, "The designated expert will review other uses of >>>> requested new HOBA signature algorithms, with particular >>>> consideration to their use in other IETF standards track >>>> protocols." Perhaps there's also another word or two to say >>>> about what the DE should consider? >>> >>> Sorry I don't get what's unclear. The SHOULD is targetted at the >>> DE. The text you suggest(?) in quotes would be less clear I think. >> >> SHOULD is for describing protocol interoperability issues, not for >> giving instructions to DEs. > > Why? Where's it say that? In 2119. > I think a DE is quite capable of getting the ask here. Yes, true. >>>> -- Sections 9.4 and 9.5 -- Surely, IANA (or the designated >>>> expert) will want to have some idea of how high "small" might >>>> reasonably get. Can you put any bound on it, even a non-binding >>>> one? And might there be any other advice for the designated >>>> expert, anything at all? >>> >>> Really? Are we seriously worried about there being a bazillion key >>> id algs or device id types in an experimental RFC? I am not. >> >> I'm not either; > > Cool then we can move on. > >> it's just that IANA usually wants boundaries. In any >> case, what about the second question: is there any guidance to be >> give to the DE here, or does the DE get to do whatever she likes? > > Sure. As long as its small:-) No, I mean is there any advice to DEs about what to review in regard to these registries (forget about the number of entries). In 9.3 you said that the DE should consider the use of the algorithms in IETF protocols. Great. Any advice of that nature here? Or do we want to DE to wing it? Barry From nobody Mon Jan 5 22:30:17 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED111A9103; Mon, 5 Jan 2015 22:30:16 -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 NqjGHFpfdTFv; Mon, 5 Jan 2015 22:30:14 -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 582FC1A90FE; Mon, 5 Jan 2015 22:30:14 -0800 (PST) Received: from [192.168.2.175] ([84.187.41.4]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lmb2Z-1XYDsZ3zuN-00aH8G; Tue, 06 Jan 2015 07:29:29 +0100 Message-ID: <54AB80B7.9040401@gmx.de> Date: Tue, 06 Jan 2015 07:29:11 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephen Farrell , Barry Leiba References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> In-Reply-To: <54AB4FFF.4040402@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:FV+6mmnYDWTLZ+MDKkh9aeBr4YQhzLzXHpTP2V4ni392oPuzBv+ PUGOealSMn9l68hRWCANe405HRQRDmHMcCBBGyERHQG7wgPt+g2mElbmVadhdYL4lnJdRLB eNWc+H7zG29PRLZg9hV6+aW2gGe1HmjT7JSYvRD7PRcmv6pDHfpKEMZEg2rlZ1x540LyFCQ Mq43JaG/erZx1PZYLRytg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/I3jGdcsBHL5BJ7qRUODb2kUpoS8 Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG , Barry Leiba Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 06:30:16 -0000 On 2015-01-06 04:01, Stephen Farrell wrote: > ... >> And should be in here, as well, to make it clear how the details of >> HOBA fit into the framework. > > Fully disagree. And the author of 7235 who did review this did not > suggest that iirc. This should and does correctly require that the > implementer has read or is otherwise familiar with 7235. (What you > want would also call for every http-auth WG output to include that > kind of regurgitation. It's just a bad idea.) > ... As I'm mentioned... FWIW I found the document really confusing as well; a complete example exchange of the bits on the wire would be extremely helpful. Best regards, Julian From nobody Tue Jan 6 00:11:37 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A351A9123; Tue, 6 Jan 2015 00:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io-SRS6QhRgB; Tue, 6 Jan 2015 00:11:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5701A9119; Tue, 6 Jan 2015 00:10:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DAAEBEC0; Tue, 6 Jan 2015 08:10:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yKCl9dU_pxb; Tue, 6 Jan 2015 08:10:25 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A765BEB1; Tue, 6 Jan 2015 08:10:25 +0000 (GMT) Message-ID: <54AB9870.50505@cs.tcd.ie> Date: Tue, 06 Jan 2015 08:10:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/wnKHxgzABazBrMVvNmqBnElDjSo Cc: Barry Leiba , "httpauth-chairs@tools.ietf.org" , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:11:31 -0000 Thanks for updating the ballot. I'll process your comments separately so this is just on the remaining DISCUSS point. On 06/01/15 03:36, Barry Leiba wrote: >>>>> >>>> -- Section 8.2 -- >>>>> >>>> >>>>> >>>> I don't think you need to say "a la LinkedIn," and I think it's a >>>>> >>>> bad idea to have us link a company's name to a password >>>>> >>>> compromise forever in an RFC. Especially when it's not >>>>> >>>> necessary. >>>> >>> >>>> >>> Is that really DISCUSS worthy? I don't think it is. Which of the >>>> >>> DISCUSS criteria relate to that. Seems like a stylistic thing to >>>> >>> me. >>> >> >>> >> I think it is: I think it's a very bad thing to disparage specific >>> >> companies in our RFCs. >> > >> > Its a statement of fact though. That is very different. >> > >>> >> That said, if you'd actually discuss >> > >> > Rhetorical fail alert:-) That last use of "discuss" != DISCUSS-worthy. >> > You're ignoring a) that this is a style issue and explicitly not >> > DISCUSS-worthy and b) that I am in fact happy to discus your >> > non-blocking comments. >> > >> > I think it's entirely fair to establish if a point does or does not >> > warrant being blocking before disposing of the detail. (And hey, >> > when did an author not want to demote a DISCUSS to a COMMENT if that >> > is fair-game? Not often.:-) >> > >>> >> this with me (why you think it's >>> >> important to leave it there), then the discussion will have happened, >>> >> and we can move ahead. Yet here we still are? :-) >> > >> > Facts are much more convincing than abstractions. We could risk a >> > Streisand effect by not naming one of the major breaches of this >> > kind. That one was the most topical at the time that text was first >> > written. A naive reader following up on that will find a plethora >> > of other examples, of real associated costs and of lessons learned >> > none of which would be anywhere near as easily found starting (as >> > a naive reader) from an example.com abstraction (at least afaik >> > example.com have not had a significant password breach so far, >> > maybe we ought engineer one:-). >> > >> > That enough? > The fact that there's a plethora of examples really speaks to not > calling out one company on this, I re-iterate: At the time of writing this was the poster-child example. It still remains one, and a good one for RFC readers. > as well as that it's not necessary to > do so. We could just say "the many password exposures that have been > well documented in the media," for example. That may be a reasonable comment, but I continue to maintain that it is not DISCUSS-worthy. And I think being so shy about this is a bad plan actually and we ought if anything be more direct about it. > (On the DISCUSS criteria, "This cannot be an exhaustive list, but this > set should be taken as exemplary of the common causes for DISCUSSes > seen by the IESG in the past." This is a rare situation, so, of > course, it's not explicitly listed. I can only say again that I think > it's a bad idea to call out specific companies unless there's a strong > need to.) "bad idea" does not mean DISCUSS-worthy, and extending the DISCUSS criteria in that way seems very wrong to me. The DISCUSS non-criteria also exists though, quoting, I think this falls squarely under two of those: " - Pedantic corrections to non-normative text. Oftentimes, poor phrasing or misunderstandings in descriptive text are corrected during IESG review. However, if these corrections are not essential to the implementation of the specification, these should not be blocking comments. - Stylistic issues of any kind. The IESG are welcome to copy-edit as a non-blocking comment, but this should not obstruct document processing. " I think in a case like this it is entirely correct to reference well publicised security incidents in the most natural fashion via the name of the organisation that experienced the incident. In this case, I re-iterate that that incident was I think the most commonly cited one at the time of writing. (I can buy that adding a citation for more detail would be a good addition though.) Cheers, S. > From nobody Tue Jan 6 00:12:44 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCB91A9120; Tue, 6 Jan 2015 00:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBZ857Wnj0fP; Tue, 6 Jan 2015 00:12:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859201A911D; Tue, 6 Jan 2015 00:12:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 56455BEC0; Tue, 6 Jan 2015 08:12:31 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWE8cSHnadvM; Tue, 6 Jan 2015 08:12:30 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2D8F8BEB1; Tue, 6 Jan 2015 08:12:30 +0000 (GMT) Message-ID: <54AB98ED.4090504@cs.tcd.ie> Date: Tue, 06 Jan 2015 08:12:29 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , Barry Leiba References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54AB80B7.9040401@gmx.de> In-Reply-To: <54AB80B7.9040401@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/I5T7cD_u1FGFezL5w2BgpqnXVq4 Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG , Barry Leiba Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:12:42 -0000 On 06/01/15 06:29, Julian Reschke wrote: > On 2015-01-06 04:01, Stephen Farrell wrote: >> ... >>> And should be in here, as well, to make it clear how the details of >>> HOBA fit into the framework. >> >> Fully disagree. And the author of 7235 who did review this did not >> suggest that iirc. This should and does correctly require that the >> implementer has read or is otherwise familiar with 7235. (What you >> want would also call for every http-auth WG output to include that >> kind of regurgitation. It's just a bad idea.) >> ... > > As I'm mentioned... > > FWIW I found the document really confusing as well; Hmm. I didn't get that from your earlier reviews. Did I miss something? If there are specific things are confusing that would get in the way for an implementer then I'd be glad to know about those but I thought all the points you raised in your reviews of this had been addressed. > a complete example > exchange of the bits on the wire would be extremely helpful. Noted. S. > > Best regards, Julian From nobody Tue Jan 6 00:22:16 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944351A9124; Tue, 6 Jan 2015 00:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wItz2npQMBjJ; Tue, 6 Jan 2015 00:22:07 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0AC1A912A; Tue, 6 Jan 2015 00:20:41 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so19781125lab.18; Tue, 06 Jan 2015 00:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tJCsB81m07xUuPHpun95wh60IbH6K/h+nfiKUHtbQIU=; b=JyE4Qcea2zWbK4d+EmPcqMSJYc5M9FiGncfwhjlAWNzEy8s1u3GGuezbWgrrqUQwT9 r/tXNXi//cNVZJ6jzx4bFcSJCs751BQEPmGZl4kZ6eLZ1RojMq1sn8Ui9cDeOW7o906u IY1TqRKmDcXm9cAlaIMZCur6BmCHJrtKVkprJ2fo0Bi1H0pH1pGVVw9VzcS7Qa892G3Y W9fubKDEVhPdSbvqGl/RD0kutjGRldzOUDA+Na6YfOGoSRdwkxaza8I/5Fv62CWFX40q rZFAc3xsQGoJa2rgML0hURJCkbjDpdHckmw/yrNadLkPJ6cECuqyO/yPgGScsKUGfjGU 26fw== MIME-Version: 1.0 X-Received: by 10.152.7.206 with SMTP id l14mr97953791laa.1.1420532439979; Tue, 06 Jan 2015 00:20:39 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 6 Jan 2015 00:20:39 -0800 (PST) In-Reply-To: <54AB9870.50505@cs.tcd.ie> References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54AB9870.50505@cs.tcd.ie> Date: Tue, 6 Jan 2015 16:20:39 +0800 X-Google-Sender-Auth: G3fiaeuEwGLQzepiEuSPA-7vru4 Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/2VBOmIIr7zQjBqzuBpBtSS7qAuQ Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:22:08 -0000 >>>>>> >>>> I don't think you need to say "a la LinkedIn," and I think it's a >>>>>> >>>> bad idea to have us link a company's name to a password >>>>>> >>>> compromise forever in an RFC. Especially when it's not >>>>>> >>>> necessary. ... >>>> >> I think it is: I think it's a very bad thing to disparage specific >>>> >> companies in our RFCs. ... >>>> >> this with me (why you think it's >>>> >> important to leave it there), then the discussion will have happened, >>>> >> and we can move ahead. > > Yet here we still are? :-) Because I think the discussion needs to continue. I still don't understand why you think it's so important to single out LinkedIn, such that it's worth the damage that having that in an RFC represents. >> The fact that there's a plethora of examples really speaks to not >> calling out one company on this, > > I re-iterate: At the time of writing this was the poster-child > example. It still remains one, and a good one for RFC readers. It was not "the poster child": there have been so many of these breaches, both before and since, that I see no reason at all to call out any one instance. >> as well as that it's not necessary to >> do so. We could just say "the many password exposures that have been >> well documented in the media," for example. > > That may be a reasonable comment, but I continue to maintain that > it is not DISCUSS-worthy. And I think being so shy about this is > a bad plan actually and we ought if anything be more direct about > it. I don't think text such as what I suggest -- text that does not name specific companies that got hacked -- is being shy. Actually, I think it makes a *stronger* statement to say that there have been many, and that they have made big news worldwide. > "bad idea" does not mean DISCUSS-worthy, and extending the DISCUSS > criteria in that way seems very wrong to me. "Bad idea" in this case means, to me, bad for the IETF. I think it's just wrong. This is not a "pedantic correction" nor a "stylistic issue" -- it is, to me, an important point. You and I clearly don't agree on this, so let's see what other ADs think as they fill out their ballots. > I think in a case like this it is entirely correct to reference well > publicised security incidents in the most natural fashion via the name > of the organisation that experienced the incident. In this case, I > re-iterate that that incident was I think the most commonly cited one > at the time of writing. (I can buy that adding a citation for more > detail would be a good addition though.) I understand that's what you think. As I say, we disagree, apparently strongly. Barry From nobody Tue Jan 6 00:39:17 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0CE1A1F01; Tue, 6 Jan 2015 00:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxh0-m7Kh0pG; Tue, 6 Jan 2015 00:39:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669521A1EF6; Tue, 6 Jan 2015 00:39:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2EFC2BE98; Tue, 6 Jan 2015 08:39:12 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBWaVe09bSDV; Tue, 6 Jan 2015 08:39:10 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E436BE08; Tue, 6 Jan 2015 08:39:10 +0000 (GMT) Message-ID: <54AB9F2E.20707@cs.tcd.ie> Date: Tue, 06 Jan 2015 08:39:10 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54AB9870.50505@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/mGmOJ9nLhg8UdEF2Bdf1A9uYy2Q Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:39:16 -0000 On 06/01/15 08:20, Barry Leiba wrote: >>>>>>>>>>> I don't think you need to say "a la LinkedIn," and I think it's a >>>>>>>>>>> bad idea to have us link a company's name to a password >>>>>>>>>>> compromise forever in an RFC. Especially when it's not >>>>>>>>>>> necessary. > ... >>>>>>> I think it is: I think it's a very bad thing to disparage specific >>>>>>> companies in our RFCs. > ... >>>>>>> this with me (why you think it's >>>>>>> important to leave it there), then the discussion will have happened, >>>>>>> and we can move ahead. >> >> Yet here we still are? :-) > > Because I think the discussion needs to continue. I still don't > understand why you think it's so important to single out LinkedIn, > such that it's worth the damage that having that in an RFC represents. There is no additional damage to them (unless via this discussion ala Streisand;-) and I don't see any damage to the IETF from a mention of that being in an RFC - it was a real and really well publicised incident, us mentioning it in an RFC will not put it back on the front pages as it was at the time. >>> The fact that there's a plethora of examples really speaks to not >>> calling out one company on this, >> >> I re-iterate: At the time of writing this was the poster-child >> example. It still remains one, and a good one for RFC readers. > > It was not "the poster child": there have been so many of these > breaches, both before We disagree there as to the facts. My recollection is that it very much was the poster child at the time of writing. But we might of course both be recalling imperfectly. > and since, that I see no reason at all to call > out any one instance. > >>> as well as that it's not necessary to >>> do so. We could just say "the many password exposures that have been >>> well documented in the media," for example. >> >> That may be a reasonable comment, but I continue to maintain that >> it is not DISCUSS-worthy. And I think being so shy about this is >> a bad plan actually and we ought if anything be more direct about >> it. > > I don't think text such as what I suggest -- text that does not name > specific companies that got hacked -- is being shy. Actually, I think > it makes a *stronger* statement to say that there have been many, and > that they have made big news worldwide. > >> "bad idea" does not mean DISCUSS-worthy, and extending the DISCUSS >> criteria in that way seems very wrong to me. > > "Bad idea" in this case means, to me, bad for the IETF. I think it's > just wrong. > > This is not a "pedantic correction" nor a "stylistic issue" -- it is, > to me, an important point. Sure I accept that you think this important. > You and I clearly don't agree on this, Very much so. > so > let's see what other ADs think as they fill out their ballots. Yep. >> I think in a case like this it is entirely correct to reference well >> publicised security incidents in the most natural fashion via the name >> of the organisation that experienced the incident. In this case, I >> re-iterate that that incident was I think the most commonly cited one >> at the time of writing. (I can buy that adding a citation for more >> detail would be a good addition though.) > > I understand that's what you think. As I say, we disagree, apparently strongly. I strongly disagree with this comment being a DISCUSS point. Were there a blatant error in the text that might be defensible but there is not, that incident did happen and was very widely publicised. [1] [1] https://en.wikipedia.org/wiki/2012_LinkedIn_hack I far less strongly disagree about the text that ought be in the RFC - that is, my main problem with your comment is that it is a blocking DISCUSS point. Cheers, S. > > Barry > From nobody Tue Jan 6 01:47:41 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751191A912B; Tue, 6 Jan 2015 01:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KIxtguHOHZF; Tue, 6 Jan 2015 01:47:33 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110BD1A1BC3; Tue, 6 Jan 2015 01:47:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AA4E1BECA; Tue, 6 Jan 2015 09:47:31 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jrMhDeKDHG2; Tue, 6 Jan 2015 09:47:29 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 386C3BE8F; Tue, 6 Jan 2015 09:47:29 +0000 (GMT) Message-ID: <54ABAF30.8040207@cs.tcd.ie> Date: Tue, 06 Jan 2015 09:47:28 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ZX-RF90Ehr94dsWOEQ-oObZmjoQ Cc: Barry Leiba , "httpauth-chairs@tools.ietf.org" , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:47:35 -0000 Hope this works ok - I've pasted in the comment text and my responses to cut down the nesting. A proto -10 version with changes indicated below is at [1] the diff vs. -09 at [2]. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > This document would benefit from some section somewhere giving a > set of clear, numbered steps, saying who sends, who receives, and > who does what with what input at each step. I will propose such > text. And I'll happily look at that when it's available. (And hope to not have to wait much:-) > Minor editorial nit: you use "a HOBA" fairly consistently, but "an > HOBA" appears twice. Oughta fix. Fixed. > The abstract appears to overstate the password issue. It'd be > better for the abstract to say that it eliminates the transmission > of passwords and their storage on the server, which are really the > points. TBH, I prefer the current text a lot. > The introduction might expand on that a little, noting > that passwords might still be used in the user interfaces, but they > would be exclusively client-side things, never transmitted and > never seen by servers. I'd be against adding such. IMO an implementation like that is not a great idea as it's phishable (the user won't know that the password is local only and will re-use the same password in more than one place). That's a very strong (IMO) reason to argue that private key protection is an OS/platform issue and ought not be a HOBA implementation issue. And private key protection done without passwords is much more usable and less phishable. > > -- Section 2 -- > > The definition of "alg" says "the encoding of RSA-SHA256 is 0x30," > but the ABNF above says "alg = 1*2DIGIT", which implies "30", not > "0x30". As I look at Section 9.3, I think I see the problem and > my confusion. I don't think you want "a single octet" here > (otherwise, how would you encode 12 or 99? Don't you really want > something like this?: > > OLD > o alg: specifies the signature algorithm being used encoded as a > single octet as defined in Section 9.3. RSA-SHA256 MUST be > supported, RSA-SHA1 MAY be supported. The IANA registered > algorithm values are encoded as ASCII numbers; for example, the > encoding of RSA-SHA256 is 0x30. > NEW > o alg: specifies the signature algorithm being used. RSA-SHA256 > MUST be supported, RSA-SHA1 MAY be supported. The IANA > registered algorithm values (see Section 9.3) are encoded as one- > or two-digit ASCII numbers. For example, RSA-SHA256 (number > 0) is encoded as the ASCII character "0" (0x30), while a future > algorithm registered as number 17 would be encoded as the > ASCII characters "17" (0x3137). > END Fixed. > > -- Section 3 -- > > The "realm" attribute MUST NOT appear more than once. > > Does that mean that "challenge" and max-age can appear more than > once? No. > If not, why call it out for "realm" and not for the others? I forget and haven't found a why. I think that was in response to some other comment. Would prefer leave it just in case. > It might be good if the description of "max-age" made it clear that > it's for the purpose of allowing multiple uses (multiple sigs). As > it is, it looks like it's there to limit the delay before the > challenge is answered (once). Maybe just a forward ref to Section > 8 is good enough here. I looked at it again and still think it's ok as-is. There is more discussion of max-age a couple of paras below this bullet list. > > -- Section 4 -- > > The second paragraph starts by saying that localStorage is > required, and gives a reference. It ends by saying that > localStorage is not required, because IndexedDB works too, and it > gives a reference. That's not a disaster, but it's sloppy, and > it'd be better to say it all up front. It also makes me wonder > whether the security considerations about attacks on localStorage > do or don't also apply to IndexedDB. Shuffled that about a bit. Better now. > Another very minor point: I would avoid using "a hassle for users" > in an international document that non-native speakers are expected > to understand. "Difficult for users" seems just as good and more > understandable to all. Fixed. > Does the server really use session cookies to navigate around a > site? Or does the server give the client a session cookie for the > client to use to navigate? Fixed. > > -- Section 6.2 -- > > It seems odd to put the NOT RECOMMENDED mechanism in the middle; I > suggest switching sections 6.2.2 and 6.2.3. Noted. Not done:-) > -- Section 8 -- > > The first paragraph doesn't say enough to make sense to me. > Perhaps a few more words about why? I swapped the 1st and 2nd paras. The 1st was a bit abrupt yes but I think it fits better now. > > -- Section 8.3 -- > > The chances that a typical user (consider my mother) will know or > care about this, much less will "request" anything is vanishingly > small. Can you say anything here about what can be done that would > have any practical utility? I think we covered this sufficiently. I do not want to get into recommending ways HOBA implementers can do what really ought be an OS/platform function. In the end I added that specific point and did tweak a bit though. > > -- Section 9.3 -- > > Please create a new HOBA signature algorithms registry as follows, > with the specification required rule for updates. New HOBA signature > algorithms SHOULD be in use with other IETF standards track protocols > before being added to this registry. > > I don't think the SHOULD is really right -- who is the target? > This needs to be cast as instructions to the designated expert, > perhaps as, "The designated expert will review other uses of > requested new HOBA signature algorithms, with particular > consideration to their use in other IETF standards track > protocols." Perhaps there's also another word or two to say about > what the DE should consider? I really think the SHOULD here is good enough and is what we want and no more guidance for a qualified DE is needed and I think we agreed that that's ok. > > -- Sections 9.4 and 9.5 -- > > Might there be any advice for the designated expert, anything at > all? No, I think it's fine - there is no equivalent to the sig alg thing in 9.3 needed. Cheers, S. From nobody Tue Jan 6 01:54:42 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7821A1A1BB7; Tue, 6 Jan 2015 01:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEsjXmmK3nZ3; Tue, 6 Jan 2015 01:54:40 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C931A0029; Tue, 6 Jan 2015 01:54:39 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id z11so10974721lbi.20; Tue, 06 Jan 2015 01:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5816qoVslhh1/mmrMKHbrtoi6JByjGtPs2YVh9Ojd18=; b=Iy4iAJOFbIzAbl64S62vxj471+F5DJ/fA/H/zpquIxOeh+mwRUcc7i8gN4Qd+ULGpM p9BX6Uhgd94endn1qO82mz9r5z5XyfV6zE0tGJGXBO+Dt5vOmMyRC6aPXjgeSwYeiihr dhA0VJ8mE4jplZBJYQmA01Oo428kEVB8GNscUMJ/HquBFfKwn39XcahI7OcTGgVC4z/r FU4bmvt1P3ChW/GVc4rf8Jxk4/+BtqqDYoziPCYtlSI6+Ftuh8giMbWGUo82AWbQfcQ+ bvLZGMto534ESZ9Moh1DqFvBwyrpAH7lHSynZN8+rVO74PmI7765oO5TH+8/TCWBBMo9 zyOg== MIME-Version: 1.0 X-Received: by 10.112.25.7 with SMTP id y7mr24444841lbf.94.1420538078200; Tue, 06 Jan 2015 01:54:38 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 6 Jan 2015 01:54:38 -0800 (PST) In-Reply-To: <54ABAF30.8040207@cs.tcd.ie> References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54ABAF30.8040207@cs.tcd.ie> Date: Tue, 6 Jan 2015 17:54:38 +0800 X-Google-Sender-Auth: jtBsQjo8jzKfGG9ZnZxPMB9VcyA Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/lObLuGVDOyjC6z0VL6dpPdmSBFQ Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:54:41 -0000 > A proto -10 version with changes indicated below is at [1] the > diff vs. -09 at [2]. Will try to look at that later (Tues evening, China time). >> This document would benefit from some section somewhere giving a >> set of clear, numbered steps, saying who sends, who receives, and >> who does what with what input at each step. I will propose such >> text. > > And I'll happily look at that when it's available. (And hope to > not have to wait much:-) That's also on the schedule for after dinner. >> The abstract appears to overstate the password issue. It'd be >> better for the abstract to say that it eliminates the transmission >> of passwords and their storage on the server, which are really the >> points. > > TBH, I prefer the current text a lot. OK; thanks for having a look (and also for some of the other items). > I'd be against adding such. IMO an implementation like that is not a > great idea as it's phishable (the user won't know that the password is > local only and will re-use the same password in more than one place). A good point, which I hadn't considered; thanks. >> -- Section 8 -- >> >> The first paragraph doesn't say enough to make sense to me. >> Perhaps a few more words about why? > > I swapped the 1st and 2nd paras. The 1st was a bit abrupt yes > but I think it fits better now. Will look tonight, but I bet you're right. > I think we covered this sufficiently. I do not want to > get into recommending ways HOBA implementers can do what > really ought be an OS/platform function. In the end I > added that specific point and did tweak a bit though. T'anks. >> -- Sections 9.4 and 9.5 -- >> >> Might there be any advice for the designated expert, anything at >> all? > > No, I think it's fine - there is no equivalent to the > sig alg thing in 9.3 needed. OK. b From nobody Tue Jan 6 01:59:58 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3811A1F1D; Tue, 6 Jan 2015 01:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uDFmpQ0Bjmc; Tue, 6 Jan 2015 01:59:55 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FBD01A0178; Tue, 6 Jan 2015 01:59:55 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so19737167lab.13; Tue, 06 Jan 2015 01:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ibBoMipNDzgtyCHXCZwadEc6kXpYpBSCHInCMia8ZLI=; b=ZehJPU9jPaFxTWY1JWuwEhZ+b1DYKo7ikhXI075zryULmD/e0KHyYB76BTFXDertuw TAkiY8zbICyNhLo46KerC7gfQtyvb0NOs/dhRXMgBigN1pkyQWQIpXLFKU0n179K9m8o X1Xjx/Q60TX8fAUIIjvdeXVQVMFCQlpdyJfOKnW79H/BGXD/qpsc6O7EUdM/4TUPDwwf E16Z2ppM0xrPwGPfXAlinD5Hb28J8gWy1c66hGsA4KtycoFIxVJyepD4S12GYVCFPKGh CDFSHpdMIpU00cjmwRpPQQMKgS+FfoahaGo/34g6pNYfltOWw8kkJUfwizMQHaoEy9Ih ORYQ== MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr97140161lam.15.1420538393802; Tue, 06 Jan 2015 01:59:53 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 6 Jan 2015 01:59:53 -0800 (PST) In-Reply-To: References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54ABAF30.8040207@cs.tcd.ie> Date: Tue, 6 Jan 2015 17:59:53 +0800 X-Google-Sender-Auth: KrulP-4nHnWPDBzHrcXPPv-k_60 Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/uU5S2ZVPoGCa06iq5IRNey4yCCI Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:59:57 -0000 >> A proto -10 version with changes indicated below is at [1] the >> diff vs. -09 at [2]. > > Will try to look at that later (Tues evening, China time). Got a chance to look at the diffs now; yes, it looks good, and thanks again. Barry From nobody Tue Jan 6 05:47:20 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A4A1A6F27; Tue, 6 Jan 2015 05:47:18 -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 6uISmGWQQqgb; Tue, 6 Jan 2015 05:47:16 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B681A6F21; Tue, 6 Jan 2015 05:47:15 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id l4so19151949lbv.26; Tue, 06 Jan 2015 05:47:14 -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=uUN8GamlHEW5HnJCl79dlTeJ/O7U6zHxJFWQuY0S0p0=; b=Xtu6stC+/xB6PlN5pcRjLSSW5D85RgOSbFUZoy6cUFm0jkYQ3Lo3QNCYZk09uwVcP8 4WeiEUQw1iNHCgf+A1RLYnyRPzwwFOzGOPMuhyi/EjH7V1yqCHY3TwIeBVvnkkMZ7zts bSmufqHhhtqK9O6JSAR8UN7ffeXgvK9ZHLmUS6OPg1qHhoXzHQzZCpyxRujetM7GVarN ILY7QFQ/8GXEZkEFtFX8olQr06jklHjBzeK4DjkAr9CX1+DToaNPHyb/4oEFbR1bfatZ OoQVFzzZsq4xHaILd1zPJkJbdmLAYkqzWLUhSKTiWcc3zTdWrMcl3qXV4Mhg/hONY8fZ Rvdw== MIME-Version: 1.0 X-Received: by 10.112.52.229 with SMTP id w5mr86913321lbo.52.1420552034308; Tue, 06 Jan 2015 05:47:14 -0800 (PST) Received: by 10.112.49.52 with HTTP; Tue, 6 Jan 2015 05:47:14 -0800 (PST) In-Reply-To: References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54ABAF30.8040207@cs.tcd.ie> Date: Tue, 6 Jan 2015 08:47:14 -0500 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/37eey6bNH7HSgqtN1zUVvztdreM Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:47:18 -0000 Stephen & Barry, Thank you both for working through this. I'm caught up now as I was asleep during the exchange. I want to make sure I understand where we are at now. Barry will propose text that lists out the steps requested in his original discuss. I think this could be a helpful addition. I was fine with the text of the draft as-is, but see that different people think differently and this addition could be helpful. I had to add in something similar in one of my drafts even though I and a few others thought the steps were clear, in the end it was helpful to some. The other item was on LinkedIn and I think we are ok now on the text change, is that right? To see if I can help, I do agree with Stephen here and hope the updated text is enough to move forward on this one (it seems to be the case). If the LinkedIn attack is mentioned, most know that it was a large scale attack against the passwords stored on the server side. For what it's worth, just the mention of an attack is not necessarily bad press. Most look at how a company handled an attack and the aftermath now rather than the fact that one happened. Sometimes it is positive and most of the time it turns out to positive for companies (even TJ Max had an increase in sales after their breach that involved compromised Point of Sale systems). Barry, as an FYI, the focus on passwords is partly due to my review as that is what this draft is helping to solve. I wanted text removed that talked about phishing attacks because they are far more complicated than just passwords and can involve lots of different types of credentials. I do think the focus on passwords is more appropriate. Thank you, Kathleen On Tue, Jan 6, 2015 at 4:59 AM, Barry Leiba wrote: >>> A proto -10 version with changes indicated below is at [1] the >>> diff vs. -09 at [2]. >> >> Will try to look at that later (Tues evening, China time). > > Got a chance to look at the diffs now; yes, it looks good, and thanks again. > > Barry > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Best regards, Kathleen From Barry.Leiba@huawei.com Tue Jan 6 06:05:41 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F103D1A6F20; Tue, 6 Jan 2015 06:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruZfS41Q0tCs; Tue, 6 Jan 2015 06:05:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0131A6F22; Tue, 6 Jan 2015 06:05:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQY17272; Tue, 06 Jan 2015 14:05:35 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 Jan 2015 14:05:33 +0000 Received: from DFWEML704-CHM.china.huawei.com ([10.193.5.141]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Tue, 6 Jan 2015 06:05:29 -0800 From: Barry Leiba To: Stephen Farrell , Barry Leiba Thread-Topic: Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) Thread-Index: AQHQKTq4azhftYB1T02YBf9CB3xeW5yyRHMAgACpSoCAAAm8AIAAZ74A///AnxA= Date: Tue, 6 Jan 2015 14:05:29 +0000 Message-ID: <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E90C@dfweml704-chm> References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54ABAF30.8040207@cs.tcd.ie> In-Reply-To: <54ABAF30.8040207@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.168] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/3P-9vJC8pK0rOGe1lduleh1D9Ik X-Mailman-Approved-At: Tue, 06 Jan 2015 06:18:13 -0800 Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:07:23 -0000 Pj4gVGhpcyBkb2N1bWVudCB3b3VsZCBiZW5lZml0IGZyb20gc29tZSBzZWN0aW9uIHNvbWV3aGVy ZSBnaXZpbmcgYSBzZXQgDQo+PiBvZiBjbGVhciwgbnVtYmVyZWQgc3RlcHMsIHNheWluZyB3aG8g c2VuZHMsIHdobyByZWNlaXZlcywgYW5kIHdobyBkb2VzIA0KPj4gd2hhdCB3aXRoIHdoYXQgaW5w dXQgYXQgZWFjaCBzdGVwLiAgSSB3aWxsIHByb3Bvc2Ugc3VjaCB0ZXh0Lg0KPg0KPiBBbmQgSSds bCBoYXBwaWx5IGxvb2sgYXQgdGhhdCB3aGVuIGl0J3MgYXZhaWxhYmxlLiAoQW5kIGhvcGUgdG8g bm90IGhhdmUNCj4gdG8gd2FpdCBtdWNoOi0pDQoNCkFuZCBoZXJlIHdlIGdvOyBub3QgYSBsb3Qs IGJ1dCBJIHRoaW5rIGl0IHJlYWxseSBoZWxwcy4gIE9mIGNvdXJzZSwgYWRqdXN0IGl0IGlmIEkg Z290IGFueXRoaW5nIHdyb25nIG9yIHdvcmRlZCBpbmFjY3VyYXRlbHkuICBOb3RlIGhvdyB0aGUg c2VjdGlvbiByZWZlcmVuY2VzIGp1bXAgYXJvdW5kIC0tIHRoYXQncyB3aHkgSSBmb3VuZCBpdCBo YXJkIHRvIGZvbGxvdywgYW5kIHdoeSBJIHRoaW5rIHRoaXMgaXMgYSBiaWcgaGVscC4gIEknbSBz dWdnZXN0aW5nIG1ha2luZyB0aGlzIFNlY3Rpb24gMS4zIGJlY2F1c2UgSSB0aGluayBoYXZpbmcg aXQgdXAgZnJvbnQgbWFrZXMgaXQgdGhlIG1vc3QgdXNlZnVsLg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxLjMgQW4gT3ZlcnZpZXcgb2YgSE9CQS1odHRwIEF1dGhl bnRpY2F0aW9uDQoNCkhPQkEgYXV0aGVudGljYXRpb24gdXNlcyB0aGUgSFRUUCBhdXRoZW50aWNh dGlvbiBmcmFtZXdvcmsgZGVmaW5lZCBpbiANCltSRkM3MjM1XSwgdXNpbmcgYSBudW1iZXIgb2Yg SE9CQS1zcGVjaWZpYyBlbGVtZW50cy4gIFRoaXMgaXMgYSBoaWdoLWxldmVsIA0Kb3ZlcnZpZXcg b2YgSE9CQS1odHRwIGF1dGhlbnRpY2F0aW9uOg0KDQoxLiBJZiB0aGUgdXNlciBpcyBub3QgYWxy ZWFkeSByZWdpc3RlcmVkIHdpdGggdGhlIHdlYi1vcmlnaW4gYW5kIHJlYWxtIGl0IGlzIA0KdHJ5 aW5nIHRvIGFjY2VzcywgdGhlICJqb2luaW5nIiBwcm9jZXNzIGlzIGludm9rZWQgKHNlZSBTZWN0 aW9uIDYuMSkuICBUaGlzIA0KY3JlYXRlcyBhIGtleSBwYWlyIGFuZCBtYWtlcyB0aGUgQ1BLIGtu b3duIHRvIHRoZSBzZXJ2ZXIuDQoNCjIuIFRoZSBjbGllbnQgY29ubmVjdHMgdG8gdGhlIHNlcnZl ciBhbmQgbWFrZXMgYSByZXF1ZXN0LCBhbmQgdGhlIHNlcnZlcidzIA0KcmVzcG9uc2UgaW5jbHVk ZXMgYSBXV1ctQXV0aGVudGljYXRlIGhlYWRlciBmaWVsZCB0aGF0IGNvbnRhaW5zIHRoZSAiSE9C QSIgDQphdXRoLXNjaGVtZSwgYWxvbmcgd2l0aCBhc3NvY2lhdGVkIHBhcmFtZXRlcnMgKHNlZSBT ZWN0aW9uIDMpLg0KDQozLiBUaGUgY2xpZW50IHVzZXMgdGhlIGNoYWxsZW5nZSBmcm9tIHRoZSBI T0JBIGF1dGgtc2NoZW1lIHBhcmFtZXRlcnMsIGFsb25nIA0Kd2l0aCBvdGhlciBpbmZvcm1hdGlv biBpdCBrbm93cyBhYm91dCB0aGUgd2ViLW9yaWdpbiBhbmQgcmVhbG0sIHRvIGNyZWF0ZSANCmFu ZCBzaWduIGEgSE9CQS1UQlMgc3RyaW5nIChzZWUgU2VjdGlvbiAyKS4NCg0KNC4gVGhlIGNsaWVu dCBjcmVhdGVzIGEgSE9CQSBjbGllbnQtcmVzdWx0IChIT0JBLVJFUyksIHVzaW5nIHRoZSBzaWdu ZWQgDQpIT0JBLVRCUyBmb3IgdGhlICJzaWciIHZhbHVlIChzZWUgU2VjdGlvbiAyKS4NCg0KNS4g VGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgQXV0aG9yaXphdGlvbiBoZWFkZXIgZmllbGQgaW4gaXRz IG5leHQgcmVxdWVzdCwgDQp1c2luZyB0aGUgIkhPQkEiIGF1dGgtc2NoZW1lIGFuZCBwdXR0aW5n IHRoZSBIT0JBIGNsaWVudC1yZXN1bHQgaW4gYW4gDQphdXRoLXBhcmFtIG5hbWVkICJyZXN1bHQi IChzZWUgU2VjdGlvbiAzKS4NCg0KNi4gVGhlIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBIT0JB IGNsaWVudC1yZXN1bHQgKHNlZSBTZWN0aW9uIDUuMykuDQoNCjcuIFR5cGljYWxseSwgdGhlIHNl cnZlcidzIHJlc3BvbnNlIGluY2x1ZGVzIGEgc2Vzc2lvbiBjb29raWUgdGhhdCBhbGxvd3MgDQp0 aGUgY2xpZW50IHRvIGluZGljYXRlIGl0cyBhdXRoZW50aWNhdGlvbiBzdGF0ZSBpbiBmdXR1cmUg cmVxdWVzdHMgKHNlZSANClNlY3Rpb24gMS4xKS4NCg0KW1lvdSBtaWdodCBpbmNsdWRlIGFuIGV4 YW1wbGUgaGVyZSwgYXMgSnVsaWFuIHN1Z2dlc3RzLiAgT3IgcGVyaGFwcyB5b3UgbWlnaHQgcHV0 IGFuIGV4YW1wbGUgaW4gYW4gYXBwZW5kaXgsIGFuZCBqdXN0IGNpdGUgaXQgaGVyZS5dDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUGxlYXNlIGxldCBtZSBrbm93 IHdoYXQgeW91IHRoaW5rLg0KDQpCYXJyeQ0KDQo= From nobody Tue Jan 6 06:48:22 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377DC1A8839; Tue, 6 Jan 2015 06:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtO8D1iIhJkE; Tue, 6 Jan 2015 06:48:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534091A87AE; Tue, 6 Jan 2015 06:48:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C0478BE64; Tue, 6 Jan 2015 14:48:11 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcqNKdEnmk_v; Tue, 6 Jan 2015 14:48:11 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6219BBE7C; Tue, 6 Jan 2015 14:48:09 +0000 (GMT) Message-ID: <54ABF5A9.3090700@cs.tcd.ie> Date: Tue, 06 Jan 2015 14:48:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba , Barry Leiba References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54ABAF30.8040207@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E90C@dfweml704-chm> In-Reply-To: <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E90C@dfweml704-chm> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/rLFMoI2wOX6Pvg0BkiuoeqEY18Y Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:48:17 -0000 Hiya, On 06/01/15 14:05, Barry Leiba wrote: >>> This document would benefit from some section somewhere giving a >>> set of clear, numbered steps, saying who sends, who receives, and >>> who does what with what input at each step. I will propose such >>> text. >> >> And I'll happily look at that when it's available. (And hope to not >> have to wait much:-) > > And here we go; Thanks for being timely. > not a lot, but I think it really helps. Of course, > adjust it if I got anything wrong or worded inaccurately. Note how > the section references jump around -- that's why I found it hard to > follow, and why I think this is a big help. I'm suggesting making > this Section 1.3 because I think having it up front makes it the most > useful. Yeah, TBH I think that's superflous but harmless and doesn't replicate text already elsewhere so I've put it in (same [1,2] as before work) almost as-is. Cheers, S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > > ------------------------------------- 1.3 An Overview of HOBA-http > Authentication > > HOBA authentication uses the HTTP authentication framework defined in > [RFC7235], using a number of HOBA-specific elements. This is a > high-level overview of HOBA-http authentication: > > 1. If the user is not already registered with the web-origin and > realm it is trying to access, the "joining" process is invoked (see > Section 6.1). This creates a key pair and makes the CPK known to the > server. > > 2. The client connects to the server and makes a request, and the > server's response includes a WWW-Authenticate header field that > contains the "HOBA" auth-scheme, along with associated parameters > (see Section 3). > > 3. The client uses the challenge from the HOBA auth-scheme > parameters, along with other information it knows about the > web-origin and realm, to create and sign a HOBA-TBS string (see > Section 2). > > 4. The client creates a HOBA client-result (HOBA-RES), using the > signed HOBA-TBS for the "sig" value (see Section 2). > > 5. The client includes the Authorization header field in its next > request, using the "HOBA" auth-scheme and putting the HOBA > client-result in an auth-param named "result" (see Section 3). > > 6. The server authenticates the HOBA client-result (see Section > 5.3). > > 7. Typically, the server's response includes a session cookie that > allows the client to indicate its authentication state in future > requests (see Section 1.1). > > [You might include an example here, as Julian suggests. Or perhaps > you might put an example in an appendix, and just cite it here.] > > ------------------------------------- > > Please let me know what you think. > > Barry > From mike@fresheez.com Tue Jan 6 08:02:20 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EC01A005D for ; Tue, 6 Jan 2015 08:02:20 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzesl8uWXQfg for ; Tue, 6 Jan 2015 08:02:14 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AA11A000C for ; Tue, 6 Jan 2015 08:02:14 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id r10so30781091pdi.9 for ; Tue, 06 Jan 2015 08:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fresheez.com; s=fluffulence; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Xn+TJDKks/m35tbZCo3zlZDsqo8/cInlTwlTe0kq+LY=; b=BL6aMvEafui47PUnB4da4X1A2jMfJFp3qMapHOBM9sYycBDn1D0g8SZYPk3ZBxXEE6 ZYgdnWKqizPdt16DoZ5tLCCDTcjdj/5GrTdk7Uyu19fYAaCbWMAGLD1HpSiUhZyFzT7h A2Se1fJJpSNFT8pCsXnEXiVvY9GtDrMRKjVOw= 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; bh=Xn+TJDKks/m35tbZCo3zlZDsqo8/cInlTwlTe0kq+LY=; b=Qt463x7U75aJjq1aU0Mh4/94tan6uf+X7lNH0rrAIfHv6Tskshq8xRAtkXslUBQXgc xX2TKf/Xjl4GSGN1ppL0MCKOYDAuw54p7JrlC7IITCqIvgsaIU5EMLPhD7sfhKojBN0J mGvKuHNWpA2uMe8Yy8ehbtIucDmIEd03iPucY7/Xcx/57JXyvrg9uxmlYvUQ8IQkHBer lMY7x54TcgMDSvEc7RVuLu+fb2eVTs/aovVbIFjtVO+Kt4dqYYwWH7CmySTWKly0KrRz G1OJVEJxRWyrhV9ZAuMjXRVde8tuH+zQVxKtBQArOoHulNZWQqD262/mGYVi9JEgVVeU Z7nA== X-Gm-Message-State: ALoCoQkg0nUwwwcUkJ/JJL4HPb4LvdxqbQiAbqG1CX2ZRM1RkWuk3odhUH/gZ9Gw+l33HiLFajX3 X-Received: by 10.68.134.3 with SMTP id pg3mr159567472pbb.84.1420560132757; Tue, 06 Jan 2015 08:02:12 -0800 (PST) Received: from takifugu.mtcc.com (mtcc.com. [50.0.18.224]) by mx.google.com with ESMTPSA id bl10sm57764953pac.23.2015.01.06.08.02.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jan 2015 08:02:11 -0800 (PST) Message-ID: <54AC0701.3020703@fresheez.com> Date: Tue, 06 Jan 2015 08:02:09 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Barry Leiba , Stephen Farrell , Barry Leiba References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54ABAF30.8040207@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E90C@dfweml704-chm> In-Reply-To: <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E90C@dfweml704-chm> Content-Type: multipart/alternative; boundary="------------090908030905070904040306" Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ep7ThmscbMXXh_T9ZelC4oQMMTc X-Mailman-Approved-At: Tue, 06 Jan 2015 08:06:00 -0800 Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:04:56 -0000 This is a multi-part message in MIME format. --------------090908030905070904040306 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks, Barry. The programmer in me thinks these are very useful too. Mike On 01/06/2015 06:05 AM, Barry Leiba wrote: >>> This document would benefit from some section somewhere giving a set >>> of clear, numbered steps, saying who sends, who receives, and who does >>> what with what input at each step. I will propose such text. >> And I'll happily look at that when it's available. (And hope to not have >> to wait much:-) > > 1. > And here we go; not a lot, but I think it really helps. Of course, adjust it if I got anything wrong or worded inaccurately. Note how the section references jump around -- that's why I found it hard to follow, and why I think this is a big help. I'm suggesting making this Section 1.3 because I think having it up front makes it the most useful. > > ------------------------------------- > 1.3 An Overview of HOBA-http Authentication > > HOBA authentication uses the HTTP authentication framework defined in > [RFC7235], using a number of HOBA-specific elements. This is a high-level > overview of HOBA-http authentication: > > 1. If the user is not already registered with the web-origin and realm it is > trying to access, the "joining" process is invoked (see Section 6.1). This > creates a key pair and makes the CPK known to the server. > > 2. The client connects to the server and makes a request, and the server's > response includes a WWW-Authenticate header field that contains the "HOBA" > auth-scheme, along with associated parameters (see Section 3). > > 3. The client uses the challenge from the HOBA auth-scheme parameters, along > with other information it knows about the web-origin and realm, to create > and sign a HOBA-TBS string (see Section 2). > > 4. The client creates a HOBA client-result (HOBA-RES), using the signed > HOBA-TBS for the "sig" value (see Section 2). > > 5. The client includes the Authorization header field in its next request, > using the "HOBA" auth-scheme and putting the HOBA client-result in an > auth-param named "result" (see Section 3). > > 6. The server authenticates the HOBA client-result (see Section 5.3). > > 7. Typically, the server's response includes a session cookie that allows > the client to indicate its authentication state in future requests (see > Section 1.1). > > [You might include an example here, as Julian suggests. Or perhaps you might put an example in an appendix, and just cite it here.] > > ------------------------------------- > > Please let me know what you think. > > Barry > --------------090908030905070904040306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Thanks, Barry. The programmer in me thinks these are very useful too.

Mike

On 01/06/2015 06:05 AM, Barry Leiba wrote:
This document would benefit from some section somewhere giving a set 
of clear, numbered steps, saying who sends, who receives, and who does 
what with what input at each step.  I will propose such text.

And I'll happily look at that when it's available. (And hope to not have
to wait much:-)

  1. And here we go; not a lot, but I think it really helps.  Of course, adjust it if I got anything wrong or worded inaccurately.  Note how the section references jump around -- that's why I found it hard to follow, and why I think this is a big help.  I'm suggesting making this Section 1.3 because I think having it up front makes it the most useful.

-------------------------------------
1.3 An Overview of HOBA-http Authentication

HOBA authentication uses the HTTP authentication framework defined in 
[RFC7235], using a number of HOBA-specific elements.  This is a high-level 
overview of HOBA-http authentication:

1. If the user is not already registered with the web-origin and realm it is 
trying to access, the "joining" process is invoked (see Section 6.1).  This 
creates a key pair and makes the CPK known to the server.

2. The client connects to the server and makes a request, and the server's 
response includes a WWW-Authenticate header field that contains the "HOBA" 
auth-scheme, along with associated parameters (see Section 3).

3. The client uses the challenge from the HOBA auth-scheme parameters, along 
with other information it knows about the web-origin and realm, to create 
and sign a HOBA-TBS string (see Section 2).

4. The client creates a HOBA client-result (HOBA-RES), using the signed 
HOBA-TBS for the "sig" value (see Section 2).

5. The client includes the Authorization header field in its next request, 
using the "HOBA" auth-scheme and putting the HOBA client-result in an 
auth-param named "result" (see Section 3).

6. The server authenticates the HOBA client-result (see Section 5.3).

7. Typically, the server's response includes a session cookie that allows 
the client to indicate its authentication state in future requests (see 
Section 1.1).

[You might include an example here, as Julian suggests.  Or perhaps you might put an example in an appendix, and just cite it here.]

-------------------------------------

Please let me know what you think.

Barry

--------------090908030905070904040306-- From nobody Tue Jan 6 08:25:03 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884641A017F for ; Tue, 6 Jan 2015 08:24:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFMAMMRiJ0hZ for ; Tue, 6 Jan 2015 08:24:58 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF26A1A01C6 for ; Tue, 6 Jan 2015 08:24:46 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id p10so30683932pdj.13 for ; Tue, 06 Jan 2015 08:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fresheez.com; s=fluffulence; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C50IUVIL64d0kMN99wUakhMGx8lXTDRXMaR71oatBPM=; b=CvAkD448a6gpkbMM2bapypK+Ac7F8+FI/C501RLa0fRY5k9d+9KMjzIZbEwr3yB3JL 7u0CpAToVygWUVPBhgzBkcGPpAquJqbJL6+/Aox5Hg7fGjvuFVMZSUG597/kzATfFHE5 iCk6m75iN//I7uK1vr67Mc3NLxI01gnvkB7i0= 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=C50IUVIL64d0kMN99wUakhMGx8lXTDRXMaR71oatBPM=; b=cN1yeblAbv3VwP5A3VVQttbYfm2H2LCOhxk3bxWfz9T0U8Bd+EU7c+pvWKQJzoip3k uxwDE2/S7Pg71JIwir3XTcSLpbh32XqAy8yOJ5rtfHi8r8nSC27nghIMRc3ttum1MImT 2HUwBhQnee/4Hojr+R2HtpHyiod4VzeHOTEBs8KzNHxt66wfk/yo2liqwBEFX98sUpuL v7xSjRYLvNq6H7A9kQrhrNxGHglpsvTNjU+pp1fyVzy0I9K/6DQMkre8CulgpXyqNiv9 ZLgLa5p0lOwbF0yDcPBVVQZF5Aj/JKebwSJySyBqWjn8yu8SbHr26jtuCFWT//gK0oaM D3sw== X-Gm-Message-State: ALoCoQmi/TXYnoJ3Kw+OxExrwQBXbNa5Gby6XRgxHHlqB1zv7UByYO63a5yoPFXbvvYC2gM8QfOs X-Received: by 10.66.146.167 with SMTP id td7mr81146215pab.101.1420561485958; Tue, 06 Jan 2015 08:24:45 -0800 (PST) Received: from takifugu.mtcc.com (mtcc.com. [50.0.18.224]) by mx.google.com with ESMTPSA id c17sm57503857pdl.6.2015.01.06.08.24.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jan 2015 08:24:44 -0800 (PST) Message-ID: <54AC0C4B.9070608@fresheez.com> Date: Tue, 06 Jan 2015 08:24:43 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Barry Leiba , Stephen Farrell References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54AB9870.50505@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/upW4u9r43HzVazNvUgDkrv1wjEw Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:24:59 -0000 On 01/06/2015 12:20 AM, Barry Leiba wrote: > > Yet here we still are? :-) > Because I think the discussion needs to continue. I still don't > understand why you think it's so important to single out LinkedIn, > such that it's worth the damage that having that in an RFC represents. > >>> The fact that there's a plethora of examples really speaks to not >>> calling out one company on this, >> I re-iterate: At the time of writing this was the poster-child >> example. It still remains one, and a good one for RFC readers. > It was not "the poster child": there have been so many of these > breaches, both before and since, that I see no reason at all to call > out any one instance. I'm pretty sure that I'm responsible for the offending text and it was enough of a a poster child in my mind because my JS implementation was a direct response in an "enough is enough" way. Yes, there have been lots of these but if a large, well known, well funded company is vulnerable, how can we expect everybody else to not fall prey? The problem isn't with LinkedIn per se -- and it makes me extremely angry when the finger waggers inevitably blame end users -- it's with password schemes in general, which is a failure of engineering. FWIW, I don't see LinkedIn in this case as "name and shame" but more of "this too can be YOU" example. For that reason, I think it's better to leave it in as a cautionary tale instead of diluting it down to non-specific "others". Mike From nobody Wed Jan 7 06:29:37 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF391A906C; Wed, 7 Jan 2015 06:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v28VKlVD7231; Wed, 7 Jan 2015 06:29:25 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADA21A906B; Wed, 7 Jan 2015 06:29:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 281F02CEFB; Wed, 7 Jan 2015 16:29:24 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTzrfhtO6nGv; Wed, 7 Jan 2015 16:29:15 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 5C13C2CC4D; Wed, 7 Jan 2015 16:29:15 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_2457EA9F-96E5-4556-839B-7B5B91C26AF4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: Date: Wed, 7 Jan 2015 16:29:14 +0200 Message-Id: References: To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/mGcOs8z8CggI4MhzFn3aehib5fY Cc: "ops-dir@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "paul.hoffman@vpnc.org" , "http-auth@ietf.org" , "mike@phresheez.com" Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-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, 07 Jan 2015 14:29:32 -0000 --Apple-Mail=_2457EA9F-96E5-4556-839B-7B5B91C26AF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the review, David, and thank you Stephen and Julian for = working on the issues. I have placed a no-objection position for this = document on tomorrow=92s IESG telechat. Jari --Apple-Mail=_2457EA9F-96E5-4556-839B-7B5B91C26AF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUrUK6AAoJEM80gCTQU46qGfcP/2psQe8Mlmp6Ka2LPO1s+cDv 6hzDMPfkY27WWiHsAlJI6pjRbc9m4zEQddbyZdYMdJ3fgqQI/VOr8cgCVcti3DCc HK539ZUIjpLA8kN/uLTVjdWmcp+TYAwvOoeq4JnTi2eNBsRbqk6x2D65v8qWNwVe lReVMpEfuD7e5FslZnl80mmfcVAzV1UiFUhLhwJSg51TkxKIyf4clx5QNrtCQpIB SwXWeW4LIShao5PXviLUV7TAeX/TAjijxzN5dFNCkn/vigM4Ccuq16Y8d0UGxqt9 XdZWp9O+uXZBT5QMUnxELVePEEeKD3hadq1daRkWjElNOc0OxWaAFyfzS71sAZ7o MNLiFik2ez8FP8FdPW+lW4nl1C+0DKd587WnqbJullsd1OVE2uH/d+mqTbMCzL75 lsCWRxSrwgrziqKMEffQwk3z+DdtcuH4AfGT9AOqJgmDj2rhJcEEywcbDBtjpjRa amhHIAE/6ATjjCcarklccRLRsVDhrh1xeSYUk6crCHScPvExD4zme22WwwGsJFDo B6fi5Iv4U2UTcD3AGrkVLMHI/RGdqZAHfzTFuM6dn8BlRT5fD+BioNltqkwpaAss +piR1R+XU2cvjo+Pdvv7qxEfrXK3AbUnUt3N6jDNFcYP8uICexXIwcW0zLo3iqBN XUYgSwvdVTPTOTin6Mrl =Pk95 -----END PGP SIGNATURE----- --Apple-Mail=_2457EA9F-96E5-4556-839B-7B5B91C26AF4-- From nobody Wed Jan 7 12:48:31 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C651A1B69; Wed, 7 Jan 2015 12:48:29 -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 2gyZk8YVqZxU; Wed, 7 Jan 2015 12:48:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC561A1B34; Wed, 7 Jan 2015 12:48:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107204827.4676.82945.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 12:48:27 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/iYx6u1VPyQREFovjujC6Smm3o9Q Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 20:48:29 -0000 Pete Resnick has entered the following ballot position for draft-ietf-httpauth-hoba-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Yay HOBA! Very good that we are finally doing this thing. Totally nitty things here. Barry covered anything substantive that I found: - Use of the word "we" always makes me gag in IETF documents. Blech. For example, in 1.2 (2 times): OLD We use this term when describing something that is NEW This term is used when describing something that is Passive voice is under-rated for some things. There are 9 other uses of "we" throughout the doc. We would be happy if we changed them. - The last paragraph of section 2 is (a) ungrammatical and (b) seems more like it belongs in section 1. - Grammatical 2119 fussiness: OLD UAs MAY optimise their use of challenges by pre-fetching a challenge NEW To optimise their use of challenges, UAs MAY pre-fetch a challenge From nobody Wed Jan 7 14:42:53 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1F31A1B94; Wed, 7 Jan 2015 14:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw6IK4mwhZh8; Wed, 7 Jan 2015 14:42:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75421A1B93; Wed, 7 Jan 2015 14:42:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2AF2BBECA; Wed, 7 Jan 2015 22:42:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czrRpq89Nlze; Wed, 7 Jan 2015 22:42:41 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A6647BEC0; Wed, 7 Jan 2015 22:42:41 +0000 (GMT) Message-ID: <54ADB661.9080108@cs.tcd.ie> Date: Wed, 07 Jan 2015 22:42:41 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Pete Resnick , The IESG References: <20150107204827.4676.82945.idtracker@ietfa.amsl.com> In-Reply-To: <20150107204827.4676.82945.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/kh_IGI4y0S_ZwBgKK8n3DE0FYKw Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 22:42:48 -0000 Hiya, On 07/01/15 20:48, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-httpauth-hoba-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Yay HOBA! Very good that we are finally doing this thing. Totally nitty > things here. Barry covered anything substantive that I found: > > - Use of the word "we" always makes me gag in IETF documents. Blech. For > example, in 1.2 (2 times): > > OLD > We use this term when describing something that is > NEW > This term is used when describing something that is > > Passive voice is under-rated for some things. There are 9 other uses of > "we" throughout the doc. We would be happy if we changed them. We would prefer not. > > - The last paragraph of section 2 is (a) ungrammatical and (b) seems more > like it belongs in section 1. > > - Grammatical 2119 fussiness: > > OLD > UAs MAY optimise their use of challenges by pre-fetching a challenge > NEW > To optimise their use of challenges, UAs MAY pre-fetch a challenge Sure, fixed in working draft. S. > > From nobody Wed Jan 7 14:56:26 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BFF1A6FF3; Wed, 7 Jan 2015 14:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXdCju1GGj3p; Wed, 7 Jan 2015 14:56:22 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7DF1A1EF9; Wed, 7 Jan 2015 14:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1420671382; x=1452207382; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AK6LsOCek4EpPqpeVbB8UmVb5w2IHWlT8FEq6gj2keE=; b=FTy/PoF2Sdc/8jbaEirEsbz9Ff17+3UtxDvpIgLF5M0qfv6nIMhOdbqI kT9QB2wbkwfdtQhBjCLGqU0UxUGe6voU5D6fd7fwf7TQ1d1VLL9T90bhL xda2ZMfTlMqIbsnypbRbfwb0yloWJdqWn8+T+i0vrna1jKqyQjb8/D3rb o=; X-IronPort-AV: E=McAfee;i="5600,1067,7674"; a="97035998" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jan 2015 14:56:22 -0800 X-IronPort-AV: E=Sophos;i="5.07,717,1413270000"; d="scan'208";a="879371014" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Jan 2015 14:56:21 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 7 Jan 2015 14:56:20 -0800 Message-ID: <54ADB993.9030203@qti.qualcomm.com> Date: Wed, 7 Jan 2015 16:56:19 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <20150107204827.4676.82945.idtracker@ietfa.amsl.com> <54ADB661.9080108@cs.tcd.ie> In-Reply-To: <54ADB661.9080108@cs.tcd.ie> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/KN2-wICzwGWqehjJTEv8JgP3sDA Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, The IESG Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 22:56:24 -0000 On 1/7/15 4:42 PM, Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Yay HOBA! Very good that we are finally doing this thing. Totally nitty >> things here. Barry covered anything substantive that I found: >> >> - Use of the word "we" always makes me gag in IETF documents. Blech. For >> example, in 1.2 (2 times): >> >> OLD >> We use this term when describing something that is >> NEW >> This term is used when describing something that is >> >> Passive voice is under-rated for some things. There are 9 other uses of >> "we" throughout the doc. We would be happy if we changed them. >> > We would prefer not. > I will do what I can to avoid weeping into my beer. The world will not stop turning either way. >> - The last paragraph of section 2 is (a) ungrammatical and (b) seems more >> like it belongs in section 1. >> >> - Grammatical 2119 fussiness: >> >> OLD >> UAs MAY optimise their use of challenges by pre-fetching a challenge >> NEW >> To optimise their use of challenges, UAs MAY pre-fetch a challenge >> > Sure, fixed in working draft. > Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Jan 7 14:56:45 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B881A1BAC; Wed, 7 Jan 2015 14:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 r3dV9J2cZrcu; Wed, 7 Jan 2015 14:20:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 024871A6F2C; Wed, 7 Jan 2015 14:20:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 14:20:27 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/DNgUTsqxKrcQFx0eEwpjF_q1ClI X-Mailman-Approved-At: Wed, 07 Jan 2015 14:56:44 -0800 Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 22:20:48 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-httpauth-hoba-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Good stuff! Couple of comments. = Logging out = The intro says "Logout features can be useful for UAs, so HOBA defines a way to close a current HTTP "session", and also a way to close all current sessions, even if more than one session is currently active from different UAs for the same account." But the method specified in 6.3 seems to only accomplish the first of these (assuming the recommendation about server deletion of cookies related to "the session" is meant to be specific to one session). What is the method for logging out of all sessions associated with different UAs for the same account? = Section 6.1 = Either the device identifier/device identifier type bits are underspecified, or it's not clear to me how they are meant to be used. What other device identifier types are expected to be used in the future, such that a registry of them is necessary? To me it seems like you would want UAs/users to take some care with the precision of the device identifiers shared with servers -- e.g., "Alissa's laptop" seems like it could be useful and fairly safe, whereas "IMEI 013584009812219" seems like total overkill and a bad idea. (As an aside, it might be good to provide some guidance about this in the document.) The creation of the registry makes me wonder if more structured device identifiers of the IMEI-ilk are envisioned, and if so what the purpose of them is expected to be? Also, I would suggest s/if absent then the "string" form of device identifier MUST be used./if absent then the "string" form of device identifier defined in Section 9.5 MUST be used. = Section 8 = "Binding my CPK with someone else's account would be fun and profitable so SHOULD be appropriately hard." Sarcasm translates pretty poorly across cultures. I would suggest saying what you actually mean here. = Section 8.2 = If you want to leave in the LinkedIn reference, or any specific example, it needs a citation. From nobody Wed Jan 7 15:13:33 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64C1A6FFD; Wed, 7 Jan 2015 15:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY4Zb8ctbos1; Wed, 7 Jan 2015 15:13:12 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F081A701A; Wed, 7 Jan 2015 15:13:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E7187BE88; Wed, 7 Jan 2015 23:13:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOkoHD4Fh5mJ; Wed, 7 Jan 2015 23:12:59 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E371ABE75; Wed, 7 Jan 2015 23:12:58 +0000 (GMT) Message-ID: <54ADBD79.4090201@cs.tcd.ie> Date: Wed, 07 Jan 2015 23:12:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> In-Reply-To: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/kzAkoMAZC7knxIBko-ILymgADw8 Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: Re: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 23:13:20 -0000 Hiya, Two non-trivial changes here, see below, but also please check that though, working copy is at [1], diff vs. -09 at [2] as usual. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt On 07/01/15 22:20, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-httpauth-hoba-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Good stuff! Couple of comments. > > = Logging out = > > The intro says > > "Logout features can be useful for UAs, so HOBA defines a way to > close a current HTTP "session", and also a way to close all > current sessions, even if more than one session is currently > active from different UAs for the same account." > > But the method specified in 6.3 seems to only accomplish the first of > these (assuming the recommendation about server deletion of cookies > related to "the session" is meant to be specific to one session). What is > the method for logging out of all sessions associated with different UAs > for the same account? Oops that's a relic, good catch. Deleted from "...and also a way" to the end. My code doesn't have that anymore, I didn't check other folks. We could always add it back later if needed, it'd just be one more .well-knonw/hoba thing. (And in case you ask, sorry but I forget when/why we dropped that or if it was because it didn't work or out of laziness or someone's objection:-) > > = Section 6.1 = > > Either the device identifier/device identifier type bits are > underspecified, or it's not clear to me how they are meant to be used. > What other device identifier types are expected to be used in the future, > such that a registry of them is necessary? To me it seems like you would > want UAs/users to take some care with the precision of the device > identifiers shared with servers -- e.g., "Alissa's laptop" seems like it > could be useful and fairly safe, whereas "IMEI 013584009812219" seems > like total overkill and a bad idea. (As an aside, it might be good to > provide some guidance about this in the document.) The creation of the > registry makes me wonder if more structured device identifiers of the > IMEI-ilk are envisioned, and if so what the purpose of them is expected > to be? Nobody had mentioned IMEIs but that's a very good point since most devices have something like that it'd be bad to use. The idea of the registry for dids was that they might be part of the registration flow that a site used (hence not specified here), so e.g. account creation for phones might differ from that for tablets or laptops. (And no, I don't think we yet know enough to do a good job on defining those right now, so how to use this well would be a part of the experiment I figure. And now I'm hoping we don't get asked to say all that in the draft;-) I added text about possible privacy issue in both 8.1 and 9.5. 8.1, NEW: Device identifiers are intended to specify classes of device in a way that can assist with registration and with presentation to the user of information about previous sessions, e.g. last login time. Device identifier types MUST NOT be privacy sensitive, with values that would allow tracking a user in unexpected ways. In particular, using an device identifier type that is analogous to the International Mobile Equipment Identifier (IMEI) would be a really bad idea and is the reason for the MUST NOT above. In that case "mobile phone" could be an acceptable choice. If possible, implementations ought encourage use of device identifier values that are not personally identifying except for the user concerned, for example "Alice's mobile" is likely to be chosen and is somewhat identifying but "Alice's phone: UUID 1234-5567-89abc-def0" would be a very bad choice. 9.5, NEW: The designated expert for this registry is to carefully pay attention to the notes on this field in Section 8.1, in particular the "MUST NOT" stated therein. Happy to wordsmith that some more and we probably will want to. (Isn't it interesting how even those of us who care about this kind of thing can miss it entirely;-) > > Also, I would suggest > > s/if absent then the "string" form of device identifier MUST be used./if > absent then the "string" form of device identifier defined in Section 9.5 > MUST be used. Sure > > = Section 8 = > > "Binding my CPK with someone else's account would be fun and > profitable so SHOULD be appropriately hard." > > Sarcasm translates pretty poorly across cultures. I would suggest saying > what you actually mean here. Wasn't meant to be sarcastic at all. I guess it is a little opaque but surely the threat is so obvious that the "fun and profit" colloquialism is ok. > > = Section 8.2 = > > If you want to leave in the LinkedIn reference, or any specific example, > it needs a citation. Yep, I added one to the working copy. It's wikipedia but I've wrangled that with the RFC editor before via the wiki permanent URL feature:-) Cheers, S. > > From nobody Wed Jan 7 16:20:23 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B721AC39E; Wed, 7 Jan 2015 16:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 P0l6vbWZEkuK; Wed, 7 Jan 2015 16:20:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E7D1AC39A; Wed, 7 Jan 2015 16:20:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 16:20:15 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/LdtNdoyyqiCjMobK-v8wXg2O8j4 Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 00:20:19 -0000 Richard Barnes has entered the following ballot position for draft-ietf-httpauth-hoba-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) It does not seem to me that the mechanism defined in this document actually conforms to the framework for HTTP authentication. The general framework defined in RFC 7235 is all scoped to a resource -- you can implement authorization for a specific resource, without impacting anything else on the server. HOBA, by contrast, requires the authenticating resource to be also be correlated to several resource under .well-known, meaning that it will not be usable in a large number of deployment circumstances. Was this issue discussed in the WG, and was there input from the broader HTTP community? (2) What is your justification for using a SHA-1 based signature in a new protocol, when it is being actively deprecated elsewhere, in particular the web PKI? (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST (4) Given that the size of the header seems to be a concern (since you're not passing the key in the header), why are there no ECC signing algorithms defined? It seems like if you used any of the normal curves, you could comfortably pass the key along with the authentication value. (5) For that matter, why bother defining a new algorithm registry at all, when JWA provides a perfectly nice one that only costs you 4 characters. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The HOBA-TBS construction seems really unnecessarily complicated. Other than in the "origin" component, there are no ":" characters allowed in any of the components, so if you could remove the unnecessarily pretty serialization of the origin, you could just use ':' as a delimiter. Or leave the origin, and delimit with something like %x20. Either way, this length construction seems like a pain to implement by comparison. "alg = 1*2DIGIT" - In general, it seems unwise to limit code point spaces unnecessarily. In addition to the funny title of Section 6.2.2, the contents seem kind of risible as well. Making a OTP is 100% equivalent to the mechanism recommended in Section 6.2.3, and arguably more likely to deploy (since the OTP doesn't have special semantics of being a URI). Please update the algorithms so that the reader doesn't have to go look up which algorithm this is (PKCS1 vs. PSS). OLD: "RSA is defined in Section 8.2 of [RFC3447]" NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of [RFC3447]" Given how convoluted the use case is here, an example would be very helpful. At the very least to demonstrate the syntax of the WWW-Authenticate header. From nobody Wed Jan 7 16:39:21 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EC91A8777; Wed, 7 Jan 2015 16:39:13 -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 kzfD4kt-s6rd; Wed, 7 Jan 2015 16:39:10 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB70F1A876F; Wed, 7 Jan 2015 16:39:09 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id z107so66576qgd.4; Wed, 07 Jan 2015 16:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NOlCfQwh/v12PIcPaPSn0/2B5KE9OLO26ZB0b8OuQP8=; b=b+Ofp9x+q0PACoidWYK0igv6pHPqYtn1QO6dKEGbXAnPY5lkf2ejZ/mlBjGtol1bKM 0i2V6ZBQq3zAB1qDkIpwSEQtAVCM1rEAtMWsnJrP7U/Bw/PCDK1L95pIV3+kKGqxRbUt wX8q1VHOyxmBWKxPRcSy943g5aSLctgOpSXeJTCfyNMKpv84k6d2tm8kmvty6lXxA0Xk xNsW4FmjfQryJHlD5XeVVYP6ZjZyIHUeCscN1H0QaYWN7T2lljhY8F3L+Mvo8AcTNx8G TCxZOsEVGJKkc7VgqVArJWg32l8khazAG1JFk5L6eZ0N7VljDGI7PnyJthdqAtk2IHcB ntzQ== X-Received: by 10.224.50.75 with SMTP id y11mr9867709qaf.89.1420677549134; Wed, 07 Jan 2015 16:39:09 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id u14sm2607404qau.37.2015.01.07.16.39.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 16:39:07 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54ADBD79.4090201@cs.tcd.ie> Date: Wed, 7 Jan 2015 19:39:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> <54ADBD79.4090201@cs.tcd.ie> To: Stephen Farrell Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/gBt4JGESr86MmasiifVwrJbzHkg Cc: "httpauth-chairs@tools.ietf.org" , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , Alissa Cooper , "http-auth@ietf.org" , The IESG Subject: Re: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 00:39:13 -0000 Sent from my iPhone > On Jan 7, 2015, at 6:12 PM, Stephen Farrell wr= ote: >=20 >=20 >=20 > Hiya, >=20 > Two non-trivial changes here, see below, but also please check that > though, working copy is at [1], diff vs. -09 at [2] as usual. >=20 > [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > [2] > https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-httpauth-hoba-09.txt&url2= =3Dhttps://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt >=20 >> On 07/01/15 22:20, Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-httpauth-hoba-09: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> Good stuff! Couple of comments. >>=20 >> =3D Logging out =3D >>=20 >> The intro says >>=20 >> "Logout features can be useful for UAs, so HOBA defines a way to >> close a current HTTP "session", and also a way to close all >> current sessions, even if more than one session is currently >> active from different UAs for the same account." >>=20 >> But the method specified in 6.3 seems to only accomplish the first of >> these (assuming the recommendation about server deletion of cookies >> related to "the session" is meant to be specific to one session). What is= >> the method for logging out of all sessions associated with different UAs >> for the same account? >=20 > Oops that's a relic, good catch. Deleted from "...and also a way" to > the end. My code doesn't have that anymore, I didn't check other > folks. We could always add it back later if needed, it'd just be one > more .well-knonw/hoba thing. (And in case you ask, sorry but I forget > when/why we dropped that or if it was because it didn't work or out > of laziness or someone's objection:-) >=20 >>=20 >> =3D Section 6.1 =3D >>=20 >> Either the device identifier/device identifier type bits are >> underspecified, or it's not clear to me how they are meant to be used. >> What other device identifier types are expected to be used in the future,= >> such that a registry of them is necessary? To me it seems like you would >> want UAs/users to take some care with the precision of the device >> identifiers shared with servers -- e.g., "Alissa's laptop" seems like it >> could be useful and fairly safe, whereas "IMEI 013584009812219" seems >> like total overkill and a bad idea. (As an aside, it might be good to >> provide some guidance about this in the document.) The creation of the >> registry makes me wonder if more structured device identifiers of the >> IMEI-ilk are envisioned, and if so what the purpose of them is expected >> to be? >=20 > Nobody had mentioned IMEIs but that's a very good point since most > devices have something like that it'd be bad to use. The idea of the > registry for dids was that they might be part of the registration > flow that a site used (hence not specified here), so e.g. account > creation for phones might differ from that for tablets or laptops. > (And no, I don't think we yet know enough to do a good job on defining > those right now, so how to use this well would be a part of the > experiment I figure. And now I'm hoping we don't get asked to say > all that in the draft;-) >=20 > I added text about possible privacy issue in both 8.1 and 9.5. >=20 > 8.1, NEW: >=20 > Device identifiers are intended to specify classes of device in a way > that can assist with registration and with presentation to the user > of information about previous sessions, e.g. last login time. >=20 > Device identifier types MUST NOT be privacy sensitive, with values > that would allow tracking a user in unexpected ways. In particular, > using an device identifier type that is analogous to the > International Mobile Equipment Identifier (IMEI) would be a really > bad idea and is the reason for the MUST NOT above. In that case > "mobile phone" could be an acceptable choice. >=20 > If possible, implementations ought encourage use of device identifier > values that are not personally identifying except for the user > concerned, for example "Alice's mobile" is likely to be chosen and is > somewhat identifying but "Alice's phone: UUID 1234-5567-89abc-def0" > would be a very bad choice. >=20 > 9.5, NEW: >=20 > The designated expert for this registry is to carefully pay attention > to the notes on this field in Section 8.1, in particular the "MUST > NOT" stated therein. >=20 > Happy to wordsmith that some more and we probably will want to. >=20 > (Isn't it interesting how even those of us who care about this kind of > thing can miss it entirely;-) >=20 Good catch, thanks Alissa. >>=20 >> Also, I would suggest >>=20 >> s/if absent then the "string" form of device identifier MUST be used./if >> absent then the "string" form of device identifier defined in Section 9.5= >> MUST be used. >=20 > Sure >=20 >>=20 >> =3D Section 8 =3D >>=20 >> "Binding my CPK with someone else's account would be fun and >> profitable so SHOULD be appropriately hard." >>=20 >> Sarcasm translates pretty poorly across cultures. I would suggest saying >> what you actually mean here. >=20 > Wasn't meant to be sarcastic at all. I guess it is a little opaque but > surely the threat is so obvious that the "fun and profit" colloquialism > is ok. I think it's better to replace this text, I agree with Alissa that other cul= tures may have problems with it. Thanks, Kathleen=20 >=20 >>=20 >> =3D Section 8.2 =3D >>=20 >> If you want to leave in the LinkedIn reference, or any specific example, >> it needs a citation. >=20 > Yep, I added one to the working copy. It's wikipedia but I've wrangled > that with the RFC editor before via the wiki permanent URL feature:-) >=20 > Cheers, > S. >=20 >=20 >>=20 >>=20 From nobody Wed Jan 7 16:39:58 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9841A8777; Wed, 7 Jan 2015 16:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, 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 mJzELnY53-Ko; Wed, 7 Jan 2015 16:39:21 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39EED1AC3B4; Wed, 7 Jan 2015 16:39:20 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so381507lbv.11; Wed, 07 Jan 2015 16:39: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=SUYbW+mBDGAFLDIyI93gpk/SZFb+Qaj6Pxmk1JgpYCU=; b=mnYxrrxT/pQiAzX22fcFJRZtViWzzpxklEnVftifXrd+rCuN8yL9fxicVg0OYqkiRv QYxqkTuggssPWWxU20Q0bK/f7nPam1Iowvy1K6e4KLsRpma0emko7PgRs7as2CmekXvN wRornvk7AU6cSHGS2w34IP/6ydPZ50KNvzFTXeHj3nyN87+bPbqaITSVYkiiN0CuCgls TCNq1xDYk2L3mfyGubvWz/P/3VusezWGXLCZD9eREsUH5Xo6dElDj8aGdv06BMsfFg3f MHH8+/ylDJgRE59w0gt+l9VwWy9eDErZyHsjh0YPosvzBn4rYmpT+dbPSxqJ9zLyN13S scSg== MIME-Version: 1.0 X-Received: by 10.112.188.201 with SMTP id gc9mr9525798lbc.6.1420677557647; Wed, 07 Jan 2015 16:39:17 -0800 (PST) Received: by 10.152.185.195 with HTTP; Wed, 7 Jan 2015 16:39:17 -0800 (PST) Received: by 10.152.185.195 with HTTP; Wed, 7 Jan 2015 16:39:17 -0800 (PST) In-Reply-To: <54ADBD79.4090201@cs.tcd.ie> References: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> <54ADBD79.4090201@cs.tcd.ie> Date: Wed, 7 Jan 2015 18:39:17 -0600 Message-ID: From: Spencer Dawkins at IETF To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c3736629feb8050c19457e Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/1ao0m-L7YkdyqxCvJDOchmaAG6A Cc: httpauth-chairs@tools.ietf.org, draft-ietf-httpauth-hoba.all@tools.ietf.org, Alissa Cooper , http-auth@ietf.org, iesg@ietf.org Subject: Re: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 00:39:45 -0000 --001a11c3736629feb8050c19457e Content-Type: text/plain; charset=UTF-8 On Jan 8, 2015 7:13 AM, "Stephen Farrell" wrote: > > > > Hiya, > > Two non-trivial changes here, see below, but also please check that > though, working copy is at [1], diff vs. -09 at [2] as usual. > > [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > [2] > https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > > On 07/01/15 22:20, Alissa Cooper wrote: > > Alissa Cooper has entered the following ballot position for > > draft-ietf-httpauth-hoba-09: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Good stuff! Couple of comments. > > > > = Logging out = > > > > The intro says > > > > "Logout features can be useful for UAs, so HOBA defines a way to > > close a current HTTP "session", and also a way to close all > > current sessions, even if more than one session is currently > > active from different UAs for the same account." > > > > But the method specified in 6.3 seems to only accomplish the first of > > these (assuming the recommendation about server deletion of cookies > > related to "the session" is meant to be specific to one session). What is > > the method for logging out of all sessions associated with different UAs > > for the same account? > > Oops that's a relic, good catch. Deleted from "...and also a way" to > the end. My code doesn't have that anymore, I didn't check other > folks. We could always add it back later if needed, it'd just be one > more .well-knonw/hoba thing. (And in case you ask, sorry but I forget > when/why we dropped that or if it was because it didn't work or out > of laziness or someone's objection:-) > > > > > = Section 6.1 = > > > > Either the device identifier/device identifier type bits are > > underspecified, or it's not clear to me how they are meant to be used. > > What other device identifier types are expected to be used in the future, > > such that a registry of them is necessary? To me it seems like you would > > want UAs/users to take some care with the precision of the device > > identifiers shared with servers -- e.g., "Alissa's laptop" seems like it > > could be useful and fairly safe, whereas "IMEI 013584009812219" seems > > like total overkill and a bad idea. (As an aside, it might be good to > > provide some guidance about this in the document.) The creation of the > > registry makes me wonder if more structured device identifiers of the > > IMEI-ilk are envisioned, and if so what the purpose of them is expected > > to be? > > Nobody had mentioned IMEIs but that's a very good point since most > devices have something like that it'd be bad to use. The idea of the > registry for dids was that they might be part of the registration > flow that a site used (hence not specified here), so e.g. account > creation for phones might differ from that for tablets or laptops. > (And no, I don't think we yet know enough to do a good job on defining > those right now, so how to use this well would be a part of the > experiment I figure. And now I'm hoping we don't get asked to say > all that in the draft;-) > > I added text about possible privacy issue in both 8.1 and 9.5. > > 8.1, NEW: > > Device identifiers are intended to specify classes of device in a way > that can assist with registration and with presentation to the user > of information about previous sessions, e.g. last login time. > > Device identifier types MUST NOT be privacy sensitive, with values > that would allow tracking a user in unexpected ways. In particular, > using an device identifier type that is analogous to the > International Mobile Equipment Identifier (IMEI) would be a really > bad idea and is the reason for the MUST NOT above. In that case > "mobile phone" could be an acceptable choice. > > If possible, implementations ought encourage use of device identifier > values that are not personally identifying except for the user > concerned, for example "Alice's mobile" is likely to be chosen and is > somewhat identifying but "Alice's phone: UUID 1234-5567-89abc-def0" > would be a very bad choice. > > 9.5, NEW: > > The designated expert for this registry is to carefully pay attention > to the notes on this field in Section 8.1, in particular the "MUST > NOT" stated therein. > > Happy to wordsmith that some more and we probably will want to. > > (Isn't it interesting how even those of us who care about this kind of > thing can miss it entirely;-) > > > > > Also, I would suggest > > > > s/if absent then the "string" form of device identifier MUST be used./if > > absent then the "string" form of device identifier defined in Section 9.5 > > MUST be used. > > Sure > > > > > = Section 8 = > > > > "Binding my CPK with someone else's account would be fun and > > profitable so SHOULD be appropriately hard." > > > > Sarcasm translates pretty poorly across cultures. I would suggest saying > > what you actually mean here. > > Wasn't meant to be sarcastic at all. I guess it is a little opaque but > surely the threat is so obvious that the "fun and profit" colloquialism > is ok. > > > > > = Section 8.2 = > > > > If you want to leave in the LinkedIn reference, or any specific example, > > it needs a citation. > > Yep, I added one to the working copy. It's wikipedia but I've wrangled > that with the RFC editor before via the wiki permanent URL feature:-) For what it's worth, I like using a reference for this. Thank you, Alissa, for making the suggestion, and thank you, Stephen, for making the change. I understand the point about the LinkedIn example being a Big Hairy Deal, so pointing to it sounds like a plan. I wonder if it's more effective to say "this happens all the time" in the text, which I understand to be the case, with the reference being to LinkedIn. I'm no security maven, but when I was reading recently about Sony's wizard security practices, I thought to myself, "I'd never do anything that dumb", and kind of stopped there. I wonder if that's more likely if the text calls out any single company. Spencer, who may still be too nice to be an AD ... > Cheers, > S. > > > > > > > --001a11c3736629feb8050c19457e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 8, 2015 7:13 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
>
>
>
> Hiya,
>
> Two non-trivial changes here, see below, but also please check that > though, working copy is at [1], diff vs. -09 at [2] as usual.
>
> =C2=A0 =C2=A0[1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-= hoba-10.txt
> =C2=A0 =C2=A0[2]
> https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-httpauth-hoba-= 09.txt&url2=3Dhttps://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-= 10.txt
>
> On 07/01/15 22:20, Alissa Cooper wrote:
> > Alissa Cooper has entered the following ballot position for
> > draft-ietf-httpauth-hoba-09: No Objection
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > Good stuff! Couple of comments.
> >
> > =3D Logging out =3D
> >
> > The intro says
> >
> > "Logout features can be useful for UAs, so HOBA defines a wa= y to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0close a current HTTP "session"= ;, and also a way to close all
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0current sessions, even if more than one= session is currently
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0active from different UAs for the same = account."
> >
> > But the method specified in 6.3 seems to only accomplish the firs= t of
> > these (assuming the recommendation about server deletion of cooki= es
> > related to "the session" is meant to be specific to one= session). What is
> > the method for logging out of all sessions associated with differ= ent UAs
> > for the same account?
>
> Oops that's a relic, good catch. Deleted from "...and also a = way" to
> the end. My code doesn't have that anymore, I didn't check oth= er
> folks. We could always add it back later if needed, it'd just be o= ne
> more .well-knonw/hoba thing. (And in case you ask, sorry but I forget<= br> > when/why we dropped that or if it was because it didn't work or ou= t
> of laziness or someone's objection:-)
>
> >
> > =3D Section 6.1 =3D
> >
> > Either the device identifier/device identifier type bits are
> > underspecified, or it's not clear to me how they are meant to= be used.
> > What other device identifier types are expected to be used in the= future,
> > such that a registry of them is necessary? To me it seems like yo= u would
> > want UAs/users to take some care with the precision of the device=
> > identifiers shared with servers -- e.g., "Alissa's lapto= p" seems like it
> > could be useful and fairly safe, whereas "IMEI 0135840098122= 19" seems
> > like total overkill and a bad idea. (As an aside, it might be goo= d to
> > provide some guidance about this in the document.) The creation o= f the
> > registry makes me wonder if more structured device identifiers of= the
> > IMEI-ilk are envisioned, and if so what the purpose of them is ex= pected
> > to be?
>
> Nobody had mentioned IMEIs but that's a very good point since most=
> devices have something like that it'd be bad to use. The idea of t= he
> registry for dids was that they might be part of the registration
> flow that a site used (hence not specified here), so e.g. account
> creation for phones might differ from that for tablets or laptops.
> (And no, I don't think we yet know enough to do a good job on defi= ning
> those right now, so how to use this well would be a part of the
> experiment I figure. And now I'm hoping we don't get asked to = say
> all that in the draft;-)
>
> I added text about possible privacy issue in both 8.1 and 9.5.
>
> 8.1, NEW:
>
> =C2=A0 =C2=A0Device identifiers are intended to specify classes of dev= ice in a way
> =C2=A0 =C2=A0that can assist with registration and with presentation t= o the user
> =C2=A0 =C2=A0of information about previous sessions, e.g.=C2=A0 last l= ogin time.
>
> =C2=A0 =C2=A0Device identifier types MUST NOT be privacy sensitive, wi= th values
> =C2=A0 =C2=A0that would allow tracking a user in unexpected ways.=C2= =A0 In particular,
> =C2=A0 =C2=A0using an device identifier type that is analogous to the<= br> > =C2=A0 =C2=A0International Mobile Equipment Identifier (IMEI) would be= a really
> =C2=A0 =C2=A0bad idea and is the reason for the MUST NOT above.=C2=A0 = In that case
> =C2=A0 =C2=A0"mobile phone" could be an acceptable choice. >
> =C2=A0 =C2=A0If possible, implementations ought encourage use of devic= e identifier
> =C2=A0 =C2=A0values that are not personally identifying except for the= user
> =C2=A0 =C2=A0concerned, for example "Alice's mobile" is = likely to be chosen and is
> =C2=A0 =C2=A0somewhat identifying but "Alice's phone: UUID 12= 34-5567-89abc-def0"
> =C2=A0 =C2=A0would be a very bad choice.
>
> 9.5, NEW:
>
> =C2=A0 =C2=A0The designated expert for this registry is to carefully p= ay attention
> =C2=A0 =C2=A0to the notes on this field in Section 8.1, in particular = the "MUST
> =C2=A0 =C2=A0NOT" stated therein.
>
> Happy to wordsmith that some more and we probably will want to.
>
> (Isn't it interesting how even those of us who care about this kin= d of
> thing can miss it entirely;-)
>
> >
> > Also, I would suggest
> >
> > s/if absent then the "string" form of device identifier= MUST be used./if
> > absent then the "string" form of device identifier defi= ned in Section 9.5
> > MUST be used.
>
> Sure
>
> >
> > =3D Section 8 =3D
> >
> > "Binding my CPK with someone else's account would be fun= and
> >=C2=A0 =C2=A0 profitable so SHOULD be appropriately hard." > >
> > Sarcasm translates pretty poorly across cultures. I would suggest= saying
> > what you actually mean here.
>
> Wasn't meant to be sarcastic at all. I guess it is a little opaque= but
> surely the threat is so obvious that the "fun and profit" co= lloquialism
> is ok.
>
> >
> > =3D Section 8.2 =3D
> >
> > If you want to leave in the LinkedIn reference, or any specific e= xample,
> > it needs a citation.
>
> Yep, I added one to the working copy. It's wikipedia but I've = wrangled
> that with the RFC editor before via the wiki permanent URL feature:-)<= /p>

For what it's worth, I like using a reference for this. = Thank you, Alissa, for making the suggestion, and thank you, Stephen, for m= aking the change.

I understand the point about the LinkedIn example being a Bi= g Hairy Deal, so pointing to it sounds like a plan.

I wonder if it's more effective to say "this happen= s all the time" in the text, which I understand to be the case, with t= he reference being to LinkedIn.

I'm no security maven, but when I was reading recently a= bout Sony's wizard security practices, I thought to myself, "I'= ;d never do anything that dumb", and kind of stopped there. I wonder i= f that's more likely if the text calls out any single company.

Spencer, who may still be too nice to be an AD ...

> Cheers,
> S.
>
>
> >
> >
>

--001a11c3736629feb8050c19457e-- From nobody Wed Jan 7 16:41:52 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629B31AC3B4 for ; Wed, 7 Jan 2015 16:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkqtDEALcET2 for ; Wed, 7 Jan 2015 16:41:46 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DEF31AC3B3 for ; Wed, 7 Jan 2015 16:41:46 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so387713lbv.7 for ; Wed, 07 Jan 2015 16:41:44 -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=3d0uT+u64hDB1q7BlFutLeAHD4FBYBgRNIdG9D0cCsM=; b=NB8lmSKpe5gd19lBc01eD+eF5byMRk0DYoS6NaFjyIvEpY/dW039cX8zqTAGoSNNff 6ypjwcNJYPntYytgRPX12+aohdCrFVCb/ujrNQPKAglUTA7d0ukibR+0LDGdr66wDde/ DXdpm4r3PoUXFOvpP+IivAk7yGFDCAXJDey0EFKa2DXiXyG/GX6t1UeEzgLMvc6pxYMo YMJvr1BpyljjuzC52dgKa6+Ne3eklPk+7klPQQOR1wG96xtMJ4NJ2bQ7WcF78XqIYEZb uIogfnWqPV5Nj+Asj023nX0yCUHF9oBW+B22hQue0o3BBA+QyOahc6uWz1z/cwBWVPM9 982g== MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr9485149laf.82.1420677704523; Wed, 07 Jan 2015 16:41:44 -0800 (PST) Received: by 10.114.27.162 with HTTP; Wed, 7 Jan 2015 16:41:44 -0800 (PST) In-Reply-To: References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> <84507cffd01791c6fbc190c05c757d59@mail.gmail.com> Date: Wed, 7 Jan 2015 19:41:44 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Yoav Nir Content-Type: multipart/alternative; boundary=089e0158b86eeb25c6050c194d90 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/suDuhjP7GzPwpORjy6p7Cx2KHfs Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.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, 08 Jan 2015 00:41:50 -0000 --089e0158b86eeb25c6050c194d90 Content-Type: text/plain; charset=ISO-8859-1 Brett, I am fine with the text you proposed here: http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html Julian, The proposed text seems useful for backward compatibility reasons. What is your concern exactly with that text? Regards, Rifaat On Mon, Jan 5, 2015 at 11:40 AM, Yoav Nir wrote: > > > I think it's obvious that backward compatibility is important. If you are > deploying something new with no legacy implementations around, you are not > going to pick Basic or Digest (I hope). The point of Digest is to keep > implementations functioning when the crypto library removes MD5 and when > the password database suddenly contains names and passwords with non-ASCII > characters. > > Yoav > > On Jan 5, 2015, at 6:10 PM, Brett Tate wrote: > > Hi, > > > Should draft-ietf-httpauth-digest-09 indicate how to remain interoperable > (backward compatible) with RFC 2617 compliant devices? It seems like it > should. For instance, isn't that why RFC 7235 section 2.2 indicates the > following concerning the realm? > > > "For historical reasons, a sender MUST only generate the quoted-string > syntax." > > > However if the working group doesn't think that it is important, the > vendors are likely smart enough to look at RFC 2617 if experiencing > interoperability issues with older devices. > > > Thanks, > Brett > > > *From:* Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] > *Sent:* Saturday, December 20, 2014 10:43 AM > *To:* Brett Tate > *Cc:* Julian Reschke; http-auth@ietf.org > *Subject:* Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt > > > Hi Brett, > > > Thanks for your review and comments. > Please, see my reply inline... > > > Regards, > Rifaat > > > > > On Mon, Dec 15, 2014 at 8:56 AM, Brett Tate wrote: > > Hi, > > Concerning the quoted-string ambiguity, I agree that the ambiguity still > exists. > > Draft-ietf-httpauth-digest-09 did not address my quoted string general > comment. > > http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html > > Was it not addressed because of working group discussion at IETF 91? If > so, I have the same comment. The draft is not clear concerning when > quoted strings MUST/SHOULD/MAY be used. For historical reasons, the > resolution from a sender perspective should be backward compatible with > RFC 2617 which used ABNF to clearly indicate the mandate. > > > Yes, it was discussed. > Here is a quote from the minutes: > > > > -- Quoted Strings Issue: > > > > Julian: I think the slide is probably correctly. However, do we know for sure if this is required for historical reasons? > > Better not to put edge cases into the spec if we don't need them > > > > > > > > Additional comments inline. > > > > qop > > Indicates what "quality of protection" the client has applied to > > the message. Its value MUST be one of the alternatives the server > > indicated it supports in the WWW-Authenticate header field. These > > values affect the computation of the response. Note that this is > a > > single token, not a quoted list of alternatives as in WWW- > > Authenticate. > > > > Can it use quoted-string nevertheless? > > Not if the draft/device wants to remain backward compatible with RFC 2617. > > Agree > > > > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > > --089e0158b86eeb25c6050c194d90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Brett,

I am fine with the te= xt you proposed here:


Julian,

The proposed text seems usef= ul for backward compatibility reasons.
What is your concern= exactly with that text?

Regards,
&n= bsp;Rifaat





On Mon, Ja= n 5, 2015 at 11:40 AM, Yoav Nir <ynir.ietf@gmail.com> wrot= e:
&l= t;no hats>

I think it’s obvious that backward c= ompatibility is important. If you are deploying something new with no legac= y implementations around, you are not going to pick Basic or Digest (I hope= ). The point of Digest is to keep implementations functioning when the cryp= to library removes MD5 and when the password database suddenly contains nam= es and passwords with non-ASCII characters.

Yoav

<= div>
On Jan 5, 2015, a= t 6:10 PM, Brett Tate <brett@broadsoft.com> wrote:

<= div class=3D"h5">
Hi,

 

Should draft-ietf-httpauth-digest-09 indicate how = to remain interoperable (backward compatible) with RFC 2617 compliant devic= es?  It seems like it should.  For instance, isn’t that why= RFC 7235 section 2.2 indicates the following concerning the realm?<= /div>

 

“For historical reasons, a sender MUST onl= y generate the quoted-string syntax.”

 

However if the working group doesn’t think that it is important, t= he vendors are likely smart enough to look at RFC 2617 if experiencing inte= roperability issues with older devices.

 

T= hanks,
Brett

 

From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] 
Se= nt: Saturday, December 20, 2014 10:43 AM
To: Brett Tate
Cc: Julian Resch= ke; http-auth@ietf.org<= br>Subject: Re: [http-auth] I-D Action: draft-ietf= -httpauth-digest-09.txt

 

Hi Brett,

 

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

 

Regards,
 Rifaat

 

 

On Mon, Dec 15, 2= 014 at 8:56 AM, Brett Tate <brett@broadso= ft.com> wrote:

Hi,

= Concerning the quoted-string ambiguity, I agree that the ambiguity stillexists.

Draft-ietf-httpauth-digest-09 did not address my quoted str= ing general
comment.

http://www.ietf.org/mail-archive/web/http-auth= /current/msg01949.html

Was it not addressed because of working g= roup discussion at IETF 91?  If
so, I have the same comment.  = The draft is not clear concerning when
quoted strings MUST/SHOULD/MAY be= used.  For historical reasons, the
resolution from a sender perspe= ctive should be backward compatible with
RFC 2617 which used ABNF to cle= arly indicate the mandate.

 

Yes, it was discussed.
Here is a quote from the minutes:

 

-- Quoted Strings Is=
sue: 
 
=
   Julian: I think the slide is probably correctly. However, do w=
e know for sure if this is required for historical reasons?
          = ; Better not to put edge cases into the spec if we don't need them

 

 

 

Additional comments inline.=


>     qop
>        = Indicates what "quality of protection" the client has applied to<= br>>        the message. Its value MUST be one of th= e alternatives the server
>        indicated it s= upports in the WWW-Authenticate header field. These
>    &n= bsp;   values affect the computation of the response. Note that this i= s
a
>        single token, not a quoted list o= f alternatives as in WWW-
>        Authenticate.<= br>>
> Can it use quoted-string nevertheless?

Not if the dr= aft/device wants to remain backward compatible with RFC 2617.

Agree

 

 

 

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


--089e0158b86eeb25c6050c194d90-- From nobody Wed Jan 7 16:59:05 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62CF1A879F; Wed, 7 Jan 2015 16:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=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 kxmjIkmzWEBi; Wed, 7 Jan 2015 16:58:54 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A67D1A87A0; Wed, 7 Jan 2015 16:58:54 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id z60so120228qgd.9; Wed, 07 Jan 2015 16:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BF8orOrxg/LQPvFWauKY9/250//EjWXYTvisiq/6yJE=; b=pPPSxYH3WaqjuX0uSxyTMukK5PZev2VPsfZikVPhipy/6nLs1VoQtndPi4x8Y82JAC mfrwFH890O+jS9EpDCzyGlqwDS5P7IiZnRl4Pb/8jkCISlD8yDuXyc2/z7s+Sb4IKjEs B3IPRBFCoaRqGED5GzCrpys+rvgQMVDNARkysxXCWDZo1ybCma8kh1eSGvh+vtKth3Tr 4XerKTLrdgHO8ykizBZCqMMYwTRUi6ZreLMxIxAPFF2bNhrXcvj811saO6cGz3j+/B1d tXOkS80w/t93dkD9nV4Q9NEKeRkgBYhkWlzXEwOKgialATXpXh5y265S+O2NSI0fX8/N 2B0A== X-Received: by 10.140.21.80 with SMTP id 74mr9465177qgk.87.1420678733649; Wed, 07 Jan 2015 16:58:53 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id s2sm2637577qam.45.2015.01.07.16.58.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 16:58:52 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-0BD6E011-401B-413C-9312-613A3708016C Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 7 Jan 2015 19:58:53 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> <54ADBD79.4090201@cs.tcd.ie> To: Spencer Dawkins at IETF Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/5KBB7cQUoottSuon3ZFF-ATA3pQ Cc: "httpauth-chairs@tools.ietf.org" , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , Alissa Cooper , "http-auth@ietf.org" , "iesg@ietf.org" Subject: Re: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 00:59:00 -0000 --Apple-Mail-0BD6E011-401B-413C-9312-613A3708016C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Jan 7, 2015, at 7:39 PM, Spencer Dawkins at IETF wrote: >=20 >=20 > On Jan 8, 2015 7:13 AM, "Stephen Farrell" wrot= e: > > > > > > > > Hiya, > > > > Two non-trivial changes here, see below, but also please check that > > though, working copy is at [1], diff vs. -09 at [2] as usual. > > > > [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > > [2] > > https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-httpauth-hoba-09.txt&ur= l2=3Dhttps://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > > > > On 07/01/15 22:20, Alissa Cooper wrote: > > > Alissa Cooper has entered the following ballot position for > > > draft-ietf-httpauth-hoba-09: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut thi= s > > > introductory paragraph, however.) > > > > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ > > > > > > > > > > > > ----------------------------------------------------------------------= > > > COMMENT: > > > ----------------------------------------------------------------------= > > > > > > Good stuff! Couple of comments. > > > > > > =3D Logging out =3D > > > > > > The intro says > > > > > > "Logout features can be useful for UAs, so HOBA defines a way to > > > close a current HTTP "session", and also a way to close all > > > current sessions, even if more than one session is currently > > > active from different UAs for the same account." > > > > > > But the method specified in 6.3 seems to only accomplish the first of > > > these (assuming the recommendation about server deletion of cookies > > > related to "the session" is meant to be specific to one session). What= is > > > the method for logging out of all sessions associated with different U= As > > > for the same account? > > > > Oops that's a relic, good catch. Deleted from "...and also a way" to > > the end. My code doesn't have that anymore, I didn't check other > > folks. We could always add it back later if needed, it'd just be one > > more .well-knonw/hoba thing. (And in case you ask, sorry but I forget > > when/why we dropped that or if it was because it didn't work or out > > of laziness or someone's objection:-) > > > > > > > > =3D Section 6.1 =3D > > > > > > Either the device identifier/device identifier type bits are > > > underspecified, or it's not clear to me how they are meant to be used.= > > > What other device identifier types are expected to be used in the futu= re, > > > such that a registry of them is necessary? To me it seems like you wou= ld > > > want UAs/users to take some care with the precision of the device > > > identifiers shared with servers -- e.g., "Alissa's laptop" seems like i= t > > > could be useful and fairly safe, whereas "IMEI 013584009812219" seems > > > like total overkill and a bad idea. (As an aside, it might be good to > > > provide some guidance about this in the document.) The creation of the= > > > registry makes me wonder if more structured device identifiers of the > > > IMEI-ilk are envisioned, and if so what the purpose of them is expecte= d > > > to be? > > > > Nobody had mentioned IMEIs but that's a very good point since most > > devices have something like that it'd be bad to use. The idea of the > > registry for dids was that they might be part of the registration > > flow that a site used (hence not specified here), so e.g. account > > creation for phones might differ from that for tablets or laptops. > > (And no, I don't think we yet know enough to do a good job on defining > > those right now, so how to use this well would be a part of the > > experiment I figure. And now I'm hoping we don't get asked to say > > all that in the draft;-) > > > > I added text about possible privacy issue in both 8.1 and 9.5. > > > > 8.1, NEW: > > > > Device identifiers are intended to specify classes of device in a way= > > that can assist with registration and with presentation to the user > > of information about previous sessions, e.g. last login time. > > > > Device identifier types MUST NOT be privacy sensitive, with values > > that would allow tracking a user in unexpected ways. In particular, > > using an device identifier type that is analogous to the > > International Mobile Equipment Identifier (IMEI) would be a really > > bad idea and is the reason for the MUST NOT above. In that case > > "mobile phone" could be an acceptable choice. > > > > If possible, implementations ought encourage use of device identifier= > > values that are not personally identifying except for the user > > concerned, for example "Alice's mobile" is likely to be chosen and is= > > somewhat identifying but "Alice's phone: UUID 1234-5567-89abc-def0" > > would be a very bad choice. > > > > 9.5, NEW: > > > > The designated expert for this registry is to carefully pay attention= > > to the notes on this field in Section 8.1, in particular the "MUST > > NOT" stated therein. > > > > Happy to wordsmith that some more and we probably will want to. > > > > (Isn't it interesting how even those of us who care about this kind of > > thing can miss it entirely;-) > > > > > > > > Also, I would suggest > > > > > > s/if absent then the "string" form of device identifier MUST be used./= if > > > absent then the "string" form of device identifier defined in Section 9= .5 > > > MUST be used. > > > > Sure > > > > > > > > =3D Section 8 =3D > > > > > > "Binding my CPK with someone else's account would be fun and > > > profitable so SHOULD be appropriately hard." > > > > > > Sarcasm translates pretty poorly across cultures. I would suggest sayi= ng > > > what you actually mean here. > > > > Wasn't meant to be sarcastic at all. I guess it is a little opaque but > > surely the threat is so obvious that the "fun and profit" colloquialism > > is ok. > > > > > > > > =3D Section 8.2 =3D > > > > > > If you want to leave in the LinkedIn reference, or any specific exampl= e, > > > it needs a citation. > > > > Yep, I added one to the working copy. It's wikipedia but I've wrangled > > that with the RFC editor before via the wiki permanent URL feature:-) >=20 > For what it's worth, I like using a reference for this. Thank you, Alissa,= for making the suggestion, and thank you, Stephen, for making the change. >=20 > I understand the point about the LinkedIn example being a Big Hairy Deal, s= o pointing to it sounds like a plan. >=20 > I wonder if it's more effective to say "this happens all the time" in the t= ext, which I understand to be the case, with the reference being to LinkedIn= . >=20 > I'm no security maven, but when I was reading recently about Sony's wizard= security practices, I thought to myself, "I'd never do anything that dumb",= and kind of stopped there. I wonder if that's more likely if the text calls= out any single company. >=20 > Spencer, who may still be too nice to be an AD ... >=20 For big attacks, the security folks tend to name the first or a big recent e= xample of a specific attack. When you say the LinkedIn attack, I remember t= hat there was some crazy large (I think a million+) number of passwords stol= en from at he server side. This caused a lot of questions from friends and l= ots of password changes (well publicized). In response to Barry's question o= n this that led to Stephen's update, I mentioned that most look at how a com= pany responds in terms of reputation as opposed to the fact that an event oc= curs. Business usually goes up as crazy as that sounds. RSA gets mentioned= when the discussion is about APTs or the trend in supply chain attacks. I h= ope this was helpful. Does the new language help enough? I think it does, but another security p= erson. Thanks, Kathleen > > Cheers, > > S. > > > > > > > > > > > > --Apple-Mail-0BD6E011-401B-413C-9312-613A3708016C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Jan 7, 2015, at 7:39 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote= :


On Jan 8, 2015 7:13 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
>
>
>
> Hiya,
>
> Two non-trivial changes here, see below, but also please check that
= > though, working copy is at [1], diff vs. -09 at [2] as usual.
>
>    [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-ho= ba-10.txt
>    [2]
> https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-httpauth-hoba-09.= txt&url2=3Dhttps://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.t= xt
>
> On 07/01/15 22:20, Alissa Cooper wrote:
> > Alissa Cooper has entered the following ballot position for
> > draft-ietf-httpauth-hoba-09: No Objection
> >
> > When responding, please keep the subject line intact and reply to a= ll
> > email addresses included in the To and CC lines. (Feel free to cut= this
> > introductory paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html<= /a>
> > for more information about IESG DISCUSS and COMMENT positions.
= > >
> >
> > The document, along with other ballot positions, can be found here= :
> > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/
> >
> >
> >
> > ------------------------------------------------------------------= ----
> > COMMENT:
> > ------------------------------------------------------------------= ----
> >
> > Good stuff! Couple of comments.
> >
> > =3D Logging out =3D
> >
> > The intro says
> >
> > "Logout features can be useful for UAs, so HOBA defines a way to > >       close a current HTTP "session", and also= a way to close all
> >       current sessions, even if more than one s= ession is currently
> >       active from different UAs for the same a= ccount."
> >
> > But the method specified in 6.3 seems to only accomplish the first= of
> > these (assuming the recommendation about server deletion of cookie= s
> > related to "the session" is meant to be specific to one session). W= hat is
> > the method for logging out of all sessions associated with differe= nt UAs
> > for the same account?
>
> Oops that's a relic, good catch. Deleted from "...and also a way" to > the end. My code doesn't have that anymore, I didn't check other
> folks. We could always add it back later if needed, it'd just be one > more .well-knonw/hoba thing. (And in case you ask, sorry but I forget > when/why we dropped that or if it was because it didn't work or out
= > of laziness or someone's objection:-)
>
> >
> > =3D Section 6.1 =3D
> >
> > Either the device identifier/device identifier type bits are
> > underspecified, or it's not clear to me how they are meant to be u= sed.
> > What other device identifier types are expected to be used in the f= uture,
> > such that a registry of them is necessary? To me it seems like you= would
> > want UAs/users to take some care with the precision of the device<= br> > > identifiers shared with servers -- e.g., "Alissa's laptop" seems l= ike it
> > could be useful and fairly safe, whereas "IMEI 013584009812219" se= ems
> > like total overkill and a bad idea. (As an aside, it might be good= to
> > provide some guidance about this in the document.) The creation of= the
> > registry makes me wonder if more structured device identifiers of t= he
> > IMEI-ilk are envisioned, and if so what the purpose of them is exp= ected
> > to be?
>
> Nobody had mentioned IMEIs but that's a very good point since most
> devices have something like that it'd be bad to use. The idea of the > registry for dids was that they might be part of the registration
> flow that a site used (hence not specified here), so e.g. account
> creation for phones might differ from that for tablets or laptops.
> (And no, I don't think we yet know enough to do a good job on defining<= br> > those right now, so how to use this well would be a part of the
> experiment I figure. And now I'm hoping we don't get asked to say
> all that in the draft;-)
>
> I added text about possible privacy issue in both 8.1 and 9.5.
>
> 8.1, NEW:
>
>    Device identifiers are intended to specify classes of devi= ce in a way
>    that can assist with registration and with presentation to= the user
>    of information about previous sessions, e.g.  last lo= gin time.
>
>    Device identifier types MUST NOT be privacy sensitive, wit= h values
>    that would allow tracking a user in unexpected ways. = In particular,
>    using an device identifier type that is analogous to the >    International Mobile Equipment Identifier (IMEI) would be a= really
>    bad idea and is the reason for the MUST NOT above.  I= n that case
>    "mobile phone" could be an acceptable choice.
>
>    If possible, implementations ought encourage use of device= identifier
>    values that are not personally identifying except for the u= ser
>    concerned, for example "Alice's mobile" is likely to be ch= osen and is
>    somewhat identifying but "Alice's phone: UUID 1234-5567-89= abc-def0"
>    would be a very bad choice.
>
> 9.5, NEW:
>
>    The designated expert for this registry is to carefully pa= y attention
>    to the notes on this field in Section 8.1, in particular t= he "MUST
>    NOT" stated therein.
>
> Happy to wordsmith that some more and we probably will want to.
>
> (Isn't it interesting how even those of us who care about this kind of<= br> > thing can miss it entirely;-)
>
> >
> > Also, I would suggest
> >
> > s/if absent then the "string" form of device identifier MUST be us= ed./if
> > absent then the "string" form of device identifier defined in Sect= ion 9.5
> > MUST be used.
>
> Sure
>
> >
> > =3D Section 8 =3D
> >
> > "Binding my CPK with someone else's account would be fun and
> >    profitable so SHOULD be appropriately hard."
> >
> > Sarcasm translates pretty poorly across cultures. I would suggest s= aying
> > what you actually mean here.
>
> Wasn't meant to be sarcastic at all. I guess it is a little opaque but<= br> > surely the threat is so obvious that the "fun and profit" colloquialism=
> is ok.
>
> >
> > =3D Section 8.2 =3D
> >
> > If you want to leave in the LinkedIn reference, or any specific ex= ample,
> > it needs a citation.
>
> Yep, I added one to the working copy. It's wikipedia but I've wrangled<= br> > that with the RFC editor before via the wiki permanent URL feature:-)

For what it's worth, I like using a reference for this. Thank= you, Alissa, for making the suggestion, and thank you, Stephen, for making t= he change.

I understand the point about the LinkedIn example being a Big= Hairy Deal, so pointing to it sounds like a plan.

I wonder if it's more effective to say "this happens all the t= ime" in the text, which I understand to be the case, with the reference bein= g to LinkedIn.

I'm no security maven, but when I was reading recently about S= ony's wizard security practices, I thought to myself, "I'd never do anything= that dumb", and kind of stopped there. I wonder if that's more likely if th= e text calls out any single company.

Spencer, who may still be too nice to be an AD ...

<= /blockquote>

For big attacks, the security folks tend to name t= he first or a big recent example of a specific attack.  When you say th= e LinkedIn attack, I remember that there was some crazy large (I think a mil= lion+) number of passwords stolen from at he server side.  This caused a= lot of questions from friends and lots of password changes (well publicized= ).  In response to Barry's question on this that led to Stephen's updat= e, I mentioned that most look at how a company responds in terms of reputati= on as opposed to the fact that an event occurs.  Business usually goes u= p as crazy as that sounds.  RSA gets mentioned when the discussion is a= bout APTs or the trend in supply chain attacks. I hope this was helpful.
Does the new language help enough?  I think it does, bu= t  another security person.

Thanks,
= Kathleen

> Cheers,
> S.
>
>
> >
> >
>

= --Apple-Mail-0BD6E011-401B-413C-9312-613A3708016C-- From nobody Wed Jan 7 17:02:01 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4028C1AC3BA; Wed, 7 Jan 2015 17:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv8_RARcIUC4; Wed, 7 Jan 2015 17:01:35 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7643D1AC3C0; Wed, 7 Jan 2015 17:01:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F1D0BED6; Thu, 8 Jan 2015 01:01:33 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pr2xrrcXVfH; Thu, 8 Jan 2015 01:01:31 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 76F0ABEC0; Thu, 8 Jan 2015 01:01:31 +0000 (GMT) Message-ID: <54ADD6E9.2060200@cs.tcd.ie> Date: Thu, 08 Jan 2015 01:01:29 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Richard Barnes , The IESG References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> In-Reply-To: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/GLzAJA14OnZB37CGh4SrwgQTVcw Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:01:40 -0000 X-List-Received-Date: Thu, 08 Jan 2015 01:01:40 -0000 Hi Richard, You are taking into account that this is aiming at experimental right? I get the feeling you're not, but anyway... On 08/01/15 00:20, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-httpauth-hoba-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) It does not seem to me that the mechanism defined in this document > actually conforms to the framework for HTTP authentication. "does not seem" is very imprecise please say exactly how if you are going to maintain this as a blocking point > The general > framework defined in RFC 7235 is all scoped to a resource -- you can > implement authorization for a specific resource, That works for HOBA too, just fine. > without impacting > anything else on the server. Where is that stated? Wouldn't that mean that using cookies after an HTTP auth somehow didn't conform? Wouldn't that be nonsense? (And possibly indicate an issue with 7235 but not HOBA.) > HOBA, by contrast, requires the > authenticating resource to be also be correlated to several resource > under .well-known, meaning that it will not be usable in a large number > of deployment circumstances. s/large number/some/ or do you have evidence of magnitude? And I'd note that all web and HTTP authentication/authorization enhancements are likely to have similar issues, e.g. oauth can't be used everywhere. And that's just fine. > Was this issue discussed in the WG, and was > there input from the broader HTTP community? That was not discussed in the WG. The broader HTTP community were invited to comment a number of times and did not raise this or basically did not comment, with a couple of exceptions where folks did take the time. However, that issue (lack of interest from the HTTP community and esp. browsers) was IMO disposed of when the WG was chartered so ought not by itself be a valid argument against this work or any other work from this WG as I'm sure you'll agree. Yes, HOBA uses .well-known, but that does not mean it is not conformant to 7235. Please quote me something in 7235 that indicates otherwise. Yes, there will be web sites where you cannot use this. That's just fine. > (2) What is your justification for using a SHA-1 based signature in a new > protocol, when it is being actively deprecated elsewhere, in particular > the web PKI? SHA256 is the MTI here. SHA1 is a MAY. I'd be fine with losing SHA1 if you go check and tell me that there are finally no development environments that only have SHA1 and not SHA256. That could be the case now but wasn't when we started this. (I think it was PHP didn't have it initially, but that I know is ok now.) In any case, allocating an optional to use codepoint should be fine. > (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST There are still some non-WebCrypto cases where 2048 (keygen in particular) is too slow in JS for that to be a good plan. Making that a MUST here and now would be a mistake. When/if WebCrypto is fully deployed that might well change but it's too early for that still I think. > (4) Given that the size of the header seems to be a concern (since you're > not passing the key in the header), why are there no ECC signing > algorithms defined? It seems like if you used any of the normal curves, > you could comfortably pass the key along with the authentication value. RSA is an acceptable choice from the security POV. One reason there is no ECC as I still think the IPR situation isn't as clear as for RSA. I'd expect that to change if this ever gets put on the standards track but I think insisting on that wouldn't be correct. Being conservative in that way wrt IPR should not be penalised. And I think ECC would also suffer from the same as SHA256 but much worse, as I don't think all development environments support ECDSA yet. I'd also prefer to wait for CFRG to produce an ECC signing scheme with non-NIST curves and without needing a random input before I'd want to make ECC the MTI thing. That could well happen but we're not there yet. Arguably, ECDSA would be worse than RSA with non-WebCrypto JS code as a dodgy RNG exposes the private key. That will I hope be fixed in a new ECC signature scheme from CFRG but that doesn't yet exist. > (5) For that matter, why bother defining a new algorithm registry at all, > when JWA provides a perfectly nice one that only costs you 4 characters. Is that DISCUSS-worthy? Building dependencies like that is just a design choice. It is one that could be revisited later maybe by a WG but not (I think) in IESG eval. In any case, this work was done in parallel with JOSE and such cross dependencies are a recipe for disaster:-) Again, if a standards track version were to be desirable that could easily be changed then. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The HOBA-TBS construction seems really unnecessarily complicated. It's not complicated IMO, not when compared to alternatives. But whatever, that kind of subjective comment isn't resolvable. > Other > than in the "origin" component, there are no ":" characters allowed in > any of the components, so if you could remove the unnecessarily pretty > serialization of the origin, you could just use ':' as a delimiter. Or > leave the origin, and delimit with something like %x20. Either way, this > length construction seems like a pain to implement by comparison. I felt no pain. > > "alg = 1*2DIGIT" - In general, it seems unwise to limit code point spaces > unnecessarily. For algs, I'd prefer just two bits myself actually. 330+ ciphersuites in TLS is bad really. I don't expect this to be any deal anyway, 99 signature algs is more than enough so far. > > In addition to the funny title of Section 6.2.2, the contents seem kind > of risible as well. Thanks. Or not, I guess;-) > Making a OTP is 100% equivalent to the mechanism > recommended in Section 6.2.3, and arguably more likely to deploy (since > the OTP doesn't have special semantics of being a URI). No. A human-memorable OTP is not at all the same as 6.2.3. You are simply incorrect there sorry. With a human-memorable OTP and a server with any significant traffic guessing an OTP would get the attacker some value even if they don't know whose account they are joining. And preventing that is hard or worse, since the the attacker can trickle the guesses. With 6.2.3, the URL can and should not be human memorable and hence guesses won't be an issue with any sensible implementation. Again, you are just wrong there, but perhaps not risibly so. > > Please update the algorithms so that the reader doesn't have to go look > up which algorithm this is (PKCS1 vs. PSS). Eh, no thanks:-) > > OLD: "RSA is defined in Section 8.2 of [RFC3447]" > > NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of > [RFC3447]" I don't really find those decorated names useful to be honest. > Given how convoluted Thanks for the pejorative. > the use case is here, an example would be very > helpful. At the very least to demonstrate the syntax of the > WWW-Authenticate header. Noted. S. > > From nobody Wed Jan 7 17:10:25 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DFF1A87D4; Wed, 7 Jan 2015 17:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgUh8eMxwVPx; Wed, 7 Jan 2015 17:10:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1277B1A87C6; Wed, 7 Jan 2015 17:10:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7745EBED6; Thu, 8 Jan 2015 01:10:10 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKMRudyRgIo4; Thu, 8 Jan 2015 01:10:09 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 01224BEC0; Thu, 8 Jan 2015 01:10:08 +0000 (GMT) Message-ID: <54ADD8F0.8020500@cs.tcd.ie> Date: Thu, 08 Jan 2015 01:10:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> <54ADBD79.4090201@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/rBvtAeTfG8Z31f14cm_W3XcWfbc Cc: "httpauth-chairs@tools.ietf.org" , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , Alissa Cooper , "http-auth@ietf.org" , The IESG Subject: Re: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:10:20 -0000 On 08/01/15 00:39, Kathleen Moriarty wrote:>>> >> = Section 8 = >>> >> >>> >> "Binding my CPK with someone else's account would be fun and >>> >> profitable so SHOULD be appropriately hard." >>> >> >>> >> Sarcasm translates pretty poorly across cultures. I would suggest saying >>> >> what you actually mean here. >> > >> > Wasn't meant to be sarcastic at all. I guess it is a little opaque but >> > surely the threat is so obvious that the "fun and profit" colloquialism >> > is ok. > I think it's better to replace this text, I agree with Alissa that other > cultures may have problems with it. Alissa didn't mention other cultures but a form of speech, at least as I read her comment, and a form of speech that wasn't intended as it happened;-) In this case the colloquialism is colloquial to security nerds and not people from a particular lat/long. So yes, we could replace this but IMO that'd be us being silly, as it's a quite well known phrase for security researchers [1] and, turns out, (and I didn't know) is actually not very modern. [2] S. [1] http://scholar.google.com/scholar?hl=en&q=%22fun+and+profit%22&btnG=&as_sdt=1%2C5&as_sdtp= [2] https://english.stackexchange.com/questions/25205/what-is-the-origin-of-phrase-for-fun-and-profit From nobody Wed Jan 7 17:13:35 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1591AC3B8; Wed, 7 Jan 2015 17:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, 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 CXgO0DgZQy24; Wed, 7 Jan 2015 17:13:24 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E7A1A882F; Wed, 7 Jan 2015 17:13:24 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so472003lbi.10; Wed, 07 Jan 2015 17:13:22 -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=fGOckjbAO3+lEVhmCBnXsR0zO70Q9ZtVa/2NCUNi5QU=; b=MQZ9tEpAEESXVBEz5M8FZF8T3Ijdq/fQNbEuv0YwEsaAqlj/qG+KeoEaLhz7xawmXF NLsdgK3fS3ki89H3B/B+3y7kllwmE1/ELKcwdSodL75cWejhyd3eAEKsmHiK2AHPZMyK W0YPuU5TZLlchM0tB2v1IhYyVDhL9DgP5Xtjgy9CHczUjCVOKqAz83hTYnp2c+SGo/p1 6+cPinhEitvha2ZZZqloSANFdYzmxonHkNBEnfABrAtHnm+vTOGGtqK9gZcAoFU4w4tw Gzl73ATge+M3F7DGZXOaZABy7ZNkDHXMS/P6+9qS/l/sLIBb/Gn9R0mrN7+tcYA0sfmX 3VsA== MIME-Version: 1.0 X-Received: by 10.112.26.135 with SMTP id l7mr1030790lbg.56.1420679602665; Wed, 07 Jan 2015 17:13:22 -0800 (PST) Received: by 10.152.185.195 with HTTP; Wed, 7 Jan 2015 17:13:22 -0800 (PST) Received: by 10.152.185.195 with HTTP; Wed, 7 Jan 2015 17:13:22 -0800 (PST) In-Reply-To: References: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> <54ADBD79.4090201@cs.tcd.ie> Date: Wed, 7 Jan 2015 19:13:22 -0600 Message-ID: From: Spencer Dawkins at IETF To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a113365660e7d84050c19bf34 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/DP0lhGXQQ94UtT1yJtvPi3_9V-I Cc: httpauth-chairs@tools.ietf.org, "draft-ietf-httpauth-hoba.all@tools.ietf.org" , Alissa Cooper , "http-auth@ietf.org" , "iesg@ietf.org" Subject: Re: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:13:29 -0000 --001a113365660e7d84050c19bf34 Content-Type: text/plain; charset=UTF-8 On Jan 8, 2015 8:58 AM, "Kathleen Moriarty" < kathleen.moriarty.ietf@gmail.com> wrote: > > > > Sent from my iPhone > > On Jan 7, 2015, at 7:39 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > >> >> On Jan 8, 2015 7:13 AM, "Stephen Farrell" wrote: >> > >> > >> > >> > Hiya, >> > >> > Two non-trivial changes here, see below, but also please check that >> > though, working copy is at [1], diff vs. -09 at [2] as usual. >> > >> > [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt >> > [2] >> > https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt >> > >> > On 07/01/15 22:20, Alissa Cooper wrote: >> > > Alissa Cooper has entered the following ballot position for >> > > draft-ietf-httpauth-hoba-09: No Objection >> > > >> > > When responding, please keep the subject line intact and reply to all >> > > email addresses included in the To and CC lines. (Feel free to cut this >> > > introductory paragraph, however.) >> > > >> > > >> > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> > > for more information about IESG DISCUSS and COMMENT positions. >> > > >> > > >> > > The document, along with other ballot positions, can be found here: >> > > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ >> > > >> > > >> > > >> > > ---------------------------------------------------------------------- >> > > COMMENT: >> > > ---------------------------------------------------------------------- >> > > >> > > Good stuff! Couple of comments. >> > > >> > > = Logging out = >> > > >> > > The intro says >> > > >> > > "Logout features can be useful for UAs, so HOBA defines a way to >> > > close a current HTTP "session", and also a way to close all >> > > current sessions, even if more than one session is currently >> > > active from different UAs for the same account." >> > > >> > > But the method specified in 6.3 seems to only accomplish the first of >> > > these (assuming the recommendation about server deletion of cookies >> > > related to "the session" is meant to be specific to one session). What is >> > > the method for logging out of all sessions associated with different UAs >> > > for the same account? >> > >> > Oops that's a relic, good catch. Deleted from "...and also a way" to >> > the end. My code doesn't have that anymore, I didn't check other >> > folks. We could always add it back later if needed, it'd just be one >> > more .well-knonw/hoba thing. (And in case you ask, sorry but I forget >> > when/why we dropped that or if it was because it didn't work or out >> > of laziness or someone's objection:-) >> > >> > > >> > > = Section 6.1 = >> > > >> > > Either the device identifier/device identifier type bits are >> > > underspecified, or it's not clear to me how they are meant to be used. >> > > What other device identifier types are expected to be used in the future, >> > > such that a registry of them is necessary? To me it seems like you would >> > > want UAs/users to take some care with the precision of the device >> > > identifiers shared with servers -- e.g., "Alissa's laptop" seems like it >> > > could be useful and fairly safe, whereas "IMEI 013584009812219" seems >> > > like total overkill and a bad idea. (As an aside, it might be good to >> > > provide some guidance about this in the document.) The creation of the >> > > registry makes me wonder if more structured device identifiers of the >> > > IMEI-ilk are envisioned, and if so what the purpose of them is expected >> > > to be? >> > >> > Nobody had mentioned IMEIs but that's a very good point since most >> > devices have something like that it'd be bad to use. The idea of the >> > registry for dids was that they might be part of the registration >> > flow that a site used (hence not specified here), so e.g. account >> > creation for phones might differ from that for tablets or laptops. >> > (And no, I don't think we yet know enough to do a good job on defining >> > those right now, so how to use this well would be a part of the >> > experiment I figure. And now I'm hoping we don't get asked to say >> > all that in the draft;-) >> > >> > I added text about possible privacy issue in both 8.1 and 9.5. >> > >> > 8.1, NEW: >> > >> > Device identifiers are intended to specify classes of device in a way >> > that can assist with registration and with presentation to the user >> > of information about previous sessions, e.g. last login time. >> > >> > Device identifier types MUST NOT be privacy sensitive, with values >> > that would allow tracking a user in unexpected ways. In particular, >> > using an device identifier type that is analogous to the >> > International Mobile Equipment Identifier (IMEI) would be a really >> > bad idea and is the reason for the MUST NOT above. In that case >> > "mobile phone" could be an acceptable choice. >> > >> > If possible, implementations ought encourage use of device identifier >> > values that are not personally identifying except for the user >> > concerned, for example "Alice's mobile" is likely to be chosen and is >> > somewhat identifying but "Alice's phone: UUID 1234-5567-89abc-def0" >> > would be a very bad choice. >> > >> > 9.5, NEW: >> > >> > The designated expert for this registry is to carefully pay attention >> > to the notes on this field in Section 8.1, in particular the "MUST >> > NOT" stated therein. >> > >> > Happy to wordsmith that some more and we probably will want to. >> > >> > (Isn't it interesting how even those of us who care about this kind of >> > thing can miss it entirely;-) >> > >> > > >> > > Also, I would suggest >> > > >> > > s/if absent then the "string" form of device identifier MUST be used./if >> > > absent then the "string" form of device identifier defined in Section 9.5 >> > > MUST be used. >> > >> > Sure >> > >> > > >> > > = Section 8 = >> > > >> > > "Binding my CPK with someone else's account would be fun and >> > > profitable so SHOULD be appropriately hard." >> > > >> > > Sarcasm translates pretty poorly across cultures. I would suggest saying >> > > what you actually mean here. >> > >> > Wasn't meant to be sarcastic at all. I guess it is a little opaque but >> > surely the threat is so obvious that the "fun and profit" colloquialism >> > is ok. >> > >> > > >> > > = Section 8.2 = >> > > >> > > If you want to leave in the LinkedIn reference, or any specific example, >> > > it needs a citation. >> > >> > Yep, I added one to the working copy. It's wikipedia but I've wrangled >> > that with the RFC editor before via the wiki permanent URL feature:-) >> >> For what it's worth, I like using a reference for this. Thank you, Alissa, for making the suggestion, and thank you, Stephen, for making the change. >> >> I understand the point about the LinkedIn example being a Big Hairy Deal, so pointing to it sounds like a plan. >> >> I wonder if it's more effective to say "this happens all the time" in the text, which I understand to be the case, with the reference being to LinkedIn. >> >> I'm no security maven, but when I was reading recently about Sony's wizard security practices, I thought to myself, "I'd never do anything that dumb", and kind of stopped there. I wonder if that's more likely if the text calls out any single company. >> >> Spencer, who may still be too nice to be an AD ... > > > For big attacks, the security folks tend to name the first or a big recent example of a specific attack. When you say the LinkedIn attack, I remember that there was some crazy large (I think a million+) number of passwords stolen from at he server side. This caused a lot of questions from friends and lots of password changes (well publicized). In response to Barry's question on this that led to Stephen's update, I mentioned that most look at how a company responds in terms of reputation as opposed to the fact that an event occurs. Business usually goes up as crazy as that sounds. RSA gets mentioned when the discussion is about APTs or the trend in supply chain attacks. I hope this was helpful. This all makes sense to me. > Does the new language help enough? I think it does, but another security person. I think the question is whether we think the readers of this RFC (to be) will have the security community mindset, or whether there will be a broader audience. I have no idea which of those is the case, of course. Spencer > Thanks, > Kathleen >> >> > Cheers, >> > S. >> > >> > >> > > >> > > >> > --001a113365660e7d84050c19bf34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 8, 2015 8:58 AM, "Kathleen Moriarty" <kathleen.moriarty.ietf@gmail.com>= wrote:
>
>
>
> Sent from my iPhone
>
> On Jan 7, 2015, at 7:39 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wr= ote:
>
>>
>> On Jan 8, 2015 7:13 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:=
>> >
>> >
>> >
>> > Hiya,
>> >
>> > Two non-trivial changes here, see below, but also please chec= k that
>> > though, working copy is at [1], diff vs. -09 at [2] as usual.=
>> >
>> > =C2=A0 =C2=A0[1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-= httpauth-hoba-10.txt
>> > =C2=A0 =C2=A0[2]
>> > https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-httpa= uth-hoba-09.txt&url2=3Dhttps://down.dsg.cs.tcd.ie/misc/draft-ietf-httpa= uth-hoba-10.txt
>> >
>> > On 07/01/15 22:20, Alissa Cooper wrote:
>> > > Alissa Cooper has entered the following ballot position = for
>> > > draft-ietf-httpauth-hoba-09: No Objection
>> > >
>> > > When responding, please keep the subject line intact and= reply to all
>> > > email addresses included in the To and CC lines. (Feel f= ree to cut this
>> > > introductory paragraph, however.)
>> > >
>> > >
>> > > Please refer to http://www.ietf.org/iesg/statement/discuss-cri= teria.html
>> > > for more information about IESG DISCUSS and COMMENT posi= tions.
>> > >
>> > >
>> > > The document, along with other ballot positions, can be = found here:
>> > > http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/=
>> > >
>> > >
>> > >
>> > > --------------------------------------------------------= --------------
>> > > COMMENT:
>> > > --------------------------------------------------------= --------------
>> > >
>> > > Good stuff! Couple of comments.
>> > >
>> > > =3D Logging out =3D
>> > >
>> > > The intro says
>> > >
>> > > "Logout features can be useful for UAs, so HOBA def= ines a way to
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0close a current HTTP "ses= sion", and also a way to close all
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0current sessions, even if more= than one session is currently
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0active from different UAs for = the same account."
>> > >
>> > > But the method specified in 6.3 seems to only accomplish= the first of
>> > > these (assuming the recommendation about server deletion= of cookies
>> > > related to "the session" is meant to be specif= ic to one session). What is
>> > > the method for logging out of all sessions associated wi= th different UAs
>> > > for the same account?
>> >
>> > Oops that's a relic, good catch. Deleted from "...an= d also a way" to
>> > the end. My code doesn't have that anymore, I didn't = check other
>> > folks. We could always add it back later if needed, it'd = just be one
>> > more .well-knonw/hoba thing. (And in case you ask, sorry but = I forget
>> > when/why we dropped that or if it was because it didn't w= ork or out
>> > of laziness or someone's objection:-)
>> >
>> > >
>> > > =3D Section 6.1 =3D
>> > >
>> > > Either the device identifier/device identifier type bits= are
>> > > underspecified, or it's not clear to me how they are= meant to be used.
>> > > What other device identifier types are expected to be us= ed in the future,
>> > > such that a registry of them is necessary? To me it seem= s like you would
>> > > want UAs/users to take some care with the precision of t= he device
>> > > identifiers shared with servers -- e.g., "Alissa= 9;s laptop" seems like it
>> > > could be useful and fairly safe, whereas "IMEI 0135= 84009812219" seems
>> > > like total overkill and a bad idea. (As an aside, it mig= ht be good to
>> > > provide some guidance about this in the document.) The c= reation of the
>> > > registry makes me wonder if more structured device ident= ifiers of the
>> > > IMEI-ilk are envisioned, and if so what the purpose of t= hem is expected
>> > > to be?
>> >
>> > Nobody had mentioned IMEIs but that's a very good point s= ince most
>> > devices have something like that it'd be bad to use. The = idea of the
>> > registry for dids was that they might be part of the registra= tion
>> > flow that a site used (hence not specified here), so e.g. acc= ount
>> > creation for phones might differ from that for tablets or lap= tops.
>> > (And no, I don't think we yet know enough to do a good jo= b on defining
>> > those right now, so how to use this well would be a part of t= he
>> > experiment I figure. And now I'm hoping we don't get = asked to say
>> > all that in the draft;-)
>> >
>> > I added text about possible privacy issue in both 8.1 and 9.5= .
>> >
>> > 8.1, NEW:
>> >
>> > =C2=A0 =C2=A0Device identifiers are intended to specify class= es of device in a way
>> > =C2=A0 =C2=A0that can assist with registration and with prese= ntation to the user
>> > =C2=A0 =C2=A0of information about previous sessions, e.g.=C2= =A0 last login time.
>> >
>> > =C2=A0 =C2=A0Device identifier types MUST NOT be privacy sens= itive, with values
>> > =C2=A0 =C2=A0that would allow tracking a user in unexpected w= ays.=C2=A0 In particular,
>> > =C2=A0 =C2=A0using an device identifier type that is analogou= s to the
>> > =C2=A0 =C2=A0International Mobile Equipment Identifier (IMEI)= would be a really
>> > =C2=A0 =C2=A0bad idea and is the reason for the MUST NOT abov= e.=C2=A0 In that case
>> > =C2=A0 =C2=A0"mobile phone" could be an acceptable = choice.
>> >
>> > =C2=A0 =C2=A0If possible, implementations ought encourage use= of device identifier
>> > =C2=A0 =C2=A0values that are not personally identifying excep= t for the user
>> > =C2=A0 =C2=A0concerned, for example "Alice's mobile&= quot; is likely to be chosen and is
>> > =C2=A0 =C2=A0somewhat identifying but "Alice's phone= : UUID 1234-5567-89abc-def0"
>> > =C2=A0 =C2=A0would be a very bad choice.
>> >
>> > 9.5, NEW:
>> >
>> > =C2=A0 =C2=A0The designated expert for this registry is to ca= refully pay attention
>> > =C2=A0 =C2=A0to the notes on this field in Section 8.1, in pa= rticular the "MUST
>> > =C2=A0 =C2=A0NOT" stated therein.
>> >
>> > Happy to wordsmith that some more and we probably will want t= o.
>> >
>> > (Isn't it interesting how even those of us who care about= this kind of
>> > thing can miss it entirely;-)
>> >
>> > >
>> > > Also, I would suggest
>> > >
>> > > s/if absent then the "string" form of device i= dentifier MUST be used./if
>> > > absent then the "string" form of device identi= fier defined in Section 9.5
>> > > MUST be used.
>> >
>> > Sure
>> >
>> > >
>> > > =3D Section 8 =3D
>> > >
>> > > "Binding my CPK with someone else's account wou= ld be fun and
>> > >=C2=A0 =C2=A0 profitable so SHOULD be appropriately hard.= "
>> > >
>> > > Sarcasm translates pretty poorly across cultures. I woul= d suggest saying
>> > > what you actually mean here.
>> >
>> > Wasn't meant to be sarcastic at all. I guess it is a litt= le opaque but
>> > surely the threat is so obvious that the "fun and profit= " colloquialism
>> > is ok.
>> >
>> > >
>> > > =3D Section 8.2 =3D
>> > >
>> > > If you want to leave in the LinkedIn reference, or any s= pecific example,
>> > > it needs a citation.
>> >
>> > Yep, I added one to the working copy. It's wikipedia but = I've wrangled
>> > that with the RFC editor before via the wiki permanent URL fe= ature:-)
>>
>> For what it's worth, I like using a reference for this. Thank = you, Alissa, for making the suggestion, and thank you, Stephen, for making = the change.
>>
>> I understand the point about the LinkedIn example being a Big Hair= y Deal, so pointing to it sounds like a plan.
>>
>> I wonder if it's more effective to say "this happens all = the time" in the text, which I understand to be the case, with the ref= erence being to LinkedIn.
>>
>> I'm no security maven, but when I was reading recently about S= ony's wizard security practices, I thought to myself, "I'd nev= er do anything that dumb", and kind of stopped there. I wonder if that= 's more likely if the text calls out any single company.
>>
>> Spencer, who may still be too nice to be an AD ...
>
>
> For big attacks, the security folks tend to name the first or a big re= cent example of a specific attack.=C2=A0 When you say the LinkedIn attack, = I remember that there was some crazy large (I think a million+) number of p= asswords stolen from at he server side.=C2=A0 This caused a lot of question= s from friends and lots of password changes (well publicized).=C2=A0 In res= ponse to Barry's question on this that led to Stephen's update, I m= entioned that most look at how a company responds in terms of reputation as= opposed to the fact that an event occurs.=C2=A0 Business usually goes up a= s crazy as that sounds.=C2=A0 RSA gets mentioned when the discussion is abo= ut APTs or the trend in supply chain attacks. I hope this was helpful.

This all makes sense to me.

> Does the new language help enough?=C2=A0 I think it doe= s, but =C2=A0another security person.

I think the question is whether we think the readers of this= RFC (to be) will have the security community mindset, or whether there wil= l be a broader audience.

I have no idea which of those is the case, of course.

Spencer

> Thanks,
> Kathleen
>>
>> > Cheers,
>> > S.
>> >
>> >
>> > >
>> > >
>> >

--001a113365660e7d84050c19bf34-- From nobody Wed Jan 7 17:19:30 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926051AC3C0; Wed, 7 Jan 2015 17:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 cDmvXQy0XaNU; Wed, 7 Jan 2015 17:19:23 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 E21401A87D5; Wed, 7 Jan 2015 17:19:22 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t081JIfi071944 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2015 18:19:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> Date: Wed, 7 Jan 2015 17:19:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> To: Richard Barnes X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/WFODywuWjezRbJLI8pH6O8JaQ2M Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:19:24 -0000 On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: > (1) It does not seem to me that the mechanism defined in this document > actually conforms to the framework for HTTP authentication. The = general > framework defined in RFC 7235 is all scoped to a resource -- you can > implement authorization for a specific resource, without impacting > anything else on the server. HOBA, by contrast, requires the > authenticating resource to be also be correlated to several resource > under .well-known, meaning that it will not be usable in a large = number > of deployment circumstances. Was this issue discussed in the WG, and = was > there input from the broader HTTP community? Yes and yes. (Stephen is wrong that it was not.) The "authenticating = resource" in HOBA is purposely more expressive than that in RFC 7235, = and thus takes more primitives than HTTP auth. There was plenty of WG = discussion around this. > (2) What is your justification for using a SHA-1 based signature in a = new > protocol, when it is being actively deprecated elsewhere, in = particular > the web PKI? RSA-SHA1 is widely implemented, and thus it seemed appropriate for a = MAY-level definition when there is a more popular algorithm (RSA-SHA256) = at MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no = danger to having it here. > (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> = MUST There is no interoperability mandate for particular RSA key lengths, so = "SHOULD" is more appropriate here (until the IESG finally gets around to = updating RFC 2119...). > (4) Given that the size of the header seems to be a concern (since = you're > not passing the key in the header), why are there no ECC signing > algorithms defined? It seems like if you used any of the normal = curves, > you could comfortably pass the key along with the authentication = value. Because there is not yet agreement on which ECC signing algorithms are = likely to be popular in a year or two. We're watching the CFRG = discussion, and it is not yet coming to consensus. When it does, this = Experimental RFC can be updated. > (5) For that matter, why bother defining a new algorithm registry at = all, > when JWA provides a perfectly nice one that only costs you 4 = characters. We did not want to be tied to the JWA registry, given that JOSE could go = in quite different directions. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The HOBA-TBS construction seems really unnecessarily complicated. = Other > than in the "origin" component, there are no ":" characters allowed in > any of the components, so if you could remove the unnecessarily pretty > serialization of the origin, you could just use ':' as a delimiter. = Or > leave the origin, and delimit with something like %x20. Either way, = this > length construction seems like a pain to implement by comparison. We started with a less complex construction, and the WG specifically = asked for this. > "alg =3D 1*2DIGIT" - In general, it seems unwise to limit code point = spaces > unnecessarily. It is also unwise to have more than 99 possible algorithms for signing. > In addition to the funny title of Section 6.2.2, the contents seem = kind > of risible as well. Making a OTP is 100% equivalent to the mechanism > recommended in Section 6.2.3, and arguably more likely to deploy = (since > the OTP doesn't have special semantics of being a URI). There is wide disagreement on what is more likely to deploy. Also, I'm = pretty sure Stephen is correct about your view on OTP here. > Please update the algorithms so that the reader doesn't have to go = look > up which algorithm this is (PKCS1 vs. PSS). >=20 > OLD: "RSA is defined in Section 8.2 of [RFC3447]"=20 >=20 > NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of > [RFC3447]" Sounds good; now fixed in the post-IESG version. > Given how convoluted the use case is here, an example would be very > helpful. At the very least to demonstrate the syntax of the > WWW-Authenticate header. This doesn't seem all that needed, regardless of your view of = convolution. --Paul Hoffman= From nobody Wed Jan 7 17:25:52 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AA61AC3D0; Wed, 7 Jan 2015 17:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9peeK1Jcxp-2; Wed, 7 Jan 2015 17:25:48 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE771AC3CF; Wed, 7 Jan 2015 17:25:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F15B2BED1; Thu, 8 Jan 2015 01:25:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_QSGt8Fmknh; Thu, 8 Jan 2015 01:25:45 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2961EBEC0; Thu, 8 Jan 2015 01:25:45 +0000 (GMT) Message-ID: <54ADDC98.4000009@cs.tcd.ie> Date: Thu, 08 Jan 2015 01:25:44 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Paul Hoffman , Richard Barnes References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Cqb7phfzqEe88bz4FuPjX7eJ6Dg Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:25:51 -0000 FWIW, I'm fine that Paul's recollection of the WG stuff is better than mine and with his putting the pkcs#1 stuff in too. S On 08/01/15 01:19, Paul Hoffman wrote: > On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: >> (1) It does not seem to me that the mechanism defined in this document >> actually conforms to the framework for HTTP authentication. The general >> framework defined in RFC 7235 is all scoped to a resource -- you can >> implement authorization for a specific resource, without impacting >> anything else on the server. HOBA, by contrast, requires the >> authenticating resource to be also be correlated to several resource >> under .well-known, meaning that it will not be usable in a large number >> of deployment circumstances. Was this issue discussed in the WG, and was >> there input from the broader HTTP community? > > Yes and yes. (Stephen is wrong that it was not.) The "authenticating resource" in HOBA is purposely more expressive than that in RFC 7235, and thus takes more primitives than HTTP auth. There was plenty of WG discussion around this. > > >> (2) What is your justification for using a SHA-1 based signature in a new >> protocol, when it is being actively deprecated elsewhere, in particular >> the web PKI? > > RSA-SHA1 is widely implemented, and thus it seemed appropriate for a MAY-level definition when there is a more popular algorithm (RSA-SHA256) at MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no danger to having it here. > >> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST > > There is no interoperability mandate for particular RSA key lengths, so "SHOULD" is more appropriate here (until the IESG finally gets around to updating RFC 2119...). > >> (4) Given that the size of the header seems to be a concern (since you're >> not passing the key in the header), why are there no ECC signing >> algorithms defined? It seems like if you used any of the normal curves, >> you could comfortably pass the key along with the authentication value. > > Because there is not yet agreement on which ECC signing algorithms are likely to be popular in a year or two. We're watching the CFRG discussion, and it is not yet coming to consensus. When it does, this Experimental RFC can be updated. > >> (5) For that matter, why bother defining a new algorithm registry at all, >> when JWA provides a perfectly nice one that only costs you 4 characters. > > We did not want to be tied to the JWA registry, given that JOSE could go in quite different directions. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> The HOBA-TBS construction seems really unnecessarily complicated. Other >> than in the "origin" component, there are no ":" characters allowed in >> any of the components, so if you could remove the unnecessarily pretty >> serialization of the origin, you could just use ':' as a delimiter. Or >> leave the origin, and delimit with something like %x20. Either way, this >> length construction seems like a pain to implement by comparison. > > We started with a less complex construction, and the WG specifically asked for this. > >> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point spaces >> unnecessarily. > > It is also unwise to have more than 99 possible algorithms for signing. > >> In addition to the funny title of Section 6.2.2, the contents seem kind >> of risible as well. Making a OTP is 100% equivalent to the mechanism >> recommended in Section 6.2.3, and arguably more likely to deploy (since >> the OTP doesn't have special semantics of being a URI). > > There is wide disagreement on what is more likely to deploy. Also, I'm pretty sure Stephen is correct about your view on OTP here. > >> Please update the algorithms so that the reader doesn't have to go look >> up which algorithm this is (PKCS1 vs. PSS). >> >> OLD: "RSA is defined in Section 8.2 of [RFC3447]" >> >> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of >> [RFC3447]" > > Sounds good; now fixed in the post-IESG version. > >> Given how convoluted the use case is here, an example would be very >> helpful. At the very least to demonstrate the syntax of the >> WWW-Authenticate header. > > This doesn't seem all that needed, regardless of your view of convolution. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From nobody Wed Jan 7 18:49:13 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70001A00F7; Wed, 7 Jan 2015 18:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-Q7Pc8ilLzO; Wed, 7 Jan 2015 18:49:05 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 620A41A1A4B; Wed, 7 Jan 2015 18:49:04 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 2966832E594; Thu, 8 Jan 2015 11:48:18 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4836_32b0_559a75ac_1cfd_4426_8a64_e85dd03ed510; Thu, 08 Jan 2015 11:48:17 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 94158BF505; Thu, 8 Jan 2015 11:48:17 +0900 (JST) Message-ID: <54ADEFF1.4040301@it.aoyama.ac.jp> Date: Thu, 08 Jan 2015 11:48:17 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Spencer Dawkins at IETF , Kathleen Moriarty References: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> <54ADBD79.4090201@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/YaqdQC1NI167lkrmb6E728vMSJQ Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , httpauth-chairs@tools.ietf.org, Alissa Cooper , "iesg@ietf.org" Subject: Re: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 02:49:07 -0000 On 2015/01/08 10:13, Spencer Dawkins at IETF wrote: > On Jan 8, 2015 8:58 AM, "Kathleen Moriarty" < > kathleen.moriarty.ietf@gmail.com> wrote: >> On Jan 7, 2015, at 7:39 PM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: >>> I'm no security maven, but when I was reading recently about Sony's > wizard security practices, I thought to myself, "I'd never do anything that > dumb", and kind of stopped there. I wonder if that's more likely if the > text calls out any single company. >>> >>> Spencer, who may still be too nice to be an AD ... >> >> >> For big attacks, the security folks tend to name the first or a big > recent example of a specific attack. When you say the LinkedIn attack, I > remember that there was some crazy large (I think a million+) number of > passwords stolen from at he server side. This caused a lot of questions > from friends and lots of password changes (well publicized). In response > to Barry's question on this that led to Stephen's update, I mentioned that > most look at how a company responds in terms of reputation as opposed to > the fact that an event occurs. Business usually goes up as crazy as that > sounds. RSA gets mentioned when the discussion is about APTs or the trend > in supply chain attacks. I hope this was helpful. > > This all makes sense to me. > >> Does the new language help enough? I think it does, but another > security person. > > I think the question is whether we think the readers of this RFC (to be) > will have the security community mindset, or whether there will be a > broader audience. > > I have no idea which of those is the case, of course. What about *both*? Regards, Martin. From nobody Wed Jan 7 18:53:44 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33711A8704; Wed, 7 Jan 2015 18:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7aObysP8w2b; Wed, 7 Jan 2015 18:53:42 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 38EEC1A6EE8; Wed, 7 Jan 2015 18:53:42 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 9E75232E545; Thu, 8 Jan 2015 11:52:57 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4836_338d_448857e7_ae0e_4890_943b_b8012e264f9e; Thu, 08 Jan 2015 11:52:56 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 11644BF505; Thu, 8 Jan 2015 11:52:57 +0900 (JST) Message-ID: <54ADF108.7010208@it.aoyama.ac.jp> Date: Thu, 08 Jan 2015 11:52:56 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kathleen Moriarty , Barry Leiba References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54ABAF30.8040207@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/RN40-IOw5FS_xXdkTdk2pUsRRys Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 02:53:43 -0000 On 2015/01/06 22:47, Kathleen Moriarty wrote: > The other item was on LinkedIn and I think we are ok now on the text > change, is that right? To see if I can help, I do agree with Stephen > here and hope the updated text is enough to move forward on this one > (it seems to be the case). If the LinkedIn attack is mentioned, most > know that it was a large scale attack against the passwords stored on > the server side. For what it's worth, just the mention of an attack > is not necessarily bad press. Most look at how a company handled an > attack and the aftermath now rather than the fact that one happened. > Sometimes it is positive and most of the time it turns out to positive > for companies (even TJ Max had an increase in sales after their breach > that involved compromised Point of Sale systems). This almost sounds as if making sure you get hit once in a while and your user's data gets stolen is a good thing :-(. I seriously hope that's not the case. Regards, Martin. From nobody Wed Jan 7 19:00:57 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659551A1B7A; Wed, 7 Jan 2015 19:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 hWJJJHnQds05; Wed, 7 Jan 2015 19:00:54 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1171A00F7; Wed, 7 Jan 2015 19:00:53 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id i17so181462qcy.7; Wed, 07 Jan 2015 19:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bf+GnLYN1hIGfD2mxjhQl/2cQzB5c88v9W2TkeG7ub0=; b=mnNLK+tamRH9rYL3Nvn6eRA63ijF9Leyp3a1Dz5RiWlTjqNBqLiRj3tJ0fB09GlieV gwcjMiCmoyBEXyYcKSjWOFo7kPOVJMGE7u0T5cIxdxwnlfe9O6XNkvKuHwivAR4NFc1a WyhmNtI3esc2JlVeIxGkA43yAVfDqhfulzSMJtt270uOYkYpcnXwl5dnlSy1JoduHYCy PXGyISgHXGp1nUV3AYkJLZtayVuTl/JobUoUdBTcnpf4Yq0uRKVhF5g9NYeG5EIMksMS bgW6NjB2jFWPEOU0VojOPomgZS35MtTXZbNgosLXCsdPXfT3Mt8BqfJ3EEF/NOvuCadV ptdg== X-Received: by 10.229.181.5 with SMTP id bw5mr11021616qcb.15.1420686053079; Wed, 07 Jan 2015 19:00:53 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id w9sm2921362qab.18.2015.01.07.19.00.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 19:00:51 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54ADF108.7010208@it.aoyama.ac.jp> Date: Wed, 7 Jan 2015 22:00:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0C7C8A9C-70BF-4E68-BD4B-91652B14105A@gmail.com> References: <20150105174855.11968.51931.idtracker@ietfa.amsl.com> <54AAE9C7.8010105@cs.tcd.ie> <9C2AA051DD3C464F8ADEE38AEE6C26AD18C9E7BA@dfweml704-chm> <54AB4FFF.4040402@cs.tcd.ie> <54ABAF30.8040207@cs.tcd.ie> <54ADF108.7010208@it.aoyama.ac.jp> To: =?utf-8?Q?"Martin_J._D=C3=BCrst"?= Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/VSh7RN1Jy3l6bht7eCsrL-iUu-Q Cc: "http-auth@ietf.org" , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , Barry Leiba , "httpauth-chairs@tools.ietf.org" , The IESG Subject: Re: [http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 03:00:55 -0000 Sent from my iPhone > On Jan 7, 2015, at 9:52 PM, "Martin J. D=C3=BCrst" wrote: >=20 >> On 2015/01/06 22:47, Kathleen Moriarty wrote: >>=20 >> The other item was on LinkedIn and I think we are ok now on the text >> change, is that right? To see if I can help, I do agree with Stephen >> here and hope the updated text is enough to move forward on this one >> (it seems to be the case). If the LinkedIn attack is mentioned, most >> know that it was a large scale attack against the passwords stored on >> the server side. For what it's worth, just the mention of an attack >> is not necessarily bad press. Most look at how a company handled an >> attack and the aftermath now rather than the fact that one happened. >> Sometimes it is positive and most of the time it turns out to positive >> for companies (even TJ Max had an increase in sales after their breach >> that involved compromised Point of Sale systems). >=20 > This almost sounds as if making sure you get hit once in a while and your u= ser's data gets stolen is a good thing :-(. Martin, What I typed was to help with an explanation, not actual text to be used in a= draft. It was an example (that can be backed up with data) to say it's not= uncommon or looked at poorly to name companies when referring to specific a= ttack types. How they respond is important and I did not say anything about= repeated attacks, that or severity can have an effect on a business, but re= ally would have been getting too far off the point of whether or not it's ok= ay to name LinkedIn. Best regards, Kathleen=20 >=20 > I seriously hope that's not the case. >=20 > Regards, Martin. From nobody Thu Jan 8 02:23:37 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF41F1ACD03 for ; Thu, 8 Jan 2015 02:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otVCYJFP-L_l for ; Thu, 8 Jan 2015 02:23:27 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11341ACD00 for ; Thu, 8 Jan 2015 02:23:26 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so2036692lbj.8 for ; Thu, 08 Jan 2015 02:23:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IUyWYgz09cdH9MN9Y/d9zjubZyxW6AmdXTADesf3jdc=; b=IfF7DDy78ToVTbnqD7b37YrNJEOrN3+RuIbRguQX4BJbCJRUV9qePvW0sEeHN69687 fmFCy3dg7vw+pKSHoYAqhr2rl/xoUpzBuLO6sHgUybX8gndGX/wzhHdvnyr/cG+4+R62 AegRBnwJFFcJsmOiHIiK3u7aMa+KkWk0FybIOpsVFw1noIGMYVlIBAHD/RlkbKUriOX3 4L53hTKP7JZNiX8/bqyUznVZDRzMLMLZYxQk8+wUy4oQzeVE7Egcf/RsBo8isYb6Xt50 uKZOMjjFiCRIbblCQHEYm2qlvAu6as3xA8AP+is6Usblu+rIdLsEf7ES1ACt9dcIazKf qyMA== X-Gm-Message-State: ALoCoQlRYzVtT0uGhMU5trQIS/kjFIBEpk25eE/eSV+4cB30o4OZy0eSqzQOs07jEfnQwAXTYDqw MIME-Version: 1.0 X-Received: by 10.152.29.129 with SMTP id k1mr12198370lah.10.1420712605184; Thu, 08 Jan 2015 02:23:25 -0800 (PST) Received: by 10.25.12.215 with HTTP; Thu, 8 Jan 2015 02:23:25 -0800 (PST) In-Reply-To: <54ADDC98.4000009@cs.tcd.ie> References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADDC98.4000009@cs.tcd.ie> Date: Thu, 8 Jan 2015 10:23:25 +0000 Message-ID: From: Richard Barnes To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0160b7da290c13050c216ee2 Archived-At: Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, Paul Hoffman , The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 10:23:31 -0000 --089e0160b7da290c13050c216ee2 Content-Type: text/plain; charset=UTF-8 Hey guys, Thanks for responding productively to a DISCUSS that I admit was not written very politely. Sorry about that. Couple of comments inline. On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell wrote: > > FWIW, I'm fine that Paul's recollection of the WG stuff is better > than mine and with his putting the pkcs#1 stuff in too. > > S > > On 08/01/15 01:19, Paul Hoffman wrote: > > On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: > >> (1) It does not seem to me that the mechanism defined in this document > >> actually conforms to the framework for HTTP authentication. The general > >> framework defined in RFC 7235 is all scoped to a resource -- you can > >> implement authorization for a specific resource, without impacting > >> anything else on the server. HOBA, by contrast, requires the > >> authenticating resource to be also be correlated to several resource > >> under .well-known, meaning that it will not be usable in a large number > >> of deployment circumstances. Was this issue discussed in the WG, and > was > >> there input from the broader HTTP community? > > > > Yes and yes. (Stephen is wrong that it was not.) The "authenticating > resource" in HOBA is purposely more expressive than that in RFC 7235, and > thus takes more primitives than HTTP auth. There was plenty of WG > discussion around this. > If you happen to have a pointer to that discussion, it would help me feel more comfortable. To be a little clearer about my concern, it seems like the fact that you don't carry the public key in the Authorization header means that the authenticating resource has to be tied to the .well-known/hoba/register/ resource. > >> (2) What is your justification for using a SHA-1 based signature in a > new > >> protocol, when it is being actively deprecated elsewhere, in particular > >> the web PKI? > > > > RSA-SHA1 is widely implemented, and thus it seemed appropriate for a > MAY-level definition when there is a more popular algorithm (RSA-SHA256) at > MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no danger > to having it here. > But if you're REQUIRED to support RSA-SHA256, why would you ever use RSA-SHA1? Color me pretty skeptical that there are implementations that can't support SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto libary that fits within 64K and supports SHA-256 along with a bunch of other algorithms. > >> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST > > > > There is no interoperability mandate for particular RSA key lengths, so > "SHOULD" is more appropriate here (until the IESG finally gets around to > updating RFC 2119...). > This is not about interop, it's about achieving an appropriate security level. That is another thing for which MUSTs are commonly used. (If we're going to talk about 2119, the phrasing is "absolute requirement of the specification", not "absolutely required for interop".) To Stephen's point on JS performance: I made a little empirical test: http://www.ipv.sx/tmp/rsa-2048.html On a good laptop, a good phone, and a crappier phone, the time to generate a 2048-bit key is roughly (choosing representative values after a few clicks): MacBook Pro: 5340ms iPhone 6: 7192ms FirefoxOS Flame: 31084ms These values are not great, but they're within the range of asynchronous operations that web pages already have to deal with, especially given that keygen is a once-per-origin operation. As far as sign() operations, the worst case among these devices was ~500ms, which is again not terrible. > >> (4) Given that the size of the header seems to be a concern (since > you're > >> not passing the key in the header), why are there no ECC signing > >> algorithms defined? It seems like if you used any of the normal curves, > >> you could comfortably pass the key along with the authentication value. > > > > Because there is not yet agreement on which ECC signing algorithms are > likely to be popular in a year or two. We're watching the CFRG discussion, > and it is not yet coming to consensus. When it does, this Experimental RFC > can be updated. > This is pretty weak sauce. It's not like ECDSA with P-256 is going to go away overnight when CFRG make up their minds. Maybe I'm overly worried about the complexity here, but it seems like using ECC could allow you to just shove the public key in the Authorization header. That would obviate the need for the registration resource, resolving point 1 above, and generally make HOBA easier to implement. Nonetheless, I moved this point to a COMMENT. >> (5) For that matter, why bother defining a new algorithm registry at all, > >> when JWA provides a perfectly nice one that only costs you 4 characters. > > > > We did not want to be tied to the JWA registry, given that JOSE could go > in quite different directions. > Fair enough. Cleared this one. > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> The HOBA-TBS construction seems really unnecessarily complicated. Other > >> than in the "origin" component, there are no ":" characters allowed in > >> any of the components, so if you could remove the unnecessarily pretty > >> serialization of the origin, you could just use ':' as a delimiter. Or > >> leave the origin, and delimit with something like %x20. Either way, > this > >> length construction seems like a pain to implement by comparison. > > > > We started with a less complex construction, and the WG specifically > asked for this. > > > >> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point > spaces > >> unnecessarily. > > > > It is also unwise to have more than 99 possible algorithms for signing. > Sure, but that seems like a process issue, not one to enshrine in syntax. > >> In addition to the funny title of Section 6.2.2, the contents seem kind > >> of risible as well. Making a OTP is 100% equivalent to the mechanism > >> recommended in Section 6.2.3, and arguably more likely to deploy (since > >> the OTP doesn't have special semantics of being a URI). > > > > There is wide disagreement on what is more likely to deploy. Also, I'm > pretty sure Stephen is correct about your view on OTP here. > > > >> Please update the algorithms so that the reader doesn't have to go look > >> up which algorithm this is (PKCS1 vs. PSS). > >> > >> OLD: "RSA is defined in Section 8.2 of [RFC3447]" > >> > >> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of > >> [RFC3447]" > > > > Sounds good; now fixed in the post-IESG version. > > > >> Given how convoluted the use case is here, an example would be very > >> helpful. At the very least to demonstrate the syntax of the > >> WWW-Authenticate header. > > > > This doesn't seem all that needed, regardless of your view of > convolution. > > > > --Paul Hoffman > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > > --089e0160b7da290c13050c216ee2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey guys,

Thanks for responding productively to a D= ISCUSS that I admit was not written very politely.=C2=A0 Sorry about that.<= br>
Couple of comments inline.

On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

FWIW, I'm fine that Paul's recollection of the WG stuff is better than mine and with his putting the pkcs#1 stuff in too.

S

On 08/01/15 01:19, Paul Hoffman wrote:
> On Jan 7, 2015, at 4:20 PM, Richard Barnes <rlb@ipv.sx> wrote: >> (1) It does not seem to me that the mechanism defined in this docu= ment
>> actually conforms to the framework for HTTP authentication.=C2=A0 = The general
>> framework defined in RFC 7235 is all scoped to a resource -- you c= an
>> implement authorization for a specific resource, without impacting=
>> anything else on the server.=C2=A0 HOBA, by contrast, requires the=
>> authenticating resource to be also be correlated to several resour= ce
>> under .well-known, meaning that it will not be usable in a large n= umber
>> of deployment circumstances.=C2=A0 Was this issue discussed in the= WG, and was
>> there input from the broader HTTP community?
>
> Yes and yes. (Stephen is wrong that it was not.) The "authenticat= ing resource" in HOBA is purposely more expressive than that in RFC 72= 35, and thus takes more primitives than HTTP auth. There was plenty of WG d= iscussion around this.

If y= ou happen to have a pointer to that discussion, it would help me feel more = comfortable.

To be a little clearer about my concern, it seems like = the fact that you don't carry the public key in the Authorization heade= r means that the authenticating resource has to be tied to the .well-known/= hoba/register/ resource.

=C2=A0
>> (2) What is your justification for using a SHA-1 based signature i= n a new
>> protocol, when it is being actively deprecated elsewhere, in parti= cular
>> the web PKI?
>
> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a M= AY-level definition when there is a more popular algorithm (RSA-SHA256) at = MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is n= o danger to having it here.

But if you're REQUIRED to support RSA-SHA256, why would you ever use R= SA-SHA1?

Color me pretty skeptical that there are impleme= ntations that can't support SHA-2 nowadays.=C2=A0 I just saw a presenta= tion yesterday about an IoT crypto libary that fits within 64K and supports= SHA-256 along with a bunch of other algorithms.

=C2=A0
>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used= ." -> MUST
>
> There is no interoperability mandate for particular RSA key lengths, s= o "SHOULD" is more appropriate here (until the IESG finally gets = around to updating RFC 2119...).

This is not about interop, it's about achieving an appropriate se= curity level.=C2=A0 That is another thing for which MUSTs are commonly used= .

(If we're going to talk about 2119, the phrasing is= "absolute requirement of the specification", not "absolutel= y required for interop".)

To Stephen'= s point on JS performance: I made a little empirical test:
http://www.ipv.sx/tmp/= rsa-2048.html

On a good laptop, a good phone, and a crappier pho= ne, the time to generate a 2048-bit key is roughly (choosing representative= values after a few clicks):=C2=A0
MacBook Pro: 5340ms
iPhone 6: 7192ms
FirefoxOS Flame: 31084ms
<= div>
These values are not great, but they're within the r= ange of asynchronous operations that web pages already have to deal with, e= specially given that keygen is a once-per-origin operation.=C2=A0 As far as= sign() operations, the worst case among these devices was ~500ms, which is= again not terrible.

=C2=A0
>> (4) Given that the size of the header seems to be a concern (since= you're
>> not passing the key in the header), why are there no ECC signing >> algorithms defined?=C2=A0 It seems like if you used any of the nor= mal curves,
>> you could comfortably pass the key along with the authentication v= alue.
>
> Because there is not yet agreement on which ECC signing algorithms are= likely to be popular in a year or two. We're watching the CFRG discuss= ion, and it is not yet coming to consensus. When it does, this Experimental= RFC can be updated.

This i= s pretty weak sauce.=C2=A0 It's not like ECDSA with P-256 is going to g= o away overnight when CFRG make up their minds.

Maybe I'm overly worried about the complexity here, but it seems like= using ECC could allow you to just shove the public key in the Authorizatio= n header.=C2=A0 That would obviate the need for the registration resource, = resolving point 1 above, and generally make HOBA easier to implement.
Nonetheless, I moved this point to a COMMENT.

>> (5) For that matter, why bother defining a new algorithm registry = at all,
>> when JWA provides a perfectly nice one that only costs you 4 chara= cters.
>
> We did not want to be tied to the JWA registry, given that JOSE could = go in quite different directions.

Fair enough.=C2=A0 Cleared this one.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>> The HOBA-TBS construction seems really unnecessarily complicated.= =C2=A0 Other
>> than in the "origin" component, there are no ":&quo= t; characters allowed in
>> any of the components, so if you could remove the unnecessarily pr= etty
>> serialization of the origin, you could just use ':' as a d= elimiter.=C2=A0 Or
>> leave the origin, and delimit with something like %x20.=C2=A0 Eith= er way, this
>> length construction seems like a pain to implement by comparison.<= br> >
> We started with a less complex construction, and the WG specifically a= sked for this.
>
>> "alg =3D 1*2DIGIT" - In general, it seems unwise to limi= t code point spaces
>> unnecessarily.
>
> It is also unwise to have more than 99 possible algorithms for signing= .

Sure, but that seems like= a process issue, not one to enshrine in syntax.

=C2=A0
>> In addition to the funny title of Section 6.2.2, the contents seem= kind
>> of risible as well.=C2=A0 Making a OTP is 100% equivalent to the m= echanism
>> recommended in Section 6.2.3, and arguably more likely to deploy (= since
>> the OTP doesn't have special semantics of being a URI).
>
> There is wide disagreement on what is more likely to deploy. Also, I&#= 39;m pretty sure Stephen is correct about your view on OTP here.
>
>> Please update the algorithms so that the reader doesn't have t= o go look
>> up which algorithm this is (PKCS1 vs. PSS).
>>
>> OLD: "RSA is defined in Section 8.2 of [RFC3447]"
>>
>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section = 8.2 of
>> [RFC3447]"
>
> Sounds good; now fixed in the post-IESG version.
>
>> Given how convoluted the use case is here, an example would be ver= y
>> helpful.=C2=A0 At the very least to demonstrate the syntax of the<= br> >> WWW-Authenticate header.
>
> This doesn't seem all that needed, regardless of your view of conv= olution.
>
> --Paul Hoffman
> _______________________________________________
> http-auth mailing list
> http-auth@ietf= .org
> https://www.ietf.org/mailman/listinfo/http-auth
>

--089e0160b7da290c13050c216ee2-- From nobody Thu Jan 8 03:22:09 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C2A1A1BC3 for ; Thu, 8 Jan 2015 03:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Pys_vY-_vFP for ; Thu, 8 Jan 2015 03:21:59 -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 0FB581A1EE9 for ; Thu, 8 Jan 2015 03:21:58 -0800 (PST) Received: from [192.168.178.36] ([93.217.91.67]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LwGDy-1XjNeP2lkk-017z8C; Thu, 08 Jan 2015 12:21:55 +0100 Message-ID: <54AE6850.3050905@gmx.de> Date: Thu, 08 Jan 2015 12:21:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , Yoav Nir References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> <84507cffd01791c6fbc190c05c757d59@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8h8cuUoFuFbswhuQ3M5BG6DTTdCCTfICTSu3nW35+JwZHd/8aj+ XDe143f87pEs0bQZNZbnwtPODqyQ+YatjSSmSlGXP676H/0esdPOelMCOS4zYkHzs0nf9JA j22HWED9aVx+ndB8U/LWK8mF4YPvlYxtHllL6I6VPsoEpn7d03eVvvCRlMDI1kXU3JAknHU D+RLmNbad5o35lsUVYDEQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.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, 08 Jan 2015 11:22:01 -0000 On 2015-01-08 01:41, Rifaat Shekh-Yusef wrote: > Brett, > > I am fine with the text you proposed here: > http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html > > > Julian, > > The proposed text seems useful for backward compatibility reasons. > What is your concern exactly with that text? > ... My concern was to put in requirements for backwards compat when we aren't sure that they are needed; if you Digest experts agree that they are needed, then yes, put them in. Best regards, Julian From nobody Thu Jan 8 03:46:08 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4708A1A8990; Thu, 8 Jan 2015 03:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPkIai1EHSxa; Thu, 8 Jan 2015 03:45:58 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EE61A0368; Thu, 8 Jan 2015 03:45:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C0F85BEE9; Thu, 8 Jan 2015 11:45:56 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7kmrrR1UQ_q; Thu, 8 Jan 2015 11:45:54 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88155BEDB; Thu, 8 Jan 2015 11:45:54 +0000 (GMT) Message-ID: <54AE6DF2.80500@cs.tcd.ie> Date: Thu, 08 Jan 2015 11:45:54 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Richard Barnes References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADDC98.4000009@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, Paul Hoffman , The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 11:46:02 -0000 Hiya, On 08/01/15 10:23, Richard Barnes wrote: > Hey guys, > > Thanks for responding productively to a DISCUSS that I admit was not > written very politely. Sorry about that. I do it myself from time to time, no probs. (And to be honest I was more rude about your ballot in IM to someone else, so we're even:-) > > Couple of comments inline. > > On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell > wrote: > >> >> FWIW, I'm fine that Paul's recollection of the WG stuff is better >> than mine and with his putting the pkcs#1 stuff in too. >> >> S >> >> On 08/01/15 01:19, Paul Hoffman wrote: >>> On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: >>>> (1) It does not seem to me that the mechanism defined in this document >>>> actually conforms to the framework for HTTP authentication. The general >>>> framework defined in RFC 7235 is all scoped to a resource -- you can >>>> implement authorization for a specific resource, without impacting >>>> anything else on the server. HOBA, by contrast, requires the >>>> authenticating resource to be also be correlated to several resource >>>> under .well-known, meaning that it will not be usable in a large number >>>> of deployment circumstances. Was this issue discussed in the WG, and >> was >>>> there input from the broader HTTP community? >>> >>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating >> resource" in HOBA is purposely more expressive than that in RFC 7235, and >> thus takes more primitives than HTTP auth. There was plenty of WG >> discussion around this. >> > > If you happen to have a pointer to that discussion, it would help me feel > more comfortable. > > To be a little clearer about my concern, it seems like the fact that you > don't carry the public key in the Authorization header means that the > authenticating resource has to be tied to the .well-known/hoba/register/ > resource. Yes, that's true. But entirely acceptable as a reasonable limitation of the scheme. It's reasonable because a) less header bloat if you send public key once, b) with RSA in particular public keys are big, and c) I hold out the hope that I can someday develop a privacy friendly kid type so that the strongly identifying nature of the HOBA signature is addressed. (I have not so far figured one out, sadly.) So I still don't see a reason for this to block the experiment. > > > >>>> (2) What is your justification for using a SHA-1 based signature in a >> new >>>> protocol, when it is being actively deprecated elsewhere, in particular >>>> the web PKI? >>> >>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a >> MAY-level definition when there is a more popular algorithm (RSA-SHA256) at >> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no danger >> to having it here. >> > > But if you're REQUIRED to support RSA-SHA256, why would you ever use > RSA-SHA1? > > Color me pretty skeptical that there are implementations that can't support > SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto > libary that fits within 64K and supports SHA-256 along with a bunch of > other algorithms. That was the case with PHP when this work started and at that time I needed the rsa-sha1 code point for my code. That was only a year or two ago. I bet there are still web sites with only that version of PHP available today - that is scary but adding HOBA to such could still represent a security improvement if it meant that a new application can be deployed without a new password verifier DB, and that would be the case since we have the rsa-sha1 codepoint. Taking away the codepoint would prevent such being deployed. And we know for sure that the relevant risk here is not the signature crypto but is overwhelmingly and utterly the password verifier DB. You are I fear arguing that we ought prioritise crypto plumbing over the real security risk. I have not done a survey of all web development platforms to check if this is now a solved issue or not. You skepticism is fine (and perhaps correct) but if you don't do that survey, then blocking on that basis is not correct. >>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST >>> >>> There is no interoperability mandate for particular RSA key lengths, so >> "SHOULD" is more appropriate here (until the IESG finally gets around to >> updating RFC 2119...). >> > > This is not about interop, it's about achieving an appropriate security > level. That is another thing for which MUSTs are commonly used. > > (If we're going to talk about 2119, the phrasing is "absolute requirement > of the specification", not "absolutely required for interop".) > > To Stephen's point on JS performance: I made a little empirical test: > http://www.ipv.sx/tmp/rsa-2048.html > > On a good laptop, a good phone, and a crappier phone, the time to generate > a 2048-bit key is roughly (choosing representative values after a few > clicks): > MacBook Pro: 5340ms > iPhone 6: 7192ms > FirefoxOS Flame: 31084ms I've seen it take >120s which is not usable in this context. That was on older iphones (4 I think) with various browsers. With some older versions of IE on older laptops it's also horrendous. > These values are not great, but they're within the range of asynchronous > operations that web pages already have to deal with, especially given that > keygen is a once-per-origin operation. As far as sign() operations, the > worst case among these devices was ~500ms, which is again not terrible. Signing is tolerable in most cases thanks to the getchal and using a worker. And the appropriate security level for HOBA is not the usual thing actually. Here we're after "substantially better than passwords" and will likely transition to a cookie (bearer token) just after signing. So I would argue that even an otherwise-undesirable 1500 bit modulus could be ok here, if a site has a way to bump that up later, e.g. as new browsers deploy webcrypto. However, that is not stuff that needs or ought be in the RFC. For an experimental RFC we should not block on this. (I would myself for a stds track but not exp.) >>>> (4) Given that the size of the header seems to be a concern (since >> you're >>>> not passing the key in the header), why are there no ECC signing >>>> algorithms defined? It seems like if you used any of the normal curves, >>>> you could comfortably pass the key along with the authentication value. >>> >>> Because there is not yet agreement on which ECC signing algorithms are >> likely to be popular in a year or two. We're watching the CFRG discussion, >> and it is not yet coming to consensus. When it does, this Experimental RFC >> can be updated. >> > > This is pretty weak sauce. It's not like ECDSA with P-256 is going to go > away overnight when CFRG make up their minds. The development platform issue that perhaps no longer exists for sha256 is I believe still real for ecdsa. But the main thing I'd like from the CFRG work would be to lose the RNG requirement at signing time, which is unnecessarily a part of ECDSA. That's a real security win, if we get it. > Maybe I'm overly worried about the complexity here, but it seems like using > ECC could allow you to just shove the public key in the Authorization > header. That would obviate the need for the registration resource, > resolving point 1 above, and generally make HOBA easier to implement. > > Nonetheless, I moved this point to a COMMENT. > > >>> (5) For that matter, why bother defining a new algorithm registry at all, >>>> when JWA provides a perfectly nice one that only costs you 4 characters. >>> >>> We did not want to be tied to the JWA registry, given that JOSE could go >> in quite different directions. >> > > Fair enough. Cleared this one. Cool. > > > >>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> The HOBA-TBS construction seems really unnecessarily complicated. Other >>>> than in the "origin" component, there are no ":" characters allowed in >>>> any of the components, so if you could remove the unnecessarily pretty >>>> serialization of the origin, you could just use ':' as a delimiter. Or >>>> leave the origin, and delimit with something like %x20. Either way, >> this >>>> length construction seems like a pain to implement by comparison. >>> >>> We started with a less complex construction, and the WG specifically >> asked for this. >>> >>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point >> spaces >>>> unnecessarily. >>> >>> It is also unwise to have more than 99 possible algorithms for signing. >> > > Sure, but that seems like a process issue, not one to enshrine in syntax. The opposite I think. We seem unable to fix the vanity/national crypto thing via process so I'd like to see us try via syntax myself. But that's for another day:-) Cheers, S. > > > >>>> In addition to the funny title of Section 6.2.2, the contents seem kind >>>> of risible as well. Making a OTP is 100% equivalent to the mechanism >>>> recommended in Section 6.2.3, and arguably more likely to deploy (since >>>> the OTP doesn't have special semantics of being a URI). >>> >>> There is wide disagreement on what is more likely to deploy. Also, I'm >> pretty sure Stephen is correct about your view on OTP here. >>> >>>> Please update the algorithms so that the reader doesn't have to go look >>>> up which algorithm this is (PKCS1 vs. PSS). >>>> >>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" >>>> >>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of >>>> [RFC3447]" >>> >>> Sounds good; now fixed in the post-IESG version. >>> >>>> Given how convoluted the use case is here, an example would be very >>>> helpful. At the very least to demonstrate the syntax of the >>>> WWW-Authenticate header. >>> >>> This doesn't seem all that needed, regardless of your view of >> convolution. >>> >>> --Paul Hoffman >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>> >> > From nobody Thu Jan 8 04:07:04 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C6F1ACD2D for ; Thu, 8 Jan 2015 04:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyJ1IihKO70g for ; Thu, 8 Jan 2015 04:06:52 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC22E1ACD24 for ; Thu, 8 Jan 2015 04:06:51 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so2458826lbj.8 for ; Thu, 08 Jan 2015 04:06:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M0azuojCtQqbTmP4MkNe/wEfmNil49sTLccHAgKRBy0=; b=b65+FsMCKINLV4kf/ac+nP520Ga0DW/OSHtHkRDmnz2TYfj4iuBDHEauXrL08xaewV 1Gl1P3P1CmZRII3n0I4XQZ60ya4U4lZm9Gy5BHr7bpQtBz891ADj2SmkulOgw5zhDxdi 3C4/zzPwLGXarTz4lOH3Iyntq3noUTvmN50TvuJwB4bYsVyyLrHayoT6euSODkp2ooOK hUZ+VWJr4QqwFlM5jvH2j8bt2qXGZDY1/gRLhIyqmfOlR5ZF+rEKy2MKZffrw5+M9H3S bgOQOk8FK77n18kxbGnf+kUBQ+Bl5vtpdTKI6f7xbaRq9nVwIqlMM1y70Vb/ipTM2y/o eJ1g== X-Gm-Message-State: ALoCoQlF92+7lpegZoh9ZieFqlYHtgANqzOYOCD85gEb9MeTHX95VSmYxlQ44BgtLymR16rNZODR MIME-Version: 1.0 X-Received: by 10.152.29.129 with SMTP id k1mr13158844lah.10.1420718809897; Thu, 08 Jan 2015 04:06:49 -0800 (PST) Received: by 10.25.12.215 with HTTP; Thu, 8 Jan 2015 04:06:49 -0800 (PST) In-Reply-To: <54AE6DF2.80500@cs.tcd.ie> References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADDC98.4000009@cs.tcd.ie> <54AE6DF2.80500@cs.tcd.ie> Date: Thu, 8 Jan 2015 12:06:49 +0000 Message-ID: From: Richard Barnes To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0160b7dafd67c7050c22df36 Archived-At: Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, Paul Hoffman , The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:07:01 -0000 --089e0160b7dafd67c7050c22df36 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell wrote: > > Hiya, > > On 08/01/15 10:23, Richard Barnes wrote: > > Hey guys, > > > > Thanks for responding productively to a DISCUSS that I admit was not > > written very politely. Sorry about that. > > I do it myself from time to time, no probs. (And to be honest I > was more rude about your ballot in IM to someone else, so we're > even:-) > > > > > Couple of comments inline. > > > > On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> FWIW, I'm fine that Paul's recollection of the WG stuff is better > >> than mine and with his putting the pkcs#1 stuff in too. > >> > >> S > >> > >> On 08/01/15 01:19, Paul Hoffman wrote: > >>> On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: > >>>> (1) It does not seem to me that the mechanism defined in this document > >>>> actually conforms to the framework for HTTP authentication. The > general > >>>> framework defined in RFC 7235 is all scoped to a resource -- you can > >>>> implement authorization for a specific resource, without impacting > >>>> anything else on the server. HOBA, by contrast, requires the > >>>> authenticating resource to be also be correlated to several resource > >>>> under .well-known, meaning that it will not be usable in a large > number > >>>> of deployment circumstances. Was this issue discussed in the WG, and > >> was > >>>> there input from the broader HTTP community? > >>> > >>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating > >> resource" in HOBA is purposely more expressive than that in RFC 7235, > and > >> thus takes more primitives than HTTP auth. There was plenty of WG > >> discussion around this. > >> > > > > If you happen to have a pointer to that discussion, it would help me feel > > more comfortable. > > > > To be a little clearer about my concern, it seems like the fact that you > > don't carry the public key in the Authorization header means that the > > authenticating resource has to be tied to the .well-known/hoba/register/ > > resource. > > Yes, that's true. But entirely acceptable as a reasonable > limitation of the scheme. It's reasonable because a) less > header bloat if you send public key once, b) with RSA in > particular public keys are big, and c) I hold out the hope > that I can someday develop a privacy friendly kid type so > that the strongly identifying nature of the HOBA signature > is addressed. (I have not so far figured one out, sadly.) > > So I still don't see a reason for this to block the experiment. > > > > > > > > >>>> (2) What is your justification for using a SHA-1 based signature in a > >> new > >>>> protocol, when it is being actively deprecated elsewhere, in > particular > >>>> the web PKI? > >>> > >>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a > >> MAY-level definition when there is a more popular algorithm > (RSA-SHA256) at > >> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no > danger > >> to having it here. > >> > > > > But if you're REQUIRED to support RSA-SHA256, why would you ever use > > RSA-SHA1? > > > > Color me pretty skeptical that there are implementations that can't > support > > SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto > > libary that fits within 64K and supports SHA-256 along with a bunch of > > other algorithms. > > That was the case with PHP when this work started and at that time I > needed the rsa-sha1 code point for my code. That was only a year or > two ago. I bet there are still web sites with only that version of > PHP available today - that is scary but adding HOBA to such could > still represent a security improvement if it meant that a new > application can be deployed without a new password verifier DB, and > that would be the case since we have the rsa-sha1 codepoint. Taking > away the codepoint would prevent such being deployed. And we know > for sure that the relevant risk here is not the signature crypto > but is overwhelmingly and utterly the password verifier DB. You are > I fear arguing that we ought prioritise crypto plumbing over the > real security risk. > > I have not done a survey of all web development platforms to check > if this is now a solved issue or not. You skepticism is fine (and > perhaps correct) but if you don't do that survey, then blocking on > that basis is not correct. > Isn't the burden on the one trying to weaken the protocol? :) All of the web development platforms I can think of have SHA-2 support. Looking at the list on wikipedia: http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites ASP.NET, C, C++, Java, JavaScript, Perl, Python, Ruby: Should be obvious PHP, Xhp, Hack: http://php.net/manual/en/function.hash.php Scala: https://github.com/Nycto/Hasher Go: http://golang.org/pkg/crypto/sha256/ Erlang: http://erlang.org/doc/man/crypto.html D: http://dlang.org/phobos/std_digest_sha.html So unless you can come up with a platform that *doesn't* support SHA-2, I don't see why it should be allowed. In any event, it seems like this whole pageant is moot, since the document *requires* SHA-2 support. If you've got that, why would you ever do SHA-1? > >>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> > MUST > >>> > >>> There is no interoperability mandate for particular RSA key lengths, so > >> "SHOULD" is more appropriate here (until the IESG finally gets around to > >> updating RFC 2119...). > >> > > > > This is not about interop, it's about achieving an appropriate security > > level. That is another thing for which MUSTs are commonly used. > > > > (If we're going to talk about 2119, the phrasing is "absolute requirement > > of the specification", not "absolutely required for interop".) > > > > To Stephen's point on JS performance: I made a little empirical test: > > http://www.ipv.sx/tmp/rsa-2048.html > > > > On a good laptop, a good phone, and a crappier phone, the time to > generate > > a 2048-bit key is roughly (choosing representative values after a few > > clicks): > > MacBook Pro: 5340ms > > iPhone 6: 7192ms > > FirefoxOS Flame: 31084ms > > I've seen it take >120s which is not usable in this context. That > was on older iphones (4 I think) with various browsers. With some > older versions of IE on older laptops it's also horrendous. > > > These values are not great, but they're within the range of asynchronous > > operations that web pages already have to deal with, especially given > that > > keygen is a once-per-origin operation. As far as sign() operations, the > > worst case among these devices was ~500ms, which is again not terrible. > > Signing is tolerable in most cases thanks to the getchal and using > a worker. > > And the appropriate security level for HOBA is not the usual thing > actually. Here we're after "substantially better than passwords" > and will likely transition to a cookie (bearer token) just after > signing. So I would argue that even an otherwise-undesirable 1500 > bit modulus could be ok here, if a site has a way to bump that up > later, e.g. as new browsers deploy webcrypto. However, that is not > stuff that needs or ought be in the RFC. > > For an experimental RFC we should not block on this. (I would myself > for a stds track but not exp.) > Yeah, OK. I guess I can live with this. Could we possibly add some bounding text, e.g., "Keys shorter than 2048 bits should only be used in cases where generating 2048-bit (or longer) keys is impractical, e.g., on constrained devices. If an application uses short keys, then it MUST expire and re-generate keys periodically, say every few weeks." > >>>> (4) Given that the size of the header seems to be a concern (since > >> you're > >>>> not passing the key in the header), why are there no ECC signing > >>>> algorithms defined? It seems like if you used any of the normal > curves, > >>>> you could comfortably pass the key along with the authentication > value. > >>> > >>> Because there is not yet agreement on which ECC signing algorithms are > >> likely to be popular in a year or two. We're watching the CFRG > discussion, > >> and it is not yet coming to consensus. When it does, this Experimental > RFC > >> can be updated. > >> > > > > This is pretty weak sauce. It's not like ECDSA with P-256 is going to go > > away overnight when CFRG make up their minds. > > The development platform issue that perhaps no longer exists for > sha256 is I believe still real for ecdsa. > > But the main thing I'd like from the CFRG work would be to lose the > RNG requirement at signing time, which is unnecessarily a part of > ECDSA. That's a real security win, if we get it. > > > Maybe I'm overly worried about the complexity here, but it seems like > using > > ECC could allow you to just shove the public key in the Authorization > > header. That would obviate the need for the registration resource, > > resolving point 1 above, and generally make HOBA easier to implement. > > > > Nonetheless, I moved this point to a COMMENT. > > > > > >>> (5) For that matter, why bother defining a new algorithm registry at > all, > >>>> when JWA provides a perfectly nice one that only costs you 4 > characters. > >>> > >>> We did not want to be tied to the JWA registry, given that JOSE could > go > >> in quite different directions. > >> > > > > Fair enough. Cleared this one. > > Cool. > > > > > > > > >>> > >>>> ---------------------------------------------------------------------- > >>>> COMMENT: > >>>> ---------------------------------------------------------------------- > >>>> > >>>> The HOBA-TBS construction seems really unnecessarily complicated. > Other > >>>> than in the "origin" component, there are no ":" characters allowed in > >>>> any of the components, so if you could remove the unnecessarily pretty > >>>> serialization of the origin, you could just use ':' as a delimiter. > Or > >>>> leave the origin, and delimit with something like %x20. Either way, > >> this > >>>> length construction seems like a pain to implement by comparison. > >>> > >>> We started with a less complex construction, and the WG specifically > >> asked for this. > >>> > >>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point > >> spaces > >>>> unnecessarily. > >>> > >>> It is also unwise to have more than 99 possible algorithms for signing. > >> > > > > Sure, but that seems like a process issue, not one to enshrine in syntax. > > The opposite I think. We seem unable to fix the vanity/national crypto > thing via process so I'd like to see us try via syntax myself. But > that's for another day:-) > > Cheers, > S. > > > > > > > > >>>> In addition to the funny title of Section 6.2.2, the contents seem > kind > >>>> of risible as well. Making a OTP is 100% equivalent to the mechanism > >>>> recommended in Section 6.2.3, and arguably more likely to deploy > (since > >>>> the OTP doesn't have special semantics of being a URI). > >>> > >>> There is wide disagreement on what is more likely to deploy. Also, I'm > >> pretty sure Stephen is correct about your view on OTP here. > >>> > >>>> Please update the algorithms so that the reader doesn't have to go > look > >>>> up which algorithm this is (PKCS1 vs. PSS). > >>>> > >>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" > >>>> > >>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of > >>>> [RFC3447]" > >>> > >>> Sounds good; now fixed in the post-IESG version. > >>> > >>>> Given how convoluted the use case is here, an example would be very > >>>> helpful. At the very least to demonstrate the syntax of the > >>>> WWW-Authenticate header. > >>> > >>> This doesn't seem all that needed, regardless of your view of > >> convolution. > >>> > >>> --Paul Hoffman > >>> _______________________________________________ > >>> http-auth mailing list > >>> http-auth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/http-auth > >>> > >> > > > On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell wrote: > > Hiya, > > On 08/01/15 10:23, Richard Barnes wrote: > > Hey guys, > > > > Thanks for responding productively to a DISCUSS that I admit was not > > written very politely. Sorry about that. > > I do it myself from time to time, no probs. (And to be honest I > was more rude about your ballot in IM to someone else, so we're > even:-) > > > > > Couple of comments inline. > > > > On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> FWIW, I'm fine that Paul's recollection of the WG stuff is better > >> than mine and with his putting the pkcs#1 stuff in too. > >> > >> S > >> > >> On 08/01/15 01:19, Paul Hoffman wrote: > >>> On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: > >>>> (1) It does not seem to me that the mechanism defined in this document > >>>> actually conforms to the framework for HTTP authentication. The > general > >>>> framework defined in RFC 7235 is all scoped to a resource -- you can > >>>> implement authorization for a specific resource, without impacting > >>>> anything else on the server. HOBA, by contrast, requires the > >>>> authenticating resource to be also be correlated to several resource > >>>> under .well-known, meaning that it will not be usable in a large > number > >>>> of deployment circumstances. Was this issue discussed in the WG, and > >> was > >>>> there input from the broader HTTP community? > >>> > >>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating > >> resource" in HOBA is purposely more expressive than that in RFC 7235, > and > >> thus takes more primitives than HTTP auth. There was plenty of WG > >> discussion around this. > >> > > > > If you happen to have a pointer to that discussion, it would help me feel > > more comfortable. > > > > To be a little clearer about my concern, it seems like the fact that you > > don't carry the public key in the Authorization header means that the > > authenticating resource has to be tied to the .well-known/hoba/register/ > > resource. > > Yes, that's true. But entirely acceptable as a reasonable > limitation of the scheme. It's reasonable because a) less > header bloat if you send public key once, b) with RSA in > particular public keys are big, and c) I hold out the hope > that I can someday develop a privacy friendly kid type so > that the strongly identifying nature of the HOBA signature > is addressed. (I have not so far figured one out, sadly.) > > So I still don't see a reason for this to block the experiment. > > > > > > > > >>>> (2) What is your justification for using a SHA-1 based signature in a > >> new > >>>> protocol, when it is being actively deprecated elsewhere, in > particular > >>>> the web PKI? > >>> > >>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a > >> MAY-level definition when there is a more popular algorithm > (RSA-SHA256) at > >> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no > danger > >> to having it here. > >> > > > > But if you're REQUIRED to support RSA-SHA256, why would you ever use > > RSA-SHA1? > > > > Color me pretty skeptical that there are implementations that can't > support > > SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto > > libary that fits within 64K and supports SHA-256 along with a bunch of > > other algorithms. > > That was the case with PHP when this work started and at that time I > needed the rsa-sha1 code point for my code. That was only a year or > two ago. I bet there are still web sites with only that version of > PHP available today - that is scary but adding HOBA to such could > still represent a security improvement if it meant that a new > application can be deployed without a new password verifier DB, and > that would be the case since we have the rsa-sha1 codepoint. Taking > away the codepoint would prevent such being deployed. And we know > for sure that the relevant risk here is not the signature crypto > but is overwhelmingly and utterly the password verifier DB. You are > I fear arguing that we ought prioritise crypto plumbing over the > real security risk. > > I have not done a survey of all web development platforms to check > if this is now a solved issue or not. You skepticism is fine (and > perhaps correct) but if you don't do that survey, then blocking on > that basis is not correct. > > >>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> > MUST > >>> > >>> There is no interoperability mandate for particular RSA key lengths, so > >> "SHOULD" is more appropriate here (until the IESG finally gets around to > >> updating RFC 2119...). > >> > > > > This is not about interop, it's about achieving an appropriate security > > level. That is another thing for which MUSTs are commonly used. > > > > (If we're going to talk about 2119, the phrasing is "absolute requirement > > of the specification", not "absolutely required for interop".) > > > > To Stephen's point on JS performance: I made a little empirical test: > > http://www.ipv.sx/tmp/rsa-2048.html > > > > On a good laptop, a good phone, and a crappier phone, the time to > generate > > a 2048-bit key is roughly (choosing representative values after a few > > clicks): > > MacBook Pro: 5340ms > > iPhone 6: 7192ms > > FirefoxOS Flame: 31084ms > > I've seen it take >120s which is not usable in this context. That > was on older iphones (4 I think) with various browsers. With some > older versions of IE on older laptops it's also horrendous. > > > These values are not great, but they're within the range of asynchronous > > operations that web pages already have to deal with, especially given > that > > keygen is a once-per-origin operation. As far as sign() operations, the > > worst case among these devices was ~500ms, which is again not terrible. > > Signing is tolerable in most cases thanks to the getchal and using > a worker. > > And the appropriate security level for HOBA is not the usual thing > actually. Here we're after "substantially better than passwords" > and will likely transition to a cookie (bearer token) just after > signing. So I would argue that even an otherwise-undesirable 1500 > bit modulus could be ok here, if a site has a way to bump that up > later, e.g. as new browsers deploy webcrypto. However, that is not > stuff that needs or ought be in the RFC. > > For an experimental RFC we should not block on this. (I would myself > for a stds track but not exp.) > > >>>> (4) Given that the size of the header seems to be a concern (since > >> you're > >>>> not passing the key in the header), why are there no ECC signing > >>>> algorithms defined? It seems like if you used any of the normal > curves, > >>>> you could comfortably pass the key along with the authentication > value. > >>> > >>> Because there is not yet agreement on which ECC signing algorithms are > >> likely to be popular in a year or two. We're watching the CFRG > discussion, > >> and it is not yet coming to consensus. When it does, this Experimental > RFC > >> can be updated. > >> > > > > This is pretty weak sauce. It's not like ECDSA with P-256 is going to go > > away overnight when CFRG make up their minds. > > The development platform issue that perhaps no longer exists for > sha256 is I believe still real for ecdsa. > > But the main thing I'd like from the CFRG work would be to lose the > RNG requirement at signing time, which is unnecessarily a part of > ECDSA. That's a real security win, if we get it. > > > Maybe I'm overly worried about the complexity here, but it seems like > using > > ECC could allow you to just shove the public key in the Authorization > > header. That would obviate the need for the registration resource, > > resolving point 1 above, and generally make HOBA easier to implement. > > > > Nonetheless, I moved this point to a COMMENT. > > > > > >>> (5) For that matter, why bother defining a new algorithm registry at > all, > >>>> when JWA provides a perfectly nice one that only costs you 4 > characters. > >>> > >>> We did not want to be tied to the JWA registry, given that JOSE could > go > >> in quite different directions. > >> > > > > Fair enough. Cleared this one. > > Cool. > > > > > > > > >>> > >>>> ---------------------------------------------------------------------- > >>>> COMMENT: > >>>> ---------------------------------------------------------------------- > >>>> > >>>> The HOBA-TBS construction seems really unnecessarily complicated. > Other > >>>> than in the "origin" component, there are no ":" characters allowed in > >>>> any of the components, so if you could remove the unnecessarily pretty > >>>> serialization of the origin, you could just use ':' as a delimiter. > Or > >>>> leave the origin, and delimit with something like %x20. Either way, > >> this > >>>> length construction seems like a pain to implement by comparison. > >>> > >>> We started with a less complex construction, and the WG specifically > >> asked for this. > >>> > >>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point > >> spaces > >>>> unnecessarily. > >>> > >>> It is also unwise to have more than 99 possible algorithms for signing. > >> > > > > Sure, but that seems like a process issue, not one to enshrine in syntax. > > The opposite I think. We seem unable to fix the vanity/national crypto > thing via process so I'd like to see us try via syntax myself. But > that's for another day:-) > > Cheers, > S. > > > > > > > > >>>> In addition to the funny title of Section 6.2.2, the contents seem > kind > >>>> of risible as well. Making a OTP is 100% equivalent to the mechanism > >>>> recommended in Section 6.2.3, and arguably more likely to deploy > (since > >>>> the OTP doesn't have special semantics of being a URI). > >>> > >>> There is wide disagreement on what is more likely to deploy. Also, I'm > >> pretty sure Stephen is correct about your view on OTP here. > >>> > >>>> Please update the algorithms so that the reader doesn't have to go > look > >>>> up which algorithm this is (PKCS1 vs. PSS). > >>>> > >>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" > >>>> > >>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of > >>>> [RFC3447]" > >>> > >>> Sounds good; now fixed in the post-IESG version. > >>> > >>>> Given how convoluted the use case is here, an example would be very > >>>> helpful. At the very least to demonstrate the syntax of the > >>>> WWW-Authenticate header. > >>> > >>> This doesn't seem all that needed, regardless of your view of > >> convolution. > >>> > >>> --Paul Hoffman > >>> _______________________________________________ > >>> http-auth mailing list > >>> http-auth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/http-auth > >>> > >> > > > --089e0160b7dafd67c7050c22df36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya,

On 08/01/15 10:23, Richard Barnes wrote:
> Hey guys,
>
> Thanks for responding productively to a DISCUSS that I admit was not > written very politely.=C2=A0 Sorry about that.

I do it myself from time to time, no probs. (And to be honest I
was more rude about your ballot in IM to someone else, so we're
even:-)

>
> Couple of comments inline.
>
> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> FWIW, I'm fine that Paul's recollection of the WG stuff is= better
>> than mine and with his putting the pkcs#1 stuff in too.
>>
>> S
>>
>> On 08/01/15 01:19, Paul Hoffman wrote:
>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes <rlb@ipv.sx> = wrote:
>>>> (1) It does not seem to me that the mechanism defined in t= his document
>>>> actually conforms to the framework for HTTP authentication= .=C2=A0 The general
>>>> framework defined in RFC 7235 is all scoped to a resource = -- you can
>>>> implement authorization for a specific resource, without i= mpacting
>>>> anything else on the server.=C2=A0 HOBA, by contrast, requ= ires the
>>>> authenticating resource to be also be correlated to severa= l resource
>>>> under .well-known, meaning that it will not be usable in a= large number
>>>> of deployment circumstances.=C2=A0 Was this issue discusse= d in the WG, and
>> was
>>>> there input from the broader HTTP community?
>>>
>>> Yes and yes. (Stephen is wrong that it was not.) The "aut= henticating
>> resource" in HOBA is purposely more expressive than that in R= FC 7235, and
>> thus takes more primitives than HTTP auth. There was plenty of WG<= br> >> discussion around this.
>>
>
> If you happen to have a pointer to that discussion, it would help me f= eel
> more comfortable.
>
> To be a little clearer about my concern, it seems like the fact that y= ou
> don't carry the public key in the Authorization header means that = the
> authenticating resource has to be tied to the .well-known/hoba/registe= r/
> resource.

Yes, that's true. But entirely acceptable as a reasonable limitation of the scheme. It's reasonable because a) less
header bloat if you send public key once, b) with RSA in
particular public keys are big, and c) I hold out the hope
that I can someday develop a privacy friendly kid type so
that the strongly identifying nature of the HOBA signature
is addressed. (I have not so far figured one out, sadly.)

So I still don't see a reason for this to block the experiment.

>
>
>
>>>> (2) What is your justification for using a SHA-1 based sig= nature in a
>> new
>>>> protocol, when it is being actively deprecated elsewhere, = in particular
>>>> the web PKI?
>>>
>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate= for a
>> MAY-level definition when there is a more popular algorithm (RSA-S= HA256) at
>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, t= here is no danger
>> to having it here.
>>
>
> But if you're REQUIRED to support RSA-SHA256, why would you ever u= se
> RSA-SHA1?
>
> Color me pretty skeptical that there are implementations that can'= t support
> SHA-2 nowadays.=C2=A0 I just saw a presentation yesterday about an IoT= crypto
> libary that fits within 64K and supports SHA-256 along with a bunch of=
> other algorithms.

That was the case with PHP when this work started and at that time I=
needed the rsa-sha1 code point for my code. That was only a year or
two ago. I bet there are still web sites with only that version of
PHP available today - that is scary but adding HOBA to such could
still represent a security improvement if it meant that a new
application can be deployed without a new password verifier DB, and
that would be the case since we have the rsa-sha1 codepoint. Taking
away the codepoint would prevent such being deployed. And we know
for sure that the relevant risk here is not the signature crypto
but is overwhelmingly and utterly the password verifier DB. You are
I fear arguing that we ought prioritise crypto plumbing over the
real security risk.

I have not done a survey of all web development platforms to check
if this is now a solved issue or not. You skepticism is fine (and
perhaps correct) but if you don't do that survey, then blocking on
that basis is not correct.
Isn't the burden on the one trying to weaken the protocol?= =C2=A0 :)

All of the web development platforms I can thin= k of have SHA-2 support.=C2=A0 Looking at the list on wikipedia:
http://en.wikipedia.org/wiki/Programming_languages_used_in_most_= popular_websites

ASP.NET, C, C++, Java, JavaScript, Perl, Python, Ruby: Should be obvious
So unless you= can come up with a platform that *doesn't* support SHA-2, I don't = see why it should be allowed.

In any event, it seems like= this whole pageant is moot, since the document *requires* SHA-2 support.= =C2=A0 If you've got that, why would you ever do SHA-1?=C2=A0

=C2=A0
>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD= be used." -> MUST
>>>
>>> There is no interoperability mandate for particular RSA key le= ngths, so
>> "SHOULD" is more appropriate here (until the IESG finall= y gets around to
>> updating RFC 2119...).
>>
>
> This is not about interop, it's about achieving an appropriate sec= urity
> level.=C2=A0 That is another thing for which MUSTs are commonly used.<= br> >
> (If we're going to talk about 2119, the phrasing is "absolute= requirement
> of the specification", not "absolutely required for interop&= quot;.)
>
> To Stephen's point on JS performance: I made a little empirical te= st:
> http= ://www.ipv.sx/tmp/rsa-2048.html
>
> On a good laptop, a good phone, and a crappier phone, the time to gene= rate
> a 2048-bit key is roughly (choosing representative values after a few<= br> > clicks):
> MacBook Pro: 5340ms
> iPhone 6: 7192ms
> FirefoxOS Flame: 31084ms

I've seen it take >120s which is not usable in this context. = That
was on older iphones (4 I think) with various browsers. With some
older versions of IE on older laptops it's also horrendous.

> These values are not great, but they're within the range of asynch= ronous
> operations that web pages already have to deal with, especially given = that
> keygen is a once-per-origin operation.=C2=A0 As far as sign() operatio= ns, the
> worst case among these devices was ~500ms, which is again not terrible= .

Signing is tolerable in most cases thanks to the getchal and using a worker.

And the appropriate security level for HOBA is not the usual thing
actually. Here we're after "substantially better than passwords&qu= ot;
and will likely transition to a cookie (bearer token) just after
signing. So I would argue that even an otherwise-undesirable 1500
bit modulus could be ok here, if a site has a way to bump that up
later, e.g. as new browsers deploy webcrypto. However, that is not
stuff that needs or ought be in the RFC.

For an experimental RFC we should not block on this. (I would myself
for a stds track but not exp.)

Yeah, OK.=C2=A0 I guess I can live with this.=C2=A0 Could w= e possibly add some bounding text, e.g.,

"Keys short= er than 2048 bits should only be used in cases where generating 2048-bit (o= r longer) keys is impractical, e.g., on constrained devices.=C2=A0 If an ap= plication uses short keys, then it MUST expire and re-generate keys periodi= cally, say every few weeks."


=C2=A0
>>>> (4) Given that the size of the header seems to be a concer= n (since
>> you're
>>>> not passing the key in the header), why are there no ECC s= igning
>>>> algorithms defined?=C2=A0 It seems like if you used any of= the normal curves,
>>>> you could comfortably pass the key along with the authenti= cation value.
>>>
>>> Because there is not yet agreement on which ECC signing algori= thms are
>> likely to be popular in a year or two. We're watching the CFRG= discussion,
>> and it is not yet coming to consensus. When it does, this Experime= ntal RFC
>> can be updated.
>>
>
> This is pretty weak sauce.=C2=A0 It's not like ECDSA with P-256 is= going to go
> away overnight when CFRG make up their minds.

The development platform issue that perhaps no longer exists for
sha256 is I believe still real for ecdsa.

But the main thing I'd like from the CFRG work would be to lose the
RNG requirement at signing time, which is unnecessarily a part of
ECDSA. That's a real security win, if we get it.

> Maybe I'm overly worried about the complexity here, but it seems l= ike using
> ECC could allow you to just shove the public key in the Authorization<= br> > header.=C2=A0 That would obviate the need for the registration resourc= e,
> resolving point 1 above, and generally make HOBA easier to implement.<= br> >
> Nonetheless, I moved this point to a COMMENT.
>
>
>>> (5) For that matter, why bother defining a new algorithm regis= try at all,
>>>> when JWA provides a perfectly nice one that only costs you= 4 characters.
>>>
>>> We did not want to be tied to the JWA registry, given that JOS= E could go
>> in quite different directions.
>>
>
> Fair enough.=C2=A0 Cleared this one.

Cool.

>
>
>
>>>
>>>> ----------------------------------------------------------= ------------
>>>> COMMENT:
>>>> ----------------------------------------------------------= ------------
>>>>
>>>> The HOBA-TBS construction seems really unnecessarily compl= icated.=C2=A0 Other
>>>> than in the "origin" component, there are no &qu= ot;:" characters allowed in
>>>> any of the components, so if you could remove the unnecess= arily pretty
>>>> serialization of the origin, you could just use ':'= ; as a delimiter.=C2=A0 Or
>>>> leave the origin, and delimit with something like %x20.=C2= =A0 Either way,
>> this
>>>> length construction seems like a pain to implement by comp= arison.
>>>
>>> We started with a less complex construction, and the WG specif= ically
>> asked for this.
>>>
>>>> "alg =3D 1*2DIGIT" - In general, it seems unwise= to limit code point
>> spaces
>>>> unnecessarily.
>>>
>>> It is also unwise to have more than 99 possible algorithms for= signing.
>>
>
> Sure, but that seems like a process issue, not one to enshrine in synt= ax.

The opposite I think. We seem unable to fix the vanity/national cryp= to
thing via process so I'd like to see us try via syntax myself. But
that's for another day:-)

Cheers,
S.

>
>
>
>>>> In addition to the funny title of Section 6.2.2, the conte= nts seem kind
>>>> of risible as well.=C2=A0 Making a OTP is 100% equivalent = to the mechanism
>>>> recommended in Section 6.2.3, and arguably more likely to = deploy (since
>>>> the OTP doesn't have special semantics of being a URI)= .
>>>
>>> There is wide disagreement on what is more likely to deploy. A= lso, I'm
>> pretty sure Stephen is correct about your view on OTP here.
>>>
>>>> Please update the algorithms so that the reader doesn'= t have to go look
>>>> up which algorithm this is (PKCS1 vs. PSS).
>>>>
>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]"= ;
>>>>
>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in = Section 8.2 of
>>>> [RFC3447]"
>>>
>>> Sounds good; now fixed in the post-IESG version.
>>>
>>>> Given how convoluted the use case is here, an example woul= d be very
>>>> helpful.=C2=A0 At the very least to demonstrate the syntax= of the
>>>> WWW-Authenticate header.
>>>
>>> This doesn't seem all that needed, regardless of your view= of
>> convolution.
>>>
>>> --Paul Hoffman
>>> _______________________________________________
>>> http-auth mailing list
>>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth
>>>
>>
>

<= br>
On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farr= ell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 08/01/15 10:23, Richard Barnes wrote:
> Hey guys,
>
> Thanks for responding productively to a DISCUSS that I admit was not > written very politely.=C2=A0 Sorry about that.

I do it myself from time to time, no probs. (And to be honest I
was more rude about your ballot in IM to someone else, so we're
even:-)

>
> Couple of comments inline.
>
> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> FWIW, I'm fine that Paul's recollection of the WG stuff is= better
>> than mine and with his putting the pkcs#1 stuff in too.
>>
>> S
>>
>> On 08/01/15 01:19, Paul Hoffman wrote:
>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes <rlb@ipv.sx> = wrote:
>>>> (1) It does not seem to me that the mechanism defined in t= his document
>>>> actually conforms to the framework for HTTP authentication= .=C2=A0 The general
>>>> framework defined in RFC 7235 is all scoped to a resource = -- you can
>>>> implement authorization for a specific resource, without i= mpacting
>>>> anything else on the server.=C2=A0 HOBA, by contrast, requ= ires the
>>>> authenticating resource to be also be correlated to severa= l resource
>>>> under .well-known, meaning that it will not be usable in a= large number
>>>> of deployment circumstances.=C2=A0 Was this issue discusse= d in the WG, and
>> was
>>>> there input from the broader HTTP community?
>>>
>>> Yes and yes. (Stephen is wrong that it was not.) The "aut= henticating
>> resource" in HOBA is purposely more expressive than that in R= FC 7235, and
>> thus takes more primitives than HTTP auth. There was plenty of WG<= br> >> discussion around this.
>>
>
> If you happen to have a pointer to that discussion, it would help me f= eel
> more comfortable.
>
> To be a little clearer about my concern, it seems like the fact that y= ou
> don't carry the public key in the Authorization header means that = the
> authenticating resource has to be tied to the .well-known/hoba/registe= r/
> resource.

Yes, that's true. But entirely acceptable as a reasonable limitation of the scheme. It's reasonable because a) less
header bloat if you send public key once, b) with RSA in
particular public keys are big, and c) I hold out the hope
that I can someday develop a privacy friendly kid type so
that the strongly identifying nature of the HOBA signature
is addressed. (I have not so far figured one out, sadly.)

So I still don't see a reason for this to block the experiment.

>
>
>
>>>> (2) What is your justification for using a SHA-1 based sig= nature in a
>> new
>>>> protocol, when it is being actively deprecated elsewhere, = in particular
>>>> the web PKI?
>>>
>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate= for a
>> MAY-level definition when there is a more popular algorithm (RSA-S= HA256) at
>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, t= here is no danger
>> to having it here.
>>
>
> But if you're REQUIRED to support RSA-SHA256, why would you ever u= se
> RSA-SHA1?
>
> Color me pretty skeptical that there are implementations that can'= t support
> SHA-2 nowadays.=C2=A0 I just saw a presentation yesterday about an IoT= crypto
> libary that fits within 64K and supports SHA-256 along with a bunch of=
> other algorithms.

That was the case with PHP when this work started and at that time I=
needed the rsa-sha1 code point for my code. That was only a year or
two ago. I bet there are still web sites with only that version of
PHP available today - that is scary but adding HOBA to such could
still represent a security improvement if it meant that a new
application can be deployed without a new password verifier DB, and
that would be the case since we have the rsa-sha1 codepoint. Taking
away the codepoint would prevent such being deployed. And we know
for sure that the relevant risk here is not the signature crypto
but is overwhelmingly and utterly the password verifier DB. You are
I fear arguing that we ought prioritise crypto plumbing over the
real security risk.

I have not done a survey of all web development platforms to check
if this is now a solved issue or not. You skepticism is fine (and
perhaps correct) but if you don't do that survey, then blocking on
that basis is not correct.

>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD= be used." -> MUST
>>>
>>> There is no interoperability mandate for particular RSA key le= ngths, so
>> "SHOULD" is more appropriate here (until the IESG finall= y gets around to
>> updating RFC 2119...).
>>
>
> This is not about interop, it's about achieving an appropriate sec= urity
> level.=C2=A0 That is another thing for which MUSTs are commonly used.<= br> >
> (If we're going to talk about 2119, the phrasing is "absolute= requirement
> of the specification", not "absolutely required for interop&= quot;.)
>
> To Stephen's point on JS performance: I made a little empirical te= st:
> http= ://www.ipv.sx/tmp/rsa-2048.html
>
> On a good laptop, a good phone, and a crappier phone, the time to gene= rate
> a 2048-bit key is roughly (choosing representative values after a few<= br> > clicks):
> MacBook Pro: 5340ms
> iPhone 6: 7192ms
> FirefoxOS Flame: 31084ms

I've seen it take >120s which is not usable in this context. = That
was on older iphones (4 I think) with various browsers. With some
older versions of IE on older laptops it's also horrendous.

> These values are not great, but they're within the range of asynch= ronous
> operations that web pages already have to deal with, especially given = that
> keygen is a once-per-origin operation.=C2=A0 As far as sign() operatio= ns, the
> worst case among these devices was ~500ms, which is again not terrible= .

Signing is tolerable in most cases thanks to the getchal and using a worker.

And the appropriate security level for HOBA is not the usual thing
actually. Here we're after "substantially better than passwords&qu= ot;
and will likely transition to a cookie (bearer token) just after
signing. So I would argue that even an otherwise-undesirable 1500
bit modulus could be ok here, if a site has a way to bump that up
later, e.g. as new browsers deploy webcrypto. However, that is not
stuff that needs or ought be in the RFC.

For an experimental RFC we should not block on this. (I would myself
for a stds track but not exp.)

>>>> (4) Given that the size of the header seems to be a concer= n (since
>> you're
>>>> not passing the key in the header), why are there no ECC s= igning
>>>> algorithms defined?=C2=A0 It seems like if you used any of= the normal curves,
>>>> you could comfortably pass the key along with the authenti= cation value.
>>>
>>> Because there is not yet agreement on which ECC signing algori= thms are
>> likely to be popular in a year or two. We're watching the CFRG= discussion,
>> and it is not yet coming to consensus. When it does, this Experime= ntal RFC
>> can be updated.
>>
>
> This is pretty weak sauce.=C2=A0 It's not like ECDSA with P-256 is= going to go
> away overnight when CFRG make up their minds.

The development platform issue that perhaps no longer exists for
sha256 is I believe still real for ecdsa.

But the main thing I'd like from the CFRG work would be to lose the
RNG requirement at signing time, which is unnecessarily a part of
ECDSA. That's a real security win, if we get it.

> Maybe I'm overly worried about the complexity here, but it seems l= ike using
> ECC could allow you to just shove the public key in the Authorization<= br> > header.=C2=A0 That would obviate the need for the registration resourc= e,
> resolving point 1 above, and generally make HOBA easier to implement.<= br> >
> Nonetheless, I moved this point to a COMMENT.
>
>
>>> (5) For that matter, why bother defining a new algorithm regis= try at all,
>>>> when JWA provides a perfectly nice one that only costs you= 4 characters.
>>>
>>> We did not want to be tied to the JWA registry, given that JOS= E could go
>> in quite different directions.
>>
>
> Fair enough.=C2=A0 Cleared this one.

Cool.

>
>
>
>>>
>>>> ----------------------------------------------------------= ------------
>>>> COMMENT:
>>>> ----------------------------------------------------------= ------------
>>>>
>>>> The HOBA-TBS construction seems really unnecessarily compl= icated.=C2=A0 Other
>>>> than in the "origin" component, there are no &qu= ot;:" characters allowed in
>>>> any of the components, so if you could remove the unnecess= arily pretty
>>>> serialization of the origin, you could just use ':'= ; as a delimiter.=C2=A0 Or
>>>> leave the origin, and delimit with something like %x20.=C2= =A0 Either way,
>> this
>>>> length construction seems like a pain to implement by comp= arison.
>>>
>>> We started with a less complex construction, and the WG specif= ically
>> asked for this.
>>>
>>>> "alg =3D 1*2DIGIT" - In general, it seems unwise= to limit code point
>> spaces
>>>> unnecessarily.
>>>
>>> It is also unwise to have more than 99 possible algorithms for= signing.
>>
>
> Sure, but that seems like a process issue, not one to enshrine in synt= ax.

The opposite I think. We seem unable to fix the vanity/national cryp= to
thing via process so I'd like to see us try via syntax myself. But
that's for another day:-)

Cheers,
S.

>
>
>
>>>> In addition to the funny title of Section 6.2.2, the conte= nts seem kind
>>>> of risible as well.=C2=A0 Making a OTP is 100% equivalent = to the mechanism
>>>> recommended in Section 6.2.3, and arguably more likely to = deploy (since
>>>> the OTP doesn't have special semantics of being a URI)= .
>>>
>>> There is wide disagreement on what is more likely to deploy. A= lso, I'm
>> pretty sure Stephen is correct about your view on OTP here.
>>>
>>>> Please update the algorithms so that the reader doesn'= t have to go look
>>>> up which algorithm this is (PKCS1 vs. PSS).
>>>>
>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]"= ;
>>>>
>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in = Section 8.2 of
>>>> [RFC3447]"
>>>
>>> Sounds good; now fixed in the post-IESG version.
>>>
>>>> Given how convoluted the use case is here, an example woul= d be very
>>>> helpful.=C2=A0 At the very least to demonstrate the syntax= of the
>>>> WWW-Authenticate header.
>>>
>>> This doesn't seem all that needed, regardless of your view= of
>> convolution.
>>>
>>> --Paul Hoffman
>>> _______________________________________________
>>> http-auth mailing list
>>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth
>>>
>>
>

--089e0160b7dafd67c7050c22df36-- From nobody Thu Jan 8 04:40:35 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A329B1A89F0; Thu, 8 Jan 2015 04:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws5xoRCu_m7N; Thu, 8 Jan 2015 04:40:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0261ACCE2; Thu, 8 Jan 2015 04:40:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A95DEBEB6; Thu, 8 Jan 2015 12:40:23 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl8WF76bkSAv; Thu, 8 Jan 2015 12:40:20 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6B98ABEDB; Thu, 8 Jan 2015 12:40:15 +0000 (GMT) Message-ID: <54AE7AA0.2000100@cs.tcd.ie> Date: Thu, 08 Jan 2015 12:40:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Richard Barnes References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADDC98.4000009@cs.tcd.ie> <54AE6DF2.80500@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, Paul Hoffman , The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:40:33 -0000 (Richard and I plan to chat via IM before the call hopefully so this is more to tee that up than to clear right now.) There are a couple of changes below, those are done in the working version at the usual [1,2]. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt On 08/01/15 12:06, Richard Barnes wrote: > On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell > wrote: > >> >> Hiya, >> >> On 08/01/15 10:23, Richard Barnes wrote: >>> Hey guys, >>> >>> Thanks for responding productively to a DISCUSS that I admit was not >>> written very politely. Sorry about that. >> >> I do it myself from time to time, no probs. (And to be honest I >> was more rude about your ballot in IM to someone else, so we're >> even:-) >> >>> >>> Couple of comments inline. >>> >>> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> >>> wrote: >>> >>>> >>>> FWIW, I'm fine that Paul's recollection of the WG stuff is better >>>> than mine and with his putting the pkcs#1 stuff in too. >>>> >>>> S >>>> >>>> On 08/01/15 01:19, Paul Hoffman wrote: >>>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: >>>>>> (1) It does not seem to me that the mechanism defined in this document >>>>>> actually conforms to the framework for HTTP authentication. The >> general >>>>>> framework defined in RFC 7235 is all scoped to a resource -- you can >>>>>> implement authorization for a specific resource, without impacting >>>>>> anything else on the server. HOBA, by contrast, requires the >>>>>> authenticating resource to be also be correlated to several resource >>>>>> under .well-known, meaning that it will not be usable in a large >> number >>>>>> of deployment circumstances. Was this issue discussed in the WG, and >>>> was >>>>>> there input from the broader HTTP community? >>>>> >>>>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating >>>> resource" in HOBA is purposely more expressive than that in RFC 7235, >> and >>>> thus takes more primitives than HTTP auth. There was plenty of WG >>>> discussion around this. >>>> >>> >>> If you happen to have a pointer to that discussion, it would help me feel >>> more comfortable. >>> >>> To be a little clearer about my concern, it seems like the fact that you >>> don't carry the public key in the Authorization header means that the >>> authenticating resource has to be tied to the .well-known/hoba/register/ >>> resource. >> >> Yes, that's true. But entirely acceptable as a reasonable >> limitation of the scheme. It's reasonable because a) less >> header bloat if you send public key once, b) with RSA in >> particular public keys are big, and c) I hold out the hope >> that I can someday develop a privacy friendly kid type so >> that the strongly identifying nature of the HOBA signature >> is addressed. (I have not so far figured one out, sadly.) >> >> So I still don't see a reason for this to block the experiment. >> >>> >>> >>> >>>>>> (2) What is your justification for using a SHA-1 based signature in a >>>> new >>>>>> protocol, when it is being actively deprecated elsewhere, in >> particular >>>>>> the web PKI? >>>>> >>>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a >>>> MAY-level definition when there is a more popular algorithm >> (RSA-SHA256) at >>>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no >> danger >>>> to having it here. >>>> >>> >>> But if you're REQUIRED to support RSA-SHA256, why would you ever use >>> RSA-SHA1? >>> >>> Color me pretty skeptical that there are implementations that can't >> support >>> SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto >>> libary that fits within 64K and supports SHA-256 along with a bunch of >>> other algorithms. >> >> That was the case with PHP when this work started and at that time I >> needed the rsa-sha1 code point for my code. That was only a year or >> two ago. I bet there are still web sites with only that version of >> PHP available today - that is scary but adding HOBA to such could >> still represent a security improvement if it meant that a new >> application can be deployed without a new password verifier DB, and >> that would be the case since we have the rsa-sha1 codepoint. Taking >> away the codepoint would prevent such being deployed. And we know >> for sure that the relevant risk here is not the signature crypto >> but is overwhelmingly and utterly the password verifier DB. You are >> I fear arguing that we ought prioritise crypto plumbing over the >> real security risk. >> >> I have not done a survey of all web development platforms to check >> if this is now a solved issue or not. You skepticism is fine (and >> perhaps correct) but if you don't do that survey, then blocking on >> that basis is not correct. >> > > Isn't the burden on the one trying to weaken the protocol? :) > > All of the web development platforms I can think of have SHA-2 support. > Looking at the list on wikipedia: > http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites > > ASP.NET, C, C++, Java, JavaScript, Perl, Python, Ruby: Should be obvious > PHP, Xhp, Hack: http://php.net/manual/en/function.hash.php > Scala: https://github.com/Nycto/Hasher > Go: http://golang.org/pkg/crypto/sha256/ > Erlang: http://erlang.org/doc/man/crypto.html > D: http://dlang.org/phobos/std_digest_sha.html > > So unless you can come up with a platform that *doesn't* support SHA-2, I > don't see why it should be allowed. > > In any event, it seems like this whole pageant is moot, since the document > *requires* SHA-2 support. If you've got that, why would you ever do > SHA-1? Because e.g. PHP4 is still installed on a site where I don't get to fix that. Shodanhq indicates there are a number of those still about, though less than I'd have expected, but not sure if they search for that deliberately or as a side-effect. But anyway, I have no problem saying rsa-sha1 MUST NOT be used except in cases like that where you have no choice. Given that the codepoint was in the draft for quite a while, it seems silly (process-wonkery?:-) to take it out now and then maybe re-use it for something else later, so I'd argue we can leave the code point. So I added: "RSA-SHA1 MUST NOT be used, except in cases where SHA256 is unavailable, say if some developmemt platform has to be used that is quite out of date." Happy to wordsmith that. > > > >>>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> >> MUST >>>>> >>>>> There is no interoperability mandate for particular RSA key lengths, so >>>> "SHOULD" is more appropriate here (until the IESG finally gets around to >>>> updating RFC 2119...). >>>> >>> >>> This is not about interop, it's about achieving an appropriate security >>> level. That is another thing for which MUSTs are commonly used. >>> >>> (If we're going to talk about 2119, the phrasing is "absolute requirement >>> of the specification", not "absolutely required for interop".) >>> >>> To Stephen's point on JS performance: I made a little empirical test: >>> http://www.ipv.sx/tmp/rsa-2048.html >>> >>> On a good laptop, a good phone, and a crappier phone, the time to >> generate >>> a 2048-bit key is roughly (choosing representative values after a few >>> clicks): >>> MacBook Pro: 5340ms >>> iPhone 6: 7192ms >>> FirefoxOS Flame: 31084ms >> >> I've seen it take >120s which is not usable in this context. That >> was on older iphones (4 I think) with various browsers. With some >> older versions of IE on older laptops it's also horrendous. >> >>> These values are not great, but they're within the range of asynchronous >>> operations that web pages already have to deal with, especially given >> that >>> keygen is a once-per-origin operation. As far as sign() operations, the >>> worst case among these devices was ~500ms, which is again not terrible. >> >> Signing is tolerable in most cases thanks to the getchal and using >> a worker. >> >> And the appropriate security level for HOBA is not the usual thing >> actually. Here we're after "substantially better than passwords" >> and will likely transition to a cookie (bearer token) just after >> signing. So I would argue that even an otherwise-undesirable 1500 >> bit modulus could be ok here, if a site has a way to bump that up >> later, e.g. as new browsers deploy webcrypto. However, that is not >> stuff that needs or ought be in the RFC. >> >> For an experimental RFC we should not block on this. (I would myself >> for a stds track but not exp.) >> > > Yeah, OK. I guess I can live with this. Could we possibly add some > bounding text, e.g., > > "Keys shorter than 2048 bits should only be used in cases where generating > 2048-bit (or longer) keys is impractical, e.g., on constrained devices. If > an application uses short keys, then it MUST expire and re-generate keys > periodically, say every few weeks." I've added the first sentence. I don't think the 2nd is wise really but will explain in IM as its a bit convoluted. (And of course, HOBA itself has no concept of expiry at all, that's for the account handling code.) Cheers, S. > > > > >>>>>> (4) Given that the size of the header seems to be a concern (since >>>> you're >>>>>> not passing the key in the header), why are there no ECC signing >>>>>> algorithms defined? It seems like if you used any of the normal >> curves, >>>>>> you could comfortably pass the key along with the authentication >> value. >>>>> >>>>> Because there is not yet agreement on which ECC signing algorithms are >>>> likely to be popular in a year or two. We're watching the CFRG >> discussion, >>>> and it is not yet coming to consensus. When it does, this Experimental >> RFC >>>> can be updated. >>>> >>> >>> This is pretty weak sauce. It's not like ECDSA with P-256 is going to go >>> away overnight when CFRG make up their minds. >> >> The development platform issue that perhaps no longer exists for >> sha256 is I believe still real for ecdsa. >> >> But the main thing I'd like from the CFRG work would be to lose the >> RNG requirement at signing time, which is unnecessarily a part of >> ECDSA. That's a real security win, if we get it. >> >>> Maybe I'm overly worried about the complexity here, but it seems like >> using >>> ECC could allow you to just shove the public key in the Authorization >>> header. That would obviate the need for the registration resource, >>> resolving point 1 above, and generally make HOBA easier to implement. >>> >>> Nonetheless, I moved this point to a COMMENT. >>> >>> >>>>> (5) For that matter, why bother defining a new algorithm registry at >> all, >>>>>> when JWA provides a perfectly nice one that only costs you 4 >> characters. >>>>> >>>>> We did not want to be tied to the JWA registry, given that JOSE could >> go >>>> in quite different directions. >>>> >>> >>> Fair enough. Cleared this one. >> >> Cool. >> >>> >>> >>> >>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> The HOBA-TBS construction seems really unnecessarily complicated. >> Other >>>>>> than in the "origin" component, there are no ":" characters allowed in >>>>>> any of the components, so if you could remove the unnecessarily pretty >>>>>> serialization of the origin, you could just use ':' as a delimiter. >> Or >>>>>> leave the origin, and delimit with something like %x20. Either way, >>>> this >>>>>> length construction seems like a pain to implement by comparison. >>>>> >>>>> We started with a less complex construction, and the WG specifically >>>> asked for this. >>>>> >>>>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point >>>> spaces >>>>>> unnecessarily. >>>>> >>>>> It is also unwise to have more than 99 possible algorithms for signing. >>>> >>> >>> Sure, but that seems like a process issue, not one to enshrine in syntax. >> >> The opposite I think. We seem unable to fix the vanity/national crypto >> thing via process so I'd like to see us try via syntax myself. But >> that's for another day:-) >> >> Cheers, >> S. >> >>> >>> >>> >>>>>> In addition to the funny title of Section 6.2.2, the contents seem >> kind >>>>>> of risible as well. Making a OTP is 100% equivalent to the mechanism >>>>>> recommended in Section 6.2.3, and arguably more likely to deploy >> (since >>>>>> the OTP doesn't have special semantics of being a URI). >>>>> >>>>> There is wide disagreement on what is more likely to deploy. Also, I'm >>>> pretty sure Stephen is correct about your view on OTP here. >>>>> >>>>>> Please update the algorithms so that the reader doesn't have to go >> look >>>>>> up which algorithm this is (PKCS1 vs. PSS). >>>>>> >>>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" >>>>>> >>>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of >>>>>> [RFC3447]" >>>>> >>>>> Sounds good; now fixed in the post-IESG version. >>>>> >>>>>> Given how convoluted the use case is here, an example would be very >>>>>> helpful. At the very least to demonstrate the syntax of the >>>>>> WWW-Authenticate header. >>>>> >>>>> This doesn't seem all that needed, regardless of your view of >>>> convolution. >>>>> >>>>> --Paul Hoffman >>>>> _______________________________________________ >>>>> http-auth mailing list >>>>> http-auth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/http-auth >>>>> >>>> >>> >> > > > On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell > wrote: > >> >> Hiya, >> >> On 08/01/15 10:23, Richard Barnes wrote: >>> Hey guys, >>> >>> Thanks for responding productively to a DISCUSS that I admit was not >>> written very politely. Sorry about that. >> >> I do it myself from time to time, no probs. (And to be honest I >> was more rude about your ballot in IM to someone else, so we're >> even:-) >> >>> >>> Couple of comments inline. >>> >>> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> >>> wrote: >>> >>>> >>>> FWIW, I'm fine that Paul's recollection of the WG stuff is better >>>> than mine and with his putting the pkcs#1 stuff in too. >>>> >>>> S >>>> >>>> On 08/01/15 01:19, Paul Hoffman wrote: >>>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: >>>>>> (1) It does not seem to me that the mechanism defined in this document >>>>>> actually conforms to the framework for HTTP authentication. The >> general >>>>>> framework defined in RFC 7235 is all scoped to a resource -- you can >>>>>> implement authorization for a specific resource, without impacting >>>>>> anything else on the server. HOBA, by contrast, requires the >>>>>> authenticating resource to be also be correlated to several resource >>>>>> under .well-known, meaning that it will not be usable in a large >> number >>>>>> of deployment circumstances. Was this issue discussed in the WG, and >>>> was >>>>>> there input from the broader HTTP community? >>>>> >>>>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating >>>> resource" in HOBA is purposely more expressive than that in RFC 7235, >> and >>>> thus takes more primitives than HTTP auth. There was plenty of WG >>>> discussion around this. >>>> >>> >>> If you happen to have a pointer to that discussion, it would help me feel >>> more comfortable. >>> >>> To be a little clearer about my concern, it seems like the fact that you >>> don't carry the public key in the Authorization header means that the >>> authenticating resource has to be tied to the .well-known/hoba/register/ >>> resource. >> >> Yes, that's true. But entirely acceptable as a reasonable >> limitation of the scheme. It's reasonable because a) less >> header bloat if you send public key once, b) with RSA in >> particular public keys are big, and c) I hold out the hope >> that I can someday develop a privacy friendly kid type so >> that the strongly identifying nature of the HOBA signature >> is addressed. (I have not so far figured one out, sadly.) >> >> So I still don't see a reason for this to block the experiment. >> >>> >>> >>> >>>>>> (2) What is your justification for using a SHA-1 based signature in a >>>> new >>>>>> protocol, when it is being actively deprecated elsewhere, in >> particular >>>>>> the web PKI? >>>>> >>>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a >>>> MAY-level definition when there is a more popular algorithm >> (RSA-SHA256) at >>>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no >> danger >>>> to having it here. >>>> >>> >>> But if you're REQUIRED to support RSA-SHA256, why would you ever use >>> RSA-SHA1? >>> >>> Color me pretty skeptical that there are implementations that can't >> support >>> SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto >>> libary that fits within 64K and supports SHA-256 along with a bunch of >>> other algorithms. >> >> That was the case with PHP when this work started and at that time I >> needed the rsa-sha1 code point for my code. That was only a year or >> two ago. I bet there are still web sites with only that version of >> PHP available today - that is scary but adding HOBA to such could >> still represent a security improvement if it meant that a new >> application can be deployed without a new password verifier DB, and >> that would be the case since we have the rsa-sha1 codepoint. Taking >> away the codepoint would prevent such being deployed. And we know >> for sure that the relevant risk here is not the signature crypto >> but is overwhelmingly and utterly the password verifier DB. You are >> I fear arguing that we ought prioritise crypto plumbing over the >> real security risk. >> >> I have not done a survey of all web development platforms to check >> if this is now a solved issue or not. You skepticism is fine (and >> perhaps correct) but if you don't do that survey, then blocking on >> that basis is not correct. >> >>>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> >> MUST >>>>> >>>>> There is no interoperability mandate for particular RSA key lengths, so >>>> "SHOULD" is more appropriate here (until the IESG finally gets around to >>>> updating RFC 2119...). >>>> >>> >>> This is not about interop, it's about achieving an appropriate security >>> level. That is another thing for which MUSTs are commonly used. >>> >>> (If we're going to talk about 2119, the phrasing is "absolute requirement >>> of the specification", not "absolutely required for interop".) >>> >>> To Stephen's point on JS performance: I made a little empirical test: >>> http://www.ipv.sx/tmp/rsa-2048.html >>> >>> On a good laptop, a good phone, and a crappier phone, the time to >> generate >>> a 2048-bit key is roughly (choosing representative values after a few >>> clicks): >>> MacBook Pro: 5340ms >>> iPhone 6: 7192ms >>> FirefoxOS Flame: 31084ms >> >> I've seen it take >120s which is not usable in this context. That >> was on older iphones (4 I think) with various browsers. With some >> older versions of IE on older laptops it's also horrendous. >> >>> These values are not great, but they're within the range of asynchronous >>> operations that web pages already have to deal with, especially given >> that >>> keygen is a once-per-origin operation. As far as sign() operations, the >>> worst case among these devices was ~500ms, which is again not terrible. >> >> Signing is tolerable in most cases thanks to the getchal and using >> a worker. >> >> And the appropriate security level for HOBA is not the usual thing >> actually. Here we're after "substantially better than passwords" >> and will likely transition to a cookie (bearer token) just after >> signing. So I would argue that even an otherwise-undesirable 1500 >> bit modulus could be ok here, if a site has a way to bump that up >> later, e.g. as new browsers deploy webcrypto. However, that is not >> stuff that needs or ought be in the RFC. >> >> For an experimental RFC we should not block on this. (I would myself >> for a stds track but not exp.) >> >>>>>> (4) Given that the size of the header seems to be a concern (since >>>> you're >>>>>> not passing the key in the header), why are there no ECC signing >>>>>> algorithms defined? It seems like if you used any of the normal >> curves, >>>>>> you could comfortably pass the key along with the authentication >> value. >>>>> >>>>> Because there is not yet agreement on which ECC signing algorithms are >>>> likely to be popular in a year or two. We're watching the CFRG >> discussion, >>>> and it is not yet coming to consensus. When it does, this Experimental >> RFC >>>> can be updated. >>>> >>> >>> This is pretty weak sauce. It's not like ECDSA with P-256 is going to go >>> away overnight when CFRG make up their minds. >> >> The development platform issue that perhaps no longer exists for >> sha256 is I believe still real for ecdsa. >> >> But the main thing I'd like from the CFRG work would be to lose the >> RNG requirement at signing time, which is unnecessarily a part of >> ECDSA. That's a real security win, if we get it. >> >>> Maybe I'm overly worried about the complexity here, but it seems like >> using >>> ECC could allow you to just shove the public key in the Authorization >>> header. That would obviate the need for the registration resource, >>> resolving point 1 above, and generally make HOBA easier to implement. >>> >>> Nonetheless, I moved this point to a COMMENT. >>> >>> >>>>> (5) For that matter, why bother defining a new algorithm registry at >> all, >>>>>> when JWA provides a perfectly nice one that only costs you 4 >> characters. >>>>> >>>>> We did not want to be tied to the JWA registry, given that JOSE could >> go >>>> in quite different directions. >>>> >>> >>> Fair enough. Cleared this one. >> >> Cool. >> >>> >>> >>> >>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> The HOBA-TBS construction seems really unnecessarily complicated. >> Other >>>>>> than in the "origin" component, there are no ":" characters allowed in >>>>>> any of the components, so if you could remove the unnecessarily pretty >>>>>> serialization of the origin, you could just use ':' as a delimiter. >> Or >>>>>> leave the origin, and delimit with something like %x20. Either way, >>>> this >>>>>> length construction seems like a pain to implement by comparison. >>>>> >>>>> We started with a less complex construction, and the WG specifically >>>> asked for this. >>>>> >>>>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point >>>> spaces >>>>>> unnecessarily. >>>>> >>>>> It is also unwise to have more than 99 possible algorithms for signing. >>>> >>> >>> Sure, but that seems like a process issue, not one to enshrine in syntax. >> >> The opposite I think. We seem unable to fix the vanity/national crypto >> thing via process so I'd like to see us try via syntax myself. But >> that's for another day:-) >> >> Cheers, >> S. >> >>> >>> >>> >>>>>> In addition to the funny title of Section 6.2.2, the contents seem >> kind >>>>>> of risible as well. Making a OTP is 100% equivalent to the mechanism >>>>>> recommended in Section 6.2.3, and arguably more likely to deploy >> (since >>>>>> the OTP doesn't have special semantics of being a URI). >>>>> >>>>> There is wide disagreement on what is more likely to deploy. Also, I'm >>>> pretty sure Stephen is correct about your view on OTP here. >>>>> >>>>>> Please update the algorithms so that the reader doesn't have to go >> look >>>>>> up which algorithm this is (PKCS1 vs. PSS). >>>>>> >>>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" >>>>>> >>>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of >>>>>> [RFC3447]" >>>>> >>>>> Sounds good; now fixed in the post-IESG version. >>>>> >>>>>> Given how convoluted the use case is here, an example would be very >>>>>> helpful. At the very least to demonstrate the syntax of the >>>>>> WWW-Authenticate header. >>>>> >>>>> This doesn't seem all that needed, regardless of your view of >>>> convolution. >>>>> >>>>> --Paul Hoffman >>>>> _______________________________________________ >>>>> http-auth mailing list >>>>> http-auth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/http-auth >>>>> >>>> >>> >> > From nobody Thu Jan 8 06:12:41 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16241A6FFC; Thu, 8 Jan 2015 06:12:29 -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 s7wy0s0euehM; Thu, 8 Jan 2015 06:12:24 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031751A1A58; Thu, 8 Jan 2015 06:11:41 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so3144896lbg.5; Thu, 08 Jan 2015 06:11:39 -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=OlfmXORr3SR8IfCDzc7ui8FsXJ8hk0u3Z3oU4jGeY1A=; b=ZRSDGAZaCDK4OBUlPrDF9BqVqF0YVAi0FLg7qoRDsroRr+KY5rmJQbr8aep/+71YLv 9eRTlX4Iyw6Y9VxiFWgrjQke6M4V+r5myU9xtOMhR9rp9LU/SozakFChcmsJjudsZrYr uZduLswKQNKjqRTCZvI+ZNTwNzPjwDLw5iZZEVi8qZAnv76EpdUdlo12Sh6I8HV0dMFX ZPfhrK64e2f33HtrJhAq6IheABM7rfYhwuwKCcoacMPo0XH4pAsj8bavdrqHX1340+av qeZ/HcLjozRfL1PJoId2wuDALvCeY+nAirpObctgeIA612nOck618lYWRIb3tmyURi3A u09Q== MIME-Version: 1.0 X-Received: by 10.112.52.229 with SMTP id w5mr13958219lbo.52.1420726299268; Thu, 08 Jan 2015 06:11:39 -0800 (PST) Received: by 10.112.49.52 with HTTP; Thu, 8 Jan 2015 06:11:39 -0800 (PST) In-Reply-To: <54AE7AA0.2000100@cs.tcd.ie> References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADDC98.4000009@cs.tcd.ie> <54AE6DF2.80500@cs.tcd.ie> <54AE7AA0.2000100@cs.tcd.ie> Date: Thu, 8 Jan 2015 09:11:39 -0500 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "httpauth-chairs@tools.ietf.org" , Richard Barnes , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , Paul Hoffman , "http-auth@ietf.org" , The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:12:30 -0000 On Thu, Jan 8, 2015 at 7:40 AM, Stephen Farrell wrote: > > (Richard and I plan to chat via IM before the call hopefully > so this is more to tee that up than to clear right now.) > > There are a couple of changes below, those are done in the > working version at the usual [1,2]. > > [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > [2] > https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > > On 08/01/15 12:06, Richard Barnes wrote: >> On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell >> wrote: >> >>> >>> Hiya, >>> >>> On 08/01/15 10:23, Richard Barnes wrote: >>>> Hey guys, >>>> >>>> Thanks for responding productively to a DISCUSS that I admit was not >>>> written very politely. Sorry about that. >>> >>> I do it myself from time to time, no probs. (And to be honest I >>> was more rude about your ballot in IM to someone else, so we're >>> even:-) >>> >>>> >>>> Couple of comments inline. >>>> >>>> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell < >>> stephen.farrell@cs.tcd.ie> >>>> wrote: >>>> >>>>> >>>>> FWIW, I'm fine that Paul's recollection of the WG stuff is better >>>>> than mine and with his putting the pkcs#1 stuff in too. >>>>> >>>>> S >>>>> >>>>> On 08/01/15 01:19, Paul Hoffman wrote: >>>>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: >>>>>>> (1) It does not seem to me that the mechanism defined in this document >>>>>>> actually conforms to the framework for HTTP authentication. The >>> general >>>>>>> framework defined in RFC 7235 is all scoped to a resource -- you can >>>>>>> implement authorization for a specific resource, without impacting >>>>>>> anything else on the server. HOBA, by contrast, requires the >>>>>>> authenticating resource to be also be correlated to several resource >>>>>>> under .well-known, meaning that it will not be usable in a large >>> number >>>>>>> of deployment circumstances. Was this issue discussed in the WG, and >>>>> was >>>>>>> there input from the broader HTTP community? >>>>>> >>>>>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating >>>>> resource" in HOBA is purposely more expressive than that in RFC 7235, >>> and >>>>> thus takes more primitives than HTTP auth. There was plenty of WG >>>>> discussion around this. >>>>> >>>> >>>> If you happen to have a pointer to that discussion, it would help me feel >>>> more comfortable. >>>> >>>> To be a little clearer about my concern, it seems like the fact that you >>>> don't carry the public key in the Authorization header means that the >>>> authenticating resource has to be tied to the .well-known/hoba/register/ >>>> resource. >>> >>> Yes, that's true. But entirely acceptable as a reasonable >>> limitation of the scheme. It's reasonable because a) less >>> header bloat if you send public key once, b) with RSA in >>> particular public keys are big, and c) I hold out the hope >>> that I can someday develop a privacy friendly kid type so >>> that the strongly identifying nature of the HOBA signature >>> is addressed. (I have not so far figured one out, sadly.) >>> >>> So I still don't see a reason for this to block the experiment. >>> >>>> >>>> >>>> >>>>>>> (2) What is your justification for using a SHA-1 based signature in a >>>>> new >>>>>>> protocol, when it is being actively deprecated elsewhere, in >>> particular >>>>>>> the web PKI? >>>>>> >>>>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a >>>>> MAY-level definition when there is a more popular algorithm >>> (RSA-SHA256) at >>>>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no >>> danger >>>>> to having it here. >>>>> >>>> >>>> But if you're REQUIRED to support RSA-SHA256, why would you ever use >>>> RSA-SHA1? >>>> >>>> Color me pretty skeptical that there are implementations that can't >>> support >>>> SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto >>>> libary that fits within 64K and supports SHA-256 along with a bunch of >>>> other algorithms. >>> >>> That was the case with PHP when this work started and at that time I >>> needed the rsa-sha1 code point for my code. That was only a year or >>> two ago. I bet there are still web sites with only that version of >>> PHP available today - that is scary but adding HOBA to such could >>> still represent a security improvement if it meant that a new >>> application can be deployed without a new password verifier DB, and >>> that would be the case since we have the rsa-sha1 codepoint. Taking >>> away the codepoint would prevent such being deployed. And we know >>> for sure that the relevant risk here is not the signature crypto >>> but is overwhelmingly and utterly the password verifier DB. You are >>> I fear arguing that we ought prioritise crypto plumbing over the >>> real security risk. >>> >>> I have not done a survey of all web development platforms to check >>> if this is now a solved issue or not. You skepticism is fine (and >>> perhaps correct) but if you don't do that survey, then blocking on >>> that basis is not correct. >>> >> >> Isn't the burden on the one trying to weaken the protocol? :) >> >> All of the web development platforms I can think of have SHA-2 support. >> Looking at the list on wikipedia: >> http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites >> >> ASP.NET, C, C++, Java, JavaScript, Perl, Python, Ruby: Should be obvious >> PHP, Xhp, Hack: http://php.net/manual/en/function.hash.php >> Scala: https://github.com/Nycto/Hasher >> Go: http://golang.org/pkg/crypto/sha256/ >> Erlang: http://erlang.org/doc/man/crypto.html >> D: http://dlang.org/phobos/std_digest_sha.html >> >> So unless you can come up with a platform that *doesn't* support SHA-2, I >> don't see why it should be allowed. >> >> In any event, it seems like this whole pageant is moot, since the document >> *requires* SHA-2 support. If you've got that, why would you ever do >> SHA-1? > > Because e.g. PHP4 is still installed on a site where I don't > get to fix that. Shodanhq indicates there are a number of those > still about, though less than I'd have expected, but not sure > if they search for that deliberately or as a side-effect. > > But anyway, I have no problem saying rsa-sha1 MUST NOT be used > except in cases like that where you have no choice. > > Given that the codepoint was in the draft for quite a while, > it seems silly (process-wonkery?:-) to take it out now and > then maybe re-use it for something else later, so I'd argue > we can leave the code point. > > So I added: > > "RSA-SHA1 MUST > NOT be used, except in cases where SHA256 is unavailable, say > if some developmemt platform has to be used that is quite out > of date." Thanks, I think this is a good change and in-line with what we've asked on other drafts. I don't think RSA-SHA1 should be needed and would be good to deprecate it where possible. You will just want to fix the typo on "development". I'm not sure why someone would want to use a development platform that is really out-of-date though. We shouldn't encourage that as it presents additional risks, but this text is an improvement... -Kathleen > > Happy to wordsmith that. > > >> >> >> >>>>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> >>> MUST >>>>>> >>>>>> There is no interoperability mandate for particular RSA key lengths, so >>>>> "SHOULD" is more appropriate here (until the IESG finally gets around to >>>>> updating RFC 2119...). >>>>> >>>> >>>> This is not about interop, it's about achieving an appropriate security >>>> level. That is another thing for which MUSTs are commonly used. >>>> >>>> (If we're going to talk about 2119, the phrasing is "absolute requirement >>>> of the specification", not "absolutely required for interop".) >>>> >>>> To Stephen's point on JS performance: I made a little empirical test: >>>> http://www.ipv.sx/tmp/rsa-2048.html >>>> >>>> On a good laptop, a good phone, and a crappier phone, the time to >>> generate >>>> a 2048-bit key is roughly (choosing representative values after a few >>>> clicks): >>>> MacBook Pro: 5340ms >>>> iPhone 6: 7192ms >>>> FirefoxOS Flame: 31084ms >>> >>> I've seen it take >120s which is not usable in this context. That >>> was on older iphones (4 I think) with various browsers. With some >>> older versions of IE on older laptops it's also horrendous. >>> >>>> These values are not great, but they're within the range of asynchronous >>>> operations that web pages already have to deal with, especially given >>> that >>>> keygen is a once-per-origin operation. As far as sign() operations, the >>>> worst case among these devices was ~500ms, which is again not terrible. >>> >>> Signing is tolerable in most cases thanks to the getchal and using >>> a worker. >>> >>> And the appropriate security level for HOBA is not the usual thing >>> actually. Here we're after "substantially better than passwords" >>> and will likely transition to a cookie (bearer token) just after >>> signing. So I would argue that even an otherwise-undesirable 1500 >>> bit modulus could be ok here, if a site has a way to bump that up >>> later, e.g. as new browsers deploy webcrypto. However, that is not >>> stuff that needs or ought be in the RFC. >>> >>> For an experimental RFC we should not block on this. (I would myself >>> for a stds track but not exp.) >>> >> >> Yeah, OK. I guess I can live with this. Could we possibly add some >> bounding text, e.g., >> >> "Keys shorter than 2048 bits should only be used in cases where generating >> 2048-bit (or longer) keys is impractical, e.g., on constrained devices. If >> an application uses short keys, then it MUST expire and re-generate keys >> periodically, say every few weeks." > > I've added the first sentence. I don't think the 2nd is wise > really but will explain in IM as its a bit convoluted. (And > of course, HOBA itself has no concept of expiry at all, that's > for the account handling code.) > > Cheers, > S. > >> >> >> >> >>>>>>> (4) Given that the size of the header seems to be a concern (since >>>>> you're >>>>>>> not passing the key in the header), why are there no ECC signing >>>>>>> algorithms defined? It seems like if you used any of the normal >>> curves, >>>>>>> you could comfortably pass the key along with the authentication >>> value. >>>>>> >>>>>> Because there is not yet agreement on which ECC signing algorithms are >>>>> likely to be popular in a year or two. We're watching the CFRG >>> discussion, >>>>> and it is not yet coming to consensus. When it does, this Experimental >>> RFC >>>>> can be updated. >>>>> >>>> >>>> This is pretty weak sauce. It's not like ECDSA with P-256 is going to go >>>> away overnight when CFRG make up their minds. >>> >>> The development platform issue that perhaps no longer exists for >>> sha256 is I believe still real for ecdsa. >>> >>> But the main thing I'd like from the CFRG work would be to lose the >>> RNG requirement at signing time, which is unnecessarily a part of >>> ECDSA. That's a real security win, if we get it. >>> >>>> Maybe I'm overly worried about the complexity here, but it seems like >>> using >>>> ECC could allow you to just shove the public key in the Authorization >>>> header. That would obviate the need for the registration resource, >>>> resolving point 1 above, and generally make HOBA easier to implement. >>>> >>>> Nonetheless, I moved this point to a COMMENT. >>>> >>>> >>>>>> (5) For that matter, why bother defining a new algorithm registry at >>> all, >>>>>>> when JWA provides a perfectly nice one that only costs you 4 >>> characters. >>>>>> >>>>>> We did not want to be tied to the JWA registry, given that JOSE could >>> go >>>>> in quite different directions. >>>>> >>>> >>>> Fair enough. Cleared this one. >>> >>> Cool. >>> >>>> >>>> >>>> >>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> The HOBA-TBS construction seems really unnecessarily complicated. >>> Other >>>>>>> than in the "origin" component, there are no ":" characters allowed in >>>>>>> any of the components, so if you could remove the unnecessarily pretty >>>>>>> serialization of the origin, you could just use ':' as a delimiter. >>> Or >>>>>>> leave the origin, and delimit with something like %x20. Either way, >>>>> this >>>>>>> length construction seems like a pain to implement by comparison. >>>>>> >>>>>> We started with a less complex construction, and the WG specifically >>>>> asked for this. >>>>>> >>>>>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point >>>>> spaces >>>>>>> unnecessarily. >>>>>> >>>>>> It is also unwise to have more than 99 possible algorithms for signing. >>>>> >>>> >>>> Sure, but that seems like a process issue, not one to enshrine in syntax. >>> >>> The opposite I think. We seem unable to fix the vanity/national crypto >>> thing via process so I'd like to see us try via syntax myself. But >>> that's for another day:-) >>> >>> Cheers, >>> S. >>> >>>> >>>> >>>> >>>>>>> In addition to the funny title of Section 6.2.2, the contents seem >>> kind >>>>>>> of risible as well. Making a OTP is 100% equivalent to the mechanism >>>>>>> recommended in Section 6.2.3, and arguably more likely to deploy >>> (since >>>>>>> the OTP doesn't have special semantics of being a URI). >>>>>> >>>>>> There is wide disagreement on what is more likely to deploy. Also, I'm >>>>> pretty sure Stephen is correct about your view on OTP here. >>>>>> >>>>>>> Please update the algorithms so that the reader doesn't have to go >>> look >>>>>>> up which algorithm this is (PKCS1 vs. PSS). >>>>>>> >>>>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" >>>>>>> >>>>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of >>>>>>> [RFC3447]" >>>>>> >>>>>> Sounds good; now fixed in the post-IESG version. >>>>>> >>>>>>> Given how convoluted the use case is here, an example would be very >>>>>>> helpful. At the very least to demonstrate the syntax of the >>>>>>> WWW-Authenticate header. >>>>>> >>>>>> This doesn't seem all that needed, regardless of your view of >>>>> convolution. >>>>>> >>>>>> --Paul Hoffman >>>>>> _______________________________________________ >>>>>> http-auth mailing list >>>>>> http-auth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/http-auth >>>>>> >>>>> >>>> >>> >> >> >> On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell >> wrote: >> >>> >>> Hiya, >>> >>> On 08/01/15 10:23, Richard Barnes wrote: >>>> Hey guys, >>>> >>>> Thanks for responding productively to a DISCUSS that I admit was not >>>> written very politely. Sorry about that. >>> >>> I do it myself from time to time, no probs. (And to be honest I >>> was more rude about your ballot in IM to someone else, so we're >>> even:-) >>> >>>> >>>> Couple of comments inline. >>>> >>>> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell < >>> stephen.farrell@cs.tcd.ie> >>>> wrote: >>>> >>>>> >>>>> FWIW, I'm fine that Paul's recollection of the WG stuff is better >>>>> than mine and with his putting the pkcs#1 stuff in too. >>>>> >>>>> S >>>>> >>>>> On 08/01/15 01:19, Paul Hoffman wrote: >>>>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: >>>>>>> (1) It does not seem to me that the mechanism defined in this document >>>>>>> actually conforms to the framework for HTTP authentication. The >>> general >>>>>>> framework defined in RFC 7235 is all scoped to a resource -- you can >>>>>>> implement authorization for a specific resource, without impacting >>>>>>> anything else on the server. HOBA, by contrast, requires the >>>>>>> authenticating resource to be also be correlated to several resource >>>>>>> under .well-known, meaning that it will not be usable in a large >>> number >>>>>>> of deployment circumstances. Was this issue discussed in the WG, and >>>>> was >>>>>>> there input from the broader HTTP community? >>>>>> >>>>>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating >>>>> resource" in HOBA is purposely more expressive than that in RFC 7235, >>> and >>>>> thus takes more primitives than HTTP auth. There was plenty of WG >>>>> discussion around this. >>>>> >>>> >>>> If you happen to have a pointer to that discussion, it would help me feel >>>> more comfortable. >>>> >>>> To be a little clearer about my concern, it seems like the fact that you >>>> don't carry the public key in the Authorization header means that the >>>> authenticating resource has to be tied to the .well-known/hoba/register/ >>>> resource. >>> >>> Yes, that's true. But entirely acceptable as a reasonable >>> limitation of the scheme. It's reasonable because a) less >>> header bloat if you send public key once, b) with RSA in >>> particular public keys are big, and c) I hold out the hope >>> that I can someday develop a privacy friendly kid type so >>> that the strongly identifying nature of the HOBA signature >>> is addressed. (I have not so far figured one out, sadly.) >>> >>> So I still don't see a reason for this to block the experiment. >>> >>>> >>>> >>>> >>>>>>> (2) What is your justification for using a SHA-1 based signature in a >>>>> new >>>>>>> protocol, when it is being actively deprecated elsewhere, in >>> particular >>>>>>> the web PKI? >>>>>> >>>>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a >>>>> MAY-level definition when there is a more popular algorithm >>> (RSA-SHA256) at >>>>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no >>> danger >>>>> to having it here. >>>>> >>>> >>>> But if you're REQUIRED to support RSA-SHA256, why would you ever use >>>> RSA-SHA1? >>>> >>>> Color me pretty skeptical that there are implementations that can't >>> support >>>> SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto >>>> libary that fits within 64K and supports SHA-256 along with a bunch of >>>> other algorithms. >>> >>> That was the case with PHP when this work started and at that time I >>> needed the rsa-sha1 code point for my code. That was only a year or >>> two ago. I bet there are still web sites with only that version of >>> PHP available today - that is scary but adding HOBA to such could >>> still represent a security improvement if it meant that a new >>> application can be deployed without a new password verifier DB, and >>> that would be the case since we have the rsa-sha1 codepoint. Taking >>> away the codepoint would prevent such being deployed. And we know >>> for sure that the relevant risk here is not the signature crypto >>> but is overwhelmingly and utterly the password verifier DB. You are >>> I fear arguing that we ought prioritise crypto plumbing over the >>> real security risk. >>> >>> I have not done a survey of all web development platforms to check >>> if this is now a solved issue or not. You skepticism is fine (and >>> perhaps correct) but if you don't do that survey, then blocking on >>> that basis is not correct. >>> >>>>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> >>> MUST >>>>>> >>>>>> There is no interoperability mandate for particular RSA key lengths, so >>>>> "SHOULD" is more appropriate here (until the IESG finally gets around to >>>>> updating RFC 2119...). >>>>> >>>> >>>> This is not about interop, it's about achieving an appropriate security >>>> level. That is another thing for which MUSTs are commonly used. >>>> >>>> (If we're going to talk about 2119, the phrasing is "absolute requirement >>>> of the specification", not "absolutely required for interop".) >>>> >>>> To Stephen's point on JS performance: I made a little empirical test: >>>> http://www.ipv.sx/tmp/rsa-2048.html >>>> >>>> On a good laptop, a good phone, and a crappier phone, the time to >>> generate >>>> a 2048-bit key is roughly (choosing representative values after a few >>>> clicks): >>>> MacBook Pro: 5340ms >>>> iPhone 6: 7192ms >>>> FirefoxOS Flame: 31084ms >>> >>> I've seen it take >120s which is not usable in this context. That >>> was on older iphones (4 I think) with various browsers. With some >>> older versions of IE on older laptops it's also horrendous. >>> >>>> These values are not great, but they're within the range of asynchronous >>>> operations that web pages already have to deal with, especially given >>> that >>>> keygen is a once-per-origin operation. As far as sign() operations, the >>>> worst case among these devices was ~500ms, which is again not terrible. >>> >>> Signing is tolerable in most cases thanks to the getchal and using >>> a worker. >>> >>> And the appropriate security level for HOBA is not the usual thing >>> actually. Here we're after "substantially better than passwords" >>> and will likely transition to a cookie (bearer token) just after >>> signing. So I would argue that even an otherwise-undesirable 1500 >>> bit modulus could be ok here, if a site has a way to bump that up >>> later, e.g. as new browsers deploy webcrypto. However, that is not >>> stuff that needs or ought be in the RFC. >>> >>> For an experimental RFC we should not block on this. (I would myself >>> for a stds track but not exp.) >>> >>>>>>> (4) Given that the size of the header seems to be a concern (since >>>>> you're >>>>>>> not passing the key in the header), why are there no ECC signing >>>>>>> algorithms defined? It seems like if you used any of the normal >>> curves, >>>>>>> you could comfortably pass the key along with the authentication >>> value. >>>>>> >>>>>> Because there is not yet agreement on which ECC signing algorithms are >>>>> likely to be popular in a year or two. We're watching the CFRG >>> discussion, >>>>> and it is not yet coming to consensus. When it does, this Experimental >>> RFC >>>>> can be updated. >>>>> >>>> >>>> This is pretty weak sauce. It's not like ECDSA with P-256 is going to go >>>> away overnight when CFRG make up their minds. >>> >>> The development platform issue that perhaps no longer exists for >>> sha256 is I believe still real for ecdsa. >>> >>> But the main thing I'd like from the CFRG work would be to lose the >>> RNG requirement at signing time, which is unnecessarily a part of >>> ECDSA. That's a real security win, if we get it. >>> >>>> Maybe I'm overly worried about the complexity here, but it seems like >>> using >>>> ECC could allow you to just shove the public key in the Authorization >>>> header. That would obviate the need for the registration resource, >>>> resolving point 1 above, and generally make HOBA easier to implement. >>>> >>>> Nonetheless, I moved this point to a COMMENT. >>>> >>>> >>>>>> (5) For that matter, why bother defining a new algorithm registry at >>> all, >>>>>>> when JWA provides a perfectly nice one that only costs you 4 >>> characters. >>>>>> >>>>>> We did not want to be tied to the JWA registry, given that JOSE could >>> go >>>>> in quite different directions. >>>>> >>>> >>>> Fair enough. Cleared this one. >>> >>> Cool. >>> >>>> >>>> >>>> >>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> The HOBA-TBS construction seems really unnecessarily complicated. >>> Other >>>>>>> than in the "origin" component, there are no ":" characters allowed in >>>>>>> any of the components, so if you could remove the unnecessarily pretty >>>>>>> serialization of the origin, you could just use ':' as a delimiter. >>> Or >>>>>>> leave the origin, and delimit with something like %x20. Either way, >>>>> this >>>>>>> length construction seems like a pain to implement by comparison. >>>>>> >>>>>> We started with a less complex construction, and the WG specifically >>>>> asked for this. >>>>>> >>>>>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point >>>>> spaces >>>>>>> unnecessarily. >>>>>> >>>>>> It is also unwise to have more than 99 possible algorithms for signing. >>>>> >>>> >>>> Sure, but that seems like a process issue, not one to enshrine in syntax. >>> >>> The opposite I think. We seem unable to fix the vanity/national crypto >>> thing via process so I'd like to see us try via syntax myself. But >>> that's for another day:-) >>> >>> Cheers, >>> S. >>> >>>> >>>> >>>> >>>>>>> In addition to the funny title of Section 6.2.2, the contents seem >>> kind >>>>>>> of risible as well. Making a OTP is 100% equivalent to the mechanism >>>>>>> recommended in Section 6.2.3, and arguably more likely to deploy >>> (since >>>>>>> the OTP doesn't have special semantics of being a URI). >>>>>> >>>>>> There is wide disagreement on what is more likely to deploy. Also, I'm >>>>> pretty sure Stephen is correct about your view on OTP here. >>>>>> >>>>>>> Please update the algorithms so that the reader doesn't have to go >>> look >>>>>>> up which algorithm this is (PKCS1 vs. PSS). >>>>>>> >>>>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" >>>>>>> >>>>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of >>>>>>> [RFC3447]" >>>>>> >>>>>> Sounds good; now fixed in the post-IESG version. >>>>>> >>>>>>> Given how convoluted the use case is here, an example would be very >>>>>>> helpful. At the very least to demonstrate the syntax of the >>>>>>> WWW-Authenticate header. >>>>>> >>>>>> This doesn't seem all that needed, regardless of your view of >>>>> convolution. >>>>>> >>>>>> --Paul Hoffman >>>>>> _______________________________________________ >>>>>> http-auth mailing list >>>>>> http-auth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/http-auth >>>>>> >>>>> >>>> >>> >> -- Best regards, Kathleen From nobody Thu Jan 8 06:15:47 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD8C1A0231; Thu, 8 Jan 2015 06:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNnSef_eLXHq; Thu, 8 Jan 2015 06:15:41 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB0A1A00C6; Thu, 8 Jan 2015 06:15:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6AC45BEB2; Thu, 8 Jan 2015 14:15:37 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAyJvH8x56mL; Thu, 8 Jan 2015 14:15:36 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 59610BE5D; Thu, 8 Jan 2015 14:15:36 +0000 (GMT) Message-ID: <54AE9107.1050901@cs.tcd.ie> Date: Thu, 08 Jan 2015 14:15:35 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADDC98.4000009@cs.tcd.ie> <54AE6DF2.80500@cs.tcd.ie> <54AE7AA0.2000100@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "httpauth-chairs@tools.ietf.org" , Richard Barnes , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , Paul Hoffman , "http-auth@ietf.org" , The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:15:45 -0000 On 08/01/15 14:11, Kathleen Moriarty wrote: > I'm not sure why someone would want to > use a development platform that is really out-of-date though. Some web developers get no choice. They don't control the web server, just their chunks of PHP code. S. From nobody Thu Jan 8 06:17:12 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E9A1A00C2; Thu, 8 Jan 2015 06:17:11 -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 8wjW5LDhGKdN; Thu, 8 Jan 2015 06:17:10 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AE31A0012; Thu, 8 Jan 2015 06:17:09 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id u10so3042151lbd.13; Thu, 08 Jan 2015 06:17:08 -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=K1UFiuJHotiklud9C+zaZy6oeqSvPWlCm2L5qGA3jeI=; b=UK+tBDRTbgcWJMcMMqTQwQ9lnez5tMnBLKQUvYGI6oPDKkHe/N25ndm5xM4Ntts7a5 lbEzkpfaHJ+7r7No8tQqdWeQLWM2TJnEa8pvjoGkgJmbBL/SQME8SGtpGFg84dZ+nw4U RwgNr900r+rOM3ejO0TBDO35nc6mglfbqertAIKyElFUw2Eg33MB0XDw+CIXk8miTwSN /TJ7+I6v0AdQE1dA5ivXspHhHGDimcN2BSnZdBunYaPGLRU6ypb08r68wDdf4JgvLZQd PMURyRr1pqesYvOFWnBDAeRNAIn3JjJdtbksW01jLb1ngkgP6FlqhWUBtpX02+snR6fM MNAg== MIME-Version: 1.0 X-Received: by 10.152.20.98 with SMTP id m2mr14082348lae.49.1420726628109; Thu, 08 Jan 2015 06:17:08 -0800 (PST) Received: by 10.112.49.52 with HTTP; Thu, 8 Jan 2015 06:17:08 -0800 (PST) In-Reply-To: <54AE9107.1050901@cs.tcd.ie> References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADDC98.4000009@cs.tcd.ie> <54AE6DF2.80500@cs.tcd.ie> <54AE7AA0.2000100@cs.tcd.ie> <54AE9107.1050901@cs.tcd.ie> Date: Thu, 8 Jan 2015 09:17:08 -0500 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "httpauth-chairs@tools.ietf.org" , Richard Barnes , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , Paul Hoffman , "http-auth@ietf.org" , The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:17:11 -0000 On Thu, Jan 8, 2015 at 9:15 AM, Stephen Farrell wrote: > > > On 08/01/15 14:11, Kathleen Moriarty wrote: >> I'm not sure why someone would want to >> use a development platform that is really out-of-date though. > > Some web developers get no choice. They don't control the > web server, just their chunks of PHP code. > > S. Sure, I get that, just don't think we should encourage it when we are trying to deprecate old stuff. Thanks, Kathleen -- Best regards, Kathleen From nobody Thu Jan 8 08:02:29 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB861A87E3; Thu, 8 Jan 2015 08:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1r7shuX7Q_8; Thu, 8 Jan 2015 08:02:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7B41A8702; Thu, 8 Jan 2015 08:01:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1E69BBED1; Thu, 8 Jan 2015 16:01:57 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98UFRUFbjxGt; Thu, 8 Jan 2015 16:01:54 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 96ACABE87; Thu, 8 Jan 2015 16:01:53 +0000 (GMT) Message-ID: <54AEA9F1.609@cs.tcd.ie> Date: Thu, 08 Jan 2015 16:01:53 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Richard Barnes References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADDC98.4000009@cs.tcd.ie> <54AE6DF2.80500@cs.tcd.ie> <54AE7AA0.2000100@cs.tcd.ie> In-Reply-To: <54AE7AA0.2000100@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, Paul Hoffman , The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:02:16 -0000 On 08/01/15 12:40, Stephen Farrell wrote: > > (Richard and I plan to chat via IM before the call hopefully > so this is more to tee that up than to clear right now.) So we did that. There're a few more tweaks in [1,2] and Richard has cleared (thanks Richard). If folks could check I didn't mess up with edits, that'd be good, Ta, S. > > There are a couple of changes below, those are done in the > working version at the usual [1,2]. > > [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > [2] > https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt > > On 08/01/15 12:06, Richard Barnes wrote: >> On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell >> wrote: >> >>> >>> Hiya, >>> >>> On 08/01/15 10:23, Richard Barnes wrote: >>>> Hey guys, >>>> >>>> Thanks for responding productively to a DISCUSS that I admit was not >>>> written very politely. Sorry about that. >>> >>> I do it myself from time to time, no probs. (And to be honest I >>> was more rude about your ballot in IM to someone else, so we're >>> even:-) >>> >>>> >>>> Couple of comments inline. >>>> >>>> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell < >>> stephen.farrell@cs.tcd.ie> >>>> wrote: >>>> >>>>> >>>>> FWIW, I'm fine that Paul's recollection of the WG stuff is better >>>>> than mine and with his putting the pkcs#1 stuff in too. >>>>> >>>>> S >>>>> >>>>> On 08/01/15 01:19, Paul Hoffman wrote: >>>>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: >>>>>>> (1) It does not seem to me that the mechanism defined in this document >>>>>>> actually conforms to the framework for HTTP authentication. The >>> general >>>>>>> framework defined in RFC 7235 is all scoped to a resource -- you can >>>>>>> implement authorization for a specific resource, without impacting >>>>>>> anything else on the server. HOBA, by contrast, requires the >>>>>>> authenticating resource to be also be correlated to several resource >>>>>>> under .well-known, meaning that it will not be usable in a large >>> number >>>>>>> of deployment circumstances. Was this issue discussed in the WG, and >>>>> was >>>>>>> there input from the broader HTTP community? >>>>>> >>>>>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating >>>>> resource" in HOBA is purposely more expressive than that in RFC 7235, >>> and >>>>> thus takes more primitives than HTTP auth. There was plenty of WG >>>>> discussion around this. >>>>> >>>> >>>> If you happen to have a pointer to that discussion, it would help me feel >>>> more comfortable. >>>> >>>> To be a little clearer about my concern, it seems like the fact that you >>>> don't carry the public key in the Authorization header means that the >>>> authenticating resource has to be tied to the .well-known/hoba/register/ >>>> resource. >>> >>> Yes, that's true. But entirely acceptable as a reasonable >>> limitation of the scheme. It's reasonable because a) less >>> header bloat if you send public key once, b) with RSA in >>> particular public keys are big, and c) I hold out the hope >>> that I can someday develop a privacy friendly kid type so >>> that the strongly identifying nature of the HOBA signature >>> is addressed. (I have not so far figured one out, sadly.) >>> >>> So I still don't see a reason for this to block the experiment. >>> >>>> >>>> >>>> >>>>>>> (2) What is your justification for using a SHA-1 based signature in a >>>>> new >>>>>>> protocol, when it is being actively deprecated elsewhere, in >>> particular >>>>>>> the web PKI? >>>>>> >>>>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a >>>>> MAY-level definition when there is a more popular algorithm >>> (RSA-SHA256) at >>>>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no >>> danger >>>>> to having it here. >>>>> >>>> >>>> But if you're REQUIRED to support RSA-SHA256, why would you ever use >>>> RSA-SHA1? >>>> >>>> Color me pretty skeptical that there are implementations that can't >>> support >>>> SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto >>>> libary that fits within 64K and supports SHA-256 along with a bunch of >>>> other algorithms. >>> >>> That was the case with PHP when this work started and at that time I >>> needed the rsa-sha1 code point for my code. That was only a year or >>> two ago. I bet there are still web sites with only that version of >>> PHP available today - that is scary but adding HOBA to such could >>> still represent a security improvement if it meant that a new >>> application can be deployed without a new password verifier DB, and >>> that would be the case since we have the rsa-sha1 codepoint. Taking >>> away the codepoint would prevent such being deployed. And we know >>> for sure that the relevant risk here is not the signature crypto >>> but is overwhelmingly and utterly the password verifier DB. You are >>> I fear arguing that we ought prioritise crypto plumbing over the >>> real security risk. >>> >>> I have not done a survey of all web development platforms to check >>> if this is now a solved issue or not. You skepticism is fine (and >>> perhaps correct) but if you don't do that survey, then blocking on >>> that basis is not correct. >>> >> >> Isn't the burden on the one trying to weaken the protocol? :) >> >> All of the web development platforms I can think of have SHA-2 support. >> Looking at the list on wikipedia: >> http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites >> >> ASP.NET, C, C++, Java, JavaScript, Perl, Python, Ruby: Should be obvious >> PHP, Xhp, Hack: http://php.net/manual/en/function.hash.php >> Scala: https://github.com/Nycto/Hasher >> Go: http://golang.org/pkg/crypto/sha256/ >> Erlang: http://erlang.org/doc/man/crypto.html >> D: http://dlang.org/phobos/std_digest_sha.html >> >> So unless you can come up with a platform that *doesn't* support SHA-2, I >> don't see why it should be allowed. >> >> In any event, it seems like this whole pageant is moot, since the document >> *requires* SHA-2 support. If you've got that, why would you ever do >> SHA-1? > > Because e.g. PHP4 is still installed on a site where I don't > get to fix that. Shodanhq indicates there are a number of those > still about, though less than I'd have expected, but not sure > if they search for that deliberately or as a side-effect. > > But anyway, I have no problem saying rsa-sha1 MUST NOT be used > except in cases like that where you have no choice. > > Given that the codepoint was in the draft for quite a while, > it seems silly (process-wonkery?:-) to take it out now and > then maybe re-use it for something else later, so I'd argue > we can leave the code point. > > So I added: > > "RSA-SHA1 MUST > NOT be used, except in cases where SHA256 is unavailable, say > if some developmemt platform has to be used that is quite out > of date." > > Happy to wordsmith that. > > >> >> >> >>>>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> >>> MUST >>>>>> >>>>>> There is no interoperability mandate for particular RSA key lengths, so >>>>> "SHOULD" is more appropriate here (until the IESG finally gets around to >>>>> updating RFC 2119...). >>>>> >>>> >>>> This is not about interop, it's about achieving an appropriate security >>>> level. That is another thing for which MUSTs are commonly used. >>>> >>>> (If we're going to talk about 2119, the phrasing is "absolute requirement >>>> of the specification", not "absolutely required for interop".) >>>> >>>> To Stephen's point on JS performance: I made a little empirical test: >>>> http://www.ipv.sx/tmp/rsa-2048.html >>>> >>>> On a good laptop, a good phone, and a crappier phone, the time to >>> generate >>>> a 2048-bit key is roughly (choosing representative values after a few >>>> clicks): >>>> MacBook Pro: 5340ms >>>> iPhone 6: 7192ms >>>> FirefoxOS Flame: 31084ms >>> >>> I've seen it take >120s which is not usable in this context. That >>> was on older iphones (4 I think) with various browsers. With some >>> older versions of IE on older laptops it's also horrendous. >>> >>>> These values are not great, but they're within the range of asynchronous >>>> operations that web pages already have to deal with, especially given >>> that >>>> keygen is a once-per-origin operation. As far as sign() operations, the >>>> worst case among these devices was ~500ms, which is again not terrible. >>> >>> Signing is tolerable in most cases thanks to the getchal and using >>> a worker. >>> >>> And the appropriate security level for HOBA is not the usual thing >>> actually. Here we're after "substantially better than passwords" >>> and will likely transition to a cookie (bearer token) just after >>> signing. So I would argue that even an otherwise-undesirable 1500 >>> bit modulus could be ok here, if a site has a way to bump that up >>> later, e.g. as new browsers deploy webcrypto. However, that is not >>> stuff that needs or ought be in the RFC. >>> >>> For an experimental RFC we should not block on this. (I would myself >>> for a stds track but not exp.) >>> >> >> Yeah, OK. I guess I can live with this. Could we possibly add some >> bounding text, e.g., >> >> "Keys shorter than 2048 bits should only be used in cases where generating >> 2048-bit (or longer) keys is impractical, e.g., on constrained devices. If >> an application uses short keys, then it MUST expire and re-generate keys >> periodically, say every few weeks." > > I've added the first sentence. I don't think the 2nd is wise > really but will explain in IM as its a bit convoluted. (And > of course, HOBA itself has no concept of expiry at all, that's > for the account handling code.) > > Cheers, > S. > >> >> >> >> >>>>>>> (4) Given that the size of the header seems to be a concern (since >>>>> you're >>>>>>> not passing the key in the header), why are there no ECC signing >>>>>>> algorithms defined? It seems like if you used any of the normal >>> curves, >>>>>>> you could comfortably pass the key along with the authentication >>> value. >>>>>> >>>>>> Because there is not yet agreement on which ECC signing algorithms are >>>>> likely to be popular in a year or two. We're watching the CFRG >>> discussion, >>>>> and it is not yet coming to consensus. When it does, this Experimental >>> RFC >>>>> can be updated. >>>>> >>>> >>>> This is pretty weak sauce. It's not like ECDSA with P-256 is going to go >>>> away overnight when CFRG make up their minds. >>> >>> The development platform issue that perhaps no longer exists for >>> sha256 is I believe still real for ecdsa. >>> >>> But the main thing I'd like from the CFRG work would be to lose the >>> RNG requirement at signing time, which is unnecessarily a part of >>> ECDSA. That's a real security win, if we get it. >>> >>>> Maybe I'm overly worried about the complexity here, but it seems like >>> using >>>> ECC could allow you to just shove the public key in the Authorization >>>> header. That would obviate the need for the registration resource, >>>> resolving point 1 above, and generally make HOBA easier to implement. >>>> >>>> Nonetheless, I moved this point to a COMMENT. >>>> >>>> >>>>>> (5) For that matter, why bother defining a new algorithm registry at >>> all, >>>>>>> when JWA provides a perfectly nice one that only costs you 4 >>> characters. >>>>>> >>>>>> We did not want to be tied to the JWA registry, given that JOSE could >>> go >>>>> in quite different directions. >>>>> >>>> >>>> Fair enough. Cleared this one. >>> >>> Cool. >>> >>>> >>>> >>>> >>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> The HOBA-TBS construction seems really unnecessarily complicated. >>> Other >>>>>>> than in the "origin" component, there are no ":" characters allowed in >>>>>>> any of the components, so if you could remove the unnecessarily pretty >>>>>>> serialization of the origin, you could just use ':' as a delimiter. >>> Or >>>>>>> leave the origin, and delimit with something like %x20. Either way, >>>>> this >>>>>>> length construction seems like a pain to implement by comparison. >>>>>> >>>>>> We started with a less complex construction, and the WG specifically >>>>> asked for this. >>>>>> >>>>>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point >>>>> spaces >>>>>>> unnecessarily. >>>>>> >>>>>> It is also unwise to have more than 99 possible algorithms for signing. >>>>> >>>> >>>> Sure, but that seems like a process issue, not one to enshrine in syntax. >>> >>> The opposite I think. We seem unable to fix the vanity/national crypto >>> thing via process so I'd like to see us try via syntax myself. But >>> that's for another day:-) >>> >>> Cheers, >>> S. >>> >>>> >>>> >>>> >>>>>>> In addition to the funny title of Section 6.2.2, the contents seem >>> kind >>>>>>> of risible as well. Making a OTP is 100% equivalent to the mechanism >>>>>>> recommended in Section 6.2.3, and arguably more likely to deploy >>> (since >>>>>>> the OTP doesn't have special semantics of being a URI). >>>>>> >>>>>> There is wide disagreement on what is more likely to deploy. Also, I'm >>>>> pretty sure Stephen is correct about your view on OTP here. >>>>>> >>>>>>> Please update the algorithms so that the reader doesn't have to go >>> look >>>>>>> up which algorithm this is (PKCS1 vs. PSS). >>>>>>> >>>>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" >>>>>>> >>>>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of >>>>>>> [RFC3447]" >>>>>> >>>>>> Sounds good; now fixed in the post-IESG version. >>>>>> >>>>>>> Given how convoluted the use case is here, an example would be very >>>>>>> helpful. At the very least to demonstrate the syntax of the >>>>>>> WWW-Authenticate header. >>>>>> >>>>>> This doesn't seem all that needed, regardless of your view of >>>>> convolution. >>>>>> >>>>>> --Paul Hoffman >>>>>> _______________________________________________ >>>>>> http-auth mailing list >>>>>> http-auth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/http-auth >>>>>> >>>>> >>>> >>> >> >> >> On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell >> wrote: >> >>> >>> Hiya, >>> >>> On 08/01/15 10:23, Richard Barnes wrote: >>>> Hey guys, >>>> >>>> Thanks for responding productively to a DISCUSS that I admit was not >>>> written very politely. Sorry about that. >>> >>> I do it myself from time to time, no probs. (And to be honest I >>> was more rude about your ballot in IM to someone else, so we're >>> even:-) >>> >>>> >>>> Couple of comments inline. >>>> >>>> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell < >>> stephen.farrell@cs.tcd.ie> >>>> wrote: >>>> >>>>> >>>>> FWIW, I'm fine that Paul's recollection of the WG stuff is better >>>>> than mine and with his putting the pkcs#1 stuff in too. >>>>> >>>>> S >>>>> >>>>> On 08/01/15 01:19, Paul Hoffman wrote: >>>>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes wrote: >>>>>>> (1) It does not seem to me that the mechanism defined in this document >>>>>>> actually conforms to the framework for HTTP authentication. The >>> general >>>>>>> framework defined in RFC 7235 is all scoped to a resource -- you can >>>>>>> implement authorization for a specific resource, without impacting >>>>>>> anything else on the server. HOBA, by contrast, requires the >>>>>>> authenticating resource to be also be correlated to several resource >>>>>>> under .well-known, meaning that it will not be usable in a large >>> number >>>>>>> of deployment circumstances. Was this issue discussed in the WG, and >>>>> was >>>>>>> there input from the broader HTTP community? >>>>>> >>>>>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating >>>>> resource" in HOBA is purposely more expressive than that in RFC 7235, >>> and >>>>> thus takes more primitives than HTTP auth. There was plenty of WG >>>>> discussion around this. >>>>> >>>> >>>> If you happen to have a pointer to that discussion, it would help me feel >>>> more comfortable. >>>> >>>> To be a little clearer about my concern, it seems like the fact that you >>>> don't carry the public key in the Authorization header means that the >>>> authenticating resource has to be tied to the .well-known/hoba/register/ >>>> resource. >>> >>> Yes, that's true. But entirely acceptable as a reasonable >>> limitation of the scheme. It's reasonable because a) less >>> header bloat if you send public key once, b) with RSA in >>> particular public keys are big, and c) I hold out the hope >>> that I can someday develop a privacy friendly kid type so >>> that the strongly identifying nature of the HOBA signature >>> is addressed. (I have not so far figured one out, sadly.) >>> >>> So I still don't see a reason for this to block the experiment. >>> >>>> >>>> >>>> >>>>>>> (2) What is your justification for using a SHA-1 based signature in a >>>>> new >>>>>>> protocol, when it is being actively deprecated elsewhere, in >>> particular >>>>>>> the web PKI? >>>>>> >>>>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a >>>>> MAY-level definition when there is a more popular algorithm >>> (RSA-SHA256) at >>>>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no >>> danger >>>>> to having it here. >>>>> >>>> >>>> But if you're REQUIRED to support RSA-SHA256, why would you ever use >>>> RSA-SHA1? >>>> >>>> Color me pretty skeptical that there are implementations that can't >>> support >>>> SHA-2 nowadays. I just saw a presentation yesterday about an IoT crypto >>>> libary that fits within 64K and supports SHA-256 along with a bunch of >>>> other algorithms. >>> >>> That was the case with PHP when this work started and at that time I >>> needed the rsa-sha1 code point for my code. That was only a year or >>> two ago. I bet there are still web sites with only that version of >>> PHP available today - that is scary but adding HOBA to such could >>> still represent a security improvement if it meant that a new >>> application can be deployed without a new password verifier DB, and >>> that would be the case since we have the rsa-sha1 codepoint. Taking >>> away the codepoint would prevent such being deployed. And we know >>> for sure that the relevant risk here is not the signature crypto >>> but is overwhelmingly and utterly the password verifier DB. You are >>> I fear arguing that we ought prioritise crypto plumbing over the >>> real security risk. >>> >>> I have not done a survey of all web development platforms to check >>> if this is now a solved issue or not. You skepticism is fine (and >>> perhaps correct) but if you don't do that survey, then blocking on >>> that basis is not correct. >>> >>>>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> >>> MUST >>>>>> >>>>>> There is no interoperability mandate for particular RSA key lengths, so >>>>> "SHOULD" is more appropriate here (until the IESG finally gets around to >>>>> updating RFC 2119...). >>>>> >>>> >>>> This is not about interop, it's about achieving an appropriate security >>>> level. That is another thing for which MUSTs are commonly used. >>>> >>>> (If we're going to talk about 2119, the phrasing is "absolute requirement >>>> of the specification", not "absolutely required for interop".) >>>> >>>> To Stephen's point on JS performance: I made a little empirical test: >>>> http://www.ipv.sx/tmp/rsa-2048.html >>>> >>>> On a good laptop, a good phone, and a crappier phone, the time to >>> generate >>>> a 2048-bit key is roughly (choosing representative values after a few >>>> clicks): >>>> MacBook Pro: 5340ms >>>> iPhone 6: 7192ms >>>> FirefoxOS Flame: 31084ms >>> >>> I've seen it take >120s which is not usable in this context. That >>> was on older iphones (4 I think) with various browsers. With some >>> older versions of IE on older laptops it's also horrendous. >>> >>>> These values are not great, but they're within the range of asynchronous >>>> operations that web pages already have to deal with, especially given >>> that >>>> keygen is a once-per-origin operation. As far as sign() operations, the >>>> worst case among these devices was ~500ms, which is again not terrible. >>> >>> Signing is tolerable in most cases thanks to the getchal and using >>> a worker. >>> >>> And the appropriate security level for HOBA is not the usual thing >>> actually. Here we're after "substantially better than passwords" >>> and will likely transition to a cookie (bearer token) just after >>> signing. So I would argue that even an otherwise-undesirable 1500 >>> bit modulus could be ok here, if a site has a way to bump that up >>> later, e.g. as new browsers deploy webcrypto. However, that is not >>> stuff that needs or ought be in the RFC. >>> >>> For an experimental RFC we should not block on this. (I would myself >>> for a stds track but not exp.) >>> >>>>>>> (4) Given that the size of the header seems to be a concern (since >>>>> you're >>>>>>> not passing the key in the header), why are there no ECC signing >>>>>>> algorithms defined? It seems like if you used any of the normal >>> curves, >>>>>>> you could comfortably pass the key along with the authentication >>> value. >>>>>> >>>>>> Because there is not yet agreement on which ECC signing algorithms are >>>>> likely to be popular in a year or two. We're watching the CFRG >>> discussion, >>>>> and it is not yet coming to consensus. When it does, this Experimental >>> RFC >>>>> can be updated. >>>>> >>>> >>>> This is pretty weak sauce. It's not like ECDSA with P-256 is going to go >>>> away overnight when CFRG make up their minds. >>> >>> The development platform issue that perhaps no longer exists for >>> sha256 is I believe still real for ecdsa. >>> >>> But the main thing I'd like from the CFRG work would be to lose the >>> RNG requirement at signing time, which is unnecessarily a part of >>> ECDSA. That's a real security win, if we get it. >>> >>>> Maybe I'm overly worried about the complexity here, but it seems like >>> using >>>> ECC could allow you to just shove the public key in the Authorization >>>> header. That would obviate the need for the registration resource, >>>> resolving point 1 above, and generally make HOBA easier to implement. >>>> >>>> Nonetheless, I moved this point to a COMMENT. >>>> >>>> >>>>>> (5) For that matter, why bother defining a new algorithm registry at >>> all, >>>>>>> when JWA provides a perfectly nice one that only costs you 4 >>> characters. >>>>>> >>>>>> We did not want to be tied to the JWA registry, given that JOSE could >>> go >>>>> in quite different directions. >>>>> >>>> >>>> Fair enough. Cleared this one. >>> >>> Cool. >>> >>>> >>>> >>>> >>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> The HOBA-TBS construction seems really unnecessarily complicated. >>> Other >>>>>>> than in the "origin" component, there are no ":" characters allowed in >>>>>>> any of the components, so if you could remove the unnecessarily pretty >>>>>>> serialization of the origin, you could just use ':' as a delimiter. >>> Or >>>>>>> leave the origin, and delimit with something like %x20. Either way, >>>>> this >>>>>>> length construction seems like a pain to implement by comparison. >>>>>> >>>>>> We started with a less complex construction, and the WG specifically >>>>> asked for this. >>>>>> >>>>>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point >>>>> spaces >>>>>>> unnecessarily. >>>>>> >>>>>> It is also unwise to have more than 99 possible algorithms for signing. >>>>> >>>> >>>> Sure, but that seems like a process issue, not one to enshrine in syntax. >>> >>> The opposite I think. We seem unable to fix the vanity/national crypto >>> thing via process so I'd like to see us try via syntax myself. But >>> that's for another day:-) >>> >>> Cheers, >>> S. >>> >>>> >>>> >>>> >>>>>>> In addition to the funny title of Section 6.2.2, the contents seem >>> kind >>>>>>> of risible as well. Making a OTP is 100% equivalent to the mechanism >>>>>>> recommended in Section 6.2.3, and arguably more likely to deploy >>> (since >>>>>>> the OTP doesn't have special semantics of being a URI). >>>>>> >>>>>> There is wide disagreement on what is more likely to deploy. Also, I'm >>>>> pretty sure Stephen is correct about your view on OTP here. >>>>>> >>>>>>> Please update the algorithms so that the reader doesn't have to go >>> look >>>>>>> up which algorithm this is (PKCS1 vs. PSS). >>>>>>> >>>>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" >>>>>>> >>>>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of >>>>>>> [RFC3447]" >>>>>> >>>>>> Sounds good; now fixed in the post-IESG version. >>>>>> >>>>>>> Given how convoluted the use case is here, an example would be very >>>>>>> helpful. At the very least to demonstrate the syntax of the >>>>>>> WWW-Authenticate header. >>>>>> >>>>>> This doesn't seem all that needed, regardless of your view of >>>>> convolution. >>>>>> >>>>>> --Paul Hoffman >>>>>> _______________________________________________ >>>>>> http-auth mailing list >>>>>> http-auth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/http-auth >>>>>> >>>>> >>>> >>> >> > From nobody Thu Jan 8 10:05:35 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE4F1A8AE2 for ; Thu, 8 Jan 2015 10:05: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 Gu9djrt4VbZ6; Thu, 8 Jan 2015 10:05:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FB11A8F35; Thu, 8 Jan 2015 10:05:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108180527.8362.66608.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 10:05:27 -0800 From: IETF Secretariat Archived-At: Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:05:31 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Thu Jan 8 10:06:00 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287C11A8F4B; Thu, 8 Jan 2015 10:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kRokzqUBQopo; Thu, 8 Jan 2015 10:05:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6189D1A8AE7; Thu, 8 Jan 2015 10:05:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108180556.3017.88381.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 10:05:56 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-10.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, 08 Jan 2015 18:05:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Origin-Bound Authentication (HOBA) Authors : Stephen Farrell Paul Hoffman Michael Thomas Filename : draft-ietf-httpauth-hoba-10.txt Pages : 28 Date : 2015-01-08 Abstract: HTTP Origin-Bound Authentication (HOBA) is a digital signature based design for an HTTP authentication method. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-hoba-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 8 10:06:04 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406C71A8FD3 for ; Thu, 8 Jan 2015 10:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WcQJwyX-q98G; Thu, 8 Jan 2015 10:05:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E30B1A8F41; Thu, 8 Jan 2015 10:05:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" , Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108180556.3017.58029.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 10:05:56 -0800 Archived-At: Subject: [http-auth] New Version Notification - draft-ietf-httpauth-hoba-10.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, 08 Jan 2015 18:06:01 -0000 A new version (-10) has been submitted for draft-ietf-httpauth-hoba: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-hoba-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Jan 8 12:02:22 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72B61A1A07 for ; Thu, 8 Jan 2015 12:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ntp6Aj4FVzD for ; Thu, 8 Jan 2015 12:02:15 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2348C1A0AC8 for ; Thu, 8 Jan 2015 12:01:36 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9355220E85 for ; Thu, 8 Jan 2015 15:01:35 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 08 Jan 2015 15:01:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=74O4G0gOP962CkLqyZmEhMcp5F4=; b=ekMtg4os0WM3Bp8G+9Ckv cq0rn9OInos6zJtnxUecOPvHs2r4nMMl3vpUUh4WqZVHmK0z66Q1S36Z9tpfLgnd Y9dt/Zn7dSANMyoMyyKzWaxAwqqJDk16TeqYopYOm0nxLBdMYzj3TYBwmbF6Kcso ItQ80UfawnWBianYw5NdXM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=74O4G0gOP962CkLqyZmEhMc p5F4=; b=gFy5qtVIvMvTwuiSCuHAu0Su6OLRFtcxkvSi2ihEhajAFN9mC8A0dsG rU2ZX5F7F5IxkZMByOsG8FMzMt2j+dHjHFlftCNjDmJcqCdUtjQUEma31hRtUmNa V+Nl71Vo0DBHu8ZCY0gkqyT9nZKjhBYBhXa0CzntB6OKYU6Bw0/8= X-Sasl-enc: 0XOljclj/8JOq3CsAD1C35zD2qg/RWTimEXqw0E3/ld0 1420747295 Received: from dhcp-171-68-21-108.cisco.com (unknown [171.68.21.108]) by mail.messagingengine.com (Postfix) with ESMTPA id DBD9568014C; Thu, 8 Jan 2015 15:01:33 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54ADD8F0.8020500@cs.tcd.ie> Date: Thu, 8 Jan 2015 12:01:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150107222027.18377.83227.idtracker@ietfa.amsl.com> <54ADBD79.4090201@cs.tcd.ie> <54ADD8F0.8020500@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "httpauth-chairs@tools.ietf.org" , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , IESG Subject: Re: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 20:02:18 -0000 On Jan 7, 2015, at 5:10 PM, Stephen Farrell = wrote: >=20 >=20 > On 08/01/15 00:39, Kathleen Moriarty wrote:>>> >> =3D Section 8 =3D >>>>>>=20 >>>>>> "Binding my CPK with someone else's account would be fun and >>>>>> profitable so SHOULD be appropriately hard." >>>>>>=20 >>>>>> Sarcasm translates pretty poorly across cultures. I would suggest > saying >>>>>> what you actually mean here. >>>>=20 >>>> Wasn't meant to be sarcastic at all. I guess it is a little opaque = but >>>> surely the threat is so obvious that the "fun and profit" = colloquialism >>>> is ok. >=20 >> I think it's better to replace this text, I agree with Alissa that = other >> cultures may have problems with it. >=20 > Alissa didn't mention other cultures but a form of speech, at least > as I read her comment, and a form of speech that wasn't intended > as it happened;-) >=20 > In this case the colloquialism is colloquial to security nerds and > not people from a particular lat/long. So yes, we could replace this > but IMO that'd be us being silly, as it's a quite well known > phrase for security researchers [1] and, turns out, (and I > didn't know) is actually not very modern. [2] Re sarcasm: I assumed it was sarcastic because if you read the sentence = literally, it doesn=92t make sense. Why would you normatively recommend = against something that is fun and profitable? Of course I know what the = colloquialism implies, but anyone who is not familiar with the = colloquialism =97 whether because they are non-native English speakers = or come from a =93culture=94 that is not the security-clueful culture =97 = may not. Furthermore, given that the way the phrase is used is a = variation on the original, a Google search doesn=92t actually produce = helpful results in the first couple of pages (whereas searching on =93for = fun and profit=94 yields the most salient result in the top spot). I hate to lose our colloquialisms and inside jokes as much as the next = person, but for RFCs I disagree that it=92s us being silly. It=92s us = lowering barriers for those unfamiliar with the phrases and jokes to = understanding and using the output of the IETF. There are plenty of = other places where we can still be colloquial. Alissa >=20 > S. >=20 > [1] > = http://scholar.google.com/scholar?hl=3Den&q=3D%22fun+and+profit%22&btnG=3D= &as_sdt=3D1%2C5&as_sdtp=3D > [2] > = https://english.stackexchange.com/questions/25205/what-is-the-origin-of-ph= rase-for-fun-and-profit From nobody Thu Jan 8 14:50:04 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BA31A1B1B; Thu, 8 Jan 2015 14:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 us7_vuvQn1dy; Thu, 8 Jan 2015 14:49:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E1B1A006D; Thu, 8 Jan 2015 14:49:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p7 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108224959.18508.15898.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 14:49:59 -0800 Archived-At: Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: [http-auth] Barry Leiba's Yes on draft-ietf-httpauth-hoba-10: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 22:50:01 -0000 Barry Leiba has entered the following ballot position for draft-ietf-httpauth-hoba-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have looked at the change to Section 8.2, and I think it (and the reference) is a perfect choice, and makes the document stronger. Thank you very much for going in this direction! ------------ Remaining minor comments, left for posterity ------------ -- Section 3 -- The "realm" attribute MUST NOT appear more than once. Does that mean that "challenge" and max-age can appear more than once? If not, why call it out for "realm" and not for the others? -- Section 6.2 -- It seems odd to put the NOT RECOMMENDED mechanism in the middle; I suggest switching sections 6.2.2 and 6.2.3. -- Section 8.3 -- The chances that a typical user (consider my mother) will know or care about this, much less will "request" anything is vanishingly small. Can you say anything here about what can be done that would have any practical utility? -- Section 9.3 -- Please create a new HOBA signature algorithms registry as follows, with the specification required rule for updates. New HOBA signature algorithms SHOULD be in use with other IETF standards track protocols before being added to this registry. I don't think the SHOULD is really right -- who is the target? This needs to be cast as instructions to the designated expert, perhaps as, "The designated expert will review other uses of requested new HOBA signature algorithms, with particular consideration to their use in other IETF standards track protocols." Perhaps there's also another word or two to say about what the DE should consider? -- Sections 9.4 and 9.5 -- Might there be any advice for the designated expert, anything at all? From nobody Thu Jan 8 22:57:48 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879AE1A0055; Thu, 8 Jan 2015 22:57:43 -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 YmmzMrv08wsS; Thu, 8 Jan 2015 22:57:37 -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 E151B1A701E; Thu, 8 Jan 2015 22:57:36 -0800 (PST) Received: from [192.168.2.175] ([93.217.109.11]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MU1MP-1YHtYH2Hk9-00QhQh; Fri, 09 Jan 2015 07:57:05 +0100 Message-ID: <54AF7BB1.9070204@gmx.de> Date: Fri, 09 Jan 2015 07:56:49 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephen Farrell , Richard Barnes , The IESG References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADD6E9.2060200@cs.tcd.ie> In-Reply-To: <54ADD6E9.2060200@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:30XXfZ1C4yZmRy81TA1vHllEBwypijk3gGMdMrAqhLsUyBFRfQ2 QPiCoiJ0l9uCcDsU8Kk1kr5FJ7fwT8VgxK+VqepRerF89rM+8PO4OsFIrJlTSHaeaYLSDZS TaZi1cLXxgXc9JWbMPgtopUlMDmlQILOte6gh97hUXtpYW6MitwCv28WBybVpGo2A0AMDW7 SfhfCe4Lj5VRdze/aoLJQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 06:57:44 -0000 On 2015-01-08 02:01, Stephen Farrell wrote: > ... >> without impacting >> anything else on the server. > > Where is that stated? Wouldn't that mean that using cookies after > an HTTP auth somehow didn't conform? Wouldn't that be nonsense? > (And possibly indicate an issue with 7235 but not HOBA.) > ... RFC 7235 is agnostic of cookies, it's a complete separate construct. Furthermore, cookies are entirely OPTIONAL in HTTP, at least in theory. If HOBA requires cookie support to make the HOBA HTTP authentication work (does it), it might make sense to say that clearly. Best regards, Julian From nobody Thu Jan 8 23:15:23 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DC11A86E6; Thu, 8 Jan 2015 23:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgTX0v9vFROn; Thu, 8 Jan 2015 23:15:08 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043641A86DF; Thu, 8 Jan 2015 23:15:07 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id l4so6752748lbv.12; Thu, 08 Jan 2015 23:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZJBJhvSyEuMx5FpXmXnNZl0wCNIJXmUO/EJMOnBtpIA=; b=EhIvkNH35kNOxcFltH/BY4cCic1w5i2iGduR96Pt/CyAIQThYR+JUBSdxHrHOf6G5f r70bOD9gDIyXiIjq1rUDmu6j9JDgxkadDs4nx8aDTJvR99Kfv7FSoJJkfow26mUPtbqo 2DCRNIHz6esL0BRgglXEJPi4OGCoGtxOPSo6e7+LRswEtNvhZV1LljnMiClpQ4X1CMJK QyrSAHAg1riaSqKi+arsoQYCDKRGELcbKwzf17AHkc+DTWqV10sGD2vQz+WXrVp/Cre1 5pjJ6lPx6DqYenE1TyIOCeEUnMPDjCNSzkDfHrXMGWZ1TIoaN3LgWgwqS3d3/kX6T7S2 0uSg== MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr19685883lam.15.1420787706176; Thu, 08 Jan 2015 23:15:06 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Thu, 8 Jan 2015 23:15:06 -0800 (PST) In-Reply-To: <54AF7BB1.9070204@gmx.de> References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADD6E9.2060200@cs.tcd.ie> <54AF7BB1.9070204@gmx.de> Date: Fri, 9 Jan 2015 15:15:06 +0800 X-Google-Sender-Auth: SLuJ4OdMAavqEEdCZzAVkKT6kW4 Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "httpauth-chairs@tools.ietf.org" , Richard Barnes , "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "http-auth@ietf.org" , The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 07:15:10 -0000 > Furthermore, cookies are entirely OPTIONAL in HTTP, at least in theory. If > HOBA requires cookie support to make the HOBA HTTP authentication work (does > it), it might make sense to say that clearly. It doesn't, and I think it says *that* clearly. That is, it says that cookies can be used, and are typically used, but nowhere that they're required. Without cookies, I believe the client would have to re-send the challenge-response with each request, until the challenge expires (max-age), after which it would receive and handle a new challenge. Cookies make things more convenient and save overhead. Barry From nobody Fri Jan 9 00:27:32 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F4C1A86FA for ; Fri, 9 Jan 2015 00:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trkDJ18oulVG for ; Fri, 9 Jan 2015 00:27:26 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987541A86EB for ; Fri, 9 Jan 2015 00:27:25 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id gd6so13370746lab.3 for ; Fri, 09 Jan 2015 00:27:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7JLlNvxyKxR8/RDzKYnJpFSMusCNlf+R+Y4JLhWTr6w=; b=Y1nYq9GIrMbCR2Kbj58rw3gLWjNjSl3oFD2ysqElMr+dBu6krZ3jnBVifzV5HaJ3ok OUGEi4dAzoEdjJRMi4BBACGGJIVGu07TA3Mqnle2ztyczYZTlV0mDw+E76Qlr8p0VCKK cuU8UiCbfWsMWhZfeZtnxAhnQ/ofMFXwKkcfDGOOFCipwiFpFqOwYuF/wtRw4xmg+kvU 88HCZ/u0FqAdyXegd8lF1bUUsWiE3Taxee66xcYiA2gO29B8xQOvwH1uUlcWEpdCAusT jFmzv16od+d6KAJ+DjfwitPod/46EdHmSWQbQpOXltAgEO3TxKM/iUcVaPA/HuBnfezS 5N1w== X-Gm-Message-State: ALoCoQn7bcMHp54m4Bx1lbQoWElIHhKMVlQPAkWUr5enCVMFaScPvlyp1RnrmWi+iQkmnwLdBNFN MIME-Version: 1.0 X-Received: by 10.152.5.67 with SMTP id q3mr20065515laq.73.1420792043949; Fri, 09 Jan 2015 00:27:23 -0800 (PST) Received: by 10.25.12.215 with HTTP; Fri, 9 Jan 2015 00:27:23 -0800 (PST) In-Reply-To: <54AF7BB1.9070204@gmx.de> References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADD6E9.2060200@cs.tcd.ie> <54AF7BB1.9070204@gmx.de> Date: Fri, 9 Jan 2015 08:27:23 +0000 Message-ID: From: Richard Barnes To: Julian Reschke Content-Type: multipart/alternative; boundary=089e013d1734146606050c33ed59 Archived-At: Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 08:27:27 -0000 --089e013d1734146606050c33ed59 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 9, 2015 at 6:56 AM, Julian Reschke wrote: > On 2015-01-08 02:01, Stephen Farrell wrote: > >> ... >> >>> without impacting >>> anything else on the server. >>> >> >> Where is that stated? Wouldn't that mean that using cookies after >> an HTTP auth somehow didn't conform? Wouldn't that be nonsense? >> (And possibly indicate an issue with 7235 but not HOBA.) >> ... >> > > RFC 7235 is agnostic of cookies, it's a complete separate construct. > > Furthermore, cookies are entirely OPTIONAL in HTTP, at least in theory. If > HOBA requires cookie support to make the HOBA HTTP authentication work > (does it), it might make sense to say that clearly. > > Best regards, Julian > Julian, Rather than cookies, my concern was that this authentication scheme isn't scoped to the authenticating resource. In addition to the authenticating resource, the authentication process needs to have access to the resource .well-known/hoba/register on the same host. Does that cause you any architectural concern? I cleared because I felt like I could live with it for Experimental. This pattern would not fly with me for PS. --Richard --089e013d1734146606050c33ed59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 9, 2015 at 6:56 AM, Julian Reschke <julian.reschke@gmx= .de> wrote:
On 2015-01-08 0= 2:01, Stephen Farrell wrote:
...
without impacting
anything else on the server.

Where is that stated? Wouldn't that mean that using cookies after
an HTTP auth somehow didn't conform? Wouldn't that be nonsense?
(And possibly indicate an issue with 7235 but not HOBA.)
 ...

RFC 7235 is agnostic of cookies, it's a complete separate construct.
Furthermore, cookies are entirely OPTIONAL in HTTP, at least in theory. If = HOBA requires cookie support to make the HOBA HTTP authentication work (doe= s it), it might make sense to say that clearly.

Best regards, Julian

Julian,

Rat= her than cookies, my concern was that this authentication scheme isn't = scoped to the authenticating resource.=C2=A0 In addition to the authenticat= ing resource, the authentication process needs to have access to the resour= ce .well-known/hoba/register on the same host.=C2=A0 Does that cause you an= y architectural concern?

I cleared because I felt like I = could live with it for Experimental.=C2=A0 This pattern would not fly with = me for PS.

--Richard=C2=A0
=C2=A0

--089e013d1734146606050c33ed59-- From nobody Fri Jan 9 00:44:23 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D5C1A86E8; Fri, 9 Jan 2015 00:44:22 -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 LHLksRds7W1H; Fri, 9 Jan 2015 00:44:20 -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 26BFF1A701C; Fri, 9 Jan 2015 00:44:20 -0800 (PST) Received: from [192.168.2.175] ([93.217.109.11]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MPD8G-1YDstP2KzA-004URd; Fri, 09 Jan 2015 09:43:56 +0100 Message-ID: <54AF94C1.7020103@gmx.de> Date: Fri, 09 Jan 2015 09:43:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Richard Barnes References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <54ADD6E9.2060200@cs.tcd.ie> <54AF7BB1.9070204@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KzVQ9etdXdRXm+gov271/fUOGpKs4kOkaMHvP3UhoQIFVMVa0O0 jvirNTYd90kgepMBQBbB4h3j37zgnLWxugXZ01RJTg0IPIbiHeMOAiraL+ZInSrl/nDZdzc SB6nb5zUSpc8VO60BnNKEb+GqBxML+Pj9AKSJjeKzWmAdAlYHupShvlLOkknC0xoamPh3Qp kQDwZ0IB1mIVJmoV7DCCw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, The IESG Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 08:44:22 -0000 On 2015-01-09 09:27, Richard Barnes wrote: > ... > Julian, > > Rather than cookies, my concern was that this authentication scheme > isn't scoped to the authenticating resource. In addition to the > authenticating resource, the authentication process needs to have access > to the resource .well-known/hoba/register on the same host. Does that > cause you any architectural concern? It's workable unless the resource space is shared by multiple services, such as in Web application server. > I cleared because I felt like I could live with it for Experimental. > This pattern would not fly with me for PS. > ... I agree that it we'd want to think about a better approach. Best regards, Julian From nobody Sat Jan 10 11:42:21 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A65C1A87BB; Sat, 10 Jan 2015 11:42:16 -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 YKW5Db11eVrY; Sat, 10 Jan 2015 11:42:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 296261A8728; Sat, 10 Jan 2015 11:42:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150110194214.31253.86620.idtracker@ietfa.amsl.com> Date: Sat, 10 Jan 2015 11:42:14 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-10.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 19:42:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-10.txt Pages : 30 Date : 2015-01-10 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPAuth working group mailing list (http-auth@ietf.org), which is archived at [1]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 10 11:45:28 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C529C1A8781 for ; Sat, 10 Jan 2015 11:45:26 -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 eiBibZ3cCNyt for ; Sat, 10 Jan 2015 11:45:22 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA3B1A8795 for ; Sat, 10 Jan 2015 11:45:22 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so12701776lbv.11 for ; Sat, 10 Jan 2015 11:45:20 -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 :content-type; bh=zVXWjikYSmp5nna0RL6XuRp64hOYc3Gw4hVAGc1hD7Y=; b=XbYpcsfCdaumUdJWL48Nnkz9Kz+x1XbZZJWoav9KieKMLWgR/6Ivd5KwuKUbyhi2oR 90Jlim3xvgS0p+TDyqm7IekHIS531zk0dftPYrOTfJXZpQPXO4GKfoZB3gW4mAGmu0p9 m6UGHR4EMkMawfuLW1jR3plEGb78HKzp0sU14fj4iLP2WqFnSP5jMMYl7CjHKUwu9o+C YoAoGkhXP/XfCNI7MkFi/mr750S40vL1BeG/gT3YibiQ0FC/sZqNHul/8M3STvEwcEoM ORZmrvJ6J3AbZnfPbiTrBXs/0JzCohlK/5bWO5gV9aBJl4/uqjyEr3hRdk1sbDNWTavm MvMg== MIME-Version: 1.0 X-Received: by 10.112.91.43 with SMTP id cb11mr28444763lbb.63.1420919120905; Sat, 10 Jan 2015 11:45:20 -0800 (PST) Received: by 10.114.27.162 with HTTP; Sat, 10 Jan 2015 11:45:20 -0800 (PST) In-Reply-To: <20150110194214.31253.86620.idtracker@ietfa.amsl.com> References: <20150110194214.31253.86620.idtracker@ietfa.amsl.com> Date: Sat, 10 Jan 2015 14:45:20 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=001a11348fd674ce1d050c518334 Archived-At: Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-10.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 19:45:26 -0000 --001a11348fd674ce1d050c518334 Content-Type: text/plain; charset=ISO-8859-1 Hi, We think that with version -10 we have addressed all the comments we received so far. Please, take a look and let us know if we missed anything or if you have any further comments. Thanks, Rifaat On Sat, Jan 10, 2015 at 2:42 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-10.txt > Pages : 30 > Date : 2015-01-10 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that can be used with the HTTP > authentication mechanism. > > Editorial Note (To be removed by RFC Editor before publication) > > Discussion of this draft takes place on the HTTPAuth working group > mailing list (http-auth@ietf.org), which is archived at [1]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-10 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11348fd674ce1d050c518334 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We think that with version -10 we h= ave addressed all the comments we received so far.
Please, take a= look and let us know if we missed anything or if you have any further comm= ents.

Thanks,
=A0Rifaat


On Sat, Jan 1= 0, 2015 at 2:42 PM, <internet-drafts@ietf.org> wrote= :

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

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

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

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

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


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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--001a11348fd674ce1d050c518334-- From nobody Sun Jan 11 06:08:48 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21021A6EEC for ; Sun, 11 Jan 2015 06:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IugdEJ_com-c for ; Sun, 11 Jan 2015 06:08:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF761A3BA6 for ; Sun, 11 Jan 2015 06:08:29 -0800 (PST) Received: from [192.168.2.175] ([93.217.100.224]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MId0S-1YCW712S2i-002KGK; Sun, 11 Jan 2015 15:08:27 +0100 Message-ID: <54B283D4.4090202@gmx.de> Date: Sun, 11 Jan 2015 15:08:20 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: <20150110194214.31253.86620.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cftZI/0nmXRFrog3McBvk8PMNQn2E6Il5SvK2m5a7HbIO1d35tS 2fwrhab2nzjbFp7kj42ER8SBTTFp4PxS+MFDCNCBYbFKhFbFpO7hX6FBXZnK4SEPx8LZqf1 GcsZFeJus7os6JOm9bbJq1E9IGJZgdbnvkKjjzVRGhokEW6Xh4d8ERKeBPhLqG3wZ69CwJc 9x2Ej33dny5VkgwoyimJQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-10.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: Sun, 11 Jan 2015 14:08:36 -0000 On 2015-01-10 20:45, Rifaat Shekh-Yusef wrote: > Hi, > > We think that with version -10 we have addressed all the comments we > received so far. > Please, take a look and let us know if we missed anything or if you have > any further comments. > > Thanks, > Rifaat I will review once the HTTP/2 Last Calls are over next week (hint, hint). Best regards, Julian From nobody Mon Jan 12 17:12:57 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DAD1ACE5D for ; Mon, 12 Jan 2015 17:12:47 -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 BCegsNGBEuoF; Mon, 12 Jan 2015 17:12:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2B81ACE4D; Mon, 12 Jan 2015 17:12:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113011241.19952.8563.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 17:12:41 -0800 From: IETF Secretariat Archived-At: Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 01:12:47 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Mon Jan 12 17:13:12 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD321A8826; Mon, 12 Jan 2015 17:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGYBfQM-SeI5; Mon, 12 Jan 2015 17:12:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 843B81ACE54; Mon, 12 Jan 2015 17:12:44 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113011244.19952.65592.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 17:12:44 -0800 Archived-At: Cc: httpauth mailing list , httpauth chair , RFC Editor Subject: [http-auth] Document Action: 'HTTP Origin-Bound Authentication (HOBA)' to Experimental RFC (draft-ietf-httpauth-hoba-10.txt) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 01:13:02 -0000 The IESG has approved the following document: - 'HTTP Origin-Bound Authentication (HOBA)' (draft-ietf-httpauth-hoba-10.txt) as Experimental RFC This document is the product of the Hypertext Transfer Protocol Authentication Working Group. The IESG contact persons are Kathleen Moriarty and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ Technical Summary HTTP Origin-Bound Authentication (HOBA) is a digital signature based design for an HTTP authentication method. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. Working Group Summary This document is one of the experimental documents submitted to the HTTP-Auth working group. The proposed authentication method has been reviewed by many participants, mostly in WGLC, resulting in a longish list in the acknowledgements section and some substantial changes. With version -07 it is the consensus of the HTTP-Auth working group that this document is fit to be published as an experimental RFC. Document Quality There are at least two implementations of the protocol in this document ([1],[2]). They work and interoperate, but there is no wide-spread deployment, which suggests that "experimental" is the correct track for this document. All authors have confirmed that they are not aware of any undisclosed IPR associated with this document. There have been no IPR disclosures. [1] https://hoba.ie [2] https://github.com/razevedo/hoba-authentication Personnel Yoav Nir is the document shepherd. Kathleen Moriarty is the responsible Area Directory. RFC Editor note: Change reference name [bland] to [examples] or something similar so it is understood what is the intended use of the reference. I'm sure the author just put it there to make sure I checked ;-) From nobody Tue Jan 13 16:24:20 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41D91ACEC9 for ; Tue, 13 Jan 2015 16:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gltcF3Hrvny3; Tue, 13 Jan 2015 16:24:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA2D1ACD8A; Tue, 13 Jan 2015 16:24:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114002415.23657.77785.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 16:24:15 -0800 From: IETF Secretariat Archived-At: Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 00:24:18 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Thu Jan 15 08:42:34 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68371B2DC7 for ; Thu, 15 Jan 2015 08:42:27 -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 7j3b3x2LTPb6 for ; Thu, 15 Jan 2015 08:42:19 -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 056951B2DD2 for ; Thu, 15 Jan 2015 08:42:19 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MhhwJ-1YO7YZ3A15-00MrOi; Thu, 15 Jan 2015 17:42:17 +0100 Message-ID: <54B7EDE1.2090208@gmx.de> Date: Thu, 15 Jan 2015 17:42:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: <20150110194214.31253.86620.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/Huh8nY5w9hy8GuTkp0NkkuSqdl6KnknBi4NVzkcLY3W/zh/7UQ 95d0wE8rW/vTnNSSnwC2D3yuQN8PR/fW2INZZCZ0x8dn1YEctj9miHbGlPPzTAKFwG+3hAm 5nT69oM8Lr6DMgtV+9/OJQ3AMN1lLap+eECmQm0CACPgAg+js57U0bhDtAHYcACYGrdkbZl F8+SIPod7ZpCooGOyyTww== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-10.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, 15 Jan 2015 16:42:28 -0000 On 2015-01-10 20:45, Rifaat Shekh-Yusef wrote: > Hi, > > We think that with version -10 we have addressed all the comments we > received so far. > Please, take a look and let us know if we missed anything or if you have > any further comments. > > Thanks, > Rifaat > ... I had a quick glance at the I18N related stuff, and it still doesn't work. Section 3.1: Some or all of the parameters used in the various headers fields used by this document can be sent using the [RFC5987] encoding. That's not really helpful. You really need to state which. Section 3.9.2: The following example assumes that an access protected document is being requested from the server via a GET request. The URI for the request is "http://api.example.org/doe.json". Both client and server know the userhash of the username, support the UTF-8 character encoding scheme, and use the SHA-512-256 algorithm. The username for the request is "Jaesoen Doe" and the password is "Secret, or not?". The following example assumes that an access protected document is being requested from the server via a GET request. The URI for the request is "http://api.example.org/doe.json". Both client and server know the userhash of the username, support the UTF-8 character encoding scheme, and use the SHA-512-256 algorithm. The username for the request is "Jaesoen Doe" and the password is "Secret, or not?". The intent was to use a user name containing non-ASCII characters, but that was helpfully (:-) converted away by xml2rfc. Non-ASCII examples in IETF docs are currently hard. See for an example how to workaround that limitation. Section 4: The only allowed value is "UTF-8", to be matched case-insensitively (see [RFC2978], Section 2.3). It indicates that the server expects user name and password to be converted to Unicode Normalization Form C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets using the UTF-8 character encoding scheme ([RFC3629]), ), and percent escaped in extended notation ([RFC5987]). I don't believe RFC 5987 applies here at all; but maybe I'm missing something. Best regards, Julian From nobody Thu Jan 15 09:58:23 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950991B2F33 for ; Thu, 15 Jan 2015 09:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZG5s1OHvGNV for ; Thu, 15 Jan 2015 09:58:18 -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 1B0281B2F34 for ; Thu, 15 Jan 2015 09:58:16 -0800 (PST) Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id 2EDDC25ACC2E; Thu, 15 Jan 2015 18:58:14 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3kNYCn4S3wz5vN9; Thu, 15 Jan 2015 18:58:13 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Sophie Bremer In-Reply-To: <54B7EDE1.2090208@gmx.de> Date: Thu, 15 Jan 2015 18:58:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150110194214.31253.86620.idtracker@ietfa.amsl.com> <54B7EDE1.2090208@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-10.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, 15 Jan 2015 17:58:20 -0000 Hello, > Am 15.01.2015 um 17:42 schrieb Julian Reschke : >=20 > On 2015-01-10 20:45, Rifaat Shekh-Yusef wrote: >> Hi, >>=20 >> We think that with version -10 we have addressed all the comments we >> received so far. >> Please, take a look and let us know if we missed anything or if you = have >> any further comments. >>=20 >> Thanks, >> Rifaat >> ... >=20 > I had a quick glance at the I18N related stuff, and it still doesn't = work. >=20 > Section 3.1: >=20 > Some or all of the parameters used in the various headers fields = used > by this document can be sent using the [RFC5987] encoding. >=20 > That's not really helpful. You really need to state which. Do you expect something like "... fields used by this document can be = sent using the extended notation of [RFC5987]." ? > Section 3.9.2: >=20 >=20 > The following example assumes that an access protected document is > being requested from the server via a GET request. The URI for the > request is "http://api.example.org/doe.json". Both client and = server > know the userhash of the username, support the UTF-8 character > encoding scheme, and use the SHA-512-256 algorithm. The username = for > the request is "Jaesoen Doe" and the password is "Secret, or not?". > The following example assumes that an access protected document is > being requested from the server via a GET request. The URI for the > request is "http://api.example.org/doe.json". Both client and = server > know the userhash of the username, support the UTF-8 character > encoding scheme, and use the SHA-512-256 algorithm. The username = for > the request is "Jaesoen Doe" and the password is "Secret, or not?". >=20 > The intent was to use a user name containing non-ASCII characters, but = that was helpfully (:-) converted away by xml2rfc. Non-ASCII examples in = IETF docs are currently hard. See = for an example how to workaround that limitation. Thank you, we will change this. > Section 4: >=20 > The only allowed value is "UTF-8", to be matched case-insensitively > (see [RFC2978], Section 2.3). It indicates that the server expects > user name and password to be converted to Unicode Normalization Form > C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets > using the UTF-8 character encoding scheme ([RFC3629]), ), and = percent > escaped in extended notation ([RFC5987]). >=20 > I don't believe RFC 5987 applies here at all; but maybe I'm missing = something. I don't unterstand you point. RFC 5987 describes a way (extended = notation) of writing values with any possible charset. Regards, Sophie= From nobody Thu Jan 15 10:13:02 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6F01B2F87 for ; Thu, 15 Jan 2015 10:12: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 S8ZLKwbKeM0I for ; Thu, 15 Jan 2015 10:12:48 -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 9229E1B2F6C for ; Thu, 15 Jan 2015 10:12:28 -0800 (PST) Received: from [192.168.2.175] ([93.217.75.226]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0La2Xx-1XTBMV0CIX-00lnP8; Thu, 15 Jan 2015 19:12:26 +0100 Message-ID: <54B80303.5080304@gmx.de> Date: Thu, 15 Jan 2015 19:12:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sophie Bremer References: <20150110194214.31253.86620.idtracker@ietfa.amsl.com> <54B7EDE1.2090208@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jgeV0G5jw7nJP85SajJtL/npMb5GOvktnOzmpMCPcbBzmdmBiZb kaqRd8Ik/WQQh3LpU8RY6uo5O39KaKoYQbfNhbJ1C4PtwSrEzuA1+iQbJat9kYW4zLVtafv CzKUGjrLV+8Et2LsBx4OSuE4MX1k7U0qPMI8/ZfbQ+d3sSKfSwOdSXTuW5gW5MaHj4p/2uv /aSFvdwtsR4fzpgP9oskw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-10.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, 15 Jan 2015 18:12:53 -0000 On 2015-01-15 18:58, Sophie Bremer wrote: > Hello, > >> Am 15.01.2015 um 17:42 schrieb Julian Reschke : >> >> On 2015-01-10 20:45, Rifaat Shekh-Yusef wrote: >>> Hi, >>> >>> We think that with version -10 we have addressed all the comments we >>> received so far. >>> Please, take a look and let us know if we missed anything or if you have >>> any further comments. >>> >>> Thanks, >>> Rifaat >>> ... >> >> I had a quick glance at the I18N related stuff, and it still doesn't work. >> >> Section 3.1: >> >> Some or all of the parameters used in the various headers fields used >> by this document can be sent using the [RFC5987] encoding. >> >> That's not really helpful. You really need to state which. > > Do you expect something like "... fields used by this document can be sent using the extended notation of [RFC5987]." ? I'd expect an enumeration, and that enumeration to be restricted to those fields that actually need I18N. >> Section 3.9.2: >> >> >> The following example assumes that an access protected document is >> being requested from the server via a GET request. The URI for the >> request is "http://api.example.org/doe.json". Both client and server >> know the userhash of the username, support the UTF-8 character >> encoding scheme, and use the SHA-512-256 algorithm. The username for >> the request is "Jaesoen Doe" and the password is "Secret, or not?". >> The following example assumes that an access protected document is >> being requested from the server via a GET request. The URI for the >> request is "http://api.example.org/doe.json". Both client and server >> know the userhash of the username, support the UTF-8 character >> encoding scheme, and use the SHA-512-256 algorithm. The username for >> the request is "Jaesoen Doe" and the password is "Secret, or not?". >> >> The intent was to use a user name containing non-ASCII characters, but that was helpfully (:-) converted away by xml2rfc. Non-ASCII examples in IETF docs are currently hard. See for an example how to workaround that limitation. > > Thank you, we will change this. > >> Section 4: >> >> The only allowed value is "UTF-8", to be matched case-insensitively >> (see [RFC2978], Section 2.3). It indicates that the server expects >> user name and password to be converted to Unicode Normalization Form >> C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets >> using the UTF-8 character encoding scheme ([RFC3629]), ), and percent >> escaped in extended notation ([RFC5987]). >> >> I don't believe RFC 5987 applies here at all; but maybe I'm missing something. > > I don't unterstand you point. RFC 5987 describes a way (extended notation) of writing values with any possible charset. My understanding was that the charset parameter was about how things are encoded into octets before Digest computations happen. Isn't that the case? Best regards, Julian From nobody Fri Jan 16 02:55:47 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAEB1ACD3C; Fri, 16 Jan 2015 02:55:43 -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 EvgAOnKOXVcI; Fri, 16 Jan 2015 02:55:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E651AC3AC; Fri, 16 Jan 2015 02:55:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150116105536.5978.12192.idtracker@ietfa.amsl.com> Date: Fri, 16 Jan 2015 02:55:36 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-05.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 10:55:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : The 'Basic' HTTP Authentication Scheme Author : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-update-05.txt Pages : 15 Date : 2015-01-16 Abstract: This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme, which transmits credentials as userid/password pairs, obfuscated by the use of Base64 encoding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 16 03:01:18 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D737C1ACD61 for ; Fri, 16 Jan 2015 03:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AIU6CI-drae for ; Fri, 16 Jan 2015 03:01:12 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A711AC398 for ; Fri, 16 Jan 2015 03:01:11 -0800 (PST) Received: from [192.168.1.194] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 666DE15A0140 for ; Fri, 16 Jan 2015 12:01:09 +0100 (CET) Message-ID: <54B8EF6E.30806@greenbytes.de> Date: Fri, 16 Jan 2015 12:01:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: http-auth@ietf.org References: <20150116105536.5978.12192.idtracker@ietfa.amsl.com> In-Reply-To: <20150116105536.5978.12192.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-05.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 11:01:15 -0000 On 2015-01-16 11:55, 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 : The 'Basic' HTTP Authentication Scheme > Author : Julian F. Reschke > Filename : draft-ietf-httpauth-basicauth-update-05.txt > Pages : 15 > Date : 2015-01-16 > > Abstract: > This document defines the "Basic" Hypertext Transfer Protocol (HTTP) > Authentication Scheme, which transmits credentials as userid/password > pairs, obfuscated by the use of Base64 encoding. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-05 > ... This version addresses one post-WGLC comment by Michael Köller, and also updates the DIGEST reference. I believe it's ready for IETF LC. Best regards, Julian PS: WG LC comments were addressed in -04 () From nobody Fri Jan 16 04:25:55 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAA31ACD30 for ; Fri, 16 Jan 2015 04:25:54 -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 uSUv7J4AsqIO for ; Fri, 16 Jan 2015 04:25:52 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC761AC3E4 for ; Fri, 16 Jan 2015 04:25:52 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so20264514wgh.1 for ; Fri, 16 Jan 2015 04:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rijOct009q8s9XZYxst9z2t3lxZaigx95s57NPu5y70=; b=ZLnNAIY2yjl8ayZtePEEsl5GBS5oRF2wq8/OCcGHCuLTfALPuL/2g9xIPxJrHUAN21 Slh9YLFiIvcbfvl45H4+6ixD2UvQ0LHC72Q9JBnWdgib2OybxiogG5plFLtl8m/RKuRi gRUpVi/HGjT4iiClbhlDywavdiQbCEmHfsnhKgs++imER3dFGLWf96IDpsDcZPwcfH3M ih2yviGYlPa+2FhH6ShMDBhGY1ay2VlX3n2SAz/wtC0EJgBK7ZzBrHZjaCx2JTo3vRzp sSkMFKwSHoJ/wAm92/inrzdlW52H2xluF8KKWhIkvP0fR/Gs3/3i8ERDa8zhFPDZJqsm mjsA== X-Received: by 10.181.13.42 with SMTP id ev10mr5680177wid.78.1421411151065; Fri, 16 Jan 2015 04:25:51 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id fm10sm2828905wib.7.2015.01.16.04.25.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Jan 2015 04:25:50 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <54B8EF6E.30806@greenbytes.de> Date: Fri, 16 Jan 2015 14:25:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F915AE1-791E-48FC-97E5-A4F27CCFC3D3@gmail.com> References: <20150116105536.5978.12192.idtracker@ietfa.amsl.com> <54B8EF6E.30806@greenbytes.de> To: Julian Reschke X-Mailer: Apple Mail (2.1993) Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-05.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 12:25:54 -0000 > On Jan 16, 2015, at 1:01 PM, Julian Reschke = wrote: >=20 > On 2015-01-16 11:55, internet-drafts@ietf.org wrote: >>=20 >> 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. >>=20 >> Title : The 'Basic' HTTP Authentication Scheme >> Author : Julian F. Reschke >> Filename : draft-ietf-httpauth-basicauth-update-05.txt >> Pages : 15 >> Date : 2015-01-16 >>=20 >> Abstract: >> This document defines the "Basic" Hypertext Transfer Protocol = (HTTP) >> Authentication Scheme, which transmits credentials as = userid/password >> pairs, obfuscated by the use of Base64 encoding. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-05 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-basicauth-update-05= >> ... >=20 > This version addresses one post-WGLC comment by Michael K=F6ller, and = also updates the DIGEST reference. I believe it's ready for IETF LC. >=20 > Best regards, Julian >=20 > PS: WG LC comments were addressed in -04 = () Thanks, Julian. I don=92t believe we need another WGLC for this document. I=92d like to = request the working group to read this latest version. Please send a = message to the list if you *do not* believe that it is ready for IETF = LC. If we don=92t hear any objections by next Friday (23-Jan), we will send = this document to Kathleen. thanks Yoav & Matt From nobody Tue Jan 20 11:52:27 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B798C1B2B42; Tue, 20 Jan 2015 11:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ej9ijUYkRYKF; Tue, 20 Jan 2015 11:52:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E471B2AC2; Tue, 20 Jan 2015 11:52:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120195222.25067.17651.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 11:52:22 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-11.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 19:52:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-11.txt Pages : 30 Date : 2015-01-20 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPAuth working group mailing list (http-auth@ietf.org), which is archived at [1]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 20 11:56:41 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580311B2B01; Tue, 20 Jan 2015 11:56:40 -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 CGd1V9YjjXt3; Tue, 20 Jan 2015 11:56:38 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8801B2AC2; Tue, 20 Jan 2015 11:56:38 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id s18so15498087lam.5; Tue, 20 Jan 2015 11:56:36 -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=EC/OIV9ela4sA+ZyAHhr5er3mEHFukZDHPYZytjoL/Y=; b=JH06GXZ1u0kEIytZU9DM8WdTdslYGRRhPNVUfENIiIuabcdC0nzE3cM/Hpejw9ab40 FFKdUyS+dffQZ9LPica86TxfkqAzN+SI36nsNTXjp9a6Tcp3uNUdPJyln4hW89ci/8He o1xm2LBcUNNuhnXuZRHEWKcYczqH5yQj1OwStj7/tQis1sXpdrcS+HwI80NYw8j5sZJO W4+bnoUCMAUYKpMQ+1UvJVzKgq85OQi/kDA/nLi/K4hquScXYysmdmufwVLqDqQTnqpk wZXxaGvysKg+41IycLiCPLj0TkFwtFuwogovk0cBbObNwG//TsN108nwyVVCjP2PoJmW 0GqA== MIME-Version: 1.0 X-Received: by 10.112.185.101 with SMTP id fb5mr40597586lbc.12.1421783796650; Tue, 20 Jan 2015 11:56:36 -0800 (PST) Received: by 10.114.80.201 with HTTP; Tue, 20 Jan 2015 11:56:36 -0800 (PST) In-Reply-To: <20150120195222.25067.17651.idtracker@ietfa.amsl.com> References: <20150120195222.25067.17651.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 14:56:36 -0500 Message-ID: From: Rifaat Shekh-Yusef To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=001a11c3c5162596af050d1ad666 Archived-At: Cc: "http-auth@ietf.org" , i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-11.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 19:56:40 -0000 --001a11c3c5162596af050d1ad666 Content-Type: text/plain; charset=ISO-8859-1 Julian, Thanks for your comments on version -10. We believe that this new version addresses your comments. Can you please take a look and let us know if you have any further comments? Thanks, Rifaat On Tue, Jan 20, 2015 at 2:52 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-11.txt > Pages : 30 > Date : 2015-01-20 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that can be used with the HTTP > authentication mechanism. > > Editorial Note (To be removed by RFC Editor before publication) > > Discussion of this draft takes place on the HTTPAuth working group > mailing list (http-auth@ietf.org), which is archived at [1]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-11 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c3c5162596af050d1ad666 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Julian,

Thanks for your comm= ents on version -10.
We believe that this new version addresses y= our comments.
Can you please take a look and let us know if you h= ave any further comments?

Thanks,
=A0Rif= aat


On Tue, Jan 20, 2015 at 2:52 PM, <internet-drafts@iet= f.org> wrote:

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

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

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

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

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


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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--001a11c3c5162596af050d1ad666-- From nobody Tue Jan 20 14:20:57 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158C01A004E; Tue, 20 Jan 2015 14:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cunb85YN68rk; Tue, 20 Jan 2015 14:20:53 -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 0993F1A004B; Tue, 20 Jan 2015 14:20:52 -0800 (PST) Received: from [192.168.2.175] ([93.217.102.6]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MQyxa-1YIcJB01h0-00UGu5; Tue, 20 Jan 2015 23:20:51 +0100 Message-ID: <54BED4BD.9070600@gmx.de> Date: Tue, 20 Jan 2015 23:20:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , internet-drafts@ietf.org References: <20150120195222.25067.17651.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Yti2Ttv8GJ14CRIVg2FdmojVV8q1sKDNEPqyWYEhDMjydg1NahQ Y8RXOJaJS73TzP+tGklYI6rkakoy2EMmU8+pTFyrqqBnLwgabuRnRpDm/lgC/2XnVJ+yzNw PsCom75l+wJJ3ieQqnDYB+evHDdh6zoTbbrpNZ8bkjDHFLC8sLcPLFtC4fb5HWsk9NpSKYE U2wC/2nQriQQxbfQTjLLw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" , i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-11.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 22:20:56 -0000 On 2015-01-20 20:56, Rifaat Shekh-Yusef wrote: > Julian, > > Thanks for your comments on version -10. > We believe that this new version addresses your comments. > Can you please take a look and let us know if you have any further comments? > > Thanks, > Rifaat I will, but it'll probably take a few days. Best regards, Julian From nobody Tue Jan 20 17:06:17 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24A61A00F9 for ; Tue, 20 Jan 2015 17:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjlgbgZ3uK3T; Tue, 20 Jan 2015 17:06:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 660101A00EA; Tue, 20 Jan 2015 17:06:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121010614.11192.97419.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 17:06:14 -0800 From: IETF Secretariat Archived-At: Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 01:06:16 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Tue Jan 20 17:06:22 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30F21A00F5 for ; Tue, 20 Jan 2015 17:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlxNfF1VgjD3; Tue, 20 Jan 2015 17:06:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A861A00F1; Tue, 20 Jan 2015 17:06:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121010615.11192.87653.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 17:06:15 -0800 From: IETF Secretariat Archived-At: Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 01:06:18 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Wed Jan 21 12:05:28 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7785B1A87BB for ; Wed, 21 Jan 2015 12:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXsT7-L8WANR; Wed, 21 Jan 2015 12:05:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9E41A87AF; Wed, 21 Jan 2015 12:05:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121200512.1663.69618.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 12:05:12 -0800 From: IETF Secretariat Archived-At: Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 20:05:17 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Thu Jan 22 00:53:15 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8D61A1B26 for ; Thu, 22 Jan 2015 00:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aic4GbCY0DPy for ; Thu, 22 Jan 2015 00:53:13 -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 AC4B81A0166 for ; Thu, 22 Jan 2015 00:53:12 -0800 (PST) Received: from [192.168.2.175] ([84.187.32.148]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LejNC-1XvsBU03Re-00qSLj for ; Thu, 22 Jan 2015 09:53:10 +0100 Message-ID: <54C0BA6F.20302@gmx.de> Date: Thu, 22 Jan 2015 09:53:03 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:TXcGWlIw7J+CnRf9pjvqm+M75j2uCWk/C5IxrrGPk6eY9CLw3lr zCMILdd9vAzMTWZyLauGzAY/etTFESdPsYKAiR2S1fYE9bvJ9GKqJMay7kAvHf4x2mdnwIX UuGqRqJJAhz70fpH9/TnDE3bbhukoKIXfXJuDsrcRK7Wtn1IzUhqRWbRaiKzBCVmktQMzH8 KdOI9S3gOYOezoKM54hBg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [http-auth] Authentication-Info in digest draft 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, 22 Jan 2015 08:53:14 -0000 Hi there, (I came across this while looking at splitting this into a separate doc, which I still think would be better) : > On subsequent responses, the server sends Proxy-Authenticate-Info > with parameters the same as those for the Authentication-Info header > field. 1) There is no formal definition of the header field. 2) According to the IANA registry, it's called "Proxy-Authentication-Info". 3) Finally, there are no IANA considerations for updating that registration. Best regards, Julian From nobody Thu Jan 22 15:52:33 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3D71A89A0; Thu, 22 Jan 2015 15:52:29 -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 qqwi2h9Gdz3Y; Thu, 22 Jan 2015 15:52:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D971A89A9; Thu, 22 Jan 2015 15:52:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122235224.15869.24099.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 15:52:24 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-12.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, 22 Jan 2015 23:52:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-12.txt Pages : 30 Date : 2015-01-22 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPAuth working group mailing list (http-auth@ietf.org), which is archived at [1]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 22 15:54:58 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDC91A8A10 for ; Thu, 22 Jan 2015 15:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erluK3A6z6Gl for ; Thu, 22 Jan 2015 15:54:53 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D25C1A8A1C for ; Thu, 22 Jan 2015 15:54:24 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id q1so4625480lam.2 for ; Thu, 22 Jan 2015 15:54:23 -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=a+qhtcue610XtImJrVbCQZjkI6FiXSrsW0WAgOi5KYA=; b=EhHMs/c1X8IQYq3CAKYlgzltBckdHI2Xp18z+5fDvtVE53QcgqJgQT7ANjh/b92Kui IlrLwwVC5pgMX0ZNj/nzzknWxuZ57ucVt3/EOYQ1zsdRCcBm81kPnz7asPxQn3n23+yd VCA4ljODyslx5DPIhZxKIszvoHcDuLFQNaaGQ+CzTQ2if4m9b0xX1xVcjoyBZcp/Rmc/ Uiv9WmFybzTCdZbid9JedxrdA5cq9bWaBCa+MG6D+jipYQcUV9ZQz2Y7RIWs35YLnptV pd/ZYjWT2ShFgSmDDEF7nq5xYY6PA+xlNy05I6/oqIHfeNhFvOihE32HoIN1eb8EZkqE gYtw== MIME-Version: 1.0 X-Received: by 10.152.225.138 with SMTP id rk10mr4410932lac.18.1421970863095; Thu, 22 Jan 2015 15:54:23 -0800 (PST) Received: by 10.114.80.201 with HTTP; Thu, 22 Jan 2015 15:54:23 -0800 (PST) In-Reply-To: <54C0BA6F.20302@gmx.de> References: <54C0BA6F.20302@gmx.de> Date: Thu, 22 Jan 2015 18:54:23 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=001a1133b73e2d0432050d466457 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Authentication-Info in digest draft 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, 22 Jan 2015 23:54:55 -0000 --001a1133b73e2d0432050d466457 Content-Type: text/plain; charset=ISO-8859-1 Thanks Julian, Good catch. I have just submitted -12 which addresses these comments. Regards, Rifaat On Thu, Jan 22, 2015 at 3:53 AM, Julian Reschke wrote: > Hi there, > > (I came across this while looking at splitting this into a separate doc, > which I still think would be better) > > : > > On subsequent responses, the server sends Proxy-Authenticate-Info >> with parameters the same as those for the Authentication-Info header >> field. >> > > 1) There is no formal definition of the header field. > > 2) According to the IANA registry, it's called "Proxy-Authentication-Info". > > 3) Finally, there are no IANA considerations for updating that > registration. > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a1133b73e2d0432050d466457 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Julian,

Good catch. I have just = submitted -12 which addresses these comments.

Regards,
=A0Rifaat


On Thu, Jan 22, 2015 at 3:53 AM, Julian R= eschke <julian.reschke@gmx.de> wrote:
Hi there,

(I came across this while looking at splitting this into a separate doc, wh= ich I still think would be better)

<http://tools.ietf.org/html/draft-ietf-ht= tpauth-digest-11#section-3.8>:

=A0 =A0On subsequent responses, the server sends Proxy-Authenticate-Info =A0 =A0with parameters the same as those for the Authentication-Info header=
=A0 =A0field.

1) There is no formal definition of the header field.

2) According to the IANA registry, it's called "Proxy-Authenticati= on-Info".

3) Finally, there are no IANA considerations for updating that registration= .

Best regards, Julian

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

--001a1133b73e2d0432050d466457-- From nobody Sat Jan 24 04:39:50 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC471A0054 for ; Sat, 24 Jan 2015 04:39:47 -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 m48yoZozRBbT for ; Sat, 24 Jan 2015 04:39:45 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093B31A0052 for ; Sat, 24 Jan 2015 04:39:45 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id hs14so1639922lab.9 for ; Sat, 24 Jan 2015 04:39:43 -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 :content-type; bh=LqlXGx1I1ayVGkdBkfyZYgyp+cONDr8UndVQgVM691k=; b=Y6eb9reyAyM8VKt0j51UcHIoJotRfOrzwiHFuLU+TL5KgyywX+LZhf5Dy5lZX57K8g R4aWLLxDLSxH7Hoe5kW7ZZj1zJr5duISzcq3U97mzHTX4yLFD73E7tqWJvRk5/GtkAnP 6YAIU3FwlazKgt+hMc3ht8yzWiy1qbdWrP/omphf3frPBiIQrW3RS9yNlb66vbAXK00x WNO4IDwg3BUCqPjjkFqXou6hNRnY72MsGzqH0pHpSw8ed4aQWCwNj/0UKLv2QfuBrxrB AfDeuL+0nI2YzIssgPNMYuhvkU89JaUd7x+fQmLDh2dJqniQ+hlKzgJFZYeMVH9FGhX9 +X6A== MIME-Version: 1.0 X-Received: by 10.112.185.101 with SMTP id fb5mr12334138lbc.12.1422103183479; Sat, 24 Jan 2015 04:39:43 -0800 (PST) Received: by 10.114.80.201 with HTTP; Sat, 24 Jan 2015 04:39:43 -0800 (PST) In-Reply-To: <20150122235224.15869.24099.idtracker@ietfa.amsl.com> References: <20150122235224.15869.24099.idtracker@ietfa.amsl.com> Date: Sat, 24 Jan 2015 07:39:43 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3c51615d806050d6533a4 Archived-At: Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-12.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 12:39:47 -0000 --001a11c3c51615d806050d6533a4 Content-Type: text/plain; charset=ISO-8859-1 Julian, We believe that we have addresses all your comments with this version of the draft. Do you have any further comments. Regards, Rifaat On Thu, Jan 22, 2015 at 6:52 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-12.txt > Pages : 30 > Date : 2015-01-22 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that can be used with the HTTP > authentication mechanism. > > Editorial Note (To be removed by RFC Editor before publication) > > Discussion of this draft takes place on the HTTPAuth working group > mailing list (http-auth@ietf.org), which is archived at [1]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-12 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c3c51615d806050d6533a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Julian,

We believe that we have address= es all your comments with this version of the draft.
Do you have = any further comments.

Regards,
=A0Rifaat=


On Thu, Jan 22, 2015 at 6:52 PM, <internet-drafts@ietf= .org> wrote:

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

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

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

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

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


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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--001a11c3c51615d806050d6533a4-- From nobody Sat Jan 24 11:10:23 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6641A8ABA for ; Sat, 24 Jan 2015 11:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K1jF_FE86vD for ; Sat, 24 Jan 2015 11:10:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3F41A8AB8 for ; Sat, 24 Jan 2015 11:10:18 -0800 (PST) Received: from [192.168.2.175] ([93.217.106.47]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MaqeA-1Xz4Ll3aBe-00KLiV; Sat, 24 Jan 2015 20:10:15 +0100 Message-ID: <54C3EE0D.2080506@gmx.de> Date: Sat, 24 Jan 2015 20:10:05 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <20150124190127.3801.31394.idtracker@ietfa.amsl.com> In-Reply-To: <20150124190127.3801.31394.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150124190127.3801.31394.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:a2cwoy931b6Nl2gWoTKt6wpXKSjCxUpUN6q9peYpd2rbp96L4R4 bmRtjxMrwprADAAkqX4b0Rx+KxgAT0Y41IAGksXxCHARCaQEhhcfoYw8jflIX43iK9AB2JU 1sQkFoxwhje79Kr8zitBoa/0FWHyLiQ/BnFPYL/Fhjm60/DJMjcA9RvWLx+Jqwk7IEWbExr rYXbv3WDh8WPST1x0Mu6g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [http-auth] Fwd: New Version Notification for draft-reschke-httpauth-auth-info-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 19:10:20 -0000 Hi there, as discussed before, I believe Authentication-Info (and Proxy-Authentication-Info) should be defined separately from Digest. Here's my proposal. Best regards, Julian -------- Forwarded Message -------- Subject: New Version Notification for draft-reschke-httpauth-auth-info-00.txt Date: Sat, 24 Jan 2015 11:01:27 -0800 From: internet-drafts@ietf.org To: Julian F. Reschke , Julian F. Reschke A new version of I-D, draft-reschke-httpauth-auth-info-00.txt has been successfully submitted by Julian F. Reschke and posted to the IETF repository. Name: draft-reschke-httpauth-auth-info Revision: 00 Title: The Hypertext Transfer Protocol (HTTP) Authentication-Info Header Field Document date: 2015-01-24 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-reschke-httpauth-auth-info-00.txt Status: https://datatracker.ietf.org/doc/draft-reschke-httpauth-auth-info/ Htmlized: http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00 Abstract: This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" header fields for use in HTTP authentication schemes which need to return additional information during or after authentication. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sun Jan 25 05:54:07 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0AC1A1A59 for ; Sun, 25 Jan 2015 05:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 RU59I9HlITJT for ; Sun, 25 Jan 2015 05:54:01 -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 7D9B91A1A55 for ; Sun, 25 Jan 2015 05:54:01 -0800 (PST) Received: from [192.168.2.175] ([93.217.106.47]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LzbXq-1Xc4qS3sHK-014jQX; Sun, 25 Jan 2015 14:53:59 +0100 Message-ID: <54C4F56C.1080102@gmx.de> Date: Sun, 25 Jan 2015 14:53:48 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> In-Reply-To: <548DBA2D.2010808@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rNQu4vE5B20HnrGkir1ja/h3h1itTxNeASiBuxe7VaGmVwVJKxE YHt9AJHuguTMQWSy1lMeLMee13NO/b4TtZMszD1EEC9So++c/OOAAvxDKi28DA2gPUREeLi 9PpqRzzYl+myYSQsSYG0FhyK5hAIHwuv2gHM5qX/YFAcKR2ScUWD0HTi1LMkw/Kf0p2uEqv 9DJ+zhcR4jOutyPmeMt+Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.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: Sun, 25 Jan 2015 13:54:06 -0000 Hi there, I'm looking at and how the feedback below was addressed...: On 2014-12-14 17:26, Julian Reschke wrote: > ... > prefix (after both have been made absolute) may be assumed to be > in the same protection space. If this parameter is omitted or its > value is empty, the client SHOULD assume that the protection space > consists of all URIs on the web-origin. All URIs in this list > SHOULD use the same scheme (https or http); mixing them is a bad > idea. > > web_origin and canonical root need definitions. > ... This now reads: > A quoted, space-separated list of URIs, as specified in [RFC3986], > that define the protection space. If a URI is an abs_path, it is > relative to the canonical root URL (See Section 2.2 of [RFC7235]) > of the web-origin [RFC6454]. An absolute-URI in this list may > refer to a different server than the web-origin. The client can It's still not clear to me why we need both "canonical root URL" *and* web-origin here. Can you explain? Also: > Why is mixing them a "bad idea"? - maybe this could be explained better. This text is still here. > ... > stale > A case-insensitive flag indicating that the previous request from > the client was rejected because the nonce value was stale. If > stale is TRUE, the client MAY wish to simply retry the request > > "MAY wish" doesn't seem like a case for a BCP14 keyword. This now says "may wish"; please avoid lowercase BCP14 keywords. Maybe "might wish"? > 3.4 The Authorization Request Header > > s/header/header field/ There are still cases where the spec just says "header". > ... > uri > The URI from request-target of the Request-Line; duplicated here > because proxies are allowed to change the Request-Line in transit. > > The request-target of the Request-Line isn't necessarily a URI... > ... This now says: > The Effective Request URI [RFC7230] from request-target of the > Request-Line; duplicated here because proxies are allowed to > change the Request-Line in transit. I'd change the citation to "(Section 5.5 of [RFC7230])". Also change "from request-target of the Request-Line" to "of the HTTP request". Finally, "Request-Line" has been lowercased in 7230. Maybe say: "...to change the "request target ("request-target", Section 3.1.1 of [RFC7230]) in transit". > qop > Indicates what "quality of protection" the client has applied to > the message. Its value MUST be one of the alternatives the server > indicated it supports in the WWW-Authenticate header field. These > values affect the computation of the response. Note that this is a > single token, not a quoted list of alternatives as in WWW- > Authenticate. > > Can it use quoted-string nevertheless? ? > 3.4.6 Various Considerations > > The "Method" value is the HTTP request method, in all-uppercase US- > ASCII letters, as specified in section 3.1.1 of [RFC7230]. The > > Hm, no. The registered methods happen to be all-uppercase, but method > names are case-sensitive. > > Implementers should be aware of how authenticated transactions > > ...need to be... > > interact with shared caches. The HTTP/1.1 protocol specifies that > > s/The HTTP/1.1 protocol/HTTP/ Still says "HTTP protocol". The "P" in "HTTP" however already stands for "Protocol". > when a shared cache (see [RFC7234]) has received a request containing > an Authorization header field and a response from relaying that > request, it MUST NOT return that response as a reply to any other > request, unless one of two Cache-Control (see section 3.2 of > [RFC7234]) directive was present in the response. If the original > response included the "must-revalidate" Cache-Control directive, the > cache MAY use the entity of that response in replying to a subsequent > request, but MUST first revalidate it with the origin server, using > the request header fields from the new request to allow the origin > server to authenticate the new request. Alternatively, if the > original response included the "public" Cache-Control directive, the > response entity MAY be returned in reply to any subsequent request. > > Do we need to replicate this information here? (Asking because the Basic > spec does not) This test is still here. > 3.5 The Authentication-Info Header > > The Authentication-Info header field is a generic field that MAY be > used by a server to communicate some information regarding the > successful authentication of a client response. The following is the > syntax of the header: > > Authentication-Info = auth-info > > auth-info = *auth-param > > This needs to be "#auth-param" and invoke the list ABNF extension from > RFC 7230. > > The auth-param is defined in [RFC7235]. > > (I still believe we should extract this into a separate spec) See . > information. (Note that any such use can also be accomplished more > easily and safely by including the state in the nonce.) For example, > a server could be responsible for authenticating content that > actually sits on another server. It would achieve this by having the > first 401 response include a domain parameter whose value includes a > URI on the second server, and an opaque parameter whose value > contains the state information. The client will retry the request, at > which time the server might respond with a 301/302 redirection, > > Do not exclude 307/308. Just say "HTTP Redirection (Section 6.4 of > [RFC7231])" Now says: > at which time the server might respond with "HTTP Redirection > (Section 6.4 of [RFC7231]), pointing to the URI on the second server. (double quote missing) > When the client receives the response it SHOULD use the topmost > header field that it supports, unless a local policy dictates > > First challenge. Now reads: > When the client receives the first challenge it SHOULD use the > topmost header field that it supports, unless a local policy dictates > otherwise. The client MUST ignore any challenge it does not > understand. I believe this should be: "when the client received the response it SHOULD use the first challenge that it supports..." > otherwise. The client SHOULD ignore any challenge it does not > understand. > > MUST, I believe. > > Also, this sounds like requirements that are generic to WWW-A, not > specific to Digest, no? Again, this is something we should discuss? It IMHO does not belong here; this spec should not make any normative statements about how the framework works. > 5.6 Weakness Created by Multiple Authentication Schemes > > An HTTP/1.1 server MAY return multiple challenges with a 401 > (Authenticate) response, and each challenge MAY use a different auth- > scheme. A user agent MUST choose to use the strongest auth- scheme it > > s/auth- scheme/auth-scheme/ Still there. > ... Best regards, Julian From nobody Sun Jan 25 07:34:15 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C311A1A87 for ; Sun, 25 Jan 2015 07:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, 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 E4FJsCC_AokV for ; Sun, 25 Jan 2015 07:34:09 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E516B1A1A83 for ; Sun, 25 Jan 2015 07:34:08 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id gf13so4267286lab.8 for ; Sun, 25 Jan 2015 07:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rp+tOvy3K1zRpSEPFIy8rFh2Un5d86bjyj5VqNsWWiw=; b=HbQyoZlk5l6E7kjkGUapPeudHeqT5o4muw/NPnByt0zBInYL2t7CFDlYYcJE2oH4t9 XldK2N0ruJh4xi6pJoFqxMh+/uds0hWeWPVX093prmDyMK07u8OGmJ8R8y+HuzuSFIbF g2pn/+6elhQc0SJudEzMXWX4HepyICKcQmJVf66Uhy++sKdLFzLFAtv9f4PsQTA85Oua 1CXYPpkneq9eljWsvJKDliSLpwjGrNl8j443nD/H5F7EQhtpqe0NwCQiUowewuVDhoL9 HMMBh+AX9vN6/qrywBJIPSuQnrd0NDficX+sbnUGefysxPPn6IevacXfn5LxSUaT2tIa 7KGg== MIME-Version: 1.0 X-Received: by 10.112.235.67 with SMTP id uk3mr16983205lbc.48.1422200047428; Sun, 25 Jan 2015 07:34:07 -0800 (PST) Received: by 10.114.27.162 with HTTP; Sun, 25 Jan 2015 07:34:07 -0800 (PST) In-Reply-To: <54C4F56C.1080102@gmx.de> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> <54C4F56C.1080102@gmx.de> Date: Sun, 25 Jan 2015 10:34:07 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c3135ea06875050d7bc0e0 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.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: Sun, 25 Jan 2015 15:34:13 -0000 --001a11c3135ea06875050d7bc0e0 Content-Type: text/plain; charset=ISO-8859-1 Inline... On Sun, Jan 25, 2015 at 8:53 AM, Julian Reschke wrote: > Hi there, > > I'm looking at httpauth-digest-12.txt&url1=draft-ietf-httpauth-digest-09.txt> and how > the feedback below was addressed...: > > On 2014-12-14 17:26, Julian Reschke wrote: > >> ... >> prefix (after both have been made absolute) may be assumed to be >> in the same protection space. If this parameter is omitted or its >> value is empty, the client SHOULD assume that the protection space >> consists of all URIs on the web-origin. All URIs in this list >> SHOULD use the same scheme (https or http); mixing them is a bad >> idea. >> >> web_origin and canonical root need definitions. >> ... >> > > > This now reads: > > A quoted, space-separated list of URIs, as specified in [RFC3986], >> that define the protection space. If a URI is an abs_path, it is >> relative to the canonical root URL (See Section 2.2 of [RFC7235]) >> of the web-origin [RFC6454]. An absolute-URI in this list may >> refer to a different server than the web-origin. The client can >> > > It's still not clear to me why we need both "canonical root URL" *and* > web-origin here. Can you explain? > After reading the definition of canonical root URL, it seems that the mentioned of web-origin is somewhat redundant; I will remove that web-origin. > > Also: > > Why is mixing them a "bad idea"? - maybe this could be explained better. >> > > This text is still here. > As I mentioned before, this text was copied from RFC2617, and I am not sure why this was considered to be a bad idea, and nobody could provide an explanation. Should I remove that text? > > ... >> stale >> A case-insensitive flag indicating that the previous request from >> the client was rejected because the nonce value was stale. If >> stale is TRUE, the client MAY wish to simply retry the request >> >> "MAY wish" doesn't seem like a case for a BCP14 keyword. >> > > This now says "may wish"; please avoid lowercase BCP14 keywords. Maybe > "might wish"? > > 3.4 The Authorization Request Header >> >> s/header/header field/ >> > > There are still cases where the spec just says "header". > ok > > ... >> uri >> The URI from request-target of the Request-Line; duplicated here >> because proxies are allowed to change the Request-Line in transit. >> >> The request-target of the Request-Line isn't necessarily a URI... >> ... >> > > This now says: > > The Effective Request URI [RFC7230] from request-target of the >> Request-Line; duplicated here because proxies are allowed to >> change the Request-Line in transit. >> > > I'd change the citation to "(Section 5.5 of [RFC7230])". Also change "from > request-target of the Request-Line" to "of the HTTP request". Finally, > "Request-Line" has been lowercased in 7230. Maybe say: "...to change the > "request target ("request-target", Section 3.1.1 of [RFC7230]) in transit". > > ok > qop >> Indicates what "quality of protection" the client has applied to >> the message. Its value MUST be one of the alternatives the server >> indicated it supports in the WWW-Authenticate header field. These >> values affect the computation of the response. Note that this is a >> single token, not a quoted list of alternatives as in WWW- >> Authenticate. >> >> Can it use quoted-string nevertheless? >> > > ? > No; for backward compatibility. > 3.4.6 Various Considerations >> >> The "Method" value is the HTTP request method, in all-uppercase US- >> ASCII letters, as specified in section 3.1.1 of [RFC7230]. The >> >> Hm, no. The registered methods happen to be all-uppercase, but method >> names are case-sensitive. >> >> Implementers should be aware of how authenticated transactions >> >> ...need to be... >> >> interact with shared caches. The HTTP/1.1 protocol specifies that >> >> s/The HTTP/1.1 protocol/HTTP/ >> > > Still says "HTTP protocol". The "P" in "HTTP" however already stands for > "Protocol". ok > > > when a shared cache (see [RFC7234]) has received a request containing >> an Authorization header field and a response from relaying that >> request, it MUST NOT return that response as a reply to any other >> request, unless one of two Cache-Control (see section 3.2 of >> [RFC7234]) directive was present in the response. If the original >> response included the "must-revalidate" Cache-Control directive, the >> cache MAY use the entity of that response in replying to a subsequent >> request, but MUST first revalidate it with the origin server, using >> the request header fields from the new request to allow the origin >> server to authenticate the new request. Alternatively, if the >> original response included the "public" Cache-Control directive, the >> response entity MAY be returned in reply to any subsequent request. >> >> Do we need to replicate this information here? (Asking because the Basic >> spec does not) >> > > This test is still here. I will remove it. > > > 3.5 The Authentication-Info Header >> >> The Authentication-Info header field is a generic field that MAY be >> used by a server to communicate some information regarding the >> successful authentication of a client response. The following is the >> syntax of the header: >> >> Authentication-Info = auth-info >> >> auth-info = *auth-param >> >> This needs to be "#auth-param" and invoke the list ABNF extension from >> RFC 7230. >> >> The auth-param is defined in [RFC7235]. >> >> (I still believe we should extract this into a separate spec) >> > > See . I see the value of the new draft, but I am worried about about the delay the new draft might cause to this document. It is up to the WG to make a decision on how they want to proceed with this. > > > information. (Note that any such use can also be accomplished more >> easily and safely by including the state in the nonce.) For example, >> a server could be responsible for authenticating content that >> actually sits on another server. It would achieve this by having the >> first 401 response include a domain parameter whose value includes a >> URI on the second server, and an opaque parameter whose value >> contains the state information. The client will retry the request, at >> which time the server might respond with a 301/302 redirection, >> >> Do not exclude 307/308. Just say "HTTP Redirection (Section 6.4 of >> [RFC7231])" >> > > Now says: > > at which time the server might respond with "HTTP Redirection >> (Section 6.4 of [RFC7231]), pointing to the URI on the second server. >> > > (double quote missing) ok > > > When the client receives the response it SHOULD use the topmost >> header field that it supports, unless a local policy dictates >> >> First challenge. >> > > Now reads: > > When the client receives the first challenge it SHOULD use the >> topmost header field that it supports, unless a local policy dictates >> otherwise. The client MUST ignore any challenge it does not >> understand. >> > > I believe this should be: "when the client received the response it SHOULD > use the first challenge that it supports..." ok > > > otherwise. The client SHOULD ignore any challenge it does not >> understand. >> >> MUST, I believe. >> >> Also, this sounds like requirements that are generic to WWW-A, not >> specific to Digest, no? >> > > Again, this is something we should discuss? It IMHO does not belong here; > this spec should not make any normative statements about how the framework > works. > > I could not find any mention of this in the framework document; can you point to where it is mentioned? > 5.6 Weakness Created by Multiple Authentication Schemes >> >> An HTTP/1.1 server MAY return multiple challenges with a 401 >> (Authenticate) response, and each challenge MAY use a different auth- >> scheme. A user agent MUST choose to use the strongest auth- scheme it >> >> s/auth- scheme/auth-scheme/ >> > > ok Thanks, Rifaat > Still there. > > ... >> > > Best regards, Julian > > --001a11c3135ea06875050d7bc0e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline...

On Sun, Jan 25, 2015 at 8:53 AM, Julian Reschke = <julian.resch= ke@gmx.de> wrote:
Hi there,

I'm looking at <https://trac.tools.ietf.org/rfcdiff?url2= =3Ddraft-ietf-httpauth-digest-12.txt&url1=3Ddraft-ietf-ht= tpauth-digest-09.txt> and how the feedback below was addresse= d...:

On 2014-12-14 17:26, Julian Reschke wrote:
...
=A0 =A0 =A0 =A0prefix (after both have been made absolute) may be assumed t= o be
=A0 =A0 =A0 =A0in the same protection space. If this parameter is omitted o= r its
=A0 =A0 =A0 =A0value is empty, the client SHOULD assume that the protection= space
=A0 =A0 =A0 =A0consists of all URIs on the web-origin. All URIs in this lis= t
=A0 =A0 =A0 =A0SHOULD use the same scheme (https or http); mixing them is a= bad
=A0 =A0 =A0 =A0idea.

web_origin and canonical root need definitions.
 ...


This now reads:

=A0 =A0 =A0 A quoted, space-separated list of URIs, as specified in [RFC398= 6],
=A0 =A0 =A0 that define the protection space.=A0 If a URI is an abs_path, i= t is
 =A0 =A0 =A0 relative to the canonical root URL (See Section 2.2 of [RFC7235= ])
=A0 =A0 =A0 of the web-origin [RFC6454].=A0 An absolute-URI in this list ma= y
=A0 =A0 =A0 refer to a different server than the web-origin.=A0 The client = can

It's still not clear to me why we need both "canonical root URL&qu= ot; *and* web-origin here. Can you explain?

=
After reading the definition of canonical root URL, it seems that the = mentioned of web-origin is somewhat redundant; I will remove that web-origi= n.

=A0

Also:

Why is mixing them a "bad idea"? - maybe this could be explained = better.

 This text is still here.

As I mentioned= before, this text was copied from RFC2617, and I am not sure why this was = considered to be a bad idea, and nobody could provide an explanation.
=

Should I remove that text?


=A0

...
=A0 =A0 stale
=A0 =A0 =A0 =A0A case-insensitive flag indicating that the previous request= from
=A0 =A0 =A0 =A0the client was rejected because the nonce value was stale. I= f
=A0 =A0 =A0 =A0stale is TRUE, the client MAY wish to simply retry the reque= st

"MAY wish" doesn't seem like a case for a BCP14 keyword.

This now says "may wish"; please avoid lowercase BCP14 keywords. = Maybe "might wish"?

3.4 The Authorization Request Header

s/header/header field/

 There are still cases where the spec just says "header".

ok

=A0

...
=A0 =A0 uri
=A0 =A0 =A0 =A0The URI from request-target of the Request-Line; duplicated = here
=A0 =A0 =A0 =A0because proxies are allowed to change the Request-Line in tr= ansit.

The request-target of the Request-Line isn't necessarily a URI...
...

This now says:

=A0 =A0 =A0 The Effective Request URI [RFC7230] from request-target of the<= span class=3D"">
=A0 =A0 =A0 Request-Line; duplicated here because proxies are allowed to =A0 =A0 =A0 change the Request-Line in transit.

I'd change the citation to "(Section 5.5 of [RFC7230])". Also= change "from request-target of the Request-Line" to "of the= HTTP request". Finally, "Request-Line" has been lowercased = in 7230. Maybe say: "...to change the "request target ("requ= est-target", Section 3.1.1 of [RFC7230]) in transit".

ok

=A0
=A0 =A0 qop
=A0 =A0 =A0 =A0Indicates what "quality of protection" the client = has applied to
=A0 =A0 =A0 =A0the message. Its value MUST be one of the alternatives the s= erver
=A0 =A0 =A0 =A0indicated it supports in the WWW-Authenticate header field. = These
=A0 =A0 =A0 =A0values affect the computation of the response. Note that thi= s is a
=A0 =A0 =A0 =A0single token, not a quoted list of alternatives as in WWW- =A0 =A0 =A0 =A0Authenticate.

Can it use quoted-string nevertheless?

 ?
=A0
No; for backward compatibility.=

=A0
3.4.6 Various Considerations

=A0 =A0 The "Method" value is the HTTP request method, in all-upp= ercase US-
=A0 =A0 ASCII letters, as specified in section 3.1.1 of [RFC7230]. The

Hm, no. The registered methods happen to be all-uppercase, but method
names are case-sensitive.

=A0 =A0 Implementers should be aware of how authenticated transactions

...need to be...

=A0 =A0 interact with shared caches. The HTTP/1.1 protocol specifies that
s/The HTTP/1.1 protocol/HTTP/

 Still says "HTTP protocol". The "P" in "HTTP"= however already stands for "Protocol".

ok

=A0


=A0 =A0 when a shared cache (see [RFC7234]) has received a request containi= ng
=A0 =A0 an Authorization header field and a response from relaying that
=A0 =A0 request, it MUST NOT return that response as a reply to any other =A0 =A0 request, unless one of two Cache-Control (see section 3.2 of
=A0 =A0 [RFC7234]) directive was present in the response. If the original =A0 =A0 response included the "must-revalidate" Cache-Control dir= ective, the
=A0 =A0 cache MAY use the entity of that response in replying to a subseque= nt
=A0 =A0 request, but MUST first revalidate it with the origin server, using=
=A0 =A0 the request header fields from the new request to allow the origin<= br> =A0 =A0 server to authenticate the new request. Alternatively, if the
=A0 =A0 original response included the "public" Cache-Control dir= ective, the
=A0 =A0 response entity MAY be returned in reply to any subsequent request.=

Do we need to replicate this information here? (Asking because the Basic spec does not)

 This test is still here.

I will remove it.<= /div>

=A0

3.5 The Authentication-Info Header

=A0 =A0 The Authentication-Info header field is a generic field that MAY be=
=A0 =A0 used by a server to communicate some information regarding the
=A0 =A0 successful authentication of a client response. The following is th= e
=A0 =A0 syntax of the header:

=A0 =A0 =A0 =A0 =A0 =A0 Authentication-Info =3D auth-info

=A0 =A0 =A0 =A0 =A0 =A0 auth-info =3D *auth-param

This needs to be "#auth-param" and invoke the list ABNF extension= from
RFC 7230.

=A0 =A0 The auth-param is defined in [RFC7235].

(I still believe we should extract this into a separate spec)

 See <https://tools.ietf.org/html/draft-reschke= -httpauth-auth-info-00>.

I se= e the value of the new draft, but I am worried about about the delay the ne= w draft might cause to this document.
It is up to the WG to make = a decision on how they want to proceed with this.

= =A0


=A0 =A0 information. (Note that any such use can also be accomplished more<= br> =A0 =A0 easily and safely by including the state in the nonce.) For example= ,
=A0 =A0 a server could be responsible for authenticating content that
=A0 =A0 actually sits on another server. It would achieve this by having th= e
=A0 =A0 first 401 response include a domain parameter whose value includes = a
=A0 =A0 URI on the second server, and an opaque parameter whose value
=A0 =A0 contains the state information. The client will retry the request, = at
=A0 =A0 which time the server might respond with a 301/302 redirection,

Do not exclude 307/308. Just say "HTTP Redirection (Section 6.4 of
[RFC7231])"

 Now says:

=A0 =A0at which time the server might respond with "HTTP Redirection =A0 =A0(Section 6.4 of [RFC7231]), pointing to the URI on the second server= .

(double quote missing)

ok
=A0


=A0 =A0 When the client receives the response it SHOULD use the topmost
=A0 =A0 header field that it supports, unless a local policy dictates

First challenge.

 Now reads:

=A0 =A0When the client receives the first challenge it SHOULD use the
=A0 =A0topmost header field that it supports, unless a local policy dictate= s
 =A0 =A0otherwise.=A0 The client MUST ignore any challenge it does not
=A0 =A0understand.

I believe this should be: "when the client received the response it SH= OULD use the first challenge that it supports..."
ok

=A0


=A0 =A0 otherwise. The client SHOULD ignore any challenge it does not
=A0 =A0 understand.

MUST, I believe.

Also, this sounds like requirements that are generic to WWW-A, not
specific to Digest, no?

 Again, this is something we should discuss? It IMHO does not belong here; t= his spec should not make any normative statements about how the framework w= orks.


I could not find any mention of= this in the framework document; can you point to where it is mentioned?

=A0
5.6 Weakness Created by Multiple Authentication Schemes

=A0 =A0 An HTTP/1.1 server MAY return multiple challenges with a 401
=A0 =A0 (Authenticate) response, and each challenge MAY use a different aut= h-
=A0 =A0 scheme. A user agent MUST choose to use the strongest auth- scheme = it

s/auth- scheme/auth-scheme/


ok

Thanks,
=A0Rifaat

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> Still there.

...

Best regards, Julian


--001a11c3135ea06875050d7bc0e0-- From nobody Sun Jan 25 08:08:42 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B591A1AB0 for ; Sun, 25 Jan 2015 08:08:40 -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 LUfDWc4TLCrd for ; Sun, 25 Jan 2015 08:08:38 -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 36CE61A01FA for ; Sun, 25 Jan 2015 08:08:38 -0800 (PST) Received: from [192.168.2.175] ([93.217.81.131]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MGXV6-1YSdAC0adk-00DKYE; Sun, 25 Jan 2015 17:08:36 +0100 Message-ID: <54C51502.6020008@gmx.de> Date: Sun, 25 Jan 2015 17:08:34 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> <54C4F56C.1080102@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8aB9G9o/03OEd7NjoMOUBC/6LndVGyuhnEGBq0GnQaMnc4fmL8b J2bUQ6E74mnOcmC4H53PvaaraOEqG+h923qXqnO4F7qPuuAGULALfTfe9qy70LRvTZSpkRs d3Fkc5IRLWKyBsh5aIp0DzUGL40uSnF3jA/3YBxBQy8E8M+jzjljRx4FGG/BurWP9H7AUXc tcOTFhUJQH11Dli483Jkg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.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: Sun, 25 Jan 2015 16:08:41 -0000 On 2015-01-25 16:34, Rifaat Shekh-Yusef wrote: > Inline... > ... > It's still not clear to me why we need both "canonical root URL" > *and* web-origin here. Can you explain? > > > After reading the definition of canonical root URL, it seems that the > mentioned of web-origin is somewhat redundant; I will remove that > web-origin. Exactly. Thanks a lot! > > > Also: > > Why is mixing them a "bad idea"? - maybe this could be explained > better. > > > This text is still here. > > > As I mentioned before, this text was copied from RFC2617, and I am not > sure why this was considered to be a bad idea, and nobody could provide > an explanation. I can't see in in 2617. > Should I remove that text? If we don't know what it's about, then yes :-) > ... > qop > Indicates what "quality of protection" the client has > applied to > the message. Its value MUST be one of the alternatives > the server > indicated it supports in the WWW-Authenticate header > field. These > values affect the computation of the response. Note that > this is a > single token, not a quoted list of alternatives as in WWW- > Authenticate. > > Can it use quoted-string nevertheless? > > > ? > > No; for backward compatibility. Then please say that more clearly. > > 3.5 The Authentication-Info Header > > The Authentication-Info header field is a generic field > that MAY be > used by a server to communicate some information regarding the > successful authentication of a client response. The > following is the > syntax of the header: > > Authentication-Info = auth-info > > auth-info = *auth-param > > This needs to be "#auth-param" and invoke the list ABNF > extension from > RFC 7230. > > The auth-param is defined in [RFC7235]. > > (I still believe we should extract this into a separate spec) > > > See > >. > > > I see the value of the new draft, but I am worried about about the delay > the new draft might cause to this document. > It is up to the WG to make a decision on how they want to proceed with this. Indeed. If it decides not to, you may want to steal some text from my draft. > otherwise. The client SHOULD ignore any challenge it does not > understand. > > MUST, I believe. > > Also, this sounds like requirements that are generic to WWW-A, not > specific to Digest, no? > > > Again, this is something we should discuss? It IMHO does not belong > here; this spec should not make any normative statements about how > the framework works. > > > I could not find any mention of this in the framework document; can you > point to where it is mentioned? : "Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the user as appropriate. Transmission of credentials within header field values implies significant security considerations regarding the confidentiality of the underlying connection, as described in Section 6.1." > ... Best regards, Julian From nobody Sun Jan 25 09:34:32 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EC91A871E for ; Sun, 25 Jan 2015 09:34:30 -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 7ciIQQGCNLkt for ; Sun, 25 Jan 2015 09:34:27 -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 B538E1A7034 for ; Sun, 25 Jan 2015 09:34:26 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ge10so4527346lab.10 for ; Sun, 25 Jan 2015 09:34:24 -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=RdQ4J+wSCNuoBlMRbJFvk42DsoG1o62BxIec6LyM8yc=; b=nTK1OgwBCQ0oj4WXuTPSX67RdnbOY9Jqrl6m0J+1MHmcMKu5ngrav0xuOAVMnPEZMD 7bFWUpm4kHYYEyFa7WscbVzxQ35vnIpDsHtoCsjOPdXjDBDaipNGXvOML8NRk/Lfe5D2 1AmQr96xUaaHsD9F7TOAwAFrMSCdvBl6UMmK6V+ibdhx2HB9bbf6W0GyzAF7s8g5CwRO xqH6Zbe2dYLCWcsgYVWL9gOvHqRoTOWi+nLB1eU8W2xSpUTgXkKjw2Qu4obO4UoYg7wA WfpLixuJwYhb+eRdOG4G/UBqiO88H63NuNuOJbsTQOfoXnLj/vaA2lrRcNpb2/C/ArQH OwSw== MIME-Version: 1.0 X-Received: by 10.112.142.201 with SMTP id ry9mr17533095lbb.4.1422207264559; Sun, 25 Jan 2015 09:34:24 -0800 (PST) Received: by 10.114.27.162 with HTTP; Sun, 25 Jan 2015 09:34:24 -0800 (PST) In-Reply-To: <54C51502.6020008@gmx.de> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> <54C4F56C.1080102@gmx.de> <54C51502.6020008@gmx.de> Date: Sun, 25 Jan 2015 12:34:24 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke , Stephen Farrell Content-Type: multipart/alternative; boundary=089e011836aacd190f050d7d6e85 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.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: Sun, 25 Jan 2015 17:34:30 -0000 --089e011836aacd190f050d7d6e85 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 25, 2015 at 11:08 AM, Julian Reschke wrote: > On 2015-01-25 16:34, Rifaat Shekh-Yusef wrote: > >> Inline... >> ... >> It's still not clear to me why we need both "canonical root URL" >> *and* web-origin here. Can you explain? >> >> >> After reading the definition of canonical root URL, it seems that the >> mentioned of web-origin is somewhat redundant; I will remove that >> web-origin. >> > > Exactly. Thanks a lot! > > >> >> Also: >> >> Why is mixing them a "bad idea"? - maybe this could be explained >> better. >> >> >> This text is still here. >> >> >> As I mentioned before, this text was copied from RFC2617, and I am not >> sure why this was considered to be a bad idea, and nobody could provide >> an explanation. >> > > I can't see in in 2617. > > Sorry; it was based on a feedback from Stephen Farrell: http://www.ietf.org/mail-archive/web/http-auth/current/msg01933.html *Stephen,* Can you please elaborate on your comment above? > Should I remove that text? >> > > If we don't know what it's about, then yes :-) > > ... >> qop >> Indicates what "quality of protection" the client has >> applied to >> the message. Its value MUST be one of the alternatives >> the server >> indicated it supports in the WWW-Authenticate header >> field. These >> values affect the computation of the response. Note that >> this is a >> single token, not a quoted list of alternatives as in WWW- >> Authenticate. >> >> Can it use quoted-string nevertheless? >> >> >> ? >> >> No; for backward compatibility. >> > > Then please say that more clearly. > It is already stated in section 3.4: " For historical reasons, a sender MUST NOT generate the quoted-string syntax for the following parameters: algorithm, qop, and nc." > >> 3.5 The Authentication-Info Header >> >> The Authentication-Info header field is a generic field >> that MAY be >> used by a server to communicate some information regarding >> the >> successful authentication of a client response. The >> following is the >> syntax of the header: >> >> Authentication-Info = auth-info >> >> auth-info = *auth-param >> >> This needs to be "#auth-param" and invoke the list ABNF >> extension from >> RFC 7230. >> >> The auth-param is defined in [RFC7235]. >> >> (I still believe we should extract this into a separate spec) >> >> >> See >> > >. >> >> >> I see the value of the new draft, but I am worried about about the delay >> the new draft might cause to this document. >> It is up to the WG to make a decision on how they want to proceed with >> this. >> > > Indeed. > > If it decides not to, you may want to steal some text from my draft. Sure. > > > otherwise. The client SHOULD ignore any challenge it does not >> understand. >> >> MUST, I believe. >> >> Also, this sounds like requirements that are generic to WWW-A, not >> specific to Digest, no? >> >> >> Again, this is something we should discuss? It IMHO does not belong >> here; this spec should not make any normative statements about how >> the framework works. >> >> >> I could not find any mention of this in the framework document; can you >> point to where it is mentioned? >> > > : > > "Both the Authorization field value and the Proxy-Authorization field > value contain the client's credentials for the realm of the resource being > requested, based upon a challenge received in a response (possibly at some > point in the past). When creating their values, the user agent ought to do > so by selecting the challenge with what it considers to be the most secure > auth-scheme that it understands, obtaining credentials from the user as > appropriate. Transmission of credentials within header field values implies > significant security considerations regarding the confidentiality of the > underlying connection, as described in Section 6.1." > > Although it is only implied, I think it is good enough; I will remove this text from my draft. Regards, Rifaat > ... >> > > > Best regards, Julian > --089e011836aacd190f050d7d6e85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 25, 2015 at 11:08 AM, Julian Reschke <= julian.reschke@g= mx.de> wrote:
On 2015-01-25 16:34, Rifaat= Shekh-Yusef wrote:
Inline...
...
=A0 =A0 It's still not clear to me why we need both "canonical roo= t URL"
=A0 =A0 *and* web-origin here. Can you explain?


After reading the definition of canonical root URL, it seems that the
mentioned of web-origin is somewhat redundant; I will remove that
web-origin.

Exactly. Thanks a lot!



=A0 =A0 Also:

=A0 =A0 =A0 =A0 Why is mixing them a "bad idea"? - maybe this cou= ld be explained
=A0 =A0 =A0 =A0 better.


=A0 =A0 This text is still here.


As I mentioned before, this text was copied from RFC2617, and I am not
sure why this was considered to be a bad idea, and nobody could provide
an explanation.

 I can't see in in 2617.


Sorry; it was based on a feedba= ck from Stephen Farrell:


Stephen,

Can you please elaborate o= n your comment above?


=A0
Should I remove that text?

 If we don't know what it's about, then yes :-)

...
=A0 =A0 =A0 =A0 =A0 =A0 =A0qop
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Indicates what "quality of protection&= quot; the client has
=A0 =A0 =A0 =A0 applied to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the message. Its value MUST be one of the a= lternatives
=A0 =A0 =A0 =A0 the server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 indicated it supports in the WWW-Authentica= te header
=A0 =A0 =A0 =A0 field. These
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 values affect the computation of the respon= se. Note that
=A0 =A0 =A0 =A0 this is a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 single token, not a quoted list of alternat= ives as in WWW-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Authenticate.

=A0 =A0 =A0 =A0 Can it use quoted-string nevertheless?


=A0 =A0 ?

No; for backward compatibility.

Then please say that more clearly.

It i= s already stated in section 3.4:

" For historical reas= ons, a sender MUST NOT generate the quoted-string
=A0 =A0syntax for= the following parameters: algorithm, qop, and nc."=A0

=A0

=A0 =A0 =A0 =A0 3.5 The Authentication-Info Header

=A0 =A0 =A0 =A0 =A0 =A0 =A0The Authentication-Info header field is a generi= c field
=A0 =A0 =A0 =A0 that MAY be
=A0 =A0 =A0 =A0 =A0 =A0 =A0used by a server to communicate some information= regarding the
=A0 =A0 =A0 =A0 =A0 =A0 =A0successful authentication of a client response. = The
=A0 =A0 =A0 =A0 following is the
=A0 =A0 =A0 =A0 =A0 =A0 =A0syntax of the header:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Authentication-Info =3D auth-inf= o

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0auth-info =3D *auth-param

=A0 =A0 =A0 =A0 This needs to be "#auth-param" and invoke the lis= t ABNF
=A0 =A0 =A0 =A0 extension from
=A0 =A0 =A0 =A0 RFC 7230.

=A0 =A0 =A0 =A0 =A0 =A0 =A0The auth-param is defined in [RFC7235].

=A0 =A0 =A0 =A0 (I still believe we should extract this into a separate spe= c)


=A0 =A0 See
 =A0 =A0 <https://tools.ietf.org/html/__dra= ft-reschke-httpauth-auth-__info-00
=A0 =A0 <https://tools.ietf.org/html/draft-res= chke-httpauth-auth-info-00>>.


I see the value of the new draft, but I am worried about about the delay the new draft might cause to this document.
It is up to the WG to make a decision on how they want to proceed with this= .

Indeed.

If it decides not to, you may want to steal some text from my draft.

Sure.

=A0


=A0 =A0 =A0 =A0 =A0 =A0 =A0otherwise. The client SHOULD ignore any challeng= e it does not
=A0 =A0 =A0 =A0 =A0 =A0 =A0understand.

=A0 =A0 =A0 =A0 MUST, I believe.

=A0 =A0 =A0 =A0 Also, this sounds like requirements that are generic to WWW= -A, not
=A0 =A0 =A0 =A0 specific to Digest, no?


=A0 =A0 Again, this is something we should discuss? It IMHO does not belong=
=A0 =A0 here; this spec should not make any normative statements about how<= br> =A0 =A0 the framework works.


I could not find any mention of this in the framework document; can you
point to where it is mentioned?

 <http://greenbytes.de/tech/webdav/rfc7235.ht= ml#rfc.section.2.1.p.9>:

"Both the Authorization field value and the Proxy-Authorization field = value contain the client's credentials for the realm of the resource be= ing requested, based upon a challenge received in a response (possibly at s= ome point in the past). When creating their values, the user agent ought to= do so by selecting the challenge with what it considers to be the most sec= ure auth-scheme that it understands, obtaining credentials from the user as= appropriate. Transmission of credentials within header field values implie= s significant security considerations regarding the confidentiality of the = underlying connection, as described in Section 6.1."


Although it is only implied, I think i= t is good enough; I will remove this text from my draft.

Regards,
=A0Rifaat


=A0
...


Best regards, Julian

--089e011836aacd190f050d7d6e85-- From nobody Sun Jan 25 15:03:45 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132DA1A00DB for ; Sun, 25 Jan 2015 15:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcbWDkFLN-3V for ; Sun, 25 Jan 2015 15:03:42 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7111A000D for ; Sun, 25 Jan 2015 15:03:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6E6A3BEA4; Sun, 25 Jan 2015 23:03:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67U1fv4E3Gqk; Sun, 25 Jan 2015 23:03:38 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.18.232]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 64002BE9F; Sun, 25 Jan 2015 23:03:38 +0000 (GMT) Message-ID: <54C5764B.1060308@cs.tcd.ie> Date: Sun, 25 Jan 2015 23:03:39 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , Julian Reschke References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> <54C4F56C.1080102@gmx.de> <54C51502.6020008@gmx.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.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: Sun, 25 Jan 2015 23:03:44 -0000 On 25/01/15 17:34, Rifaat Shekh-Yusef wrote: > *Stephen,* > > Can you please elaborate on your comment above? I didn't check much (can do tomorrow if it helps) but I think the issue was a list that mixed http and https schemed URIs would mean that a dictionary attackable authentication scheme was sometimes being used over TLS and sometimes not, which I think is a bad plan. S. From nobody Sun Jan 25 22:47:17 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C853C1A1EFF for ; Sun, 25 Jan 2015 22:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpHDkhq06Atf for ; Sun, 25 Jan 2015 22:47:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C3C1A1A5B for ; Sun, 25 Jan 2015 22:47:12 -0800 (PST) Received: from [192.168.2.175] ([93.217.81.131]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M2c1V-1XNGJG1yFx-00sRKY; Mon, 26 Jan 2015 07:47:03 +0100 Message-ID: <54C5E2E3.10202@gmx.de> Date: Mon, 26 Jan 2015 07:46:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Farrell , Rifaat Shekh-Yusef References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> <54C4F56C.1080102@gmx.de> <54C51502.6020008@gmx.de> <54C5764B.1060308@cs.tcd.ie> In-Reply-To: <54C5764B.1060308@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uZmX1SI6iQnnKxOLqy4c5HmggYhTuI3ppb7aStYh/KP0KRKJnBa E4RvJb366V2cIj3BDxyt6p8gLptWRkWPgTv4+bvzpggcCvBF4GmunKBP7XKnyAlNznnrKBy qf0kUpWm3U5e3qZ4QpDLQt/Xhu+Y0355kcrrS2EH3bRxfJJJ6K32RN+kupqQaeUxtSy4eld A/xVEA03XjZj1QbcsDbug== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 06:47:14 -0000 On 2015-01-26 00:03, Stephen Farrell wrote: > > On 25/01/15 17:34, Rifaat Shekh-Yusef wrote: >> *Stephen,* >> >> Can you please elaborate on your comment above? > > I didn't check much (can do tomorrow if it helps) but I think > the issue was a list that mixed http and https schemed URIs > would mean that a dictionary attackable authentication scheme > was sometimes being used over TLS and sometimes not, which I > think is a bad plan. Well, if there is a concern, it needs more explanation. Best regards, Julian From nobody Mon Jan 26 11:14:22 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272F01ACE9E for ; Mon, 26 Jan 2015 11:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFtMfFWPAZb0 for ; Mon, 26 Jan 2015 11:14:19 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181751ACEA7 for ; Mon, 26 Jan 2015 11:14:18 -0800 (PST) X-AuditID: 12074425-f798e6d000000d1a-cc-54c69209c212 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 06.DE.03354.90296C45; Mon, 26 Jan 2015 14:14:17 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t0QJEHU6014599; Mon, 26 Jan 2015 14:14:17 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t0QJEFtm005452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jan 2015 14:14:16 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t0QJEF8h010454; Mon, 26 Jan 2015 14:14:15 -0500 (EST) Date: Mon, 26 Jan 2015 14:14:14 -0500 (EST) From: Benjamin Kaduk To: Julian Reschke In-Reply-To: <54C3EE0D.2080506@gmx.de> Message-ID: References: <20150124190127.3801.31394.idtracker@ietfa.amsl.com> <54C3EE0D.2080506@gmx.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrcs56ViIwYVeM4sP++cwWWx++IbV gcnjw8c4jyVLfjIFMEVx2aSk5mSWpRbp2yVwZZxb8py14Ahrxfa/OxgbGHezdDFycEgImEjM 2m3dxcgJZIpJXLi3nq2LkYtDSGAxk8TiQ/eYIJyNjBIvr+9hgXAOMUl0t8yHyjQwSiydcpER pJ9FQFvix4vtrCA2m4CKxMw3G9lAbBEBLYnb9/aC1TAL6Eo8P9QOZgsLpEh8P/UVrIZTQE3i 1dZjLCA2r4CjxJs7y5lBbCGBKImlLxaA1YsK6Eis3j8FqkZQ4uTMJywQM7Uklk/fxjKBUXAW ktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcxggKV3UV1B+OEQ0qH GAU4GJV4eBuaj4YIsSaWFVfmHmKU5GBSEuVN7j8WIsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE VzoXKMebklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMFbOQGoUbAoNT21 Ii0zpwQhzcTBCTKcB2j4XJAa3uKCxNzizHSI/ClGXY4F7ftnMgmx5OXnpUqJ884BKRIAKcoo zYObA0swrxjFgd4S5t0IUsUDTE5wk14BLWECWtK38gjIkpJEhJRUA6Og3pTV9iEiL64+TVma yX/R3exJdMzPvlztzu9Hb84I57y19mrPW/15KufPrYqexFW8csvs3ukJ7feKJz6OvJr2lMcu MON9XdZazeVXPp00cHjvcbhF+17Em2OGixXOrpiZ1m2zIKV3u+D8qFv2qy5dUN3TXF91bv0q AZGWJSvOaNlXvZ0rp7hKiaU4I9FQi7moOBEAv8wbmgsDAAA= Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: New Version Notification for draft-reschke-httpauth-auth-info-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 19:14:21 -0000 On Sat, 24 Jan 2015, Julian Reschke wrote: > Hi there, > > as discussed before, I believe Authentication-Info (and > Proxy-Authentication-Info) should be defined separately from Digest. > > Here's my proposal. % Authentication scheme definitions need to allow both notations, both % for senders and recipients. This allows recipients to use generic % parsing components, independent of the authentication scheme in use. Seems like cause for some 2119 language? I think the security considerations section could explicitly mention that using TLS (i.e., HTTPS) reduces the leakage via HTTP header fields. It seems likely that this document could be moved forward quickly. -Ben From nobody Mon Jan 26 12:04:09 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE911AD36A for ; Mon, 26 Jan 2015 12:03:59 -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 X9EmEatCE5nv for ; Mon, 26 Jan 2015 12:03:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5841A1AC2 for ; Mon, 26 Jan 2015 12:03:47 -0800 (PST) Received: from [192.168.178.36] ([84.187.35.60]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lt1yI-1XZRoL11f0-012Y3A; Mon, 26 Jan 2015 21:03:43 +0100 Message-ID: <54C69D99.1020600@gmx.de> Date: Mon, 26 Jan 2015 21:03:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <20150124190127.3801.31394.idtracker@ietfa.amsl.com> <54C3EE0D.2080506@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uFzxun9rr9btWyifO3iAnl3cvDXqFnz4av3vK6lHGEtvdYlXow4 7j6E/tocs1F8kWG++Wm7hkbEb04tMDfJ9iYlRvGCJd4HJ1X5fOx1iILUdwhM99Yvc99LYin rHysPOxNMgMOR3BFgGnA/V0T22YLcoAoU/IWi1GDCNGR/ifSdxuhFSfqR5zZ48T6FMjkB0A CmurR9mEUFSIKXGBy7Y1A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: New Version Notification for draft-reschke-httpauth-auth-info-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 20:03:59 -0000 On 2015-01-26 20:14, Benjamin Kaduk wrote: > On Sat, 24 Jan 2015, Julian Reschke wrote: > >> Hi there, >> >> as discussed before, I believe Authentication-Info (and >> Proxy-Authentication-Info) should be defined separately from Digest. >> >> Here's my proposal. > > > % Authentication scheme definitions need to allow both notations, both > % for senders and recipients. This allows recipients to use generic > % parsing components, independent of the authentication scheme in use. > > Seems like cause for some 2119 language? Right now I don't have any 2119 keywords, and I wanted to see whether I can get away with that :-) What do others think? > I think the security considerations section could explicitly mention that > using TLS (i.e., HTTPS) reduces the leakage via HTTP header fields. Right. Will do. > > It seems likely that this document could be moved forward quickly. > > -Ben Best regards, Julian From nobody Mon Jan 26 12:14:04 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69EC1AD368 for ; Mon, 26 Jan 2015 12:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 q_yBRFw4MjR7 for ; Mon, 26 Jan 2015 12:14:01 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 290531AD364 for ; Mon, 26 Jan 2015 12:14:01 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t0QKDt6H003967 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2015 13:13:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: <54C69D99.1020600@gmx.de> Date: Mon, 26 Jan 2015 12:13:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8141FB9C-259A-428A-843C-A2F209731461@vpnc.org> References: <20150124190127.3801.31394.idtracker@ietfa.amsl.com> <54C3EE0D.2080506@gmx.de> <54C69D99.1020600@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] New Version Notification for draft-reschke-httpauth-auth-info-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 20:14:02 -0000 On Jan 26, 2015, at 12:03 PM, Julian Reschke = wrote: >=20 > On 2015-01-26 20:14, Benjamin Kaduk wrote: >> On Sat, 24 Jan 2015, Julian Reschke wrote: >>=20 >>> Hi there, >>>=20 >>> as discussed before, I believe Authentication-Info (and >>> Proxy-Authentication-Info) should be defined separately from Digest. >>>=20 >>> Here's my proposal. >>=20 >>=20 >> % Authentication scheme definitions need to allow both notations, = both >> % for senders and recipients. This allows recipients to use generic >> % parsing components, independent of the authentication scheme in = use. >>=20 >> Seems like cause for some 2119 language? >=20 > Right now I don't have any 2119 keywords, and I wanted to see whether = I can get away with that :-) What do others think? No need for 2119 language when saying "a different spec needs to do X". = 2119isms in that situation are silly. --Paul Hoffman= From nobody Tue Jan 27 14:03:23 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA061A6F33 for ; Tue, 27 Jan 2015 14:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 1igrSOv6X3TX for ; Tue, 27 Jan 2015 14:03:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD551A6F2E for ; Tue, 27 Jan 2015 14:03:04 -0800 (PST) Received: from [192.168.2.175] ([93.217.91.161]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MdKkd-1XzWJp1lMx-00IVAL for ; Tue, 27 Jan 2015 23:03:02 +0100 Message-ID: <54C80B12.9090806@gmx.de> Date: Tue, 27 Jan 2015 23:02:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cDuW8SFnnGd4yXpsu/GwnUenBOQvRRyA9CsS7C551fzt41fE94+ hhaL2JtBzurGotzS7iRMXhDG26+BukGiLF3ESEfo6+pXuq384Yv7GTRSQXhlwAmxThJt3zk Qry/uQDCYjfFZwKBAMuw4c+pP97FGtUbjASRi8gyGY+sqO+SzVkQNZnU4On0F4N/3P8t5dd uiAyBDLyu5CxCWxNLkeNg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [http-auth] I18N feedback on 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, 27 Jan 2015 22:03:19 -0000 Quoting: > The following example assumes that an access protected document is > being requested from the server via a GET request. The URI for the > request is "http://api.example.org/doe.json". Both client and server > know the userhash of the username, support the UTF-8 character > encoding scheme, and use the SHA-512-256 algorithm. The username for > the request is a variation of "Jason Doe" and has the byte sequence > 4A C3 A4 73 C3 B8 6E 20 44 6F 65. The password is "Secret, or not?". Can we say: > The username for the request is a variation of "Jason Doe", where the the 'a' actually is Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERES"), and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL LETTER O WITH STROKE"), leading to the octet sequence using the UTF-8 encoding scheme: > > J U+00E4 s U+00F8 n D o e > 4A C3A4 73 C3B8 6E 20 44 6F 65 > > The password is "Secret, or not?". Best regards, Julian From nobody Wed Jan 28 07:15:31 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A22D1A0A85 for ; Wed, 28 Jan 2015 07:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, 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 ylFwl70RWX-y for ; Wed, 28 Jan 2015 07:15:25 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04491A0369 for ; Wed, 28 Jan 2015 07:15:24 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id s18so19633255lam.5 for ; Wed, 28 Jan 2015 07:15:23 -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=HOPXkHPzO1gqkeEZK2g1GIG3Uy0ZatyLZpB18/WNWTI=; b=pCvcsOd8UYpZOcEIpzbQ0Xx01UBdkbsrIKw5r8gjCkTsxZPFAhADAfISmwL9R0R9ec cPPgm/cuTxZe72i7QaAldIC3mrIQ+6wJ+GPNCYUfLQEB1VhcL76OaV8okoEWM8/BTpk7 JQiHq+/wumZtma+E1IxXkkW+EgDfd0x0DhgSedsOB+8w7f/pA8e6am8/2bIoJuVzJqt9 WNbPUl1pcDWOi5/qo/15OOC3dOwPWzaeGokQ6jkZBkFE+ss5QW5kYWd54TRrpMyUjv79 Cafie1ywpLbLdNmDNMFrH1wLCuJnm1/xqh2Mfb1+jBZJmBx/iCyB6hylRTLriOeBSmMj Dirw== MIME-Version: 1.0 X-Received: by 10.152.19.194 with SMTP id h2mr5381573lae.77.1422458123434; Wed, 28 Jan 2015 07:15:23 -0800 (PST) Received: by 10.114.27.162 with HTTP; Wed, 28 Jan 2015 07:15:23 -0800 (PST) In-Reply-To: <54C80B12.9090806@gmx.de> References: <54C80B12.9090806@gmx.de> Date: Wed, 28 Jan 2015 10:15:23 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=089e013d0f1227bfc8050db7d7af Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I18N feedback on 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, 28 Jan 2015 15:15:28 -0000 --089e013d0f1227bfc8050db7d7af Content-Type: text/plain; charset=ISO-8859-1 Thanks Julian, Sure, will do that in the next version of the draft. Regards, Rifaat On Tue, Jan 27, 2015 at 5:02 PM, Julian Reschke wrote: > Quoting: > > The following example assumes that an access protected document is >> being requested from the server via a GET request. The URI for the >> request is "http://api.example.org/doe.json". Both client and server >> know the userhash of the username, support the UTF-8 character >> encoding scheme, and use the SHA-512-256 algorithm. The username for >> the request is a variation of "Jason Doe" and has the byte sequence >> 4A C3 A4 73 C3 B8 6E 20 44 6F 65. The password is "Secret, or not?". >> > > Can we say: > > The username for the request is a variation of "Jason Doe", where the the >> 'a' actually is Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH >> DIAERES"), and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL >> LETTER O WITH STROKE"), leading to the octet sequence using the UTF-8 >> encoding scheme: >> >> J U+00E4 s U+00F8 n D o e >> 4A C3A4 73 C3B8 6E 20 44 6F 65 >> >> The password is "Secret, or not?". >> > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e013d0f1227bfc8050db7d7af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Julian,

Sure, will do that in th= e next version of the draft.

Regards,
= =A0Rifaat


On Tue, Jan 27, 2015 at 5:02 PM, Julian Reschke <ju= lian.reschke@gmx.de> wrote:
Quoting:

=A0 =A0The following example assumes that an access protected document is =A0 =A0being requested from the server via a GET request.=A0 The URI for th= e
=A0 =A0request is "http://api.example.org/doe.json".=A0 Both clien= t and server
=A0 =A0know the userhash of the username, support the UTF-8 character
=A0 =A0encoding scheme, and use the SHA-512-256 algorithm.=A0 The username = for
=A0 =A0the request is a variation of "Jason Doe" and has the byte= sequence
=A0 =A04A C3 A4 73 C3 B8 6E 20 44 6F 65.=A0 The password is "Secret, o= r not?".

Can we say:

The username for the request is a variation of "Jason Doe", where= the the 'a' actually is Unicode code point U+00E4 ("LATIN SMA= LL LETTER A WITH DIAERES"), and the first 'o' is Unicode code = point U+00F8 ("LATIN SMALL LETTER O WITH STROKE"), leading to the= octet sequence using the UTF-8 encoding scheme:

=A0 =A0J=A0 U+00E4 s=A0 U+00F8 n=A0 =A0 =A0 D=A0 o=A0 e
=A0 =A04A C3A4=A0 =A073 C3B8=A0 =A06E 20 44=A0 6F 65

The password is "Secret, or not?".

Best regards, Julian

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

--089e013d0f1227bfc8050db7d7af-- From nobody Wed Jan 28 14:09:14 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0111A19F8 for ; Wed, 28 Jan 2015 14:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AUWBuxUVpO4b for ; Wed, 28 Jan 2015 14:09:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523141A032D for ; Wed, 28 Jan 2015 14:09:00 -0800 (PST) Received: from [192.168.2.175] ([93.217.85.143]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MaZrd-1XwRLH211N-00KCz7 for ; Wed, 28 Jan 2015 23:08:58 +0100 Message-ID: <54C95DF4.3070607@gmx.de> Date: Wed, 28 Jan 2015 23:08:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hkd9gi84ckpoWzDwFJN7x02cHZMjlT1R0KjdqSkFk7jRLWcT4aP Ogt834gcSW/eBTCLszaqqn1NKhkzvY9SkoFuZFamNVncPvFk8zAdI1kcJY2GQtBowu6wcbw qRSyW6HdnVDU0cgX5vKPjGcaAiYLjMHksNezXHdiyyUsN4KiJtOd76i6rk0YAeLrRz2iqQe jY6H3Yh+LAz+OlvwRyx+g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [http-auth] RFC5987 related feedback on draft-ietf-httpauth-digest-12 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, 28 Jan 2015 22:09:09 -0000 Hi there. > ... > 3.1. Overall Operation > > > The Digest scheme is based on a simple challenge-response paradigm. > The Digest scheme challenges using a nonce value, and might indicate > that username hashing is supported. A valid response contains a > checksum of the username, the password, the given nonce value, the > HTTP method, and the requested URI. In this way, the password is > never sent in the clear, and the username can be hashed, depending on > the indication received from the server. The username and password > must be prearranged in some fashion not addressed by this document. > > The security of this protocol is critically dependent on the > randomness of the randomly chosen parameters, such as client and > server nonces. These should be generated by a strong random or > properly seeded pseudorandom source (see [RFC4086]). > > For the following parameters, the value can be encoded using > [RFC5987] encoding: username. At RFC 5987 encoding applies to exactly one parameter, it would be better to mention it where it's define (so drop this here). > ... > 3.4. The Authorization Request Header Field > > > The client is expected to retry the request, passing an Authorization > header field line with Digest scheme, which is defined according to > the framework above. The values of the opaque and algorithm fields > must be those supplied in the WWW-Authenticate response header field > for the entity being requested. > > The request can include parameters from the following list: > > response > > A string of the hex digits computed as defined below, which proves > that the user knows a password. > > username > > The user's name in the specified realm. > ... So here I would insert: "If the username contains characters not allowed inside the ABNF token or quoted-string forms, it can be sent in a "username*" parameter instead, using the encoding defined in [RFC5987]." Maybe furthermore: "Sending both "username" and "username*" MUST be treated as error." > ... > ... > 4. Internationalization s/Internationalization/Internationalization Considerations/ > In challenges, servers SHOULD use the "charset" authentication > parameter (case-insensitive) to express the character encoding they The parameter *name* is matched case-intensively? Why? > expect the user agent to use when generating A1 (see Section 3.4.2) > and username hashing (see Section 3.4.4). > > The only allowed value is "UTF-8", to be matched case-insensitively > (see [RFC2978], Section 2.3). It indicates that the server expects > user name and password to be converted to Unicode Normalization Form > C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets > using the UTF-8 character encoding scheme [RFC3629]. > > For the username, recipients MUST support all characters defined in > the "UsernameCasePreserved" profile defined in in Section 3.3 of > [PRECIS], with the exception of the colon (":") character. > > For the password, recipients MUST support all characters defined in > the "OpaqueString" profile defined in in Section 4.2 of [PRECIS]. > > If the user agent does not support the encoding indicated by the > server, it can fail the request. Add: "When usernames can not be sent hashed and include non-ASCII characters, clients can include the "username*" parameter instead (using the value encoding defined in [RFC598])." (Q: does this work with existing servers? What is the *current* situation wrt non-ASCII?) > ... Best regards, Julian From nobody Thu Jan 29 06:16:28 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D5B1A1A02 for ; Thu, 29 Jan 2015 06:16:18 -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 XFQkk17vSwEc for ; Thu, 29 Jan 2015 06:16:12 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0841A19FA for ; Thu, 29 Jan 2015 06:16:12 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id u14so28389841lbd.2 for ; Thu, 29 Jan 2015 06:16:10 -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=AxEMC/cw1JQcDyGiGPx2qOW6AX0eYNcnIWhukd/8AEc=; b=cdpA0IDDOrR0GmieuKTJZELdeQ7KOS1W0002CzHIQ+kKbRpteuvoj02cK7tFubdWc4 dl7ekDFVTRov3NxCr7VWdnplTIPbiqjOMNdVFIpkQycDA54u8bu0urCVz+WrmbZUGdp8 +wU1+VQM8fPwi/PjriNIa5Yq4Ci+S9Jxg1wTjcmqfJrDV3VFm2vLLdtegP3wRZAs6sbB R9DWJ4JdsJzwswj+WqnHgvkLeQ+l/usGXlv1QpGu2NY8OWH+gaAC3SgiFeblXgDqIlig kzHbpV51jKkedWYatfvSqbdgX4cLMGaZ8xJcXxXXQZgKNKd0IzWqfbsg/vYpGH7AV7g3 OMGg== MIME-Version: 1.0 X-Received: by 10.152.19.194 with SMTP id h2mr844750lae.77.1422540970673; Thu, 29 Jan 2015 06:16:10 -0800 (PST) Received: by 10.114.27.162 with HTTP; Thu, 29 Jan 2015 06:16:10 -0800 (PST) In-Reply-To: <54C95DF4.3070607@gmx.de> References: <54C95DF4.3070607@gmx.de> Date: Thu, 29 Jan 2015 09:16:10 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=089e013d0f123c49fc050dcb21d5 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] RFC5987 related feedback on draft-ietf-httpauth-digest-12 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, 29 Jan 2015 14:16:18 -0000 --089e013d0f123c49fc050dcb21d5 Content-Type: text/plain; charset=ISO-8859-1 Inline... On Wed, Jan 28, 2015 at 5:08 PM, Julian Reschke wrote: > Hi there. > > ... >> 3.1. Overall Operation >> >> >> The Digest scheme is based on a simple challenge-response paradigm. >> The Digest scheme challenges using a nonce value, and might indicate >> that username hashing is supported. A valid response contains a >> checksum of the username, the password, the given nonce value, the >> HTTP method, and the requested URI. In this way, the password is >> never sent in the clear, and the username can be hashed, depending on >> the indication received from the server. The username and password >> must be prearranged in some fashion not addressed by this document. >> >> The security of this protocol is critically dependent on the >> randomness of the randomly chosen parameters, such as client and >> server nonces. These should be generated by a strong random or >> properly seeded pseudorandom source (see [RFC4086]). >> >> For the following parameters, the value can be encoded using >> [RFC5987] encoding: username. >> > > At RFC 5987 encoding applies to exactly one parameter, it would be better > to mention it where it's define (so drop this here). > > Ok > ... >> 3.4. The Authorization Request Header Field >> >> >> The client is expected to retry the request, passing an Authorization >> header field line with Digest scheme, which is defined according to >> the framework above. The values of the opaque and algorithm fields >> must be those supplied in the WWW-Authenticate response header field >> for the entity being requested. >> >> The request can include parameters from the following list: >> >> response >> >> A string of the hex digits computed as defined below, which proves >> that the user knows a password. >> >> username >> >> The user's name in the specified realm. >> ... >> > > So here I would insert: "If the username contains characters not allowed > inside the ABNF token or quoted-string forms, it can be sent in a > "username*" parameter instead, using the encoding defined in [RFC5987]." > > Maybe furthermore: "Sending both "username" and "username*" MUST be > treated as error." > > Sure > > ... > > > ... > >> 4. Internationalization >> > > s/Internationalization/Internationalization Considerations/ > > Ok > In challenges, servers SHOULD use the "charset" authentication >> parameter (case-insensitive) to express the character encoding they >> > > The parameter *name* is matched case-intensively? Why? > > Not the parameter name, but the parameter value. I see it is mentioned below that the value in case-insensitive, so I will remove it from here. > expect the user agent to use when generating A1 (see Section 3.4.2) >> and username hashing (see Section 3.4.4). >> >> The only allowed value is "UTF-8", to be matched case-insensitively >> (see [RFC2978], Section 2.3). It indicates that the server expects >> user name and password to be converted to Unicode Normalization Form >> C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets >> using the UTF-8 character encoding scheme [RFC3629]. >> >> For the username, recipients MUST support all characters defined in >> the "UsernameCasePreserved" profile defined in in Section 3.3 of >> [PRECIS], with the exception of the colon (":") character. >> >> For the password, recipients MUST support all characters defined in >> the "OpaqueString" profile defined in in Section 4.2 of [PRECIS]. >> >> If the user agent does not support the encoding indicated by the >> server, it can fail the request. >> > > Add: "When usernames can not be sent hashed and include non-ASCII > characters, clients can include the "username*" parameter instead (using > the value encoding defined in [RFC598])." > Sure. > > (Q: does this work with existing servers? What is the *current* situation > wrt non-ASCII?) > > I am not sure about what the current server implementations are doing with non-ASCII. Maybe some people that have server implementation can comment on this. > > ... > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e013d0f123c49fc050dcb21d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline...


On Wed, Jan 28, 2015 at 5:0= 8 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hi there.

...
3.1. Overall Operation


=A0 =A0The Digest scheme is based on a simple challenge-response paradigm.<= br> =A0 =A0The Digest scheme challenges using a nonce value, and might indicate=
=A0 =A0that username hashing is supported.=A0 A valid response contains a =A0 =A0checksum of the username, the password, the given nonce value, the =A0 =A0HTTP method, and the requested URI.=A0 In this way, the password is<= br> =A0 =A0never sent in the clear, and the username can be hashed, depending o= n
=A0 =A0the indication received from the server.=A0 The username and passwor= d
=A0 =A0must be prearranged in some fashion not addressed by this document.<= br>
=A0 =A0The security of this protocol is critically dependent on the
=A0 =A0randomness of the randomly chosen parameters, such as client and
=A0 =A0server nonces.=A0 These should be generated by a strong random or =A0 =A0properly seeded pseudorandom source (see [RFC4086]).

=A0 =A0For the following parameters, the value can be encoded using
=A0 =A0[RFC5987] encoding: username.

At RFC 5987 encoding applies to exactly one parameter, it would be better t= o mention it where it's define (so drop this here).


Ok

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
...
3.4. The Authorization Request Header Field


=A0 =A0The client is expected to retry the request, passing an Authorizatio= n
=A0 =A0header field line with Digest scheme, which is defined according to<= br> =A0 =A0the framework above.=A0 The values of the opaque and algorithm field= s
=A0 =A0must be those supplied in the WWW-Authenticate response header field=
=A0 =A0for the entity being requested.

=A0 =A0The request can include parameters from the following list:

=A0 =A0response

=A0 =A0 =A0 A string of the hex digits computed as defined below, which pro= ves
=A0 =A0 =A0 that the user knows a password.

=A0 =A0username

=A0 =A0 =A0 The user's name in the specified realm.
...

So here I would insert: "If the username contains characters not allow= ed inside the ABNF token or quoted-string forms, it can be sent in a "= username*" parameter instead, using the encoding defined in [RFC5987].= "

Maybe furthermore: "Sending both "username" and "userna= me*" MUST be treated as error."


Sure

=A0
> ...

> ...
4. Internationalization

s/Internationalization/Internationalization Considerations/


Ok

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
=A0 =A0In challenges, servers SHOULD use the "charset" authentica= tion
=A0 =A0parameter (case-insensitive) to express the character encoding they<= br>

The parameter *name* is matched case-intensively? Why?


Not the parameter name, but the parame= ter value.
I see it is mentioned below that the value in case-ins= ensitive, so I will remove it from here.

=A0
=A0 =A0expect the user agent to use when generating A1 (see Section 3.4.2)<= br> =A0 =A0and username hashing (see Section 3.4.4).

=A0 =A0The only allowed value is "UTF-8", to be matched case-inse= nsitively
=A0 =A0(see [RFC2978], Section 2.3).=A0 It indicates that the server expect= s
=A0 =A0user name and password to be converted to Unicode Normalization Form=
=A0 =A0C ("NFC", see Section 3 of [RFC5198]) and to be encoded in= to octets
=A0 =A0using the UTF-8 character encoding scheme [RFC3629].

=A0 =A0For the username, recipients MUST support all characters defined in<= br> =A0 =A0the "UsernameCasePreserved" profile defined in in Section = 3.3 of
=A0 =A0[PRECIS], with the exception of the colon (":") character.=

=A0 =A0For the password, recipients MUST support all characters defined in<= br> =A0 =A0the "OpaqueString" profile defined in in Section 4.2 of [P= RECIS].

=A0 =A0If the user agent does not support the encoding indicated by the
=A0 =A0server, it can fail the request.

Add: "When usernames can not be sent hashed and include non-ASCII char= acters, clients can include the "username*" parameter instead (us= ing the value encoding defined in [RFC598])."
Sure.

=A0

(Q: does this work with existing servers? What is the *current* situation w= rt non-ASCII?)


I am not sure about what the current s= erver implementations are doing with non-ASCII.
Maybe some people= that have server implementation can comment on this.

<= div>=A0
> ...

Best regards, Julian

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

--089e013d0f123c49fc050dcb21d5-- From nobody Sat Jan 31 01:03:57 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482C81A88E8 for ; Sat, 31 Jan 2015 01:03:55 -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 GNAUJ9lFI0aW for ; Sat, 31 Jan 2015 01:03:53 -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 639F41A88E6 for ; Sat, 31 Jan 2015 01:03:51 -0800 (PST) Received: from [192.168.2.175] ([93.217.99.220]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MB2G8-1YPDiz0A44-00A2DM; Sat, 31 Jan 2015 10:03:49 +0100 Message-ID: <54CC9A6C.1030308@gmx.de> Date: Sat, 31 Jan 2015 10:03:40 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sophie Bremer , Rifaat Shekh-Yusef References: <54C95DF4.3070607@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:bWSKcaGrwm4RYF/pDTLaxnF8yZ4pnSDj/0tpWo5A++hoPYBoU1C eiQwhEKLFrsaPms008XkCyx8lriCKO+s/4n+czRDGqsUcs9ckt7mHmBTR8Pqn/tcCzmi4BY fe1oOg/IPGOv9LkpdqpDgM7kC+Hov+aT5DqfWdlZ9X8kGWRzqrpT2rTMRwra4d4kyRzrZxN vmrlACZXrK/De0R9yFcog== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] RFC5987 related feedback on draft-ietf-httpauth-digest-12 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, 31 Jan 2015 09:03:56 -0000 On 2015-01-31 09:48, Sophie Bremer wrote: > >> >> (Q: does this work with existing servers? What is the *current* >> situation wrt non-ASCII?) >> >> >> I am not sure about what the current server implementations are doing >> with non-ASCII. >> Maybe some people that have server implementation can comment on this. > > We treat non-ASCII as UTF-8 and ignore the Authorization header option, > if this fails. So are there UAs sending UTF-8? Which? (Asking in order to compare with the situation for Basic) Best regards, Julian From nobody Sat Jan 31 01:40:04 2015 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B9F1A88FD for ; Sat, 31 Jan 2015 01:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9UBmUx-ZHTG for ; Sat, 31 Jan 2015 01:40:01 -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 531131A88F9 for ; Sat, 31 Jan 2015 01:40:01 -0800 (PST) Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id 70F3A25A2138; Sat, 31 Jan 2015 10:39:59 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3kZ9PW1RGxz5vNB; Sat, 31 Jan 2015 10:39:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Sophie Bremer In-Reply-To: <54CC9A6C.1030308@gmx.de> Date: Sat, 31 Jan 2015 10:39:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5DFB1C5F-8A86-40CF-8585-8070A4305E2D@netzkonform.de> References: <54C95DF4.3070607@gmx.de> <54CC9A6C.1030308@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] RFC5987 related feedback on draft-ietf-httpauth-digest-12 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, 31 Jan 2015 09:40:03 -0000 > On 2015-01-31 09:48, Sophie Bremer wrote: >>=20 >>>=20 >>> (Q: does this work with existing servers? What is the *current* >>> situation wrt non-ASCII?) >>>=20 >>>=20 >>> I am not sure about what the current server implementations are = doing >>> with non-ASCII. >>> Maybe some people that have server implementation can comment on = this. >>=20 >> We treat non-ASCII as UTF-8 and ignore the Authorization header = option, >> if this fails. >=20 > So are there UAs sending UTF-8? Which? >=20 > (Asking in order to compare with the situation for Basic) I just made a technical statement for the server side. I do know, that = some browsers send non-ASCII as UTF-8, for example Chrome and Safari. = But for compatibility we actually use HTML forms with cookies to support = UTF-8 logins - but like to switch to digest in the near future. Regards, Sophie=