Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E6B437F816 for ; Fri, 21 Apr 2006 09:58:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D676214226C for ; Fri, 21 Apr 2006 09:58:22 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23824-06 for ; Fri, 21 Apr 2006 09:58:22 -0700 (PDT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F3D9142267 for ; Fri, 21 Apr 2006 09:58:22 -0700 (PDT) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 48975D4C10D for ; Fri, 21 Apr 2006 12:58:21 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Fri, 21 Apr 2006 12:57:43 -0400 X-Sasl-enc: j3ap0LO3uHiRs8YvnVN8qgCgLn3n4CiYMr6Y0P5NgJr/ 1145638663 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id ED5E9A8A5 for ; Fri, 21 Apr 2006 12:57:42 -0400 (EDT) Date: Fri, 21 Apr 2006 12:58:19 -0400 From: Cyrus Daboo To: HTTP authentication list Message-ID: <4F219241584A0F0030E99E07@Cyrus-Daboo.local> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-http-auth] Google HTTP auth X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2006 16:58:23 -0000 Hi, Just in case anyone has missed this: Google have their own authentication scheme they are using for their products, including the newly released calendar. Details here: and here: -- Cyrus Daboo Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3CF307F78A for ; Thu, 13 Apr 2006 06:20:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F11C142270 for ; Thu, 13 Apr 2006 06:20:00 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32512-09 for ; Thu, 13 Apr 2006 06:19:57 -0700 (PDT) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.179]) by laweleka.osafoundation.org (Postfix) with ESMTP id 918F614226E for ; Thu, 13 Apr 2006 06:19:57 -0700 (PDT) Received: by pproxy.gmail.com with SMTP id z74so1621010pyg for ; Thu, 13 Apr 2006 06:19:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MSV8tmH5wPzswUI7Axf2Wp5C79kVFU67aShGXBJPhNM1EcrVZxquqvOtPaCfFMDFqQ+O4ieDCS44qDHO/gkXMhdDixyFGOAu7iqrqccPd1CxZZ6yf8gG9jZoT8xb+2HaH93wLwuRAuHR3M0sBO35NeFShIgcJSp6SSfNlR5/3i0= Received: by 10.35.97.17 with SMTP id z17mr763189pyl; Thu, 13 Apr 2006 06:19:55 -0700 (PDT) Received: by 10.35.26.1 with HTTP; Thu, 13 Apr 2006 06:19:55 -0700 (PDT) Message-ID: <68fba5c50604130619x546dd00dyf41b02f17e45b178@mail.gmail.com> Date: Thu, 13 Apr 2006 09:19:55 -0400 From: "Robert Sayre" To: "Robert Sayre" , "HTTP authentication list" Subject: Re: [Ietf-http-auth] Fwd: I-D ACTION:draft-sayre-http-hmac-digest-01.txt In-Reply-To: <20060413101236.GA18425@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <68fba5c50604110908l4639af9bl9db7932b3b38926f@mail.gmail.com> <20060413101236.GA18425@redhat.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2006 13:20:00 -0000 On 4/13/06, Joe Orton wrote: > > If the point of this is to allow use of Digest with a different hashing > algorithm then why create a whole new auth scheme? Why not just define > a new set of algorithm definitions which use the 2617 Digest scheme? Thanks for the feedback. One of the goals of the draft is to remove quality-of-protection options, since many parts of Digest are too unevenly-implemented to rely on. For example, the scheme in this draft requires a client nonce, something the Digest scheme requires only for qop=3D"auth" (which some implementations get right) and qop=3D"auth-int" (which very few implementations even make an effort to support). > That would be much simpler. Disagree. The Digest scheme doesn't seem very simple to implement at all, and one of the use cases I want to address with this draft is unencrypted, non-browser HTTP traffic. This scheme is simple enough to implement from the application level. Judging from the Digest implementations I have studied, I think there's enough baggage after ten years or so to make integration with existing Digest code somewhat difficult. > > The hashing of header values is I think fundamentally flawed. Proxies > may fold, unfold and combine header values as they see fit. It might be > feasible to define some canonical form for header values which both > client and server would map to. OK. Another strategy might be to recommend a list of headers that are unlikely to encounter such treatment. Could you point to an example of such a proxy? I don't doubt you, but it would be useful to observe this behavior. -- Robert Sayre Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D8DE27F68E for ; Thu, 13 Apr 2006 03:12:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CA524142266 for ; Thu, 13 Apr 2006 03:12:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17335-07 for ; Thu, 13 Apr 2006 03:12:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by laweleka.osafoundation.org (Postfix) with ESMTP id 398B014225D for ; Thu, 13 Apr 2006 03:12:39 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k3DACbUJ027754; Thu, 13 Apr 2006 06:12:37 -0400 Received: from turnip.cambridge.redhat.com (turnip.cambridge.redhat.com [172.16.18.137]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k3DACbh0002807; Thu, 13 Apr 2006 06:12:37 -0400 Received: from turnip.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by turnip.cambridge.redhat.com (8.13.6/8.13.5) with ESMTP id k3DACaK0018935; Thu, 13 Apr 2006 11:12:36 +0100 Received: (from jorton@localhost) by turnip.cambridge.redhat.com (8.13.6/8.13.6/Submit) id k3DACavE018934; Thu, 13 Apr 2006 11:12:36 +0100 X-Authentication-Warning: turnip.cambridge.redhat.com: jorton set sender to jorton@redhat.com using -f Date: Thu, 13 Apr 2006 11:12:36 +0100 From: Joe Orton To: Robert Sayre Subject: Re: [Ietf-http-auth] Fwd: I-D ACTION:draft-sayre-http-hmac-digest-01.txt Message-ID: <20060413101236.GA18425@redhat.com> Mail-Followup-To: Robert Sayre , HTTP authentication list References: <68fba5c50604110908l4639af9bl9db7932b3b38926f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50604110908l4639af9bl9db7932b3b38926f@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: HTTP authentication list X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2006 10:12:41 -0000 On Tue, Apr 11, 2006 at 12:08:42PM -0400, Robert Sayre wrote: > Hi folks, > > I've already started working on addressing some of Yngve's concerns. I > got some off-list mail that concurred with his suggestions about > Proxy-Authentication and formulas. I think it would be nice to hear > some more perspectives on Authentication-Info, hashing algorithms, > internationalization, and the extent of message integrity the scheme > should provide. If the point of this is to allow use of Digest with a different hashing algorithm then why create a whole new auth scheme? Why not just define a new set of algorithm definitions which use the 2617 Digest scheme? That would be much simpler. The hashing of header values is I think fundamentally flawed. Proxies may fold, unfold and combine header values as they see fit. It might be feasible to define some canonical form for header values which both client and server would map to. joe Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 63E5C7F70D for ; Tue, 11 Apr 2006 09:08:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 54C81142269 for ; Tue, 11 Apr 2006 09:08:46 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30252-02 for ; Tue, 11 Apr 2006 09:08:43 -0700 (PDT) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.180]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7700D142266 for ; Tue, 11 Apr 2006 09:08:43 -0700 (PDT) Received: by pproxy.gmail.com with SMTP id z74so1097389pyg for ; Tue, 11 Apr 2006 09:08:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pBCuuGcODW78FKa+eoLbrM47SBgdt/TaV9HBSaraUsIqCRkbL8uIEkdfRJOeibZKOs2Bdl4Wzaze5RQeBiY4i/j3Q9ZRM7sAJX4NUuhAKZjF3BOTse9vY/zE2q+ZU0l6G7s7H0oBtcOtdwjVHpnpXdZYvMw7ivMbRfCTeixljPY= Received: by 10.35.36.13 with SMTP id o13mr366322pyj; Tue, 11 Apr 2006 09:08:42 -0700 (PDT) Received: by 10.35.26.1 with HTTP; Tue, 11 Apr 2006 09:08:42 -0700 (PDT) Message-ID: <68fba5c50604110908l4639af9bl9db7932b3b38926f@mail.gmail.com> Date: Tue, 11 Apr 2006 12:08:42 -0400 From: "Robert Sayre" To: "HTTP authentication list" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: Subject: [Ietf-http-auth] Fwd: I-D ACTION:draft-sayre-http-hmac-digest-01.txt X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2006 16:08:46 -0000 Hi folks, I've already started working on addressing some of Yngve's concerns. I got some off-list mail that concurred with his suggestions about Proxy-Authentication and formulas. I think it would be nice to hear some more perspectives on Authentication-Info, hashing algorithms, internationalization, and the extent of message integrity the scheme should provide. As a data point, Amazon happened to deploy a similar authentication scheme for their S3 service: Change Log: 01: Add server nonce, remove client timestamp. Specify header handling more extensively. Add RFC2119 terms for header handling. Demo client excludes hop-by-hop headers. ---------- Forwarded message ---------- From: Internet-Drafts@ietf.org Date: Apr 10, 2006 6:50 PM Subject: I-D ACTION:draft-sayre-http-hmac-digest-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : HMAC Digest Access Authentication for HTTP Author(s) : A. Melnikov, R. Sayre Filename : draft-sayre-http-hmac-digest-01.txt Pages : 15 Date : 2006-4-10 This document specifies an HTTP authentication scheme based on cryptographic hashes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sayre-http-hmac-digest-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usernam= e "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sayre-http-hmac-digest-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-sayre-http-hmac-digest-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail reader= s exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -- Robert Sayre "I would have written a shorter letter, but I did not have the time." Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5C7D77F677 for ; Fri, 7 Apr 2006 12:04:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4EAD6142279 for ; Fri, 7 Apr 2006 12:04:07 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24101-08 for ; Fri, 7 Apr 2006 12:04:03 -0700 (PDT) Received: from mailbox.opera.com (mail.opera.com [193.69.113.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 71CE8142277 for ; Fri, 7 Apr 2006 12:04:02 -0700 (PDT) Received: from killashandra-ii.oslo.opera.com (pat.opera.com [193.69.113.22]) by mailbox.opera.com (8.13.4/8.13.4/Debian-3) with ESMTP id k37J3wc6027470; Fri, 7 Apr 2006 19:03:58 GMT Date: Fri, 07 Apr 2006 21:02:08 +0200 From: "Yngve Nysaeter Pettersen" To: "Robert Sayre" Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news References: <68fba5c50603221838o4d8d3011v915ac2b9f85b621e@mail.gmail.com> <68fba5c50604071028m3401e43chc57788bfe58c3ea1@mail.gmail.com> Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <68fba5c50604071028m3401e43chc57788bfe58c3ea1@mail.gmail.com> User-Agent: Opera M2/8.52 (Win32, build 7721) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.6 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: Cc: HTTP authentication list X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yngve@opera.com List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 19:04:07 -0000 On Fri, 07 Apr 2006 19:28:45 +0200, Robert Sayre wrote: > On 4/7/06, Yngve N. Pettersen wrote: >> >> I'd like to comment on a few things about this draft. Some of the >> concerns >> I have are unfortunately a bit serious, others are less serious. > > Hi Yngvie, > > Thanks for the detailed comments. I believe some of your concerns have > been addressed in the -01 revision of the document. Alexey Melnikov > has agreed to write the SASL aspects of the document, and he also > brought up many of the same issues you have. The document should appear > in the I-D directory soon. For now, I have HTML and diffs: > > > Thanks for the URLs >> First off, while I find the "reason" attribute concept interesting, in >> particular in light of what was presented in an unrelated WG meeting in >> Dallas, I am not so sure it will be useful in this case. Unless I am >> mistaken, there is no way to differentiate between unauthorized (wrong >> username/password) and (header)integrity as the reason for failure based >> on the hashvalue, and deciding unauthorized based just on the username >> would open up for an attacker to generate a list of accepted login-IDs >> at >> a server. >> >> Suggestion: Remove this item. > > The intent here was to allow server to indicate that they recieved a > message > with headers that weren't included in the digest, but need to be in > order to > successfully process the request. I will try to make this clearer. Do you mean that the integrity reason should be sent if the server expects headers A, B, C, and D to be included in the hash, but the client only sends an authentication including A, B, and D, although it sends header C as well? Or if the client specifies headers A, B, and C, but only header A and C arrives? The second case is OK, although one might suggest that the HTML page in the response gives a description of what the problem was. The problem might be caused by a gateway or filter. The first case (which is how I understand the -01 draft) raises the question: How is the client supposed to correct its mistake? The only way that would be possible would be if the servers sends a minimum required list of headers in the challenge, because otherwise clients would have to make a hardcoded list of headers they think are useful to include, and the problem would have to be fixed by releasing an updated version of the application. >> - Does this specification really need to have one HMAC algorithm >> specification and one password algorithm specification? Why not just >> specify the algorithm that is being used as part of the HMAC and also >> use >> that for the password hash? > > Yes, pw-algorithm is necessary for the scheme to work with existing > authentication databases. Things like the popular Wordpress PHP > blogging software store passwords as unsalted MD5 hashes. One of the > goals of this document is to be easy to deploy in those types of > environments. Using two different algorithms adds (IMO unnecessary) complexity to the system. I think that the security aspects of using two different algorithms should be carefully considered. >> - RFC 2617 (Digest) also specified the Authentication-Info response >> header that lets the server provide additional state information to the >> client, as well as reverse authentication and protection of the response >> entity content. AFAICT this new method does not have anything similar. >> Why >> not? > > I did not find it widely implemented. I also expect that protecting > response > content will have much more complicated interactions with HTTP > intermediaries. Opera supports this header, as well as protection of response content. >> - Several other features of Digest Authentication, such as >> server-nonces, >> stale nonces and the qop method, has been removed as well, but there is >> no >> discussion about why these are excluded. AFAIK the server-nonces in RFC >> 2617 is used to prevent certain types of attacks. Is the salt value able >> to provide the same kind of protection? > > Server nonces are back in draft-01. Good to see >> The less serious concerns: >> >> - How are new digest algorithms going to be added? >> >> Suggestion: Add IANA considerations entry for how new algorithms should >> be >> added. > > I would rather let the first person who needs to add a scheme set up > the IANA details. > >> >> - How are older clients going to be able to authenticate to a server >> that >> supports the newer method? > > I don't see an economical way to help them with that. If there are new > algorithm tokens, they'll have to be updated. > >> Suggestion: This probably requires multiple WWW-Authorization headers >> with >> separate algorithms, unless the syntax is changed to permit multiple >> algorithms. > > I'd rather leave this unsaid. It opens up downgrade attacks, which > makes me uncomfortable. I don't feel strongly about this issue, > though. Backward compatibility (for future versions) and forward compatibility (for older clients) must be considered now. If it is not considered now, we could see serious trouble when we do need to upgrade the system. Case in point: Even though SSL/TLS have (IMO) described forward compatibility well, and backward compatibility has been described (that point may IMO have a couple of problems), I have observed *serious* trouble with non-compliant implementations all the way back to the SSL v3 to TLS 1.0 transition, right up to the current transition to TLS 1.1. In fact, we've had to disable at least the version rollback security feature in the protocol in order to be able to use the newer versions of the protocol! If methods for secure backward and forward compatibility are not defined now, I expect that we will see similar problems down the road when new methods are added. Therefore, this specification need to both consider how to add new methods, and how newer servers can interact with older clients. Yes, downgrade attacks could be a problem. Can anything be done to secure a sequence of challenges, or a multialgorithm challenge? >> - I think that it would be best to specify a canonalization of the >> headers used in the digest to avoid problems if a gateway edits, breaks >> up, or concatenates headers. Are CRLFs included? Background: At least >> one >> of the HTTP stacks Opera works with on mobile devices is concatenating >> multiple headers into one (as is allowed by RFC 2616), and that created >> some problems for the cookie handling. > > Agree. There is new text in draft-01 on this subject. Does it address > your concerns? Not quite. You need to specify how headers of the same name is concatenated. What if the client sends A: X B: Y A: Z and it arrives as A: X, Z B: Y or A: X, Z B: Y ? This conversion (at least the first, I am not sure about the second) is permitted by RFC 2616. At the very least you need to define how headers are separated during the hash, and how to handle internal, non-quoted, whitespace (including the linewrapping method that is also permitted) >> >> - What about Proxy Authentication? > > I could add text on this. Does anyone see this document being used by > proxies? Opera's code only differentiate between proxy and origin-server when it comes to methods in very rare cases. You should expect it to be used for proxies. >> - What about integrity of entity bodies? RFC 2617 have functionality for >> this. > > Yes, and I found almost no implementations that used it. For example, > Mozilla and the Python standard library both contain "TODO" comments > in their source code. Digest has been around quite a while, and if people > haven't implemented a feature, that says something. Also, HMAC Digest > allows > implementations to sign headers, so Content-* can be included. Opera supports RFC 2617 content-protection, but it is quite correct that I have not seen any deployment of response content protection, although I do know that Apache has a partial implemention which, the last time I checked (a couple of years ago) only worked if the server sent an empty response. >> May I also suggest that the description of the calulations uses the same >> form as in RFC 2617? Presenting the calculations in formulas will make >> it >> easier to search for errors in the implementation. > > Hmm. I found those really confusing, but I guess I could add something > similar. I really prefer having formulas as a reference. Several times I've seen textual presentation of calculations, in particular cryptographic operations, become difficult to understand. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B943C7F774 for ; Fri, 7 Apr 2006 10:37:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AA339142279 for ; Fri, 7 Apr 2006 10:37:04 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13592-04 for ; Fri, 7 Apr 2006 10:37:02 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E99F114226F for ; Fri, 7 Apr 2006 10:37:01 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k37HavQk030916; Fri, 7 Apr 2006 10:36:57 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 10:36:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ietf-http-auth] HMAC Digest draft and implementation news Date: Fri, 7 Apr 2006 10:36:54 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0032_01C65A48.55B1F930" Message-ID: <198A730C2044DE4A96749D13E167AD37A494D9@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Ietf-http-auth] HMAC Digest draft and implementation news Thread-Index: AcZaTyKFr0RwoiipTs6K86pWX+A+YwAGfLlQ From: "Hallam-Baker, Phillip" To: "Scott Lawrence" , "Leif Johansson" X-OriginalArrivalTime: 07 Apr 2006 17:36:56.0909 (UTC) FILETIME=[DDFD9FD0:01C65A69] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: HTTP authentication list X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 17:37:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C65A48.55B1F930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit At the W3C workshop on mutual authentication the Google people showed some statistics on password use that show that 80% of people choose passwords within a list of 1 million. Since walking the namespace is a much more practical attack than attacking the MD5 MAC construction I don't see much value in that approach. If people want to continue using lightweight passwords securely without also using SSL I think we need to introduce a public key exchange in addition. For example: Challenge = nonce + public_key Response = E (HMAC (nonce + cnonce [+ content], password), public_key), cnonce, nonce I do not see much value in simply replacing PHBMAC-MD5 with HMAC-SHA1. If you look at the data sizes you will find that there is no real significant difference between the PHBMAC and HMAC construction here. > -----Original Message----- > From: ietf-http-auth-bounces@osafoundation.org > [mailto:ietf-http-auth-bounces@osafoundation.org] On Behalf > Of Scott Lawrence > Sent: Friday, April 07, 2006 10:25 AM > To: Leif Johansson > Cc: HTTP authentication list > Subject: Re: [Ietf-http-auth] HMAC Digest draft and > implementation news > > On Fri, 2006-04-07 at 16:01 +0200, Leif Johansson wrote: > > > > Suggestion: Drop MD5 support, and preferably also SHA-1, and go > > > direct for SHA-256. > > For practical purposes, we'll be supporting MD5 for a long > time. Even if there are attacks on it found that do > compromise it, it is widely deployed in embedded systems that > can't easily be updated, so browsers will likely continue to > support it for a long time (just as they still support SSLv2 > despite its problems). > > > The issue is one of algorithm agility which must be > supported. It must > > be easy to introduce new hashes wo publishing and implementing new > > versions of the standard. This probably means negotiation > in some form. > > The current spec is pretty agile in this respect. There is > an explicit token for the supported hash method in the > WWW-Authenticate challenge. > Multiple algorithms can already be supported by including > multiple challenges in the 40[17] response. All that would > be needed is the definition of new tokens specifying a new > hash algorithm. > > -- > Scott Lawrence tel:+1-781-938-5306;ext=162 or > sip:slawrence@pingtel.com > sipXpbx project coordinator - SIPfoundry > http://www.sipfoundry.org/sipX > Chief Architect - Pingtel Corp. http://www.pingtel.com/ > > > _______________________________________________ > Ietf-http-auth mailing list > Ietf-http-auth@osafoundation.org > http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth > > ------=_NextPart_000_0032_01C65A48.55B1F930 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MDcxNzM2NTRaMCMGCSqGSIb3DQEJBDEWBBTp GWDLbdzcUECpfntynbcVQZ74+zBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYC4iJIFseLr+DkzzPkQnk8P46Tp g6vzXWojjJIZXWQ84ZJsT5feyO0neS/ZMXSJs481HKtBCS3RpEkCmEKTe5BdSQhAzRBn82VMFSL/ y7TObDQrrhR8AFvchg0118eUcnJzrfoYoV5EfjxNxTqywtbSWrWMU7GyKKF9Z3f8aEXwhwAAAAAA AA== ------=_NextPart_000_0032_01C65A48.55B1F930-- Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A612A7F6D5 for ; Fri, 7 Apr 2006 10:28:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 97B57142279 for ; Fri, 7 Apr 2006 10:28:48 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16289-06 for ; Fri, 7 Apr 2006 10:28:46 -0700 (PDT) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8257414226F for ; Fri, 7 Apr 2006 10:28:46 -0700 (PDT) Received: by pproxy.gmail.com with SMTP id z74so268933pyg for ; Fri, 07 Apr 2006 10:28:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eT9qGKfdfQMgbccvYbsbCyVE0DAE8JLTGUrWuuJsrOEQO3BVzJAXoxuz5XFyX/RCJtZo5RCxpwfCUNiXbpdIL00fuC8axMPE2mN5/wzt6sNTmrZv3v5pdIYYPeaoYMjfWj3AXxTxxQSChWcn5ajkxyDJK7nV9ni2QwjfT3OWHgM= Received: by 10.35.96.11 with SMTP id y11mr632979pyl; Fri, 07 Apr 2006 10:28:45 -0700 (PDT) Received: by 10.35.26.1 with HTTP; Fri, 7 Apr 2006 10:28:45 -0700 (PDT) Message-ID: <68fba5c50604071028m3401e43chc57788bfe58c3ea1@mail.gmail.com> Date: Fri, 7 Apr 2006 13:28:45 -0400 From: "Robert Sayre" To: "Yngve N. Pettersen" Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <68fba5c50603221838o4d8d3011v915ac2b9f85b621e@mail.gmail.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: Cc: HTTP authentication list X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 17:28:48 -0000 On 4/7/06, Yngve N. Pettersen wrote: > > I'd like to comment on a few things about this draft. Some of the concern= s > I have are unfortunately a bit serious, others are less serious. Hi Yngvie, Thanks for the detailed comments. I believe some of your concerns have been addressed in the -01 revision of the document. Alexey Melnikov has agreed to write the SASL aspects of the document, and he also brought up many of the same issues you have. The document should appear in the I-D directory soon. For now, I have HTML and diffs: Please keep in mind that the document is not intended to replace HTTP Digest, but design a new scheme with a subset of features that will hopefully be easier to deploy. Many features and options have been omitted because implementors generally don't bother to write the code for them. It's possible that I have cut too much. IMHO, Digest provides *way* too many options. I've tried to keep the code paths to a minimum in HMAC Digest. > > First off, while I find the "reason" attribute concept interesting, in > particular in light of what was presented in an unrelated WG meeting in > Dallas, I am not so sure it will be useful in this case. Unless I am > mistaken, there is no way to differentiate between unauthorized (wrong > username/password) and (header)integrity as the reason for failure based > on the hashvalue, and deciding unauthorized based just on the username > would open up for an attacker to generate a list of accepted login-IDs at > a server. > > Suggestion: Remove this item. The intent here was to allow server to indicate that they recieved a messag= e with headers that weren't included in the digest, but need to be in order t= o successfully process the request. I will try to make this clearer. > > The serious concerns: > > - I am not a crypto expert, but are MD5 and SHA-1 really the proper > choices for digest algorithm now that both are known to be weaker than on= e > would like? I am also not a crypto expert. My understanding is that the attacks on MD5 and SHA do not apply to the HMAC versions. That said, it might make sense to include a stronger, mandatory-to-implement HMAC construction. I don't expect interop to be as good with the stronger, newer hash function, though. > > - Does this specification really need to have one HMAC algorithm > specification and one password algorithm specification? Why not just > specify the algorithm that is being used as part of the HMAC and also use > that for the password hash? Yes, pw-algorithm is necessary for the scheme to work with existing authentication databases. Things like the popular Wordpress PHP blogging software store passwords as unsalted MD5 hashes. One of the goals of this document is to be easy to deploy in those types of environments. > - I18N: This draft does not specify how to prepare usernames and > passwords containing characters that are not part of US-ASCII ... > It is a current problem with Basic and Digest > authentication that there is no exisiting standard on how international > characters are to be encoded. Agreed. I know it's a problem with the document, and Alexey has some ideas on how to solve it. The implementation report is very helpful, thanks. > - RFC 2617 (Digest) also specified the Authentication-Info response > header that lets the server provide additional state information to the > client, as well as reverse authentication and protection of the response > entity content. AFAICT this new method does not have anything similar. Wh= y > not? I did not find it widely implemented. I also expect that protecting respons= e content will have much more complicated interactions with HTTP intermediari= es. > - Several other features of Digest Authentication, such as server-nonce= s, > stale nonces and the qop method, has been removed as well, but there is n= o > discussion about why these are excluded. AFAIK the server-nonces in RFC > 2617 is used to prevent certain types of attacks. Is the salt value able > to provide the same kind of protection? Server nonces are back in draft-01. Alexey feels they prevent some types of attacks from malicious clients, and I feel they don't add much complexity to the scheme. > The less serious concerns: > > - How are new digest algorithms going to be added? > > Suggestion: Add IANA considerations entry for how new algorithms should b= e > added. I would rather let the first person who needs to add a scheme set up the IANA details. > > - How are older clients going to be able to authenticate to a server th= at > supports the newer method? I don't see an economical way to help them with that. If there are new algorithm tokens, they'll have to be updated. > Suggestion: This probably requires multiple WWW-Authorization headers wit= h > separate algorithms, unless the syntax is changed to permit multiple > algorithms. I'd rather leave this unsaid. It opens up downgrade attacks, which makes me uncomfortable. I don't feel strongly about this issue, though. > > - I think that it would be best to specify a canonalization of the > headers used in the digest to avoid problems if a gateway edits, breaks > up, or concatenates headers. Are CRLFs included? Background: At least one > of the HTTP stacks Opera works with on mobile devices is concatenating > multiple headers into one (as is allowed by RFC 2616), and that created > some problems for the cookie handling. Agree. There is new text in draft-01 on this subject. Does it address your concerns? > > - What about Proxy Authentication? I could add text on this. Does anyone see this document being used by proxies? > > - What about integrity of entity bodies? RFC 2617 have functionality for > this. Yes, and I found almost no implementations that used it. For example, Mozilla and the Python standard library both contain "TODO" comments in their source code. Digest has been around quite a while, and if people haven't implemented a feature, that says something. Also, HMAC Digest allow= s implementations to sign headers, so Content-* can be included. > > May I also suggest that the description of the calulations uses the same > form as in RFC 2617? Presenting the calculations in formulas will make it > easier to search for errors in the implementation. Hmm. I found those really confusing, but I guess I could add something similar. -- Robert Sayre Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7D2787F752 for ; Fri, 7 Apr 2006 07:25:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6F3AA142277 for ; Fri, 7 Apr 2006 07:25:31 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17859-06 for ; Fri, 7 Apr 2006 07:25:29 -0700 (PDT) Received: from mail.pingtel.com (mail.pingtel.com [65.220.123.3]) by laweleka.osafoundation.org (Postfix) with ESMTP id DBE29142270 for ; Fri, 7 Apr 2006 07:25:28 -0700 (PDT) Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id D9B2E6C021; Fri, 7 Apr 2006 10:25:27 -0400 (EDT) Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news From: Scott Lawrence To: Leif Johansson In-Reply-To: <443670A5.7080108@it.su.se> References: <68fba5c50603221838o4d8d3011v915ac2b9f85b621e@mail.gmail.com> <443670A5.7080108@it.su.se> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 07 Apr 2006 10:25:27 -0400 Message-Id: <1144419927.3239.22.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: HTTP authentication list X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 14:25:31 -0000 On Fri, 2006-04-07 at 16:01 +0200, Leif Johansson wrote: > > Suggestion: Drop MD5 support, and preferably also SHA-1, and go direct > > for SHA-256. For practical purposes, we'll be supporting MD5 for a long time. Even if there are attacks on it found that do compromise it, it is widely deployed in embedded systems that can't easily be updated, so browsers will likely continue to support it for a long time (just as they still support SSLv2 despite its problems). > The issue is one of algorithm agility which must be supported. It must > be easy to introduce new hashes wo publishing and implementing new > versions of the standard. This probably means negotiation in some form. The current spec is pretty agile in this respect. There is an explicit token for the supported hash method in the WWW-Authenticate challenge. Multiple algorithms can already be supported by including multiple challenges in the 40[17] response. All that would be needed is the definition of new tokens specifying a new hash algorithm. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9DD5E7F538 for ; Fri, 7 Apr 2006 07:01:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E549142254 for ; Fri, 7 Apr 2006 07:01:16 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14140-03 for ; Fri, 7 Apr 2006 07:01:14 -0700 (PDT) Received: from smtp3.su.se (smtp3.su.se [130.237.93.228]) by laweleka.osafoundation.org (Postfix) with ESMTP id B3E2F142250 for ; Fri, 7 Apr 2006 07:01:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 3ECEE3BE77; Fri, 7 Apr 2006 16:01:12 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15832-01-91; Fri, 7 Apr 2006 16:01:11 +0200 (CEST) Received: from [10.0.0.242] (1-1-2-20a.rny.sth.bostream.se [82.182.132.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 9DA4A3BE22; Fri, 7 Apr 2006 16:01:11 +0200 (CEST) Message-ID: <443670A5.7080108@it.su.se> Date: Fri, 07 Apr 2006 16:01:09 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "Yngve N. Pettersen" Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news References: <68fba5c50603221838o4d8d3011v915ac2b9f85b621e@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: HTTP authentication list X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 14:01:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > - I am not a crypto expert, but are MD5 and SHA-1 really the proper > choices for digest algorithm now that both are known to be weaker than > one would like? As far as I know the current attacks are not in the > areas that directly affects this authentication method, at present, and > as I understand it, HMAC is supposed to be somewhat resistant to such > attacks on the input digest method, but is that protection good enough? > > Suggestion: Drop MD5 support, and preferably also SHA-1, and go direct > for SHA-256. The issue is one of algorithm agility which must be supported. It must be easy to introduce new hashes wo publishing and implementing new versions of the standard. This probably means negotiation in some form. You are right about HMAC MD5; people are getting nervous about this and it should not be used. Today HMAC SHA1 is probably ok but it may not be for very long. Going to SHA256 is not the right answer though - by the time SHA1 is "broken" SHA256 may not be that much better. The security ADs have made it clear that all protocols published by the IETF on standards-track must support seamless updates of hash- algorithms within 2 years. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFENnCl8Jx8FtbMZncRAu5KAJ0XMYoQiq96RX4x653c7CYD5EKgVwCfbICV 8Ylwp8HWFqwaCrNY6TXvCug= =XYny -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E434B7F6EA for ; Fri, 7 Apr 2006 06:50:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D6296142267 for ; Fri, 7 Apr 2006 06:50:07 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10604-04 for ; Fri, 7 Apr 2006 06:50:06 -0700 (PDT) Received: from sam.opera.com (sam.opera.com [193.69.113.81]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 94742142258 for ; Fri, 7 Apr 2006 06:50:05 -0700 (PDT) Received: from localhost (pat.opera.com [193.69.113.22]) (authenticated bits=0) by sam.opera.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id k37Do0WF007116 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 7 Apr 2006 13:50:00 GMT Date: Fri, 07 Apr 2006 15:50:03 +0200 To: "Robert Sayre" , "HTTP authentication list" Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news References: <68fba5c50603221838o4d8d3011v915ac2b9f85b621e@mail.gmail.com> From: "Yngve N. Pettersen" Organization: Opera Software ASA Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <68fba5c50603221838o4d8d3011v915ac2b9f85b621e@mail.gmail.com> User-Agent: Opera M2/8.53 (Win32, build 7722) X-Scanned-By: MIMEDefang 2.39 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.6 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 13:50:08 -0000 Hello all, On Wed, 22 Mar 2006 20:38:37 -0600, Robert Sayre wrote: > In Internet-Drafts news, draft-sayre-http-hmac-digest-00.txt is now > available in the I-D directory. It's the same document I've posted > here before. One significant issue has come to light since then: > clients need to exclude standard and extension hop-by-hop headers from > the digest calculation. Per RFC 2616, extension hop-by-hop headers are > listed in the 'Connection' header. I'd like to comment on a few things about this draft. Some of the concerns I have are unfortunately a bit serious, others are less serious. First off, while I find the "reason" attribute concept interesting, in particular in light of what was presented in an unrelated WG meeting in Dallas, I am not so sure it will be useful in this case. Unless I am mistaken, there is no way to differentiate between unauthorized (wrong username/password) and (header)integrity as the reason for failure based on the hashvalue, and deciding unauthorized based just on the username would open up for an attacker to generate a list of accepted login-IDs at a server. Suggestion: Remove this item. The serious concerns: - I am not a crypto expert, but are MD5 and SHA-1 really the proper choices for digest algorithm now that both are known to be weaker than one would like? As far as I know the current attacks are not in the areas that directly affects this authentication method, at present, and as I understand it, HMAC is supposed to be somewhat resistant to such attacks on the input digest method, but is that protection good enough? Suggestion: Drop MD5 support, and preferably also SHA-1, and go direct for SHA-256. - Does this specification really need to have one HMAC algorithm specification and one password algorithm specification? Why not just specify the algorithm that is being used as part of the HMAC and also use that for the password hash? Suggestion: Remove pw-algorithm, and use the algorithm parameter to define both the password hash and the function HMAC_func(key) = HMAC(H, key), where H is defined by the algorithm parameter. - I18N: This draft does not specify how to prepare usernames and passwords containing characters that are not part of US-ASCII, such as scandinavian letters, cyrillic and letters in the asian writing systems, before using them in the authentication method. Similar problems exists for other fields as well. It is a current problem with Basic and Digest authentication that there is no exisiting standard on how international characters are to be encoded. Opera uses UTF-8, while other browsers uses a different system, apparently depending on mutual agreement between the server- and client-side configurations. This specification should avoid making the same mistake as RFC 2617 made on this point. Suggestion: Get I18N experts involved in this aspect. I believe there are several WG chairs that should be able to help locate such experts. With respect to specifics I would recommend that the Normalization part (if used) should use the same method as the IDNA Nameprep (NFKC), because implementations will probably already have that method, and using the same method would be beneficial for memory constrained implementations (such as phones and PDAs). - RFC 2617 (Digest) also specified the Authentication-Info response header that lets the server provide additional state information to the client, as well as reverse authentication and protection of the response entity content. AFAICT this new method does not have anything similar. Why not? Suggestion: Implement the Authentication-Info header, or document in the specification why it is left out. - Several other features of Digest Authentication, such as server-nonces, stale nonces and the qop method, has been removed as well, but there is no discussion about why these are excluded. AFAIK the server-nonces in RFC 2617 is used to prevent certain types of attacks. Is the salt value able to provide the same kind of protection? Suggestion: Implement these attributes in the specification, or document the reasons why their removal does not weaken the authentication method. The less serious concerns: - How are new digest algorithms going to be added? Suggestion: Add IANA considerations entry for how new algorithms should be added. - How are older clients going to be able to authenticate to a server that supports the newer method? Suggestion: This probably requires multiple WWW-Authorization headers with separate algorithms, unless the syntax is changed to permit multiple algorithms. - I think that it would be best to specify a canonalization of the headers used in the digest to avoid problems if a gateway edits, breaks up, or concatenates headers. Are CRLFs included? Background: At least one of the HTTP stacks Opera works with on mobile devices is concatenating multiple headers into one (as is allowed by RFC 2616), and that created some problems for the cookie handling. - What about Proxy Authentication? - What about integrity of entity bodies? RFC 2617 have functionality for this. May I also suggest that the description of the calulations uses the same form as in RFC 2617? Presenting the calculations in formulas will make it easier to search for errors in the implementation. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ********************************************************************