Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 7615 greenbytes
Obsoletes: 2617 September 2015
Category: Standards Track
ISSN: 2070-1721
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
HTTP身份验证信息和代理身份验证信息响应头字段
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.
本规范定义了“身份验证信息”和“代理身份验证信息”响应头字段，用于超文本传输协议（HTTP）身份验证方案，一旦接受客户端的身份验证凭据，这些方案就需要返回信息。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7615.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
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
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
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.
此规范定义了HTTP身份验证方案（[RFC7235]）中使用的“身份验证信息”和“代理身份验证信息”响应头字段，一旦接受客户端的身份验证凭据，这些方案就需要返回信息。
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.
之前在[RFC2617]的第3节中定义了这两种方法，定义了HTTP“摘要”身份验证方案。本文档概括了该描述，不仅可用于“摘要”（[RFC7616]），也可用于其他未来方案中，这些方案可能对在身份验证期间携带附加信息有相同的要求。
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].
本规范使用[RFC7230]第7节中定义的[RFC5234]的增广巴科斯-诺尔形式（ABNF）符号和列表扩展，允许使用“#”运算符（类似于“*”运算符表示重复）对逗号分隔的列表进行紧凑定义。[RFC7235]第2.1节定义了ABNF生成的“auth param”。
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).
HTTP身份验证方案可以在接受客户端的身份验证凭据后使用身份验证信息响应头字段来传递信息。此信息可以包括来自服务器的最终确定消息（例如，它可以包含服务器身份验证）。
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].
字段值是参数列表（名称/值对），使用[RFC7235]第2.1节中定义的“auth param”语法。本规范仅描述通用格式；使用身份验证信息的身份验证方案将定义各个参数。例如，“摘要”认证方案在[RFC7616]第3.5节中定义了多个参数。
Authentication-Info = #auth-param
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.
Authentication Info header字段可以在任何HTTP响应中使用，与请求方法和状态代码无关。其语义由相应请求的授权标头字段（[RFC7235]，第4.2节）指示的身份验证方案定义。
A proxy forwarding a response is not allowed to modify the field value in any way.
不允许转发响应的代理以任何方式修改字段值。
Authentication-Info can be used inside trailers ([RFC7230], Section 4.1.2) when the authentication scheme explicitly allows this.
当认证方案明确允许时，可在拖车内使用认证信息（[RFC7230]，第4.1.2节）。
Parameter values can be expressed either as "token" or as "quoted-string" (Section 3.2.6 of [RFC7230]).
参数值可以表示为“标记”或“带引号的字符串”（[RFC7230]第3.2.6节）。
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.
为了向后兼容，身份验证方案定义可以将发件人的格式限制为两种变体之一。当已知部署的实现在遇到两种格式之一时会失败时，这一点非常重要。
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:
代理身份验证信息响应头字段等同于身份验证信息，但它适用于代理身份验证（[RFC7235]，第2节），其语义由相应请求的代理授权头字段（[RFC7235]，第4.4节）指示的身份验证方案定义：
Proxy-Authentication-Info = #auth-param
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.
但是，与身份验证信息不同，代理身份验证信息头字段仅适用于响应链上的下一个出站客户端。这是因为只有选择了给定代理的客户端才可能具有身份验证所需的凭据。但是，当在同一管理域中使用多个代理时，例如大型公司网络中的办公室和区域缓存代理，通常由用户代理生成凭据并通过层次结构传递，直到使用为止。因此，在这样的配置中，由于每个代理都将发送相同的字段值，因此看起来好像正在转发代理身份验证信息。
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.
向通过未加密通道发送的HTTP响应添加信息可能会影响安全性和隐私。仅头字段的存在就表明正在使用HTTP身份验证。附加信息可通过认证方案特定参数的内容公开；在这些方案的定义中必须考虑到这一点。
HTTP header fields are registered within the "Message Headers" registry located at <http://www.iana.org/assignments/ message-headers>, as defined by [BCP90].
HTTP头字段在位于的“消息头”注册表中注册<http://www.iana.org/assignments/ 消息头>，由[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 |
+---------------------------+----------+----------+-----------------+
+---------------------------+----------+----------+-----------------+
| 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 |
+---------------------------+----------+----------+-----------------+
[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>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<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>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<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>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[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>.
[BCP90]Klyne，G.，Nottingham，M.，和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月<http://www.rfc-editor.org/info/bcp90>.
[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>.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 2617，DOI 10.17487/RFC2617，1999年6月<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>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<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.
本文档基于RFCs 2069和2617中的标题字段定义，其作者为：John Franks、Phillip M.Hallam Baker、Jeffery L.Hostetler、Scott D.Lawrence、Paul J.Leach、Ari Luotonen、Eric W.Sink和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.
还要感谢HTTPAUTH和HTTPBIS工作组的成员，即阿莫斯·杰弗里斯、本杰明·卡杜克、阿列克谢·梅尔尼科夫、马克·诺丁汉、尤塔卡·奥瓦、里法特·谢赫·尤塞夫和马丁·汤姆森。
Author's Address
作者地址
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/