Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F39247F603 for ; Thu, 5 Jan 2006 14:38:20 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C787A1422D0; Thu, 5 Jan 2006 14:38:20 -0800 (PST) In-Reply-To: <20060105222353.GA15846@redhat.com> References: <20060105222353.GA15846@redhat.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-http-auth] Clients desiring to authenticate Date: Thu, 5 Jan 2006 14:38:17 -0800 To: Joe Orton X-Mailer: Apple Mail (2.623) Cc: HTTP authentication list , webdav WG X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 22:38:21 -0000 On Jan 5, 2006, at 2:23 PM, Joe Orton wrote: > On Thu, Jan 05, 2006 at 10:33:13AM -0800, Lisa Dusseault wrote: >> Thanks for your thoughts on the authentication stuff, Joe, but I >> certainly disagree at a most fundamental level about whether it's >> something clients need to be able to do. Browsers might not need to >> do >> so, but I can think of cases where that would be useful for browsers >> too, and it's definitely useful for authoring clients where >> authorization info is usually necessary to do write operations. >> >> Consider some of the WebDAV clients that I'm familiar with: > ... > > None of this has anything to do with "pre-authenticating" in HTTP. > > If your application is designed such that it cannot interactively > prompt > users for credentials when challenged, fine, the app must request those > credentials from the user ahead of time. This isn't necessarily an application that can't interactively prompt users for credentials. This is an application that, in addition to that, can save credentials as preferences, and to save the user from confusion (either from seeing incomplete information or to know what parts of the UI to enable) would like to perform operations with the maximum permissions available. Have you ever seen an application where certain menu functions, buttons or form areas were greyed out or disabled based on what permissions were available? I can read my colleague Ted's calendar as I'm subscribed to it via Apple's iCal. Yet I can't add notes to his events, move them around, or add new events, and the UI makes that clear (e.g. New Event is greyed out in the menu). But let's say Apple wanted to add the feature that if Ted grants write permission to me, to write his publicly-viewable calendar. How would Apple's client know what to grey out? > That is purely an application > design problem, it doesn't imply that the user agent must send those > credentials to the server *before it is challenged to do so*. > >> I also disagree about your reading of 2617. The text is "If the origin >> server does not wish to accept the credentials sent with a request, it >> SHOULD return a 401 (Unauthorized) response. " Isn't ignoring the >> credentials the same thing as "not wish to accept"? How can you >> justify accepting a bogus username and password except by entirely >> ignoring it? > > The server has no basis on which to validate the credentials, and hence > do anything other than ignore them. My statement would go like "The server had no basis on which to validate the credentials, and hence do anything other than fail the request." > It *cannot* form a valid WWW-Auth > challenge because it has not been configured to do so. Follow your > argument through as if you were going to implement it server-side: what > challenge do you expect the server to send? It cannot make one up out > of thin air. All of the servers I've worked on had the ability to put together a valid WWW-Auth challenge for any resource on the server (IIS, Exchange, Xythos WebFile Server, Cosmo). I can certainly understand some Web servers don't even have user logins and thus can't form a challenge, and for those Web servers presumably ignoring the Authorization header could be considered somewhat reasonable. But that isn't the case with the server we tested against, www.webdav.org. I know that server has the ability to put together a challenge because if I formulate a PUT to one of its pages it does challenge me. In this specific example, isn't it wrong for www.webdav.org to simply ignore the auth attempt? What should www.webdav.org do if I send a request with my real username but an incorrect password? > >> But we can certainly quibble about *how* the problem is solved, I care >> more *that* the problem is solved -- for HTTP, WebDAV, CalDAV and >> others. Would you feel it was still a hack if the client used what >> had previously been a legitimate username (at least for elsewhere in >> that domain)? > > If we're not talking about the "I don't want to have to send the 100MB > PUT body twice in case I get a 401 the first time" problem (which is > what I presumed that Appendix D was really about), I don't know what > problem you're talking about. It's really more about the PROPFIND returning different results depending on how the client is authenticated, and the WebDAV ACL "what permissions do I have" request returning different results depending on how the client is authenticated. Lisa Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 74F457F5EF; Thu, 5 Jan 2006 14:23:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 61B231422D0; Thu, 5 Jan 2006 14:23:57 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24259-06; Thu, 5 Jan 2006 14:23:57 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0192B1422CF; Thu, 5 Jan 2006 14:23:56 -0800 (PST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k05MNuO6010023; Thu, 5 Jan 2006 17:23:56 -0500 Received: from radish.cambridge.redhat.com (radish.cambridge.redhat.com [172.16.18.90]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k05MNt128089; Thu, 5 Jan 2006 17:23:55 -0500 Received: (from jorton@localhost) by radish.cambridge.redhat.com (8.13.4/8.13.4/Submit) id k05MNrdP017143; Thu, 5 Jan 2006 22:23:53 GMT Date: Thu, 5 Jan 2006 22:23:53 +0000 From: Joe Orton To: Lisa Dusseault Subject: Re: [Ietf-http-auth] Clients desiring to authenticate Message-ID: <20060105222353.GA15846@redhat.com> Mail-Followup-To: Lisa Dusseault , HTTP authentication list , webdav WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: HTTP authentication list , webdav WG X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 22:23:57 -0000 On Thu, Jan 05, 2006 at 10:33:13AM -0800, Lisa Dusseault wrote: > Thanks for your thoughts on the authentication stuff, Joe, but I > certainly disagree at a most fundamental level about whether it's > something clients need to be able to do. Browsers might not need to do > so, but I can think of cases where that would be useful for browsers > too, and it's definitely useful for authoring clients where > authorization info is usually necessary to do write operations. > > Consider some of the WebDAV clients that I'm familiar with: ... None of this has anything to do with "pre-authenticating" in HTTP. If your application is designed such that it cannot interactively prompt users for credentials when challenged, fine, the app must request those credentials from the user ahead of time. That is purely an application design problem, it doesn't imply that the user agent must send those credentials to the server *before it is challenged to do so*. > I also disagree about your reading of 2617. The text is "If the origin > server does not wish to accept the credentials sent with a request, it > SHOULD return a 401 (Unauthorized) response. " Isn't ignoring the > credentials the same thing as "not wish to accept"? How can you > justify accepting a bogus username and password except by entirely > ignoring it? The server has no basis on which to validate the credentials, and hence do anything other than ignore them. It *cannot* form a valid WWW-Auth challenge because it has not been configured to do so. Follow your argument through as if you were going to implement it server-side: what challenge do you expect the server to send? It cannot make one up out of thin air. > But we can certainly quibble about *how* the problem is solved, I care > more *that* the problem is solved -- for HTTP, WebDAV, CalDAV and > others. Would you feel it was still a hack if the client used what > had previously been a legitimate username (at least for elsewhere in > that domain)? If we're not talking about the "I don't want to have to send the 100MB PUT body twice in case I get a 401 the first time" problem (which is what I presumed that Appendix D was really about), I don't know what problem you're talking about. joe Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 216F97F5C8; Thu, 5 Jan 2006 11:10:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E4691422C6; Thu, 5 Jan 2006 11:10:13 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30167-01; Thu, 5 Jan 2006 11:10:12 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id B489F1422C4; Thu, 5 Jan 2006 11:10:12 -0800 (PST) Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k05JAC3F003586; Thu, 5 Jan 2006 12:10:12 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k05JAAgt029415; Thu, 5 Jan 2006 12:10:11 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k05JA6c8004154; Thu, 5 Jan 2006 13:10:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k05JA5MK004153; Thu, 5 Jan 2006 13:10:05 -0600 (CST) Date: Thu, 5 Jan 2006 13:10:05 -0600 From: Nicolas Williams To: Lisa Dusseault Subject: Re: [Ietf-http-auth] Clients desiring to authenticate Message-ID: <20060105191005.GI18698@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: HTTP authentication list , Joe Orton , webdav WG X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 19:10:13 -0000 On Thu, Jan 05, 2006 at 10:33:13AM -0800, Lisa Dusseault wrote: > I do agree both of the approaches outlined in the current appendix are > hacks. We had previously specified a non-hack approach -- a > "Force-Authentication" request header flag that indicated the client > might have authorization information which it could provide if only the > server sent a challenge. It's not necessarily easy for the server to know that a client would have more access were it to authenticate (at all, differently), though it's safe to assume that it might. I think this is the identity selection problem, which I did not think this list was intended to tackle. Nico -- Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 52F137F5C1 for ; Thu, 5 Jan 2006 10:33:17 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D00AF1422C7; Thu, 5 Jan 2006 10:33:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Thu, 5 Jan 2006 10:33:13 -0800 To: Joe Orton X-Mailer: Apple Mail (2.623) Cc: HTTP authentication list , webdav WG Subject: [Ietf-http-auth] Clients desiring to authenticate X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 18:33:17 -0000 Thanks for your thoughts on the authentication stuff, Joe, but I certainly disagree at a most fundamental level about whether it's something clients need to be able to do. Browsers might not need to do so, but I can think of cases where that would be useful for browsers too, and it's definitely useful for authoring clients where authorization info is usually necessary to do write operations. Consider some of the WebDAV clients that I'm familiar with: - When you configure a Network Place in Windows you can provide a username and password right up front. - Xythos WebFile client has username and password configured when you set up the connection to the server, and subsequent connections use that preference info. - Chandler 0.6 configures sharing servers just like email servers, assuming that users have a home directory and should always log in -- again, preference info that's reused with later connections. When any of these clients is directed to a URL that may be publicly readable but with results that may differ depending on what permissions you have, what are these clients supposed to do? Some real examples: - If a Xythos WebFile server has some resources that are not publicly readable, these won't show up in publicly readable parent collections. It requires permissions to see the whole set of child resources of a collection in a PROPFIND response. Yet an anonymous request to the publicly readable parent collection won't result in a challenge -- just a smaller result set. - If a Cosmo sharing server has a publicly readable calendar, then when Chandler visits that calendar, it will be able to read the calendar and ask what permissions it has without ever seeing an authentication challenge. Yet it's quite possible that the Chandler user has a username and password that would provide write permissions on the calendar. How does Chandler even know to activate the "add event" button when it's anonymous, asks what permissions it has, and is told that it has read-only? Not only is this coming up on the WebDAV list but this and similar problems caused us to try to get the "HTTP-Auth" list started recently, and the DIX (Digital Identity Exchange) discussion list (DIX is working towards a BOF, then they hope a WG). I've been asked over and over again how a client "desiring" to authenticate (OK I agree desiring is the wrong word) can do so. I also disagree about your reading of 2617. The text is "If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. " Isn't ignoring the credentials the same thing as "not wish to accept"? How can you justify accepting a bogus username and password except by entirely ignoring it? But we can certainly quibble about *how* the problem is solved, I care more *that* the problem is solved -- for HTTP, WebDAV, CalDAV and others. Would you feel it was still a hack if the client used what had previously been a legitimate username (at least for elsewhere in that domain)? I do agree both of the approaches outlined in the current appendix are hacks. We had previously specified a non-hack approach -- a "Force-Authentication" request header flag that indicated the client might have authorization information which it could provide if only the server sent a challenge. Lisa