You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/11/13 04:52:29 UTC
svn commit: r594419 [16/16] -
/labs/webarch/trunk/http/draft-fielding-http/00/
Propchange: labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p6-cache-00.xml
------------------------------------------------------------------------------
svn:eol-style = native
Added: labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.txt
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.txt?rev=594419&view=auto
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.txt (added)
+++ labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.txt Mon Nov 12 19:52:28 2007
@@ -0,0 +1,504 @@
+
+
+
+Network Working Group R. Fielding, Ed.
+Internet-Draft Day Software
+Obsoletes: 2068, 2616, 2617 J. Gettys
+(if approved) J. Mogul
+Intended status: Standards Track HP
+Expires: May 14, 2008 H. Frystyk
+ Microsoft
+ L. Masinter
+ Adobe Systems
+ P. Leach
+ Microsoft
+ T. Berners-Lee
+ W3C/MIT
+ November 11, 2007
+
+
+ HTTP/1.1, part 7: Authentication
+ draft-fielding-http-p7-auth-00
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on May 14, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+
+
+
+Fielding, et al. Expires May 14, 2008 [Page 1]
+
+Internet-Draft HTTP/1.1 November 2007
+
+
+Abstract
+
+ The Hypertext Transfer Protocol (HTTP) is an application-level
+ protocol for distributed, collaborative, hypermedia information
+ systems. HTTP has been in use by the World Wide Web global
+ information initiative since 1990. This document is Part 7 of the
+ eight-part specification that defines the protocol referred to as
+ "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. Part
+ 7 defines HTTP Authentication.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Header Field Definitions . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Authorization . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 4
+ 2.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . . 4
+ 2.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 5
+ 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Authentication Credentials and Idle Clients . . . . . . . . 5
+ 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Intellectual Property and Copyright Statements . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires May 14, 2008 [Page 2]
+
+Internet-Draft HTTP/1.1 November 2007
+
+
+1. Introduction
+
+ This document will define aspects of HTTP related to access control
+ and authentication. Right now it only includes the extracted
+ relevant sections of RFC 2616 [RFC2616] with only minor edits.
+
+ 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
+ general framework for access authentication, and the specification of
+ "basic" and "digest" authentication, are specified in "HTTP
+ Authentication: Basic and Digest Access Authentication" [RFC2617].
+ This specification adopts the definitions of "challenge" and
+ "credentials" from that specification.
+
+
+2. Header Field Definitions
+
+ This section defines the syntax and semantics of all standard
+ HTTP/1.1 header fields. For entity-header fields, both sender and
+ recipient refer to either the client or the server, depending on who
+ sends and who receives the entity.
+
+2.1. Authorization
+
+ A user agent that wishes to authenticate itself with a server--
+ usually, but not necessarily, after receiving a 401 response--does so
+ by including an Authorization request-header field with the request.
+ The Authorization field value consists of credentials containing the
+ authentication information of the user agent for the realm of the
+ resource being requested.
+
+ Authorization = "Authorization" ":" credentials
+
+ HTTP access authentication is described in "HTTP Authentication:
+ Basic and Digest Access Authentication" [RFC2617]. If a request is
+ authenticated and a realm specified, the same credentials SHOULD be
+ valid for all other requests within this realm (assuming that the
+ authentication scheme itself does not require otherwise, such as
+ credentials that vary according to a challenge value or using
+ synchronized clocks).
+
+ When a shared cache (see [Part 6]) 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:
+
+
+
+
+
+Fielding, et al. Expires May 14, 2008 [Page 3]
+
+Internet-Draft HTTP/1.1 November 2007
+
+
+ 1. If the response includes the "s-maxage" cache-control directive,
+ the cache MAY use that response in replying to a subsequent
+ request. But (if the specified maximum age has passed) a proxy
+ cache MUST first revalidate it with the origin server, using the
+ request-headers from the new request to allow the origin server
+ to authenticate the new request. (This is the defined behavior
+ for s-maxage.) If the response includes "s-maxage=0", the proxy
+ MUST always revalidate it before re-using it.
+
+ 2. If the response includes the "must-revalidate" cache-control
+ directive, the cache MAY use that response in replying to a
+ subsequent request. But if the response is stale, all caches
+ MUST first revalidate it with the origin server, using the
+ request-headers from the new request to allow the origin server
+ to authenticate the new request.
+
+ 3. If the response includes the "public" cache-control directive, it
+ MAY be returned in reply to any subsequent request.
+
+2.2. Proxy-Authenticate
+
+ The Proxy-Authenticate response-header field MUST be included as part
+ of a 407 (Proxy Authentication Required) response. The field value
+ consists of a challenge that indicates the authentication scheme and
+ parameters applicable to the proxy for this Request-URI.
+
+ Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
+
+ The HTTP access authentication process is described in "HTTP
+ Authentication: Basic and Digest Access Authentication" [RFC2617].
+ Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
+ only to the current connection and SHOULD NOT be passed on to
+ downstream clients. However, an intermediate proxy might need to
+ obtain its own credentials by requesting them from the downstream
+ client, which in some circumstances will appear as if the proxy is
+ forwarding the Proxy-Authenticate header field.
+
+2.3. Proxy-Authorization
+
+ The Proxy-Authorization request-header field allows the client to
+ identify itself (or its user) to a proxy which requires
+ authentication. The Proxy-Authorization field value consists of
+ credentials containing the authentication information of the user
+ agent for the proxy and/or realm of the resource being requested.
+
+ Proxy-Authorization = "Proxy-Authorization" ":" credentials
+
+ The HTTP access authentication process is described in "HTTP
+
+
+
+Fielding, et al. Expires May 14, 2008 [Page 4]
+
+Internet-Draft HTTP/1.1 November 2007
+
+
+ Authentication: Basic and Digest Access Authentication" [RFC2617].
+ Unlike Authorization, the Proxy-Authorization header field applies
+ only to the next outbound proxy that demanded authentication using
+ the Proxy-Authenticate field. When multiple proxies are used in a
+ chain, the Proxy-Authorization header field is consumed by the first
+ outbound proxy that was expecting to receive credentials. A proxy
+ MAY relay the credentials from the client request to the next proxy
+ if that is the mechanism by which the proxies cooperatively
+ authenticate a given request.
+
+2.4. WWW-Authenticate
+
+ The WWW-Authenticate response-header field MUST be included in 401
+ (Unauthorized) response messages. The field value consists of at
+ least one challenge that indicates the authentication scheme(s) and
+ parameters applicable to the Request-URI.
+
+ WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
+
+ The HTTP access authentication process is described in "HTTP
+ Authentication: Basic and Digest Access Authentication" [RFC2617].
+ User agents are advised to take special care in parsing the WWW-
+ Authenticate field value as it might contain more than one challenge,
+ or if more than one WWW-Authenticate header field is provided, the
+ contents of a challenge itself can contain a comma-separated list of
+ authentication parameters.
+
+
+3. IANA Considerations
+
+ TBD.
+
+
+4. Security Considerations
+
+ This section is meant to inform application developers, information
+ providers, and users of the security limitations in HTTP/1.1 as
+ described by this document. The discussion does not include
+ definitive solutions to the problems revealed, though it does make
+ some suggestions for reducing security risks.
+
+4.1. Authentication Credentials and Idle Clients
+
+ Existing HTTP clients and user agents typically retain authentication
+ information indefinitely. HTTP/1.1. does not provide a method for a
+ server to direct clients to discard these cached credentials. This
+ is a significant defect that requires further extensions to HTTP.
+ Circumstances under which credential caching can interfere with the
+
+
+
+Fielding, et al. Expires May 14, 2008 [Page 5]
+
+Internet-Draft HTTP/1.1 November 2007
+
+
+ application's security model include but are not limited to:
+
+ o Clients which have been idle for an extended period following
+ which the server might wish to cause the client to reprompt the
+ user for credentials.
+
+ o Applications which include a session termination indication (such
+ as a `logout' or `commit' button on a page) after which the server
+ side of the application `knows' that there is no further reason
+ for the client to retain the credentials.
+
+ This is currently under separate study. There are a number of work-
+ arounds to parts of this problem, and we encourage the use of
+ password protection in screen savers, idle time-outs, and other
+ methods which mitigate the security problems inherent in this
+ problem. In particular, user agents which cache credentials are
+ encouraged to provide a readily accessible mechanism for discarding
+ cached credentials under user control.
+
+
+5. Acknowledgments
+
+ Based on an XML translation of RFC 2616 by Julian Reschke.
+
+
+6. References
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+ Leach, P., Luotonen, A., and L. Stewart, "HTTP
+ Authentication: Basic and Digest Access Authentication",
+ RFC 2617, June 1999.
+
+
+Index
+
+ A
+ Authorization header 3
+
+ G
+ Grammar
+ Authorization 3
+ Proxy-Authenticate 4
+ Proxy-Authorization 4
+ WWW-Authenticate 5
+
+
+
+Fielding, et al. Expires May 14, 2008 [Page 6]
+
+Internet-Draft HTTP/1.1 November 2007
+
+
+ H
+ Headers
+ Authorization 3
+ Proxy-Authenticate 4
+ Proxy-Authorization 4
+ WWW-Authenticate 5
+
+ P
+ Proxy-Authenticate header 4
+ Proxy-Authorization header 4
+
+ W
+ WWW-Authenticate header 5
+
+
+Authors' Addresses
+
+ Roy T. Fielding (editor)
+ Day Software
+ 23 Corporate Plaza DR, Suite 280
+ Newport Beach, CA 92660
+ USA
+
+ Phone: +1-949-706-5300
+ Fax: +1-949-706-5305
+ Email: fielding@gbiv.com
+ URI: http://roy.gbiv.com/
+
+
+ James Gettys
+ Hewlett-Packard Company
+ HP Labs, Cambridge Research Laboratory
+ One Cambridge Center
+ Cambridge, MA 02138
+ USA
+
+ Email: Jim.Gettys@hp.com
+
+
+ Jeffrey C. Mogul
+ Hewlett-Packard Company
+ HP Labs, Large Scale Systems Group
+ 1501 Page Mill Road, MS 1177
+ Palo Alto, CA 94304
+ USA
+
+ Email: JeffMogul@acm.org
+
+
+
+
+Fielding, et al. Expires May 14, 2008 [Page 7]
+
+Internet-Draft HTTP/1.1 November 2007
+
+
+ Henrik Frystyk Nielsen
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+
+ Email: henrikn@microsoft.com
+
+
+ Larry Masinter
+ Adobe Systems, Incorporated
+ 345 Park Ave
+ San Jose, CA 95110
+ USA
+
+ Email: LMM@acm.org
+ URI: http://larry.masinter.net/
+
+
+ Paul J. Leach
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052
+
+ Email: paulle@microsoft.com
+
+
+ Tim Berners-Lee
+ World Wide Web Consortium
+ MIT Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139
+ USA
+
+ Fax: +1 (617) 258 8682
+ Email: timbl@w3.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires May 14, 2008 [Page 8]
+
+Internet-Draft HTTP/1.1 November 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Fielding, et al. Expires May 14, 2008 [Page 9]
+
Propchange: labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.xml?rev=594419&view=auto
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.xml (added)
+++ labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.xml Mon Nov 12 19:52:28 2007
@@ -0,0 +1,475 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE rfc [
+ <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
+ <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
+ <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
+ <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
+ <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
+ <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
+ <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
+ <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
+ <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
+ <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
+ <!ENTITY shared-and-non-shared-caches "[Part 6]">
+]>
+<?rfc toc="yes" ?>
+<?rfc symrefs="yes" ?>
+<?rfc sortrefs="yes" ?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no" ?>
+<?rfc linkmailto="no" ?>
+<?rfc editing="no" ?>
+<?rfc-ext allow-markup-in-artwork="yes" ?>
+<?rfc-ext include-references-in-index="yes" ?>
+<rfc obsoletes="2068, 2616, 2617" category="std"
+ ipr="full3978" docName="draft-fielding-http-p7-auth-00"
+ xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit">
+<front>
+
+ <title abbrev="HTTP/1.1">HTTP/1.1, part 7: Authentication</title>
+
+ <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
+ <organization abbrev="Day Software">Day Software</organization>
+ <address>
+ <postal>
+ <street>23 Corporate Plaza DR, Suite 280</street>
+ <city>Newport Beach</city>
+ <region>CA</region>
+ <code>92660</code>
+ <country>USA</country>
+ </postal>
+ <phone>+1-949-706-5300</phone>
+ <facsimile>+1-949-706-5305</facsimile>
+ <email>fielding@gbiv.com</email>
+ <uri>http://roy.gbiv.com/</uri>
+ </address>
+ </author>
+
+ <author initials="J." surname="Gettys" fullname="James Gettys">
+ <organization abbrev="HP">Hewlett-Packard Company</organization>
+ <address>
+ <postal>
+ <street>HP Labs, Cambridge Research Laboratory</street>
+ <street>One Cambridge Center</street>
+ <city>Cambridge</city>
+ <region>MA</region>
+ <code>02138</code>
+ <country>USA</country>
+ </postal>
+ <email>Jim.Gettys@hp.com</email>
+ </address>
+ </author>
+
+ <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+ <organization abbrev="HP">Hewlett-Packard Company</organization>
+ <address>
+ <postal>
+ <street>HP Labs, Large Scale Systems Group</street>
+ <street>1501 Page Mill Road, MS 1177</street>
+ <city>Palo Alto</city>
+ <region>CA</region>
+ <code>94304</code>
+ <country>USA</country>
+ </postal>
+ <email>JeffMogul@acm.org</email>
+ </address>
+ </author>
+
+ <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ <country>USA</country>
+ </postal>
+ <email>henrikn@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
+ <address>
+ <postal>
+ <street>345 Park Ave</street>
+ <city>San Jose</city>
+ <region>CA</region>
+ <code>95110</code>
+ <country>USA</country>
+ </postal>
+ <email>LMM@acm.org</email>
+ <uri>http://larry.masinter.net/</uri>
+ </address>
+ </author>
+
+ <author initials="P." surname="Leach" fullname="Paul J. Leach">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ </postal>
+ <email>paulle@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city>
+ <region>MA</region>
+ <code>02139</code>
+ <country>USA</country>
+ </postal>
+ <facsimile>+1 (617) 258 8682</facsimile>
+ <email>timbl@w3.org</email>
+ </address>
+ </author>
+
+ <date month="November" year="2007"/>
+
+<abstract>
+<t>
+ The Hypertext Transfer Protocol (HTTP) is an application-level
+ protocol for distributed, collaborative, hypermedia information
+ systems. HTTP has been in use by the World Wide Web global information
+ initiative since 1990. This document is Part 7 of the eight-part specification
+ that defines the protocol referred to as "HTTP/1.1" and, taken together,
+ updates RFC 2616 and RFC 2617. Part 7 defines HTTP Authentication.
+</t>
+</abstract>
+</front>
+<middle>
+<section title="Introduction" anchor="introduction">
+<t>
+ This document will define aspects of HTTP related to access control and
+ authentication. Right now it only includes the extracted relevant sections
+ of <xref target="RFC2616">RFC 2616</xref> with only minor edits.
+</t>
+<t>
+ 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
+ general framework for access authentication, and the specification of
+ "basic" and "digest" authentication, are specified in "HTTP
+ Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. This
+ specification adopts the definitions of "challenge" and "credentials"
+ from that specification.
+</t>
+</section>
+<section title="Header Field Definitions" anchor="header.fields">
+<t>
+ This section defines the syntax and semantics of all standard
+ HTTP/1.1 header fields. For entity-header fields, both sender and
+ recipient refer to either the client or the server, depending on who
+ sends and who receives the entity.
+</t>
+
+<section title="Authorization" anchor="header.authorization">
+ <iref primary="true" item="Authorization header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Authorization" x:for-anchor=""/>
+<t>
+ A user agent that wishes to authenticate itself with a server--
+ usually, but not necessarily, after receiving a 401 response--does
+ so by including an Authorization request-header field with the
+ request. The Authorization field value consists of credentials
+ containing the authentication information of the user agent for
+ the realm of the resource being requested.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/>
+ Authorization = "Authorization" ":" credentials
+</artwork></figure>
+<t>
+ HTTP access authentication is described in "HTTP Authentication:
+ Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is
+ authenticated and a realm specified, the same credentials &SHOULD;
+ be valid for all other requests within this realm (assuming that
+ the authentication scheme itself does not require otherwise, such
+ as credentials that vary according to a challenge value or using
+ synchronized clocks).
+</t>
+<t>
+ When a shared cache (see &shared-and-non-shared-caches;) 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:
+</t>
+<t>
+ <list style="numbers">
+ <t>If the response includes the "s-maxage" cache-control
+ directive, the cache &MAY; use that response in replying to a
+ subsequent request. But (if the specified maximum age has
+ passed) a proxy cache &MUST; first revalidate it with the origin
+ server, using the request-headers from the new request to allow
+ the origin server to authenticate the new request. (This is the
+ defined behavior for s-maxage.) If the response includes "s-maxage=0",
+ the proxy &MUST; always revalidate it before re-using
+ it.</t>
+
+ <t>If the response includes the "must-revalidate" cache-control
+ directive, the cache &MAY; use that response in replying to a
+ subsequent request. But if the response is stale, all caches
+ &MUST; first revalidate it with the origin server, using the
+ request-headers from the new request to allow the origin server
+ to authenticate the new request.</t>
+
+ <t>If the response includes the "public" cache-control directive,
+ it &MAY; be returned in reply to any subsequent request.</t>
+ </list>
+</t>
+</section>
+
+<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
+ <iref primary="true" item="Proxy-Authenticate header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Proxy-Authenticate" x:for-anchor=""/>
+<t>
+ The Proxy-Authenticate response-header field &MUST; be included as part
+ of a 407 (Proxy Authentication Required) response. The field value
+ consists of a challenge that indicates the authentication scheme and
+ parameters applicable to the proxy for this Request-URI.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/>
+ Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
+</artwork></figure>
+<t>
+ The HTTP access authentication process is described in "HTTP
+ Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike
+ WWW-Authenticate, the Proxy-Authenticate header field applies only to
+ the current connection and &SHOULD-NOT; be passed on to downstream
+ clients. However, an intermediate proxy might need to obtain its own
+ credentials by requesting them from the downstream client, which in
+ some circumstances will appear as if the proxy is forwarding the
+ Proxy-Authenticate header field.
+</t>
+</section>
+
+<section title="Proxy-Authorization" anchor="header.proxy-authorization">
+ <iref primary="true" item="Proxy-Authorization header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Proxy-Authorization" x:for-anchor=""/>
+<t>
+ The Proxy-Authorization request-header field allows the client to
+ identify itself (or its user) to a proxy which requires
+ authentication. The Proxy-Authorization field value consists of
+ credentials containing the authentication information of the user
+ agent for the proxy and/or realm of the resource being requested.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/>
+ Proxy-Authorization = "Proxy-Authorization" ":" credentials
+</artwork></figure>
+<t>
+ The HTTP access authentication process is described in "HTTP
+ Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike
+ Authorization, the Proxy-Authorization header field applies only to
+ the next outbound proxy that demanded authentication using the Proxy-Authenticate
+ field. When multiple proxies are used in a chain, the
+ Proxy-Authorization header field is consumed by the first outbound
+ proxy that was expecting to receive credentials. A proxy &MAY; relay
+ the credentials from the client request to the next proxy if that is
+ the mechanism by which the proxies cooperatively authenticate a given
+ request.
+</t>
+</section>
+
+<section title="WWW-Authenticate" anchor="header.www-authenticate">
+ <iref primary="true" item="WWW-Authenticate header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="WWW-Authenticate" x:for-anchor=""/>
+<t>
+ The WWW-Authenticate response-header field &MUST; be included in 401
+ (Unauthorized) response messages. The field value consists of at
+ least one challenge that indicates the authentication scheme(s) and
+ parameters applicable to the Request-URI.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/>
+ WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
+</artwork></figure>
+<t>
+ The HTTP access authentication process is described in "HTTP
+ Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. User
+ agents are advised to take special care in parsing the WWW-Authenticate
+ field value as it might contain more than one challenge,
+ or if more than one WWW-Authenticate header field is provided, the
+ contents of a challenge itself can contain a comma-separated list of
+ authentication parameters.
+</t>
+</section>
+
+</section>
+
+<section title="IANA Considerations" anchor="IANA.considerations">
+<t>
+ TBD.
+</t>
+</section>
+
+<section title="Security Considerations" anchor="security.considerations">
+<t>
+ This section is meant to inform application developers, information
+ providers, and users of the security limitations in HTTP/1.1 as
+ described by this document. The discussion does not include
+ definitive solutions to the problems revealed, though it does make
+ some suggestions for reducing security risks.
+</t>
+
+<section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
+<t>
+ Existing HTTP clients and user agents typically retain authentication
+ information indefinitely. HTTP/1.1. does not provide a method for a
+ server to direct clients to discard these cached credentials. This is
+ a significant defect that requires further extensions to HTTP.
+ Circumstances under which credential caching can interfere with the
+ application's security model include but are not limited to:
+ <list style="symbols">
+ <t>Clients which have been idle for an extended period following
+ which the server might wish to cause the client to reprompt the
+ user for credentials.</t>
+
+ <t>Applications which include a session termination indication
+ (such as a `logout' or `commit' button on a page) after which
+ the server side of the application `knows' that there is no
+ further reason for the client to retain the credentials.</t>
+ </list>
+</t>
+<t>
+ This is currently under separate study. There are a number of work-arounds
+ to parts of this problem, and we encourage the use of
+ password protection in screen savers, idle time-outs, and other
+ methods which mitigate the security problems inherent in this
+ problem. In particular, user agents which cache credentials are
+ encouraged to provide a readily accessible mechanism for discarding
+ cached credentials under user control.
+</t>
+</section>
+</section>
+
+<section title="Acknowledgments" anchor="ack">
+<t>
+ Based on an XML translation of RFC 2616 by Julian Reschke.
+</t>
+</section>
+</middle>
+<back>
+<references>
+<reference anchor="RFC2616">
+ <front>
+ <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
+ <author initials="R." surname="Fielding" fullname="R. Fielding">
+ <organization>University of California, Irvine</organization>
+ <address><email>fielding@ics.uci.edu</email></address>
+ </author>
+ <author initials="J." surname="Gettys" fullname="J. Gettys">
+ <organization>W3C</organization>
+ <address><email>jg@w3.org</email></address>
+ </author>
+ <author initials="J." surname="Mogul" fullname="J. Mogul">
+ <organization>Compaq Computer Corporation</organization>
+ <address><email>mogul@wrl.dec.com</email></address>
+ </author>
+ <author initials="H." surname="Frystyk" fullname="H. Frystyk">
+ <organization>MIT Laboratory for Computer Science</organization>
+ <address><email>frystyk@w3.org</email></address>
+ </author>
+ <author initials="L." surname="Masinter" fullname="L. Masinter">
+ <organization>Xerox Corporation</organization>
+ <address><email>masinter@parc.xerox.com</email></address>
+ </author>
+ <author initials="P." surname="Leach" fullname="P. Leach">
+ <organization>Microsoft Corporation</organization>
+ <address><email>paulle@microsoft.com</email></address>
+ </author>
+ <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
+ <organization>W3C</organization>
+ <address><email>timbl@w3.org</email></address>
+ </author>
+ <date month="June" year="1999"/>
+ </front>
+ <seriesInfo name="RFC" value="2616"/>
+</reference>
+
+<reference anchor="RFC2617">
+<front>
+<title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
+<author initials="J." surname="Franks" fullname="John Franks">
+<organization>Northwestern University, Department of Mathematics</organization>
+<address>
+<postal>
+<street/>
+<city>Evanston</city>
+<region>IL</region>
+<code>60208-2730</code>
+<country>US</country></postal>
+<email>john@math.nwu.edu</email></address></author>
+<author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
+<organization>Verisign Inc.</organization>
+<address>
+<postal>
+<street>301 Edgewater Place</street>
+<street>Suite 210</street>
+<city>Wakefield</city>
+<region>MA</region>
+<code>01880</code>
+<country>US</country></postal>
+<email>pbaker@verisign.com</email></address></author>
+<author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
+<organization>AbiSource, Inc.</organization>
+<address>
+<postal>
+<street>6 Dunlap Court</street>
+<city>Savoy</city>
+<region>IL</region>
+<code>61874</code>
+<country>US</country></postal>
+<email>jeff@AbiSource.com</email></address></author>
+<author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
+<organization>Agranat Systems, Inc.</organization>
+<address>
+<postal>
+<street>5 Clocktower Place</street>
+<street>Suite 400</street>
+<city>Maynard</city>
+<region>MA</region>
+<code>01754</code>
+<country>US</country></postal>
+<email>lawrence@agranat.com</email></address></author>
+<author initials="P.J." surname="Leach" fullname="Paul J. Leach">
+<organization>Microsoft Corporation</organization>
+<address>
+<postal>
+<street>1 Microsoft Way</street>
+<city>Redmond</city>
+<region>WA</region>
+<code>98052</code>
+<country>US</country></postal>
+<email>paulle@microsoft.com</email></address></author>
+<author initials="A." surname="Luotonen" fullname="Ari Luotonen">
+<organization>Netscape Communications Corporation</organization>
+<address>
+<postal>
+<street>501 East Middlefield Road</street>
+<city>Mountain View</city>
+<region>CA</region>
+<code>94043</code>
+<country>US</country></postal></address></author>
+<author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
+<organization>Open Market, Inc.</organization>
+<address>
+<postal>
+<street>215 First Street</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02142</code>
+<country>US</country></postal>
+<email>stewart@OpenMarket.com</email></address></author>
+<date month="June" year="1999"/>
+</front>
+<seriesInfo name="RFC" value="2617"/>
+</reference>
+</references>
+</back>
+</rfc>
Propchange: labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p7-auth-00.xml
------------------------------------------------------------------------------
svn:eol-style = native
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org