Internet Engineering Task Force (IETF) S. Winter
Request for Comments: 7057 RESTENA
Updates: 3748 J. Salowey
Category: Standards Track Cisco
ISSN: 2070-1721 December 2013
Internet Engineering Task Force (IETF) S. Winter
Request for Comments: 7057 RESTENA
Updates: 3748 J. Salowey
Category: Standards Track Cisco
ISSN: 2070-1721 December 2013
Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)
更新可扩展身份验证协议（EAP）适用性声明，用于Web之外联邦访问的应用程序桥接（ABFAB）
Abstract
摘要
This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture.
本文档更新了RFC 3748中的可扩展身份验证协议（EAP）适用性声明，以反映EAP协议在web之外的联邦访问应用程序桥接（ABFAB）体系结构中的最新使用情况。
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/rfc7057.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7057.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Uses of EAP for Application-Layer Access ........................2
2.1. Retransmission .............................................4
2.2. Re-authentication ..........................................5
3. Revised EAP Applicability Statement .............................5
4. Security Considerations .........................................6
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Uses of EAP for Application-Layer Access ........................2
2.1. Retransmission .............................................4
2.2. Re-authentication ..........................................5
3. Revised EAP Applicability Statement .............................5
4. Security Considerations .........................................6
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
The EAP applicability statement in [RFC3748] defines the scope of the Extensible Authentication Protocol to be "for use in network access authentication, where IP layer connectivity may not be available", and states that "Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED".
[RFC3748]中的EAP适用性声明将可扩展认证协议的范围定义为“用于网络访问认证，其中IP层连接可能不可用”，并声明“不建议将EAP用于其他目的，如批量数据传输”。
While some of the reasons for the recommendation against usage of EAP for bulk data transport are still valid, some of the other provisions in the applicability statement have turned out to be too narrow. Section 2 describes the example where EAP is used to authenticate application-layer access. Section 3 provides new text to update Section 1.3., "Applicability", in [RFC3748].
虽然建议禁止在批量数据传输中使用EAP的一些原因仍然有效，但适用性声明中的其他一些条款被证明过于狭窄。第2节描述了EAP用于验证应用层访问的示例。第3节提供了更新[RFC3748]第1.3节“适用性”的新文本。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
在本文件中，使用了几个词来表示规范的要求。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Ongoing work in the IETF specifies the use of EAP over Generic Security Service Application Program Interface (GSS-API) for generic application layer access [RFC7055]. In the past, using EAP in this context has met resistance due to the lack of channel bindings [RFC6677]. Without channel bindings, a peer cannot verify if an authenticator is authorized to provide an advertised service.
IETF中正在进行的工作规定了在通用安全服务应用程序接口（GSS-API）上使用EAP进行通用应用层访问[RFC7055]。在过去，由于缺少通道绑定，在这种上下文中使用EAP遇到了阻力[RFC6677]。没有通道绑定，对等方无法验证验证器是否有权提供播发服务。
However, as additional services use EAP for authentication, the distinction of which service is being contacted becomes more important. Application services might have different properties. Consider an environment with multiple printers, some of which provide a confidential service to output documents to a controlled location. If a peer sent a document to the wrong service, then potentially sensitive information might be printed in an uncontrolled location and be disclosed. In addition, it might be more likely that a low-value service is compromised than some high-value service. If the high-value service could be impersonated by a low-value service then the security of the overall system would be limited by the security of the lower-value service.
然而，随着附加服务使用EAP进行身份验证，联系哪个服务的区别变得更加重要。应用程序服务可能具有不同的属性。考虑一个具有多个打印机的环境，其中一些提供机密服务，将文档输出到受控位置。如果对等方将文档发送到错误的服务，那么潜在的敏感信息可能会打印在不受控制的位置并被披露。此外，与某些高价值服务相比，低价值服务可能更容易受到损害。如果高值服务可以由低值服务模拟，那么整个系统的安全性将受到低值服务安全性的限制。
This distinction is present in any environment where peers' security depends on which service they reach. However, it is particularly acute in a federated environment where multiple organizations are involved. It is very likely that these organizations will have different security policies and practices. It is very likely that the goals of these organizations will not entirely be aligned. In many situations, one organization could gain value by being able to impersonate another. In this environment, authenticating the EAP server is insufficient: the peer must also validate that the contacted host is authorized to provide the requested service.
这种区别在任何环境中都存在，在这种环境中，对等点的安全性取决于它们到达的服务。然而，在涉及多个组织的联合环境中，这一点尤为突出。这些组织很可能有不同的安全策略和做法。这些组织的目标很可能不会完全一致。在许多情况下，一个组织可以通过模仿另一个组织来获得价值。在此环境中，对EAP服务器进行身份验证是不够的：对等方还必须验证所联系的主机是否有权提供请求的服务。
In environments where EAP is used for purposes other than network access authentication:
在EAP用于网络访问身份验证以外目的的环境中：
o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings.
o 所有EAP服务器和所有应用程序访问EAP对等方必须支持通道绑定。所有网络访问EAP对等方都应支持通道绑定。
o Channel binding MUST be used for all application authentication. The EAP server MUST require that either the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication.
o 通道绑定必须用于所有应用程序身份验证。EAP服务器必须要求应用程序身份验证的通道绑定数据中存在正确的EAP下层属性或指示身份验证目的的另一个属性。
o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication.
o 通道绑定应用于所有网络访问身份验证，当存在通道绑定数据时，EAP服务器必须要求其包含正确的EAP下层属性，以明确标识身份验证的原因。
o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage.
o EAP的任何新用法都必须使用通道绑定，包括EAP lower layer属性，以防止与网络访问用法混淆。
Operators need to carefully consider the security implications before relaxing these requirements. One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing service other than network access. A device can be created that impersonates a Network Access Service (NAS) to peers, but actually proxies the authentication to the new application service that accepts EAP authentications. This may decrease the security of this service even for users who previously used non-EAP means of authentication to the service.
在放松这些需求之前，运营商需要仔细考虑安全问题。当不需要通道绑定，并且将EAP身份验证引入网络访问以外的现有服务时，存在一种潜在的严重攻击。可以创建一个设备，向对等方模拟网络访问服务（NAS），但实际上将身份验证代理给接受EAP身份验证的新应用程序服务。这可能会降低此服务的安全性，即使对于以前使用非EAP身份验证方式的用户也是如此。
It is REQUIRED for the application layer to prove that both the EAP peer and EAP authenticator possess the EAP Master Session Key (MSK). Failing to validate the possession of the EAP MSK can allow an attacker to insert himself into the conversation and impersonate the peer or authenticator. In addition, the application should define channel binding attributes that are sufficient to validate that the application service is being correctly represented to the peer.
应用层需要证明EAP对等方和EAP验证器都拥有EAP主会话密钥（MSK）。如果无法验证EAP MSK的拥有权，攻击者可以将自己插入对话并模拟对等方或身份验证者。此外，应用程序应该定义通道绑定属性，这些属性足以验证应用程序服务是否正确地表示给对等方。
In EAP, the authenticator is responsible for retransmission. By default, EAP assumes that the lower layer (the application in this context) is unreliable. The authenticator can send a packet whenever its retransmission timer triggers. In this mode, applications need to be able to receive and process EAP messages at any time during the authentication conversation.
在EAP中，认证者负责重传。默认情况下，EAP假定较低层（此上下文中的应用程序）不可靠。认证器可以在其重传计时器触发时发送数据包。在此模式下，应用程序需要能够在身份验证对话期间的任何时间接收和处理EAP消息。
Alternatively, EAP permits a lower layer to set the retransmission timer to infinite. When this happens, the lower layer becomes responsible for reliable delivery of EAP messages. Applications that use a lock-step or client-driven authentication protocol might benefit from this approach.
或者，EAP允许较低层将重传定时器设置为无限。当这种情况发生时，下层负责EAP消息的可靠传递。使用锁定步骤或客户端驱动的身份验证协议的应用程序可能会从这种方法中受益。
In addition to retransmission behavior, applications need to deal with discarded EAP messages. For example, whenever some EAP methods receive erroneous input, these methods discard the input rather than generating an error response. If the erroneous input was generated by an attacker, legitimate input can sometimes be received after the erroneous input. Applications MUST handle discarded EAP messages, although the specific way in which discarded messages will be handled depends on the characteristics of the application. Options include failing the authentication at the application level, requesting an EAP retransmit and waiting for additional EAP input.
除了重传行为，应用程序还需要处理丢弃的EAP消息。例如，每当某些EAP方法接收到错误的输入时，这些方法就会丢弃输入，而不是生成错误响应。如果错误输入是由攻击者生成的，则有时会在错误输入之后接收到合法输入。应用程序必须处理丢弃的EAP消息，尽管处理丢弃消息的具体方式取决于应用程序的特性。选项包括在应用程序级别验证失败、请求EAP重新传输和等待其他EAP输入。
Applications designers that incorporate EAP into their application need to determine how retransmission and message discards are handled.
将EAP纳入其应用程序的应用程序设计者需要确定如何处理重传和消息丢弃。
EAP lower layers MAY provide a mechanism for re-authentication to happen within an existing session [RFC3748]. Re-authentication permits security associations to be updated without establishing a new session. For network access, this can be important because interrupting network access can disrupt connections and media.
EAP较低层可提供一种机制，用于在现有会话中进行重新认证[RFC3748]。重新身份验证允许在不建立新会话的情况下更新安全关联。对于网络访问，这可能很重要，因为中断网络访问会中断连接和媒体。
Some applications might not need re-authentication support. For example, if sessions are relatively short-lived or if sessions can be replaced without significant disruption, re-authentication might not provide value. Protocols like HyperText Transfer Protocol (HTTP) [RFC2616] and Simple Mail Transport Protocol (SMTP) [RFC5321] are examples of protocols where establishing a new connection to update security associations is likely to be sufficient.
某些应用程序可能不需要重新身份验证支持。例如，如果会话相对较短，或者如果会话可以在不造成重大中断的情况下被替换，则重新身份验证可能不会提供价值。超文本传输协议（HTTP）[RFC2616]和简单邮件传输协议（SMTP）[RFC5321]等协议是建立新连接以更新安全关联可能就足够的协议示例。
Re-authentication is likely to be valuable if sessions or connections are long-lived or if there is a significant cost to disrupting them.
如果会话或连接是长期存在的，或者如果中断会话或连接的成本很高，则重新身份验证可能很有价值。
Another factor may make re-authentication important. Some protocols only permit one party in a protocol (for example, the client) to establish a new connection. If another party in the protocol needs the security association refreshed, then re-authentication can provide a mechanism to do so.
另一个因素可能使重新认证变得重要。某些协议只允许协议中的一方（例如，客户端）建立新连接。如果协议中的另一方需要刷新安全关联，那么重新身份验证可以提供这样做的机制。
Application designers need to determine whether re-authentication support is needed and which parties can initiate it.
应用程序设计人员需要确定是否需要重新身份验证支持，以及哪些方可以发起重新身份验证。
The following text is appended to the EAP applicability statement in [RFC3748].
以下文本附在[RFC3748]中的EAP适用性声明之后。
In cases where EAP is used for application authentication, support for EAP channel bindings is REQUIRED on the EAP peer and EAP server to validate that the host is authorized to provide the services requested. In addition, the application MUST define channel binding attributes that are sufficient to validate that the application service is being correctly represented to the peer. The protocol carrying EAP MUST prove possession of the EAP MSK between the EAP peer and EAP authenticator. In the context of EAP for application access the application is providing the EAP lower layer. Applications protocols vary so their specific behavior and transport characteristics needs to be considered when determining their retransmission and re-authentication behavior. Circumstances might require that applications need to perform conversion of identities from an application specific character set to UTF-8 or another
在EAP用于应用程序身份验证的情况下，需要在EAP对等方和EAP服务器上支持EAP通道绑定，以验证主机是否有权提供请求的服务。此外，应用程序必须定义通道绑定属性，这些属性足以验证应用程序服务是否正确地表示给对等方。承载EAP的协议必须证明在EAP对等方和EAP验证器之间拥有EAP MSK。在应用程序访问的EAP上下文中，应用程序提供EAP底层。应用程序协议各不相同，因此在确定它们的重传和重新身份验证行为时，需要考虑它们的特定行为和传输特性。环境可能要求应用程序需要执行从特定于应用程序的字符集到UTF-8或其他字符集的身份转换
character set required by a particular EAP method. See also [RADEXT-NAI], Section 2.6, for information about normalization of identifiers.
特定EAP方法所需的字符集。有关标识符标准化的信息，另请参见[RADEXT-NAI]，第2.6节。
In addition to the requirements discussed in the main sections of the document, applications should take into account how server authentication is achieved. Some deployments may allow for weak server authentication that is then validated with an additional existing exchange that provides mutual authentication. In order to fully mitigate the risk of NAS impersonation when these mechanisms are used, it is RECOMMENDED that mutual channel bindings be used to bind the authentications together as described in [RFC7029]. When doing channel binding it is REQUIRED that the authenticator is not able to modify the channel binding data passed between the peer to the authenticator as part of the authentication process.
除了本文档主要章节中讨论的要求外，应用程序还应考虑如何实现服务器身份验证。某些部署可能允许弱服务器身份验证，然后使用提供相互身份验证的其他现有exchange进行验证。为了在使用这些机制时完全降低NAS模拟的风险，建议使用交互通道绑定将身份验证绑定在一起，如[RFC7029]中所述。进行通道绑定时，要求身份验证程序不能修改对等方与身份验证程序之间传递的通道绑定数据，这是身份验证过程的一部分。
Large amounts of helpful text and insightful thoughts were contributed by Sam Hartman, Painless Security. David Black contributed to the text clarifying channel bindings usage.
Sam Hartman，《无痛安全》提供了大量有用的文本和深刻的想法。DavidBlack对澄清通道绑定使用的文本做出了贡献。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
[RFC6677]Hartman，S.，Clancy，T.，和K.Hoeper，“可扩展身份验证协议（EAP）方法的通道绑定支持”，RFC 6677，2012年7月。
[RADEXT-NAI] DeKok, A., "The Network Access Identifier", Work in Progress, November 2013.
[RADEXT-NAI]DeKok，A.，“网络访问标识符”，正在进行的工作，2013年11月。
[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.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding", RFC 7029, October 2013.
[RFC7029]Hartman，S.，Wasserman，M.，和D.Zhang，“可扩展认证协议（EAP）相互加密绑定”，RFC 70292013年10月。
[RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", RFC 7055, December 2013.
[RFC7055]Hartman，S.，Ed.和J.Howlett，“可扩展身份验证协议的GSS-API机制”，RFC 7055，2013年12月。
Authors' Addresses
作者地址
Stefan Winter Fondation RESTENA 6, rue Richard Coudenhove-Kalergi Luxembourg 1359 LUXEMBOURG
卢森堡里查德·库登霍夫·卡勒吉街Stefan Winter Foundation RESTENA 6号卢森堡1359
Phone: +352 424409 1 Fax: +352 422473 EMail: stefan.winter@restena.lu URI: http://www.restena.lu.
电话：+352 424409 1传真：+352 422473电子邮件：stefan。winter@restena.luURI:http://www.restena.lu.
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, Washington 98121 USA
美国华盛顿州西雅图第三大道2901号Joseph Salowey Cisco Systems 98121
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com