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

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 May 2012 20:59:04 +0100

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

    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.

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

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 08 May 2012 21:59:11 +0000

------ Original Message ------
From: "Alexey Melnikov" <[email-masked]>
To: "HTTP Working Group" <[email-masked]>
Sent: 9/05/2012 7:59:04 a.m.
Subject: Review of draft-ietf-httpbis-p7-auth-19.txt
>another. (If it can, then "does not accept" is not necessarily 
NTLM has several.

Also I don't think HTTP should be specifying what should be policy 
decisions for a system operator.
  
A server should be free to decide that it doesn't wish to offer the 
client another attempt to supply credentials (e.g. send a 403 back).  
So the above paragraphs should be put in the context of only where the 
server does wish to offer this option.
  
Adrien

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 09 May 2012 11:42:46 +1200

> they are not implementation alternatives. Maybe change them to "can"?

Or; " -- does so by including" ?

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

> another. (If it can, then "does not accept" is not necessarily

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 9 May 2012 13:15:10 +1000

Thanks, Alexey.

> they are not implementation alternatives. Maybe change them to "can"?

New editorial ticket: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/356>

> with scheme A failed, and both A and B were advertised by the server.

This is already covered by <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/349>, I think.

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

New design ticket: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/357>

--
Mark Nottingham   http://www.mnot.net/