From nobody Thu May 8 14:42:06 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D131A0162 for ; Thu, 8 May 2014 14:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 DJ1CnG27xdYf for ; Thu, 8 May 2014 14:42:02 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 551841A0160 for ; Thu, 8 May 2014 14:42:02 -0700 (PDT) Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1WiW4i-0007jn-6j; Thu, 08 May 2014 17:41:56 -0400 Message-ID: <536BFA23.9020900@digitalbazaar.com> Date: Thu, 08 May 2014 17:41:55 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: IETF HTTP Auth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/DTGo3JE3Gn8h9917Yg4d95kuClw Cc: Julian Reschke , Mark Nottingham , Web Payments CG Subject: [http-auth] Review Request for third draft of "Signing HTTP Messages" X-BeenThere: http-auth@ietf.org X-Mailman-Version: 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 May 2014 21:42:03 -0000 After feedback from Mark Nottingham[1], Julian Reschke[2], folks in the HTTP Auth WG, and people in the Web Payments CG, we've modified the HTTP Signatures specification in the following ways: 1. The specification has been renamed to "Signing HTTP Messages". 2. The specification now covers both a signature-based Authorization mechanism (client-to-server) as well as a general mechanism to sign HTTP messages (client-to-server and server-to-client). 3. A new "Signature" header has been introduced. 4. The layout has been modified heavily to streamline the information conveyed in the spec. 5. New registries have been created for the algorithms referred to in the specification. 6. We're now more specific in the way certain canonicalizations are performed. 7. More examples have been added, including how to digitally sign the body of an HTTP message. The basic mechanism of generating the signatures has not changed (and has been stable for over a year). The newest spec can be found here: http://tools.ietf.org/html/draft-cavage-http-signatures-02 The diff is here: http://tools.ietf.org/rfcdiff?url2=draft-cavage-http-signatures-02.txt Matt, Yoav, Kathleen, if there are no show stopping review comments, I'd like to push this spec onto the RFC track in the HTTP Auth WG, or HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize that HTTP Auth may be shutting down next month, so what's the next step to get the HTTP Signatures spec further down the IETF RFC track? -- manu [1] http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html [2] http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.html -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Marathonic Dawn of Web Payments http://manu.sporny.org/2014/dawn-of-web-payments/ From nobody Thu May 8 15:54:05 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964AA1A014E for ; Thu, 8 May 2014 15:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zs3umtPWNH1 for ; Thu, 8 May 2014 15:54:01 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB271A0147 for ; Thu, 8 May 2014 15:54:01 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id q8so4562556lbi.13 for ; Thu, 08 May 2014 15:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uH5lKX7fr5Xkn6IGffyCHEHwso3cjjNd1cisONxpgVI=; b=z3FR6uFY85thCJFKJSZ93yBGuCF6+OjfWIROP0MtxfGaNnb/IW+i95losopvqSqacR YxoL9DBpuTooY+4QiJSBXcFNo3vRbR/kY5SXY9/YYc1WJy966CjX9ni4S1hvQ1TA/t4/ NN5SAoPpmqbbodaCwVyWsekNQ32QJV3iaQFly8LillaB8sYevnFrmiCZayaqFixlSiTd VCMJjdzoiGCIx3xKLc4XTcQQFBzEtsD4ZKJ4+rrkOW9wsI5qWvq/wZZjsk3DCBc2SVkH GJX1/PNmuCE49MRpo+dxpZIs/MTzHg8n97faX5kRRssyxUqKqkavfwMavIg7tIaQKmuN qB6A== MIME-Version: 1.0 X-Received: by 10.112.29.79 with SMTP id i15mr7639041lbh.26.1399589635887; Thu, 08 May 2014 15:53:55 -0700 (PDT) Received: by 10.112.147.101 with HTTP; Thu, 8 May 2014 15:53:55 -0700 (PDT) In-Reply-To: <536BFA23.9020900@digitalbazaar.com> References: <536BFA23.9020900@digitalbazaar.com> Date: Fri, 9 May 2014 00:53:55 +0200 Message-ID: From: Melvin Carvalho To: Manu Sporny Content-Type: multipart/alternative; boundary=001a1133ed7a149de104f8eb5b22 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/jil1mzTG742OidHSrOl7z-Ca_Iw Cc: Julian Reschke , Mark Nottingham , IETF HTTP Auth , Web Payments CG Subject: Re: [http-auth] Review Request for third draft of "Signing HTTP Messages" X-BeenThere: http-auth@ietf.org X-Mailman-Version: 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 May 2014 22:54:03 -0000 --001a1133ed7a149de104f8eb5b22 Content-Type: text/plain; charset=UTF-8 On 8 May 2014 23:41, Manu Sporny wrote: > After feedback from Mark Nottingham[1], Julian Reschke[2], folks in the > HTTP Auth WG, and people in the Web Payments CG, we've modified the HTTP > Signatures specification in the following ways: > > 1. The specification has been renamed to "Signing HTTP Messages". > 2. The specification now covers both a signature-based Authorization > mechanism (client-to-server) as well as a general mechanism to sign > HTTP messages (client-to-server and server-to-client). > 3. A new "Signature" header has been introduced. > 4. The layout has been modified heavily to streamline the information > conveyed in the spec. > 5. New registries have been created for the algorithms referred to in > the specification. > Thanks for updating this, it looks great. One thing, I'm slightly confused as to how algorithms should be specified. For example: SHA256 Appears in the document and both lower case and upper case. It also appears both with a hyphen and without a hyphen. I'm also currently using sha-256 as specified in RFC 6920 I'd like to start using things like ECDSA signature as defined in crypto currencies, but I am finding it challenging to find an easy to spot pattern in the naming. Any guidance would be appreciated. > 6. We're now more specific in the way certain canonicalizations are > performed. > 7. More examples have been added, including how to digitally sign > the body of an HTTP message. > > The basic mechanism of generating the signatures has not changed (and > has been stable for over a year). > > The newest spec can be found here: > > http://tools.ietf.org/html/draft-cavage-http-signatures-02 > > The diff is here: > > http://tools.ietf.org/rfcdiff?url2=draft-cavage-http-signatures-02.txt > > Matt, Yoav, Kathleen, if there are no show stopping review comments, I'd > like to push this spec onto the RFC track in the HTTP Auth WG, or > HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize that > HTTP Auth may be shutting down next month, so what's the next step to > get the HTTP Signatures spec further down the IETF RFC track? > > -- manu > > [1] > http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html > [2] > http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.html > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: The Marathonic Dawn of Web Payments > http://manu.sporny.org/2014/dawn-of-web-payments/ > > --001a1133ed7a149de104f8eb5b22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 8 May 2014 23:41, Manu Sporny <msporny@digitalbazaar.co= m> wrote:
After feedback from Mark = Nottingham[1], Julian Reschke[2], folks in the
HTTP Auth WG, and people in the Web Payments CG, we've modified the HTT= P
Signatures specification in the following ways:

1. The specification has been renamed to "Signing HTTP Messages".=
2. The specification now covers both a signature-based Authorization
=C2=A0 =C2=A0mechanism (client-to-server) as well as a general mechanism to= sign
=C2=A0 =C2=A0HTTP messages (client-to-server and server-to-client).
3. A new "Signature" header has been introduced.
4. The layout has been modified heavily to streamline the information
=C2=A0 =C2=A0conveyed in the spec.
5. New registries have been created for the algorithms referred to in
=C2=A0 =C2=A0the specification.

Thanks for u= pdating this, it looks great.

= One thing, I'm slightly confused as to how algorithms should be specifi= ed.

For example: SHA256

Appears in the documen= t and both lower case and upper case.

It also appears bot= h with a hyphen and without a hyphen.

I'm = also currently using sha-256 as specified in RFC 6920

I'd like to start using things like ECDSA signature as d= efined in crypto currencies, but I am finding it challenging to find an eas= y to spot pattern in the naming.

Any guidance would be appreciated.<= br>

=C2=A0
6. We're now more specific in the way certain canonicalizations are
=C2=A0 =C2=A0performed.
7. More examples have been added, including how to digitally sign
=C2=A0 =C2=A0the body of an HTTP message.

The basic mechanism of generating the signatures has not changed (and
has been stable for over a year).

The newest spec can be found here:

http://tools.ietf.org/html/draft-cavage-http-signatures-02

The diff is here:

http://tools.ietf.org/rfcdiff?url2=3Ddraft-cava= ge-http-signatures-02.txt

Matt, Yoav, Kathleen, if there are no show stopping review comments, I'= d
like to push this spec onto the RFC track in the HTTP Auth WG, or
HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize that=
HTTP Auth may be shutting down next month, so what's the next step to get the HTTP Signatures spec further down the IETF RFC track?

-- manu

[1] http://lists.w3.org/Archives/Public/public-= webpayments/2014Feb/0038.html
[2] http://lists.w3.org/Archives/Public/public-= webpayments/2014Feb/0036.html

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/


--001a1133ed7a149de104f8eb5b22-- From garyamort@gmail.com Mon May 12 12:03:30 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0863D1A076E for ; Mon, 12 May 2014 12:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYM-vvarqA4E for ; Mon, 12 May 2014 12:03:27 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 917561A075C for ; Mon, 12 May 2014 12:03:27 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q107so8075732qgd.38 for ; Mon, 12 May 2014 12:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=3/nJ4VVshcUSUwi/st9l8rJyE/JNs2+hgJB4OCJj/h0=; b=ie+8rY18A8m1XXzTUbBtc8SftVlcIdlYsc1f+3Bg8JIKeAwN+/h+Jd4Qt8iRsZI3IY ouzM9qgQNtO39K5ReI2EYUSMydYaLBk8zOyxeQuo6o69FH8FEGV9Lba+bXDZXm86tM9d YydMcEX3c4BNJD7npwu4awNorePeFjLXdPrh7cAYisl7jXoDFDPxCk/hsD4rPoLA/QaT QAEzqDh76DwrEe+fez8bfYzZkKRkh6zz9kJmfqYAWmZlut5Hea9GfsWlXs1nweMnIhow iJDZ6nmECDzsunSWRz7jLo3AYuVDuXnyyXcKzcbOagOfyPLxEUBQdLzEPOABjuKLK7y5 pnvA== X-Received: by 10.224.26.71 with SMTP id d7mr40183455qac.29.1399921401321; Mon, 12 May 2014 12:03:21 -0700 (PDT) Received: from ?IPv6:2604:2000:1118:4036:62a4:4cff:fea8:603d? ([2604:2000:1118:4036:62a4:4cff:fea8:603d]) by mx.google.com with ESMTPSA id j3sm22816107qaf.6.2014.05.12.12.03.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 12:03:20 -0700 (PDT) Message-ID: <53711AF6.2080304@gmail.com> Date: Mon, 12 May 2014 15:03:18 -0400 From: Gary Mort User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rifaat.ietf@gmail.com, http-auth@ietf.org Content-Type: multipart/alternative; boundary="------------020503040209080001090502" Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/VLL7m32LPQbPYvUuyro93pvDTSE Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-07.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, 12 May 2014 19:15:38 -0000 This is a multi-part message in MIME format. --------------020503040209080001090502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 3.3 The WWW-Authenticate Response Header " domain A quoted, space-separated list of URIs, as specified inRFC 3986 [RFC3986 ], that define the protection space. If a URI is an abs_path, it is relative to the canonical root URL of the server being accessed. An absolute-URI in this list may refer to a different server than the one being accessed. The client can use this list to determine the set of URIs for which the same authentication information may be sent: any URI that has a URI in this list as a 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 responding server." Looking at the source code for both Firefox and Google Chrome - I find that this header is ignored by both browsers. There is an outstanding issue for Chrome mentioning that they have assigned this low priority since Firefox never supported it. Are there any browsers which support this feature? If not, it would be better to deprecate the feature entirely then document a feature no one will support. If the feature is worthwhile[and I happen to think it is] it should be placed as an independent RFC. Moreover, I would recommend that in a seperate RFC, the "Domains" option should remain deprecated and be replaced with some more explicit options. As currently written, "Domains" has the same security issues as session cookies and cross domain usage. IE just as allowing one domain to set a cookie value for another unrelated domain is a security issue - allowing one domain to set an http authentication header for other domains is an issue. -Gary A Mort --------------020503040209080001090502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
3.3 The WWW-Authenticate Response Header




" domain
      A quoted, space-separated list of URIs, as specified in RFC 3986
      [RFC3986], that define the protection space.  If a URI is an
      abs_path, it is relative to the canonical root URL of the server
      being accessed. An absolute-URI in this list may refer to a
      different server than the one being accessed. The client can use
      this list to determine the set of URIs for which the same
      authentication information may be sent: any URI that has a URI in
      this list as a 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 responding server."

      Looking at the source code for both Firefox and Google Chrome - I
      find that this header is ignored by both browsers.  There is an
      outstanding issue for Chrome mentioning that they have assigned
      this low priority since Firefox never supported it.

      

      

      Are there any browsers which support this feature?  If not, it
      would be better to deprecate the feature entirely then document a
      feature no one will support.

      

      

      If the feature is worthwhile[and I happen to think it is] it
      should be placed as an independent RFC.  Moreover, I would
      recommend that in a seperate RFC, the "Domains" option should
      remain deprecated and be replaced with some more explicit options.

      

      As currently written, "Domains" has the same security issues as
      session cookies and cross domain usage.  IE just as allowing one
      domain to set a cookie value for another unrelated domain is a
      security issue - allowing one domain to set an http authentication
      header for other domains is an issue.  

      

      -Gary A Mort

      

    

  


--------------020503040209080001090502--


From garyamort@gmail.com  Mon May 12 12:14:46 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F82B1A0728 for ; Mon, 12 May 2014 12:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myTb1xnvsOu1 for ; Mon, 12 May 2014 12:14:44 -0700 (PDT)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 833B41A076A for ; Mon, 12 May 2014 12:14:44 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id i8so8228373qcq.4 for ; Mon, 12 May 2014 12:14:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=teIHUxR3wiPTWdcPbFJ1V6xed3KXudVM8PrZSnIHuKs=; b=WzlI2pPqwnxAhlw0WK09WR3sTtQLtHq0+k9SQ5cOa8p1PjqVgUNv+QSLIa7j6x+XAY 2Gm+YAi9nF2cde5fLxC2VrmJ55D+gdeoaWjKHECHy+E5lUpC++IXXdm/BDe3boaq5uBr RpGTaQgbkE7Op8Q9xvwJBnmNOIcI4wF0ywblOq8wuNlj31uF36hslWSV1yCm3XIgfvu8 YiZn2XhXiRVMpcDz8AhnmKR8F7UEyMzXFjsmtQQ0KZINFaRUXcheuuaptvH4S1vMMzuP MSuRlLVScjqacnTovybDKY6bzwZZgSATXqUVu/zM37XwvBXnI92W1evqdIkT6lI4oufa fJXA==
X-Received: by 10.140.82.7 with SMTP id g7mr38989333qgd.74.1399922078310; Mon, 12 May 2014 12:14:38 -0700 (PDT)
Received: from ?IPv6:2604:2000:1118:4036:62a4:4cff:fea8:603d? ([2604:2000:1118:4036:62a4:4cff:fea8:603d]) by mx.google.com with ESMTPSA id j88sm7752358qgf.39.2014.05.12.12.14.36 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 12:14:37 -0700 (PDT)
Message-ID: <53711D9B.2070804@gmail.com>
Date: Mon, 12 May 2014 15:14:35 -0400
From: Gary Mort 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: rifaat.ietf@gmail.com, http-auth@ietfa.amsl.com
Content-Type: multipart/alternative; boundary="------------020009050403060203070309"
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/cxMVr4nukmBnnPJNhS8bn0o_ABI
Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-07.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, 12 May 2014 19:15:49 -0000

This is a multi-part message in MIME format.
--------------020009050403060203070309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The documentation for A1 has consistently led to some confusion in implementations.

"
3.4.2 A1
    If the "algorithm" parameter's value is "", e.g. "SHA-
    256", then A1 is:

         A1       = unq(username) ":" unq(realm) ":" passwd
       where
          passwd   = < user's password >

    If the "algorithm" parameter's value is "-sess", e.g.
    "SHA-256-sess", then A1 is calculated only once - on the first
    request by the client following receipt of a WWW-Authenticate
    challenge from the server.  It uses the server nonce from that
    challenge, and the first client nonce value to construct A1 as
    follows:

          A1       = H( unq(username) ":" unq(realm)
                         ":" passwd )
                         ":" unq(nonce) ":" unq(cnonce)
"

For either case, A1 can be calculated only once.  IE since
  unq(username) ":" unq(realm) ":" passwd
  is fixed for the life of the session, there is no requirement for the client and server to calculate it upon each submission.

Moreover, whether the client is free to calculate A1 only once OR it can calculate A1 for each packet - it just needs to ensure to always use the initial nonce and cnonce if it recalculates the hash.

Just as a start, I would rephrase as:
3.4.2 A1

    If the "algorithm" parameter's value is "", e.g. "SHA-
    256", then A1 is:

          A1       = unq(username) ":" unq(realm) ":" passwd

       where

          passwd   = < user's password >

    If the "algorithm" parameter's value is "-sess", e.g.
    "SHA-256-sess", then A1 is calculated using the initial nonce and
    cnounce value from the firstrequest by the client following receipt
    of a WWW-Authenticate challenge from the server.  It uses the server
    nonce from that challenge, herin called nonce-prime, and the first
    client nonce value to construct A1, herin called cnonce-prime as
    follows:

          A1       = H( unq(username) ":" unq(realm)
                         ":" passwd )
                         ":" unq(nonce-prime) ":" unq(cnonce-prime)

    This creates a 'session key' for the authentication of subsequent
    requests and responses which is different for each "authentication
    session", thus limiting the amount of material hashed with any one
    key.  (Note: see further discussion of the authentication session in
    section 3.6.) Because the server need only use the hash of the user
    credentials in order to create the A1 value, this construction could
    be used in conjunction with a third party authentication service so
    that the web server would not need the actual password value.  The
    specification of such a protocol is beyond the scope of this
    specification.



--------------020009050403060203070309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    
    
The documentation for A1 has consistently led to some confusion in implementations.

"
3.4.2 A1
   If the "algorithm" parameter's value is "<algorithm>", e.g. "SHA-
   256", then A1 is:

        A1       = unq(username) ":" unq(realm) ":" passwd
      where
         passwd   = < user's password >

   If the "algorithm" parameter's value is "<algorithm>-sess", e.g.
   "SHA-256-sess", then A1 is calculated only once - on the first
   request by the client following receipt of a WWW-Authenticate
   challenge from the server.  It uses the server nonce from that
   challenge, and the first client nonce value to construct A1 as
   follows:

         A1       = H( unq(username) ":" unq(realm)
                        ":" passwd )
                        ":" unq(nonce) ":" unq(cnonce)
"

For either case, A1 can be calculated only once.  IE since 
 unq(username) ":" unq(realm) ":" passwd
 is fixed for the life of the session, there is no requirement for the client and server to calculate it upon each submission.

Moreover, whether the client is free to calculate A1 only once OR it can calculate A1 for each packet - it just needs to ensure to always use the initial nonce and cnonce if it recalculates the hash.

Just as a start, I would rephrase as:
3.4.2 A1

   If the "algorithm" parameter's value is "<algorithm>", e.g. "SHA-
   256", then A1 is:

         A1       = unq(username) ":" unq(realm) ":" passwd

      where

         passwd   = < user's password >

   If the "algorithm" parameter's value is "<algorithm>-sess", e.g.
   "SHA-256-sess", then A1 is calculated using the initial nonce and 
   cnounce value from the firstrequest by the client following receipt 
   of a WWW-Authenticate challenge from the server.  It uses the server 
   nonce from that challenge, herin called nonce-prime, and the first 
   client nonce value to construct A1, herin called cnonce-prime as
   follows:

         A1       = H( unq(username) ":" unq(realm)
                        ":" passwd )
                        ":" unq(nonce-prime) ":" unq(cnonce-prime)

   This creates a 'session key' for the authentication of subsequent
   requests and responses which is different for each "authentication
   session", thus limiting the amount of material hashed with any one
   key.  (Note: see further discussion of the authentication session in
   section 3.6.) Because the server need only use the hash of the user
   credentials in order to create the A1 value, this construction could
   be used in conjunction with a third party authentication service so
   that the web server would not need the actual password value.  The
   specification of such a protocol is beyond the scope of this
   specification.



  


--------------020009050403060203070309--


From nobody Mon May 12 12:44:11 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8DC1A07D9 for ; Mon, 12 May 2014 12:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pERivuTV5o7n for ; Mon, 12 May 2014 12:43:51 -0700 (PDT)
Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18A1A079B for ; Mon, 12 May 2014 12:43:51 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id l6so8523891qcy.9 for ; Mon, 12 May 2014 12:43:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=YQSwPaTTUxDZ8r5Q7b60Y5SjqdtrbmhifvjiG5GLjgI=; b=PcZHwoO1B3aM7xH6HoHfLohKF4NPlIhXs0rCBEWVeRldDHGf43FAWXrKNkgn2T1dCd CI8fAymdyjrUSYphDwbm1xGJB1corrcMWJrKE/lD6vZswalt9vjhdKoBPTUSPFMR0M1y 67c+lUhotho9dHQXU9Qi68yHgMOnMK5Evdvdv2gjhtNRcMnoli0Yin4lHJjVjaqU7ZDL fxrGG/DVuAqoQ1mKg7iSpLwoykQHXrx1KHXLLimx0+NLRtPzcKJlUYYR7STKwig3FF/d 42LE/QuodLs5/iwtCiWyn606SAzzJ7qCYyA+db6+ksBanxpPUT05dySYHexRIBAb1xC3 eUCQ==
X-Received: by 10.224.5.134 with SMTP id 6mr41196578qav.52.1399923825120; Mon, 12 May 2014 12:43:45 -0700 (PDT)
Received: from ?IPv6:2604:2000:1118:4036:62a4:4cff:fea8:603d? ([2604:2000:1118:4036:62a4:4cff:fea8:603d]) by mx.google.com with ESMTPSA id x2sm22947909qar.44.2014.05.12.12.43.44 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 12:43:44 -0700 (PDT)
Message-ID: <5371246E.8020902@gmail.com>
Date: Mon, 12 May 2014 15:43:42 -0400
From: Gary Mort 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: http-auth@ietf.org
Content-Type: multipart/alternative; boundary="------------030802060707070701060405"
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/eftraqXovCWKD6RJ-KVUzp0j6Q0
Subject: [http-auth] WWW-Authenticate for 200 Response Codes
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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, 12 May 2014 19:43:55 -0000

This is a multi-part message in MIME format.
--------------030802060707070701060405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

As I read the WWW-Authenticate specs, they /may/ be sent for status 
codes other then 401.

An example usage that may be useful for some applications:

WWW-Authenticate: TOTS realm="www.example.com", totosforms="formname", totsfield="fieldname"
WWW-Authenticate: COOKIE realm="www.example.com", cookie="cookiename"


Using a scheme such as this, were various authentication methods are set, it would then be possible for custom extensions in web clients to support more user friendly logon procedures.

To further the example, the use of TOTS today is disruptive for the end user, they must not only enter their userid and password to logon, but afterwards submission they will be prompted to enter a TOTS code before being allowed to log on.

If a website advertises TOTS support for all requests where the user is not logged on, then it would be possible for the client to automatically query any connected TOTS devices and automatically fill in the totsfield when a logon form is submitted.  TOTS devices which require manual intervention at the least prompt the user to retrieve that data before logging on.

By the same token, session cookie names tend to be rather opaque for end users, so users who choose not to allow cookies without their explicit permission are innundated with opaque prompts.   By specifying that authentication is via a cookie, and specifying the name of that cookie, clients could provide clearer information to end users.  IE instead of a message like "Do you wish wwww.example.com to be allowed to set the PHPSESSID cookie" they could provide clarity with a message such as "Do you wish wwww.eample.com to be allowed to set the visitor tracking cookie PHPSESSID"


In any case, I am not specifically promoting these particular extensions - I simply wish to verify that this type of usage is implicitly supported in the current standards.   The primary benefit of doing this with multiple headers is that it current browsers "support" this implementation in that for 401 responses, it is the last header which is used - so WWW-Authenticate: digest... can be placed last and the browser will default to using it - while extensions have events available so they can override the default behaviour based on the existence of additional headers.

-Gary






--------------030802060707070701060405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    As I read the WWW-Authenticate specs, they /may/ be sent for status
    codes other then 401.

    

    An example usage that may be useful for some applications:

    
    
WWW-Authenticate: TOTS realm="www.example.com", totosforms="formname", totsfield="fieldname"
WWW-Authenticate: COOKIE realm="www.example.com", cookie="cookiename"


Using a scheme such as this, were various authentication methods are set, it would then be possible for custom extensions in web clients to support more user friendly logon procedures.

To further the example, the use of TOTS today is disruptive for the end user, they must not only enter their userid and password to logon, but afterwards submission they will be prompted to enter a TOTS code before being allowed to log on.

If a website advertises TOTS support for all requests where the user is not logged on, then it would be possible for the client to automatically query any connected TOTS devices and automatically fill in the totsfield when a logon form is submitted.  TOTS devices which require manual intervention at the least prompt the user to retrieve that data before logging on.

By the same token, session cookie names tend to be rather opaque for end users, so users who choose not to allow cookies without their explicit permission are innundated with opaque prompts.   By specifying that authentication is via a cookie, and specifying the name of that cookie, clients could provide clearer information to end users.  IE instead of a message like "Do you wish wwww.example.com to be allowed to set the PHPSESSID cookie" they could provide clarity with a message such as "Do you wish wwww.eample.com to be allowed to set the visitor tracking cookie PHPSESSID"


In any case, I am not specifically promoting these particular extensions - I simply wish to verify that this type of usage is implicitly supported in the current standards.   The primary benefit of doing this with multiple headers is that it current browsers "support" this implementation in that for 401 responses, it is the last header which is used - so WWW-Authenticate: digest... can be placed last and the browser will default to using it - while extensions have events available so they can override the default behaviour based on the existence of additional headers.

-Gary





    

    

  


--------------030802060707070701060405--


From nobody Mon May 12 12:51:13 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CEC1A0766 for ; Mon, 12 May 2014 12:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SskXf-fA2oQA for ; Mon, 12 May 2014 12:51:07 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85C1A0772 for ; Mon, 12 May 2014 12:51:07 -0700 (PDT)
Received: from [192.168.2.117] ([84.187.36.166]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LgptO-1X7hXm0SgQ-00oH4r; Mon, 12 May 2014 21:51:00 +0200
Message-ID: <53712622.5070009@gmx.de>
Date: Mon, 12 May 2014 21:50:58 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Gary Mort , http-auth@ietf.org
References: <5371246E.8020902@gmail.com>
In-Reply-To: <5371246E.8020902@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:UFya41vwJEWxDheWfC8tmUBucOVf/3WcZce6g9qyrerjAbHkqWw tOmRKxgDuo3qKN6/eJRYxWA395d8bzx0YohwWjkypyfgMI+rrsAAQrYfIjdkjtnclwIK5i5 ctFzxpMzIKo9+cHl2JJC918efOnPT8z1KeGH27GJIz8MuNKvUVxZ80BUudIcscnVdGaX/AG BKyOxVLBXX6NVfXCE3pfA==
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/lM8qlh1QAsrF41rZ8UiEPD0c0sk
Subject: Re: [http-auth] WWW-Authenticate for 200 Response Codes
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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, 12 May 2014 19:51:11 -0000

On 2014-05-12 21:43, Gary Mort wrote:
> As I read the WWW-Authenticate specs, they /may/ be sent for status
> codes other then 401.
>
> An example usage that may be useful for some applications:
>
> WWW-Authenticate: TOTS realm="www.example.com", totosforms="formname", totsfield="fieldname"
> WWW-Authenticate: COOKIE realm="www.example.com", cookie="cookiename"
>
>
> Using a scheme such as this, were various authentication methods are set, it would then be possible for custom extensions in web clients to support more user friendly logon procedures.
>
> To further the example, the use of TOTS today is disruptive for the end user, they must not only enter their userid and password to logon, but afterwards submission they will be prompted to enter a TOTS code before being allowed to log on.
>
> If a website advertises TOTS support for all requests where the user is not logged on, then it would be possible for the client to automatically query any connected TOTS devices and automatically fill in the totsfield when a logon form is submitted.  TOTS devices which require manual intervention at the least prompt the user to retrieve that data before logging on.
>
> By the same token, session cookie names tend to be rather opaque for end users, so users who choose not to allow cookies without their explicit permission are innundated with opaque prompts.   By specifying that authentication is via a cookie, and specifying the name of that cookie, clients could provide clearer information to end users.  IE instead of a message like "Do you wish wwww.example.com to be allowed to set the PHPSESSID cookie" they could provide clarity with a message such as "Do you wish wwww.eample.com to be allowed to set the visitor tracking cookie PHPSESSID"
>
>
> In any case, I am not specifically promoting these particular extensions - I simply wish to verify that this type of usage is implicitly supported in the current standards.   The primary benefit of doing this with multiple headers is that it current browsers "support" this implementation in that for 401 responses, it is the last header which is used - so WWW-Authenticate: digest... can be placed last and the browser will default to using it - while extensions have events available so they can override the default behaviour based on the existence of additional headers.
>
> -Gary

Although this is the "http-auth" mailing list, you're in the wrong 
location. "http-auth" is about defining specific auth schemes.

What's relevant here is the authentication *framework*, and that is 
defined in the httpbis specs, in particular 
, 
to be published as RFC really soon now.

Best regards, Julian


From nobody Tue May 13 06:00:18 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FB31A00A6 for ; Tue, 13 May 2014 06:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTsuPI40GVZx for ; Tue, 13 May 2014 06:00:12 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 143C11A00A5 for ; Tue, 13 May 2014 06:00:11 -0700 (PDT)
Received: by mail-lb0-f182.google.com with SMTP id q8so240930lbi.13 for ; Tue, 13 May 2014 06:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7FDG7glkYTyw5UC180Y2UM0kFjMY0yCIajEvVZA4ozg=; b=Lk1BDPyV2mLy+Fa4GnJD9pDH5UOhMs99XhdAH4SBbWiyBEFtg7d40469JvGZIMfK6A 4+htmQOX5qMZjy5rcV/lP8CvUBXLrxkWNdeYJaTv3Rji36YsIxLMwC/IRZzriw2OcDyM 5hUWu6uuswNhDcNA+hNoRKNL939nJNWsUt7RW7Oe+f8ZspPZrmdszfd8kOgkT/VPCqUu Wtw3nt6jEDPlUvxRDfvJE0gh0ylT7v6N58eRWU0YUClKsJPx0T/GltjMi6EwNdpXL8GA 13FIvmC+sQEC/JboVloD81jJK6K0wkEufPHlLmMS8aJzaJ7PtM2QDKdTXl6dTQPYd1q1 yMmQ==
MIME-Version: 1.0
X-Received: by 10.112.137.5 with SMTP id qe5mr29052536lbb.16.1399986005014; Tue, 13 May 2014 06:00:05 -0700 (PDT)
Received: by 10.114.5.102 with HTTP; Tue, 13 May 2014 06:00:04 -0700 (PDT)
In-Reply-To: <53711AF6.2080304@gmail.com>
References: <53711AF6.2080304@gmail.com>
Date: Tue, 13 May 2014 09:00:04 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: Gary Mort 
Content-Type: multipart/alternative; boundary=089e0115fd3c84fedb04f947a472
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/5ZgwZ4QKtbrpgz5KayA5T9tcHeE
Cc: "http-auth@ietf.org" 
Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-07.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, 13 May 2014 13:00:14 -0000

--089e0115fd3c84fedb04f947a472
Content-Type: text/plain; charset=ISO-8859-1

Hi Gary,

This is an optional parameter, so systems are not obliged to support it.
Browsers might not support it, but there might be some web services out
there that use it.

So, I am not sure that it would be a good idea to deprecate it.

Regards,
 Rifaat




On Mon, May 12, 2014 at 3:03 PM, Gary Mort  wrote:

>  3.3  The WWW-Authenticate Response Header
>
>
>   " domain
>       A quoted, space-separated list of URIs, as specified in RFC 3986 
>
>       [RFC3986 ], that define the protection space.  If a URI is an
>       abs_path, it is relative to the canonical root URL of the server
>       being accessed. An absolute-URI in this list may refer to a
>       different server than the one being accessed. The client can use
>       this list to determine the set of URIs for which the same
>       authentication information may be sent: any URI that has a URI in
>       this list as a 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 responding server."
>
>  Looking at the source code for both Firefox and Google Chrome - I find
> that this header is ignored by both browsers.  There is an outstanding
> issue for Chrome mentioning that they have assigned this low priority since
> Firefox never supported it.
>
>
> Are there any browsers which support this feature?  If not, it would be
> better to deprecate the feature entirely then document a feature no one
> will support.
>
>
> If the feature is worthwhile[and I happen to think it is] it should be
> placed as an independent RFC.  Moreover, I would recommend that in a
> seperate RFC, the "Domains" option should remain deprecated and be replaced
> with some more explicit options.
>
> As currently written, "Domains" has the same security issues as session
> cookies and cross domain usage.  IE just as allowing one domain to set a
> cookie value for another unrelated domain is a security issue - allowing
> one domain to set an http authentication header for other domains is an
> issue.
>
> -Gary A Mort
>
>

--089e0115fd3c84fedb04f947a472
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Gary,

This is an optional parameter,=
 so systems are not obliged to support it.
Browsers might not sup=
port it, but there might be some web services out there that use it.



So, I am not sure that it would be a good idea to depre=
cate it.

Regards,
=A0Rifaat




On Mon, May 12, 2014 at 3:03 PM, Gary Mort <garyamort@gmail.com><=
/span> wrote:


 =20

   =20
 =20
  

   =20
    


      
3.3 The WWW-Authenticate Re=
sponse Header




    

    


        


        

      

    


      
" domain
      A quoted, space-separated list of URIs, as specified in RFC 3986

      
      [RFC3986], that define the protection=
 space.  If a URI is an
      abs_path, it is relative to the canonical root URL of the server
      being accessed. An absolute-URI in this list may refer to a
      different server than the one being accessed. The client can use
      this list to determine the set of URIs for which the same
      authentication information may be sent: any URI that has a URI in
      this list as a 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 responding server."=


      

      Looking at the source code for both Firefox and Google Chrome - I
      find that this header is ignored by both browsers.=A0 There is an
      outstanding issue for Chrome mentioning that they have assigned
      this low priority since Firefox never supported it.

      

      

      Are there any browsers which support this feature?=A0 If not, it
      would be better to deprecate the feature entirely then document a
      feature no one will support.

      

      

      If the feature is worthwhile[and I happen to think it is] it
      should be placed as an independent RFC.=A0 Moreover, I would
      recommend that in a seperate RFC, the "Domains" option shou=
ld
      remain deprecated and be replaced with some more explicit options.
      

      As currently written, "Domains" has the same security issue=
s as
      session cookies and cross domain usage.=A0 IE just as allowing one
      domain to set a cookie value for another unrelated domain is a
      security issue - allowing one domain to set an http authentication
      header for other domains is an issue.=A0 

      

      -Gary A Mort

      

    

  






--089e0115fd3c84fedb04f947a472--


From nobody Tue May 13 06:02:09 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C011C1A00B5 for ; Tue, 13 May 2014 06:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idUVb1iEVc6Y for ; Tue, 13 May 2014 06:02:03 -0700 (PDT)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by ietfa.amsl.com (Postfix) with ESMTP id C7AD01A00A5 for ; Tue, 13 May 2014 06:02:02 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id mc6so241070lab.21 for ; Tue, 13 May 2014 06:01:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=48SiXFD0SneENo+qA+98bKdp8Kk3g5qitqLBHMSkZNs=; b=oXYVPTbyqK7AdWG+YXfL433paVLodDLm4AoYjfnXIYjbbXO+WsPZjaQ5Moq/EewBCU KZ+fu44OfYxDeSB6zQHij+vWc6zuSM+HlLAJx1oyeUT3or0MukPJPt9lJugG8G8Oyc+g jpVsJ/yTyJ1sIXiPqyesEgge7H6w7GsSLmPqe+wbCWJUis75yEsEkKI/TJBMrHrdHgzD osP4jWDYeVXQVFG9dFghsVnubsQV4doSVorw68XH9T/zIuVdKJVfXpKIpnaLp04LHgQ0 Zzd3oybGxChkl5Npi2MawSVHPM9Ly9exYfdHCx62avWf9vNjj6I8FF9V60W4FMgcWRT5 /GHA==
MIME-Version: 1.0
X-Received: by 10.152.203.236 with SMTP id kt12mr17769671lac.8.1399986115265;  Tue, 13 May 2014 06:01:55 -0700 (PDT)
Received: by 10.114.5.102 with HTTP; Tue, 13 May 2014 06:01:55 -0700 (PDT)
In-Reply-To: <53711D9B.2070804@gmail.com>
References: <53711D9B.2070804@gmail.com>
Date: Tue, 13 May 2014 09:01:55 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: Gary Mort 
Content-Type: multipart/alternative; boundary=001a113455f41747d504f947ab59
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/DawNxAkm9CXadUdP3Nzksczw5NA
Cc: http-auth@ietfa.amsl.com
Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-07.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, 13 May 2014 13:02:04 -0000

--001a113455f41747d504f947ab59
Content-Type: text/plain; charset=ISO-8859-1

I am fine with your proposed change.
If I do not hear any objection, I will make the change in the next version
of the draft.

Regards,
 Rifaat



On Mon, May 12, 2014 at 3:14 PM, Gary Mort  wrote:

>  The documentation for A1 has consistently led to some confusion in implementations.
>
> "
> 3.4.2 A1
>    If the "algorithm" parameter's value is "", e.g. "SHA-
>    256", then A1 is:
>
>         A1       = unq(username) ":" unq(realm) ":" passwd
>       where
>          passwd   = < user's password >
>
>    If the "algorithm" parameter's value is "-sess", e.g.
>    "SHA-256-sess", then A1 is calculated only once - on the first
>    request by the client following receipt of a WWW-Authenticate
>    challenge from the server.  It uses the server nonce from that
>    challenge, and the first client nonce value to construct A1 as
>    follows:
>
>          A1       = H( unq(username) ":" unq(realm)
>                         ":" passwd )
>                         ":" unq(nonce) ":" unq(cnonce)
> "
>
> For either case, A1 can be calculated only once.  IE since
>  unq(username) ":" unq(realm) ":" passwd
>  is fixed for the life of the session, there is no requirement for the client and server to calculate it upon each submission.
>
> Moreover, whether the client is free to calculate A1 only once OR it can calculate A1 for each packet - it just needs to ensure to always use the initial nonce and cnonce if it recalculates the hash.
>
> Just as a start, I would rephrase as:3.4.2 A1
>
>    If the "algorithm" parameter's value is "", e.g. "SHA-
>    256", then A1 is:
>
>          A1       = unq(username) ":" unq(realm) ":" passwd
>
>       where
>
>          passwd   = < user's password >
>
>    If the "algorithm" parameter's value is "-sess", e.g.
>    "SHA-256-sess", then A1 is calculated using the initial nonce and
>    cnounce value from the firstrequest by the client following receipt
>    of a WWW-Authenticate challenge from the server.  It uses the server
>    nonce from that challenge, herin called nonce-prime, and the first
>    client nonce value to construct A1, herin called cnonce-prime as
>    follows:
>
>          A1       = H( unq(username) ":" unq(realm)
>                         ":" passwd )
>                         ":" unq(nonce-prime) ":" unq(cnonce-prime)
>
>    This creates a 'session key' for the authentication of subsequent
>    requests and responses which is different for each "authentication
>    session", thus limiting the amount of material hashed with any one
>    key.  (Note: see further discussion of the authentication session in
>    section 3.6.) Because the server need only use the hash of the user
>    credentials in order to create the A1 value, this construction could
>    be used in conjunction with a third party authentication service so
>    that the web server would not need the actual password value.  The
>    specification of such a protocol is beyond the scope of this
>    specification.
>
>

--001a113455f41747d504f947ab59
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I am fine with your proposed change.
If=
 I do not hear any objection, I will make the change in the next version of=
 the draft.

Regards,
=A0Rifaat




On =
Mon, May 12, 2014 at 3:14 PM, Gary Mort <garyamort@gmail.com> wrote:



 =20

   =20
 =20
  

   =20
    
The documentation for A1 has consistently led to some confusion in implemen=
tations.

"
3.4.2 A1
   If the "algorithm" parameter's value is "<algorith=
m>", e.g. "SHA-
   256", then A1 is:

        A1       =3D unq(username) ":" unq(realm) ":" p=
asswd
      where
         passwd   =3D < user's password >

   If the "algorithm" parameter's value is "<algorith=
m>-sess", e.g.
   "SHA-256-sess", then A1 is calculated only once - on the first
   request by the client following receipt of a WWW-Authenticate
   challenge from the server.  It uses the server nonce from that
   challenge, and the first client nonce value to construct A1 as
   follows:

         A1       =3D H( unq(username) ":" unq(realm)
                        ":" passwd )
                        ":" unq(nonce) ":" unq(cnonce)
"

For either case, A1 can be calculated only once.  IE since=20
 unq(username) ":" unq(realm) ":" passwd
 is fixed for the life of the session, there is no requirement for the clie=
nt and server to calculate it upon each submission.

Moreover, whether the client is free to calculate A1 only once OR it can ca=
lculate A1 for each packet - it just needs to ensure to always use the init=
ial nonce and cnonce if it recalculates the hash.

Just as a start, I would rephrase as:
3.4.2 A1

   If the "algorithm" parameter's value is "<algorith=
m>", e.g. "SHA-
   256", then A1 is:

         A1       =3D unq(username) ":" unq(realm) ":" =
passwd

      where

         passwd   =3D < user's password >

   If the "algorithm" parameter's value is "<algorith=
m>-sess", e.g.
   "SHA-256-sess", then A1 is calculated using the initial nonce =
and=20
   cnounce value from the firstrequest by the client following receipt=20
   of a WWW-Authenticate challenge from the server.  It uses the server=20
   nonce from that challenge, herin called nonce-prime, and the first=20
   client nonce value to construct A1, herin called cnonce-prime as
   follows:

         A1       =3D H( unq(username) ":" unq(realm)
                        ":" passwd )
                        ":" unq(nonce-prime) ":" unq(cn=
once-prime)

   This creates a 'session key' for the authentication of subsequen=
t
   requests and responses which is different for each "authentication
   session", thus limiting the amount of material hashed with any one
   key.  (Note: see further discussion of the authentication session in
   section 3.6.) Because the server need only use the hash of the user
   credentials in order to create the A1 value, this construction could
   be used in conjunction with a third party authentication service so
   that the web server would not need the actual password value.  The
   specification of such a protocol is beyond the scope of this
   specification.



  






--001a113455f41747d504f947ab59--


From nobody Tue May 13 09:40:08 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD331A0115 for ; Tue, 13 May 2014 09:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.979
X-Spam-Level: 
X-Spam-Status: No, score=-0.979 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, MISSING_HEADERS=1.021, 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 SmQQpA4P98Sw for ; Tue, 13 May 2014 09:40:04 -0700 (PDT)
Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 38DF31A0102 for ; Tue, 13 May 2014 09:40:04 -0700 (PDT)
Received: by mail-qc0-f180.google.com with SMTP id i17so749218qcy.11 for ; Tue, 13 May 2014 09:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Lu3NyiMW8nmw3FvsQitmql6aCMS+SkC9YGDpasuBYT8=; b=wb8oDXVmfxqsQxY3b/trWuqukzYudobdd2nneoS3b2xwIwvlhVfhnugrpeunWenFwj AOrpMmwYElCYyJOftN3I/LFw0PdZZKOBO2dEB7RoAj5QI9cKbC25f/YMe7OgB/aWbTpM Cvq0bbnVK772D7kZmkIPFOevrHnqBwk0TzVKYjBV1ji9x4UmHzIglkP7SXRC+WeCq7Qi GyPB8qlDN4JH8Tk7MN1ofHi/WDGc3r7kCtEMtSJIkfIPdZkDRMlQL8y0qu+AEw2fmral f5XSBo1TbRyaB9Nu9ZU/4ADn8dPrvikRfkzD2fNRTuAeetzRkZ4lfLTHpoCKDi89kg4s YxUA==
X-Received: by 10.140.40.239 with SMTP id x102mr47391049qgx.16.1399999197808;  Tue, 13 May 2014 09:39:57 -0700 (PDT)
Received: from ?IPv6:2604:2000:1118:4036:62a4:4cff:fea8:603d? ([2604:2000:1118:4036:62a4:4cff:fea8:603d]) by mx.google.com with ESMTPSA id j110sm9594590qga.40.2014.05.13.09.39.56 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 09:39:57 -0700 (PDT)
Message-ID: <53724ADB.5020400@gmail.com>
Date: Tue, 13 May 2014 12:39:55 -0400
From: Gary Mort 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
CC: "http-auth@ietf.org" 
References: <53711AF6.2080304@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/pkupyEzJxJ28Y1lpK9a1tMQhrYM
Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-07.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, 13 May 2014 16:40:06 -0000

On 05/13/2014 09:00 AM, Rifaat Shekh-Yusef wrote:
> Hi Gary,
>
> This is an optional parameter, so systems are not obliged to support it.
> Browsers might not support it, but there might be some web services 
> out there that use it.
>
> So, I am not sure that it would be a good idea to deprecate it.

Personally, I feel if it is not actively being used, it is better not to 
have it listed in the spec - especially since there are security 
implications to it. While the digest spec is theoretically used for 
transmission of passwords and possibly usernames, in implementation 
nothing restricts the use to passwords and possibly usernames.  For 
example, it can be used to store session id's by redirecting first time 
visitors to sessionid@uri and then responding with a 401 code.   Most 
clients will skip prompting the user for credentials and instead attempt 
to use the designated password as the credentials - creating a session 
id in the header without the use of cookies.

Implementations which support the domain option would then be vulnrible 
to session hi-jacking as other domains can set their session id.

I would tend towards deprecating a feature that is potentially used that 
has a potential security issue.  If there was actual usage of this 
feature, then I would say actual usage trumps potential security issues.

I don't know of any active usage of the Domain feature, so I would 
rather see it removed entirely.  At the very least, by deprecating it in 
a draft you can find out if anyone is using it when they complain.  
Additionally, even if removed, it could be brought back as a seperate 
RFC - especially since the Domain feature is generic enough to be used 
in any of the authentication schemes - there is no reason to limit it to 
only digest mode.


From nobody Tue May 13 09:53:19 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087F51A0087 for ; Tue, 13 May 2014 09:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP8RFJj0SUkO for ; Tue, 13 May 2014 09:53:13 -0700 (PDT)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCC31A0124 for ; Tue, 13 May 2014 09:53:12 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id e16so781967qcx.27 for ; Tue, 13 May 2014 09:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QIk1vVLoKx+lZm7xJNtyL7HkLrJKMEu/MUY5oeRcM0E=; b=QbCC9E3PLilvfGqLfSHq3VvPCoc6vAp+fLMhCYfHj2fzKPUthRLsq+bPIcymZhOKSd LWYng4XALAIgTTG2yYUDG8FR0ux4vRI9JNcWDTOybHbea2eSjUY+5KLz6NSsLlh8ceN5 84rLbP/m6D0lpTvDYFPQl3pZS8x5Sl7J8LCyuyyiJHxA1aQ7OgCivXKwrwuRx6KdAYJO ZdRpWId+61zQwNgWWRrXevtdqoFSe2enaJftBc+TBKufdD2EG/JOlTXo4AlQOFV1SeiZ +l3Y+NuWrVYlxOjSaOqPrbaG31fy3kdDQ3+4eYfe9DIRa69c0WAQ1PPTzHQh1DIvdpU1 b79g==
X-Received: by 10.140.23.7 with SMTP id 7mr47808107qgo.0.1399999986445; Tue, 13 May 2014 09:53:06 -0700 (PDT)
Received: from ?IPv6:2604:2000:1118:4036:62a4:4cff:fea8:603d? ([2604:2000:1118:4036:62a4:4cff:fea8:603d]) by mx.google.com with ESMTPSA id d89sm12293357qga.2.2014.05.13.09.53.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 09:53:05 -0700 (PDT)
Message-ID: <53724DEF.5070603@gmail.com>
Date: Tue, 13 May 2014 12:53:03 -0400
From: Gary Mort 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Julian Reschke , http-auth@ietf.org
References: <5371246E.8020902@gmail.com> <53712622.5070009@gmx.de>
In-Reply-To: <53712622.5070009@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/drMbkkdX874A34XDYICKfWcOIaU
Subject: Re: [http-auth] WWW-Authenticate for 200 Response Codes
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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, 13 May 2014 16:53:15 -0000

On 05/12/2014 03:50 PM, Julian Reschke wrote:
> On 2014-05-12 21:43, Gary Mort wrote:
>> As I read the WWW-Authenticate specs, they /may/ be sent for status
>> codes other then 401.
> Although this is the "http-auth" mailing list, you're in the wrong 
> location. "http-auth" is about defining specific auth schemes.
>
> What's relevant here is the authentication *framework*, and that is 
> defined in the httpbis specs, in particular 
> , 
> to be published as RFC really soon now.

Thanks  - sorry for the confusion and I will redirect my query.

I was playing around with exploring some of the some less well know HTTP 
Auth features recently which led me to this working group - not meaning 
to tred on any toes, I just wanted to confirm my own understandings as 
well as to comment on some of the sections where I found confusion in 
various attempts to implment it via PHP since some versions of IIS and 
some other servers did expect nonce-prime but instead expected the 
current nonce to be used.

The current wording seemed fairly unambigous to me - but if it can be 
made clearer then it saves me time in the future when dealing with 
integration. :-)

-Gary


From nobody Tue May 13 09:56:05 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4536A1A0115 for ; Tue, 13 May 2014 09:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwfAeXF7tMUg for ; Tue, 13 May 2014 09:55:57 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B15271A010C for ; Tue, 13 May 2014 09:55:56 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id pn19so503975lab.34 for ; Tue, 13 May 2014 09:55:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OKJbX1NX87DIBZE4NQuvxGOwuhPkkJhoqAlmspY0PdI=; b=TbxWFJWm1yYxqpuLrWLkpP66VpJVQgxib6WdCtCJwjrKg6OAcYKj2UPTYLJzgc84PM Sx+AQYt49T/mqowM9aHjg3X7cuQi9dnKJeYD8AeB7EZ7q/W0WrLrZc0czMe61hLWwhPc jUmUjRWhhAbYNHKpE0GOGdImiR6b6kTi3tBL6OU1mns8M8EJwN2rPpwXvUyRYmYzSP3C Tu87LPBYEn5eSAUW+wNMrE/hk/ZqZfrYRpfYtlwsudTQmgyN5buqFXtn8PWRjy9BwX7p /UO12Ume93rtACoA5ST2+Lwxb3yOhmSezaCeKXuv/EV66oRMNJvrsR875hecW3U7P/cG HP1g==
MIME-Version: 1.0
X-Received: by 10.112.118.236 with SMTP id kp12mr2314092lbb.56.1400000149759;  Tue, 13 May 2014 09:55:49 -0700 (PDT)
Received: by 10.114.5.102 with HTTP; Tue, 13 May 2014 09:55:49 -0700 (PDT)
In-Reply-To: <53724ADB.5020400@gmail.com>
References: <53711AF6.2080304@gmail.com>  <53724ADB.5020400@gmail.com>
Date: Tue, 13 May 2014 12:55:49 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: Gary Mort 
Content-Type: multipart/alternative; boundary=e89a8f6472cb9caa8504f94aef72
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Dm8QjxFoQxRZOShgT9YX_x3jjQw
Cc: "http-auth@ietf.org" 
Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-07.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, 13 May 2014 16:56:02 -0000

--e89a8f6472cb9caa8504f94aef72
Content-Type: text/plain; charset=ISO-8859-1

I do not have a strong opinion on this issue.
Do other people have an opinion on this?

Regards,
 Rifaat




On Tue, May 13, 2014 at 12:39 PM, Gary Mort  wrote:

>
> On 05/13/2014 09:00 AM, Rifaat Shekh-Yusef wrote:
>
>> Hi Gary,
>>
>> This is an optional parameter, so systems are not obliged to support it.
>> Browsers might not support it, but there might be some web services out
>> there that use it.
>>
>> So, I am not sure that it would be a good idea to deprecate it.
>>
>
> Personally, I feel if it is not actively being used, it is better not to
> have it listed in the spec - especially since there are security
> implications to it. While the digest spec is theoretically used for
> transmission of passwords and possibly usernames, in implementation nothing
> restricts the use to passwords and possibly usernames.  For example, it can
> be used to store session id's by redirecting first time visitors to
> sessionid@uri and then responding with a 401 code.   Most clients will
> skip prompting the user for credentials and instead attempt to use the
> designated password as the credentials - creating a session id in the
> header without the use of cookies.
>
> Implementations which support the domain option would then be vulnrible to
> session hi-jacking as other domains can set their session id.
>
> I would tend towards deprecating a feature that is potentially used that
> has a potential security issue.  If there was actual usage of this feature,
> then I would say actual usage trumps potential security issues.
>
> I don't know of any active usage of the Domain feature, so I would rather
> see it removed entirely.  At the very least, by deprecating it in a draft
> you can find out if anyone is using it when they complain.  Additionally,
> even if removed, it could be brought back as a seperate RFC - especially
> since the Domain feature is generic enough to be used in any of the
> authentication schemes - there is no reason to limit it to only digest mode.
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth
>

--e89a8f6472cb9caa8504f94aef72
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I do not have a strong opinion on this issue.
Do other=
 people have an opinion on this?

Regards,
=A0Rifaat





On Tue, May 13, 2014 at 12:39 PM, Gary M=
ort <garyamort@gmail.com> wrote:




On 05/13/2014 09:00 AM, Rifaat Shekh-Yusef wrote:



Hi Gary,



This is an optional parameter, so systems are not obliged to support it.
Browsers might not support it, but there might be some web services out the=
re that use it.



So, I am not sure that it would be a good idea to deprecate it.





Personally, I feel if it is not actively being used, it is better not to ha=
ve it listed in the spec - especially since there are security implications=
 to it. While the digest spec is theoretically used for transmission of pas=
swords and possibly usernames, in implementation nothing restricts the use =
to passwords and possibly usernames. =A0For example, it can be used to stor=
e session id's by redirecting first time visitors to sessionid@uri and =
then responding with a 401 code. =A0 Most clients will skip prompting the u=
ser for credentials and instead attempt to use the designated password as t=
he credentials - creating a session id in the header without the use of coo=
kies.




Implementations which support the domain option would then be vulnrible to =
session hi-jacking as other domains can set their session id.



I would tend towards deprecating a feature that is potentially used that ha=
s a potential security issue. =A0If there was actual usage of this feature,=
 then I would say actual usage trumps potential security issues.



I don't know of any active usage of the Domain feature, so I would rath=
er see it removed entirely. =A0At the very least, by deprecating it in a dr=
aft you can find out if anyone is using it when they complain. =A0Additiona=
lly, even if removed, it could be brought back as a seperate RFC - especial=
ly since the Domain feature is generic enough to be used in any of the auth=
entication schemes - there is no reason to limit it to only digest mode.



_______________________________________________

http-auth mailing list

http-auth@ietf.org<=
/a>

https://www.ietf.org/mailman/listinfo/http-auth





--e89a8f6472cb9caa8504f94aef72--


From nobody Thu May 15 13:30:05 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10721A0191 for ; Thu, 15 May 2014 13:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.795
X-Spam-Level: **
X-Spam-Status: No, score=2.795 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 p6udrBKvw_gR for ; Thu, 15 May 2014 13:30:01 -0700 (PDT)
Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64141A0158 for ; Thu, 15 May 2014 13:30:01 -0700 (PDT)
Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1Wl2Ho-0007Y9-Uj; Thu, 15 May 2014 16:29:53 -0400
Message-ID: <537523C0.3050300@digitalbazaar.com>
Date: Thu, 15 May 2014 16:29:52 -0400
From: Manu Sporny 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131103 Icedove/17.0.10
MIME-Version: 1.0
To: Melvin Carvalho 
References: <536BFA23.9020900@digitalbazaar.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/yor0vCALdiF7BdteODI9x6MfVNQ
Cc: Julian Reschke , Mark Nottingham , IETF HTTP Auth , Web Payments CG 
Subject: Re: [http-auth] Review Request for third draft of "Signing HTTP Messages"
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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 May 2014 20:30:03 -0000

On 05/08/2014 06:53 PM, Melvin Carvalho wrote:
> One thing, I'm slightly confused as to how algorithms should be
> specified.
> 
> For example: SHA256 Appears in the document and both lower case and
> upper case. It also appears both with a hyphen and without a hyphen. 
> I'm also currently using sha-256 as specified in RFC 6920

It depends on where you're using it.

If you use it in the Digest header, it's "SHA-256" per RFC 5843:
http://tools.ietf.org/html/rfc5843#section-1.1

If you use it in the algorithm parameter of the Signature header or Auth
scheme, or you're specifying a particular signature algorithm, you
should use the value out of the signature algorithm registry:

http://tools.ietf.org/id/draft-cavage-http-signatures-02.html#rfc.appendix.E.2

> I'd like to start using things like ECDSA signature as defined in
> crypto currencies, but I am finding it challenging to find an easy to
> spot pattern in the naming.
> 
> Any guidance would be appreciated.

I spent a lot of time looking at how this sort of stuff is specified and
I couldn't see a pattern. Most of the RFC authors just specify the
values in the documents themselves. I also searched the entire IANA
registry for generic signature or hashing algorithm registries and
didn't find anything. Some do exist, but they tend to be very specific
to particular technologies (like TLS). Perhaps someone more
knowledgeable in this area, like Julian, could shed some light on a
general registry for hashing or signing algorithms.

If there are none, the spec requests that IANA create one here:

http://tools.ietf.org/id/draft-cavage-http-signatures-02.html#rfc.appendix.E.2

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/


From nobody Sun May 18 05:40:24 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B981A0069 for ; Sun, 18 May 2014 05:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.649
X-Spam-Level: 
X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiVhD_EPqrEX for ; Sun, 18 May 2014 05:40:18 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id BE7EE1A0056 for ; Sun, 18 May 2014 05:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1400416816; d=isode.com; s=selector; i=@isode.com; bh=KHJt1Qi+AzkLWgx0C72vndU+Wld4p8CqGL1W1O6O1tM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=bIKigJmRq/b3DJbQdRhsR4Ts8sl6Z8L/IxWIKHrxUBpJ04zMK2ilxVzu3ULgErOu7yVZHt oLWYMcxrMvjcqdgTVvi9pSPDhKEi6outxyiw4byBo0st2IWFAA3orRSpZcpP3ml/x59Z5h qNbSne6uXccPSd5P1AxHczbuDTRmyik=;
Received: from [192.168.0.7] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25])  by waldorf.isode.com (submission channel) via TCP with ESMTPA  id ; Sun, 18 May 2014 13:40:15 +0100
Message-ID: <5378AA5F.6000201@isode.com>
Date: Sun, 18 May 2014 13:41:03 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
To: Tony Hansen 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/z0y1XU7OgMgEsbvVT7iiKHQoV80
Cc: http-auth@ietf.org
Subject: Re: [http-auth] a review of draft-ietf-httpauth-scram-auth
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 May 2014 12:40:21 -0000

Hi Tony,
Sorry for the very slow response on this.
(Also, I discovered that I got unsubscribed from the http-auth mailing 
list, so I reconstructed your email message from the web archive.)

Firstly, thank you very much for your review and comment.
> I just recently finished an implementation of SCRAM support in another
> protocol that is almost identical to HTTP, so my wounds there are rather
> fresh. This is a review of Salted Challenge Response (SCRAM) HTTP
> Authentication Mechanism, draft-ietf-httpauth-scram-auth. (In what
> follows, I'll refer to this version of SCRAM as "HTTP SCRAM" and that in
> RFC 5802 as "SASL SCRAM".) In the following, I raise a large number of
> points about this draft in particular, along with some points related to
> HTTP auth in general.
>
>       Tony Hansen
>
> As I was re-reading this draft, my thoughts kept getting drawn to these
> questions:
>
> 1) what is different in HTTP SCRAM from the original SASL SCRAM
> documented in RFC 5802?
> 2) hash agility
> 3) method agility
>
>
>
> 1. What is different in HTTP SCRAM from the original SASL SCRAM
> documented in RFC 5802?
>
> When a new version of a spec is created by copying such a large portion
> of another protocol document, as this document was from RFC 5802,
> someone who has implemented the earlier protocol or who has a library
> that implements the earlier protocol needs to be concerned about the
> differences between this new incarnation and the previous incarnation.
> If you do a diff between this draft and RFC 5802 (such as using
> tools.ietf.org/rfcdiff), you will see many gratuitous differences (eg
> "left side" vs "left-side", "that" vs "which") whose very quantity could
> hide the actual differences.
I think these are because I started from my pre-SCRAM-as-RFC-publication 
draft versa the final SCRAM RFC...
> First off, get rid of the gratuitous differences! If the copied text is
> going to be kept, make it easy to diff the two.
>
> Now note: actual differences do exist. In particular, I noted several
> specific differences, although I may have missed some:
>
> a) The specification of the gs2 header is different. It has been
> "adjusted" to match the name=value format of www-authenticate's
> 1#challenge. In addition, the use of authzid has been lost. For example,
> in SASL SCRAM the gs2-header uses "p=channel,authzid," and in HTTP
> SCRAM, gs2-header uses "g=p=channel," with no way to specify authzid.
> b) The handling of white space and double quotes.
>
> The consequence of these substantive differences is that existing
> implementations of SASL SCRAM can NOT be used to implement HTTP SCRAM.
> Personally I think that this is a bad consequence.
>
> There are two fixes for going forward:
>
> A) Accept that there are differences. If we do this, I feel that there
> MUST MUST MUST be a serious WARNING section added for implementers to
> let them know that current SASL SCRAM libraries can NOT be used.
One way to handle the differences is to canonicalize SCRAM HTTP 
challenges/responses (strip WSP between parameters, reorder them in the 
order prescribed by SCRAM) before passing canonicalized results to the 
SCRAM library.

And any data generated by SASL SCRAM is pretty much valid HTTP syntax 
(other then the gs2 header and the authorization identity).

However I do find your proposal to just base64 data to be tempting.
> B) Get rid of these differences. See below.
>
> Regarding the handling of white space, one of the hardest parts to get
> right with SCRAM is getting the inputs into the hash algorithms exactly
> right, on BOTH sides. For example, if one side includes a space and the
> other side does not, then the hashes will not match.
Right. See above.
> If you look at the ABNF for "challenge" (HTTP-P7, HTTP-P1) and the ABNF
> for the elements for the name=value pairs in HTTP SCRAM, you will find
> that they are not compatible. The HTTP definition is a superset in that
> it allows for the use of quoted strings and allows for white space to be
> included in various locations, neither of which are allowed by the ABNF
> for the SCRAM-specific elements. I don't think that the ABNF for
> auth-param is compatible at all with gs2-header p= option because
> token68 does not allow an "=".
>
> The examples all use copious white space both between parameters and
> beginnings and ends of multiple lines, as well as the line breaks
> themselves. At a minimum, there need to be a note about this difference,
> as well as a requirement that all white space must be stripped before
> doing any hashing. Or see my note below on eliminating the differences.
>
> As for the quotation marks, there are a couple possibilities. The most
> correct would be to change the ABNF for ALL of the SCRAM elements to be
> compatible with the ABNF for "challenge". This is also required to
> satisfy the gs2-header issue mentioned above. Or see my note below on
> eliminating the differences.
Right.
> The loss of authz is potentially troublesome. I know that HTTP hasn't
> included this concept before, so anyone who has needed this concept has
> had to implement it below HTTP or using a non-standard HTTP header.
> There is discussion of the use of authz elsewhere on the httpauth list.
> One way to correct this is to provide a new "z=" parameter (to pick
> that is allowed as part of gs2-header. NOTE: this further breaks
> compatibility with stock SCRAM implementations. Or see my note below on
> eliminating the differences.
I personally don't object to keeping the authorization identity, but it 
would be good to hear other opinions on this.
> There is no ABNF for the sid value or any constraints on it.
I am hoping that this can be extracted to a separate document, which can 
be shared by all authentication mechanisms.

But either way, I agree that this should be defined.
> 2) Hash agility
>
> HTTP SCRAM is defining a >family< of authentication schemes whose names
> all start with "SCRAM-" and end with a hash value.
>
> a) The ABNF for challenge-scram and credentials-scram are wrong. They
> both specify "SCRAM-SHA-1" as the only string that can be used. Instead
> they should say something like:
>
>       challenge-scram    = scram-name 1*SP 1#auth-param
>       credentials-scram  = scram-name 1*SP 1#auth-param
>
>       scram-name = "SCRAM-SHA-1" / other-scram-name
>           ; SCRAM-SHA-1 is registered by this RFC
>       other-scram-name = "SCRAM-" hash-name
>           ; hash-name is a capitalized form of names from IANA "Hash
> Function Textual Names" registry.
>           ; Additional SCRAM names must be registered in both the IANA
> "SASL mechanisms" registry
>           ; and the IANA "authentication scheme" registry.
>
> The comments about sasl name and hash name registry come from RFC 5802.
>
> It MIGHT be worth mentioning the potential use of SCRAM-SHA-256 in the
> future, but I'm not going to get hung up on this.
Ok. I have no objections to multiple SCRAM mechanisms.
> Actually, the ABNF shown in section 5 and aboe is incorrect as shown
> because auth-param is actually optional when there is no realm. A better
> description might be
>
>       challenge-scram = scram-name (1*SP 1#auth-param)
>       credentials-scram = scram-name (1*SP 1#auth-param)
>
>
>
>
> 3) method agility
>
> Unless I'm totally mistaken, the issues with method agility are
> associated with the protocol exchange example shown in section 5 is
> incorrect with respect to the realm and the description of the original
> 401 Unauthorized challenge along with subsequent descriptions of the realm.
>
> I think it's worth showing a *complete* example 401 challenge exchange,
> filling in the "server might have returned 401 Unauthorized first"
> comment. THIS is where the server might provide one or more realm names
> as part of its challenge. For example, you might see:
>
>       WWW-Authenticate: Basic  Digest realm="realm1"
>           Digest realm="realm2" Digest realm="realm3"
>           SCRAM-SHA-1 realm="realm3" SCRAM-SHA-1 realm="realm4"
>
> In this example, the user may authenticate using Basic with no realm,
> using Digest in realms 1, 2 or 3, and using SCRAM-SHA-1 using realms 3 or 4.
>
> The first client response that includes a WWW-Authenticate header then
> specifies the authentication scheme along with the optional realm that's
> been chosen and any additional parameters needed for the specific
> authentication scheme.
Right.
> The interesting new thing about SCRAM-SHA1 as an authentication scheme
> is that it is the first one that has multiple rounds. The server
> challenge that comes back from an authentication scheme that requires
> such multiple rounds should NOT specify the realm parameter again, nor
> should subsequent client responses include the realm parameter again.
>
>         [...The server might have returned 401 Unauthorized first...]
>         S: WWW-Authenticate: Basic
>               Digest realm="realm1@host.com"
>               Digest realm="realm2@host.com"
>               Digest realm="realm3@host.com"
>               SCRAM-SHA-1 realm="realm3@host.com"
>               SCRAM-SHA-1 realm="testrealm@host.com"
>         S: [...]
>
>         C: GET /resource HTTP/1.1
>         C: Host: server.example.com
>         C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com",
>                g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL
>         C: [...]
>
>         S: HTTP/1.1 401 Unauthorized
>         S: WWW-Authenticate: SCRAM-SHA-1
>                sid=AAAABBBBCCCCDDDD,
> r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
>                i=4096
>         S: [...]
>
>         C: GET /resource HTTP/1.1
>         C: Host: server.example.com
>         C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD,
>                c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
>                p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
>         C: [...]
>
>         S: HTTP/1.1 200 Ok
>         S: Authentication-Info: SCRAM-SHA-1
>                sid=AAAABBBBCCCCDDDD,
>                v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
>         S: [...Other header fields and resource body...]
>
> The description of the realm parameter(s) need to be adjusted to reflect
> when the server and client send it/them.
>
> It might be worth introducing SOMEWHERE the terms "challenge #0" as the
> server challenge that lists the acceptable authentication schemes and
> their optional realms, and then the client response is "response #1"
> followed by "challenge #1", and counting up from there. In general
> terms, challenge #0 always lists the available authentication schemes
> and their optional realms (along with any other initial parameters that
> need to be passed along with that authentication scheme). Response #1
> specifies the next round of parameters for the given authentication
> scheme chosen by the client. Challenge #1 either returns the 200 with an
> optional Authorization-Info or another 401 Unauthorized with a
> WWW-Authenticate header. If this is an authentication scheme that allows
> another round to be used for additional information, Challenge #1 would
> also include a sid= parameter (or WWW-Authentication-Sid header as has
> been suggested elsewhere). Subsequent Responses (#2 and beyond) then use
> the same sid=/WWW-Authentication-Sid value to tie the challenges and
> response together.
>
> I'm not sure where SOMEWHERE should be. Is it too late to get this into
> HTTP BIS P7?
>
>
>
>
>
>
>
>
> Getting Rid of the Differences with SASL SCRAM
>
> Now I'm going to present an alternative way of fixing some of the
> problems above. The basic idea is to say that the SCRAM-SHA-1 payloads
> are exactly as specified in RFC 5802, but are base64-encoded for use
> within HTTP. This is exactly the SASL authentication split that is used
> by all other application protocols that use SASL: the SASL mechanism
> specifies what information needs to be included in any given round of
> exchange and the application protocol specifies how that information is
> wrapped for transmission within the application protocol. For example,
> an application protocol could use base64 encoding of that data (as
> suggested here), or could use run-length-encoding if it's binary, or
> could use quoted-printable or hex or whatever. The important thing is
> that is a strict separation of responsibility. The application protocol
> doesn't care what the data is and what is included within it; it just
> has some mechanism for getting that data across the protocol boundary
> safely. The application protocol restores that data back to its octet
> form and passes that data into the authentication mechanism. The
> response from the authentication mechanism is then encoded for the
> application-layer response.
>
> How does this look for HTTP SCRAM? I'm going to use the word "payload"
> to represent the parameter that holds the SCRAM-SHA-1 payload. Each
> challenge and response becomes 1) the scram name, 2) either the realm or
> sid value, and then 3) the payload value. (I don't care what the
> parameter name is called.) In ABNF, this would be something like this:
>
>       challenge-scram   = scram-name WS realm-or-sid BWS "," OWS
> "payload=" payload-value
>       credentials-scram   = scram-name WS realm-or-sid BWS "," OWS
> "payload=" payload-value
>       realm-or-sid = ( "realm=" realm-value / "sid=" sid-value )
>       payload-value = 1*base64 / DQUOTE 1*base64 DQUOTE
>
> If "sid=" were moved out to a different header, then the above would become
>
>       challenge-scram   = scram-name WS [realm BWS ","] OWS "payload="
> payload-value
>       credentials-scram   = scram-name WS [realm BWS ","] OWS "payload="
> payload-value
>       realm-spec = "realm=" realm-value
>       payload-value = 1*base64 / DQUOTE 1*base64 DQUOTE
>       session-id-header = "WWW-Authentication-ID:" *SP session-id
>       session-id = token
>
>
> All of the rest of the document that provides details on what is
> included within that payload would be removed and replaced with a
> reference to RFC 5802 and a small section on how HTTP authentication
> credentials map into the SASL concepts of authentication id,
> authorization id, etc.
I wouldn't mind doing this. One concern I had is that whenever web 
developers see "GSS-API" (e.g. in RFC 5802), they might freak-out. So I 
was trying to avoid references to unusual terminology. But hopefully 
what you suggest would work.
> The document would still only register SCRAM-SHA-1.
>
>
>
>
> Generalizing Just a Bit Further
>
> An interesting consequence of this modification is that it is extremely
> close to what would be needed to generalize HTTP authentication to using
> any given SASL mechanism that is duly registered and supported by the
> server.
>
> The first editing step is to change the ABNF names used above from
> scram-name to sasl-name.
>
> The only other required change is noting somewhere that challenge#0 MAY
> include an optional payload if that particular authentication mechanism
> has a payload value that is to be sent first from the server to the
> client. (Just as Digest has a variety of parameters that are transmitted
> along with challenge#0.)
>
> There might be a constraint placed on the non-use of SASL security
> layers and restricting the set of SASL mechanisms only to those that do
> not require a security layer to be used.
That might be of interest in the future. I used to have a draft on this 
over 10 years ago :-).
> And I think that that's it.
>
>
> I hope this is of use.
It is very much is.


From nobody Sun May 18 17:34:05 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5E81A0230 for ; Sun, 18 May 2014 17:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.098
X-Spam-Level: 
X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6t0peKzoUEm for ; Sun, 18 May 2014 17:34:01 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10431A0229 for ; Sun, 18 May 2014 17:34:00 -0700 (PDT)
Received: from [192.168.1.57] (unknown [118.209.226.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CABF0509B6; Sun, 18 May 2014 20:33:54 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Mark Nottingham 
In-Reply-To: <536BFA23.9020900@digitalbazaar.com>
Date: Mon, 19 May 2014 10:33:59 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <44475C73-A79F-4C54-A09D-A9842FD49CA2@mnot.net>
References: <536BFA23.9020900@digitalbazaar.com>
To: Manu Sporny 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/QXbde77yeufyiYrATUNok1zZcgg
Cc: "Julian F. Reschke" , IETF HTTP Auth , Web Payments CG 
Subject: Re: [http-auth] Review Request for third draft of "Signing HTTP Messages"
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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, 19 May 2014 00:34:03 -0000

Hi Manu,

This is looking pretty good IMO.

A bit more feedback:

* I think you need to strip out all of the motivation text (i.e., =
substantial portions of 1.x); it makes claims that are hard to justify =
about how this helps with pervasive monitoring, and it also omits a lot =
of other potential uses for the spec. Just keep it simple.

* Section 2.1.3 - Is Date the default value if no =91headers=92 is =
specified, or is it always in the set of headers? It isn=92t clear from =
this text.

* Section 2.3. - How is whitespace around field-values handled =97 is it =
included in the value or not? Note that as per =
, it isn=92t (but it would be good if you made this explicit, both in =
spec and with examples)

* Section 2.3 - Request-line is HTTP/1 specific, and =97 again =97 the =
HTTP version is a hop-by-hop attribute of the message, so you=92re going =
to get signature failures through intermediaries. Suggestion: use =
HTTP/2=92s :method, :authority and :path pseudo-headers.

* Can trailers be included in a signature? Can a Signature header be =
included in the message trailers?

* You talk (often implicitly) about how a signature is created, but not =
what constitutes a valid signature. This is going to be especially =
important for the authentication scheme.



On 9 May 2014, at 7:41 am, Manu Sporny  =
wrote:

> After feedback from Mark Nottingham[1], Julian Reschke[2], folks in =
the
> HTTP Auth WG, and people in the Web Payments CG, we've modified the =
HTTP
> Signatures specification in the following ways:
>=20
> 1. The specification has been renamed to "Signing HTTP Messages".
> 2. The specification now covers both a signature-based Authorization
>   mechanism (client-to-server) as well as a general mechanism to sign
>   HTTP messages (client-to-server and server-to-client).
> 3. A new "Signature" header has been introduced.
> 4. The layout has been modified heavily to streamline the information
>   conveyed in the spec.
> 5. New registries have been created for the algorithms referred to in
>   the specification.
> 6. We're now more specific in the way certain canonicalizations are
>   performed.
> 7. More examples have been added, including how to digitally sign
>   the body of an HTTP message.
>=20
> The basic mechanism of generating the signatures has not changed (and
> has been stable for over a year).
>=20
> The newest spec can be found here:
>=20
> http://tools.ietf.org/html/draft-cavage-http-signatures-02
>=20
> The diff is here:
>=20
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-cavage-http-signatures-02.txt=

>=20
> Matt, Yoav, Kathleen, if there are no show stopping review comments, =
I'd
> like to push this spec onto the RFC track in the HTTP Auth WG, or
> HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize =
that
> HTTP Auth may be shutting down next month, so what's the next step to
> get the HTTP Signatures spec further down the IETF RFC track?
>=20
> -- manu
>=20
> [1] =
http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html
> [2] =
http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.html
>=20
> --=20
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/

--
Mark Nottingham   http://www.mnot.net/




From gruberda@student.ethz.ch  Sun May 18 23:31:53 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6AB1A02F6 for ; Sun, 18 May 2014 23:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level: 
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WVO8151UOIR for ; Sun, 18 May 2014 23:31:51 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B71D1A02F4 for ; Sun, 18 May 2014 23:31:50 -0700 (PDT)
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 19 May 2014 08:31:46 +0200
Received: from [192.168.1.74] (84.73.206.78) by mail.ethz.ch (172.31.38.212) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 19 May 2014 08:31:48 +0200
Message-ID: <5379A554.9000200@student.ethz.ch>
Date: Mon, 19 May 2014 08:31:48 +0200
From: Damian Gruber 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: 
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [84.73.206.78]
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/87UArIOIWuvbSvBpLFhrZi2yf0c
Subject: [http-auth]  - Debugging and Firefox
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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, 19 May 2014 06:33:29 -0000

Hi,


I'm implementing a server which does digest access authentication, 
accroding to RFC 2617.
Unfortunately I don't have an (implemented) corresponding client, which 
makes debugging and testing a bit difficult.
Therefore, I'm using Firefox as a user agent, to get at least a bit of 
information.

I hit on three problems, could you have a look at them?

1) It seems that if my server sends out a wrong rspauth-field in the 
Authentication-Info header, a user using Firefox does not get informed 
that the server didn't properly authenticate itself.
Is this true?
Does Firefox even check whether the rspauth-field is as expected?

2) If the user tries to access "/login", the server sends back a 
response which contains the following field in the WWW-Authenticate header:
domain="/login /protected"
After a successful authentication, the user then tries to access this url
"/public/area/"
Firefox also sends the Authorization header for this request, even if 
this url is not in the list from the WWW-Authenticate header, right?

3) Is there some debug output from Firefox, which I can access?


Thanks!


From nobody Mon May 19 10:24:13 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294621A037C for ; Mon, 19 May 2014 10:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.288
X-Spam-Level: 
X-Spam-Status: No, score=-0.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=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 mqPcLPI-mwtP for ; Mon, 19 May 2014 10:24:09 -0700 (PDT)
Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315561A0387 for ; Mon, 19 May 2014 10:24:04 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id e16so9593661qcx.14 for ; Mon, 19 May 2014 10:24:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=ciA6QcIS7aabkqw7vlMJBNqc6yljzPbklt5BL4cxqkk=; b=AYo2v4jSbd47Uc/XSjlwZ1XFdM7jKRMGES90anrB7gz83cn3fXnWMnscnPJdv69tPn khsl+bkrClIDMfsyjMG5y9jNp1RCSPNuQ8yJ8K//gDYgqvQBby+r7whp8YOMwvzXFcS7 pwbOTdhGzM+O60cX3nL5eHCZgAdBPt36GzjN0UQDSqzINu80jvx8D35U9fDOtPnK9/mx KUUfkjcerY3zR70iBCt7w6g3yVgkt8e7tTZTKWuG4wSYDBF/xR21bix8A5UI2PfNFONK ch7p9AjXXbsDh0SMtVLShJqSPnwbnZinD9rGdYeE+cZy290nhBh3O4P9a4EmzhqZ5L9u 0dPQ==
X-Received: by 10.224.167.132 with SMTP id q4mr50144784qay.77.1400520243590; Mon, 19 May 2014 10:24:03 -0700 (PDT)
Received: from ?IPv6:2604:2000:1118:4036:62a4:4cff:fea8:603d? ([2604:2000:1118:4036:62a4:4cff:fea8:603d]) by mx.google.com with ESMTPSA id k9sm28488095qaj.25.2014.05.19.10.24.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 10:24:02 -0700 (PDT)
Message-ID: <537A3E2E.6000609@gmail.com>
Date: Mon, 19 May 2014 13:23:58 -0400
From: Gary Mort 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Damian Gruber , http-auth@ietf.org
References: <5379A554.9000200@student.ethz.ch>
In-Reply-To: <5379A554.9000200@student.ethz.ch>
Content-Type: multipart/alternative; boundary="------------050008000203020701020404"
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Q6BzZEozrGo2JcA5GgV4i-WEdCM
Subject: Re: [http-auth] - Debugging and Firefox
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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, 19 May 2014 17:24:11 -0000

This is a multi-part message in MIME format.
--------------050008000203020701020404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 05/19/2014 02:31 AM, Damian Gruber wrote:
> Hi,
>
>
> I'm implementing a server which does digest access authentication, 
> accroding to RFC 2617.
> Unfortunately I don't have an (implemented) corresponding client, 
> which makes debugging and testing a bit difficult.
> Therefore, I'm using Firefox as a user agent, to get at least a bit of 
> information.
>
> I hit on three problems, could you have a look at them?
>
> 1) It seems that if my server sends out a wrong rspauth-field in the 
> Authentication-Info header, a user using Firefox does not get informed 
> that the server didn't properly authenticate itself.
> Is this true?
> Does Firefox even check whether the rspauth-field is as expected?
Don't know, but the code is found here: 
http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpDigestAuth.cpp#161

Considering that there are lots of comments like

215        // we do not support auth-int "quality of protection" currently


and

226    #if0



I'd say it's safe to say that client authentication of the server is 
broken in many ways.


All of this links back to "generateCredentials"

91        string    generateCredentials  (in     nsIHttpAuthenticableChannel    aChannel  ,


I've noticed that in the google chrome code, there is a lot of 
over-reliance on the cache - and that anytime credentials aren't 
returned by some authentication handler, chrome will fall back to 
pulling the last data from the cache.  So as long as the last data in 
the cache will be accepted by the server, it will keep going.

I haven't done a lot of work with the Firefox code.

Another oddity I found in the chrome code[which was mainly copied from 
the firefox code] is that for a given domain name, the browser will only 
cache one set of credentials.

Ie credentials cached for http://www.example.com/~bob , realm="bobs 
virtual server"

After connecting to htttp://www.example.com/~alice, realm="alices 
virtual server"

The credentials for bob's virtual server are lost and will have to be 
re-entered.


>
> 2) If the user tries to access "/login", the server sends back a 
> response which contains the following field in the WWW-Authenticate 
> header:
> domain="/login /protected"
> After a successful authentication, the user then tries to access this url
> "/public/area/"
> Firefox also sends the Authorization header for this request, even if 
> this url is not in the list from the WWW-Authenticate header, right?

Both Chrome and Firefox ignore the Domain header, see 
https://code.google.com/p/chromium/issues/detail?id=74590&q=http%20auth%20digest&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified


>
> 3) Is there some debug output from Firefox, which I can access?
>


There are a few auth extensions already written in the extension directory.
For example, here is some code:
https://addons.mozilla.org/en-us/firefox/files/browse/130396/file/chrome/content/overlay.js#top

Basically, just write a small extension which listens for the "load", 
"unload", and "http_on_modify_request" events and then you can set your 
javascript debugger to break at those function points in your extension 
and examine what header fields are set at those points.


--------------050008000203020701020404
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 05/19/2014 02:31 AM, Damian Gruber
      wrote:

    

    
Hi,
      

      

      

      I'm implementing a server which does digest access authentication,
      accroding to RFC 2617.
      

      Unfortunately I don't have an (implemented) corresponding client,
      which makes debugging and testing a bit difficult.
      

      Therefore, I'm using Firefox as a user agent, to get at least a
      bit of information.
      

      

      I hit on three problems, could you have a look at them?
      

      

      1) It seems that if my server sends out a wrong rspauth-field in
      the Authentication-Info header, a user using Firefox does not get
      informed that the server didn't properly authenticate itself.
      

      Is this true?
      

      Does Firefox even check whether the rspauth-field is as expected?
      

    

    Don't know, but the code is found here:
http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpDigestAuth.cpp#161

    

    Considering that there are lots of comments like

    
    
215     // we do not support auth-int "quality of protection" currently


    

    and

    
    
226 #if 0


    

    

    I'd say it's safe to say that client authentication of the server is
    broken in many ways.

    

    

    All of this links back to "generateCredentials" 

    
    
91     string generateCredentials(in    nsIHttpAuthenticableChannel 
aChannel,

    

    I've noticed that in the google chrome code, there is a lot of
    over-reliance on the cache - and that anytime credentials aren't
    returned by some authentication handler, chrome will fall back to
    pulling the last data from the cache.  So as long as the last data
    in the cache will be accepted by the server, it will keep going.

    

    I haven't done a lot of work with the Firefox code.

    

    Another oddity I found in the chrome code[which was mainly copied
    from the firefox code] is that for a given domain name, the browser
    will only cache one set of credentials.

    

    Ie credentials cached for http://www.example.com/~bob , realm="bobs
    virtual server"

    

    After connecting to htttp://www.example.com/~alice, realm="alices
    virtual server"

    

    The credentials for bob's virtual server are lost and will have to
    be re-entered.

    

    

    

      

      2) If the user tries to access "/login", the server sends back a
      response which contains the following field in the
      WWW-Authenticate header:
      

      domain="/login /protected"
      

      After a successful authentication, the user then tries to access
      this url
      

      "/public/area/"
      

      Firefox also sends the Authorization header for this request, even
      if this url is not in the list from the WWW-Authenticate header,
      right?
      

    

    

    Both Chrome and Firefox ignore the Domain header, see
https://code.google.com/p/chromium/issues/detail?id=74590&q=http%20auth%20digest&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

    

    

    

      

      3) Is there some debug output from Firefox, which I can access?
      

      

    

    

    

    There are a few auth extensions already written in the extension
    directory. 

    For example, here is some code:

https://addons.mozilla.org/en-us/firefox/files/browse/130396/file/chrome/content/overlay.js#top

    

    Basically, just write a small extension which listens for the
    "load", "unload", and "http_on_modify_request" events and then you
    can set your javascript debugger to break at those function points
    in your extension and examine what header fields are set at those
    points.

    

  


--------------050008000203020701020404--


From nobody Mon May 19 11:43:32 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD581A0156 for ; Mon, 19 May 2014 11:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y13tkSNHwtkf for ; Mon, 19 May 2014 11:43:29 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F87C1A00EA for ; Mon, 19 May 2014 11:43:29 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id x13so8367945wgg.22 for ; Mon, 19 May 2014 11:43:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jE2AE4eIYyTFnLdc3PWv6eoFqHX/ActEwxHNL8vmT4w=; b=Ja/G4m2P92CXPB6xJ4/eTmQdzlD8GLwexyE9U8VOLT2sCyBgaXOtah5JZ1QkprOzP4 3+sR4eju06GWvj7R8KvqOS7RfCd5cWzLcdnDeV1jemGQKLkfXbhLBWRVJDv6CsDZ3CKV 669i5QdU7d8rAYdghgkufGvTNkkK9FDPM3fqWsgd0OjmQ2+4l4uVYsGAj6RYQ4xHrlPZ vAUMgx34EHK1813KGnr9QkxbFwAxBJ9+JzBf8F8KgWAv+DzIm7/Vfp8G7fBZKwhsrgIA +yfPppkYH+2gJbmOaDBeKvb4JWRM4R9POVKp7M1v+eBJa+SeyesOXl2xIvMZWTIELp8N onFQ==
MIME-Version: 1.0
X-Received: by 10.194.94.202 with SMTP id de10mr3658329wjb.84.1400525007712; Mon, 19 May 2014 11:43:27 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Mon, 19 May 2014 11:43:27 -0700 (PDT)
In-Reply-To: <537A3E2E.6000609@gmail.com>
References: <5379A554.9000200@student.ethz.ch> <537A3E2E.6000609@gmail.com>
Date: Mon, 19 May 2014 11:43:27 -0700
Message-ID: 
From: Martin Thomson 
To: Gary Mort 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/IfHDd0HRiwG5K-JQd69VF2K_x0A
Cc: http-auth@ietf.org
Subject: Re: [http-auth] - Debugging and Firefox
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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, 19 May 2014 18:43:30 -0000

This is the wrong forum for this discussion.  If you have concrete
issues, might I suggest that you take those to
https://bugzilla.mozilla.org/.

On 19 May 2014 10:23, Gary Mort  wrote:
>
> On 05/19/2014 02:31 AM, Damian Gruber wrote:
>
> Hi,
>
>
> I'm implementing a server which does digest access authentication, accroding
> to RFC 2617.
> Unfortunately I don't have an (implemented) corresponding client, which
> makes debugging and testing a bit difficult.
> Therefore, I'm using Firefox as a user agent, to get at least a bit of
> information.
>
> I hit on three problems, could you have a look at them?
>
> 1) It seems that if my server sends out a wrong rspauth-field in the
> Authentication-Info header, a user using Firefox does not get informed that
> the server didn't properly authenticate itself.
> Is this true?
> Does Firefox even check whether the rspauth-field is as expected?
>
> Don't know, but the code is found here:
> http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpDigestAuth.cpp#161
>
> Considering that there are lots of comments like
>
> 215     // we do not support auth-int "quality of protection" currently
>
>
> and
>
> 226 #if 0
>
>
>
> I'd say it's safe to say that client authentication of the server is broken
> in many ways.
>
>
> All of this links back to "generateCredentials"
>
> 91     string generateCredentials(in    nsIHttpAuthenticableChannel
> aChannel,
>
>
> I've noticed that in the google chrome code, there is a lot of over-reliance
> on the cache - and that anytime credentials aren't returned by some
> authentication handler, chrome will fall back to pulling the last data from
> the cache.  So as long as the last data in the cache will be accepted by the
> server, it will keep going.
>
> I haven't done a lot of work with the Firefox code.
>
> Another oddity I found in the chrome code[which was mainly copied from the
> firefox code] is that for a given domain name, the browser will only cache
> one set of credentials.
>
> Ie credentials cached for http://www.example.com/~bob , realm="bobs virtual
> server"
>
> After connecting to htttp://www.example.com/~alice, realm="alices virtual
> server"
>
> The credentials for bob's virtual server are lost and will have to be
> re-entered.
>
>
>
>
> 2) If the user tries to access "/login", the server sends back a response
> which contains the following field in the WWW-Authenticate header:
> domain="/login /protected"
> After a successful authentication, the user then tries to access this url
> "/public/area/"
> Firefox also sends the Authorization header for this request, even if this
> url is not in the list from the WWW-Authenticate header, right?
>
>
> Both Chrome and Firefox ignore the Domain header, see
> https://code.google.com/p/chromium/issues/detail?id=74590&q=http%20auth%20digest&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified
>
>
>
>
> 3) Is there some debug output from Firefox, which I can access?
>
>
>
> There are a few auth extensions already written in the extension directory.
> For example, here is some code:
> https://addons.mozilla.org/en-us/firefox/files/browse/130396/file/chrome/content/overlay.js#top
>
> Basically, just write a small extension which listens for the "load",
> "unload", and "http_on_modify_request" events and then you can set your
> javascript debugger to break at those function points in your extension and
> examine what header fields are set at those points.
>
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth
>


From nobody Wed May 21 23:05:54 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09431A00D7 for ; Wed, 21 May 2014 23:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 yoUC8iKuTI8Q for ; Wed, 21 May 2014 23:05:49 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625C81A00C3 for ; Wed, 21 May 2014 23:05:49 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id k48so3001429wev.17 for ; Wed, 21 May 2014 23:05:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IWIzGCWQCQvPcf3e0nneWpYHnAfLKohXsIEwh407ggs=; b=NNrzUqYGpF8ayP6quuZQu9WRQEgw4pB9UMUWTxiRY7onM+fALv3eR9vMw+lB8cDEwA ccvZzCpYlFrpxyape9FrmTtGo/4W0WiFzFfOHESKxI9ALn/p/c48dGokWi5ByUJCzmcG UYsL6Irt/ISvJdUqWgBmGr7q9+97Qbjdxdn4p9bSq0l6JdNnh/PcAwkB6frcScVzOfVO wD1oxtb6Xd0cuh+82ld4zgMHcTLELp3SiUu9HpNcDP+PW5aJJOnj8hVaED/jKharukec EhlL4GNdr76csTM1TArHwMThNO9HP1CoNq64yQ2Gy+UGCeIziwAwzsr2grkoq2uIzQzo awyw==
X-Received: by 10.180.97.10 with SMTP id dw10mr14659242wib.38.1400738747095; Wed, 21 May 2014 23:05:47 -0700 (PDT)
Received: from [10.4.8.70] ([80.179.9.115]) by mx.google.com with ESMTPSA id p18sm6111346wik.3.2014.05.21.23.05.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 23:05:43 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F1BF168-1073-4DB4-8F2C-AE858E9434EF"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir 
In-Reply-To: <536BFA23.9020900@digitalbazaar.com>
Date: Thu, 22 May 2014 09:04:30 +0300
Message-Id: <73FEA0D3-E9EE-4020-8467-9DEAFA2630E1@gmail.com>
References: <536BFA23.9020900@digitalbazaar.com>
To: Manu Sporny 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/0DfEwZzc2ITzEcLd4Hk_hgJ-H5U
Cc: IETF HTTP Auth , Web Payments CG 
Subject: Re: [http-auth] Review Request for third draft of "Signing HTTP Messages"
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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 May 2014 06:05:52 -0000

--Apple-Mail=_5F1BF168-1073-4DB4-8F2C-AE858E9434EF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi, Manu

Interesting draft. I finally found the time to go over it. A few =
comments in no particular order:

I agree with Mark about keeping the motivation part simpler. Signing =
prevents forgeries, not monitoring.=20
To my mind, the main motivation for this is that HTTP (and HTTPS) are =
often not deployed end-to-end. There are internal proxies, decrypting =
proxies, next-generation firewalls, load balancers, TLS routers, and =
probably a dozen others I=92ve forgotten. Each hop of an HTTP connection =
may or may not be protected by TLS, may or may not strip the encryption, =
and may or may not re-encrypt (and re-authenticate) for the next hop. =
Signing requests are responses provides end-to-end integrity, which =
current HTTP(S) does not provide.
About the text in section 1 regarding password cracking:
                                                          Digest
   authentication, while providing a little more protection, still
   leaves the scheme open to brute-force attacks that are capable of
   discovering a weak or random 8 character password in less than 3
   hours using a single commodity computer
I=92m not sure how you can crack 8-character random passwords on a =
commodity computer in 3 hours. Brute force won=92t get you there. I =
suggest you either explain how, point to a reference, or even better, =
pull it out.=20
The URL of signature schemes ( =
http://www.iana.org/assignments/signature-algorithms ) is broken and I =
couldn=92t figure out the one you meant.
2.1.3: some headers may appear more than once (if their value is defined =
as a comma-separated list). If there are such header lines, I=92m =
guessing the signature applies to all or none, right?  (that=92s not a =
bad thing - just a clarification question)
I=92m wondering if the WWW-Authenticate header should have a =93headers=94=
 parameter. Otherwise, the server demands a signature, and then the =
client signs something, which may or may not cover everything the server =
policy says should be signed. This could be pre-arranged between client =
and server, but then the client should also know in advance when to =
sign. So I think the server should specify which fields need to be =
included in the signature.

Regards,

Yoav


--Apple-Mail=_5F1BF168-1073-4DB4-8F2C-AE858E9434EF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Hi, Manu

Interesting =
draft. I finally found the time to go over it. A few comments in no =
particular order:

  • I=
 agree with Mark about keeping the motivation part simpler. Signing =
prevents forgeries, not monitoring. 
  • To my mind, the main =
motivation for this is that HTTP (and HTTPS) are often not deployed =
end-to-end. There are internal proxies, decrypting proxies, =
next-generation firewalls, load balancers, TLS routers, and probably a =
dozen others I=92ve forgotten. Each hop of an HTTP connection may or may =
not be protected by TLS, may or may not strip the encryption, and may or =
may not re-encrypt (and re-authenticate) for the next hop. Signing =
requests are responses provides end-to-end integrity, which current =
HTTP(S) does not provide.
  • About the text in section 1 regarding =
password cracking:
                                                              =
Digest
   authentication, while providing a little more protection, still
   leaves the scheme open to brute-force attacks that are capable of
   discovering a weak or random 8 character password in less than 3
   hours using a single commodity computer
    I=92m not sure how you =
can crack 8-character random passwords on a commodity computer in 3 =
hours. Brute force won=92t get you there. I suggest you either explain =
how, point to a reference, or even better, pull it =
out. 
  • The URL of signature schemes ( http://www.iana.org/assignments/signature-algorithms ) is =
broken and I couldn=92t figure out the one you meant.
  • 2.1.3: =
some headers may appear more than once (if their value is defined as a =
comma-separated list). If there are such header lines, I=92m guessing =
the signature applies to all or none, right?  (that=92s not a bad =
thing - just a clarification question)
  • I=92m wondering if the =
WWW-Authenticate header should have a =93headers=94 parameter. =
Otherwise, the server demands a signature, and then the client signs =
something, which may or may not cover everything the server policy says =
should be signed. This could be pre-arranged between client and server, =
but then the client should also know in advance when to sign. So I think =
the server should specify which fields need to be included in the =
signature.

Regards,

Yoav

=

--Apple-Mail=_5F1BF168-1073-4DB4-8F2C-AE858E9434EF--


From nobody Thu May 22 23:46:21 2014
Return-Path: 
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA5E1A03AF for ; Thu, 22 May 2014 23:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.25
X-Spam-Level: 
X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldUL8owE7GjW for ; Thu, 22 May 2014 23:46:07 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EC51A004D for ; Thu, 22 May 2014 23:46:05 -0700 (PDT)
Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 23 May 2014 08:45:58 +0200
Received: from [192.168.178.30] (178.195.84.245) by mail.ethz.ch (172.31.38.211) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 23 May 2014 08:46:01 +0200
Message-ID: <537EEEA9.50405@student.ethz.ch>
Date: Fri, 23 May 2014 08:46:01 +0200
From: Damian Gruber 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Gary Mort , 
References: <5379A554.9000200@student.ethz.ch> <537A3E2E.6000609@gmail.com>
In-Reply-To: <537A3E2E.6000609@gmail.com>
Content-Type: multipart/alternative; boundary="------------020609070004090403090001"
X-Originating-IP: [178.195.84.245]
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/dhlBrslmxz607xAl3N8xwjGcgEo
Subject: Re: [http-auth] - Debugging and Firefox
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 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, 23 May 2014 06:46:11 -0000

--------------020609070004090403090001
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Thanks a lot for your reply!

Basically, my problem is to debug my server.
I agree, Firefox might not be the right choice.

I'm now trying to debug it with cURL.
But also there, it seems that my server can send an arbitrary rspauth 
field, and the user does not get informed about a wrong rspauth field.

Do you have an idea of how I can debug my server, especially find out 
when a rspauth-field is wrong?






Am 19.05.2014 19:23, schrieb Gary Mort:
>
> On 05/19/2014 02:31 AM, Damian Gruber wrote:
>> Hi,
>>
>>
>> I'm implementing a server which does digest access authentication, 
>> accroding to RFC 2617.
>> Unfortunately I don't have an (implemented) corresponding client, 
>> which makes debugging and testing a bit difficult.
>> Therefore, I'm using Firefox as a user agent, to get at least a bit 
>> of information.
>>
>> I hit on three problems, could you have a look at them?
>>
>> 1) It seems that if my server sends out a wrong rspauth-field in the 
>> Authentication-Info header, a user using Firefox does not get 
>> informed that the server didn't properly authenticate itself.
>> Is this true?
>> Does Firefox even check whether the rspauth-field is as expected?
> Don't know, but the code is found here: 
> http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpDigestAuth.cpp#161
>
> Considering that there are lots of comments like
> 215        // we do not support auth-int "quality of protection" currently
>
> and
> 226    #if0
>
>
> I'd say it's safe to say that client authentication of the server is 
> broken in many ways.
>
>
> All of this links back to "generateCredentials"
> 91        string    generateCredentials  (in     nsIHttpAuthenticableChannel    
> aChannel  ,
>
> I've noticed that in the google chrome code, there is a lot of 
> over-reliance on the cache - and that anytime credentials aren't 
> returned by some authentication handler, chrome will fall back to 
> pulling the last data from the cache.  So as long as the last data in 
> the cache will be accepted by the server, it will keep going.
>
> I haven't done a lot of work with the Firefox code.
>
> Another oddity I found in the chrome code[which was mainly copied from 
> the firefox code] is that for a given domain name, the browser will 
> only cache one set of credentials.
>
> Ie credentials cached for http://www.example.com/~bob , realm="bobs 
> virtual server"
>
> After connecting to htttp://www.example.com/~alice, realm="alices 
> virtual server"
>
> The credentials for bob's virtual server are lost and will have to be 
> re-entered.
>
>
>>
>> 2) If the user tries to access "/login", the server sends back a 
>> response which contains the following field in the WWW-Authenticate 
>> header:
>> domain="/login /protected"
>> After a successful authentication, the user then tries to access this 
>> url
>> "/public/area/"
>> Firefox also sends the Authorization header for this request, even if 
>> this url is not in the list from the WWW-Authenticate header, right?
>
> Both Chrome and Firefox ignore the Domain header, see 
> https://code.google.com/p/chromium/issues/detail?id=74590&q=http%20auth%20digest&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified
>
>
>>
>> 3) Is there some debug output from Firefox, which I can access?
>>
>
>
> There are a few auth extensions already written in the extension 
> directory.
> For example, here is some code:
> https://addons.mozilla.org/en-us/firefox/files/browse/130396/file/chrome/content/overlay.js#top
>
> Basically, just write a small extension which listens for the "load", 
> "unload", and "http_on_modify_request" events and then you can set 
> your javascript debugger to break at those function points in your 
> extension and examine what header fields are set at those points.
>


--------------020609070004090403090001
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi,

    

    Thanks a lot for your reply!

    

    Basically, my problem is to debug my server.

    I agree, Firefox might not be the right choice.

    

    I'm now trying to debug it with cURL.

    But also there, it seems that my server can send an arbitrary
    rspauth field, and the user does not get informed about a wrong
    rspauth field.

    

    Do you have an idea of how I can debug my server, especially find
    out when a rspauth-field is wrong?

    

    

    

    

    

    

    
Am 19.05.2014 19:23, schrieb Gary Mort:

    

    

      
      

      
On 05/19/2014 02:31 AM, Damian Gruber
        wrote:

      

      
Hi, 

        

        

        I'm implementing a server which does digest access
        authentication, accroding to RFC 2617. 

        Unfortunately I don't have an (implemented) corresponding
        client, which makes debugging and testing a bit difficult. 

        Therefore, I'm using Firefox as a user agent, to get at least a
        bit of information. 

        

        I hit on three problems, could you have a look at them? 

        

        1) It seems that if my server sends out a wrong rspauth-field in
        the Authentication-Info header, a user using Firefox does not
        get informed that the server didn't properly authenticate
        itself. 

        Is this true? 

        Does Firefox even check whether the rspauth-field is as
        expected? 

      

      Don't know, but the code is found here:
      http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpDigestAuth.cpp#161

      

      Considering that there are lots of comments like

      
215     // we do not support auth-int "quality of protection" currently


      

      and

      
226 #if 0


      

      

      I'd say it's safe to say that client authentication of the server
      is broken in many ways.

      

      

      All of this links back to "generateCredentials" 

      
91     string generateCredentials(in    nsIHttpAu
thenticableChannel 
aChannel,

      

      I've noticed that in the google chrome code, there is a lot of
      over-reliance on the cache - and that anytime credentials aren't
      returned by some authentication handler, chrome will fall back to
      pulling the last data from the cache.  So as long as the last data
      in the cache will be accepted by the server, it will keep going.

      

      I haven't done a lot of work with the Firefox code.

      

      Another oddity I found in the chrome code[which was mainly copied
      from the firefox code] is that for a given domain name, the
      browser will only cache one set of credentials.

      

      Ie credentials cached for http://www.example.com/~bob
      , realm="bobs virtual server"

      

      After connecting to htttp://www.example.com/~alice, realm="alices
      virtual server"

      

      The credentials for bob's virtual server are lost and will have to
      be re-entered.

      

      

      
 

        2) If the user tries to access "/login", the server sends back a
        response which contains the following field in the
        WWW-Authenticate header: 

        domain="/login /protected" 

        After a successful authentication, the user then tries to access
        this url 

        "/public/area/" 

        Firefox also sends the Authorization header for this request,
        even if this url is not in the list from the WWW-Authenticate
        header, right? 

      

      

      Both Chrome and Firefox ignore the Domain header, see
      https://code.google.com/p/chromium/issues/detail?id=74590&q=http%20auth%20digest&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

      

      

      
 

        3) Is there some debug output from Firefox, which I can access?
        

        

      

      

      

      There are a few auth extensions already written in the extension
      directory. 

      For example, here is some code:

      https://addons.mozilla.org/en-us/firefox/files/browse/130396/file/chrome/content/overlay.js#top

      

      Basically, just write a small extension which listens for the
      "load", "unload", and "http_on_modify_request" events and then you
      can set your javascript debugger to break at those function points
      in your extension and examine what header fields are set at those
      points.

      

    

    

  


--------------020609070004090403090001--