Re: #177: Realm required on challenges

Hi

firstly, thanks for the expanded text around realm, it makes it a lot 
clearer what it is for.

It does raise an immediate issue for proxy auth though.  Realm in the 
context of the authority + Scheme doesn't make sense for proxy auth.

If a proxy must provide a realm with any challenge, (BTW NTLM ignores 
this), then what is the base effective URI?  How can a proxy indicate 
that proxy creds can be re-used for access to the entire internet?

We may need to propose different restrictions.  For instance on the net 
it would be very dangerous to be able to specify a wild-card or 
universal realm (e.g which encompasses more than one site) due to 
credential leakage issues, but for a proxy that's exactly what you want.

Or, the realm for proxy auth must only apply to the proxy itself (which 
isn't stated anywhere).

In any case, the client will need to treat the realm differently for 
proxy auth vs auth to an O-S.

Yet another reason why intercepting connections is a bad idea.

Adrien


On 25/07/2011 7:12 a.m., Julian Reschke wrote:
> 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
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 beta out now - http://www.wingate.com/getlatest/

Received on Monday, 25 July 2011 01:39:29 UTC