Re: Basic Authentication behavior

"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> wrote:
>IETF WGs do not generate specifications; authors do.  If someone can
>author up a chunk of text for the Authentication section that describes
>how the "http" URL space is treated hierarchically for predetermining
>the reusability of credentials within a given realm, and can do so in
>a manner less complicated than this sentence, then I am sure Jim can
>add it to the Issues list and the matter can be resolved.

        Appended is the current text of Section 11.1 in the -08 draft,
with a proposed insertion to make explicit the behavior expected for
paths in Request-URIs as originally implemented for Basic Access
Authentication and recently reviewed in the HTTP-WG by Ari Luotonen,
<URL: http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0740.html>.

	Because neither RFC 1945 nor RFC 2068 addressed the issue of
paths and implied protection spaces for Basic Access Authentication,
the insertion uses SHOULD and MAY rather than MUST for this behavior.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================


[CURRENT TEXT:]
            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 base64-user-pass

                   base64-user-pass  = <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", it would use the following header
            field:

                   Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

[START INSERT]---------------------------------------------------------
            A user agent SHOULD assume that all paths at or deeper than
            the depth of the last symbolic element in the path field
            of the Request-URI also are within the protection space
            specified by the Basic realm value of the current challenge,
            and MAY send the corresponding Authorization header with
            requests for resources in that space without receipt of
            another challenge from the server.
[END INSERT]-----------------------------------------------------------

            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.

Received on Tuesday, 9 September 1997 09:18:38 UTC