Re: #177: Realm required on challenges

On 2011-07-24 20:20, Mark Nottingham wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/177>
>
> Proposal:
>
> 1) put the text on realms into a separate subsection (editorial suggestion), and
>
> 2) in p7, change:
>
>>    The authentication parameter realm is defined for all authentication schemes:
>
>
> to:
>
> """
> The authentication parameter 'realm' is reserved for use by authentications schemes that wish to indicate the scope of protection:
> """
>
> 3) drop this sentence:
>
>> The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge.

+1

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/177/177.diff>

New text of Section 2 (after putting in more structure):


2.  Access Authentication Framework

2.1.  Challenge and Response

    HTTP provides a simple challenge-response authentication mechanism
    that can 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 "=" ( 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 at least one challenge
    applicable to the proxy for the requested resource.

      challenge   = auth-scheme 1*SP 1#auth-param

       Note: User agents will need to take special care in parsing the
       WWW-Authenticate and Proxy-Authenticate header field values
       because they can contain more than one challenge, or if more than
       one of each is provided, since the contents of a challenge can
       itself contain a comma-separated list of authentication
       parameters.

       Note: Many browsers fail to parse challenges containing unknown
       schemes.  A workaround for this problem is to list well-supported
       schemes (such as "basic") first.

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

      credentials = auth-scheme ( token
                                / quoted-string
                                / #auth-param )

    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, such additional
    mechanisms are not defined by this specification.

    Proxies MUST forward the WWW-Authenticate and Authorization headers
    unmodified and follow the rules found in Section 4.1.

2.2.  Protection Space (Realm)

    The authentication parameter realm is reserved for use by
    authentication schemes that wish to indicate the scope of protection:

      realm       = "realm" "=" realm-value
      realm-value = quoted-string

    The realm value (case-sensitive), in combination with the canonical
    root URI (the scheme and authority components of the effective
    request URI; see Section 4.3 of [Part1]) 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 can have additional semantics
    specific to the authentication scheme.  Note that there can be
    multiple challenges with the same auth-scheme but different realms.

    The protection space determines the domain over which credentials can
    be automatically applied.  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.

2.3.  Authentication Scheme Registry

    The HTTP Authentication Scheme Registry defines the name space for
    the authentication schemes in challenges and credentials.

    Registrations MUST include the following fields:

    o  Authentication Scheme Name

    o  Pointer to specification text

    Values to be added to this name space are subject to IETF review
    ([RFC5226], Section 4.1).

    The registry itself is maintained at
    <http://www.iana.org/assignments/http-authschemes>.


Feedback appreciated, Julian

Received on Sunday, 24 July 2011 19:12:34 UTC