doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc7615.txt b/doc/rfc/rfc7615.txt
new file mode 100644
index 0000000..701a15b
--- /dev/null
+++ b/doc/rfc/rfc7615.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Reschke
+Request for Comments: 7615                                    greenbytes
+Obsoletes: 2617                                           September 2015
+Category: Standards Track
+ISSN: 2070-1721
+
+
+         HTTP Authentication-Info and Proxy-Authentication-Info
+                         Response Header Fields
+
+Abstract
+
+   This specification defines the "Authentication-Info" and "Proxy-
+   Authentication-Info" response header fields for use in Hypertext
+   Transfer Protocol (HTTP) authentication schemes that need to return
+   information once the client's authentication credentials have been
+   accepted.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7615.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reschke                      Standards Track                    [Page 1]
+
+RFC 7615                HTTP Authentication-Info          September 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   3
+   3.  The Authentication-Info Response Header Field . . . . . . . .   3
+     3.1.  Parameter Value Format  . . . . . . . . . . . . . . . . .   4
+   4.  The Proxy-Authentication-Info Response Header Field . . . . .   4
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6
+
+
+
+
+
+
+
+
+
+
+Reschke                      Standards Track                    [Page 2]
+
+RFC 7615                HTTP Authentication-Info          September 2015
+
+
+1.  Introduction
+
+   This specification defines the "Authentication-Info" and "Proxy-
+   Authentication-Info" response header fields for use in HTTP
+   authentication schemes ([RFC7235]) that need to return information
+   once the client's authentication credentials have been accepted.
+
+   Both were previously defined in Section 3 of [RFC2617], defining the
+   HTTP "Digest" authentication scheme.  This document generalizes the
+   description for use not only in "Digest" ([RFC7616]), but also in
+   other future schemes that might have the same requirements for
+   carrying additional information during authentication.
+
+2.  Notational Conventions
+
+   This specification uses the Augmented Backus-Naur Form (ABNF)
+   notation of [RFC5234] with a list extension, defined in Section 7 of
+   [RFC7230], that allows for compact definition of comma-separated
+   lists using a '#' operator (similar to how the '*' operator indicates
+   repetition).  The ABNF production for "auth-param" is defined in
+   Section 2.1 of [RFC7235].
+
+3.  The Authentication-Info Response Header Field
+
+   HTTP authentication schemes can use the Authentication-Info response
+   header field to communicate information after the client's
+   authentication credentials have been accepted.  This information can
+   include a finalization message from the server (e.g., it can contain
+   the server authentication).
+
+   The field value is a list of parameters (name/value pairs), using the
+   "auth-param" syntax defined in Section 2.1 of [RFC7235].  This
+   specification only describes the generic format; authentication
+   schemes using Authentication-Info will define the individual
+   parameters.  The "Digest" Authentication Scheme, for instance,
+   defines multiple parameters in Section 3.5 of [RFC7616].
+
+     Authentication-Info = #auth-param
+
+   The Authentication-Info header field can be used in any HTTP
+   response, independently of request method and status code.  Its
+   semantics are defined by the authentication scheme indicated by the
+   Authorization header field ([RFC7235], Section 4.2) of the
+   corresponding request.
+
+   A proxy forwarding a response is not allowed to modify the field
+   value in any way.
+
+
+
+
+Reschke                      Standards Track                    [Page 3]
+
+RFC 7615                HTTP Authentication-Info          September 2015
+
+
+   Authentication-Info can be used inside trailers ([RFC7230],
+   Section 4.1.2) when the authentication scheme explicitly allows this.
+
+3.1.  Parameter Value Format
+
+   Parameter values can be expressed either as "token" or as "quoted-
+   string" (Section 3.2.6 of [RFC7230]).
+
+   Authentication scheme definitions need to allow both notations, both
+   for senders and recipients.  This allows recipients to use generic
+   parsing components, independent of the authentication scheme in use.
+
+   For backwards compatibility, authentication scheme definitions can
+   restrict the format for senders to one of the two variants.  This can
+   be important when it is known that deployed implementations will fail
+   when encountering one of the two formats.
+
+4.  The Proxy-Authentication-Info Response Header Field
+
+   The Proxy-Authentication-Info response header field is equivalent to
+   Authentication-Info, except that it applies to proxy authentication
+   ([RFC7235], Section 2) and its semantics are defined by the
+   authentication scheme indicated by the Proxy-Authorization header
+   field ([RFC7235], Section 4.4) of the corresponding request:
+
+     Proxy-Authentication-Info = #auth-param
+
+   However, unlike Authentication-Info, the Proxy-Authentication-Info
+   header field applies only to the next outbound client on the response
+   chain.  This is because only the client that chose a given proxy is
+   likely to have the credentials necessary for authentication.
+   However, when multiple proxies are used within the same
+   administrative domain, such as office and regional caching proxies
+   within a large corporate network, it is common for credentials to be
+   generated by the user agent and passed through the hierarchy until
+   consumed.  Hence, in such a configuration, it will appear as if
+   Proxy-Authentication-Info is being forwarded because each proxy will
+   send the same field value.
+
+5.  Security Considerations
+
+   Adding information to HTTP responses that are sent over an
+   unencrypted channel can affect security and privacy.  The presence of
+   the header fields alone indicates that HTTP authentication is in use.
+   Additional information could be exposed by the contents of the
+   authentication-scheme specific parameters; this will have to be
+   considered in the definitions of these schemes.
+
+
+
+
+Reschke                      Standards Track                    [Page 4]
+
+RFC 7615                HTTP Authentication-Info          September 2015
+
+
+6.  IANA Considerations
+
+   HTTP header fields are registered within the "Message Headers"
+   registry located at <http://www.iana.org/assignments/
+   message-headers>, as defined by [BCP90].
+
+   This document updates the definitions of the "Authentication-Info"
+   and "Proxy-Authentication-Info" header fields, so the "Permanent
+   Message Header Field Names" registry has been updated accordingly:
+
+   +---------------------------+----------+----------+-----------------+
+   | Header Field Name         | Protocol | Status   | Reference       |
+   +---------------------------+----------+----------+-----------------+
+   | Authentication-Info       | http     | standard | Section 3 of    |
+   |                           |          |          | this document   |
+   | Proxy-Authentication-Info | http     | standard | Section 4 of    |
+   |                           |          |          | this document   |
+   +---------------------------+----------+----------+-----------------+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <http://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Authentication", RFC 7235,
+              DOI 10.17487/RFC7235, June 2014,
+              <http://www.rfc-editor.org/info/rfc7235>.
+
+7.2.  Informative References
+
+   [BCP90]    Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              September 2004, <http://www.rfc-editor.org/info/bcp90>.
+
+
+
+
+
+
+
+
+Reschke                      Standards Track                    [Page 5]
+
+RFC 7615                HTTP Authentication-Info          September 2015
+
+
+   [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, DOI 10.17487/RFC2617, June 1999,
+              <http://www.rfc-editor.org/info/rfc2617>.
+
+   [RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
+              Digest Access Authentication", RFC 7616,
+              DOI 10.17487/RFC7616, September 2015,
+              <http://www.rfc-editor.org/info/rfc7616>.
+
+Acknowledgements
+
+   This document is based on the header field definitions in RFCs 2069
+   and 2617, whose authors are: John Franks, Phillip M. Hallam-Baker,
+   Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen,
+   Eric W. Sink, and Lawrence C. Stewart.
+
+   Additional thanks go to the members of the HTTPAUTH and HTTPBIS
+   Working Groups, namely, Amos Jeffries, Benjamin Kaduk, Alexey
+   Melnikov, Mark Nottingham, Yutaka Oiwa, Rifaat Shekh-Yusef, and
+   Martin Thomson.
+
+Author's Address
+
+   Julian F. Reschke
+   greenbytes GmbH
+   Hafenweg 16
+   Muenster, NW  48155
+   Germany
+
+   Email: julian.reschke@greenbytes.de
+   URI:   http://greenbytes.de/tech/webdav/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reschke                      Standards Track                    [Page 6]
+