ISSUE PROXY-AUTHORIZATION: Proposal wording

These are the suggested changes to Chapter 11 regarding proxy
authentication. First, I have some general notes about the text:

- For some reason WWW-authenticate allows multiple challenges but
Proxy-Authenticate allows only one. However, the text was not consistent on
how many challenges there could be. This should now be consistent

- Sometimes the description of Authorization header says "client" and
sometimes it says "user agent" and likewise "origin server" vs "server".
WWW-authenticate and Authorizartion is between user agent and origin server
and Proxy-Authenticate and Proxy-Authorization is between client and
server. This should now be consistent. I don't like the idea the clients
(not only user agents) can't issue WWW-authenticate headers. There are
cases where a proxy can be authorized to do stuff on behalf of the proxy
clients but I guess that this is too late.

- 13.5.1. does not list Proxy-Authorization as a hop-by-hop header which I
guess it should.

- The edits should be orthogonal to the fact that AA is going into a
separate spec.

Comments?

Henrik

****************************************************************************

11 Access Authentication 

HTTP provides a simple challenge-response authentication mechanism which
MAY be used by a server to challenge a client request and by a client to
provide authentication information. It uses an extensible, case-insensitive
token to identify the authentication scheme, followed by a comma-separated
list of attribute-value pairs which carry the parameters necessary for
achieving authentication via that scheme.

       auth-scheme    = token
       auth-param     = token "=" quoted-string

The 401 (Unauthorized) response message is used by an origin server to
challenge the authorization of a user agent. This response MUST include a
WWW-Authenticate header field containing at least one challenge applicable
to the requested resource. The 407 (Proxy Authentication Required) response
message is used by a proxy to challenge the authorization of a client and
MUST include a Proxy-Authenticate header field containing a challenge
applicable to the proxy for the requested resource.

       challenge      = auth-scheme 1*SP realm *( "," auth-param )
       realm          = "realm" "=" realm-value
       realm-value    = quoted-string

The realm attribute (case-insensitive) is required for all authentication
schemes which issue a challenge. The realm value (case-sensitive), in
combination with the canonical root URL (see section 5.1.2) of the server
being accessed, defines the protection space. These realms allow the
protected resources on a server to be partitioned into a set of protection
spaces, each with its own authentication scheme and/or authorization
database. The realm value is a string, generally assigned by the origin
server, which may have additional semantics specific to the authentication
scheme.

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. Both the Authorization field value and the
Proxy-Authorization field value consists of credentials containing the
authentication information of the client for the realm of the resource
being requested.

       credentials    = basic-credentials
                      | auth-scheme #auth-param

The domain over which credentials can be automatically applied by a client
is determined by the protection space. If a prior request has been
authorized, the same credentials MAY be reused for all other requests
within that protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless otherwise
defined by the authentication scheme, a single protection space cannot
extend outside the scope of its 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.

The HTTP protocol does not restrict applications to this simple
challenge-response mechanism for access authentication. Additional
mechanisms MAY be used, such as encryption at the transport level or via
message encapsulation, and with additional header fields specifying
authentication information. However, these additional mechanisms are not
defined by this specification.
Proxies MUST be completely transparent regarding user agent authentication
by origin servers. That is, they MUST forward the WWW-Authenticate and
Authorization headers untouched, and follow the rules found in section
14.8. Both the Proxy-Authenticate and the Proxy-Authorization header fields
are hop-by-hop headers (see section 13.5.1).

11.1 Basic Authentication Scheme 

The "basic" authentication scheme is based on the model that the client
must authenticate itself with a user-ID and a password for each realm. The
realm value should be considered an opaque string which can only be
compared for equality with other realms on that server. The server will
service the request only if it can validate the user-ID and password for
the protection space of the Request-URI. There are no optional
authentication parameters.

Upon receipt of an unauthorized request for a URI within the protection
space, the origin server MAY respond with a challenge like the following:

       WWW-Authenticate: Basic realm="WallyWorld"

where "WallyWorld" is the string assigned by the server to identify the
protection space of the Request-URI. A proxy may respond with the same
challenge using the Proxy-Authenticate header field.

To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 [7] encoded
string in the credentials.

       basic-credentials = "Basic" SP basic-cookie
       basic-cookie   = <base64 [7] encoding of user-pass,
                        except not limited to 76 char/line>
       user-pass   = userid ":" password
       userid      = *<TEXT excluding ":">
       password    = *TEXT

Userids might be case sensitive.

If the user agent wishes to send the userid "Aladdin" and password "open
sesame" to an origin server, it would use the following header field:

       Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

If a client wishes to send the same userid and password to a proxy, it
would use the Proxy-Authorization header field. See section 15 for security
considerations associated with Basic authentication.

11.2 Digest Authentication Scheme 

Note for the RFC editor: This section is reserved for including the Digest
Authentication specification, or if the RFC editor chooses to issue a
single RFC rather than two RFC's, this section should be deleted.

Received on Thursday, 3 July 1997 12:24:55 UTC