Re: WGLC #357: Authentication Exchanges

Dear Amos and Mark,

> A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the 403 (Forbidden) status code.

I have a different understanding on the use of 401/403 statuses.
At least on current implementations (e.g. Apache),
auth-succeed and authz-failed status will be represented by
401-status instead of 403.
403 status is used, for example, when the content is
not accessible by underlying filesystem permissions,
or by server configuration for denying directory listing.

I think this (use 401 instead of 403) should be kept for two reasons:

 * Without 401 status, client will not know that changing
    the user name and the password will solve the
    inaccessibility issue.
 * If we change 403 status' behavior, it conflicts with
   the current use of 403 status described above
   (e.g. denied directory listing within auth-protected realm).

# This is part of the reason that I recently (just in httpbis-00 revision)
added "authz-failed" reason code into our HTTP Mutual proposal,
which has OPTIONAL detailed description codes for authentication/
authorization failures.

2012/6/20 Mark Nottingham <mnot@mnot.net>:
>
> On 20/06/2012, at 1:08 PM, Amos Jeffries wrote:
>
>> On 20.06.2012 14:04, Mark Nottingham wrote:
>>> Looking at this, I think this language in the spec isn't very good
>>> for other reasons as well:
>>>
>>>> If the origin server does not wish to accept the credentials sent with a request, it should return a 401 (Unauthorized) response. The responsemust include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.
>>>>
>>>> If a proxy does not accept the credentials sent with a request, it should return a 407 (Proxy Authentication Required) response. The responsemust include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested resource.
>>>
>>>
>>> Because "accept" can be read in so many ways. I think we can fix both
>>> problems with something like:
>>>
>>> """
>>> Requests for protected resources that omit credentials, contain
>>> invalid credentials (e.g., a bad password), or partial credentials
>>> (e.g., when the scheme requires more than one round trip) SHOULD
>>> return a 401 (Unauthorized) response. Such responses MUST include a
>>> WWW-Authenticate header field containing at least one (possibly new)
>>> challenge applicable to the requested resource.
>>>
>>> Likewise, requests that require authentication by proxies that omit
>>> credentials, or contain invalid or partial credentials SHOULD return a
>>> 407 (Proxy Authentication Required) response. The response MUST
>>> include a Proxy-Authenticate header field containing a (possibly new)
>>> challenge applicable to the proxy.
>>> """
>>>
>>> Thoughts?
>>>
>>
>> second paragraph:  s/The response MUST/ Such responses MUST/ is a bit clearer that its the 407 which "MUST", not any other status which may happen.
>
> OK
>
>> There is also no mention in any of the auth draft about 403 responses being used to terminate authentication attempts or cycles regardless of credentials validity or presence.
>>
>> Something informational in this section would be very useful to clarify that 403 is one of the authentication-related states, for use in halting loops or making N-tries limitations.
>
> How about, after those two paragraphs:
>
> """
> A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the 403 (Forbidden) status code.
> """
>
> ?
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>



-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Wednesday, 20 June 2012 08:37:16 UTC