Internet Engineering Task Force (IETF) S. Hartman, Ed.
Request for Comments: 7055 Painless Security
Category: Standards Track J. Howlett
ISSN: 2070-1721 JANET(UK)
December 2013
Internet Engineering Task Force (IETF) S. Hartman, Ed.
Request for Comments: 7055 Painless Security
Category: Standards Track J. Howlett
ISSN: 2070-1721 JANET(UK)
December 2013
A GSS-API Mechanism for the Extensible Authentication Protocol
可扩展认证协议的GSS-API机制
Abstract
摘要
This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol.
本文档定义了当使用可扩展身份验证协议机制时，实现通用安全服务应用程序接口（GSS-API）的对等方将采用的协议、过程和约定。通过RFC 5801中定义的GS2系列机制，这些协议还定义了简单身份验证和安全层（SASL）应用程序如何使用可扩展身份验证协议。
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/rfc7055.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7055.
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 ....................................................3
1.1. Discovery ..................................................4
1.2. Authentication .............................................4
1.3. Secure Association Protocol ................................6
2. Requirements Notation ...........................................6
3. EAP Channel Binding and Naming ..................................6
3.1. Mechanism Name Format ......................................7
3.2. Internationalization of Names .............................10
3.3. Exported Mechanism Names ..................................10
3.4. Acceptor Name RADIUS AVP ..................................11
3.5. Proxy Verification of Acceptor Name .......................11
4. Selection of EAP Method ........................................12
5. Context Tokens .................................................13
5.1. Mechanisms and Encryption Types ...........................14
5.2. Processing Received Tokens ................................15
5.3. Error Subtokens ...........................................16
5.4. Initial State .............................................16
5.4.1. Vendor Subtoken ....................................17
5.4.2. Acceptor Name Request ..............................17
5.4.3. Acceptor Name Response .............................18
5.5. Authenticate State ........................................18
5.5.1. EAP Request Subtoken ...............................19
5.5.2. EAP Response Subtoken ..............................19
5.6. Extensions State ..........................................20
5.6.1. Flags Subtoken .....................................20
5.6.2. GSS Channel Bindings Subtoken ......................20
5.6.3. MIC Subtoken .......................................21
5.7. Example Token .............................................22
5.8. Context Options ...........................................23
6. Acceptor Services ..............................................23
6.1. GSS-API Channel Binding ...................................24
6.2. Per-Message Security ......................................24
6.3. Pseudorandom Function .....................................24
7. IANA Considerations ............................................25
7.1. OID Registry ..............................................25
7.2. RFC 4121 Token Identifiers ................................26
7.3. GSS-EAP Subtoken Types ....................................26
7.4. RADIUS Attribute Assignments ..............................27
7.5. Registration of the EAP-AES128 SASL Mechanisms ............28
7.6. GSS-EAP Errors ............................................28
7.7. GSS-EAP Context Flags .....................................30
8. Security Considerations ........................................30
9. Acknowledgements ...............................................32
10. References ....................................................32
Appendix A. Pre-publication RADIUS VSA ............................33
1. Introduction ....................................................3
1.1. Discovery ..................................................4
1.2. Authentication .............................................4
1.3. Secure Association Protocol ................................6
2. Requirements Notation ...........................................6
3. EAP Channel Binding and Naming ..................................6
3.1. Mechanism Name Format ......................................7
3.2. Internationalization of Names .............................10
3.3. Exported Mechanism Names ..................................10
3.4. Acceptor Name RADIUS AVP ..................................11
3.5. Proxy Verification of Acceptor Name .......................11
4. Selection of EAP Method ........................................12
5. Context Tokens .................................................13
5.1. Mechanisms and Encryption Types ...........................14
5.2. Processing Received Tokens ................................15
5.3. Error Subtokens ...........................................16
5.4. Initial State .............................................16
5.4.1. Vendor Subtoken ....................................17
5.4.2. Acceptor Name Request ..............................17
5.4.3. Acceptor Name Response .............................18
5.5. Authenticate State ........................................18
5.5.1. EAP Request Subtoken ...............................19
5.5.2. EAP Response Subtoken ..............................19
5.6. Extensions State ..........................................20
5.6.1. Flags Subtoken .....................................20
5.6.2. GSS Channel Bindings Subtoken ......................20
5.6.3. MIC Subtoken .......................................21
5.7. Example Token .............................................22
5.8. Context Options ...........................................23
6. Acceptor Services ..............................................23
6.1. GSS-API Channel Binding ...................................24
6.2. Per-Message Security ......................................24
6.3. Pseudorandom Function .....................................24
7. IANA Considerations ............................................25
7.1. OID Registry ..............................................25
7.2. RFC 4121 Token Identifiers ................................26
7.3. GSS-EAP Subtoken Types ....................................26
7.4. RADIUS Attribute Assignments ..............................27
7.5. Registration of the EAP-AES128 SASL Mechanisms ............28
7.6. GSS-EAP Errors ............................................28
7.7. GSS-EAP Context Flags .....................................30
8. Security Considerations ........................................30
9. Acknowledgements ...............................................32
10. References ....................................................32
Appendix A. Pre-publication RADIUS VSA ............................33
The Application Bridging for Federated Access Beyond Web (ABFAB) document [ABFAB-ARCH] describes an architecture for providing federated access management to applications using the Generic Security Service Application Programming Interface (GSS-API) [RFC2743] and Simple Authentication and Security Layer (SASL) [RFC4422]. This specification provides the core mechanism for bringing federated authentication to these applications.
Web之外联邦访问的应用程序桥接（ABFAB）文档[ABFAB-ARCH]描述了使用通用安全服务应用程序编程接口（GSS-API）[RFC2743]和简单身份验证和安全层（SASL）[RFC4422]为应用程序提供联邦访问管理的体系结构。该规范提供了将联合身份验证引入这些应用程序的核心机制。
The Extensible Authentication Protocol (EAP) [RFC3748] defines a framework for authenticating a network access client and server in order to gain access to a network. A variety of different EAP methods are in wide use; one of EAP's strengths is that for most types of credentials in common use, there is an EAP method that permits the credential to be used.
可扩展身份验证协议（EAP）[RFC3748]定义了一个框架，用于验证网络访问客户端和服务器，以便访问网络。各种不同的EAP方法被广泛使用；EAP的优点之一是，对于大多数常用的凭证类型，有一种EAP方法允许使用凭证。
EAP is often used in conjunction with a backend Authentication, Authorization and Accounting (AAA) server via RADIUS [RFC3579] or Diameter [RFC4072]. In this mode, the Network Access Server (NAS) simply tunnels EAP packets over the backend authentication protocol to a home EAP/AAA server for the client. After EAP succeeds, the backend authentication protocol is used to communicate key material to the NAS. In this mode, the NAS need not be aware of or have any specific support for the EAP method used between the client and the home EAP server. The client and EAP server share a credential that depends on the EAP method; the NAS and AAA server share a credential based on the backend authentication protocol in use. The backend authentication server acts as a trusted third party, enabling network access even though the client and NAS may not actually share any common authentication methods. As described in the architecture document [ABFAB-ARCH], using AAA proxies, this mode can be extended beyond one organization to provide federated authentication for network access.
EAP通常通过RADIUS[RFC3579]或Diameter[RFC4072]与后端身份验证、授权和计费（AAA）服务器结合使用。在此模式下，网络访问服务器（NAS）只需通过后端身份验证协议将EAP数据包隧道传输到客户端的家庭EAP/AAA服务器。EAP成功后，使用后端身份验证协议将密钥材料传送到NAS。在这种模式下，NAS不需要知道或拥有对客户端和家庭EAP服务器之间使用的EAP方法的任何特定支持。客户端和EAP服务器共享一个凭证，该凭证取决于EAP方法；NAS和AAA服务器根据正在使用的后端身份验证协议共享一个凭据。后端身份验证服务器充当受信任的第三方，支持网络访问，即使客户端和NAS实际上可能不共享任何通用身份验证方法。如体系结构文档[ABFAB-ARCH]所述，使用AAA代理，此模式可以扩展到一个组织之外，为网络访问提供联合身份验证。
The GSS-API provides a generic framework for applications to use security services including authentication and per-message data security. Between protocols that support GSS-API directly or protocols that support SASL [RFC4422], many application protocols can use GSS-API for security services. However, with the exception of Kerberos [RFC4121], few GSS-API mechanisms are in wide use on the Internet. While GSS-API permits an application to be written independent of the specific GSS-API mechanism in use, there is no facility to separate the server from the implementation of the mechanism as there is with EAP and backend authentication servers.
GSS-API为应用程序提供了一个通用框架，以使用安全服务，包括身份验证和每消息数据安全。在直接支持GSS-API的协议或支持SASL[RFC4422]的协议之间，许多应用程序协议可以将GSS-API用于安全服务。然而，除了Kerberos[RFC4121]之外，很少有GSS-API机制在Internet上得到广泛使用。虽然GSS-API允许独立于使用中的特定GSS-API机制编写应用程序，但没有像EAP和后端身份验证服务器那样将服务器与机制的实现分开的功能。
The goal of this specification is to combine GSS-API's support for application protocols with EAP/AAA's support for common credential types and for authenticating to a server without requiring that server to specifically support the authentication method in use. In addition, this specification supports the architectural goal of transporting attributes about subjects to relying parties. Together this combination will provide federated authentication and authorization for GSS-API applications. This specification meets the applicability requirements for EAP to application authentication [RFC7057].
本规范的目标是将GSS-API对应用程序协议的支持与EAP/AAA对常见凭证类型的支持以及对服务器的身份验证结合起来，而无需该服务器专门支持使用中的身份验证方法。此外，本规范支持将主题的属性传输给依赖方的体系结构目标。这种组合将为GSS-API应用程序提供联合身份验证和授权。本规范满足EAP对应用程序认证[RFC7057]的适用性要求。
This mechanism is a GSS-API mechanism that encapsulates an EAP conversation. From the perspective of RFC 3748, this specification defines a new lower-layer protocol for EAP. From the perspective of the application, this specification defines a new GSS-API mechanism.
此机制是封装EAP会话的GSS-API机制。从RFC3748的角度来看，本规范为EAP定义了一个新的低层协议。从应用程序的角度来看，本规范定义了一种新的GSS-API机制。
Section 1.3 of [RFC5247] outlines the typical conversation between EAP peers where an EAP key is derived:
[RFC5247]第1.3节概述了导出EAP密钥的EAP对等方之间的典型对话：
Phase 0: Discovery Phase 1: Authentication 1a: EAP authentication 1b: AAA Key Transport (optional) Phase 2: Secure Association Protocol 2a: Unicast Secure Association 2b: Multicast Secure Association (optional)
阶段0:发现阶段1:身份验证1a:EAP身份验证1b:AAA密钥传输（可选）阶段2:安全关联协议2a:单播安全关联2b:多播安全关联（可选）
GSS-API peers discover each other and discover support for GSS-API in an application-dependent mechanism. SASL [RFC4422] describes how discovery of a particular SASL mechanism such as a GSS-API EAP mechanism is conducted. The Simple and Protected Negotiation mechanism (SPNEGO) [RFC4178] provides another approach for discovering what GSS-API mechanisms are available. The specific approach used for discovery is out of scope for this mechanism.
GSS-API对等点相互发现，并在依赖于应用程序的机制中发现对GSS-API的支持。SASL[RFC4422]描述了如何发现特定的SASL机制，如GSS-API EAP机制。简单和受保护的协商机制（SPNEGO）[RFC4178]为发现可用的GSS-API机制提供了另一种方法。用于发现的特定方法超出此机制的范围。
GSS-API authenticates a party called the "GSS-API initiator" to the GSS-API acceptor, optionally providing authentication of the acceptor to the initiator. Authentication starts with a mechanism-specific message called a "context token" sent from the initiator to the acceptor. The acceptor responds, followed by the initiator, and so on until authentication succeeds or fails. GSS-API context tokens are reliably delivered by the application using GSS-API. The application is responsible for in-order delivery and retransmission.
GSS-API向GSS-API接受者认证称为“GSS-API启动器”的一方，可选地向启动器提供接受者的认证。身份验证从一个称为“上下文令牌”的机制特定消息开始，该消息从发起方发送到接受方。接受者响应，然后是发起者，依此类推，直到身份验证成功或失败。应用程序使用GSS-API可靠地交付GSS-API上下文令牌。应用程序负责按订单交付和重新传输。
EAP authenticates a party called a "peer" to a party called the "EAP server". A third party called an "EAP pass-through authenticator" may decapsulate EAP messages from a lower layer and re-encapsulate them into a AAA protocol. The term EAP authenticator refers to whichever of the pass-through authenticator or EAP server receives the lower-layer EAP packets. The first EAP message travels from the authenticator to the peer; a GSS-API message is sent from the initiator to acceptor to prompt the authenticator to send the first EAP message. The EAP peer maps onto the GSS-API initiator. The role of the GSS-API acceptor is split between the EAP authenticator and the EAP server. When these two entities are combined, the division resembles GSS-API acceptors in other mechanisms. When a more typical deployment is used and there is a pass-through authenticator, most context establishment takes place on the EAP server and per-message operations take place on the authenticator. EAP messages from the peer to the authenticator are called responses; messages from the authenticator to the peer are called requests.
EAP将称为“对等方”的一方认证为称为“EAP服务器”的一方。被称为“EAP直通认证器”的第三方可以从较低层解除EAP消息的封装，并将其重新封装到AAA协议中。术语EAP验证器是指直通验证器或EAP服务器中接收较低层EAP分组的任何一个。第一EAP消息从认证器传送到对等方；将GSS-API消息从发起方发送到接受方，以提示认证方发送第一条EAP消息。EAP对等映射到GSS-API启动器。GSS-API接受者的角色在EAP身份验证程序和EAP服务器之间分配。当这两个实体结合在一起时，这种划分在其他机制中类似于GSS-API受体。当使用更典型的部署且存在直通身份验证器时，大多数上下文建立发生在EAP服务器上，每消息操作发生在身份验证器上。从对等方到认证器的EAP消息称为响应；从验证器到对等方的消息称为请求。
Because GSS-API applications provide guaranteed delivery of context tokens, the EAP retransmission timeout MUST be infinite and the EAP layer MUST NOT retransmit a message.
由于GSS-API应用程序提供有保证的上下文令牌传递，EAP重传超时必须是无限的，EAP层不得重传消息。
This specification permits a GSS-API acceptor to hand off the processing of the EAP packets to a remote EAP server by using AAA protocols such as RADIUS, Transport Layer Security (TLS) Encryption thereof [RFC6929], or Diameter. In this case, the GSS-API acceptor acts as an EAP pass-through authenticator. The pass-through authenticator is responsible for retransmitting AAA messages if a response is not received from the AAA server. If a response cannot be received, then the authenticator generates an error at the GSS-API level. If EAP authentication is successful, and where the chosen EAP method supports key derivation, EAP keying material may also be derived. If a AAA protocol is used, this can also be used to replicate the EAP Key from the EAP server to the EAP authenticator.
本规范允许GSS-API接受者通过使用AAA协议，例如RADIUS、传输层安全（TLS）加密[RFC6929]或Diameter，将EAP数据包的处理移交给远程EAP服务器。在这种情况下，GSS-API接受器充当EAP直通认证器。如果没有从AAA服务器接收到响应，则直通认证器负责重新传输AAA消息。如果无法接收响应，则验证器将在GSS-API级别生成错误。如果EAP认证成功，并且所选EAP方法支持密钥派生，则也可以派生EAP密钥材料。如果使用AAA协议，还可以使用该协议将EAP密钥从EAP服务器复制到EAP验证器。
See Section 5 for details of the authentication exchange.
有关身份验证交换的详细信息，请参见第5节。
After authentication succeeds, GSS-API provides a number of per-message security services that can be used:
认证成功后，GSS-API提供了许多可使用的每消息安全服务：
GSS_Wrap() provides integrity and optional confidentiality for a message.
GSS_Wrap（）为消息提供完整性和可选的机密性。
GSS_GetMIC() provides integrity protection for data sent independently of the GSS-API
GSS_GetMIC（）为独立于GSS-API发送的数据提供完整性保护
GSS_Pseudo_random [RFC4401] provides key derivation functionality.
GSS_伪_random[RFC4401]提供密钥派生功能。
These services perform a function similar to secure association protocols in network access. Like secure association protocols, these services need to be performed near the authenticator/acceptor even when a AAA protocol is used to separate the authenticator from the EAP server. The key used for these per-message services is derived from the EAP key; the EAP peer and authenticator derive this key as a result of a successful EAP authentication. In the case that the EAP authenticator is acting as a pass-through, it obtains it via the AAA protocol. See Section 6 for details.
这些服务执行的功能类似于网络访问中的安全关联协议。与安全关联协议一样，即使使用AAA协议将认证者与EAP服务器分离，这些服务也需要在认证者/接受者附近执行。用于这些每条消息服务的密钥来自EAP密钥；EAP对等方和身份验证器在EAP身份验证成功后派生此密钥。如果EAP验证器充当传递，它将通过AAA协议获得它。详见第6节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
EAP authenticates a user to a realm. The peer knows that it has exchanged authentication with an EAP server in a given realm. Today, the peer does not typically know which NAS it is talking to securely. That is often fine for network access. However, privileges to delegate to a chat server seem very different than privileges for a file server or trading site. Also, an EAP peer knows the identity of the home realm, but perhaps not even the visited realm.
EAP将用户认证到一个领域。对等方知道它已与给定域中的EAP服务器交换身份验证。如今，对等方通常不知道它正在安全地与哪个NAS通信。这对于网络访问通常是好的。然而，授权给聊天服务器的权限似乎与文件服务器或交易网站的权限大不相同。此外，EAP对等方知道主域的身份，但可能甚至不知道访问的域的身份。
In contrast, GSS-API takes a name for both the initiator and acceptor as inputs to the authentication process. When mutual authentication is used, both parties are authenticated. The granularity of these names is somewhat mechanism dependent. In the case of the Kerberos mechanism, the acceptor name typically identifies both the protocol in use (such as IMAP) and the specific instance of the service being connected to. The acceptor name almost always identifies the administrative domain providing service.
相反，GSS-API将启动器和接收器的名称作为身份验证过程的输入。当使用相互身份验证时，对双方都进行身份验证。这些名称的粒度在某种程度上取决于机制。在Kerberos机制的情况下，接受方名称通常标识正在使用的协议（如IMAP）和连接到的服务的特定实例。接受者名称几乎总是标识提供服务的管理域。
A GSS-API EAP mechanism needs to provide GSS-API naming semantics in order to work with existing GSS-API applications. EAP channel binding [RFC6677] is used to provide GSS-API naming semantics. Channel binding sends a set of attributes from the peer to the EAP server either as part of the EAP conversation or as part of a secure association protocol. In addition, attributes are sent in the backend authentication protocol from the authenticator to the EAP server. The EAP server confirms the consistency of these attributes. Confirming attribute consistency also involves checking consistency against a local policy database as discussed in Section 3.5. In particular, the peer sends the name of the acceptor it is authenticating to as part of channel binding. The acceptor sends its full name as part of the backend authentication protocol. The EAP server confirms consistency of the names.
GSS-API EAP机制需要提供GSS-API命名语义，以便与现有GSS-API应用程序协同工作。EAP通道绑定[RFC6677]用于提供GSS-API命名语义。通道绑定将一组属性从对等方发送到EAP服务器，作为EAP会话的一部分或安全关联协议的一部分。此外，属性在后端身份验证协议中从身份验证程序发送到EAP服务器。EAP服务器确认这些属性的一致性。确认属性一致性还包括根据本地策略数据库检查一致性，如第3.5节所述。特别是，对等方发送它正在验证的接受方的名称，作为通道绑定的一部分。接受方将其全名作为后端身份验证协议的一部分发送。EAP服务器确认名称的一致性。
EAP channel binding is easily confused with a facility in GSS-API also called "channel binding". GSS-API channel binding provides protection against man-in-the-middle attacks when GSS-API is used as authentication inside some tunnel; it is similar to a facility called "cryptographic binding" in EAP. See [RFC5056] for a discussion of the differences between these two facilities and Section 6.1 for how GSS-API channel binding is handled in this mechanism.
EAP通道绑定很容易与GSS-API中也称为“通道绑定”的功能混淆。当GSS-API被用作某个隧道内的身份验证时，GSS-API通道绑定提供了针对中间人攻击的保护；它类似于EAP中称为“加密绑定”的功能。参见[RFC5056]了解这两种设施之间的差异，参见第6.1节了解如何在此机制中处理GSS-API通道绑定。
Before discussing how the initiator and acceptor names are validated in the AAA infrastructure, it is necessary to discuss what composes a name for an EAP GSS-API mechanism. GSS-API permits several types of generic names to be imported using GSS_Import_name(). Once a mechanism is chosen, these names are converted into a mechanism-specific name called a "Mechanism Name". Note that a Mechanism Name is the name of an initiator or acceptor, not of a GSS-API mechanism. This section first discusses the mechanism name form and then discusses what name forms are supported.
在讨论如何在AAA基础设施中验证发起方和接受方名称之前，有必要讨论EAP GSS-API机制的名称的组成。GSS-API允许使用GSS_Import_name（）导入几种类型的通用名称。一旦选择了一个机制，这些名称将转换为一个称为“机制名称”的机制特定名称。请注意，机制名称是启动器或接收器的名称，而不是GSS-API机制的名称。本节首先讨论机制名称表单，然后讨论支持哪些名称表单。
The string representation of the GSS-EAP mechanism name has the following ABNF [RFC5234] representation:
GSS-EAP机制名称的字符串表示形式具有以下ABNF[RFC5234]表示形式：
char-normal = %x00-2E/%x30-3F/%x41-5B/%x5D-FF
char-escaped = "\" %x2F / "\" %x40 / "\" %x5C
name-char = char-normal / char-escaped
name-string = 1*name-char
user-or-service = name-string
host = [name-string]
realm = name-string
service-specific = name-string
service-specifics = service-specific 0*("/" service-specifics)
name = user-or-service ["/" host [ "/" service-specifics]] [ "@"
realm ]
char-normal = %x00-2E/%x30-3F/%x41-5B/%x5D-FF
char-escaped = "\" %x2F / "\" %x40 / "\" %x5C
name-char = char-normal / char-escaped
name-string = 1*name-char
user-or-service = name-string
host = [name-string]
realm = name-string
service-specific = name-string
service-specifics = service-specific 0*("/" service-specifics)
name = user-or-service ["/" host [ "/" service-specifics]] [ "@"
realm ]
Special characters appearing in a name can be backslash escaped to avoid their special meanings. For example, "\\" represents a literal backslash. This escaping mechanism is a property of the string representation; if the components of a name are transported in some mechanism that will keep them separate without backslash escaping, then backslash SHOULD have no special meaning.
名称中出现的特殊字符可以反斜杠转义，以避免其特殊含义。例如，“\\”表示文字反斜杠。这个转义机制是字符串表示的一个属性；如果名称的组成部分是通过某种机制传输的，这种机制将使它们保持分离，而不进行反斜杠转义，那么反斜杠应该没有特殊意义。
The user-or-service component is similar to the portion of a network access identifier (NAI) before the '@' symbol for initiator names and the service name from the registry of GSS-API host-based services in the case of acceptor names [GSS-IANA]. The NAI specification provides rules for encoding and string preparation in order to support internationalization of NAIs; implementations of this mechanism MUST NOT prepare the user-or-service according to these rules; see Section 3.2 for internationalization of this mechanism. The host portion is empty for initiators and typically contains the domain name of the system on which an acceptor service is running. Some services MAY require additional parameters to distinguish the entity being authenticated against. Such parameters are encoded in the service-specifics portion of the name. The EAP server MUST reject authentication of any acceptor name that has a non-empty service-specifics component unless the EAP server understands the service-specifics and authenticates them. The interpretation of the service-specifics is scoped by the user-or-service portion. The realm is similar to the realm portion of a NAI for initiator names; again the NAI specification's internationalization rules MUST NOT be applied to the realm. The realm is the administrative realm of a service for an acceptor name.
用户或服务组件类似于网络访问标识符（NAI）中“@”符号之前的部分，用于发起方名称，以及GSS-API基于主机的服务注册表中的服务名称（对于接受方名称[GSS-IANA]）。NAI规范提供编码和字符串准备规则，以支持NAI的国际化；此机制的实现不得根据这些规则准备用户或服务；有关该机制的国际化，请参见第3.2节。主机部分对于启动器是空的，通常包含运行接受程序服务的系统的域名。某些服务可能需要额外的参数来区分正在进行身份验证的实体。这些参数编码在名称的服务特定部分中。EAP服务器必须拒绝对具有非空服务规范组件的任何接受者名称的身份验证，除非EAP服务器了解服务规范并对其进行身份验证。服务细节的解释由用户或服务部分确定范围。对于启动器名称，领域类似于NAI的领域部分；同样，NAI规范的国际化规则不能应用于领域。领域是接受方名称的服务的管理领域。
The string representation of this name form is designed to be generally compatible with the string representation of Kerberos names defined in [RFC1964].
此名称表单的字符串表示形式通常与[RFC1964]中定义的Kerberos名称的字符串表示形式兼容。
The GSS_C_NT_USER_NAME form represents the name of an individual user. From the standpoint of this mechanism, it may take the form of either an undecorated user name or a name semantically similar to a network access identifier (NAI) [RFC4282]. The name is split at the first at-sign ('@') into the part preceding the realm, which is the user-or-service portion of the mechanism name, and the realm portion, which is the realm portion of the mechanism name.
GSS_C_NT_USER_NAME表单表示单个用户的名称。从该机制的观点来看，它可以采用未修饰的用户名或语义上类似于网络访问标识符（NAI）的名称的形式[RFC4282]。名称在第一个at符号（“@”）处被拆分为领域前面的部分，即机制名称的用户或服务部分，以及领域部分，即机制名称的领域部分。
The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running on a host; it is textually represented as "service@host". This name form is required by most SASL profiles and is used by many existing applications that use the Kerberos GSS-API mechanism. While support for this name form is critical, it presents an interesting challenge in terms of EAP channel binding. Consider a case where the server communicates with a "server proxy," or a AAA server near the server. That server proxy communicates with the EAP server. The EAP server and server proxy are in different administrative realms. The server proxy is in a position to verify that the request comes from the indicated host. However, the EAP server cannot make this determination directly. So, the EAP server needs to determine whether to trust the server proxy to verify the host portion of the acceptor name. This trust decision depends both on the host name and the realm of the server proxy. In effect, the EAP server decides whether to trust that the realm of the server proxy is the right realm for the given hostname and then makes a trust decision about the server proxy itself. The same problem appears in Kerberos: there, clients decide what Kerberos realm to trust for a given hostname. The service portion of this name is imported into the user-or-service portion of the mechanism name; the host portion is imported into the host portion of the mechanism name. The realm portion is empty. However, authentication will typically fail unless some AAA component indicates the realm to the EAP server. If the application server knows its realm, then it should be indicated in the outgoing AAA request. Otherwise, a proxy SHOULD add the realm. An alternate form of this name type MAY be used on acceptors; in this case, the name form is "service" with no host component. This is imported with the service as user-or-service and an empty host and realm portion. This form is useful when a service is unsure which name an initiator knows it by.
GSS_C_NT_HOSTBASED_服务名称表单表示在主机上运行的服务；它在文本上表示为“service@host". 大多数SASL配置文件都需要此名称形式，并且许多使用Kerberos GSS-API机制的现有应用程序都使用此名称形式。虽然对该名称表单的支持至关重要，但它在EAP通道绑定方面提出了一个有趣的挑战。考虑服务器与“服务器代理”或服务器附近的AAA服务器通信的情况。该服务器代理与EAP服务器通信。EAP服务器和服务器代理位于不同的管理领域。服务器代理可以验证请求是否来自指定的主机。但是，EAP服务器无法直接进行此确定。因此，EAP服务器需要确定是否信任服务器代理来验证接受方名称的主机部分。此信任决定取决于主机名和服务器代理的领域。实际上，EAP服务器决定是否信任服务器代理的领域是给定主机名的正确领域，然后对服务器代理本身作出信任决定。Kerberos中也出现了同样的问题：在那里，客户机决定对给定主机名信任哪个Kerberos域。将该名称的服务部分导入机制名称的用户或服务部分；主机部分导入到机制名称的主机部分。领域部分为空。但是，除非某个AAA组件向EAP服务器指示域，否则身份验证通常会失败。如果应用服务器知道它的领域，那么应该在传出的AAA请求中指出它。否则，代理应该添加领域。此名称类型的另一种形式可用于接受方；在本例中，名称表单是“服务”，没有主机组件。这将与作为用户或服务的服务以及空主机和域部分一起导入。当服务不确定启动器通过哪个名称知道它时，此表单非常有用。
If the null name type or the GSS_EAP_NT_EAP_NAME (OID
1.3.6.1.5.5.15.2.1) (see Section 7.1 ) is imported, then the string
representation above should be directly imported. Mechanisms MAY
support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form with the OID
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5(2) krb5_name(1)}. In many circumstances, Kerberos
GSS-API mechanism names will behave as expected when used with the
GSS-API EAP mechanism, but there are some differences that may cause
If the null name type or the GSS_EAP_NT_EAP_NAME (OID
1.3.6.1.5.5.15.2.1) (see Section 7.1 ) is imported, then the string
representation above should be directly imported. Mechanisms MAY
support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form with the OID
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5(2) krb5_name(1)}. In many circumstances, Kerberos
GSS-API mechanism names will behave as expected when used with the
GSS-API EAP mechanism, but there are some differences that may cause
some confusion. If an implementation does support importing Kerberos names it SHOULD fail the import if the Kerberos name is not syntactically a valid GSS-API EAP mechanism name as defined in this section.
有些混乱。如果实现不支持导入Kerberos名称，则如果Kerberos名称在语法上不是本节中定义的有效GSS-API EAP机制名称，则导入将失败。
For the most part, GSS-EAP names are transported in other protocols; those protocols define the internationalization semantics. For example, if a AAA server wishes to communicate the user-or-service portion of the initiator name to an acceptor, it does so using existing mechanisms in the AAA protocol. Existing internationalization rules are applied. Similarly, within an application, existing specifications such as [RFC5178] define the encoding of names that are imported and displayed with the GSS-API.
在大多数情况下，GSS-EAP名称在其他协议中传输；这些协议定义了国际化语义。例如，如果AAA服务器希望将启动器名称的用户或服务部分传递给接受者，则它使用AAA协议中的现有机制来实现。应用现有的国际化规则。类似地，在应用程序中，现有规范（如[RFC5178]）定义了与GSS-API一起导入和显示的名称的编码。
This mechanism does introduce a few cases where name components are sent. In these cases, the encoding of the string is UTF-8. Senders SHOULD NOT normalize or map strings before sending. These strings include RADIUS attributes introduced in Section 3.4.
这种机制确实引入了一些发送名称组件的情况。在这些情况下，字符串的编码是UTF-8。发件人在发送之前不应规范化或映射字符串。这些字符串包括第3.4节中介绍的半径属性。
When comparing the host portion of a GSS-EAP acceptor name supplied in EAP channel binding by a peer to that supplied by an acceptor, EAP servers SHOULD prepare the host portion according to [RFC5891] prior to comparison. Applications MAY prepare domain names prior to importing them into this mechanism.
当比较对等方在EAP通道绑定中提供的GSS-EAP接受方名称的主机部分与接受方提供的主机部分时，EAP服务器应在比较之前根据[RFC5891]准备主机部分。应用程序可以在将域名导入该机制之前准备域名。
GSS-API provides the GSS_Export_name call. This call can be used to export the binary representation of a name. This name form can be stored on access control lists for binary comparison.
GSS-API提供GSS_导出_名称调用。此调用可用于导出名称的二进制表示形式。此名称表单可以存储在访问控制列表中，以便进行二进制比较。
The exported name token MUST use the format described in Section 3.2 of RFC 2743. The mechanism specific portion of this name token is the string format of the mechanism name described in Section 3.1.
导出的名称令牌必须使用RFC 2743第3.2节中描述的格式。此名称标记的机制特定部分是第3.1节中描述的机制名称的字符串格式。
RFC 2744 [RFC2744] places the requirement that the result of importing a name, canonicalizing it to a Mechanism Name and then exporting it needs to be the same as importing that name, obtaining credentials for that principal, initiating a context with those credentials and exporting the name on the acceptor. In practice, GSS mechanisms often, but not always, meet this requirement. For names expected to be used as initiator names, this requirement is met. However, permitting empty host and realm components when importing host-based services may make it possible for an imported name to
RFC 2744[RFC2744]要求导入名称、将其规范化为机制名称然后导出的结果必须与导入该名称、获取该主体的凭据、使用这些凭据启动上下文并在接受程序上导出名称的结果相同。在实践中，GSS机制通常（但并非总是）满足这一要求。对于预期用作启动器名称的名称，满足此要求。但是，在导入基于主机的服务时允许空主机和领域组件，可能会导致导入的名称被删除
differ from the exported name actually used. Other mechanisms such as Kerberos have similar situations where imported and exported names may differ.
与实际使用的导出名称不同。其他机制（如Kerberos）具有类似的情况，其中导入和导出的名称可能不同。
See Section 7.4 for registrations of RADIUS attribute types to carry the acceptor service name. All the attribute types registered in that section are strings. See Section 3.1 for details of the values in a name.
请参阅第7.4节，了解携带接受者服务名称的RADIUS属性类型的注册。该部分中注册的所有属性类型都是字符串。有关名称中值的详细信息，请参见第3.1节。
If RADIUS is used as a AAA transport, the acceptor MUST send the acceptor name in these attribute types. That is, the acceptor decomposes its name and sends any non-empty portion as a RADIUS attribute. With the exception of the service-specifics portion of the name, the backslash escaping mechanism is not used in RADIUS attributes; backslash has no special meaning. In the service-specifics portion, a literal "/" separates components. In this one attribute, "\/" indicates a slash character that does not separate components and "\\" indicates a literal backslash character.
如果RADIUS用作AAA传输，则接受者必须发送这些属性类型中的接受者名称。也就是说，接受程序分解其名称并将任何非空部分作为RADIUS属性发送。除了名称的服务特定部分外，RADIUS属性中不使用反斜杠转义机制；反斜杠没有特别的意义。在服务特定部分中，文本“/”分隔组件。在这个属性中，“\/”表示不分隔组件的斜杠字符，“\\”表示文字反斜杠字符。
The initiator MUST require that the EAP method in use support channel binding and MUST send the acceptor name as part of the channel binding data. The client MUST NOT indicate mutual authentication in the result of GSS_Init_sec_context unless all name elements that the client supplied are in a successful channel binding response. For example, if the client supplied a hostname in channel binding data, the hostname MUST be in a successful channel binding response.
发起方必须要求使用中的EAP方法支持通道绑定，并且必须将接受方名称作为通道绑定数据的一部分发送。除非客户端提供的所有名称元素都在成功的通道绑定响应中，否则客户端不得在GSS_Init_sec_上下文的结果中指示相互身份验证。例如，如果客户端在通道绑定数据中提供了主机名，则主机名必须在成功的通道绑定响应中。
If an empty target name is supplied to GSS_Init_sec_context, the initiator MUST fail context establishment unless the acceptor supplies the acceptor name response (Section 5.4.3). If a null target name is supplied, the initiator MUST use this response to populate EAP channel bindings.
如果向GSS_Init_sec_上下文提供空的目标名称，则发起方必须失败上下文建立，除非接受方提供接受方名称响应（第5.4.3节）。如果提供了空目标名称，则启动器必须使用此响应来填充EAP通道绑定。
Proxies may play a role in verification of the acceptor identity. For example, a AAA proxy near the acceptor may be in a position to verify the acceptor hostname, while the EAP server is likely to be too distant to reliably verify this on its own.
代理可以在验证接受方身份方面发挥作用。例如，靠近接受者的AAA代理可能能够验证接受者主机名，而EAP服务器可能距离太远，无法单独可靠地验证。
The EAP server or some proxy trusted by the EAP server is likely to be in a position to verify the acceptor realm. In effect, this proxy is confirming that the right AAA credential is used for the claimed realm and thus that the acceptor is in the organization it claims to
EAP服务器或EAP服务器信任的某个代理可能处于验证接受方领域的位置。实际上，此代理正在确认正确的AAA凭据用于声明的领域，从而确认接受方位于其声明的组织中
be part of. This proxy is also typically trusted by the EAP server to make sure that the hostname claimed by the acceptor is a reasonable hostname for the realm of the acceptor.
成为其中的一部分。EAP服务器通常也信任此代理，以确保接受方声明的主机名是接受方领域的合理主机名。
A proxy close to the EAP server is unlikely to be in a position to confirm that the acceptor is claiming the correct hostname. Instead, this is typically delegated to a proxy near the acceptor. That proxy is typically expected to verify the acceptor hostname and to verify the appropriate AAA credential for that host is used. Such a proxy may insert the acceptor realm if it is absent, permitting realm configuration to be at the proxy boundary rather than on acceptors.
靠近EAP服务器的代理不太可能确认接受者声明的主机名正确。相反，这通常被委托给接受者附近的代理。该代理通常用于验证接受方主机名，并验证是否使用了该主机的适当AAA凭据。如果不存在接受域，这样的代理可以插入接受域，从而允许域配置位于代理边界而不是接受域上。
Ultimately, specific proxy behavior is a matter for deployment. The EAP server MUST assure that the appropriate validation has been done before including acceptor name attributes in a successful channel binding response. If the acceptor service is included, the EAP server asserts that the service is plausible for the acceptor. If the acceptor hostname is included, the EAP server asserts that the acceptor hostname is verified. If the realm is included the EAP server asserts that the realm has been verified, and if the hostname was also included, that the realm and hostname are consistent. Part of this verification MAY be delegated to proxies, but the EAP server configuration MUST guarantee that the combination of proxies meets these requirements. Typically, such delegation will involve business or operational measures such as cross-organizational agreements as well as technical measures.
最终，特定的代理行为是部署的问题。EAP服务器必须确保在成功的通道绑定响应中包含接受者名称属性之前已完成适当的验证。如果包含了接受方服务，EAP服务器将断言该服务对于接受方是合理的。如果包含了接受者主机名，EAP服务器将断言已验证接受者主机名。如果包含领域，EAP服务器会断言该领域已经过验证，如果还包含主机名，则表明领域和主机名是一致的。此验证的一部分可以委托给代理，但EAP服务器配置必须保证代理组合满足这些要求。通常，此类授权将涉及业务或运营措施，如跨组织协议以及技术措施。
It is likely that future technical work will be needed to communicate what verification has been done by proxies along the path. Such technical measures will not release the EAP server from its responsibility to decide whether proxies on the path should be trusted to perform checks delegated to them. However, technical measures could prevent misconfigurations and help to support diverse environments.
很可能需要未来的技术工作来传达代理在路径上所做的验证。此类技术措施不会免除EAP服务器决定是否信任路径上的代理执行委托给它们的检查的责任。然而，技术措施可以防止错误配置，并有助于支持不同的环境。
EAP does not provide a facility for an EAP server to advertise what methods are available to a peer. Instead, a server starts with its preferred method selection. If the peer does not accept that method, the peer sends a NAK response containing the list of methods supported by the client.
EAP不为EAP服务器提供一种设施，用于公布对等方可用的方法。相反，服务器从其首选方法选择开始。如果对等方不接受该方法，则对等方发送一个NAK响应，其中包含客户端支持的方法列表。
Providing multiple facilities to negotiate which security mechanism to use is undesirable. Section 7.3 of [RFC4462]describes the problem referencing the Secure Shell (SSH) Protocol key exchange negotiation and the SPNEGO GSS-API mechanism. If a client preferred an EAP method A, a non-EAP authentication mechanism B, and then an EAP
提供多个工具来协商使用哪种安全机制是不可取的。[RFC4462]的第7.3节描述了引用Secure Shell（SSH）协议密钥交换协商和SPNEGO GSS-API机制的问题。如果客户端首选EAP方法a、非EAP身份验证机制B，然后是EAP
method C, then the client would have to commit to using EAP before learning whether A is actually supported. Such a client might end up using C when B is available.
方法C，则客户端必须承诺使用EAP，然后才能了解是否实际支持。当B可用时，这样的客户机可能最终使用C。
The standard solution to this problem is to perform all the negotiation at one layer. In this case, rather than defining a single GSS-API mechanism, a family of mechanisms should be defined. Each mechanism corresponds to an EAP method. The EAP method type should be part of the GSS-API OID. Then, a GSS-API rather than EAP facility can be used for negotiation.
这个问题的标准解决方案是在一个层上执行所有协商。在这种情况下，应该定义一系列机制，而不是定义单个GSS-API机制。每个机制对应一个EAP方法。EAP方法类型应该是GSS-API OID的一部分。然后，可以使用GSS-API而不是EAP工具进行协商。
Unfortunately, using a family of mechanisms has a number of problems. First, GSS-API assumes that both the initiator and acceptor know the entire set of mechanisms that are available. Some negotiation mechanisms are driven by the client; others are driven by the server. With EAP GSS-API, the acceptor does not know what methods the EAP server implements. The EAP server that is used depends on the identity of the client. The best solution so far is to accept the disadvantages of multi-layer negotiation and commit to using EAP GSS-API before a specific EAP method. This has two main disadvantages. First, authentication may fail when other methods might allow authentication to succeed. Second, a non-optimal security mechanism may be chosen.
不幸的是，使用一系列机制存在许多问题。首先，GSS-API假定发起方和接受方都知道可用的整套机制。一些协商机制是由客户驱动的；其他由服务器驱动。对于EAP GSS-API，接受者不知道EAP服务器实现了什么方法。所使用的EAP服务器取决于客户端的标识。到目前为止，最好的解决方案是接受多层协商的缺点，并承诺在使用特定的EAP方法之前使用EAP GSS-API。这有两个主要缺点。首先，当其他方法允许身份验证成功时，身份验证可能会失败。其次，可以选择非最优安全机制。
All context establishment tokens emitted by the EAP mechanism SHALL have the framing described in Section 3.1 of [RFC2743], as illustrated by the following pseudo-ASN.1 structures:
EAP机制发出的所有上下文建立令牌应具有[RFC2743]第3.1节中描述的帧，如以下伪ASN.1结构所示：
GSS-API DEFINITIONS ::=
BEGIN
GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- representing EAP mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
END
MechType ::= OBJECT IDENTIFIER
-- representing EAP mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
END
The innerToken field starts with a 16-bit network byte order token type identifier. The remainder of the innerToken field is a set of type-length-value subtokens. The following figure describes the structure of the inner token:
innerToken字段以16位网络字节顺序令牌类型标识符开头。innerToken字段的其余部分是一组类型长度值子项。下图描述了内部令牌的结构：
+----------------+---------------------------+
| Octet Position | Description |
+----------------+---------------------------+
| 0..1 | token ID |
| | |
| 2..5 | first subtoken type |
| | |
| 6..9 | length of first subtoken |
| | |
| 10..10+n-1 | first subtoken body |
| | |
| 10+n..10+n+3 | second subtoken type |
+----------------+---------------------------+
+----------------+---------------------------+
| Octet Position | Description |
+----------------+---------------------------+
| 0..1 | token ID |
| | |
| 2..5 | first subtoken type |
| | |
| 6..9 | length of first subtoken |
| | |
| 10..10+n-1 | first subtoken body |
| | |
| 10+n..10+n+3 | second subtoken type |
+----------------+---------------------------+
Structure of Inner Token
内部标记的结构
The inner token continues with length, second subtoken body, and so forth. If a subtoken type is present, its length and body MUST be present.
内部标记以长度、第二个子项主体等继续。如果存在subtoken类型，则其长度和正文必须存在。
The length is a four-octet length of the subtoken body in network byte order. The length does not include the length of the type field or the length field; the length only covers the body.
长度是subtoken正文的四个八位字节长度，按网络字节顺序排列。长度不包括类型字段或长度字段的长度；长度只覆盖身体。
Tokens from the initiator to acceptor use an inner token type with ID 06 01; tokens from acceptor to initiator use an inner token type with ID 06 02. These token types are registered in the registry of RFC 4121 token types; see Section 7.2.
从发起方到接受方的令牌使用ID为06 01的内部令牌类型；从接受者到发起者的令牌使用ID为06 02的内部令牌类型。这些令牌类型在RFC 4121令牌类型的注册表中注册；见第7.2节。
See Section 5.7 for the encoding of a complete token. The following sections discuss how mechanism OIDs are chosen and the state machine that defines what subtokens are permitted at each point in the context establishment process.
有关完整令牌的编码，请参见第5.7节。以下各节讨论如何选择机制OID，以及定义在上下文建立过程中的每个点允许哪些子项的状态机。
This mechanism family uses the security services of the Kerberos cryptographic framework [RFC3961]. The root of the OID ARC for mechanisms described in this document is 1.3.6.1.5.5.15.1.1; a Kerberos encryption type number [RFC3961] is appended to that root OID to form a mechanism OID. As such, a particular encryption type needs to be chosen. By convention, there is a single object identifier arc for the EAP family of GSS-API mechanisms. A specific
此机制系列使用Kerberos加密框架[RFC3961]的安全服务。本文件所述机构的OID弧根为1.3.6.1.5.5.15.1.1；Kerberos加密类型号[RFC3961]附加到该根OID以形成机制OID。因此，需要选择特定的加密类型。按照惯例，GSS-API机制的EAP系列只有一个对象标识符arc。特定的
mechanism is chosen by adding the numeric Kerberos encryption type number to the root of this arc. However, in order to register the SASL name, the specific usage with a given encryption type needs to be registered. This document defines the EAP-AES128 GSS-API mechanism.
通过将数字Kerberos加密类型号添加到此弧的根来选择该机制。但是，为了注册SASL名称，需要注册具有给定加密类型的特定用法。本文件定义了EAP-AES128 GSS-API机制。
Whenever a context token is received, the receiver performs the following checks. First, the receiver confirms the object identifier is that of the mechanism being used. The receiver confirms that the token type corresponds to the role of the peer: acceptors will only process initiator tokens and initiators will only process acceptor tokens.
每当接收到上下文令牌时，接收方都会执行以下检查。首先，接收方确认对象标识符是正在使用的机制的标识符。接收方确认令牌类型对应于对等方的角色：接收方将仅处理发起方令牌，而发起方将仅处理接收方令牌。
Implementations of this mechanism maintain a state machine for the context establishment process. Both the initiator and acceptor start out in the initial state; see Section 5.4 for a description of this state. Associated with each state are a set of subtoken types that are processed in that state and rules for processing these subtoken types. The receiver examines the subtokens in order, processing any that are appropriate for the current state. Unknown subtokens or subtokens that are not expected in the current state are ignored if their critical bit (see below) is clear.
该机制的实现为上下文建立过程维护一个状态机。发起者和接受者都以初始状态启动；有关该状态的说明，请参见第5.4节。与每个状态关联的是一组在该状态下处理的子项类型以及处理这些子项类型的规则。接收者按顺序检查子项，处理适合当前状态的任何子项。如果关键位（见下文）清除，则忽略当前状态中不需要的未知子项或子项。
A state may have a set of required subtoken types. If a subtoken type is required by the current state but no subtoken of that type is present, then the context establishment MUST fail.
一个状态可能有一组必需的子项类型。如果当前状态需要subtoken类型，但不存在该类型的subtoken，则上下文建立必须失败。
The most significant bit (0x80000000) in a subtoken type is the critical bit. If a subtoken with this bit set in the type is received, the receiver MUST fail context establishment unless the subtoken is understood and processed for the current state.
子项类型中的最高有效位（0x8000000）是关键位。如果接收到类型中设置了此位的子项，则接收方必须失败上下文建立，除非该子项在当前状态下被理解和处理。
The subtoken type MUST be unique within a given token.
subtoken类型在给定令牌中必须是唯一的。
The acceptor may always end the exchange by generating an error subtoken. The error subtoken has the following format:
接受方可能总是通过生成错误子项来结束交换。错误subtoken的格式如下：
+--------+----------------------------------------------------------+
| Pos | Description |
+--------+----------------------------------------------------------+
| 0..3 | 0x80 00 00 01 |
| | |
| 4..7 | length of error token |
| | |
| 8..11 | major status from RFC 2744 as 32-bit network byte order |
| | |
| 12..15 | GSS-EAP error code as 32-bit network byte order; see |
| | Section 7.6 |
+--------+----------------------------------------------------------+
+--------+----------------------------------------------------------+
| Pos | Description |
+--------+----------------------------------------------------------+
| 0..3 | 0x80 00 00 01 |
| | |
| 4..7 | length of error token |
| | |
| 8..11 | major status from RFC 2744 as 32-bit network byte order |
| | |
| 12..15 | GSS-EAP error code as 32-bit network byte order; see |
| | Section 7.6 |
+--------+----------------------------------------------------------+
Initiators MUST ignore octets beyond the GSS-EAP error code for future extensibility. As indicated, the error token is always marked critical.
发起者必须忽略GSS-EAP错误代码之外的八位字节，以实现将来的扩展性。如图所示，错误标记始终标记为严重。
Both the acceptor and initiator start the context establishment process in the initial state.
接受方和发起方都以初始状态启动上下文建立过程。
The initiator sends a token to the acceptor. It MAY be empty; no subtokens are required in this state. Alternatively, the initiator MAY include a vendor ID subtoken or an acceptor name request subtoken.
发起者向接受者发送令牌。它可能是空的；此状态下不需要子项。或者，发起方可以包括供应商ID子项或接受方名称请求子项。
The acceptor responds to this message. It MAY include an acceptor name response subtoken. It MUST include a first EAP request; this is an EAP request/identity message (see Section 5.5.1 for the format of this subtoken).
接受者对此消息作出响应。它可能包括一个接受方名称响应。它必须包括第一个EAP请求；这是一条EAP请求/身份信息（参见第5.5.1节了解此子项的格式）。
The initiator and acceptor then transition to authenticate state.
然后，发起方和接受方转换到身份验证状态。
The vendor ID subtoken has type 0x0000000B and the following structure:
供应商ID子项的类型为0x0000000B，结构如下：
+-------------+------------------------+
| Pos | Description |
+-------------+------------------------+
| 0..3 | 0x0000000B |
| | |
| 4..7 | length of vendor token |
| | |
| 8..8+length | Vendor ID string |
+-------------+------------------------+
+-------------+------------------------+
| Pos | Description |
+-------------+------------------------+
| 0..3 | 0x0000000B |
| | |
| 4..7 | length of vendor token |
| | |
| 8..8+length | Vendor ID string |
+-------------+------------------------+
The vendor ID string is an UTF-8 string describing the vendor of this implementation. This string is unstructured and for debugging purposes only.
供应商ID字符串是描述此实现的供应商的UTF-8字符串。此字符串是非结构化的，仅用于调试目的。
The acceptor name request token is sent from the initiator to the acceptor indicating that the initiator wishes a particular acceptor name. This is similar to Transport Layer Security (TLS) Server Name Indication [RFC6066] that permits a client to indicate which one of a number of virtual services to contact. The structure is as follows:
接受方名称请求令牌从发起方发送到接受方，表明发起方希望获得特定的接受方名称。这类似于传输层安全（TLS）服务器名称指示[RFC6066]，它允许客户端指示要联系的虚拟服务中的哪一个。结构如下：
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000002 |
| | |
| 4..7 | length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000002 |
| | |
| 4..7 | length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+
It is likely that channel binding and thus authentication will fail if the acceptor does not choose a name that is a superset of this name. That is, if a hostname is sent, the acceptor needs to be willing to accept this hostname.
如果接受者没有选择作为该名称超集的名称，则通道绑定和身份验证可能会失败。也就是说，如果发送了一个主机名，那么接受者需要愿意接受这个主机名。
The acceptor name response subtoken indicates what acceptor name is used. This is useful, for example, if the initiator supplied no target name to the context initialization. This allows the initiator to learn the acceptor name. EAP channel bindings will provide confirmation that the acceptor is accurately naming itself.
acceptor name response subtoken指示所使用的acceptor name。例如，如果启动器未向上下文初始化提供任何目标名称，这将非常有用。这允许发起者了解接受者名称。EAP通道绑定将提供接受者准确命名自身的确认。
This token is sent from the acceptor to initiator. In the Initial state, this token would typically be sent if the acceptor name request is absent, because if the initiator already sent an acceptor name, then the initiator knows what acceptor it wishes to contact. This subtoken is also sent in Extensions state Section 5.6, so the initiator can protect against a man-in-the-middle modifying the acceptor name request subtoken.
此令牌从接受方发送到发起方。在初始状态下，如果没有接受方名称请求，则通常会发送此令牌，因为如果发起方已发送接受方名称，则发起方知道希望联系的接受方。此子项也在扩展状态第5.6节中发送，因此发起方可以防止中间人修改接受方名称请求子项。
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000003 |
| | |
| 4..7 | length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000003 |
| | |
| 4..7 | length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+
In this state, the acceptor sends EAP requests to the initiator and the initiator generates EAP responses. The goal of the state is to perform a successful EAP authentication. Since the acceptor sends an identity request at the end of the initial state, the first half-round-trip in this state is a response to that request from the initiator.
在此状态下，接受方向发起方发送EAP请求，发起方生成EAP响应。状态的目标是执行成功的EAP身份验证。由于接受者在初始状态结束时发送标识请求，因此此状态下的前半个往返是对发起者请求的响应。
The EAP conversation can end in a number of ways:
EAP对话可以通过多种方式结束：
o If the EAP state machine generates an EAP Success message, then the EAP authenticator believes the authentication is successful. The acceptor MUST confirm that a key has been derived (Section 7.10 of [RFC3748]). The acceptor MUST confirm that this success indication is consistent with any protected result indication for combined authenticators and with AAA indication of success for pass-through authenticators. If any of these checks fail, the acceptor MUST send an error subtoken and fail the context establishment. If these checks succeed, the acceptor sends the Success message using the EAP Request subtoken type and transitions to Extensions state. If the initiator receives an EAP
o 如果EAP状态机生成EAP成功消息，则EAP身份验证程序认为身份验证成功。接受者必须确认已获得密钥（RFC3748第7.10节）。接受方必须确认此成功指示与组合验证器的任何受保护结果指示一致，并与通过验证器的AAA成功指示一致。如果这些检查中的任何一个失败，则接受者必须发送一个错误subtoken并使上下文建立失败。如果这些检查成功，则接受者使用EAP Request subtoken类型发送成功消息，并转换为Extensions状态。如果启动器收到EAP
Success message, it confirms that a key has been derived and that the EAP Success is consistent with any protected result indication. If so, it transitions to Extensions state. Otherwise, it returns an error to the caller of GSS_Init_sec_context without producing an output token.
成功消息，它确认已派生密钥，并且EAP成功与任何受保护的结果指示一致。如果是这样，它将转换为扩展状态。否则，它将向GSS_Init_sec_上下文的调用方返回一个错误，而不生成输出令牌。
o If the acceptor receives an EAP failure, then the acceptor sends this in the EAP Request subtoken type. If the initiator receives an EAP Failure, it returns GSS failure.
o 如果接受者接收到EAP失败，则接受者在EAP请求子项类型中发送该失败。如果启动器收到EAP故障，则返回GSS故障。
o If there is some other error, the acceptor MAY return an error subtoken.
o 如果存在其他错误，则接受程序可能会返回错误。
The EAP Request subtoken is sent from the acceptor to the initiator. This subtoken is always critical and is REQUIRED in the authentication state.
EAP请求从接受方发送到发起方。此子项始终是关键的，并且在身份验证状态下是必需的。
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x80000005 |
| | |
| 4..7 | length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x80000005 |
| | |
| 4..7 | length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+
This subtoken is REQUIRED in authentication state messages from the initiator to the acceptor. It is always critical.
在从发起方到接受方的身份验证状态消息中需要此子项。这总是至关重要的。
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x80000004 |
| | |
| 4..7 | length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x80000004 |
| | |
| 4..7 | length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+
After EAP Success, the initiator sends a token to the acceptor including additional subtokens that negotiate optional features or provide GSS-API channel binding (see Section 6.1). The acceptor then responds with a token to the initiator. When the acceptor produces its final token, it returns GSS_S_COMPLETE; when the initiator consumes this token, it returns GSS_S_COMPLETE if no errors are detected.
EAP成功后，发起方向接受方发送令牌，包括协商可选功能或提供GSS-API通道绑定的附加子令牌（见第6.1节）。然后，接受者向发起者发出令牌响应。当接受者产生其最终令牌时，它返回GSS_S_COMPLETE；当启动器使用此令牌时，如果未检测到错误，它将返回GSS_S_COMPLETE。
The acceptor SHOULD send an acceptor name response (Section 5.4.3) so that the initiator can get a copy of the acceptor name protected by the Message Integrity Check (MIC) subtoken.
接受者应发送接受者名称响应（第5.4.3节），以便发起人可以获得受消息完整性检查（MIC）子项保护的接受者名称副本。
Both the initiator and acceptor MUST include and verify a MIC subtoken to protect the extensions exchange.
发起者和接受者都必须包含并验证MIC子项，以保护交换扩展。
This subtoken is sent to convey initiator flags to the acceptor. The flags are sent as a 32-bit integer in network byte order. The only flag defined so far is GSS_C_MUTUAL_FLAG, indicating that the initiator successfully performed mutual authentication of the acceptor. This flag is communicated to the acceptor because some protocols [RFC4462] require the acceptor to know whether the initiator has confirmed its identity. This flag has the value 0x2 to be consistent with RFC 2744.
发送此子项是为了将启动器标志传递给接受者。标志以网络字节顺序作为32位整数发送。到目前为止，唯一定义的标志是GSS_C_MUTUAL_标志，表示发起方成功执行了接受方的相互身份验证。由于某些协议[RFC4462]要求接受者知道发起者是否已确认其身份，因此将此标志传达给接受者。此标志的值0x2与RFC 2744一致。
+-------+-----------------------+
| Pos | Description |
+-------+-----------------------+
| 0..3 | 0x0000000C |
| | |
| 4..7 | length of flags token |
| | |
| 8..11 | flags |
+-------+-----------------------+
+-------+-----------------------+
| Pos | Description |
+-------+-----------------------+
| 0..3 | 0x0000000C |
| | |
| 4..7 | length of flags token |
| | |
| 8..11 | flags |
+-------+-----------------------+
Initiators MUST send 4 octets of flags. Acceptors MUST ignore flag octets beyond the first 4 and MUST ignore flag bits other than GSS_C_MUTUAL_FLAG. Initiators MUST send undefined flag bits as zero.
启动器必须发送4个八位字节的标志。接受者必须忽略前4个以外的标志八位字节，并且必须忽略GSS_C_MUTUAL_标志以外的标志位。启动器必须将未定义的标志位发送为零。
This subtoken is always critical when sent. It is sent from the initiator to the acceptor. The contents of this token are an RFC 3961 get_mic token of the application data from the GSS channel bindings structure passed into the context establishment call.
发送时，此子项始终至关重要。它从发起者发送到接受者。此令牌的内容是来自GSS通道绑定结构的应用程序数据的RFC 3961 get_mic令牌，该应用程序数据被传递到上下文建立调用中。
+-------------+-----------------------------------------------+
| Pos | Description |
+-------------+-----------------------------------------------+
| 0..3 | 0x80000006 |
| | |
| 4..7 | length of token |
| | |
| 8..8+length | get_mic of channel binding application data |
+-------------+-----------------------------------------------+
+-------------+-----------------------------------------------+
| Pos | Description |
+-------------+-----------------------------------------------+
| 0..3 | 0x80000006 |
| | |
| 4..7 | length of token |
| | |
| 8..8+length | get_mic of channel binding application data |
+-------------+-----------------------------------------------+
Again, only the application data is sent in the channel binding. Any initiator and acceptor addresses passed by an application into context establishment calls are ignored and not sent over the wire. The checksum type of the get_mic token SHOULD be the mandatory-to-implement checksum type of the Context Root Key (CRK). The key to use is the CRK and the key usage is 60 (KEY_USAGE_GSSEAP_CHBIND_MIC). An acceptor MAY accept any MIC in the channel bindings subtoken if the channel bindings input to GSS_Accept_sec_context is not provided. If the channel binding input to GSS_Accept_sec_context is provided, the acceptor MUST return failure if the channel binding MIC in a received channel binding subtoken fails to verify.
同样，在通道绑定中只发送应用程序数据。应用程序传递到上下文建立调用中的任何启动器和接收器地址都将被忽略，并且不会通过线路发送。get_mic令牌的校验和类型应该是实现上下文根键（CRK）的校验和类型所必需的。要使用的密钥是CRK，密钥用法是60（密钥用法\u GSSEAP\u CHBIND\u MIC）。如果未提供GSS_accept_sec_上下文的通道绑定输入，则接收器可以接受通道绑定子项中的任何麦克风。如果提供了GSS_Accept_sec_上下文的通道绑定输入，则如果接收到的通道绑定子项中的通道绑定MIC无法验证，则接收器必须返回failure。
The initiator MUST send this token if channel bindings including application data are passed into GSS_Init_sec_context and MUST NOT send this token otherwise.
如果将包含应用程序数据的通道绑定传递到GSS_Init_sec_上下文中，则启动器必须发送此令牌，否则不得发送此令牌。
This subtoken MUST be the last subtoken in the tokens sent in Extensions state. This subtoken is sent both by the initiator and acceptor.
此子项必须是在扩展状态下发送的令牌中的最后一个子项。此子项由发起方和接受方发送。
+-------------+--------------------------------------------------+
| Pos | Description |
+-------------+--------------------------------------------------+
| 0..3 | 0x8000000D for initiator 0x8000000E for acceptor |
| | |
| 4..7 | length of RFC 3961 MIC token |
| | |
| 8..8+length | RFC 3961 result of get_mic |
+-------------+--------------------------------------------------+
+-------------+--------------------------------------------------+
| Pos | Description |
+-------------+--------------------------------------------------+
| 0..3 | 0x8000000D for initiator 0x8000000E for acceptor |
| | |
| 4..7 | length of RFC 3961 MIC token |
| | |
| 8..8+length | RFC 3961 result of get_mic |
+-------------+--------------------------------------------------+
As with any call to get_mic, a token is produced as described in RFC 3961 using the CRK (Section 6) as the key and the mandatory checksum type for the encryption type of the CRK as the checksum type. The key usage is 61 (KEY_USAGE_GSSEAP_ACCTOKEN_MIC) for the subtoken from
与任何获取mic的调用一样，按照RFC 3961中的描述，使用CRK（第6节）作为密钥，使用CRK加密类型的强制校验和类型作为校验和类型，生成令牌。来自的子项的密钥用法为61（密钥用法\u GSSEAP\u ACCTOKEN\u MIC）
the acceptor to the initiator and 62 (KEY_USAGE_GSSEAP_INITTOKEN_MIC) for the subtoken from the initiator to the acceptor. The input is as follows:
从发起者到接受者的接受者和从发起者到接受者的子项的62（密钥使用\u GSSEAP\u INITTOKEN\u MIC）。输入如下：
1. The DER-encoded object identifier of the mechanism in use; this value starts with 0x06 (the tag for object identifier). When encoded in an RFC 2743 context token, the object identifier is preceded by the tag and length for [Application 0] SEQUENCE. This tag and the length of the overall token is not included; only the tag, length, and value of the object identifier itself.
1. 所用机构的DER编码对象标识符；该值以0x06（对象标识符的标记）开始。在RFC 2743上下文标记中编码时，对象标识符前面是[Application 0]序列的标记和长度。不包括该标记和整个令牌的长度；仅对象标识符本身的标记、长度和值。
2. A 16-bit token type in network byte order of the RFC 4121 token identifier (0x0601 for initiator, 0x0602 for acceptor).
2. RFC 4121令牌标识符的网络字节顺序的16位令牌类型（0x0601表示发起方，0x0602表示接受方）。
3. For each subtoken, other than the MIC subtoken itself, the order the subtokens appear in the token is as follows:
3. 对于每个子项，除了MIC子项本身，子项在标记中的显示顺序如下：
4.
4.
1. A four-octet subtoken type in network byte order
1. 按网络字节顺序排列的四个八位字节的子基类型
2. A four-byte length in network byte order
2. 按网络字节顺序排列的四字节长度
3. Length octets of value from that subtoken
3. 来自该子项的值的长度八位字节
+----+------+----+------+-----+-------------------------+
| 60 | 23 | 06 | 09 | 2b | 06 01 05 05 0f 01 01 11 |
+----+------+----+------+-----+-------------------------+
|App0|Token |OID |OID | 1 3 | 6 1 5 5 15 1 1 17 |
|Tag |length|Tag |length| Mechanism object ID |
+----+------+----+------+-------------------------------+
+----+------+----+------+-----+-------------------------+
| 60 | 23 | 06 | 09 | 2b | 06 01 05 05 0f 01 01 11 |
+----+------+----+------+-----+-------------------------+
|App0|Token |OID |OID | 1 3 | 6 1 5 5 15 1 1 17 |
|Tag |length|Tag |length| Mechanism object ID |
+----+------+----+------+-------------------------------+
+----------+-------------+-------------+
| 06 01 | 00 00 00 02 | 00 00 00 0e |
+----------+-------------|-------------|
|Initiator | Acceptor | Length |
|context | name | (14 octets) |
|token ID | request | |
+----------+-------------+-------------+
+----------+-------------+-------------+
| 06 01 | 00 00 00 02 | 00 00 00 0e |
+----------+-------------|-------------|
|Initiator | Acceptor | Length |
|context | name | (14 octets) |
|token ID | request | |
+----------+-------------+-------------+
+-------------------------------------------+
| 68 6f 73 74 2f 6c 6f 63 61 6c 68 6f 73 74 |
+-------------------------------------------+
| String form of acceptor name |
| "host/localhost" |
+-------------------------------------------+
+-------------------------------------------+
| 68 6f 73 74 2f 6c 6f 63 61 6c 68 6f 73 74 |
+-------------------------------------------+
| String form of acceptor name |
| "host/localhost" |
+-------------------------------------------+
Example Initiator Token
示例启动器令牌
GSS-API provides a number of optional per-context services requested by flags on the call to GSS_Init_sec_context and indicated as outputs from both GSS_Init_sec_context and GSS_Accept_sec_context. This section describes how these services are handled. Which services the client selects in the call to GSS_Init_sec_context controls what EAP methods MAY be used by the client. Section 7.2 of RFC 3748 describes a set of security claims for EAP. As described below, the selected GSS options place requirements on security claims that MUST be met.
GSS-API提供了许多可选的每上下文服务，这些服务由调用GSS_Init_sec_context时的标志请求，并指示为GSS_Init_sec_context和GSS_Accept_sec_context的输出。本节介绍如何处理这些服务。客户端在对GSS_Init_sec_上下文的调用中选择的服务控制客户端可能使用的EAP方法。RFC 3748第7.2节描述了EAP的一组安全声明。如下所述，所选GSS选项对必须满足的担保索赔提出了要求。
This GSS mechanism MUST only be used with EAP methods that provide dictionary-attack resistance. Typically, dictionary-attack resistance is obtained by using an EAP tunnel method to tunnel an inner method in TLS.
此GSS机制只能与提供字典攻击抵抗能力的EAP方法一起使用。通常，字典攻击抵抗是通过使用EAP隧道方法来隧道TLS中的内部方法来获得的。
The EAP method MUST support key derivation. Integrity, confidentiality, sequencing, and replay detection MUST be indicated in the output of GSS_Init_sec_context and GSS_Accept_sec_context regardless of which services are requested.
EAP方法必须支持密钥派生。完整性、机密性、排序和重播检测必须在GSS_Init_secu_上下文和GSS_Accept_secu_上下文的输出中指明，无论请求的是什么服务。
The PROT_READY service defined in Section 1.2.7 of [RFC2743] is never available with this mechanism. Implementations MUST NOT offer this flag or permit per-message security services to be used before context establishment.
[RFC2743]第1.2.7节中定义的PROT_就绪服务永远不可用于此机制。实现不得提供此标志或允许在建立上下文之前使用每消息安全服务。
The EAP method MUST support mutual authentication and channel binding. See Section 3.4 for details on what is required for successful mutual authentication. Regardless of whether mutual authentication is requested, the implementation MUST include channel bindings in the EAP authentication. If mutual authentication is requested and successful mutual authentication takes place as defined in Section 3.4, the initiator MUST send a flags subtoken Section 5.6.1 in Extensions state.
EAP方法必须支持相互身份验证和通道绑定。有关成功相互认证所需的详细信息，请参见第3.4节。无论是否请求相互身份验证，实现都必须在EAP身份验证中包含通道绑定。如果请求相互认证，并且按照第3.4节中的定义成功进行了相互认证，则发起方必须在扩展状态下发送第5.6.1节中的标记。
The context establishment process may be passed through to an EAP server via a backend authentication protocol. However, after the EAP authentication succeeds, security services are provided directly by the acceptor.
上下文建立过程可以通过后端认证协议传递给EAP服务器。然而，EAP认证成功后，安全服务直接由接受者提供。
This mechanism uses an RFC 3961 cryptographic key called the Context Root Key (CRK). The CRK is derived from the GMSK (GSS-API Master Session Key). The GMSK is the result of the random-to-key [RFC3961] operation of the encryption type of this mechanism consuming the
此机制使用RFC 3961加密密钥，称为上下文根密钥（CRK）。CRK源自GMSK（GSS-API主会话密钥）。GMSK是该机制的加密类型的随机转密钥[RFC3961]操作的结果，该机制使用
appropriate number of bits from the EAP MSK. For example, for aes128-cts-hmac-sha1-96, the random-to-key operation consumes 16 octets of key material; thus, the first 16 bytes of the MSK are input to random-to-key to form the GMSK. If the MSK is too short, authentication MUST fail.
来自EAP MSK的适当位数。例如，对于aes128-cts-hmac-sha1-96，随机到键操作消耗16个八位组的键材料；因此，MSK的前16个字节被输入到random to key以形成GMSK。如果MSK太短，则身份验证必须失败。
In the following, pseudorandom is the RFC 3961 pseudorandom operation for the encryption type of the GMSK and random-to-key is the RFC 3961 random-to-key operation for the enctype of the mechanism. The truncate function takes the initial l bits of its input. The goal in constructing a CRK is to call the pseudorandom function enough times to produce the right number of bits of output and discard any excess bits of output.
在下文中，伪随机是用于GMSK的加密类型的RFC 3961伪随机操作，而随机到密钥是用于该机制的加密类型的RFC 3961随机到密钥操作。truncate函数接受其输入的初始l位。构造CRK的目标是调用伪随机函数足够多次，以产生正确数量的输出比特，并丢弃多余的输出比特。
The CRK is derived from the GMSK using the following procedure:
CRK是使用以下程序从GMSK导出的：
Tn = pseudorandom(GMSK, n || "rfc4121-gss-eap")
CRK = random-to-key(truncate(L, T0 || T1 || .. || Tn))
L = random-to-key input size
Tn = pseudorandom(GMSK, n || "rfc4121-gss-eap")
CRK = random-to-key(truncate(L, T0 || T1 || .. || Tn))
L = random-to-key input size
Where n is a 32-bit integer in network byte order starting at 0 and incremented to each call to the pseudo_random operation.
其中，n是网络字节顺序的32位整数，从0开始，每次调用伪随机操作时递增。
GSS-API channel binding [RFC5554] is a protected facility for exchanging a cryptographic name for an enclosing channel between the initiator and acceptor. The initiator sends channel binding data and the acceptor confirms that channel binding data has been checked.
GSS-API通道绑定[RFC5554]是一种受保护的工具，用于在发起方和接受方之间为封闭通道交换加密名称。发起方发送通道绑定数据，接受方确认已检查通道绑定数据。
The acceptor SHOULD accept any channel binding provided by the initiator if null channel bindings are passed into gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] depend on this behavior of some Kerberos implementations.
如果将空通道绑定传递到gss_accept_sec_上下文中，则接受方应接受发起方提供的任何通道绑定。HTTP协商[RFC4559]等协议依赖于某些Kerberos实现的这种行为。
As discussed, the GSS channel bindings subtoken is sent in the Extensions state.
如前所述，GSS通道绑定在Extensions状态下发送。
The per-message tokens of Section 4 of RFC 4121 are used. The CRK SHALL be treated as the initiator sub-session key, the acceptor sub-session key and the ticket session key.
使用RFC 4121第4节的每消息令牌。CRK应被视为发起方子会话密钥、接收方子会话密钥和票据会话密钥。
The pseudorandom function defined in [RFC4402] is used to provide GSS_Pseudo_Random functionality to applications.
[RFC4402]中定义的伪随机函数用于向应用程序提供GSS_伪_随机功能。
This specification creates a number of IANA registries.
本规范创建了许多IANA注册表。
IANA has created a registry of ABFAB object identifiers titled "Object Identifiers for Application Bridging for Federated Access". The initial contents of the registry are specified below. The registration policy is IETF Review or IESG Approval [RFC5226]. Early allocation is permitted. IANA has updated the reference for the root of this OID delegation to point to the newly created registry.
IANA已经创建了一个ABFAB对象标识符注册表，名为“用于联邦访问的应用程序桥接的对象标识符”。注册表的初始内容如下所示。注册政策为IETF审查或IESG批准[RFC5226]。允许提前分配。IANA已更新此OID委派根的引用，以指向新创建的注册表。
Decimal Name Description References
------- ---- ---------------------------------- ----------
0 Reserved Reserved RFC 7055
1 mechanisms A sub-arc containing ABFAB RFC 7055
mechanisms
2 nametypes A sub-arc containing ABFAB RFC 7055
GSS-API Name Types
Decimal Name Description References
------- ---- ---------------------------------- ----------
0 Reserved Reserved RFC 7055
1 mechanisms A sub-arc containing ABFAB RFC 7055
mechanisms
2 nametypes A sub-arc containing ABFAB RFC 7055
GSS-API Name Types
Prefix: iso.org.dod.internet.security.mechanisms.abfab (1.3.6.1.5.5.15)
前缀：iso.org.dod.internet.security.mechanism.abfab（1.3.6.1.5.5.15）
NOTE: the following mechanisms registry is the root of the OID for the mechanism in question. As discussed in Section 5.1, a Kerberos encryption type number [RFC3961] is appended to the mechanism version OID below to form the OID of a specific mechanism.
注意：以下机制注册表是相关机制的OID的根。如第5.1节所述，将Kerberos加密类型号[RFC3961]附加到下面的机制版本OID中，以形成特定机制的OID。
Prefix: iso.org.dod.internet.security.mechanisms.abfab.mechanisms (1.3.6.1.5.5.15.1)
前缀：iso.org.dod.internet.security.mechanism.abfab.mechanism（1.3.6.1.5.5.15.1）
Decimal Name Description References
------- ---- ------------------------------- ----------
0 Reserved Reserved RFC 7055
1 gss-eap-v1 The GSS-EAP mechanism RFC 7055
Decimal Name Description References
------- ---- ------------------------------- ----------
0 Reserved Reserved RFC 7055
1 gss-eap-v1 The GSS-EAP mechanism RFC 7055
Prefix: iso.org.dod.internet.security.mechanisms.abfab.nametypes (1.3.6.1.5.5.15.2)
前缀：iso.org.dod.internet.security.mechanism.abfab.nametypes（1.3.6.1.5.5.15.2）
Decimal Name Description References
------- ---- --------------------- ----------
0 Reserved Reserved RFC 7055
1 GSS_EAP_NT_EAP_NAME RFC 7055, Section 3.1
Decimal Name Description References
------- ---- --------------------- ----------
0 Reserved Reserved RFC 7055
1 GSS_EAP_NT_EAP_NAME RFC 7055, Section 3.1
In the top-level registry titled "Kerberos V GSS-API Mechanism Parameters", a subregistry called "Kerberos GSS-API Token Type Identifiers" was created; the references for this subregistry are RFC 4121 and this document. The allocation procedure is Expert Review [RFC5226]. The Expert's primary job is to make sure that token type identifiers are requested by an appropriate requester for the RFC 4121 mechanism in which they will be used and that multiple values are not allocated for the same purpose. For RFC 4121 and this mechanism, the Expert is currently expected to make allocations for token identifiers from documents in the IETF stream; effectively, for these mechanisms, the Expert currently confirms the allocation meets the requirements of the IETF Review process.
在名为“Kerberos V GSS-API机制参数”的顶级注册表中，创建了名为“Kerberos GSS-API令牌类型标识符”的子域；本次区域的参考文献为RFC 4121和本文件。分配程序为专家评审[RFC5226]。专家的主要工作是确保令牌类型标识符由RFC 4121机制的适当请求者请求，在RFC 4121机制中将使用令牌类型标识符，并且不为相同目的分配多个值。对于RFC 4121和该机制，专家当前期望从IETF流中的文档中为令牌标识符进行分配；实际上，对于这些机制，专家目前确认分配符合IETF审查过程的要求。
The ID field is a hexadecimal token identifier specified in network byte order.
ID字段是以网络字节顺序指定的十六进制令牌标识符。
The initial registrations are as follows:
初步注册情况如下：
+-------+-------------------------------+---------------------------+
| ID | Description | Reference |
+-------+-------------------------------+---------------------------+
| 01 00 | KRB_AP_REQ | RFC 4121, Section 4.1 |
| | | |
| 02 00 | KRB_AP_REP | RFC 4121, Section 4.1 |
| | | |
| 03 00 | KRB_ERROR | RFC 4121, Section 4.1 |
| | | |
| 04 04 | MIC tokens | RFC 4121, Section 4.2.6.1 |
| | | |
| 05 04 | wrap tokens | RFC 4121, Section 4.2.6.2 |
| | | |
| 06 01 | GSS-EAP initiator context | RFC 7055, Section 5 |
| | token | |
| | | |
| 06 02 | GSS EAP acceptor context | RFC 7055, Section 5 |
| | token | |
+-------+-------------------------------+---------------------------+
+-------+-------------------------------+---------------------------+
| ID | Description | Reference |
+-------+-------------------------------+---------------------------+
| 01 00 | KRB_AP_REQ | RFC 4121, Section 4.1 |
| | | |
| 02 00 | KRB_AP_REP | RFC 4121, Section 4.1 |
| | | |
| 03 00 | KRB_ERROR | RFC 4121, Section 4.1 |
| | | |
| 04 04 | MIC tokens | RFC 4121, Section 4.2.6.1 |
| | | |
| 05 04 | wrap tokens | RFC 4121, Section 4.2.6.2 |
| | | |
| 06 01 | GSS-EAP initiator context | RFC 7055, Section 5 |
| | token | |
| | | |
| 06 02 | GSS EAP acceptor context | RFC 7055, Section 5 |
| | token | |
+-------+-------------------------------+---------------------------+
This document creates a top-level registry called "The Extensible Authentication Protocol Mechanism for the Generic Security Service Application Programming Interface (GSS-EAP) Parameters". In any short form of that name, including any URI for this registry, it is important that the string GSS come before the string EAP; this will
本文档创建了一个顶级注册表，名为“通用安全服务应用程序编程接口（GSS-EAP）参数的可扩展身份验证协议机制”。在该名称的任何简短形式中，包括此注册表的任何URI，字符串GSS必须位于字符串EAP之前；这将
help to distinguish registries if EAP methods for performing GSS-API authentication are ever defined.
如果定义了用于执行GSS-API身份验证的EAP方法，则有助于区分注册表。
In this registry is a subregistry of subtoken types. Identifiers are 32-bit integers; the upper bit (0x80000000) is reserved as a critical flag and should not be indicated in the registration. Assignments of GSS-EAP subtoken types are made by Expert Review [RFC5226]. The Expert is expected to require a public specification of the subtoken similar in detail to registrations given in this document. The security of GSS-EAP depends on making sure that subtoken information has adequate protection and that the overall mechanism continues to be secure. Examining the security and architectural consistency of the proposed registration is the primary responsibility of the Expert.
在该注册表中，有一个子目录类型。标识符是32位整数；高位（0x8000000）保留为关键标志，不应在注册中显示。GSS-EAP子项类型的分配由专家评审[RFC5226]完成。专家要求提供类似于本文件中给出的注册详细信息的subtoken公开规范。GSS-EAP的安全性取决于确保信息得到充分保护，并且整个机制继续保持安全。审查拟议注册的安全性和架构一致性是专家的主要责任。
+------------+--------------------------+---------------+
| Type | Description | Reference |
+------------+--------------------------+---------------+
| 0x00000001 | Error | Section 5.3 |
| | | |
| 0x0000000B | Vendor | Section 5.4.1 |
| | | |
| 0x00000002 | Acceptor name request | Section 5.4.2 |
| | | |
| 0x00000003 | Acceptor name response | Section 5.4.3 |
| | | |
| 0x00000005 | EAP request | Section 5.5.1 |
| | | |
| 0x00000004 | EAP response | Section 5.5.2 |
| | | |
| 0x0000000C | Flags | Section 5.6.1 |
| | | |
| 0x00000006 | GSS-API channel bindings | Section 5.6.2 |
| | | |
| 0x0000000D | Initiator MIC | Section 5.6.3 |
| | | |
| 0x0000000E | Acceptor MIC | Section 5.6.3 |
+------------+--------------------------+---------------+
+------------+--------------------------+---------------+
| Type | Description | Reference |
+------------+--------------------------+---------------+
| 0x00000001 | Error | Section 5.3 |
| | | |
| 0x0000000B | Vendor | Section 5.4.1 |
| | | |
| 0x00000002 | Acceptor name request | Section 5.4.2 |
| | | |
| 0x00000003 | Acceptor name response | Section 5.4.3 |
| | | |
| 0x00000005 | EAP request | Section 5.5.1 |
| | | |
| 0x00000004 | EAP response | Section 5.5.2 |
| | | |
| 0x0000000C | Flags | Section 5.6.1 |
| | | |
| 0x00000006 | GSS-API channel bindings | Section 5.6.2 |
| | | |
| 0x0000000D | Initiator MIC | Section 5.6.3 |
| | | |
| 0x0000000E | Acceptor MIC | Section 5.6.3 |
+------------+--------------------------+---------------+
The following RADIUS attribute type values [RFC3575] are assigned. The allocation instructions in Section 10.3 of [RFC6929] have been followed.
分配了以下半径属性类型值[RFC3575]。已遵循[RFC6929]第10.3节中的分配说明。
+--------------------------------+-------+--------------------------+
| Description | Value | More Information |
+--------------------------------+-------+--------------------------+
| GSS-Acceptor-Service-Name | 164 | user-or-service portion |
| | | of name |
| | | |
| GSS-Acceptor-Host-Name | 165 | host portion of name |
| | | |
| GSS-Acceptor-Service-Specifics | 166 | service-specifics |
| | | portion of name |
| | | |
| GSS-Acceptor-Realm-Name | 167 | Realm portion of name |
+--------------------------------+-------+--------------------------+
+--------------------------------+-------+--------------------------+
| Description | Value | More Information |
+--------------------------------+-------+--------------------------+
| GSS-Acceptor-Service-Name | 164 | user-or-service portion |
| | | of name |
| | | |
| GSS-Acceptor-Host-Name | 165 | host portion of name |
| | | |
| GSS-Acceptor-Service-Specifics | 166 | service-specifics |
| | | portion of name |
| | | |
| GSS-Acceptor-Realm-Name | 167 | Realm portion of name |
+--------------------------------+-------+--------------------------+
Subject: Registration of SASL mechanisms EAP-AES128 and EAP-AES128-PLUS
主题：SASL机构EAP-AES128和EAP-AES128-PLUS的注册
SASL mechanism names: EAP-AES128 and EAP-AES128-PLUS
SASL机制名称：EAP-AES128和EAP-AES128-PLUS
Security considerations: See RFC 5801 and RFC 7055
安全注意事项：参见RFC 5801和RFC 7055
Published specification (recommended): RFC 7055
已发布规范（推荐）：RFC 7055
Person & email address to contact for further information: Abfab Working Group, abfab@ietf.org
联系人和电子邮件地址，以获取更多信息：Abfab工作组，abfab@ietf.org
Intended usage: common
预期用途：普通
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
Note: This mechanism describes the GSS-EAP mechanism used with the aes128-cts-hmac-sha1-96 enctype. The GSS-API OID for this mechanism is 1.3.6.1.5.5.15.1.1.17.
注：该机制描述了与aes128-cts-hmac-sha1-96 enctype一起使用的GSS-EAP机制。该机构的GSS-API OID为1.3.6.1.5.5.15.1.1.17。
As described in RFC 5801, a PLUS variant of this mechanism is also required.
如RFC 5801中所述，还需要该机制的一个PLUS变体。
A new subregistry is created in the GSS-EAP parameters registry titled "GSS-EAP Error Codes". The error codes in this registry are unsigned 32-bit numbers. Values less than or equal to 127 are assigned by Standards Action [RFC5226]. Values 128 through 255 are assigned with the Specification Required assignment policy [RFC5226].
在GSS-EAP参数注册表中创建了一个名为“GSS-EAP错误代码”的新子区域。此注册表中的错误代码是无符号32位数字。小于或等于127的值由标准行动[RFC5226]分配。值128到255使用规范要求的分配策略[RFC5226]进行分配。
Values greater than 255 are reserved; updates to registration policy may make these values available for assignment and implementations MUST be prepared to receive them.
保留大于255的值；对注册策略的更新可能会使这些值可用于分配，而实现必须准备好接收这些值。
This table provides the initial contents of the registry.
此表提供注册表的初始内容。
+-------+------------------------------------------------+
| Value | Description |
+-------+------------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Buffer is incorrect size |
| | |
| 2 | Incorrect mechanism OID |
| | |
| 3 | Token is corrupted |
| | |
| 4 | Token is truncated |
| | |
| 5 | Packet received by direction that sent it |
| | |
| 6 | Incorrect token type identifier |
| | |
| 7 | Unhandled critical subtoken received |
| | |
| 8 | Missing required subtoken |
| | |
| 9 | Duplicate subtoken type |
| | |
| 10 | Received unexpected subtoken for current state |
| | |
| 11 | EAP did not produce a key |
| | |
| 12 | EAP key too short |
| | |
| 13 | Authentication rejected |
| | |
| 14 | AAA returned an unexpected message type |
| | |
| 15 | AAA response did not include EAP request |
| | |
| 16 | Generic AAA failure |
+-------+------------------------------------------------+
+-------+------------------------------------------------+
| Value | Description |
+-------+------------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Buffer is incorrect size |
| | |
| 2 | Incorrect mechanism OID |
| | |
| 3 | Token is corrupted |
| | |
| 4 | Token is truncated |
| | |
| 5 | Packet received by direction that sent it |
| | |
| 6 | Incorrect token type identifier |
| | |
| 7 | Unhandled critical subtoken received |
| | |
| 8 | Missing required subtoken |
| | |
| 9 | Duplicate subtoken type |
| | |
| 10 | Received unexpected subtoken for current state |
| | |
| 11 | EAP did not produce a key |
| | |
| 12 | EAP key too short |
| | |
| 13 | Authentication rejected |
| | |
| 14 | AAA returned an unexpected message type |
| | |
| 15 | AAA response did not include EAP request |
| | |
| 16 | Generic AAA failure |
+-------+------------------------------------------------+
A new subregistry is created in the GSS-EAP parameters registry. This registry holds registrations of flag bits sent in the flags subtoken (Section 5.6.1). There are 32 flag bits available for registration represented as hexadecimal numbers from the most significant bit 0x80000000 to the least significant bit 0x1. The registration policy for this registry is IETF Review or, in exceptional cases, IESG Approval. The following table indicates initial registrations; all other values are available for assignment.
在GSS-EAP参数注册表中创建一个新的子区域。该注册表保存在标志子目录中发送的标志位的注册（第5.6.1节）。从最高有效位0x8000000到最低有效位0x1，有32个标志位可用于注册，表示为十六进制数。该注册中心的注册政策是IETF审查，或在特殊情况下，IESG批准。下表显示了初始注册；所有其他值都可用于赋值。
+------+-------------------+---------------+
| Flag | Name | Reference |
+------+-------------------+---------------+
| 0x2 | GSS_C_MUTUAL_FLAG | Section 5.6.1 |
+------+-------------------+---------------+
+------+-------------------+---------------+
| Flag | Name | Reference |
+------+-------------------+---------------+
| 0x2 | GSS_C_MUTUAL_FLAG | Section 5.6.1 |
+------+-------------------+---------------+
RFC 3748 discusses security issues surrounding EAP. RFC 5247 discusses the security and requirements surrounding key management that leverages the AAA infrastructure. These documents are critical to the security analysis of this mechanism.
RFC3748讨论了围绕EAP的安全问题。RFC 5247讨论了围绕利用AAA基础架构的密钥管理的安全性和要求。这些文档对于该机制的安全性分析至关重要。
RFC 2743 discusses generic security considerations for the GSS-API. RFC 4121 discusses security issues surrounding the specific per-message services used in this mechanism.
RFC 2743讨论了GSS-API的一般安全注意事项。RFC4121讨论了围绕此机制中使用的特定每消息服务的安全问题。
As discussed in Section 4, this mechanism may introduce multiple layers of security negotiation into application protocols. Multiple layer negotiations are vulnerable to a bid-down attack when a mechanism negotiated at the outer layer is preferred to some but not all mechanisms negotiated at the inner layer; see Section 7.3 of [RFC4462] for an example. One possible approach to mitigate this attack is to construct security policy such that the preference for all mechanisms negotiated in the inner layer falls between preferences for two outer-layer mechanisms or falls at one end of the overall ranked preferences including both the inner and outer layer. Another approach is to only use this mechanism when it has specifically been selected for a given service. The second approach is likely to be common in practice because one common deployment will involve an EAP supplicant interacting with a user to select a given identity. Only when an identity is successfully chosen by the user will this mechanism be attempted.
如第4节所述，该机制可能会在应用程序协议中引入多层安全协商。当在外层协商的机制优于在内层协商的一些但不是所有机制时，多层协商容易受到向下出价攻击；示例见[RFC4462]第7.3节。缓解此攻击的一种可能方法是构造安全策略，使得内层中协商的所有机制的首选项位于两个外层机制的首选项之间，或者位于包括内层和外层的总体排序首选项的一端。另一种方法是仅在为给定服务专门选择该机制时使用该机制。第二种方法在实践中可能很常见，因为一种常见的部署将涉及EAP请求者与用户交互以选择给定的身份。只有当用户成功选择标识时，才会尝试此机制。
EAP channel binding is used to give the GSS-API initiator confidence in the identity of the GSS-API acceptor. Thus, the security of this mechanism depends on the use and verification of EAP channel binding.
EAP通道绑定用于使GSS-API启动器对GSS-API接受者的身份有信心。因此，该机制的安全性取决于EAP通道绑定的使用和验证。
Today, EAP channel binding is in very limited deployment. If EAP channel binding is not used, then the system may be vulnerable to phishing attacks where a user is diverted from one service to another. If the EAP method in question supports mutual authentication then users can only be diverted between servers that are part of the same AAA infrastructure. For deployments where membership in the AAA infrastructure is limited, this may serve as a significant limitation on the value of phishing as an attack. For other deployments, use of EAP channel binding is critical to avoid phishing. These attacks are possible with EAP today although not typically with common GSS-API mechanisms. For this reason, implementations are required to implement and use EAP channel binding; see Section 3 for details.
今天，EAP通道绑定的部署非常有限。如果未使用EAP通道绑定，则当用户从一个服务转移到另一个服务时，系统可能容易受到钓鱼攻击。如果所讨论的EAP方法支持相互认证，那么用户只能在属于同一AAA基础设施的服务器之间转移。对于AAA基础架构成员资格有限的部署，这可能会严重限制网络钓鱼作为攻击的价值。对于其他部署，使用EAP通道绑定对于避免网络钓鱼至关重要。这些攻击在今天的EAP中是可能的，尽管通常不使用常见的GSS-API机制。因此，需要实现并使用EAP通道绑定；详见第3节。
The security considerations of EAP channel binding [RFC6677] describe the security properties of channel binding. Two attacks are worth calling out here. First, when a tunneled EAP method is used, it is critical that the channel binding be performed with an EAP server trusted by the peer. With existing EAP methods, this typically requires validating the certificate of the server tunnel endpoint back to a trust anchor and confirming the name of the entity who is a subject of that certificate. EAP methods may suffer from bid-down attacks where an attacker can cause a peer to think that a particular EAP server does not support channel binding. This does not directly cause a problem because mutual authentication is only offered at the GSS-API level when channel binding to the server's identity is successful. However, when an EAP method is not vulnerable to these bid-down attacks, additional protection is available. This mechanism will benefit significantly from new strong EAP methods such as [TEAP].
EAP通道绑定的安全注意事项[RFC6677]描述了通道绑定的安全属性。这里有两次攻击值得一提。首先，当使用隧道EAP方法时，必须使用对等方信任的EAP服务器执行通道绑定。对于现有EAP方法，这通常需要将服务器隧道端点的证书验证回信任锚点，并确认作为该证书主体的实体的名称。EAP方法可能遭受向下出价攻击，攻击者可导致对等方认为特定EAP服务器不支持通道绑定。这不会直接导致问题，因为只有在与服务器标识的通道绑定成功时，才在GSS-API级别提供相互身份验证。但是，当EAP方法不易受到这些下标攻击时，可以提供额外的保护。这一机制将大大受益于新的强有力的EAP方法，如[TEAP]。
Every proxy in the AAA chain from the authenticator to the EAP server needs to be trusted to help verify channel bindings and to protect the integrity of key material. GSS-API applications may be built to assume a trust model where the acceptor is directly responsible for authentication. However, GSS-API is definitely used with trusted-third-party mechanisms such as Kerberos.
AAA链中从认证器到EAP服务器的每个代理都需要受信任，以帮助验证通道绑定并保护密钥材料的完整性。GSS-API应用程序的构建可以假定一个信任模型，其中接受方直接负责身份验证。但是，GSS-API肯定与受信任的第三方机制（如Kerberos）一起使用。
RADIUS does provide a weak form of hop-by-hop confidentiality of key material based on using MD5 as a stream cipher. Diameter can use TLS or IPsec but has no mandatory-to-implement confidentiality mechanism. Operationally, protecting key material as it is transported between the Identity Provider (IdP) and Relying Party (RP) is critical to per-message security and verification of GSS-API channel binding [RFC5056]. Mechanisms such as RADIUS over TLS [RFC6614] provide significantly better protection of key material than the base RADIUS specification.
RADIUS在使用MD5作为流密码的基础上，提供了一种弱形式的密钥资料逐跳保密性。Diameter可以使用TLS或IPsec，但不强制实施保密机制。在操作上，保护在身份提供者（IdP）和依赖方（RP）之间传输的关键材料对于GSS-API通道绑定的每条消息安全和验证至关重要[RFC5056]。诸如TLS上的半径[RFC6614]等机制对关键材料的保护明显优于基本半径规范。
Luke Howard, Jim Schaad, Alejandro Perez Mendez, Alexey Melnikov, and Sujing Zhou provided valuable reviews of this document.
卢克·霍华德（Luke Howard）、吉姆·沙德（Jim Schaad）、亚历杭德罗·佩雷斯·门德斯（Alejandro Perez Melnez）、阿列克谢·梅尔尼科夫（Alexey Melnikov）和周苏静（Sujing Zhou）对该文件进行了有价值的。
Rhys Smith provided the text for the OID registry section. Sam Hartman's work on this document has been funded by JANET.
Rhys Smith为OID注册表部分提供了文本。山姆·哈特曼在这份文件上的工作得到了珍妮特的资助。
[GSS-IANA] IANA, "GSS-API Service Name Registry", <http://www.iana.org/assignments/gssapi-service-names>.
[GSS-IANA]IANA，“GSS-API服务名称注册表”<http://www.iana.org/assignments/gssapi-service-names>.
[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月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC2744]Wray，J.，“通用安全服务API第2版：C-绑定”，RFC 2744，2000年1月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575]Aboba，B.“RADIUS（远程认证拨入用户服务）的IANA注意事项”，RFC 3575，2003年7月。
[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月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，2005年2月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 41212005年7月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4401]Williams，N.，“通用安全服务应用程序接口（GSS-API）的伪随机函数（PRF）API扩展”，RFC4401，2006年2月。
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", RFC 4402, February 2006.
[RFC4402]Williams，N.，“Kerberos V通用安全服务应用程序接口（GSS-API）机制的伪随机函数（PRF）”，RFC4402，2006年2月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5554] Williams, N., "Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings", RFC 5554, May 2009.
[RFC5554]Williams，N.“用于通道绑定的通用安全服务应用程序接口（GSS-API）的澄清和扩展”，RFC 5554，2009年5月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[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月。
[RFC7057] Winter, S. and J. Salowey, "Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)", RFC 7057, December 2013.
[RFC7057]Winter，S.和J.Salowey，“可扩展身份验证协议（EAP）适用性声明的更新，用于Web之外联邦访问的应用程序桥接（ABFAB）”，RFC 7057，2013年12月。
[ABFAB-ARCH] Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Work in Progress, July 2013.
[ABFAB-ARCH]Howlett，J.，Hartman，S.，Tschofenig，H.，Lear，E.，和J.Schaad，“Web之外的联邦访问（ABFAB）体系结构的应用程序桥接”，正在进行的工作，2013年7月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005.
[RFC4178]Zhu，L.，Leach，P.，Jaganathan，K.，和W.Ingersoll，“简单和受保护的通用安全服务应用程序接口（GSS-API）协商机制”，RFC 4178，2005年10月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC4462]Hutzelman，J.，Salowey，J.，Galbraith，J.，和V.Welch，“安全壳（SSH）协议的通用安全服务应用程序接口（GSS-API）认证和密钥交换”，RFC 4462，2006年5月。
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, June 2006.
[RFC4559]Jaganathan，K.，Zhu，L.，和J.Brezak，“Microsoft Windows中基于SPNEGO的Kerberos和NTLM HTTP身份验证”，RFC 4559，2006年6月。
[RFC5178] Williams, N. and A. Melnikov, "Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type", RFC 5178, May 2008.
[RFC5178]Williams，N.和A.Melnikov，“通用安全服务应用程序接口（GSS-API）国际化和基于域的服务名称和名称类型”，RFC 5178，2008年5月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，2008年8月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，2012年5月。
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.
[RFC6929]DeKok，A.和A.Lior，“远程身份验证拨入用户服务（RADIUS）协议扩展”，RFC 69292013年4月。
[TEAP] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel EAP Method (TEAP) Version 1", Work in Progress, September 2013.
[TEAP]Zhou，H.，Cam Winget，N.，Salowey，J.，和S.Hanna，“隧道EAP方法（TEAP）第1版”，正在进行的工作，2013年9月。
As described in Section 3.4, RADIUS attributes are used to carry the acceptor name when this family of mechanisms is used with RADIUS. Prior to the publication of this specification, a vendor-specific RADIUS attribute was used. This non-normative appendix documents that attribute as it may be seen from older implementations.
如第3.4节所述，当该系列机构与RADIUS一起使用时，RADIUS属性用于承载接受者名称。在本规范发布之前，使用了特定于供应商的RADIUS属性。本非规范性附录记录了从较旧的实现中可以看到的属性。
Prior to IANA assignment, GSS-EAP used a RADIUS vendor-specific attribute for carrying the acceptor name. The Vendor-Specific Attribute (VSA) with enterprise ID 25622 is formatted as a VSA according to the recommendation in the RADIUS specification. The following sub-attributes are defined:
在IANA分配之前，GSS-EAP使用RADIUS供应商特定属性来携带接受者名称。根据RADIUS规范中的建议，企业ID为25622的供应商特定属性（VSA）被格式化为VSA。定义了以下子属性：
+--------------------------------+-----------+----------------------+
| Name | Attribute | Description |
+--------------------------------+-----------+----------------------+
| GSS-Acceptor-Service-Name | 128 | user-or-service |
| | | portion of name |
| | | |
| GSS-Acceptor-Host-Name | 129 | host portion of name |
| | | |
| GSS-Acceptor-Service-Specifics | 130 | service-specifics |
| | | portion of name |
| | | |
| GSS-Acceptor-Realm-Name | 131 | Realm portion of |
| | | name |
+--------------------------------+-----------+----------------------+
+--------------------------------+-----------+----------------------+
| Name | Attribute | Description |
+--------------------------------+-----------+----------------------+
| GSS-Acceptor-Service-Name | 128 | user-or-service |
| | | portion of name |
| | | |
| GSS-Acceptor-Host-Name | 129 | host portion of name |
| | | |
| GSS-Acceptor-Service-Specifics | 130 | service-specifics |
| | | portion of name |
| | | |
| GSS-Acceptor-Realm-Name | 131 | Realm portion of |
| | | name |
+--------------------------------+-----------+----------------------+
Authors' Addresses
作者地址
Sam Hartman (editor) Painless Security
山姆·哈特曼（编辑）无痛安全
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Josh Howlett JANET(UK)
Josh Howlett JANET（英国）
EMail: josh.howlett@ja.net
EMail: josh.howlett@ja.net