Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 7DFE53E03A3 for ; Mon, 12 Jan 2009 08:32:58 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4jn1pqiN3jF for ; Mon, 12 Jan 2009 08:32:45 -0800 (PST) Received: from mysterion.org (mysterion.org [69.25.196.35]) by leka.osafoundation.org (Postfix) with ESMTP id 1349E3E0281 for ; Mon, 12 Jan 2009 08:32:45 -0800 (PST) Received: from x61.home.mysterion.org (lan-nat-pool-bos.redhat.com [66.187.234.200]) by mysterion.org (Postfix) with ESMTPA id 52F9E8028D; Mon, 12 Jan 2009 11:32:44 -0500 (EST) Message-ID: <496B7090.5090100@gmail.com> Date: Mon, 12 Jan 2009 11:32:16 -0500 From: Dan Winship User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Julian Reschke References: <496A2F24.2040109@gmx.de> <496A9C77.9040004@gmail.com> <496AF820.2050808@gmx.de> In-Reply-To: <496AF820.2050808@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 16:32:58 -0000 Julian Reschke wrote: >> Yeah, basically no one handles this correctly. I pointed this out on the >> httpbis list, and the consensus seemed to be "then they should fix their >> code". > > Please elaborate: is *-Authenticate broken in the same way as Cookie in > that combining multiple instances into the same header makes it > *impossible* to parse the value, or is parsing just harder? It's just harder. Provided that all the WWW-Authenticate headers obey the 2617 syntax for "challenge", then I'm pretty sure the rule I gave is correct: >> "a comma followed by a token >> which is not followed by an equals sign indicates the start of a new >> challenge" That rule also still works with NTLM and Negotiate. Of course, it would be possible for someone to violate the 2617 grammar in other ways that would make that rule fail, but AFAIK no one has *yet*, and so if someone did in the future, we could all gang up on them and beat them until they stopped. I looked around at one point and found four other uses of WWW-Authenticate: draft-nystrom-http-sasl, OAuth, the proposed OpenID-over-WWW-Authenticate, and the WSSE auth that was proposed for AtomPub but later dropped. All four used the correct RFC2617 syntax. -- Dan Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 6429D3E0513 for ; Mon, 12 Jan 2009 05:41:20 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[AWL=0.000, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUKbZWg4nvM1 for ; Mon, 12 Jan 2009 05:41:18 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by leka.osafoundation.org (Postfix) with ESMTP id 3F3D23E04FC for ; Mon, 12 Jan 2009 05:41:18 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so3908854fgg.17 for ; Mon, 12 Jan 2009 05:41:17 -0800 (PST) Received: by 10.86.51.10 with SMTP id y10mr16761571fgy.51.1231767676469; Mon, 12 Jan 2009 05:41:16 -0800 (PST) Received: by 10.86.30.11 with HTTP; Mon, 12 Jan 2009 05:41:16 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2009 14:41:16 +0100 From: "Thomas Broyer" To: "Yngve N. Pettersen (Developer Opera Software ASA)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <496A2F24.2040109@gmx.de> Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 13:41:20 -0000 On Sun, Jan 11, 2009 at 11:50 PM, Thomas Broyer wrote: > On Sun, Jan 11, 2009 at 10:17 PM, Yngve N. Pettersen (Developer Opera > Software ASA) wrote: >> >> WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic" > > My *.asis file contained two distinct headers, so it must be an > artifact of apache mod_asis... > I've put the tests under version control so you can get the source and > run them with some other server: > http://hg.ltgt.net/http-cookie-auth/file/tip/tests I've just added a small python script to serve an *.asis file for all incoming requests: http://hg.ltgt.net/http-cookie-auth/raw-file/tip/tests/asis.py (call the script with the asis file as the first argument, the server will listen on port 8000; it also dumps the request headers on stdout) Results for cookie-and-basic: All tested browsers prompt for "Basic" (i.e. ignore the unknown "cookie" scheme): IE (6, 7 and 8b2), Firefox (2.0.0.20, 3.0.5 and 3.1b2), Opera (9.63 and 10), Safari 3.2.1/Windows, and Chrome 2.0.156.1. Results for basic-and-cookie: I've only tested Opera (9.63 and 10) and Chrome Dev (2.0.156.1) on this one, and the results are the same as above; i.e. order of the WWW-Authenticate headers doesn't matter. These are the expected results, per RFC2616 (AFAICT). @Julian: this means that if you want to mix Cookie and Basic at the same URL, you'll have Basic unless the user has already authenticated with Cookie at another (non-mixed) URL. -- Thomas Broyer Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 34F903E050D for ; Mon, 12 Jan 2009 04:58:57 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNuXHTc5yGNK for ; Mon, 12 Jan 2009 04:58:46 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by leka.osafoundation.org (Postfix) with ESMTP id 615833E04FC for ; Mon, 12 Jan 2009 04:58:46 -0800 (PST) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0CCwhPN006816; Mon, 12 Jan 2009 07:58:43 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n0CCwhEP023168; Mon, 12 Jan 2009 07:58:43 -0500 Received: from turnip.manyfish.co.uk (vpn-12-116.rdu.redhat.com [10.11.12.116]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n0CCwgdx013693; Mon, 12 Jan 2009 07:58:42 -0500 Received: from jorton by turnip.manyfish.co.uk with local (Exim 4.69) (envelope-from ) id 1LMMNN-0003dR-4A; Mon, 12 Jan 2009 12:58:41 +0000 Date: Mon, 12 Jan 2009 12:58:41 +0000 From: Joe Orton To: Julian Reschke Message-ID: <20090112125840.GA3975@redhat.com> Mail-Followup-To: Julian Reschke , Bjoern Hoehrmann , ietf-http-auth@osafoundation.org References: <496A9C77.9040004@gmail.com> <496AF820.2050808@gmx.de> <0abmm4lc9iku6qo9rlnkk5rmmq32l1s6tf@hive.bjoern.hoehrmann.de> <496B36A8.4030403@gmx.de> <496B3B46.1080004@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <496B3B46.1080004@gmx.de> User-Agent: Mutt/1.5.18 (2008-05-17) Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 12:58:57 -0000 On Mon, Jan 12, 2009 at 01:44:54PM +0100, Julian Reschke wrote: > So it seems RFC 4559 is incompatible with RFC 2617. Does anybody > volunteer to raise an erratum? Incompatibilities include: - the auth-param grammar issue mentioned here - connection-auth not request-auth - use of WWW-Auth in a 2xx response rather than Auth-Info the correct thing to do with 4559 is to deprecate it and replace it with something which isn't completely broken, which draft-johansson-http-gss looks to be doing though I haven't reviewed that in detail. joe Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 389C63E0508 for ; Mon, 12 Jan 2009 04:45:16 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-50 required=4 tests=[AWL=-0.455, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTNQpkBSI78B for ; Mon, 12 Jan 2009 04:45:05 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id 281D23E04FC for ; Mon, 12 Jan 2009 04:45:04 -0800 (PST) Received: (qmail invoked by alias); 12 Jan 2009 12:45:00 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp046) with SMTP; 12 Jan 2009 13:45:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX198bxJ4m+R8QypRgCzu5XqhHNF5xbKM/Cexp1eVhy QuUdxyia4z/092 Message-ID: <496B3B46.1080004@gmx.de> Date: Mon, 12 Jan 2009 13:44:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <496A2F24.2040109@gmx.de> <496A9C77.9040004@gmail.com> <496AF820.2050808@gmx.de> <0abmm4lc9iku6qo9rlnkk5rmmq32l1s6tf@hive.bjoern.hoehrmann.de> <496B36A8.4030403@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 12:45:16 -0000 Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> But auth-param is defined to be a token, thus can not contain a space >> character...: >> >> auth-scheme = token >> auth-param = token "=" ( token | quoted-string ) >> challenge = auth-scheme 1*SP 1#auth-param > > As I understand it, at the moment all NTLM and Negotiate headers are not > properly formed, either you get only the scheme name without a mandatory > parameter, or you get a scheme name followed by a base64 string, which > usually does not follow the token=token syntax. The point was that even > if you wish to support them, you'd need some other scheme with a special > kind of invalid syntax for there to be a problem. Oh, I see. Thanks for the clarification. So it seems RFC 4559 is incompatible with RFC 2617. Does anybody volunteer to raise an erratum? BR, Julian Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 5F1FD3E050F for ; Mon, 12 Jan 2009 04:38:16 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[AWL=0.000, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ81uDeIhYIs for ; Mon, 12 Jan 2009 04:38:05 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id 367F23E04FC for ; Mon, 12 Jan 2009 04:38:05 -0800 (PST) Received: (qmail invoked by alias); 12 Jan 2009 12:38:03 -0000 Received: from dslb-088-074-184-231.pools.arcor-ip.net (EHLO hive) [88.74.184.231] by mail.gmx.net (mp052) with SMTP; 12 Jan 2009 13:38:03 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+s9rY3xoGs9uida9+ycIbS3pVqPiOafxl6lW/nFJ NkXgbkYQ6F2Mp1 From: Bjoern Hoehrmann To: Julian Reschke Date: Mon, 12 Jan 2009 13:38:07 +0100 Message-ID: References: <496A2F24.2040109@gmx.de> <496A9C77.9040004@gmail.com> <496AF820.2050808@gmx.de> <0abmm4lc9iku6qo9rlnkk5rmmq32l1s6tf@hive.bjoern.hoehrmann.de> <496B36A8.4030403@gmx.de> In-Reply-To: <496B36A8.4030403@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.72 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 12:38:16 -0000 * Julian Reschke wrote: >But auth-param is defined to be a token, thus can not contain a space >character...: > > auth-scheme = token > auth-param = token "=" ( token | quoted-string ) > challenge = auth-scheme 1*SP 1#auth-param As I understand it, at the moment all NTLM and Negotiate headers are not properly formed, either you get only the scheme name without a mandatory parameter, or you get a scheme name followed by a base64 string, which usually does not follow the token=token syntax. The point was that even if you wish to support them, you'd need some other scheme with a special kind of invalid syntax for there to be a problem. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 34A2A3E04FC for ; Mon, 12 Jan 2009 04:38:03 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-50 required=4 tests=[AWL=-0.526, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUssyVcKvlDA for ; Mon, 12 Jan 2009 04:38:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id 607183E0281 for ; Mon, 12 Jan 2009 04:38:01 -0800 (PST) Received: (qmail invoked by alias); 12 Jan 2009 12:38:00 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp015) with SMTP; 12 Jan 2009 13:38:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18zVYdip0szdXhXps+7F/49vA0dK3J2ZgarnpgdJV o6kmKvLhOXzkXH Message-ID: <496B39A2.7090402@gmx.de> Date: Mon, 12 Jan 2009 13:37:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <496A2F24.2040109@gmx.de> <496A9C77.9040004@gmail.com> <496AF820.2050808@gmx.de> <0abmm4lc9iku6qo9rlnkk5rmmq32l1s6tf@hive.bjoern.hoehrmann.de> <496B36A8.4030403@gmx.de> In-Reply-To: <496B36A8.4030403@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 12:38:03 -0000 Julian Reschke wrote: > But auth-param is defined to be a token, thus can not contain a space > character...: s/auth-param/the name in auth-param/ > ... BR, Julian Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 964F03E04FC for ; Mon, 12 Jan 2009 04:31:31 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDy+3RzM6LoC for ; Mon, 12 Jan 2009 04:31:29 -0800 (PST) Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by leka.osafoundation.org (Postfix) with ESMTP id EB7A73E0281 for ; Mon, 12 Jan 2009 04:31:28 -0800 (PST) Received: from [192.168.1.6] (unknown [192.168.1.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id A2567C4C082; Mon, 12 Jan 2009 13:31:27 +0100 (CET) In-Reply-To: <0abmm4lc9iku6qo9rlnkk5rmmq32l1s6tf@hive.bjoern.hoehrmann.de> References: <496A2F24.2040109@gmx.de> <496A9C77.9040004@gmail.com> <496AF820.2050808@gmx.de> <0abmm4lc9iku6qo9rlnkk5rmmq32l1s6tf@hive.bjoern.hoehrmann.de> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4309B34B-CA8C-4DDD-B250-F800E66BFBB3@greenbytes.de> Content-Transfer-Encoding: quoted-printable From: Stefan Eissing Date: Mon, 12 Jan 2009 13:31:24 +0100 To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.753.1) Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 12:31:31 -0000 The algorithm I have implemented and working for some years now: - Concatenate all "WWW-Authenticate:" as comma-separated single header - Parse "WWW-Authenticate:" by splitting along ",": - if " " is there and has no '"' before it, remember the string =20 before " " as scheme name - else if it is a known scheme name, remember that - else if we remember a scheme name, this is a parameter(-part) =20 to that scheme - else we have an invalid case, insert error handling here All parameters of a scheme are just concatenated to a single string. =20 So parameters with "," in their value will be glued together again. - Then we have collected a map of scheme names and all parameters to =20 it (as single string) - This is handed to the Scheme handler the client knows and prefers =20 and has not already tried. Other strategies are of course possible. Cheers, Stefan Am 12.01.2009 um 13:20 schrieb Bjoern Hoehrmann: > * Julian Reschke wrote: >> Please elaborate: is *-Authenticate broken in the same way as =20 >> Cookie in >> that combining multiple instances into the same header makes it >> *impossible* to parse the value, or is parsing just harder? > > You would essentially need a scheme with key=3Dvalue pairs as = parameters > where the key can include spaces like in > > WWW-Authenticate: Hypothetical realm=3D"hypo", Security Level=3D"3", = ... > > Parsing this would require conflict resolution as it can be parsed as > one challenge for Hypothetical or two challenges for Hypothetical and > Security. As I recall, this is not the case for Negotiate or NTLM. > > If you do have a case as above, you should still be able to process it > with knowledge about the scheme, you would also have to have =20 > overlap in > the parameter names and scheme names to get values that =20 > implementations > who care would have trouble processing. So I don't think this =20 > counts as > impossible. > --=20 > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://=20 > bjoern.hoehrmann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://=20 > www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://=20 > www.websitedev.de/ > _______________________________________________ > ietf-http-auth mailing list > ietf-http-auth@osafoundation.org > http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth -- bytes GmbH, Hafenweg 16, D-48155 M=FCnster, Germany Amtsgericht M=FCnster: HRB5782 Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 40BF13E050B for ; Mon, 12 Jan 2009 04:25:31 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -3.368 X-Spam-Level: X-Spam-Status: No, score=-3.368 tagged_above=-50 required=4 tests=[AWL=-0.769, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTMKpNQeFiao for ; Mon, 12 Jan 2009 04:25:20 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id D55B93E0281 for ; Mon, 12 Jan 2009 04:25:19 -0800 (PST) Received: (qmail invoked by alias); 12 Jan 2009 12:25:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp049) with SMTP; 12 Jan 2009 13:25:18 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/vWjde5Zjv/sQlr98VNR+Nr0HJpArwMneYbA3exv sbZlfjK+Zp2TAu Message-ID: <496B36A8.4030403@gmx.de> Date: Mon, 12 Jan 2009 13:25:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <496A2F24.2040109@gmx.de> <496A9C77.9040004@gmail.com> <496AF820.2050808@gmx.de> <0abmm4lc9iku6qo9rlnkk5rmmq32l1s6tf@hive.bjoern.hoehrmann.de> In-Reply-To: <0abmm4lc9iku6qo9rlnkk5rmmq32l1s6tf@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 12:25:31 -0000 Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> Please elaborate: is *-Authenticate broken in the same way as Cookie in >> that combining multiple instances into the same header makes it >> *impossible* to parse the value, or is parsing just harder? > > You would essentially need a scheme with key=value pairs as parameters > where the key can include spaces like in > > WWW-Authenticate: Hypothetical realm="hypo", Security Level="3", ... > > Parsing this would require conflict resolution as it can be parsed as > one challenge for Hypothetical or two challenges for Hypothetical and > Security. As I recall, this is not the case for Negotiate or NTLM. > ... But auth-param is defined to be a token, thus can not contain a space character...: auth-scheme = token auth-param = token "=" ( token | quoted-string ) challenge = auth-scheme 1*SP 1#auth-param () BR, Julian Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 098E23E0505 for ; Mon, 12 Jan 2009 04:20:58 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmvDbdKq0+k3 for ; Mon, 12 Jan 2009 04:20:47 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id E097A3E0281 for ; Mon, 12 Jan 2009 04:20:46 -0800 (PST) Received: (qmail invoked by alias); 12 Jan 2009 12:20:45 -0000 Received: from dslb-088-074-184-231.pools.arcor-ip.net (EHLO hive) [88.74.184.231] by mail.gmx.net (mp005) with SMTP; 12 Jan 2009 13:20:45 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/ZvJkW4FvZ+Bc47ZTahD9sqg+q+CCpyMlygZEQpv X7k4vuRCficsB/ From: Bjoern Hoehrmann To: Julian Reschke Date: Mon, 12 Jan 2009 13:20:49 +0100 Message-ID: <0abmm4lc9iku6qo9rlnkk5rmmq32l1s6tf@hive.bjoern.hoehrmann.de> References: <496A2F24.2040109@gmx.de> <496A9C77.9040004@gmail.com> <496AF820.2050808@gmx.de> In-Reply-To: <496AF820.2050808@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 12:20:58 -0000 * Julian Reschke wrote: >Please elaborate: is *-Authenticate broken in the same way as Cookie in >that combining multiple instances into the same header makes it >*impossible* to parse the value, or is parsing just harder? You would essentially need a scheme with key=value pairs as parameters where the key can include spaces like in WWW-Authenticate: Hypothetical realm="hypo", Security Level="3", ... Parsing this would require conflict resolution as it can be parsed as one challenge for Hypothetical or two challenges for Hypothetical and Security. As I recall, this is not the case for Negotiate or NTLM. If you do have a case as above, you should still be able to process it with knowledge about the scheme, you would also have to have overlap in the parameter names and scheme names to get values that implementations who care would have trouble processing. So I don't think this counts as impossible. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id EACD63E0507 for ; Sun, 11 Jan 2009 23:58:44 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.805 X-Spam-Level: X-Spam-Status: No, score=-2.805 tagged_above=-50 required=4 tests=[AWL=-0.206, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLUW3E2E9oqO for ; Sun, 11 Jan 2009 23:58:33 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id A04203E024B for ; Sun, 11 Jan 2009 23:58:32 -0800 (PST) Received: (qmail invoked by alias); 12 Jan 2009 07:58:30 -0000 Received: from p508FC1E7.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.193.231] by mail.gmx.net (mp026) with SMTP; 12 Jan 2009 08:58:30 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19vOLhYvYJvSJfRYAQRS+jr8s/rGgS34sru4khLHF QkW02e/EyasgHx Message-ID: <496AF820.2050808@gmx.de> Date: Mon, 12 Jan 2009 08:58:24 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Dan Winship References: <496A2F24.2040109@gmx.de> <496A9C77.9040004@gmail.com> In-Reply-To: <496A9C77.9040004@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 07:58:45 -0000 Dan Winship wrote: > Yngve N. Pettersen (Developer Opera Software ASA) wrote: >>> At least as defined in RFC 2616 it makes no difference whether you have >>> two headers, or a single header with the two values separated by a comma >>> and RFC 2616, which defines the syntax of the header, notes: >> >> Well, you are right, and I had missed that one, primarily because I >> considered 2617 the entire (selfcontained, except for general syntax) >> specification for authentication, including the headers. (commenting Yngwe...) The definition of the WWW-Authenticate header is in RFC 2616, which says: WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge () And yes, that requires the reader to know the "#" rule (list production). And yes again, it would be good if in HTTPbis, we can have syntax and general semantics of HTTP auth in a single document. My proposal is to insert the contents RFC 2617, Section 1, into Part 7 of HTTPbis. >> This is possibly a problem that can occur frequently when splitting a >> specification across multiple documents > > 2617 actually explicitly warns about this: > > Note: User agents will need to take special care in parsing the WWW- > Authenticate or Proxy-Authenticate header field value if it contains > more than one challenge, or if more than one WWW-Authenticate header > field is provided, since the contents of a challenge may itself > contain a comma-separated list of authentication parameters. Indeed. >> It would not surprise me if this have bitten more than one >> authentication implementor > > Yeah, basically no one handles this correctly. I pointed this out on the > httpbis list, and the consensus seemed to be "then they should fix their > code". Please elaborate: is *-Authenticate broken in the same way as Cookie in that combining multiple instances into the same header makes it *impossible* to parse the value, or is parsing just harder? I wouldn't want to add another special case to Part 1, Section 4.2 () if it isn't absolutely required. >> However, I am aware of two methods (there may be more) that does not use >> the parameter parts in the initial step and cannot be used with the syntax >> in 2616: NTLM and Negotiate. One might say that they are not conformant, >> but they are in wide use on intranets. > > They don't use commas internally though, right? So you can still split > multiple challenges apart by using the rule "a comma followed by a token > which is not followed by an equals sign indicates the start of a new > challenge". Easy! :-/ Let's try to nail down a way to properly parse those. If we can't, we'll need to think about another special case in HTTPbis. BR, Julian Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id CE08F3E04F4 for ; Sun, 11 Jan 2009 17:27:54 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SW52zqyuCIUK for ; Sun, 11 Jan 2009 17:27:51 -0800 (PST) Received: from mysterion.org (mysterion.org [69.25.196.35]) by leka.osafoundation.org (Postfix) with ESMTP id B0B823E04DC for ; Sun, 11 Jan 2009 17:27:51 -0800 (PST) Received: from x61.home.mysterion.org (72-255-49-77.client.stsn.net [72.255.49.77]) by mysterion.org (Postfix) with ESMTPA id 1DF688028D; Sun, 11 Jan 2009 20:27:50 -0500 (EST) Message-ID: <496A9C77.9040004@gmail.com> Date: Sun, 11 Jan 2009 20:27:19 -0500 From: Dan Winship User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: "Yngve N. Pettersen (Developer Opera Software ASA)" References: <496A2F24.2040109@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 01:27:54 -0000 Yngve N. Pettersen (Developer Opera Software ASA) wrote: >> At least as defined in RFC 2616 it makes no difference whether you have >> two headers, or a single header with the two values separated by a comma >> and RFC 2616, which defines the syntax of the header, notes: > > > Well, you are right, and I had missed that one, primarily because I > considered 2617 the entire (selfcontained, except for general syntax) > specification for authentication, including the headers. > > This is possibly a problem that can occur frequently when splitting a > specification across multiple documents 2617 actually explicitly warns about this: Note: User agents will need to take special care in parsing the WWW- Authenticate or Proxy-Authenticate header field value if it contains more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge may itself contain a comma-separated list of authentication parameters. > It would not surprise me if this have bitten more than one > authentication implementor Yeah, basically no one handles this correctly. I pointed this out on the httpbis list, and the consensus seemed to be "then they should fix their code". > However, I am aware of two methods (there may be more) that does not use > the parameter parts in the initial step and cannot be used with the syntax > in 2616: NTLM and Negotiate. One might say that they are not conformant, > but they are in wide use on intranets. They don't use commas internally though, right? So you can still split multiple challenges apart by using the rule "a comma followed by a token which is not followed by an equals sign indicates the start of a new challenge". Easy! :-/ -- Dan Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 388703E04D6 for ; Sun, 11 Jan 2009 15:13:37 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-50 required=4 tests=[AWL=0.233, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14CUrF2LZbQV for ; Sun, 11 Jan 2009 15:13:25 -0800 (PST) Received: from smtp.opera.com (sam.opera.com [213.236.208.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 741343E04DF for ; Sun, 11 Jan 2009 15:13:25 -0800 (PST) Received: from nimisha.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id n0BNDLKK029211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 11 Jan 2009 23:13:22 GMT Date: Mon, 12 Jan 2009 00:13:21 +0100 To: "Bjoern Hoehrmann" From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <496A2F24.2040109@gmx.de> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.26 (Win32) Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 23:13:37 -0000 On Sun, 11 Jan 2009 22:39:53 +0100, Bjoern Hoehrmann wrote: > * Yngve N. Pettersen (Developer Opera Software ASA) wrote: >> This test sends an (IMO) invalid header >> >> WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic" >> >> All parameters in WWW-Authenticate, except the first, are comma >> separated, >> combining two WWW_Authenticate headers by comma separating them >> therefore >> IMO changes the meaning of the meaning. This becomed very clear if you >> add >> a Digest authentication challenge as well. > > At least as defined in RFC 2616 it makes no difference whether you have > two headers, or a single header with the two values separated by a comma > and RFC 2616, which defines the syntax of the header, notes: Well, you are right, and I had missed that one, primarily because I considered 2617 the entire (selfcontained, except for general syntax) specification for authentication, including the headers. This is possibly a problem that can occur frequently when splitting a specification across multiple documents: Part of the fundamentals is in one document, but the most of the defintition is in another document which leaves out recollecting/repeating the fundamentals detailed in the other document. IMO 2617 should have duplicated the header definitions from 2616. It would not surprise me if this have bitten more than one authentication implementor, as 2617 is the primary reference for the methods and where the implementor would turn for all information relevant to implementing support for those methods and the headers. However, I am aware of two methods (there may be more) that does not use the parameter parts in the initial step and cannot be used with the syntax in 2616: NTLM and Negotiate. One might say that they are not conformant, but they are in wide use on intranets. One might perhaps note that if a syntax element with multiple (low level) elements can be used repeatedly within the same header, then the lower level elements within the syntax should use a different separator than the separator used for the higher level elements. (in RFC2965 the use of commas in the port element require the entire value to be qouted in order to separate them from the commas that can be used in the high level syntax.) -- 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 localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 8EF173E04DC for ; Sun, 11 Jan 2009 14:50:50 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[AWL=0.000, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Cxa6eRU4zaI for ; Sun, 11 Jan 2009 14:50:48 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by leka.osafoundation.org (Postfix) with ESMTP id F1C663E04C8 for ; Sun, 11 Jan 2009 14:50:47 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so3806879fgg.17 for ; Sun, 11 Jan 2009 14:50:46 -0800 (PST) Received: by 10.86.51.10 with SMTP id y10mr16302233fgy.9.1231714245698; Sun, 11 Jan 2009 14:50:45 -0800 (PST) Received: by 10.86.30.11 with HTTP; Sun, 11 Jan 2009 14:50:45 -0800 (PST) Message-ID: Date: Sun, 11 Jan 2009 23:50:45 +0100 From: "Thomas Broyer" To: "Yngve N. Pettersen (Developer Opera Software ASA)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <496A2F24.2040109@gmx.de> Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 22:50:50 -0000 On Sun, Jan 11, 2009 at 10:17 PM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > On Sun, 11 Jan 2009 21:00:36 +0100, Thomas Broyer wrote: > >>> - 401 with WWW-Authenticate / Cookie *and* Basic (for instance). >> >> http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis > > This test sends an (IMO) invalid header > > WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic" My *.asis file contained two distinct headers, so it must be an artifact of apache mod_asis... I've put the tests under version control so you can get the source and run them with some other server: http://hg.ltgt.net/http-cookie-auth/file/tip/tests (and as Bjoern pointed out, the combined header is nonetheless valid) -- Thomas Broyer Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id A07373E04D1 for ; Sun, 11 Jan 2009 13:39:55 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh5RrqhMOU+s for ; Sun, 11 Jan 2009 13:39:52 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id 5C7393E04C8 for ; Sun, 11 Jan 2009 13:39:52 -0800 (PST) Received: (qmail invoked by alias); 11 Jan 2009 21:39:50 -0000 Received: from dslb-088-075-237-191.pools.arcor-ip.net (EHLO hive) [88.75.237.191] by mail.gmx.net (mp021) with SMTP; 11 Jan 2009 22:39:50 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+MZPIxvf2MEByqjXJoyTyBZHNkGS5l0bzbzfk0l+ VaRBrFiG8uS57D From: Bjoern Hoehrmann To: "Yngve N. Pettersen (Developer Opera Software ASA)" Date: Sun, 11 Jan 2009 22:39:53 +0100 Message-ID: References: <496A2F24.2040109@gmx.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 21:39:55 -0000 * Yngve N. Pettersen (Developer Opera Software ASA) wrote: >This test sends an (IMO) invalid header > >WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic" > >All parameters in WWW-Authenticate, except the first, are comma separated, >combining two WWW_Authenticate headers by comma separating them therefore >IMO changes the meaning of the meaning. This becomed very clear if you add >a Digest authentication challenge as well. At least as defined in RFC 2616 it makes no difference whether you have two headers, or a single header with the two values separated by a comma and RFC 2616, which defines the syntax of the header, notes: The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. User agents are advised to take special care in parsing the WWW- Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters. There have been discussions about changing how multiple headers are joined, I am not sure what the status of that is. >I suspect this needs some clearing up in HTTPbis. My recommendation is to >require only a single challenge in each WWW-Authenticate header, and to >forbid joining of multiple authentication headers. (Don't forget to raise that then as issue :-) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 63BB73E04D1 for ; Sun, 11 Jan 2009 13:17:44 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2+LdFfbHLeP for ; Sun, 11 Jan 2009 13:17:32 -0800 (PST) Received: from smtp.opera.com (sam.opera.com [213.236.208.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 45DD33E04C8 for ; Sun, 11 Jan 2009 13:17:31 -0800 (PST) Received: from nimisha.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id n0BLHRYc024927 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 11 Jan 2009 21:17:28 GMT Date: Sun, 11 Jan 2009 22:17:27 +0100 To: "Thomas Broyer" , ietf-http-auth@osafoundation.org From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <496A2F24.2040109@gmx.de> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.26 (Win32) Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 21:17:44 -0000 On Sun, 11 Jan 2009 21:00:36 +0100, Thomas Broyer wrote: >> - 401 with WWW-Authenticate / Cookie *and* Basic (for instance). > > http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis This test sends an (IMO) invalid header WWW-Authenticate: Cookie realm="Cookie", Basic realm="Basic" All parameters in WWW-Authenticate, except the first, are comma separated, combining two WWW_Authenticate headers by comma separating them therefore IMO changes the meaning of the meaning. This becomed very clear if you add a Digest authentication challenge as well. Each method offered must be in a separate header. > http://ltgt.net/tests/http-cookie-auth/basic-and-cookie.asis The same applies for this one. I do notice, though, upon a *very* close reading (resembling what happened with ccTLD cookies in Netscape's spec), that RFC 2617 says in a single sentence (with similar for Proxy) that This response MUST include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. There is no syntax definition in RFC2617 of what the form of WWW-Authenticate is, only the form of the challenge. The above quote may be taken to mean that the definition of WWW-Authenticate is WWW-Authenticate ":" 1#challenge challenge = auth-scheme 1*SP 1#auth-param while Opera is assuming, due to the syntax of "challenge" WWW-Authenticate ":" challenge challenge = auth-scheme 1*SP 1#auth-param a defintion which IMO makes much more sense considering the combined use of space and comma as separators (the 1#challenge variant would require clients to scan each parameter for an internal space, and would make parsing more difficult). I suspect this needs some clearing up in HTTPbis. My recommendation is to require only a single challenge in each WWW-Authenticate header, and to forbid joining of multiple authentication headers. AFAIK all servers send each method offered as an individual header, not combined. This is also a method that makes sense when authentication methods can be plugged into the server in the form of modules. For reference: Cookies (RFC2965) got around the multiple cookie problem only by requiring all non-cookie parameters on the header to start with "$". -- 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 localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id EFAE73E04B7 for ; Sun, 11 Jan 2009 12:23:49 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.842 X-Spam-Level: X-Spam-Status: No, score=-2.842 tagged_above=-50 required=4 tests=[AWL=-0.243, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwxv--6XBGzI for ; Sun, 11 Jan 2009 12:23:48 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id EAA913E049E for ; Sun, 11 Jan 2009 12:23:46 -0800 (PST) Received: (qmail invoked by alias); 11 Jan 2009 20:23:44 -0000 Received: from p508FBCB5.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.188.181] by mail.gmx.net (mp015) with SMTP; 11 Jan 2009 21:23:44 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/prUFCbznpTY103TsajLs5UYUCnqCJZLLeIsne0H Yf6/KoLpxNeWgo Message-ID: <496A5547.8080608@gmx.de> Date: Sun, 11 Jan 2009 21:23:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Thomas Broyer References: <496A2F24.2040109@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 20:23:50 -0000 Thomas Broyer wrote: > ... >> So it seems that there are at least three scenarios to be tested: > > Note that the "results" above are only for WWW-Authenticateion / > Cookie (test00). > ... Yep -- I was hoping you add the tests, which you did. (Thanks!) > ... > http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis > http://ltgt.net/tests/http-cookie-auth/basic-and-cookie.asis > > You'd have to sniff your connection (I generally use Fiddler on > Windows) to know what your browser actually do. (another good one is Microsoft Network Monitor 3.2) > Chrome "stable" pops up the authentication dialog with "Cookie" in the > first test and "Basic" in the second, so I guess (I have no Fiddler at > hand) in the first case it won't send any Authorization header to the > server (as in the simple WWW-Authenticate / Cookie test). I just tried with 2.0.156.1, and for the response body is displayed immediately. > Opera 9.63 shows the blocking error page for cookie-and-basic, and > pops up the authentication dialog for basic-and-cookie; so order > matters. Right. But it shouldn't, methinks. Otherwise deploying new auth schemes gets even harder as it is right now. This should be reported as a bug to Opera... > IE7 and Firefox 3 (3.0.4) both show the 401 response body in the > cookie-and-basic case, and pops up the authentication dialog in the > basic-and-cookie case. Which happens to be what we want (but really isn't what they should be doing...). > Safari 3.2.1 on Windows shows the "Basic" prompt in both cases. When > you dismiss the prompt, you're *not* given the 401 response body. Picking the only known scheme regardless of ordering seems to me the right thing to do, although it will make it harder to deploy "Cookie". Best regards, Julian Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 10FE03E04D1 for ; Sun, 11 Jan 2009 12:01:00 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI9P5hbZd9ln for ; Sun, 11 Jan 2009 12:00:38 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by leka.osafoundation.org (Postfix) with ESMTP id 9AB0E3E04ED for ; Sun, 11 Jan 2009 12:00:37 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so3789245fgg.17 for ; Sun, 11 Jan 2009 12:00:36 -0800 (PST) Received: by 10.86.84.5 with SMTP id h5mr16252978fgb.10.1231704036085; Sun, 11 Jan 2009 12:00:36 -0800 (PST) Received: by 10.86.30.11 with HTTP; Sun, 11 Jan 2009 12:00:36 -0800 (PST) Message-ID: Date: Sun, 11 Jan 2009 21:00:36 +0100 From: "Thomas Broyer" To: ietf-http-auth@osafoundation.org In-Reply-To: <496A2F24.2040109@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <496A2F24.2040109@gmx.de> Subject: Re: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 20:01:00 -0000 On Sun, Jan 11, 2009 at 6:40 PM, Julian Reschke wrote: > Thomas Broyer wrote: >> >> ... >> Tests at: http://ltgt.net/tests/http-cookie-auth/ >> Results at: >> http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html >> ... > > So it seems that there are at least three scenarios to be tested: Note that the "results" above are only for WWW-Authenticateion / Cookie (test00). > - 401 with no WWW-Authenticate header (illegal according to RFC2617, but > interesting to see how the various UAs behave), http://ltgt.net/tests/http-cookie-auth/no-www-authenticate.asis HTML content displayed as is in all the browsers I've tested (same list as ua-compat.html) > - 401 with WWW-Authenticate / Cookie, and http://ltgt.net/tests/http-cookie-auth/test00/ Results in ua-compat.html linked above. Summary: will work in Chrome (works in "dev" version), doesn't work in Opera (blocking error page) but I've filed a bug so I hope it'll be fixed in Opera 10. > - 401 with WWW-Authenticate / Cookie *and* Basic (for instance). http://ltgt.net/tests/http-cookie-auth/cookie-and-basic.asis http://ltgt.net/tests/http-cookie-auth/basic-and-cookie.asis You'd have to sniff your connection (I generally use Fiddler on Windows) to know what your browser actually do. Chrome "stable" pops up the authentication dialog with "Cookie" in the first test and "Basic" in the second, so I guess (I have no Fiddler at hand) in the first case it won't send any Authorization header to the server (as in the simple WWW-Authenticate / Cookie test). Opera 9.63 shows the blocking error page for cookie-and-basic, and pops up the authentication dialog for basic-and-cookie; so order matters. IE7 and Firefox 3 (3.0.4) both show the 401 response body in the cookie-and-basic case, and pops up the authentication dialog in the basic-and-cookie case. Safari 3.2.1 on Windows shows the "Basic" prompt in both cases. When you dismiss the prompt, you're *not* given the 401 response body. -- Thomas Broyer Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 5BE083E04AF for ; Sun, 11 Jan 2009 09:41:36 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.858 X-Spam-Level: X-Spam-Status: No, score=-2.858 tagged_above=-50 required=4 tests=[AWL=-0.259, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLyHCR1xw9tV for ; Sun, 11 Jan 2009 09:41:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id 5256A3E0474 for ; Sun, 11 Jan 2009 09:41:23 -0800 (PST) Received: (qmail invoked by alias); 11 Jan 2009 17:41:17 -0000 Received: from p508FBCB5.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.188.181] by mail.gmx.net (mp011) with SMTP; 11 Jan 2009 18:41:17 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Ruo0sAFqRGk1ns57RWRzGEQv+bjo4nN69jjFzqj valIA3KnOCAuQo Message-ID: <496A2F24.2040109@gmx.de> Date: Sun, 11 Jan 2009 18:40:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Thomas Broyer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 Cc: ietf-http-auth@osafoundation.org Subject: [ietf-http-auth] Test Scenarios, was: Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 17:41:36 -0000 Thomas Broyer wrote: > ... > Tests at: http://ltgt.net/tests/http-cookie-auth/ > Results at: http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html > ... So it seems that there are at least three scenarios to be tested: - 401 with no WWW-Authenticate header (illegal according to RFC2617, but interesting to see how the various UAs behave), - 401 with WWW-Authenticate / Cookie, and - 401 with WWW-Authenticate / Cookie *and* Basic (for instance). The latter case would be used for sites that want to support a hybrid approach: form based login for browsers, programmatic login for other clients (such as WebDAV, AtomPub...). Currently these sites need to do user agent sniffing or just hope for those 'other' clients not to start their conversation with GET. Best regards, Julian Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id DA1323E0446 for ; Sun, 11 Jan 2009 06:43:26 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-50 required=4 tests=[AWL=-0.287, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Emm0mWQIadQH for ; Sun, 11 Jan 2009 06:43:12 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id 16C5077D702 for ; Sun, 11 Jan 2009 06:43:02 -0800 (PST) Received: (qmail invoked by alias); 11 Jan 2009 14:43:01 -0000 Received: from p508FBCB5.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.188.181] by mail.gmx.net (mp011) with SMTP; 11 Jan 2009 15:43:01 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18cqcZUmO8clUOLGF9EzSyx3g+c7J+Iz9ZRPqzwGP ML1k/WUm5azHdt Message-ID: <496A056F.9080500@gmx.de> Date: Sun, 11 Jan 2009 15:42:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Thomas Broyer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: ietf-http-auth@osafoundation.org Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 14:43:27 -0000 Thomas Broyer wrote: > Summary of this long reply: > The I-D is absolutely unclear about it but the goal is that the > migration path from current implementations to sending a 401 is as > easy as possible (in many cases, it'd be nothing more than either > adding two lines of code for sending the 401 status and the > WWW-Authenticate header; or replacing a redirect with an internal > forward; then come the SSO systems which are a bit harder to deal > with, but not that much actually, even when crossing domain > boundaries). > The (almost) only motivation for a specific auth scheme is that a 401 > response requires a WWW-Authenticate. (I've found however that not > sending a WWW-Authenticate at all is even better supported by > browsers.) > Moving away from cookies (while supporting them for backwards > compatibility) is not part of the plan; at least for "version" 1" of > the Cookie auth scheme. > > Tests at: http://ltgt.net/tests/http-cookie-auth/ > Results at: http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html > ... Good stuff. I agree that it would be helpful if the next draft would elaborate a bit on goals and non-goals, such as: 1) have a HTTP auth scheme that can be returned with a 401 2) whether, for instance for text/html, the additional information should be sufficient for non-interactive clients to log in I think there's sufficient support for part 1), even though currently it breaks with Opera. However I'm optimistic that this could be fixed in future Opera versions, and that their upgrade rate is good enough not to worry about 9.6 too much in time this is done. (Yngwe, are you on this list?) Solving 2) is much harder, at least in the general case where there's more than username and password. Maybe there's a middle ground though; what about trying just to solve the special case where the form indeed only needs a name and a password? That may be sufficiently common to be useful. Related to this; if this moves forward, are there changes for HTML 5 that would help? Such as pointing UA implementers to this spec? (Anything else?) Best regards, Julian - remiding Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 4498E77D700 for ; Sat, 10 Jan 2009 18:40:24 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-+J0z0LPWEv for ; Sat, 10 Jan 2009 18:40:20 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by leka.osafoundation.org (Postfix) with ESMTP id 01A203E04BD for ; Sat, 10 Jan 2009 18:40:18 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so3700189fgg.17 for ; Sat, 10 Jan 2009 18:40:17 -0800 (PST) Received: by 10.86.60.14 with SMTP id i14mr15814146fga.70.1231641616657; Sat, 10 Jan 2009 18:40:16 -0800 (PST) Received: by 10.86.30.11 with HTTP; Sat, 10 Jan 2009 18:40:16 -0800 (PST) Message-ID: Date: Sun, 11 Jan 2009 03:40:16 +0100 From: "Thomas Broyer" To: ietf-http-auth@osafoundation.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 02:40:24 -0000 U3VtbWFyeSBvZiB0aGlzIGxvbmcgcmVwbHk6ClRoZSBJLUQgaXMgYWJzb2x1dGVseSB1bmNsZWFy IGFib3V0IGl0IGJ1dCB0aGUgZ29hbCBpcyB0aGF0IHRoZQptaWdyYXRpb24gcGF0aCBmcm9tIGN1 cnJlbnQgaW1wbGVtZW50YXRpb25zIHRvIHNlbmRpbmcgYSA0MDEgaXMgYXMKZWFzeSBhcyBwb3Nz aWJsZSAoaW4gbWFueSBjYXNlcywgaXQnZCBiZSBub3RoaW5nIG1vcmUgdGhhbiBlaXRoZXIKYWRk aW5nIHR3byBsaW5lcyBvZiBjb2RlIGZvciBzZW5kaW5nIHRoZSA0MDEgc3RhdHVzIGFuZCB0aGUK V1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXI7IG9yIHJlcGxhY2luZyBhIHJlZGlyZWN0IHdpdGggYW4g aW50ZXJuYWwKZm9yd2FyZDsgdGhlbiBjb21lIHRoZSBTU08gc3lzdGVtcyB3aGljaCBhcmUgYSBi aXQgaGFyZGVyIHRvIGRlYWwKd2l0aCwgYnV0IG5vdCB0aGF0IG11Y2ggYWN0dWFsbHksIGV2ZW4g d2hlbiBjcm9zc2luZyBkb21haW4KYm91bmRhcmllcykuClRoZSAoYWxtb3N0KSBvbmx5IG1vdGl2 YXRpb24gZm9yIGEgc3BlY2lmaWMgYXV0aCBzY2hlbWUgaXMgdGhhdCBhIDQwMQpyZXNwb25zZSBy ZXF1aXJlcyBhIFdXVy1BdXRoZW50aWNhdGUuIChJJ3ZlIGZvdW5kIGhvd2V2ZXIgdGhhdCBub3QK c2VuZGluZyBhIFdXVy1BdXRoZW50aWNhdGUgYXQgYWxsIGlzIGV2ZW4gYmV0dGVyIHN1cHBvcnRl ZCBieQpicm93c2Vycy4pCk1vdmluZyBhd2F5IGZyb20gY29va2llcyAod2hpbGUgc3VwcG9ydGlu ZyB0aGVtIGZvciBiYWNrd2FyZHMKY29tcGF0aWJpbGl0eSkgaXMgbm90IHBhcnQgb2YgdGhlIHBs YW47IGF0IGxlYXN0IGZvciAidmVyc2lvbiIgMSIgb2YKdGhlIENvb2tpZSBhdXRoIHNjaGVtZS4K ClRlc3RzIGF0OiBodHRwOi8vbHRndC5uZXQvdGVzdHMvaHR0cC1jb29raWUtYXV0aC8KUmVzdWx0 cyBhdDogaHR0cDovL2hnLmx0Z3QubmV0L2h0dHAtY29va2llLWF1dGgvcmF3LWZpbGUvdGlwL3Vh LWNvbXBhdC5odG1sCgpPbiBGcmksIEphbiA5LCAyMDA5IGF0IDg6MzIgUE0sIEJydW5vIEhhcmJ1 bG90IHdyb3RlOgo+Cj4gVGhvbWFzIEJyb3llciB3cm90ZToKPj4KPj4gU28geWVzLCBtYXliZSBh IGZvcm0taWQgd291bGQgYmUgYmV0dGVyPwo+Cj4gWWVzLCBJJ2QgYmUgaW4gZmF2b3VyIG9mIGEg Zm9ybS1pZC4KPiBJIHdhcyB0aGlua2luZyBvZiBhIG5vbi1icm93c2VyIHVzZXItYWdlbnQsIHdo aWNoIGlzIHByb2JhYmx5IHRoZSBzYW1lCj4gYXMgd2hhdCB5b3UgbWVhbiBieSB0aGUgY2FzZSB3 aGVyZSB0aGUgY3JlZGVudGlhbHMgaGF2ZSBiZWVuIHBhc3NlZAo+IHVwLWZyb250LgoKV2VsbCwg aW4gdGhlIGNhc2Ugb2YgYSBub24tYnJvd3NlciBVQSwgaWRlbnRpZnlpbmcgdGhlIGxvZ2luIGZv cm0gaXMKdXNlZnVsIGJ1dCBub3QgZW5vdWdoLCBhcyBpdCB3b3VsZCBoYXZlIHRvIGZpbGwgaXQs IGFuZCB0aGF0IHRoaXMKbWlnaHQgZGVwZW5kIG9uIG90aGVyIHBhcnRzIG9mIHRoZSBwYWdlIChp ZiB3ZSBvbmx5IHNwZWFrIGFib3V0IEhUTUwKZm9ybXMgaGVyZSkgc3VjaCBhcyBqYXZhc2NyaXB0 LCBpbWFnZXMgKGNhcHRjaGEpLCBldGMuCkFsc28sIHRoZSBDb29raWUgYXV0aCBzY2hlbWUgYWxs b3dzIGZvciBjcmVkZW50aWFscyBiZXlvbmQgYQp1c2VyK3Bhc3N3b3JkIHBhaXIgKHBlb3BsZSBt ZW50aW9ubmVkIHRoaXMgb24gdGhlIFdIQVQgV0csIEknbSBub3QKYXdhcmUgb2YgYW55dGhpbmcg b3RoZXIgdGhhbiB0aGUgZmFtb3VzICJyZW1lbWJlciBtZSIgY2hlY2sgYm94IGFuZAp0aGUgImFz ayBtZSB3aGVuIGNoYW5naW5nIHNlcnZpY2UiIG9mIEpBLVNJRyBDQVMpLgpJZiB5b3UgZG8gbm90 IHByb3ZpZGUgY3JlZGVudGlhbHMgdXBmcm9udCAoYXMgaW4sIGluIGEgbm9uLWludGVyYWN0aXZl CndheSksIGFsbCB5b3UgY2FuIGRvIGlzIHByZXNlbnQgdGhlIHJlc3BvbnNlIGJvZHkgdG8gdGhl IGVuZC11c2VyLgpBY3R1YWxseSwgbm9uLWludGVyZmFjdGl2ZSBVQXMgbWlnaHQgdmVyeSB3ZWxs IGJlIHVuYWJsZSB0byBsb2cgaW4gdG8KbWFueSBhcHBsaWNhdGlvbnMvc2l0ZXMgd2hlbiB0aGV5 IHJlcXVpcmUgc29tZSBkYXRhIHRoYXQgY2hhbmdlcyBhdAplYWNoIHJlcXVlc3QgKGNhcHRjaGEs IHNvbWUgamF2YXNjcmlwdCBjb21wdXRhdGlvbiB3aG9zZSByZXN1bHQgaXMgcHV0CmludG8gYW4g PGlucHV0IHR5cGU9aGlkZGVuPiwgbm90IGV2ZW4gbWVudGlvbm5pbmcgY29va2llcyBzZXQgYnkK amF2YXNjcmlwdCByYXRoZXIgdGhhbiBieSBpc3N1aW5nIGEgcmVxdWVzdCwgcmVxdWVzdHMgZG9u ZSB3aXRoIEFKQVgKd2l0aG91dCAiZ3JhY2VmdWwgZGVncmFkYXRpb24iIHdoZW4gdGhhdCdzIG5v dCBwb3NzaWJsZSwgZXRjLikKSSBtZWFuLCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgc2lnbmluZyBp biBpcyBvbmx5IHBvc3NpYmxlIGZvcgpicm93c2VycywgYW5kL29yIGJyb3dzZXJzIGRyaXZlbiBi eSBhIGh1bWFuIGJlaW5nLgpUaGUgZ29hbCBvZiB0aGUgQ29va2llIGF1dGggc2NoZW1lIGlzIHRv IGJlIGFibGUgdG8gcmV0dXJuIGEgNDAxIHRvCm5vbi1icm93c2VyIFVBcyBzbyB0aGF0IHRoZXkg a25vdyB0aGVyZSdzIGFuIGF1dGhvcml6YXRpb24gaXNzdWUKKHdoaWNoIHRoZXkgY2Fubm90IGRv IHdoZW4gdGhlIGxvZ2luIGZvcm0gaXMgc2VudCB3aXRoIGEgMjAwIHN0YXR1cyBvcgp0aHJvdWdo IGEgcmVkaXJlY3Rpb24sIGFzIGlzIHRoZSBjYXNlIHRvZGF5KTsgYW5kIGEgNDAxIHJlc3BvbnNl CnJlcXVpcmVzIGEgV1dXLUF1dGhlbnRpY2F0aW9uIGhlYWRlci4gSSBkb3VidCB3ZSBjYW4gZ28g YW55d2hlcmUKZmFydGhlciAoYXBhcnQgZnJvbSBuYW1pbmcgdGhlIGNvb2tpZXMgdXNlZCwgYXMg cHJvcG9zZWQgd2l0aApjb29raWUtbmFtZS9zZWN1cmUtY29va2llLW5hbWUpLgoKSWRlbnRpZnlp bmcgdGhlIGxvZ2luIGZvcm0gbWlnaHQgaGVscCBhdXRvLWZpbGxpbmcgKG9yIE5PVAphdXRvLWZp bGxpbmcgZm9yIGJldHRlciBzZWN1cml0eSAvIHJlZHVjZWQgY29udmVuaWVuY2UpIG9yIGV2ZW50 dWFsbHkKc3RvcmluZyBhdXRvLWZpbGxpbmcgdmFsdWVzIGludG8gYSBtb3JlIHNlY3VyZSBzdG9y YWdlIHRoYW4gZm9yIG90aGVyCmZvcm1zLgoKPiBXaGF0IEknZCBsaWtlIHRvIHNlZSBpbiB1c2Vy LWFnZW50cyBzdXBwb3J0aW5nIHRoaXMgdHlwZSBvZgo+IGF1dGhlbnRpY2F0aW9uLCBpcyB0aGUg YXdhcmVuZXNzIHRoYXQgYSBwb3RlbnRpYWwgcmVkaXJlY3Rpb24gdG8gYSBmb3JtCj4gaXMganVz dCBmb3IgYXV0aGVudGljYXRpb24gYW5kIHRoYXQgaXQgc2hvdWxkIGdvIGJhY2sgdG8gdGhlIGlu aXRpYWwKPiByZXF1ZXN0IHVwb24gc3VjY2Vzc2Z1bCBhdXRoZW50aWNhdGlvbi4KCkkgdGhvdWdo dCBhYm91dCBhZGRpbmcgYSBuZXcgM3h4IGNvZGUgaW5zdGVhZCB0byBjb21tdW5pY2F0ZSB0aGUg ZmFjdAp0aGF0IHlvdSdyZSByZWRpcmVjdGluZyB0byBhIGxvZ2luIGZvcm07IGJ1dCAic3VjY2Vz c2Z1bAphdXRoZW50aWNhdGlvbiIgbWlnaHQgYmUgaGFyZCB0byB0ZWxsICh0byBhdXRvbWF0aWNh bGx5IHJlLXRyeSB0aGUKb3JpZ2luYWwgcmVxdWVzdCkuCgpIb3dldmVyLCB0aGVyZSBhcmUgc29t ZSBmcmFtZXdvcmtzIChBbGZyZXNjbyBTVVJGKSBhbmQgYXBwbGljYXRpb25zCihkb3RQcm9qZWN0 KSBvdXQgdGhlcmUgdGhhdCBzZW5kIHRoZSBsb2dpbiBmb3JtIHdpdGhpbiBhIDIwMCAoT0spCnJl c3BvbnNlOyBmb3IgdGhvc2UgYSA0MDEgd291bGQgYmUgZWFzaWVyIHRvIGltcGxlbWVudC4gRm9y IG90aGVycwpyZWRpcmVjdGluZyB0byBhIGxvZ2luIGZvcm0sIG1vc3QgZnJhbWV3b3Jrcy9ydW50 aW1lcyBhbGxvdyBmb3J3YXJkaW5nCnJlcXVlc3RzIGludGVybmFsbHkgdG8gb3RoZXIgcmVzb3Vy Y2VzIChBU1AuTkVULCBKYXZhIFNlcnZsZXQsIHRoZQp2aXJ0dWFsKCkgYW5kIG5zYXBpX3ZpcnR1 YWwoKSBmdW5jdGlvbnMgaW4gUEhQKSwgb3IgaW5jbHVkaW5nIGEgc2hhcmVkCnJlc291cmNlIChp bmNsdWRlIGluIFBIUCksIHNvIGNoYW5naW5nIGEgM3h4IGludG8gYSA0MDEgaXMgc3RpbGwKcG9z c2libGUuIFdoZW4gaXQgaXMgbm90IHBvc3NpYmxlLCBhIDQwMSBjYW4gc3RpbGwgcmVkaXJlY3Qg dXNpbmcgYQoibWV0YSByZWZyZXNoIiBhbmQvb3IgamF2YXNjcmlwdCAoYSBuZXcgM3h4IHdvdWxk IGJlIGJldHRlciBpbmRlYWQsCmJ1dCBub3QgcmVxdWlyZWQgc2hvcnQtdGVybSBhcyBmYXIgYXMg YnJvd3Nlci1jb21wYXRpYmlsaXR5IGlzCmNvbmNlcm5lZCkuCkFuZCByZW1lbWJlciB0aGF0IGZv ciBub24tYnJvd3NlciBVQXMsIGhhdmluZyBhIDQwMSwgZXZlbiBpZiB1bnVzYWJsZSwKaXMgc3Rp bGwgYmV0dGVyIHRoYW4gYSAyMDAgb3IgM3h4IChleGNlcHQgaWYgdGhhdCAzeHggd291bGQgYmUg YSBuZXcKb25lIHNwZWNpZmljYWxseSBkZXNpZ25lZCB0byBjb252ZXkgYW4gbGFjayBvZiBhdXRo b3JpemF0aW9ucykuCgo+IEl0IGRvZXNuJ3QgbWF0dGVyIHRoYW4gbXVjaCBmb3IKPiBHRVQgcmVx dWVzdHMsIGJ1dCBpdCdzIG1vcmUgaW1wb3J0YW50IGZvciBhIFBPU1QgcmVxdWVzdC4KPgo+IEFu IGV4YW1wbGUgb2YgdGhpcyBwcm9ibGVtIGlzIHNvbWV0aGluZyB0aGF0IGhhcHBlbnMgb24gYSB3 aWtpIHRoYXQgSQo+IHVzZSwgd2hlcmUgdGhlIHNlc3Npb24gY29va2llIGV4cGlyZXMgYWZ0ZXIg YSByYXRoZXIgc2hvcnQgcGVyaW9kIG9mCj4gdGltZS4gU3VwcG9zZSB5b3UncmUgZWRpdGluZyBh IHBhZ2UgaW4geW91ciBicm93c2VyLCB0aGF0IHlvdSdyZSBhYm91dAo+IHRvIFBPU1QgdGhlIG1v ZGlmaWNhdGlvbiwgYnV0IHRoYXQgeW91ciBjcmVkZW50aWFscyBoYXZlIGV4cGlyZWQuCgpGb3Ig YSBnb29kIFVYLCB0aGUgYXBwIHNob3VsZCByZWFsbHkga2VlcCB0aGUgc2VudCBkYXRhIHVudGls CmF1dGhvcml6YXRpb24gaXMgc3VjY2Vzc2Z1bCAocGFzc2luZyBpdCBhbG9uZyB3aXRoIGF1dGhl bnRpY2F0aW9uIGluZm8KaWYgcG9zc2libGU7IG9yIGRvaW5nIGF1dGhlbnRpY2F0aW9uIGluIGFu b3RoZXIgYnJvd3NlciBjb250ZXh0IHN1Y2gKYXMgbmV3IHdpbmRvdyBvciBhbiBpZnJhbWUpLgoK PiAgIEEuIElmIHRoZSB3ZWJzaXRlIHVzZXMgSFRUUCBCYXNpYyAob3Igb3RoZXIgV1dXLUF1dGhl bnRpY2F0ZSBoZWFkZXIKPiBhdXRoLiksIHRoZSBpbnRlcmFjdGlvbiB3aWxsIGJlIGxpa2UgdGhp czoKPgo+ICAgICAgKDEpIEMtPlM6Cj4gICAgICAgIFBPU1QgaHR0cDovL2V4YW1wbGUub3JnL215 cGFnZSBIVFRQLzEuMQo+Cj4gICAgICAgIHRoZS11cGRhdGVkLXRleHQKPgo+Cj4gICAgICAoMikg Uy0+QzoKPiAgICAgICAgSFRUUC8xLjEgNDAxCj4gICAgICAgIFdXVy1BdXRoZW50aWNhdGU6IEJh c2ljIHh4eHh4eHh4eHgKPgo+ICAgICAgICA8dGl0bGU+VW5hdXRob3JpemVkPC90aXRsZT4KPgo+ IChUaGUgYnJvd3NlciBhc2tzIHRoZSB1c2VyIGZvciB0aGUgcGFzc3dvcmQuKQo+Cj4gICAgICAo MykgQy0+UzoKPiAgICAgICAgUE9TVCBodHRwOi8vZXhhbXBsZS5vcmcvbXlwYWdlIEhUVFAvMS4x Cj4gICAgICAgIEF1dGhvcml6YXRpb246IEJhc2ljIHh4eHh4eHh4eHh4eHh4eHgKPgo+ICAgICAg ICB0aGUtdXBkYXRlZC10ZXh0Cj4KPgo+IChUaGlzIHJhcmVseSBoYXBwZW5zIGluIHByYWN0aWNl IHdpdGggQmFzaWMgYXV0aCwgYmVjYXVzZSBicm93c2VycyB0ZW5kCj4gdG8ga2VlcCB5b3UgbG9n Z2VkIGluIGZvciBob3dldmVyIGxvbmcgdGhleSBydW4sIHVubGVzcyBoYXZpbmcKPiBleHBsaWNp dGx5IHRvbGQgbm90IHRvLCBidXQgbGV0J3MgYXNzdW1lIHRoZSBjcmVkZW50aWFscyB5b3VyIGJy b3dzZXIKPiBoYXMgYXJlIG5vIGxvbmdlciB2YWxpZCBmb3IgcmVxdWVzdCAoMSkuKQoKVGhlIGZv cm0gbWlnaHQganVzdCBoYXZlIG5vdCByZXF1aXJlZCBhdXRoZW50aWNhdGlvbiA7LSkKCj4gICBC LiBJZiB0aGUgd2Vic2l0ZSB1c2VzIGEgZm9ybQo+Cj4gICAgICAoMSkgQy0+UzoKPiAgICAgICAg UE9TVCBodHRwOi8vZXhhbXBsZS5vcmcvbXlwYWdlIEhUVFAvMS4xCj4KPiAgICAgICAgdGhlLXVw ZGF0ZWQtdGV4dAo+Cj4gICAgICAoMikgUy0+QzoKPiAgICAgICAgSFRUUC8xLjEgMjAwCj4KPiAg ICAgICAgPHRpdGxlPlVuYXV0aG9yaXplZDwvdGl0bGU+Cj4gICAgICAgIDxmb3JtPi4uLjwvZm9y bT4KCkhlcmUsIGluY2x1ZGUgYWxsIHRoZSBkYXRhIHN1Ym1pdHRlZCBpbiAoMSkgd2l0aGluIGhp ZGRlbiBmaWVsZHMuCihhbmQgcmVwbGFjZSB0aGUgMjAwIHdpdGggYSA0MDEgd2l0aCB0aGUgY29v a2llIGF1dGggc2NoZW1lIDspICkKCj4gICAgICAoMykgQy0+UzoKPiAgICAgICAgUE9TVCAvbG9n aW4KPgo+ICAgICAgICB1c2VybmFtZT0uLi4mcGFzc3dvcmQ9Li4uCj4KPiAgICAgICg0KSBTLT5D Ogo+ICAgICAgICBIVFRQLzEuMSAyMDAKPgo+ICAgICAgICA8dGl0bGU+V2VsY29tZSwgZGVhciB4 eHh4eC48L3RpdGxlPgoKVGhlIHNlcnZlciB3b3VsZCB0aGVuIHZhbGlkYXRlIGNyZWRlbnRpYWxz ICphbmQqIGRvIHdoYXQgeW91Cm9yaWdpbmFsbHkgcmVxdWVzdGVkIGluICgxKS4KCkltYWdpbmUg dGhlcmUgYXJlIHVzZXJuYW1lL3Bhc3N3b3JkIGZpZWxkcyBpbiBhbGwgZm9ybXMgYW5kIHRoYXQg eW91CmRvbid0IG5lZWQgdG8gZmlsbCB0aGVtIHVudGlsIHlvdXIgc2Vzc2lvbiBoYXMgZXhwaXJl ZCAoaW4gd2hpY2ggY2FzZSwKeW91J3JlIHByZXNlbnRlZCBhIDQwMSB3aXRoIHRoZSB2ZXJ5IHNh bWUgKHByZWZpbGxlZCkgZm9ybSBleGNlcHQKdGhvc2UgZmllbGRzIGFyZSBub3cgcmVxdWlyZWQg dG8gYmUgZmlsbGVkKS4gVGhhdCB3b3VsZCBiYXNpY2FsbHkgd29yawp0aGUgc2FtZS4KCkFsdGVy bmF0aXZlbHksIHRoZSBzZXJ2ZXIgY291bGQgY3JlYXRlIGEgdGVtcG9yYXJ5IHJlc291cmNlIGZv ciB5b3VyCnN1Ym1pdHRlZCBkYXRhIChleHBpcmluZyBpbiwgc2F5LCBoYWxmIGFuIGhvdXIpIGFu ZCByZWRpcmVjdCB0byB0aGF0CnJlc291cmNlIGF0IHRoZSBlbmQgZm9yIHlvdSB0byAiY29tbWl0 IHlvdXIgY2hhbmdlcyIuIEl0J3Mgbm90IGxpa2VseQp0byBiZSB3aWRlbHkgaW1wbGVtZW50ZWQg dGhvdWdoLCBhcyBpdCByZXF1aXJlcyBtb3JlIHNlcnZlciByZXNvdXJjZXMKKHdlbGwsIHByb2Jh Ymx5IG5vdCBtdWNoIG1vcmUgdGhhbiB3aGF0J3MgbmVlZGVkIHRvIG1haW50YWluIHVzZXIKc2Vz c2lvbnMgd2l0aCBsb3RzIG9mIGRhdGEsIGFzIGZvciBzaG9wcGluZyBjYXJ0cy4uLikKCj4gVW5m b3J0dW5hdGVseSwgdGhlIGVudGl0eSBvZiB0aGUgZmlyc3QgcmVxdWVzdCB3aWxsIGJlIGxvc3Qs IHVubGVzcwo+IHRoZXJlJ3MgYSBzZXNzaW9uIHRoYXQgaGFzIG1lbW9yaXNlZCBpdCBhbmQgY2Fu IGxldCB0aGUgc2VydmVyIHByb2Nlc3MKPiB0aGUgaW5pdGlhbCByZXF1ZXN0ICh0aGF0IHdvdWxk bid0IGJlIFJFU1RmdWwpLgo+IFRoaXMgcHJvYmxlbSBpcyBsZXNzIG9idmlvdXMgd2l0aCBHRVQg cmVxdWVzdHMsIGJlY2F1c2UgdGhlIGZvcm0KPiByZXR1cm5lZCBpbiAoMikgY291bGQgaW5jbHVk ZSBhIHJlZmVyZW5jZSB0byB0aGUgb3JpZ2luYWwgcGFnZSBzbyB0aGF0Cj4gKDMpIGFuZCAoNCkg bG9va3MgbGlrZSB0aGlzOgo+Cj4gICAgICAoMykgQy0+UzoKPiAgICAgICAgUE9TVCAvbG9naW4/ b3JpZ2luPWh0dHA6Ly9leGFtcGxlLm9yZy9teXBhZ2UKPgo+ICAgICAgICB1c2VybmFtZT0uLi4m cGFzc3dvcmQ9Li4uCj4KPiAgICAgICg0KSBTLT5DOgo+ICAgICAgICBIVFRQLzEuMSAzMDIKPiAg ICAgICAgTG9jYXRpb246IGh0dHA6Ly9leGFtcGxlLm9yZy9teXBhZ2UKPgo+ICAgICAgICA8dGl0 bGU+V2VsY29tZSwgZGVhciB4eHh4eC48L3RpdGxlPgo+Cj4gICAgICAoNSkgUy0+QzoKPiAgICAg ICAgR0VUIGh0dHA6Ly9leGFtcGxlLm9yZy9teXBhZ2UKPgo+Cj4gVGhpcyBsYXN0IHN0ZXAgb3Vn aHQgbm90IHRvIGhhcHBlbiBhY2NvcmRpbmcgdG8gUkZDIDI2MTYgKFNlY3Rpb24KPiAxMC4zLjMp IFsxXSwgYnV0IGl0J3MgdGhlIHdheSBGaXJlZm94LCBJRSBhbmQgU2FmYXJpIGRvIGl0LiAoSW4g ZmFjdCwKPiB0aGVzZSBicm93c2VycyBjb3VsZCBlbmQgdXAgZG9pbmcgYSBHRVQgaW4gc3RlcCAo NSkgZXZlbiBpbiByZXF1ZXN0ICgxKQo+IHdhcyBhIFBPU1QuKQoKcy8zMDIvMzAzLyB0byBnZXQg YSBjb25zaXN0ZW50IGJlaGF2aW91ciAoYmV0d2VlbiBpbXBsZW1lbnRhdGlvbnMgYW5kIHNwZWMp Cgo+IFRoZXJlIGlzIGFsc28gYSB3b3JzZSB2YXJpYW50IHRvIHRoaXM6Cj4KPiAgICAgICgxKSBD LT5TOgo+ICAgICAgICBQT1NUIGh0dHA6Ly9leGFtcGxlLm9yZy9teXBhZ2UgSFRUUC8xLjEKPgo+ ICAgICAgICB0aGUtdXBkYXRlZC10ZXh0Cj4KPiAgICAgICgyYSkgUy0+QzoKPiAgICAgICAgSFRU UC8xLjEgMzAyCj4gICAgICAgIExvY2F0aW9uOiAvbG9naW4KPgo+ICAgICAgICA8dGl0bGU+VW5h dXRob3JpemVkPC90aXRsZT4KPiAgICAgICAgPGZvcm0+Li4uPC9mb3JtPgo+Cj4gICAgICAoMmIp IEMtPlM6Cj4gICAgICAgIEdFVCAvbG9naW4gSFRUUC8xLjEKPgo+ICAgICAgKDJjKSBTLT5DOgo+ ICAgICAgICBIVFRQLzEuMSAyMDAKPgo+ICAgICAgICA8dGl0bGU+UGxlYXNlIGlkZW50aWZ5IHlv dXJzZWxmIG9yIHJlZ2lzdGVyLjwvdGl0bGU+Cj4gICAgICAgIDxmb3JtPi4uLjwvZm9ybT4KPgo+ Cj4gKFRoZSBhY3R1YWwgd2lraSBJIGhhdmUgaW4gbWluZCBoYXMgaW4gZmFjdCBhIG11Y2ggbG9u Z2VyIHNldCBvZgo+IGludGVyYWN0aW9ucyBmb3Igd2hhdCdzIHVsdGltYXRlbHkgYSBjb29raWUt YmFzZWQgYXV0aGVudGljYXRpb24sIGFzCj4gaXQncyBwcm90ZWN0ZWQgdXNpbmcgU2hpYmJvbGV0 aC4gSSd2ZSBkZXNjcmliZWQgdGhlIGludGVyYWN0aW9uIGluIFsyXSwKPiBpbiB0aGUgU2hpYmJv bGV0aCBzZWN0aW9uIHRvd2FyZHMgdGhlIGVuZC4uLiBTb3JyeSwgbm8gbG9jYWwgYW5jaG9ycy4p CgpIYXZlIGEgbG9vayBhdCB0aGUgM3JkIGV4YW1wbGUgKHlldCB0byBiZSB3cml0dGVuLCBidXQg YnJpZWZseQpkZXNjcmliZWQpIG9mIGh0dHAtY29va2llLWF1dGgtMDAuClNoaWJib2xldGggaXMg dmVyeSBzaW1pbGFyIHRvIEpBLVNJRyBDQVMgKENBUyBkb2VzIG5vdCBuZWVkIHRoZSBmb3JtCmF1 dG8tc3VibWl0IGJlY2F1c2UgaXQgdXNlcyBhICJ0aWNrZXQiIGluIHRoZSBVUkwgYW5kIHRoZW4K c2VydmVyLXRvLXNlcnZlciBjb21tdW5pY2F0aW9uIHRvIHZhbGlkYXRlIGl0KQoKPiBGb3IgdGhp cyByZWFzb24sIEkgaG9wZSB0aGF0LCBvbmUgZGF5LCBpdCB3b3VsZCBiZSBwb3NzaWJsZSBmb3Ig YnJvd3NlcnMKPiB0byBiZSBhd2FyZSB0aGF0IGF1dGhlbnRpY2F0aW9uIGZvcm1zIHNob3VsZCBi ZSB0cmVhdGVkIG9ydGhvZ29uYWxseSwKPiBsaWtlIG90aGVyIFdXVy1BdXRoZW50aWNhdGUgbWVj aGFuaXNtcywgd2hlcmUgc3VjY2Vzc2Z1bCBhdXRoZW50aWNhdGlvbgo+IHdvdWxkIG1ha2UgdGhl IHVzZXItYWdlbnQgY29udGludWUgd2l0aCB0aGUgb3JpZ2luYWwgaW50ZW5kZWQgcmVxdWVzdC4K ClRoYXQgd291bGQgYmUgaWRlYWwgYnV0IGlzIG5vdCBpbi1zY29wZSBmb3IgaHR0cC1jb29raWUt YXV0aCAoYXQgbGVhc3QKZm9yICJ2ZXJzaW9uIDEiKS4KCj4gV2hldGhlciB0aGlzIGlzIGRvbmUg dmlhIGEgc2VwYXJhdGUgcG9wLXVwLCBzb21lIEFKQVggb3Igc29tZXRoaW5nIGVsc2UKPiAocGVy aGFwcyBpbiB0aGUgc2FtZSB3aW5kb3cgYnV0IGNvbWluZyBiYWNrIHRvIHRoZSBtYWluIGFjdGlv biB1cG9uCj4gc3VjY2Vzcykgd291bGQgYmUgYSBjaG9pY2Ugb2YgaW1wbGVtZW50YXRpb24uCgou Li4gYW5kIGNvdWxkIGFscmVhZHkgYmUgZG9uZSB0b2RheSBieSBhcHBsaWNhdGlvbnMuCgo+IElu IGZhY3QsIEknZCBzYXkgSSdkIGJhcmVseSBzZWUgdGhlIHBvaW50IG9mIGEgV1dXLUF1dGhlbnRp Y2F0ZSBDb29raWUKPiBzY2hlbWUgaWYgaXQgZG9lc24ndCBhaW0gdG8gbWFrZSB0aGUgYXV0aGVu dGljYXRpb24gcHJvcGVybHkgb3J0aG9nb25hbAoKQ29tbXVuaWNhdGluZyB0aGUgZmFjdCB0aGF0 IHRoZSB1c2VyIGlzbid0IGF1dGhlbnRpY2F0ZWQgaXMgZG9uZSB3aXRoYQo0MDEgaW4gSFRUUC4g QSA0MDEgcmVxdWlyZXMgYSBXV1ctQXV0aGVudGljYXRlIGhlYWRlci4gVGhlIENvb2tpZQpzY2hl bWUgYWxsb3dzIGZvciBmaWxsaW5nIHRoZSBXV1ctQXV0aGVudGljYXRlIGZpZWxkIHZhbHVlLgpI b3cgbWFueSBoYXZlIHJ1biBpbnRvIGlzc3VlcyB3aXRoIHRoZWlyIHdlYi1zZXJ2aWNlcyBiZWNh dXNlIHRoZXkKd2VyZSBwcm90ZWN0ZWQgYnkgZm9ybS1iYXNlZCBhdXRoPyBUaGUgQ29va2llIHNj aGVtZSwgYnkgYWxsb3dpbmcgYQpwcm9wZXIgNDAxIHJlc3BvbnNlLCBlbmFibGVzIG5vbi1icm93 c2VyIFVBIHRvIGRpc2NvdmVyIHRoZXkncmUKdW5hdXRob3JpemVkLCB3aXRob3V0IGhhdmluZyBl cnJvcnMgZHVlIHRvIHJlY2VpdmluZyB0aGUgbG9naW4gZm9ybQppbnN0ZWFkIG9mIHRoZSBkYXRh IHRoZXkgdGhvdWdodCB0aGV5IHJlY2VpdmVkIChiZWNhdXNlIG9mIGEgc3VjY2VzcwpzdGF0dXMp LgoKVGhlcmUgd291bGQgYmUgdGhlIGFsdGVybmF0aXZlIG9mIG5vdCByZXR1cm5pbmcgYSBXV1ct QXV0aGVudGljYXRlIGF0CmFsbCAod2l0aCBhY3R1YWxseSBldmVuIGJldHRlciBVQSAiY29tcGF0 aWJpbGl0eSI6IE9wZXJhIGFuZCBDaHJvbWUKd29yayBPSyBhbmQgZGlyZWN0bHkgZGlzcGxheSB0 aGUgcmVzcG9uc2UgYm9keSwgc2VlIGJlbG93IGFib3V0CnVhLWNvbXBhdCk7IHRoYXQncyB3aGF0 IEFsZnJlc2NvIFNVUkYgdXNlcyBieSBkZWZhdWx0IGZvciBpdHMKImVuZHBvaW50cyIgKGNhbGxl ZCB1c2luZyBBSkFYIGluIHRoZWlyIEFsZnJlc2NvIFNoYXJlIGFwcGxpY2F0aW9uKSwKdGhleSBy ZW1vdmUgYW55IFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyIHNvIHRoYXQgdGhlIGphdmFzY3JpcHQg Y29kZQpjYW4gaGFuZGxlIHRoZSA0MDEgd2l0aG91dCB0aGUgYnJvd3NlciBwb3BwaW5nIGEgZGlh bG9nIG9mIHNvbWUgc29ydC4KQnV0IGJlc2lkZXMgYmVpbmcgImJldHRlciBzdXBwb3J0ZWQiLCBJ IHRoaW5rIHVzaW5nIGEgc3BlY2lmaWMgc2NoZW1lCihDb29raWUpIGlzIGJldHRlciAoYW5kIGRv ZXMgbm90IHZpb2xhdGUgSFRUUCwgdGhvdWdoIEhUVFBiaXMgY291bGQKZXZlbnR1YWxseSBhbGxv dyB0aGlzKS4KCj4+PiBJIHRoaW5rIHRoaXMgSW50ZXJuZXQgRHJhZnQgcHJlc2VudHMgYSBzYXRp c2ZhY3Rvcnkgc29sdXRpb24gZm9yIGRlYWxpbmcKPj4+IGJvdGggd2l0aCBjdXJyZW50IGNvb2tp ZSBtZWNoYW5pc21zICh0byBiZWNvbWUgbGVnYWN5KSBhbmQgd2l0aCBhIG5ldwo+Pj4gbWVjaGFu aXNtIGluIGxpbmUgd2l0aCBSRkMgMjYxNy4KPj4+IEhvd2V2ZXIsIGlmIHRoaXMgbmV3IG1lY2hh bmlzbSB3YXMgdG8gYmUgaW1wbGVtZW50ZWQgYW5kIGFjdHVhbGx5Cj4+PiBzdXBwb3J0ZWQgYnkg YnJvd3NlcnMgaW4gdGhlIGZ1dHVyZSwgSSB0aGluayBtb3ZpbmcgYXdheSBmcm9tIHVzaW5nCj4+ PiBjb29raWVzIGFzIGF1dGhlbnRpY2F0aW9uIHRva2VucyBzaG91bGQgYmUgcGFydCBvZiB0aGUg cGxhbi4KPj4KPj4gTm90aGluZyBwcmVjbHVkZXMgYWRkaW5nIGl0IGxhdGVyLiBJJ2QgcmF0aGVy IGhhdmUgc29tZXRoaW5nIHRoYXQganVzdAo+PiBkb2VzIHdoYXQgaXQncyBiZWVuIG1hZGUgZm9y IChjb21tdW5pY2F0ZSB1bmF1dGhvcml6ZWQgYWNjZXNzIHRocm91Z2gKPj4gYSA0MDEgc3RhdHVz IHJhdGhlciB0aGFuIDIwMCBvciAzeHgpIHNvb25lciwgdGhhbiBzb21ldGhpbmcgdGhhdCBkb2Vz Cj4+IGV2ZW4gbW9yZSwgbGF0ZXIuCj4KPiBUcnVlLCBidXQgSSB0aGluayB0aGlzIGlzIG1haW5s eSBhIHF1ZXN0aW9uIG9mIGFjdHVhbCBhZG9wdGlvbiBvZiB0aGlzCj4gSS1ELCBhbmQgd2hpY2gg b25lIHdpbGwgYnJlYWsgbGVzcyB0aGUgY3VycmVudCBiZWhhdmlvdXIuCgpJZiBubyBhcHBsaWNh dGlvbi9zaXRlIHNlbmRzIGEgIjQwMSArIFdXVy1BdXRoZW50aWNhdGU6IENvb2tpZSIsIG5vIFVB CndpbGwgc3VwcG9ydCBpdC4gQW5kIGFwcGxpY2F0aW9ucy9zaXRlcyB3b24ndCB1c2UgaXQgaWYg aXQgcmVxdWlyZXMKdG9vIG11Y2ggd29yay4KSSdtIG5vdCByZWFsbHkgZXhwZWN0aW5nIGJyb3dz ZXJzIHRvIGFjdHVhbGx5IHN1cHBvcnQgaXQsIGJ1dCBpbiB0aGUKZXZlbnQgdGhleSB3b3VsZCwg dGhlbiBjb29raWUtbmFtZS9zZWN1cmUtY29va2llLW5hbWUgd2lsbCBoZWxwIHRoZW0Kc2VjdXJl IHRoZWlyIGltcGxlbWVudGF0aW9uIChJIGd1ZXNzLCBJJ20gZmFyIGZyb20gYmVpbmcgYSBzZWN1 cml0eQpleHBlcnQpLgpCdXQgaWYgQXV0aG9yaXphdGlvbiB3b3VsZCB3b3JrIGV4YWN0bHkgdGhl IHNhbWUgYXMgQ29va2llIChhbmQKYXBwbGljYXRpb25zIHdvdWxkIGNvbnRpbnVlIHRvIHVzZSBT ZXQtQ29va2llIGZvciBhdCBsZWFzdCAxNSB5ZWFycwpmcm9tIG5vdyksIHRoZW4gaXQgd291bGQg aGF2ZSBubyBhZGRlZC12YWx1ZSBzZWN1cml0eS13aXNlLCB3aGlsZQphZGRpbmcgYnVyZGVuIHRv IGltcGxlbWVudG9ycy4KCj4gSW4gcGFydGljdWxhciwgd2lsbCBhICI0MDEgKyBXV1ctQXV0aGVu dGljYXRlOiBDb29raWUiIGNvbmZ1c2UgYW5kIGJyZWFrCj4gYnJvd3NlcnM/IFdvdWxkIHRoZSBh ZGRpdGlvbiBvZiBBdXRoZW50aWNhdGlvbi1JbmZvIGNvbmZ1c2UgdGhlbSBldmVuCj4gbW9yZT8g SSdtIG5vdCBzdXJlLCBJIGhhdmVuJ3QgdHJpZWQuCgpJJ3ZlIGp1c3QgYWRkZWQgYW4gdWEtY29t cGF0Lmh0bWwgcGFnZSB0byBteSBtZXJjdXJpYWwgcmVwbzoKaHR0cDovL2hnLmx0Z3QubmV0L2h0 dHAtY29va2llLWF1dGgvcmF3LWZpbGUvdGlwL3VhLWNvbXBhdC5odG1sClN1bW1hcnk6IE9wZXJh IHNob3dzIGFuIGVycm9yIHBhZ2UsIENocm9tZSdzIGN1cnJlbnQgU3RhYmxlL0JldGEKdmVyc2lv biBwb3BzIHVwIGFuIGF1dGhlbnRpY2F0aW9uIGRpYWxvZywgYnV0IENocm9tZSdzIERldiB2ZXJz aW9uCndvcmtzIE9LOyBqdXN0IGFzIElFIChhbGwgdmVyc2lvbnMpIGFuZCBGaXJlZm94IChhbGwg dmVyc2lvbnMpLgpJJ3ZlIGZpbGVkIGEgYnVnIGF0IE9wZXJhIChhcyBIVE1MNSBub3cgc2F5cyBi cm93c2VycyBzaG91bGQgc2hvdyB0aGUKcmV0dXJuZWQgZW50aXR5IGluIGNhc2UgaXQgZG9lc24n dCB1bmRlcnN0YW5kIHRoZSBhdXRoZW50aWNhdGlvbgpzY2hlbWUpLgoKSSBoYXZlbid0IHRlc3Rl ZCB1c2luZyBhbiBBdXRoZW50aWNhdGlvbi1JbmZvIHRob3VnaC4KCkFzIG5vdGVkIGFib3ZlLCBu b3Qgc2VuZGluZyBhIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyIGF0IGFsbCB3b3JrcyBPSwppbiBh bGwgYnJvd3NlcnMgSSd2ZSB0ZXN0ZWQgKGFsbCBvbiBXaW5kb3dzKS4gSXQgbWlnaHQgYmUgdXNl ZCBhcyBhCndvcmthcm91bmQgZm9yIENocm9tZSBhbmQgT3BlcmEgKGJhc2VkIG9uIHRoZWlyIFVB IHN0cmluZzsgeWVzLCBJIGtub3cKdGhpcyBpcyBCYWTihKIsIGp1c3QgYXMgYmFkIGFzIGFueSB3 b3JrYXJvdW5kKQoKCi0tIApUaG9tYXMgQnJveWVyCg== Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id BEE553E044C for ; Fri, 9 Jan 2009 11:33:59 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gP91Hb+3U3FD for ; Fri, 9 Jan 2009 11:33:47 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 4ADA23E0411 for ; Fri, 9 Jan 2009 11:33:47 -0800 (PST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LLN72-0006Uk-P8 for ietf-http-auth@osafoundation.org; Fri, 09 Jan 2009 19:33:44 +0000 Received: from rain.gmane.org ([80.91.229.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Jan 2009 19:33:43 +0000 Received: from Bruno.Harbulot by rain.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Jan 2009 19:33:43 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-http-auth@osafoundation.org From: Bruno Harbulot Date: Fri, 09 Jan 2009 19:32:18 +0000 Lines: 324 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: rain.gmane.org User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) In-Reply-To: Sender: news Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 19:33:59 -0000 Hello, Thomas Broyer wrote: >> >> A. Form identification. >> >> I think it would be useful to identify which of the forms is to be used >> for authorisation. [...] > > Why not... that was suggested on the WHAT WG too; and you're right > that form-action was part of the answer. > As you said, "it wouldn't necessarily be a good design", so let's not > encourage it (just do not include the form-action attribute –and do > not benefit from automatically submitted form– or live with the > ambiguity; it would still be better than the current practice of > redirecting to the login page or sending the login page with a 200 > status and no-cache controls). > The use-case for form-action was identifying the form in the response > body for automatic population and submition, in case credentials have > been passed up-front (as is the case, for example, with httplib2 > ). Initially, I was only thinking > about use-cases where the cookie is set by the server with a > Set-Cookie2 header (actually in practice, a non-RFC2109-compliant > Set-Cookie) in response to a POST request. > During edition of the draft before -00, I loosened the requirements > (how about a cookie set by a javascript? what about non-HTML > entities?), but left the form-action unchanged. > So yes, maybe a form-id would be better? Yes, I'd be in favour of a form-id. I was thinking of a non-browser user-agent, which is probably the same as what you mean by the case where the credentials have been passed up-front. "form-id" seems clearer as a concept, to identify the form, and it might also be easier to program (for example, using DOM's getElementById). >> In addition, this might be used for pointing to a form on a different page: >> >> 1. User Agent -> Server >> >> GET https://www.example.com/acme/ HTTP/1.1 >> >> 2. Server -> User Agent >> >> HTTP/1.1 401 Unauthorized >> WWW-Authenticate: Cookie realm="Acme" >> form-uri="https://www.example.com/acme/login#loginform" >> form-action="/acme/login" >> cookie-name=ACME_TICKET >> Content-Type: text/html >> >> Unauthorized > > It would be totally non-backwards-compatible (with current UAs, with > mostly browsers in mind); or the form would have to be pulled in from > the returned entity (e.g. an AJAX request to get the form, instead of > including it directly within the response body; or a frame eventually, > but I don't see the point: the UA have to process the returned entity > to be able to proceed with signing in, so what would it add to > form-action?). > There almost no reason not to allow it (developers just won't use it > most of the time), but what should an UA do with this? present the > Unauthorized or redirect to the form-uri? (should it be > an HTTP URI? should it be accessed with a simple HTTP GET? if so, why > couldn't it be included as part of the returned entity, or the > returned entity issue the redirection? –see the notes about the > upcoming 3rd example) Yes, indeed, having a full URI wouldn't be backward compatible. I'm only trying to leave the door open just in case one day browsers implement this spec and if it can evolve into another spec. It seems easier to have form-id="#loginform" and then allow form-id="http://example.org/login#loginform" in the not-so-near future; at least it doesn't do any harm. If it was just form-id="loginform", it would be harder to allow for general URIs later. What I'd like to see in user-agents supporting this type of authentication, is the awareness that a potential redirection to a form is just for authentication and that it should go back to the initial request upon successful authentication. It doesn't matter than much for GET requests, but it's more important for a POST request. An example of this problem is something that happens on a wiki that I use, where the session cookie expires after a rather short period of time. Suppose you're editing a page in your browser, that you're about to POST the modification, but that your credentials have expired. A. If the website uses HTTP Basic (or other WWW-Authenticate header auth.), the interaction will be like this: (1) C->S: POST http://example.org/mypage HTTP/1.1 the-updated-text (2) S->C: HTTP/1.1 401 WWW-Authenticate: Basic xxxxxxxxxx Unauthorized (The browser asks the user for the password.) (3) C->S: POST http://example.org/mypage HTTP/1.1 Authorization: Basic xxxxxxxxxxxxxxxx the-updated-text (This rarely happens in practice with Basic auth, because browsers tend to keep you logged in for however long they run, unless having explicitly told not to, but let's assume the credentials your browser has are no longer valid for request (1).) B. If the website uses a form (1) C->S: POST http://example.org/mypage HTTP/1.1 the-updated-text (2) S->C: HTTP/1.1 200 Unauthorized
...
(3) C->S: POST /login username=...&password=... (4) S->C: HTTP/1.1 200 Welcome, dear xxxxx. Unfortunately, the entity of the first request will be lost, unless there's a session that has memorised it and can let the server process the initial request (that wouldn't be RESTful). This problem is less obvious with GET requests, because the form returned in (2) could include a reference to the original page so that (3) and (4) looks like this: (3) C->S: POST /login?origin=http://example.org/mypage username=...&password=... (4) S->C: HTTP/1.1 302 Location: http://example.org/mypage Welcome, dear xxxxx. (5) S->C: GET http://example.org/mypage This last step ought not to happen according to RFC 2616 (Section 10.3.3) [1], but it's the way Firefox, IE and Safari do it. (In fact, these browsers could end up doing a GET in step (5) even in request (1) was a POST.) There is also a worse variant to this: (1) C->S: POST http://example.org/mypage HTTP/1.1 the-updated-text (2a) S->C: HTTP/1.1 302 Location: /login Unauthorized
...
(2b) C->S: GET /login HTTP/1.1 (2c) S->C: HTTP/1.1 200 Please identify yourself or register.
...
(The actual wiki I have in mind has in fact a much longer set of interactions for what's ultimately a cookie-based authentication, as it's protected using Shibboleth. I've described the interaction in [2], in the Shibboleth section towards the end... Sorry, no local anchors.) For this reason, I hope that, one day, it would be possible for browsers to be aware that authentication forms should be treated orthogonally, like other WWW-Authenticate mechanisms, where successful authentication would make the user-agent continue with the original intended request. Whether this is done via a separate pop-up, some AJAX or something else (perhaps in the same window but coming back to the main action upon success) would be a choice of implementation. I think this specification should aim to provide support for this, even though we can't expect current implementations to understand this. I don't think this would lead to something non-backward-compatible, it would just mean that implementations that are broken in the way they currently are and that wouldn't support this would still be broken in the same way. In fact, I'd say I'd barely see the point of a WWW-Authenticate Cookie scheme if it doesn't aim to make the authentication properly orthogonal (which indeed might not be understood by current user-agents --they'd behave like they do now-- but could be by the newer ones, progressively). >> B. Use of Authorization/AuthenticationInfo. >> >> To quote Roy Fielding on Cookie-based authentication: "Cookie >> authentication is not allowed in REST because it lacks visibility, which >> causes security problems because the other components don't know it is >> sensitive information." >> (http://tech.groups.yahoo.com/group/rest-discuss/message/3729) >> >> I think this document is a step forward to address this problem (in >> particular via "cookie-name" and "secure-cookie-name"), in a way that is >> compatible with the current browser behaviour. > > Note that it doesn't solve the case where the user signs in from a > public page, and thus never ever sees a 401 and the cookie-name and > secure-cookie-name (hence Julian's question in early december about > including the WWW-Authenticate header within a success response –2xx > or eventually 3xx–; that should IMO be added to httpbis or defined in > a distinct I-D) I guess you're referring to this thread [3]. Yes, that's a problem for mixed authenticated and non-authenticated access. I guess WWW-Authenticate could be present in successful responses indeed, as it's already the case for SPNEGO (someone has already mentioned it on that thread). >> However, perhaps this could be viewed in a broader context. >> >> In my opinion, form-based authentication differs from the authentication >> mechanisms that use WWW-Authenticate mainly because the authentication >> function is performed as part of the application (in the REST >> "Hypermedia As The Engine Of State" sense), unlike the other schemes, >> which use a mechanism orthogonal to it (such as a dialog box in the >> browser for Basic auth). Authentication cookies are then merely an >> artefact of the intersection between the main application and the >> authentication concern, where the cookie is a vehicle for the >> authentication token. >> I think it would be worth trying to go a step further and aiming at >> decoupling this authentication token from the concept of cookies (which >> are also widely used for maintaining sessions). >> >> I think this Internet Draft presents a satisfactory solution for dealing >> both with current cookie mechanisms (to become legacy) and with a new >> mechanism in line with RFC 2617. >> However, if this new mechanism was to be implemented and actually >> supported by browsers in the future, I think moving away from using >> cookies as authentication tokens should be part of the plan. > > Nothing precludes adding it later. I'd rather have something that just > does what it's been made for (communicate unauthorized access through > a 401 status rather than 200 or 3xx) sooner, than something that does > even more, later. True, but I think this is mainly a question of actual adoption of this I-D, and which one will break less the current behaviour. In particular, will a "401 + WWW-Authenticate: Cookie" confuse and break browsers? Would the addition of Authentication-Info confuse them even more? I'm not sure, I haven't tried. >> Thus, I'd suggest adding support for Authorization/AuthenticationInfo as >> well (and perhaps making them mandatory for implementations to qualify >> as compliant with this specification), with headers looking like this: >> >> S->UA: >> AuthenticationInfo: Cookie xxxxxxxxxxxx >> (optionally in conjunction with a Set-Cookie2 header containing the >> same information, for legacy user-agents) >> >> UA->S: >> Authorization: Cookie xxxxxxxxxxxx >> (optionally in conjunction with a Cookie header containing the same >> information, for legacy user-agents) > > How do you communicate the "protected space"? duplicating RFC2965 at > the Authentication-Info level with Domain, Path, Secure, etc. > attributes? (that wouldn't work because no-one is actually > implementing either RFC2109 or RFC2965, because "the Web" uses > something looking more like Netscape's cookies) Yes, that would be something along those lines. I'm just suggesting there should be an Authentication-Info header similar to what sets the cookie for future user-agents, those embracing this I-D. Set-Cookie2 (or whatever else is currently used) should be present as well for the existing implementations. Implementations supporting this I-D would then be allowed (and perhaps encouraged) to ignore the corresponding session-cookie if they understand the Authentication-Info. Separating them is just for clarity of the purpose of the header. Best wishes, Bruno. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3 [2] http://blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechanisms-and-how-they-could-work-in-Restlet [3] http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/0245.html Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 473FD3E0266 for ; Thu, 8 Jan 2009 14:20:15 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqivai-V4d5Q for ; Thu, 8 Jan 2009 14:20:03 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by leka.osafoundation.org (Postfix) with ESMTP id 7B2873E0410 for ; Thu, 8 Jan 2009 14:20:02 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so3332976fgg.17 for ; Thu, 08 Jan 2009 14:20:01 -0800 (PST) Received: by 10.86.60.14 with SMTP id i14mr14484410fga.70.1231453201270; Thu, 08 Jan 2009 14:20:01 -0800 (PST) Received: by 10.86.30.11 with HTTP; Thu, 8 Jan 2009 14:20:01 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2009 23:20:01 +0100 From: "Thomas Broyer" To: ietf-http-auth@osafoundation.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 22:20:15 -0000 T24gVGh1LCBKYW4gOCwgMjAwOSBhdCA0OjQ5IFBNLCBCcnVubyBIYXJidWxvdCB3cm90ZToKPgo+ IChIYXBweSBiaXJ0aGRheS4pCgoodGhhbmtzOyBmdW5uaWx5LCBKYW51YXJ5IDh0aCBpcyBteSBt b3RoZXIncyBiaXJ0aGRheSEgYW5kIGlmIHNvbWVvbmUKd2FudHMgdG8gZm9sbG93IHRoZSBtZW1l LCAyMHRoIGlzIHRoZSBiaXJ0aGRheSBvZiBteSBkYXVnaHRlciBhbmQKRmVicnVhcnkgMXN0IGlz IHRoZSBvbiBvZiBteSBmYXRoZXIgaW4gbGF3KQoKPiBUaGlzIGxvb2tzIGdvb2QuIFRoZXJlIGFy ZSBhIGZldyBwb2ludHMgSSdkIHN1Z2dlc3QgdG8gZG8gYSBiaXQKPiBkaWZmZXJlbnRseSBwZXJo YXBzLgo+Cj4KPiBBLiBGb3JtIGlkZW50aWZpY2F0aW9uLgo+Cj4gSSB0aGluayBpdCB3b3VsZCBi ZSB1c2VmdWwgdG8gaWRlbnRpZnkgd2hpY2ggb2YgdGhlIGZvcm1zIGlzIHRvIGJlIHVzZWQKPiBm b3IgYXV0aG9yaXNhdGlvbi4gSSBjYW4gaW1hZ2luZSB0aGUgY2FzZSB3aGVyZSB0aGVyZSB3b3Vs ZCBiZSBzZXZlcmFsCj4gZm9ybXMgb24gdGhlIHNhbWUgcGFnZS4gRm9yIGV4YW1wbGUsIGEgcGFn ZSB3aXRoIGEgdGVtcGxhdGUgY291bGQgaGF2ZSBhCj4gZGVmYXVsdCBzZWFyY2ggZm9ybSBhcyBw YXJ0IG9mIHRoZSBnZW5lcmFsIGxheW91dCBvZiB0aGUgcGFnZSAocXVpdGUKPiBjb21tb24gZm9y IGEgd2lraSBmb3IgZXhhbXBsZSksIGFzIHdlbGwgYXMgdGhlIGxvZ2luIGZvcm07IGJvdGggY291 bGQgYmUKPiBkaXNwbGF5ZWQgb24gdGhlIHBhZ2UgcmV0dXJuZWQgd2l0aCAiNDAxIFVuYXV0aG9y aXplZCIuIEFsdGhvdWdoIGl0J3MKPiBvZnRlbiBlYXN5IGZvciBhIGh1bWFuIHRvIHBpY2sgdGhl IHJpZ2h0IGZvcm0sIGl0IHdvdWxkIG5vdCBiZSBzbwo+IG9idmlvdXMgZm9yIGEgbm9uLWJyb3dz ZXIgdXNlci1hZ2VudC4KPiAiZm9ybS1hY3Rpb24iIHBhcnRseSBhZGRyZXNzZXMgdGhpcyBwcm9i bGVtLCBidXQgdGhlcmUncyBpbiBwcmluY2lwbGUKPiBub3RoaW5nIHRvIHByZXZlbnQgdHdvIGZv cm1zIG9uIHRoZSBzYW1lIHBhZ2UgdG8gdXNlIHRoZSBzYW1lIGFjdGlvbiAoaXQKPiB3b3VsZG4n dCBuZWNlc3NhcmlseSBiZSBhIGdvb2QgZGVzaWduLCBidXQgdGhhdCdzIHBvc3NpYmxlKS4KPiBJ IHdvdWxkICBzdWdnZXN0IHVzaW5nIGFub3RoZXIgZGlyZWN0aXZlLCBwZXJoYXBzIGNhbGxlZCAi Zm9ybS11cmkiLAo+IGNvbWJpbmVkIHdpdGggYW4gImlkIiBhdHRyaWJ1dGUgaW4gdGhlIGZvcm0u CgpXaHkgbm90Li4uIHRoYXQgd2FzIHN1Z2dlc3RlZCBvbiB0aGUgV0hBVCBXRyB0b287IGFuZCB5 b3UncmUgcmlnaHQKdGhhdCBmb3JtLWFjdGlvbiB3YXMgcGFydCBvZiB0aGUgYW5zd2VyLgpBcyB5 b3Ugc2FpZCwgIml0IHdvdWxkbid0IG5lY2Vzc2FyaWx5IGJlIGEgZ29vZCBkZXNpZ24iLCBzbyBs ZXQncyBub3QKZW5jb3VyYWdlIGl0IChqdXN0IGRvIG5vdCBpbmNsdWRlIHRoZSBmb3JtLWFjdGlv biBhdHRyaWJ1dGUg4oCTYW5kIGRvCm5vdCBiZW5lZml0IGZyb20gYXV0b21hdGljYWxseSBzdWJt aXR0ZWQgZm9ybeKAkyBvciBsaXZlIHdpdGggdGhlCmFtYmlndWl0eTsgaXQgd291bGQgc3RpbGwg YmUgYmV0dGVyIHRoYW4gdGhlIGN1cnJlbnQgcHJhY3RpY2Ugb2YKcmVkaXJlY3RpbmcgdG8gdGhl IGxvZ2luIHBhZ2Ugb3Igc2VuZGluZyB0aGUgbG9naW4gcGFnZSB3aXRoIGEgMjAwCnN0YXR1cyBh bmQgbm8tY2FjaGUgY29udHJvbHMpLgpUaGUgdXNlLWNhc2UgZm9yIGZvcm0tYWN0aW9uIHdhcyBp ZGVudGlmeWluZyB0aGUgZm9ybSBpbiB0aGUgcmVzcG9uc2UKYm9keSBmb3IgYXV0b21hdGljIHBv cHVsYXRpb24gYW5kIHN1Ym1pdGlvbiwgaW4gY2FzZSBjcmVkZW50aWFscyBoYXZlCmJlZW4gcGFz c2VkIHVwLWZyb250IChhcyBpcyB0aGUgY2FzZSwgZm9yIGV4YW1wbGUsIHdpdGggaHR0cGxpYjIK PGh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9odHRwbGliMi8+ICkuIEluaXRpYWxseSwgSSB3YXMg b25seSB0aGlua2luZwphYm91dCB1c2UtY2FzZXMgd2hlcmUgdGhlIGNvb2tpZSBpcyBzZXQgYnkg dGhlIHNlcnZlciB3aXRoIGEKU2V0LUNvb2tpZTIgaGVhZGVyIChhY3R1YWxseSBpbiBwcmFjdGlj ZSwgYSBub24tUkZDMjEwOS1jb21wbGlhbnQKU2V0LUNvb2tpZSkgaW4gcmVzcG9uc2UgdG8gYSBQ T1NUIHJlcXVlc3QuCkR1cmluZyBlZGl0aW9uIG9mIHRoZSBkcmFmdCBiZWZvcmUgLTAwLCBJIGxv b3NlbmVkIHRoZSByZXF1aXJlbWVudHMKKGhvdyBhYm91dCBhIGNvb2tpZSBzZXQgYnkgYSBqYXZh c2NyaXB0PyB3aGF0IGFib3V0IG5vbi1IVE1MCmVudGl0aWVzPyksIGJ1dCBsZWZ0IHRoZSBmb3Jt LWFjdGlvbiB1bmNoYW5nZWQuClNvIHllcywgbWF5YmUgYSBmb3JtLWlkIHdvdWxkIGJlIGJldHRl cj8KCj4gSW4gYWRkaXRpb24sIHRoaXMgbWlnaHQgYmUgdXNlZCBmb3IgcG9pbnRpbmcgdG8gYSBm b3JtIG9uIGEgZGlmZmVyZW50IHBhZ2U6Cj4KPiAgICAxLiAgVXNlciBBZ2VudCAtPiBTZXJ2ZXIK Pgo+ICAgIEdFVCBodHRwczovL3d3dy5leGFtcGxlLmNvbS9hY21lLyBIVFRQLzEuMQo+Cj4gICAg Mi4gIFNlcnZlciAtPiBVc2VyIEFnZW50Cj4KPiAgICBIVFRQLzEuMSA0MDEgVW5hdXRob3JpemVk Cj4gICAgV1dXLUF1dGhlbnRpY2F0ZTogQ29va2llIHJlYWxtPSJBY21lIgo+ICAgICAgICAgICAg Zm9ybS11cmk9Imh0dHBzOi8vd3d3LmV4YW1wbGUuY29tL2FjbWUvbG9naW4jbG9naW5mb3JtIgo+ ICAgICAgICAgICAgZm9ybS1hY3Rpb249Ii9hY21lL2xvZ2luIgo+ICAgICAgICAgICAgY29va2ll LW5hbWU9QUNNRV9USUNLRVQKPiAgICBDb250ZW50LVR5cGU6IHRleHQvaHRtbAo+Cj4gICAgPHRp dGxlPlVuYXV0aG9yaXplZDwvdGl0bGU+CgpJdCB3b3VsZCBiZSB0b3RhbGx5IG5vbi1iYWNrd2Fy ZHMtY29tcGF0aWJsZSAod2l0aCBjdXJyZW50IFVBcywgd2l0aAptb3N0bHkgYnJvd3NlcnMgaW4g bWluZCk7IG9yIHRoZSBmb3JtIHdvdWxkIGhhdmUgdG8gYmUgcHVsbGVkIGluIGZyb20KdGhlIHJl dHVybmVkIGVudGl0eSAoZS5nLiBhbiBBSkFYIHJlcXVlc3QgdG8gZ2V0ICB0aGUgZm9ybSwgaW5z dGVhZCBvZgppbmNsdWRpbmcgaXQgZGlyZWN0bHkgd2l0aGluIHRoZSByZXNwb25zZSBib2R5OyBv ciBhIGZyYW1lIGV2ZW50dWFsbHksCmJ1dCBJIGRvbid0IHNlZSB0aGUgcG9pbnQ6IHRoZSBVQSBo YXZlIHRvIHByb2Nlc3MgdGhlIHJldHVybmVkIGVudGl0eQp0byBiZSBhYmxlIHRvIHByb2NlZWQg d2l0aCBzaWduaW5nIGluLCBzbyB3aGF0IHdvdWxkIGl0IGFkZCB0bwpmb3JtLWFjdGlvbj8pLgoK VGhlcmUgYWxtb3N0IG5vIHJlYXNvbiBub3QgdG8gYWxsb3cgaXQgKGRldmVsb3BlcnMganVzdCB3 b24ndCB1c2UgaXQKbW9zdCBvZiB0aGUgdGltZSksIGJ1dCB3aGF0IHNob3VsZCBhbiBVQSBkbyB3 aXRoIHRoaXM/IHByZXNlbnQgdGhlCjx0aXRsZT5VbmF1dGhvcml6ZWQ8L3RpdGxlPiBvciByZWRp cmVjdCB0byB0aGUgZm9ybS11cmk/IChzaG91bGQgaXQgYmUKYW4gSFRUUCBVUkk/IHNob3VsZCBp dCBiZSBhY2Nlc3NlZCB3aXRoIGEgc2ltcGxlIEhUVFAgR0VUPyBpZiBzbywgd2h5CmNvdWxkbid0 IGl0IGJlIGluY2x1ZGVkIGFzIHBhcnQgb2YgdGhlIHJldHVybmVkIGVudGl0eSwgb3IgdGhlCnJl dHVybmVkIGVudGl0eSBpc3N1ZSB0aGUgcmVkaXJlY3Rpb24/IOKAk3NlZSB0aGUgbm90ZXMgYWJv dXQgdGhlCnVwY29taW5nIDNyZCBleGFtcGxlKQoKPiBCLiBVc2Ugb2YgQXV0aG9yaXphdGlvbi9B dXRoZW50aWNhdGlvbkluZm8uCj4KPiBUbyBxdW90ZSBSb3kgRmllbGRpbmcgb24gQ29va2llLWJh c2VkIGF1dGhlbnRpY2F0aW9uOiAiQ29va2llCj4gYXV0aGVudGljYXRpb24gaXMgbm90IGFsbG93 ZWQgaW4gUkVTVCBiZWNhdXNlIGl0IGxhY2tzIHZpc2liaWxpdHksIHdoaWNoCj4gY2F1c2VzIHNl Y3VyaXR5IHByb2JsZW1zIGJlY2F1c2UgdGhlIG90aGVyIGNvbXBvbmVudHMgZG9uJ3Qga25vdyBp dCBpcwo+IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4iCj4gKGh0dHA6Ly90ZWNoLmdyb3Vwcy55YWhv by5jb20vZ3JvdXAvcmVzdC1kaXNjdXNzL21lc3NhZ2UvMzcyOSkKPgo+IEkgdGhpbmsgdGhpcyBk b2N1bWVudCBpcyBhIHN0ZXAgZm9yd2FyZCB0byBhZGRyZXNzIHRoaXMgcHJvYmxlbSAoaW4KPiBw YXJ0aWN1bGFyIHZpYSAiY29va2llLW5hbWUiIGFuZCAic2VjdXJlLWNvb2tpZS1uYW1lIiksIGlu IGEgd2F5IHRoYXQgaXMKPiBjb21wYXRpYmxlIHdpdGggdGhlIGN1cnJlbnQgYnJvd3NlciBiZWhh dmlvdXIuCgpOb3RlIHRoYXQgaXQgZG9lc24ndCBzb2x2ZSB0aGUgY2FzZSB3aGVyZSB0aGUgdXNl ciBzaWducyBpbiBmcm9tIGEKcHVibGljIHBhZ2UsIGFuZCB0aHVzIG5ldmVyIGV2ZXIgc2VlcyBh IDQwMSBhbmQgdGhlIGNvb2tpZS1uYW1lIGFuZApzZWN1cmUtY29va2llLW5hbWUgKGhlbmNlIEp1 bGlhbidzIHF1ZXN0aW9uIGluIGVhcmx5IGRlY2VtYmVyIGFib3V0CmluY2x1ZGluZyB0aGUgV1dX LUF1dGhlbnRpY2F0ZSBoZWFkZXIgd2l0aGluIGEgc3VjY2VzcyByZXNwb25zZSDigJMyeHgKb3Ig ZXZlbnR1YWxseSAzeHjigJM7IHRoYXQgc2hvdWxkIElNTyBiZSBhZGRlZCB0byBodHRwYmlzIG9y IGRlZmluZWQgaW4KYSBkaXN0aW5jdCBJLUQpCgo+IEhvd2V2ZXIsIHBlcmhhcHMgdGhpcyBjb3Vs ZCBiZSB2aWV3ZWQgaW4gYSBicm9hZGVyIGNvbnRleHQuCj4KPiBJbiBteSBvcGluaW9uLCBmb3Jt LWJhc2VkIGF1dGhlbnRpY2F0aW9uIGRpZmZlcnMgZnJvbSB0aGUgYXV0aGVudGljYXRpb24KPiBt ZWNoYW5pc21zIHRoYXQgdXNlIFdXVy1BdXRoZW50aWNhdGUgbWFpbmx5IGJlY2F1c2UgdGhlIGF1 dGhlbnRpY2F0aW9uCj4gZnVuY3Rpb24gaXMgcGVyZm9ybWVkIGFzIHBhcnQgb2YgdGhlIGFwcGxp Y2F0aW9uIChpbiB0aGUgUkVTVAo+ICJIeXBlcm1lZGlhIEFzIFRoZSBFbmdpbmUgT2YgU3RhdGUi IHNlbnNlKSwgdW5saWtlIHRoZSBvdGhlciBzY2hlbWVzLAo+IHdoaWNoIHVzZSBhIG1lY2hhbmlz bSBvcnRob2dvbmFsIHRvIGl0IChzdWNoIGFzIGEgZGlhbG9nIGJveCBpbiB0aGUKPiBicm93c2Vy IGZvciBCYXNpYyBhdXRoKS4gQXV0aGVudGljYXRpb24gY29va2llcyBhcmUgdGhlbiBtZXJlbHkg YW4KPiBhcnRlZmFjdCBvZiB0aGUgaW50ZXJzZWN0aW9uIGJldHdlZW4gdGhlIG1haW4gYXBwbGlj YXRpb24gYW5kIHRoZQo+IGF1dGhlbnRpY2F0aW9uIGNvbmNlcm4sIHdoZXJlIHRoZSBjb29raWUg aXMgYSB2ZWhpY2xlIGZvciB0aGUKPiBhdXRoZW50aWNhdGlvbiB0b2tlbi4KPiBJIHRoaW5rIGl0 IHdvdWxkIGJlIHdvcnRoIHRyeWluZyB0byBnbyBhIHN0ZXAgZnVydGhlciBhbmQgYWltaW5nIGF0 Cj4gZGVjb3VwbGluZyB0aGlzIGF1dGhlbnRpY2F0aW9uIHRva2VuIGZyb20gdGhlIGNvbmNlcHQg b2YgY29va2llcyAod2hpY2gKPiBhcmUgYWxzbyB3aWRlbHkgdXNlZCBmb3IgbWFpbnRhaW5pbmcg c2Vzc2lvbnMpLgo+Cj4gSSB0aGluayB0aGlzIEludGVybmV0IERyYWZ0IHByZXNlbnRzIGEgc2F0 aXNmYWN0b3J5IHNvbHV0aW9uIGZvciBkZWFsaW5nCj4gYm90aCB3aXRoIGN1cnJlbnQgY29va2ll IG1lY2hhbmlzbXMgKHRvIGJlY29tZSBsZWdhY3kpIGFuZCB3aXRoIGEgbmV3Cj4gbWVjaGFuaXNt IGluIGxpbmUgd2l0aCBSRkMgMjYxNy4KPiBIb3dldmVyLCBpZiB0aGlzIG5ldyBtZWNoYW5pc20g d2FzIHRvIGJlIGltcGxlbWVudGVkIGFuZCBhY3R1YWxseQo+IHN1cHBvcnRlZCBieSBicm93c2Vy cyBpbiB0aGUgZnV0dXJlLCBJIHRoaW5rIG1vdmluZyBhd2F5IGZyb20gdXNpbmcKPiBjb29raWVz IGFzIGF1dGhlbnRpY2F0aW9uIHRva2VucyBzaG91bGQgYmUgcGFydCBvZiB0aGUgcGxhbi4KCk5v dGhpbmcgcHJlY2x1ZGVzIGFkZGluZyBpdCBsYXRlci4gSSdkIHJhdGhlciBoYXZlIHNvbWV0aGlu ZyB0aGF0IGp1c3QKZG9lcyB3aGF0IGl0J3MgYmVlbiBtYWRlIGZvciAoY29tbXVuaWNhdGUgdW5h dXRob3JpemVkIGFjY2VzcyB0aHJvdWdoCmEgNDAxIHN0YXR1cyByYXRoZXIgdGhhbiAyMDAgb3Ig M3h4KSBzb29uZXIsIHRoYW4gc29tZXRoaW5nIHRoYXQgZG9lcwpldmVuIG1vcmUsIGxhdGVyLgoK PiBUaHVzLCBJJ2Qgc3VnZ2VzdCBhZGRpbmcgc3VwcG9ydCBmb3IgQXV0aG9yaXphdGlvbi9BdXRo ZW50aWNhdGlvbkluZm8gYXMKPiB3ZWxsIChhbmQgcGVyaGFwcyBtYWtpbmcgdGhlbSBtYW5kYXRv cnkgZm9yIGltcGxlbWVudGF0aW9ucyB0byBxdWFsaWZ5Cj4gYXMgY29tcGxpYW50IHdpdGggdGhp cyBzcGVjaWZpY2F0aW9uKSwgd2l0aCBoZWFkZXJzIGxvb2tpbmcgbGlrZSB0aGlzOgo+Cj4gUy0+ VUE6Cj4gICAgQXV0aGVudGljYXRpb25JbmZvOiBDb29raWUgeHh4eHh4eHh4eHh4Cj4gICAgKG9w dGlvbmFsbHkgaW4gY29uanVuY3Rpb24gd2l0aCBhIFNldC1Db29raWUyIGhlYWRlciBjb250YWlu aW5nIHRoZQo+IHNhbWUgaW5mb3JtYXRpb24sIGZvciBsZWdhY3kgdXNlci1hZ2VudHMpCj4KPiBV QS0+UzoKPiAgICBBdXRob3JpemF0aW9uOiBDb29raWUgeHh4eHh4eHh4eHh4Cj4gICAgKG9wdGlv bmFsbHkgaW4gY29uanVuY3Rpb24gd2l0aCBhIENvb2tpZSBoZWFkZXIgY29udGFpbmluZyB0aGUg c2FtZQo+IGluZm9ybWF0aW9uLCBmb3IgbGVnYWN5IHVzZXItYWdlbnRzKQoKSG93IGRvIHlvdSBj b21tdW5pY2F0ZSB0aGUgInByb3RlY3RlZCBzcGFjZSI/IGR1cGxpY2F0aW5nIFJGQzI5NjUgYXQK dGhlIEF1dGhlbnRpY2F0aW9uLUluZm8gbGV2ZWwgd2l0aCBEb21haW4sIFBhdGgsIFNlY3VyZSwg ZXRjLgphdHRyaWJ1dGVzPyAodGhhdCB3b3VsZG4ndCB3b3JrIGJlY2F1c2Ugbm8tb25lIGlzIGFj dHVhbGx5CmltcGxlbWVudGluZyBlaXRoZXIgUkZDMjEwOSBvciBSRkMyOTY1LCBiZWNhdXNlICJ0 aGUgV2ViIiB1c2VzCnNvbWV0aGluZyBsb29raW5nIG1vcmUgbGlrZSBOZXRzY2FwZSdzIGNvb2tp ZXMpCgo+IEluIGZhY3QsIHBlcmhhcHMgdGhpcyBzY2hlbWUgc2hvdWxkIGJlIGNhbGxlZCBzb21l dGhpbmcgZWxzZSB0aGFuICJDb29raWUiLgoKU3VjaCBhcyAiSW5saW5lIiAodG8gY29udmV5IHRo ZSBmYWN0IHRoYXQgdGhlICJhdXRoZW50aWNhdGlvbgptZWNoYW5pc20iIGlzIHByb3ZpZGVkICJp bmxpbmUiIGluIHRoZSByZXNwb25zZSBib2R5KS4gQnV0IG5vdGhpbmcKcHJlY2x1ZGVzIHVzaW5n IGJvdGggc2NoZW1lcyAoSW5saW5lIGFuZCBDb29raWUpIGF0IHRoZSBzYW1lIHRpbWU7IFVBcwpz dXBwb3J0aW5nIElubGluZSB3b3VsZCBoYXZlIHRvIHByZWZlciBpdCB0byBDb29raWUgdG8gcXVh bGlmeSBhcwpjb21wbGlhbnQuCgpBcyBzdGF0ZWQgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0 aGUgIkNvb2tpZSBBdXRoZW50aWNhdGlvbiBTY2hlbWUiCnNlY3Rpbm8gKHNvb24gdG8gYmUgbW92 ZWQgdG8gdGhlIEludHJvZHVjdGlvbiBhbmQvb3IgQWJzdHJhY3QpOgoKICAgVGhlICJjb29raWUi IGF1dGhlbnRpY2F0aW9uIHNjaGVtZSB0cmllcyB0byByZWNvbmNpbGUgdGhlCiAgIGN1cnJlbnQg cHJhY3RpY2Ugb2YgbWFueSB3ZWIgc2l0ZXMgYW5kIHdlYiBkZXZlbG9wbWVudAogICBmcmFtZXdv cmtzIG9mIHVzaW5nIEhUTUwgZm9ybXMgYW5kIGNvb2tpZXMgdG8gYXV0aGVudGljYXRlCiAgIHVz ZXJzLCBhbmQgdGhlIEFjY2VzcyBBdXRoZW50aWNhdGlvbiBGcmFtZXdvcmsgZGVzY3JpYmVkCiAg IGluIFNlY3Rpb24gMS4yIG9mIFtSRkMyNjE3XS4KCk5vdGhpbmcgbW9yZSwgbm90aGluZyBsZXNz IChhbmQgYSBmdXR1cmUgcmV2aXNpb24gY291bGQgdmVyeSB3ZWxsCmV4dGVuZCBpdCB0byBzdXBw b3J0IEF1dGhvcml6YXRpb24vUHJveHktQXV0aG9yaXphdGlvbiBpbiBhZGRpdGlvbiB0bwpjb29r aWVzOyBvciB0aGlzIGNvdWxkIGJlIGRvbmUgd2l0aCBhIG5ldyAiSW5saW5lIiBzY2hlbWUpCgoK CkFueXdheSwgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLgoKSSdsbCB0cnkgdG8gcHVibGlzaCBh biAtMDEgZHJhZnQgYnkgSmFudWFyeSAyMHRoIDstKQoKLS0gClRob21hcyBCcm95ZXIK Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 684C13E03EA for ; Thu, 8 Jan 2009 09:00:11 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8irtcTMI8MWZ for ; Thu, 8 Jan 2009 09:00:09 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 0350A3E03C4 for ; Thu, 8 Jan 2009 09:00:06 -0800 (PST) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LKyEk-0005l2-NM for ietf-http-auth@osafoundation.org; Thu, 08 Jan 2009 17:00:02 +0000 Received: from rain.gmane.org ([80.91.229.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Jan 2009 17:00:02 +0000 Received: from Bruno.Harbulot by rain.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Jan 2009 17:00:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-http-auth@osafoundation.org From: Bruno Harbulot Date: Thu, 08 Jan 2009 15:49:28 +0000 Lines: 140 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: rain.gmane.org User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) In-Reply-To: Sender: news Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 17:00:11 -0000 Hello, Thomas Broyer wrote: > Hi all, > > As I previously said, I spent some holiday time to put my thoughts > about "RFC2617-compliant cookie-based authentication" into an Internet > Draft. > Today is my birthday (and the last day of my holidays) so I thought I > should do something special. I therefore submitted version 00 of my > work ("release early, release often" they said). (Happy birthday.) This looks good. There are a few points I'd suggest to do a bit differently perhaps. A. Form identification. I think it would be useful to identify which of the forms is to be used for authorisation. I can imagine the case where there would be several forms on the same page. For example, a page with a template could have a default search form as part of the general layout of the page (quite common for a wiki for example), as well as the login form; both could be displayed on the page returned with "401 Unauthorized". Although it's often easy for a human to pick the right form, it would not be so obvious for a non-browser user-agent. "form-action" partly addresses this problem, but there's in principle nothing to prevent two forms on the same page to use the same action (it wouldn't necessarily be a good design, but that's possible). I would suggest using another directive, perhaps called "form-uri", combined with an "id" attribute in the form. 1. User Agent -> Server GET https://www.example.com/acme/ HTTP/1.1 2. Server -> User Agent HTTP/1.1 401 Unauthorized WWW-Authenticate: Cookie realm="Acme" form-uri="#loginform" form-action="/acme/login" cookie-name=ACME_TICKET Content-Type: text/html Unauthorized

Register for an account

In addition, this might be used for pointing to a form on a different page: 1. User Agent -> Server GET https://www.example.com/acme/ HTTP/1.1 2. Server -> User Agent HTTP/1.1 401 Unauthorized WWW-Authenticate: Cookie realm="Acme" form-uri="https://www.example.com/acme/login#loginform" form-action="/acme/login" cookie-name=ACME_TICKET Content-Type: text/html Unauthorized "form-action" might become redundant in this case, or be used as a safe-guard. B. Use of Authorization/AuthenticationInfo. To quote Roy Fielding on Cookie-based authentication: "Cookie authentication is not allowed in REST because it lacks visibility, which causes security problems because the other components don't know it is sensitive information." (http://tech.groups.yahoo.com/group/rest-discuss/message/3729) I think this document is a step forward to address this problem (in particular via "cookie-name" and "secure-cookie-name"), in a way that is compatible with the current browser behaviour. However, perhaps this could be viewed in a broader context. In my opinion, form-based authentication differs from the authentication mechanisms that use WWW-Authenticate mainly because the authentication function is performed as part of the application (in the REST "Hypermedia As The Engine Of State" sense), unlike the other schemes, which use a mechanism orthogonal to it (such as a dialog box in the browser for Basic auth). Authentication cookies are then merely an artefact of the intersection between the main application and the authentication concern, where the cookie is a vehicle for the authentication token. I think it would be worth trying to go a step further and aiming at decoupling this authentication token from the concept of cookies (which are also widely used for maintaining sessions). I think this Internet Draft presents a satisfactory solution for dealing both with current cookie mechanisms (to become legacy) and with a new mechanism in line with RFC 2617. However, if this new mechanism was to be implemented and actually supported by browsers in the future, I think moving away from using cookies as authentication tokens should be part of the plan. Thus, I'd suggest adding support for Authorization/AuthenticationInfo as well (and perhaps making them mandatory for implementations to qualify as compliant with this specification), with headers looking like this: S->UA: AuthenticationInfo: Cookie xxxxxxxxxxxx (optionally in conjunction with a Set-Cookie2 header containing the same information, for legacy user-agents) UA->S: Authorization: Cookie xxxxxxxxxxxx (optionally in conjunction with a Cookie header containing the same information, for legacy user-agents) In fact, perhaps this scheme should be called something else than "Cookie". Best wishes, Bruno. -- http://blog.distributedmatter.net/ Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 174A83E01EA for ; Tue, 6 Jan 2009 15:15:57 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7IZ+seUZisd for ; Tue, 6 Jan 2009 15:15:46 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by leka.osafoundation.org (Postfix) with ESMTP id 03CD73E022F for ; Tue, 6 Jan 2009 15:15:45 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so2900986fgg.17 for ; Tue, 06 Jan 2009 15:15:44 -0800 (PST) Received: by 10.86.92.4 with SMTP id p4mr13106780fgb.36.1231283744364; Tue, 06 Jan 2009 15:15:44 -0800 (PST) Received: by 10.86.30.11 with HTTP; Tue, 6 Jan 2009 15:15:44 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2009 00:15:44 +0100 From: "Thomas Broyer" Sender: t.broyer@gmail.com To: public-html , whatwg@whatwg.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 04d792bdf7ab673a Cc: ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org Subject: Re: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 23:15:57 -0000 On Mon, Jan 5, 2009 at 1:25 AM, Thomas Broyer wrote: > > As I previously said, I spent some holiday time to put my thoughts > about "RFC2617-compliant cookie-based authentication" into an Internet > Draft. A collegue of mine told me I forgot to include a direct link to the draft. Here it is (for those not used to IETF I-Ds' URLs): http://www.ietf.org/internet-drafts/draft-broyer-http-cookie-auth-00.txt I've put an HTML version here: http://ltgt.net/projects/http-cookie-auth/draft-broyer-http-cookie-auth-00.html As a side note, I've moved my Mercurial repository from broyer.info to hg.ltgt.net (you'll be automatically redirected). And my apologies to Julian and others as the -00 draft doesn't include acknowledgements (fixed in the repo) -- Thomas Broyer Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 6A68E3E02C0 for ; Sun, 4 Jan 2009 16:25:17 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsekcMAGLKLh for ; Sun, 4 Jan 2009 16:25:15 -0800 (PST) Received: from mail-gx0-f11.google.com (mail-gx0-f11.google.com [209.85.217.11]) by leka.osafoundation.org (Postfix) with ESMTP id E2A0E3E02BA for ; Sun, 4 Jan 2009 16:25:14 -0800 (PST) Received: by gxk4 with SMTP id 4so5749906gxk.3 for ; Sun, 04 Jan 2009 16:25:14 -0800 (PST) Received: by 10.151.113.11 with SMTP id q11mr16479218ybm.147.1231115113642; Sun, 04 Jan 2009 16:25:13 -0800 (PST) Received: by 10.151.133.7 with HTTP; Sun, 4 Jan 2009 16:25:13 -0800 (PST) Message-ID: Date: Mon, 5 Jan 2009 01:25:13 +0100 From: "Thomas Broyer" Sender: t.broyer@gmail.com To: ietf-http-auth@osafoundation.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 8a222e03b7e5ac66 Cc: whatwg@whatwg.org, ietf-http-wg@w3.org, public-html Subject: [ietf-http-auth] Cookie-based HTTP Authentication (draft-broyer-http-cookie-auth-00) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 00:25:17 -0000 Hi all, As I previously said, I spent some holiday time to put my thoughts about "RFC2617-compliant cookie-based authentication" into an Internet Draft. Today is my birthday (and the last day of my holidays) so I thought I should do something special. I therefore submitted version 00 of my work ("release early, release often" they said). As written in the draft, discussion should go to the ietf-http-auth list (if it happened to not be the appropriate list, please tell me so I can fix it in the next version). The Security Considerations section is not yet complete but for this 00 draft I though the overall authentication process was the most important (have a look at the examples too). Thanks in advance for your feedback. (My intent is to publish some kind of "reference implementations" and "proof of concepts" in various languages later in my mercurial repository http://broyer.info/hg/http-cookie-auth/ but if you'd like to contribute now, just send me your code!) ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Jan 5, 2009 at 1:15 AM Subject: New Version Notification for draft-broyer-http-cookie-auth-00 To: t.broyer@ltgt.net A new version of I-D, draft-broyer-http-cookie-auth-00.txt has been successfuly submitted by Thomas Broyer and posted to the IETF repository. Filename: draft-broyer-http-cookie-auth Revision: 00 Title: Cookie-based HTTP Authentication Creation_date: 2009-01-04 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document specifies an HTTP authentication scheme for use when credentials are validated by an out-of-band mechanism (not defined here) and later communicated to the server through the use of a cookie. Which out-of-band mechanism should be used, and how, is described by the 401 (Unauthorized) response body. It is common practice that this mechanism is an HTML form, sending the user's credentials with the use of an HTTP POST request to a tier URL which will set a cookie in response; though this document doesn't preclude the use of other mechanisms. The IETF Secretariat. -- Thomas Broyer