Subject: Re: [Ietf-http-auth] Clients desiring to authenticate
From: Lisa Dusseault <[email-masked]>
To: Joe Orton <[email-masked]>
Cc: HTTP authentication list <[email-masked]>, webdav WG <[email-masked]>
Date: Thu, 5 Jan 2006 14:38:17 -0800
List-Id: ietf-http-auth.osafoundation.org

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

Date: Thu, 5 Jan 2006 22:23:53 +0000
From: Joe Orton <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] Clients desiring to authenticate
Mail-Followup-To: Lisa Dusseault <[email-masked]>, HTTP authentication list <[email-masked]>, webdav WG <[email-masked]>
Cc: HTTP authentication list <[email-masked]>, webdav WG <[email-masked]>

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

Date: Thu, 5 Jan 2006 13:10:05 -0600
From: Nicolas Williams <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] Clients desiring to authenticate
Cc: HTTP authentication list <[email-masked]>, Joe Orton <[email-masked]>, webdav WG <[email-masked]>

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
-- 

From: Lisa Dusseault <[email-masked]>
Date: Thu, 5 Jan 2006 10:33:13 -0800
To: Joe Orton <[email-masked]>
Cc: HTTP authentication list <[email-masked]>, webdav WG <[email-masked]>
Subject: [Ietf-http-auth] Clients desiring to authenticate

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