W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: Review of draft-ietf-httpbis-p7-auth-19.txt

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 09 May 2012 11:42:46 +1200
To: <ietf-http-wg@w3.org>
Message-ID: <bb71bb02cb982652319da3a3ff17d678@treenet.co.nz>
On 09.05.2012 07:59, Alexey Melnikov wrote:
> Hi,
> Yet another late review:
>
>    A user agent that wishes to authenticate itself with an origin 
> server
>    -- usually, but not necessarily, after receiving a 401 
> (Unauthorized)
>    -- MAY do so by including an Authorization header field with the
>    request.
>
>    A client that wishes to authenticate itself with a proxy -- 
> usually,
>    but not necessarily, after receiving a 407 (Proxy Authentication
>    Required) -- MAY do so by including a Proxy-Authorization header
>    field with the request.
>
> It doesn't look like use of the 2 MAYs above is appropriate, because
> they are not implementation alternatives. Maybe change them to "can"?

Or; " -- does so by including" ?

>
>    Both the Authorization field value and the Proxy-Authorization 
> field
>    value consist of credentials containing the authentication
>    information of the client for the realm of the resource being
>    requested.  The user agent MUST choose to use one of the 
> challenges
>    with the strongest auth-scheme it understands and request 
> credentials
>    from the user based upon that challenge.
>
> This is overly simplistic: I think this should talk about the client
> possibly falling back to an authentication scheme B if authentication
> with scheme A failed, and both A and B were advertised by the server.

History repeats. This argument comes up in just about every review. 
Always concluding that there is no universal "strongest" when it comes 
to schemes or security. It always depends on external environment and 
end point particulars which are outside of HTTP scope.

This MUST is not actually required for the HTTP protocol, but to 
encourage best-practice as much as possible. It is as far as the WG 
seems to be able and willing to go at present without over-reaching 
charter scope.


>
>    If the origin server does not wish to accept the credentials sent
>    with a request, it SHOULD return a 401 (Unauthorized) response.  
> The
>    response MUST 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).  The response
>    MUST include a Proxy-Authenticate header field containing a 
> (possibly
>    new) challenge applicable to the proxy for the requested resource.
>
> I think this is a bit misleading. Can an authentication exchange 
> include
> more than one round trip? I think you need to be explicit one way or
> another. (If it can, then "does not accept" is not necessarily
> correct.)

Yes. NTLM does. Which is one reason why it breaks in the presence of 
simple load balancers. Ideally the HTTP request should be self-contained 
enough for proxy chaining and TCP pathways not to matter.

AYJ
Received on Tuesday, 8 May 2012 23:43:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 May 2012 23:43:26 GMT