Source: https://tools.ietf.org/id/draft-ietf-httpbis-p7-auth-20.html
Timestamp: 2017-11-25 11:16:10
Document Index: 778847671

Matched Legal Cases: ['art2', 'art1', 'art1', 'art6', 'art1', 'art 1', 'art2', 'art 2', 'art6', 'art 6', 'art1']

Updates: 2617 (if approved) Y. Lafon, Ed.
Obsoletes: 2616 (if approved) W3C
Intended status: Standards Track J. F. Reschke, Ed.
The changes in this draft are summarized in Appendix Appendix D.1.
Appendix D.1. Since draft-ietf-httpbis-p7-auth-19
HTTP provides several OPTIONAL challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to provide authentication information. The "basic" and "digest" authentication schemes continue to be specified in RFC 2617.
The "b64token" syntax allows the 66 unreserved URI characters ([RFC3986]), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace ([RFC4648]).
Both the Authorization [header.authorization] field value and the Proxy-Authorization [header.proxy-authorization] field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received from the server (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the user as appropriate.
Upon a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server SHOULD return a 401 (Unauthorized) [status.401] response. Such responses MUST include a WWW-Authenticate [header.www-authenticate] header field containing at least one (possibly new) challenge applicable to the requested resource.
Likewise, upon a request that requires authentication by proxies that omit credentials or contain invalid or partial credentials, a proxy SHOULD return a 407 (Proxy Authentication Required) [status.407] response. Such responses MUST include a Proxy-Authenticate [header.proxy-authenticate] header field containing a (possibly new) challenge applicable to the proxy.
A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the 403 (Forbidden) status code (Section 4.6.3 of [Part2]).
A protection space is defined by the canonical root URI (the scheme and authority components of the effective request URI; see Section 5.5 of [Part1]) of the server being accessed, in combination with the realm value if present. 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 registry itself is maintained at http://www.iana.org/assignments/http-authschemes.
HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken to ensure that the connection cannot be used by any party other than the authenticated user (see Section 2.4 of [Part1]).
The credentials carried in an Authorization [header.authorization] header field are specific to the User Agent, and therefore have the same effect on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in.
Therefore, new authentication schemes which choose not to carry credentials in the Authorization [header.authorization] header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private").
The request requires user authentication. The response MUST include a WWW-Authenticate [header.www-authenticate] header field (Section 4.4) containing a challenge applicable to the target resource. The client MAY repeat the request with a suitable Authorization [header.authorization] header field (Section 4.1). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the representation that was given in the response, since that representation might include relevant diagnostic information.
This code is similar to 401 (Unauthorized) [status.401] , but indicates that the client ought to first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate [header.proxy-authenticate] header field (Section 4.2) containing a challenge applicable to the proxy for the target resource. The client MAY repeat the request with a suitable Proxy-Authorization [header.proxy-authorization] header field (Section 4.3).
The "Authorization" header field allows a user agent to authenticate itself with a server — usually, but not necessarily, after receiving a 401 (Unauthorized) [status.401] response. Its value consists of credentials containing information of the user agent for the realm of the resource being requested.
When a shared cache (see Section 1.2 of [Part6]) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:
The HTTP Method Authentication Scheme shall be created at http://www.iana.org/assignments/http-authschemes.
This is of particular concern when a server hosts resources for multiple parties under the same canonical root URI (Section 2.2). Possible mitigation strategies include restricting direct access to authentication credentials (i.e., not making the content of the Authorization [header.authorization] request header field available), and separating protection spaces by using a different host name for each party.
[Part1] Fielding, R., Lafon, Y. and J. F. Reschke, "HTTP/1.1, part 1: Message Routing and Syntax"", Internet-Draft draft-ietf-httpbis-p1-messaging-20, July 2012.
[Part2] Fielding, R., Lafon, Y. and J. F. Reschke, "HTTP/1.1, part 2: Semantics and Payloads", Internet-Draft draft-ietf-httpbis-p2-semantics-20, July 2012.
[Part6] Fielding, R., Lafon, Y., Nottingham, M. and J. F. Reschke, "HTTP/1.1, part 6: Caching", Internet-Draft draft-ietf-httpbis-p6-cache-20, July 2012.
BWS           = <BWS, defined in [Part1], Section 3.2.1>
Yves Lafon (editor) Lafon World Wide Web Consortium W3C / ERCIM 2004, rte des Lucioles Sophia-Antipolis, AM 06902 France EMail: ylafon@w3.org URI: http://www.raubacapeu.net/people/yves/