Internet Engineering Task Force (IETF) J. Howlett
Request for Comments: 7831 Jisc
Category: Informational S. Hartman
ISSN: 2070-1721 Painless Security
H. Tschofenig
ARM Ltd.
J. Schaad
August Cellars
May 2016
Internet Engineering Task Force (IETF) J. Howlett
Request for Comments: 7831 Jisc
Category: Informational S. Hartman
ISSN: 2070-1721 Painless Security
H. Tschofenig
ARM Ltd.
J. Schaad
August Cellars
May 2016
Application Bridging for Federated Access Beyond Web (ABFAB) Architecture
用于超越Web的联合访问（ABFAB）体系结构的应用程序桥接
Abstract
摘要
Over the last decade, a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common.
在过去十年中，在联邦访问管理领域进行了大量的工作。这项工作主要集中在两个用例上：网络访问和基于web的访问。然而，已经提出并部署的这些用例的解决方案往往很少有共同的构建块。
This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non-federated access management, including the Remote Authentication Dial-In User Service (RADIUS), the Generic Security Service Application Program Interface (GSS-API), the Extensible Authentication Protocol (EAP), and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of Identity Providers, Relying Parties, and federations.
本备忘录描述了一种体系结构，该体系结构利用对联邦和非联邦访问管理常用安全机制的扩展，包括远程身份验证拨入用户服务（RADIUS）、通用安全服务应用程序接口（GSS-API）、可扩展身份验证协议（EAP），以及安全断言标记语言（SAML）。该体系结构解决了对主要基于非web的服务的联合访问管理问题，其方式将扩展到大量身份提供者、依赖方和联合体。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7831.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7831.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................4
1.1. Terminology ................................................5
1.1.1. Channel Binding .....................................6
1.2. An Overview of Federation ..................................8
1.3. Challenges for Contemporary Federation ....................11
1.4. An Overview of ABFAB-Based Federation .....................11
1.5. Design Goals ..............................................14
2. Architecture ...................................................15
2.1. Relying Party to Identity Provider ........................16
2.1.1. AAA, RADIUS, and Diameter ..........................17
2.1.2. Discovery and Rules Determination ..................19
2.1.3. Routing and Technical Trust ........................20
2.1.4. AAA Security .......................................21
2.1.5. SAML Assertions ....................................22
2.2. Client to Identity Provider ...............................24
2.2.1. Extensible Authentication Protocol (EAP) ...........24
2.2.2. EAP Channel Binding ................................26
2.3. Client to Relying Party ...................................26
2.3.1. GSS-API ............................................27
2.3.2. Protocol Transport .................................28
2.3.3. Re-authentication ..................................29
3. Application Security Services ..................................29
3.1. Authentication ............................................29
3.2. GSS-API Channel Binding ...................................31
3.3. Host-Based Service Names ..................................32
3.4. Additional GSS-API Services ...............................33
4. Privacy Considerations .........................................34
4.1. Entities and Their Roles ..................................35
4.2. Privacy Aspects of ABFAB Communication Flows ..............36
4.2.1. Client to RP .......................................36
4.2.2. Client to IdP (via Federation Substrate) ...........37
4.2.3. IdP to RP (via Federation Substrate) ...............38
4.3. Relationship between User and Entities ....................39
4.4. Accounting Information ....................................39
4.5. Collection and Retention of Data and Identifiers ..........39
4.6. User Participation ........................................40
5. Security Considerations ........................................40
6. References .....................................................41
6.1. Normative References ......................................41
6.2. Informative References ....................................42
Acknowledgments ...................................................46
Authors' Addresses ................................................46
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.1.1. Channel Binding .....................................6
1.2. An Overview of Federation ..................................8
1.3. Challenges for Contemporary Federation ....................11
1.4. An Overview of ABFAB-Based Federation .....................11
1.5. Design Goals ..............................................14
2. Architecture ...................................................15
2.1. Relying Party to Identity Provider ........................16
2.1.1. AAA, RADIUS, and Diameter ..........................17
2.1.2. Discovery and Rules Determination ..................19
2.1.3. Routing and Technical Trust ........................20
2.1.4. AAA Security .......................................21
2.1.5. SAML Assertions ....................................22
2.2. Client to Identity Provider ...............................24
2.2.1. Extensible Authentication Protocol (EAP) ...........24
2.2.2. EAP Channel Binding ................................26
2.3. Client to Relying Party ...................................26
2.3.1. GSS-API ............................................27
2.3.2. Protocol Transport .................................28
2.3.3. Re-authentication ..................................29
3. Application Security Services ..................................29
3.1. Authentication ............................................29
3.2. GSS-API Channel Binding ...................................31
3.3. Host-Based Service Names ..................................32
3.4. Additional GSS-API Services ...............................33
4. Privacy Considerations .........................................34
4.1. Entities and Their Roles ..................................35
4.2. Privacy Aspects of ABFAB Communication Flows ..............36
4.2.1. Client to RP .......................................36
4.2.2. Client to IdP (via Federation Substrate) ...........37
4.2.3. IdP to RP (via Federation Substrate) ...............38
4.3. Relationship between User and Entities ....................39
4.4. Accounting Information ....................................39
4.5. Collection and Retention of Data and Identifiers ..........39
4.6. User Participation ........................................40
5. Security Considerations ........................................40
6. References .....................................................41
6.1. Normative References ......................................41
6.2. Informative References ....................................42
Acknowledgments ...................................................46
Authors' Addresses ................................................46
Numerous security mechanisms have been deployed on the Internet to manage access to various resources. These mechanisms have been generalized and scaled over the last decade through mechanisms such as the Simple Authentication and Security Layer (SASL) with the Generic Security Server Application Program Interface (GSS-API) (known as the GS2 family) [RFC5801]; the Security Assertion Markup Language (SAML) [OASIS.saml-core-2.0-os]; and the Authentication, Authorization, and Accounting (AAA) architecture as embodied in RADIUS [RFC2865] and Diameter [RFC6733].
互联网上部署了许多安全机制来管理对各种资源的访问。在过去十年中，这些机制已通过简单身份验证和安全层（SASL）和通用安全服务器应用程序接口（GSS-API）（称为GS2系列）[RFC5801]等机制得到推广和扩展；安全断言标记语言（SAML）[OASIS.SAML-core-2.0-os]；以及RADIUS[RFC2865]和Diameter[RFC6733]中体现的身份验证、授权和计费（AAA）体系结构。
A Relying Party (RP) is the entity that manages access to some resource. The entity that is requesting access to that resource is often described as the client. Many security mechanisms are manifested as an exchange of information between these entities. The RP is therefore able to decide whether the client is authorized or not.
依赖方（RP）是管理对某些资源的访问的实体。请求访问该资源的实体通常被称为客户机。许多安全机制表现为这些实体之间的信息交换。因此，RP能够决定客户是否获得授权。
Some security mechanisms allow the RP to delegate aspects of the access management decision to an entity called the Identity Provider (IdP). This delegation requires technical signaling, trust, and a common understanding of semantics between the RP and IdP. These aspects are generally managed within a relationship known as a "federation". This style of access management is accordingly described as "federated access management".
一些安全机制允许RP将访问管理决策的各个方面委托给称为身份提供者（IdP）的实体。该委托需要技术信号、信任以及RP和IdP之间语义的共同理解。这些方面通常在称为“联盟”的关系中进行管理。因此，这种访问管理风格被称为“联合访问管理”。
Federated access management has evolved over the last decade through specifications like SAML [OASIS.saml-core-2.0-os], OpenID (http://www.openid.net), OAuth [RFC6749], and WS-Trust [WS-TRUST]. The benefits of federated access management include:
在过去十年中，联邦访问管理通过SAML[OASIS.SAML-core-2.0-os]和OpenID等规范得到了发展(http://www.openid.net)、OAuth[RFC6749]和WS-Trust[WS-Trust]。联合访问管理的好处包括：
Single or simplified sign-on:
单一或简化登录：
An Internet service can delegate access management, and the associated responsibilities such as identity management and credentialing, to an organization that already has a long-term relationship with the client. This is often attractive, as RPs frequently do not want these responsibilities. The client also requires fewer credentials, which is also desirable.
Internet服务可以将访问管理和相关责任（如身份管理和认证）委托给与客户已有长期关系的组织。这通常很有吸引力，因为RPs通常不希望承担这些责任。客户端还需要更少的凭据，这也是可取的。
Data minimization and user participation:
数据最小化和用户参与：
Often, an RP does not need to know the identity of a client to reach an access management decision. It is frequently only necessary for the RP to know specific attributes about the client -- for example, that the client is affiliated with a particular organization or has a certain role or entitlement. Sometimes, the RP only needs to know a pseudonym of the client.
通常，RP不需要知道客户端的身份就可以做出访问管理决策。RP通常只需要了解客户的特定属性——例如，客户隶属于某个特定组织或具有特定角色或权利。有时，RP只需要知道客户的笔名。
Prior to the release of attributes to the RP from the IdP, the IdP will check configuration and policy to determine if the attributes are to be released. There is currently no direct client participation in this decision.
在从IdP向RP释放属性之前，IdP将检查配置和策略，以确定是否要释放属性。目前没有客户直接参与该决策。
Provisioning:
供应：
Sometimes, an RP needs, or would like, to know more about a client than an affiliation or a pseudonym. For example, an RP may want the client's email address or name. Some federated access management technologies provide the ability for the IdP to supply this information, either on request by the RP or unsolicited.
有时，RP需要或希望了解更多有关客户的信息，而不是联系或笔名。例如，RP可能需要客户的电子邮件地址或名称。一些联邦访问管理技术使IdP能够根据RP的请求或未经请求提供这些信息。
This memo describes the Application Bridging for Federated Access Beyond web (ABFAB) architecture. This architecture addresses the problem of federated access management primarily for non-web-based services. This architecture makes use of extensions to the commonly used security mechanisms for both federated and non-federated access management, including RADIUS, the Generic Security Service (GSS), the Extensible Authentication Protocol (EAP), and SAML. The architecture should be extended to use Diameter in the future. It does so in a manner that is designed to scale to large numbers of IdPs, RPs, and federations.
本备忘录描述了web之外的联合访问（ABFAB）体系结构的应用程序桥接。此体系结构主要针对非基于web的服务解决联合访问管理问题。该体系结构利用对联邦和非联邦访问管理常用安全机制的扩展，包括RADIUS、通用安全服务（GSS）、可扩展身份验证协议（EAP）和SAML。该体系结构应该扩展到将来使用Diameter。这样做的方式旨在扩展到大量的IDP、RPs和联合会。
This document uses identity management and privacy terminology from [RFC6973]. In particular, this document uses the terms "identity provider", "relying party", "identifier", "pseudonymity", "unlinkability", and "anonymity".
本文件使用[RFC6973]中的身份管理和隐私术语。特别是，本文件使用了术语“身份提供者”、“依赖方”、“标识符”、“假名”、“不可链接性”和“匿名性”。
In this architecture, the IdP consists of the following components: an EAP server, a RADIUS server, and, optionally, a SAML Assertion service.
在此体系结构中，IdP由以下组件组成：EAP服务器、RADIUS服务器，以及（可选）SAML断言服务。
This document uses the term "Network Access Identifier" (NAI) as defined in [RFC7542]. An NAI consists of a realm identifier, which is associated with a AAA server, and thus an IdP and a username, that are associated with a specific client of the IdP.
本文件使用[RFC7542]中定义的术语“网络访问标识符”（NAI）。NAI包括与AAA服务器关联的领域标识符，以及与IdP的特定客户端关联的IdP和用户名。
One of the problems some people have found with reading this document is that the terminology sometimes appears to be inconsistent. This is because the various standards that we refer to use different terms for the same concept. In general, this document uses either the ABFAB term or the term associated with the standard under discussion, as appropriate. For reference, we include Table 1 below, which provides a mapping for these different terms. (Note that items marked "N/A" (not applicable) indicate that there is no name that represents the entity.)
一些人在阅读本文档时发现的一个问题是，术语有时似乎不一致。这是因为我们提到的各种标准对同一概念使用了不同的术语。通常，本文件使用ABFAB术语或与讨论中的标准相关的术语（视情况而定）。下面的表1提供了这些不同术语的映射，以供参考。（请注意，标有“N/A”（不适用）的项目表示没有代表实体的名称。）
+----------+-----------+--------------------+-----------------------+
| Protocol | Client | Relying Party | Identity Provider |
+----------+-----------+--------------------+-----------------------+
| ABFAB | N/A | Relying Party (RP) | Identity Provider |
| | | | (IdP) |
| | | | |
| | Initiator | Acceptor | N/A |
| | | | |
| | Client | Server | N/A |
| | | | |
| SAML | Subject | Service provider | Issuer |
| | | | |
| GSS-API | Initiator | Acceptor | N/A |
| | | | |
| EAP | EAP peer | EAP authenticator | EAP server |
| | | | |
| AAA | N/A | AAA client | AAA server |
| | | | |
| RADIUS | user | NAS | N/A |
| | | | |
| | N/A | RADIUS client | RADIUS server |
+----------+-----------+--------------------+-----------------------+
+----------+-----------+--------------------+-----------------------+
| Protocol | Client | Relying Party | Identity Provider |
+----------+-----------+--------------------+-----------------------+
| ABFAB | N/A | Relying Party (RP) | Identity Provider |
| | | | (IdP) |
| | | | |
| | Initiator | Acceptor | N/A |
| | | | |
| | Client | Server | N/A |
| | | | |
| SAML | Subject | Service provider | Issuer |
| | | | |
| GSS-API | Initiator | Acceptor | N/A |
| | | | |
| EAP | EAP peer | EAP authenticator | EAP server |
| | | | |
| AAA | N/A | AAA client | AAA server |
| | | | |
| RADIUS | user | NAS | N/A |
| | | | |
| | N/A | RADIUS client | RADIUS server |
+----------+-----------+--------------------+-----------------------+
Table 1: Terminology
表1：术语
This document uses the term "channel binding" in two different contexts; this term has a different meaning in each of these contexts.
本文件在两种不同的上下文中使用术语“渠道绑定”；这一术语在每种上下文中都有不同的含义。
EAP channel binding is used to implement GSS-API naming semantics. EAP 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 back-end protocol from the EAP authenticator to the EAP server. The
EAP通道绑定用于实现GSS-API命名语义。EAP通道绑定将一组属性从对等方发送到EAP服务器，作为EAP会话的一部分或安全关联协议的一部分。此外，属性通过后端协议从EAP验证器发送到EAP服务器。这个
EAP server confirms the consistency of these attributes and provides the confirmation back to the peer. In this document, channel binding without qualification refers to EAP channel binding.
EAP服务器确认这些属性的一致性，并将确认返回给对等方。在本文件中，未经认证的渠道绑定指EAP渠道绑定。
GSS-API channel binding provides protection against man-in-the-middle attacks when GSS-API is used for authentication inside of some tunnel; it is similar to a facility called "cryptographic binding" in EAP. The binding works by each side deriving a cryptographic value from the tunnel itself and then using that cryptographic value to prove to the other side that it knows the value.
当GSS-API用于某个隧道内的身份验证时，GSS-API通道绑定提供了针对中间人攻击的保护；它类似于EAP中称为“加密绑定”的功能。绑定的工作方式是，每一方从隧道本身派生一个加密值，然后使用该加密值向另一方证明它知道该值。
See [RFC5056] for a discussion of the differences between these two facilities. These differences can be summarized as follows:
有关这两个设施之间差异的讨论，请参见[RFC5056]。这些差异可概括如下：
o GSS-API channel binding specifies that there is nobody between the client and the EAP authenticator.
o GSS-API通道绑定指定客户端和EAP验证器之间没有人。
o EAP channel binding allows the client to have knowledge of such EAP authenticator attributes as the EAP authenticator's name.
o EAP通道绑定允许客户端了解EAP验证器的名称等EAP验证器属性。
Typically, when considering both EAP and GSS-API channel binding, people think of channel binding in combination with mutual authentication. This is sufficiently common that, without additional qualification, channel binding should be assumed to imply mutual authentication. In GSS-API, without mutual authentication, only the acceptor has authenticated the initiator. Similarly, in EAP, only the EAP server has authenticated the peer. Sometimes, one-way authentication is useful. Consider, for example, a user who wishes to access a protected resource for a shared whiteboard in a conference room. The whiteboard is the acceptor; it knows that the initiator is authorized to give it a presentation, and the user can validate that the whiteboard got the correct presentation by visual means. (The presentation should not be confidential in this case.) If channel binding is used without mutual authentication, it is effectively a request to disclose the resource in the context of a particular channel. Such an authentication would be similar in concept to a holder-of-key SAML Assertion. However, note also that although it is not happening in the protocol, mutual authentication is happening in the overall system: the user is able to visually authenticate the content. This is consistent with all uses of channel binding without protocol-level mutual authentication found so far.
通常，当考虑EAP和GSS-API通道绑定时，人们会将通道绑定与相互认证结合起来考虑。这是非常常见的，在没有附加限定的情况下，应该假设通道绑定意味着相互认证。在GSS-API中，在没有相互身份验证的情况下，只有接受方对发起方进行了身份验证。类似地，在EAP中，只有EAP服务器对对等方进行了身份验证。有时，单向身份验证很有用。例如，考虑希望在会议室中访问共享白板的受保护资源的用户。白板是接受者；它知道发起者有权向其演示，用户可以通过视觉方式验证白板是否获得了正确的演示。（在这种情况下，演示不应保密。）如果在没有相互验证的情况下使用通道绑定，则实际上是在特定通道的上下文中披露资源的请求。这种身份验证在概念上类似于密钥持有者SAML断言。然而，还要注意的是，尽管协议中没有发生相互认证，但整个系统中正在发生相互认证：用户能够直观地对内容进行认证。这与迄今为止发现的没有协议级相互认证的通道绑定的所有使用是一致的。
In the previous section, we introduced the following entities:
在上一节中，我们介绍了以下实体：
o the client,
o 客户，
o the IdP, and
o 国内流离失所者，以及
o the RP.
o RP。
The final entity that needs to be introduced is the Individual. An Individual is a human being that is using the client. In any given situation, an Individual may or may not exist. Clients can act as front ends for Individuals, or clients may be independent entities that are set up and allowed to run autonomously. An example of such an independent entity can be found in the Trust Router Protocol (https://www.ietf.org/proceedings/86/slides/slides-86-rtgarea-0.pdf), where the routers use ABFAB to authenticate to each other.
需要引入的最后一个实体是个人。个人是使用客户机的人。在任何特定情况下，个人可能存在，也可能不存在。客户机可以充当个人的前端，或者客户机可以是独立的实体，可以设置并允许其自主运行。这种独立实体的一个例子可以在信任路由器协议中找到(https://www.ietf.org/proceedings/86/slides/slides-86-rtgarea-0.pdf)，其中路由器使用ABFAB相互验证。
These entities and their relationships are illustrated graphically in Figure 1.
这些实体及其关系如图1所示。
,----------\ ,---------\
| Identity | Federation | Relying |
| Provider + <--------------------> + Party |
`----------' '---------'
<
\
\ Authentication
\
\
\
\
\ +---------+
\ | | O
v| Client | \|/ Individual
| | |
+---------+ / \
,----------\ ,---------\
| Identity | Federation | Relying |
| Provider + <--------------------> + Party |
`----------' '---------'
<
\
\ Authentication
\
\
\
\
\ +---------+
\ | | O
v| Client | \|/ Individual
| | |
+---------+ / \
Figure 1: Entities and Their Relationships
图1：实体及其关系
The relationships between the entities in Figure 1 are as follows:
图1中实体之间的关系如下所示：
Federation
联邦
The IdP and the RPs are part of a federation. The relationship may be direct (they have an explicit trust relationship) or transitive (the trust relationship is mediated by one or more entities). The federation relationship is governed by a federation agreement. Within a single federation, there may be multiple IdPs as well as multiple RPs.
IdP和RPs是联邦的一部分。关系可以是直接的（它们有明确的信任关系）或传递的（信任关系由一个或多个实体调解）。联盟关系受联盟协议管辖。在单个联邦中，可能有多个IDP以及多个RP。
Authentication
认证
There is a direct relationship between the client and the IdP. This relationship provides the means by which they trust each other and can securely authenticate each other.
客户和IdP之间存在直接关系。这种关系提供了一种方式，通过这种方式，他们可以相互信任，并且可以安全地相互验证。
A federation agreement typically encompasses operational specifications and legal rules:
联盟协议通常包括操作规范和法律规则：
Operational Specifications:
操作规范：
The goal of operational specifications is to provide enough definition that the system works and interoperability is possible. These include the technical specifications (e.g., protocols used to communicate between the three parties), process standards, policies, identity proofing, credential and authentication algorithm requirements, performance requirements, assessment and audit criteria, etc.
操作规范的目标是提供足够的定义，使系统能够工作，并使互操作性成为可能。其中包括技术规范（例如，用于三方之间通信的协议）、过程标准、策略、身份验证、凭证和认证算法要求、性能要求、评估和审核标准等。
Legal Rules:
法律规则：
The legal rules take the legal framework into consideration and provide contractual obligations for each entity. The rules define the responsibilities of each party and provide further clarification of the operational specifications. These legal rules regulate the operational specifications, make operational specifications legally binding to the participants, and define and govern the rights and responsibilities of the participants. The legal rules may, for example, describe liability for losses, termination rights, enforcement mechanisms, measures of damage, dispute resolution, warranties, etc.
法律规则考虑到法律框架，并为每个实体规定了合同义务。这些规则规定了各方的责任，并进一步澄清了操作规范。这些法律规则规范操作规范，使操作规范对参与者具有法律约束力，并定义和管理参与者的权利和责任。例如，法律规则可以描述损失责任、终止权、执行机制、损害措施、争议解决、保证等。
The operational specifications can demand the usage of a specific technical infrastructure, including requirements on the message routing intermediaries, to offer the required technical functionality. In other environments, the operational specifications require fewer technical components in order to meet the required technical functionality.
操作规范可以要求使用特定的技术基础设施，包括对消息路由中介的要求，以提供所需的技术功能。在其他环境中，操作规范需要较少的技术组件以满足所需的技术功能。
The legal rules include many non-technical aspects of federation, such as business practices and legal arrangements, which are outside the scope of the IETF. The legal rules can still have an impact on the architectural setup or on how to ensure the dynamic establishment of trust.
法律规则包括联盟的许多非技术方面，如商业惯例和法律安排，这些都不在IETF的范围之内。法律规则仍然会对体系结构设置或如何确保动态建立信任产生影响。
While a federation agreement is often discussed within the context of formal relationships, such as between an enterprise and an employee or between a government and a citizen, a federation agreement does not have to require any particular level of formality. For an IdP and a client, it is sufficient for a relationship to be established by something as simple as using a web form and confirmation email. For an IdP and an RP, it is sufficient for the IdP to publish contact information along with a public key and for the RP to use that data. Within the framework of ABFAB, it will generally be required that a mechanism exist for the IdP to be able to trust the identity of the RP; if this is not present, then the IdP cannot provide the assurances to the client that the identity of the RP has been established.
虽然联邦协议通常是在正式关系的背景下讨论的，例如企业与员工之间或政府与公民之间，但联邦协议不需要任何特定的正式程度。对于IdP和客户机来说，通过使用web表单和确认电子邮件这样简单的方式建立关系就足够了。对于IdP和RP，IdP发布联系信息和公钥以及RP使用该数据就足够了。在ABFAB框架内，通常要求存在一种机制，使IdP能够信任RP的身份；如果不存在，则IdP无法向客户保证RP的身份已经确定。
The nature of federation dictates that there exists some form of relationship between the IdP and the RP. This is particularly important when the RP wants to use information obtained from the IdP for access management decisions and when the IdP does not want to release information to every RP (or only under certain conditions).
联邦的性质决定了IdP和RP之间存在某种形式的关系。当RP希望将从IdP获得的信息用于访问管理决策时，以及当IdP不希望向每个RP发布信息时（或仅在某些条件下），这一点尤为重要。
While it is possible to have a bilateral agreement between every IdP and every RP, on an Internet scale, this setup requires the introduction of the multilateral federation concept, as the management of such pair-wise relationships would otherwise prove burdensome.
虽然每个IdP和每个RP之间可以在互联网范围内达成双边协议，但这种设置需要引入多边联盟的概念，否则，这种成对关系的管理将变得繁重。
The IdP will typically have a long-term relationship with the client. This relationship typically involves the IdP positively identifying and credentialing the client (for example, at the time of employment within an organization). When dealing with Individuals, this process is called "identity proofing" [NIST-SP.800-63-2]. The relationship will often be instantiated within an agreement between the IdP and the client (for example, within an employment contract or terms of use that stipulate the appropriate use of credentials and so forth).
IdP通常与客户保持长期关系。这种关系通常涉及IdP对客户的积极识别和认证（例如，在组织内工作时）。与个人打交道时，这一过程称为“身份证明”[NIST-SP.800-63-2]。这种关系通常会在IdP和客户之间的协议中被实例化（例如，在雇佣合同或使用条款中规定了证书的适当使用等等）。
The nature and quality of the relationship between the client and the IdP are important contributors to the level of trust that an RP may assign to an assertion describing a client made by an IdP. This is sometimes described as the level of assurance [NIST-SP.800-63-2].
客户和IdP之间关系的性质和质量是RP可分配给描述IdP所做客户的断言的信任水平的重要贡献者。这有时被称为保证水平[NIST-SP.800-63-2]。
Federation does not require an a priori relationship or a long-term relationship between the RP and the client; it is this property of federation that yields many of its benefits. However, federation does not preclude the possibility of a pre-existing relationship between the RP and the client or the possibility that the RP and client may use the introduction to create a new long-term relationship independent of the federation.
联盟不要求RP和客户之间存在先验关系或长期关系；正是联邦的这一特性产生了许多好处。然而，联合会并不排除RP与客户之间存在预先存在的关系的可能性，也不排除RP与客户可能会利用介绍创建独立于联合会的新的长期关系的可能性。
Finally, it is important to reiterate that in some scenarios there might indeed be an Individual behind the client and in other cases the client may be autonomous.
最后，必须重申，在某些情况下，客户背后可能确实有个人，而在其他情况下，客户可能是自主的。
As federated IdPs and RPs (services) proliferate, the role of an Individual can become ambiguous in certain circumstances. For example, a school might provide online access for a student's grades to their parents for review and to the student's teacher for modification. A teacher who is also a parent must clearly distinguish their role upon access.
随着联合国内流离失所者和RPs（服务）的激增，个人的角色在某些情况下可能变得模糊不清。例如，学校可以为学生的成绩提供在线访问，供其家长审查，并供学生的老师修改。同时也是家长的教师必须在接触时明确区分自己的角色。
Similarly, as federations proliferate, it becomes increasingly difficult to discover which IdP(s) a user is associated with. This is true for both the web and non-web case but is particularly acute for the latter, as many non-web authentication systems are not semantically rich enough on their own to allow for such ambiguities. For instance, in the case of an email provider, SMTP and IMAP do not have the ability for the server to request information from the client, beyond the client NAI, that the server would then use to decide between the multiple federations it is associated with. However, the building blocks do exist to add this functionality.
类似地，随着联盟的激增，发现用户与哪些IdP关联变得越来越困难。这对于web和非web情况都是正确的，但对于后者来说尤其严重，因为许多非web身份验证系统本身的语义不够丰富，不允许出现这种歧义。例如，在电子邮件提供商的情况下，SMTP和IMAP无法让服务器从客户端请求客户端NAI以外的信息，服务器将使用这些信息在与其关联的多个联合体之间做出决定。但是，确实存在添加此功能的构建块。
The previous section described the general model of federation and the application of access management within the federation. This section provides a brief overview of ABFAB in the context of this model.
上一节描述了联邦的一般模型以及访问管理在联邦中的应用。本节简要概述了该模型背景下的ABFAB。
In this example, a client is attempting to connect to a server in order to either get access to some data or perform some type of transaction. In order for the client to mutually authenticate with the server, the following steps are taken in an ABFAB architecture (a graphical view of the steps can be found in Figure 2):
在本例中，客户机试图连接到服务器，以便访问某些数据或执行某种类型的事务。为了让客户机与服务器相互验证，在ABFAB体系结构中采取了以下步骤（步骤的图形视图如图2所示）：
1. Client configuration: The client is configured with an NAI assigned by the IdP. It is also configured with any keys, certificates, passwords, or other secret and public information needed to run the EAP protocols between it and the IdP.
1. 客户端配置：客户端配置由IdP分配的NAI。它还配置了在它和IdP之间运行EAP协议所需的任何密钥、证书、密码或其他机密和公共信息。
2. Authentication mechanism selection: The client is configured to use the GSS-EAP GSS-API mechanism for authentication/ authorization.
2. 身份验证机制选择：客户端配置为使用GSS-EAP GSS-API机制进行身份验证/授权。
3. Client provides an NAI to RP: The client sets up a transport to the RP and begins GSS-EAP authentication. In response, the RP sends an EAP request message (nested in GSS-EAP) asking for the client's name. The client sends an EAP response with an NAI name form that, at a minimum, contains the realm portion of its full NAI.
3. 客户端向RP提供NAI：客户端设置到RP的传输并开始GSS-EAP身份验证。作为响应，RP发送一条EAP请求消息（嵌套在GSS-EAP中），询问客户机的名称。客户端发送带有NAI名称表单的EAP响应，该表单至少包含其完整NAI的领域部分。
4. Discovery of federated IdP: The RP uses preconfigured information or a federation proxy to determine what IdP to use, based on policy and the realm portion of the provided client NAI. This is discussed in detail below (Section 2.1.2).
4. 联合IdP的发现：RP使用预配置信息或联合代理，根据策略和提供的客户端NAI的领域部分来确定要使用的IdP。下文将对此进行详细讨论（第2.1.2节）。
5. Request from RP to IdP: Once the RP knows who the IdP is, it (or its agent) will send a RADIUS request to the IdP. The RADIUS Access-Request encapsulates the EAP response. At this stage, the RP will likely have no idea who the client is. The RP sends its identity to the IdP in AAA attributes, and it may send a SAML request in a AAA attribute. The AAA network checks to see that the identity claimed by the RP is valid.
5. 从RP到IdP的请求：一旦RP知道IdP是谁，它（或其代理）将向IdP发送RADIUS请求。RADIUS访问请求封装EAP响应。在此阶段，RP可能不知道客户是谁。RP在AAA属性中向IdP发送其标识，并且可以在AAA属性中发送SAML请求。AAA网络检查RP声明的身份是否有效。
6. IdP begins EAP with the client: The IdP sends an EAP message to the client with an EAP method to be used. The IdP should not re-request the client's name in this message, but clients need to be able to handle it. In this case, the IdP must accept a realm only in order to protect the client's name from the RP. The available and appropriate methods are discussed below (Section 2.2.1).
6. IdP从客户端开始EAP：IdP使用要使用的EAP方法向客户端发送EAP消息。IdP不应在此消息中重新请求客户端的名称，但客户端需要能够处理该名称。在这种情况下，IdP必须只接受一个领域，以保护客户的名称不受RP的影响。下面讨论可用的和适当的方法（第2.2.1节）。
7. EAP is run: A bunch of EAP messages are passed between the client (EAP peer) and the IdP (EAP server), until the result of the authentication protocol is determined. The number and content of those messages depend on the EAP method selected. If the IdP is unable to authenticate the client, the IdP sends an
7. EAP运行：在客户端（EAP对等方）和IdP（EAP服务器）之间传递一组EAP消息，直到确定身份验证协议的结果。这些消息的数量和内容取决于所选的EAP方法。如果IdP无法对客户端进行身份验证，IdP将发送
EAP failure message to the RP. As part of the EAP method, the client sends an EAP channel-binding message to the IdP (Section 2.2.2). In the channel-binding message, the client identifies, among other things, the RP to which it is attempting to authenticate. The IdP checks the channel-binding data from the client against the data provided by the RP via the AAA protocol. If the bindings do not match, the IdP sends an EAP failure message to the RP.
EAP失败消息发送给RP。作为EAP方法的一部分，客户端向IdP发送EAP通道绑定消息（第2.2.2节）。在通道绑定消息中，除其他事项外，客户机标识其尝试向其进行身份验证的RP。IdP根据RP通过AAA协议提供的数据检查来自客户端的通道绑定数据。如果绑定不匹配，IdP将向RP发送EAP失败消息。
8. Successful EAP authentication: At this point, the IdP (EAP server) and client (EAP peer) have mutually authenticated each other. As a result, the client and the IdP hold two cryptographic keys: a Master Session Key (MSK) and an Extended MSK (EMSK). At this point, the client has a level of assurance regarding the identity of the RP, based on the name checking the IdP has done, using the RP naming information from the AAA framework and from the client (by the channel-binding data).
8. 成功的EAP身份验证：此时，IdP（EAP服务器）和客户端（EAP对等方）已相互进行身份验证。因此，客户端和IdP持有两个加密密钥：主会话密钥（MSK）和扩展MSK（EMSK）。此时，基于IdP已完成的名称检查，客户对RP的身份有一定程度的保证，使用来自AAA框架和客户（通过通道绑定数据）的RP命名信息。
9. Local IdP policy check: At this stage, the IdP checks local policy to determine whether the RP and client are authorized for a given transaction/service and, if so, what attributes, if any, will be released to the RP. If the IdP gets a policy failure, it sends an EAP failure message to the RP and client. (The RP will have done its policy checks during the discovery process.)
9. 本地IdP策略检查：在此阶段，IdP检查本地策略，以确定RP和客户端是否被授权用于给定的事务/服务，如果是，将向RP发布哪些属性（如果有）。如果IdP出现策略故障，它将向RP和客户端发送EAP故障消息。（RP将在发现过程中完成其策略检查。）
10. IdP provides the RP with the MSK: The IdP sends a success result EAP to the RP, along with an optional set of AAA attributes associated with the client (usually as one or more SAML Assertions). In addition, the EAP MSK is returned to the RP.
10. IdP向RP提供MSK：IdP向RP发送成功结果EAP，以及与客户机关联的可选AAA属性集（通常作为一个或多个SAML断言）。此外，EAP MSK将返回给RP。
11. RP processes results: When the RP receives the result from the IdP, it should have enough information to either grant or refuse a resource Access-Request. It may have information that associates the client with specific authorization identities. If additional attributes are needed from the IdP, the RP may make a new SAML request to the IdP. It will apply these results in an application-specific way.
11. RP处理结果：当RP收到来自IdP的结果时，它应该有足够的信息来批准或拒绝资源访问请求。它可能具有将客户机与特定授权身份关联的信息。如果需要来自IdP的附加属性，RP可以向IdP发出新的SAML请求。它将以特定于应用程序的方式应用这些结果。
12. RP returns results to client: Once the RP has a response, it must inform the client of the result. If all has gone well, all are authenticated, and the application proceeds with appropriate authorization levels. The client can now complete the authentication of the RP by using the EAP MSK value.
12. RP将结果返回给客户：RP做出响应后，必须将结果通知客户。如果一切顺利，那么所有的程序都经过身份验证，应用程序将以适当的授权级别继续运行。客户端现在可以使用EAP MSK值完成RP的身份验证。
Relying Client Identity Party Provider
依赖客户端身份方提供者
| (1) | Client configuration
| | |
|<-----(2)----->| | Mechanism selection
| | |
|<-----(3)-----<| | NAI transmitted to RP
| | |
|<=====(4)====================>| IdP Discovery
| | |
|>=====(5)====================>| Access-Request from RP to IdP
| | |
| |< - - (6) - -<| EAP method to client
| | |
| |< - - (7) - ->| EAP exchange to authenticate
| | | client
| | |
| | (8 & 9) Local policy check
| | |
|<====(10)====================<| Results to RP
| | |
(11) | | RP processes results
| | |
|>----(12)----->| | Results to client
| (1) | Client configuration
| | |
|<-----(2)----->| | Mechanism selection
| | |
|<-----(3)-----<| | NAI transmitted to RP
| | |
|<=====(4)====================>| IdP Discovery
| | |
|>=====(5)====================>| Access-Request from RP to IdP
| | |
| |< - - (6) - -<| EAP method to client
| | |
| |< - - (7) - ->| EAP exchange to authenticate
| | | client
| | |
| | (8 & 9) Local policy check
| | |
|<====(10)====================<| Results to RP
| | |
(11) | | RP processes results
| | |
|>----(12)----->| | Results to client
Legend:
图例：
-----: Between client and RP
=====: Between RP and IdP
- - -: Between client and IdP (via RP)
-----: Between client and RP
=====: Between RP and IdP
- - -: Between client and IdP (via RP)
Figure 2: ABFAB Authentication Steps
图2:ABFAB认证步骤
Our key design goals are as follows:
我们的主要设计目标如下：
o Each party in a transaction will be authenticated, although perhaps not identified, and the client will be authorized for access to a specific resource.
o 事务中的每一方都将经过身份验证，尽管可能没有标识，并且客户端将被授权访问特定的资源。
o The means of authentication is decoupled from the application protocol so as to allow for multiple authentication methods with minimal changes to the application.
o 身份验证手段与应用程序协议分离，以便允许对应用程序进行最小更改的多种身份验证方法。
o The architecture requires no sharing of long-term private keys between clients and RPs.
o 该体系结构不需要在客户端和RPs之间共享长期私钥。
o The system will scale to large numbers of IdPs, RPs, and users.
o 该系统将扩展到大量IDP、RPs和用户。
o The system will be designed primarily for non-web-based authentication.
o 该系统将主要设计用于非基于web的身份验证。
o The system will build upon existing standards, components, and operational practices.
o 该系统将以现有标准、组件和操作实践为基础。
Designing new three-party authentication and authorization protocols is difficult and fraught with the risk of cryptographic flaws. Achieving widespread deployment is even more difficult. A lot of attention on federated access has been devoted to the web. This document instead focuses on a non-web-based environment and focuses on those protocols where HTTP is not used. Despite the growing trend to layer every protocol on top of HTTP, there are still a number of protocols available that do not use HTTP-based transports. Many of these protocols are lacking a native authentication and authorization framework of the style shown in Figure 1.
设计新的第三方身份验证和授权协议是困难的，并且充满了密码缺陷的风险。实现广泛部署更加困难。对联合访问的大量关注都集中在web上。相反，本文档将重点放在非基于web的环境上，并将重点放在那些不使用HTTP的协议上。尽管在HTTP之上分层每个协议的趋势越来越大，但仍然有许多协议不使用基于HTTP的传输。这些协议中的许多缺乏图1所示风格的本机身份验证和授权框架。
We have already introduced the federated access architecture, with the illustration of the different actors that need to interact. This section expands on the specifics of providing support for non-web-based applications and provides motivations for design decisions. The main theme of the work described in this document is focused on reusing existing building blocks that have been deployed already and to rearrange them in a novel way.
我们已经介绍了联邦访问体系结构，并举例说明了需要交互的不同参与者。本节将详细介绍为非基于web的应用程序提供支持的细节，并提供设计决策的动机。本文档中描述的工作的主要主题是重用已经部署的现有构建块，并以一种新颖的方式重新排列它们。
Although this architecture assumes updates to the RP, the client, and the IdP, those changes are kept at a minimum. A mechanism that can demonstrate deployment benefits (based on ease of updates to existing software, low implementation effort, etc.) is preferred, and there may be a need to specify multiple mechanisms to support the range of different deployment scenarios.
尽管此体系结构假定对RP、客户端和IdP进行更新，但这些更改保持在最低限度。首选能够证明部署优势的机制（基于现有软件易于更新、实现工作量低等），并且可能需要指定多个机制来支持不同部署场景的范围。
There are a number of ways to encapsulate EAP into an application protocol. For ease of integration with a wide range of non-web-based application protocols, GSS-API was chosen. The technical specification of GSS-EAP can be found in [RFC7055].
有许多方法可以将EAP封装到应用程序协议中。为便于与各种非基于web的应用程序协议集成，选择了GSS-API。GSS-EAP的技术规范见[RFC7055]。
The architecture consists of several building blocks, as shown graphically in Figure 3. In the following sections, we discuss the data flow between each of the entities, the protocols used for that data flow, and some of the trade-offs made in choosing the protocols.
该体系结构由几个构建块组成，如图3所示。在以下部分中，我们将讨论每个实体之间的数据流、用于该数据流的协议以及在选择协议时所做的一些权衡。
+--------------+
| Identity |
| Provider |
| (IdP) |
+-^----------^-+
* EAP o RADIUS
* o
--v----------v--
/// \\\
// \\
| Federation |
| Substrate |
\\ //
\\\ ///
--^----------^--
* EAP o RADIUS
* o
+-------------+ +-v----------v--+
| | | |
| Client | EAP/EAP Method | Relying Party |
| Application |<****************>| (RP) |
| | GSS-API | |
| |<---------------->| |
| | Application | |
| | Protocol | |
| |<================>| |
+-------------+ +---------------+
+--------------+
| Identity |
| Provider |
| (IdP) |
+-^----------^-+
* EAP o RADIUS
* o
--v----------v--
/// \\\
// \\
| Federation |
| Substrate |
\\ //
\\\ ///
--^----------^--
* EAP o RADIUS
* o
+-------------+ +-v----------v--+
| | | |
| Client | EAP/EAP Method | Relying Party |
| Application |<****************>| (RP) |
| | GSS-API | |
| |<---------------->| |
| | Application | |
| | Protocol | |
| |<================>| |
+-------------+ +---------------+
Legend:
图例：
<****>: Client-to-IdP Exchange
<---->: Client-to-RP Exchange
<oooo>: RP-to-IdP Exchange
<====>: Protocol through which GSS-API/GS2 exchanges are tunneled
<****>: Client-to-IdP Exchange
<---->: Client-to-RP Exchange
<oooo>: RP-to-IdP Exchange
<====>: Protocol through which GSS-API/GS2 exchanges are tunneled
Figure 3: ABFAB Protocol Instantiation
图3:ABFAB协议实例化
Communication between the RP and the IdP is done by the Federation Substrate. This communication channel is responsible for:
RP和IdP之间的通信由联邦基板完成。该通信通道负责：
o Establishing the trust relationship between the RP and the IdP.
o 在RP和IdP之间建立信任关系。
o Determining the rules governing the relationship.
o 确定管理关系的规则。
o Conveying authentication packets from the client to the IdP and back.
o 将身份验证数据包从客户端传送到IdP并返回。
o Providing the means of establishing a trust relationship between the RP and the client.
o 提供在RP和客户之间建立信任关系的方法。
o Providing a means for the RP to obtain attributes about the client from the IdP.
o 为RP提供从IdP获取客户机属性的方法。
The ABFAB working group has chosen the AAA framework for the messages transported between the RP and IdP. The AAA framework supports the requirements stated above, as follows:
ABFAB工作组为RP和IdP之间传输的消息选择了AAA框架。AAA框架支持上述要求，如下所示：
o The AAA backbone supplies the trust relationship between the RP and the IdP.
o AAA主干提供RP和IdP之间的信任关系。
o The agreements governing a specific AAA backbone contain the rules governing the relationships within the AAA federation.
o 管理特定AAA主干网的协议包含管理AAA联盟内部关系的规则。
o A method exists for carrying EAP packets within RADIUS [RFC3579] and Diameter [RFC4072].
o 存在在半径[RFC3579]和直径[RFC4072]内承载EAP数据包的方法。
o The use of EAP channel binding [RFC6677] along with the core ABFAB protocol provide the pieces necessary to establish the identities of the RP and the client, while EAP provides the cryptographic methods for the RP and the client to validate that they are talking to each other.
o EAP通道绑定[RFC6677]以及核心ABFAB协议的使用提供了建立RP和客户机身份所需的部分，而EAP提供了RP和客户机的加密方法，以验证他们是否在相互交谈。
o A method exists for carrying SAML packets within RADIUS [RFC7833]; this method allows the RP to query attributes about the client from the IdP.
o 存在一种在RADIUS内承载SAML数据包的方法[RFC7833]；此方法允许RP从IdP查询有关客户端的属性。
Protocols that support the same framework but do different routing are expected to be defined and used in the future. One such effort, called the Trust Router, is to set up a framework that creates a trusted point-to-point channel on the fly (https://www.ietf.org/proceedings/86/slides/slides-86-rtgarea-0.pdf).
支持相同框架但路由不同的协议有望在将来定义和使用。其中一个被称为信任路由器的工作就是建立一个框架，在运行中创建一个可信的点到点通道(https://www.ietf.org/proceedings/86/slides/slides-86-rtgarea-0.pdf).
The usage of the AAA framework with RADIUS [RFC2865] and Diameter [RFC6733] for network access authentication has been successful from a deployment point of view. To map the terminology used in Figure 1 to the AAA framework, the IdP corresponds to the AAA server; the RP corresponds to the AAA client; and the technical building blocks of a federation are AAA proxies, relays, and redirect agents (particularly if they are operated by third parties, such as AAA brokers and clearinghouses). In the case of network access authentication, the front end, i.e., the communication path between the end host and the AAA client, is offered by link-layer protocols that forward
从部署的角度来看，使用带有RADIUS[RFC2865]和Diameter[RFC6733]的AAA框架进行网络访问身份验证是成功的。为了将图1中使用的术语映射到AAA框架，IdP对应于AAA服务器；RP对应于AAA客户端；联盟的技术构件是AAA代理、中继和重定向代理（特别是由第三方运营的，如AAA经纪人和清算所）。在网络访问认证的情况下，前端，即终端主机和AAA客户端之间的通信路径，由转发的链路层协议提供
authentication protocol exchanges back and forth. An example of a large-scale RADIUS-based federation is eduroam (https://www.eduroam.org).
身份验证协议来回交换。eduroam是一个基于RADIUS的大规模联合的示例(https://www.eduroam.org).
By using the AAA framework, ABFAB can be built on the federation agreements that already exist; the agreements can then merely be expanded to cover the ABFAB architecture. The AAA framework has already addressed some of the problems outlined above. For example,
通过使用AAA框架，ABFAB可以建立在已经存在的联盟协议之上；协议只能扩展到ABFAB架构。AAA框架已经解决了上述一些问题。例如
o It already has a method for routing requests based on a domain.
o 它已经有了一种基于域路由请求的方法。
o It already has an extensible architecture allowing for new attributes to be defined and transported.
o 它已经有了一个可扩展的体系结构，允许定义和传输新的属性。
o Pre-existing relationships can be reused.
o 可以重用预先存在的关系。
The astute reader will notice that RADIUS and Diameter have substantially similar characteristics. Why not pick one? RADIUS and Diameter are deployed in different environments. RADIUS can often be found in enterprise and university networks; RADIUS is also used by operators of fixed networks. Diameter, on the other hand, is deployed by operators of mobile networks. Another key difference is that today RADIUS is largely transported over UDP. The decision regarding which protocol will be appropriate to deploy is left to implementers. The protocol defines all the necessary new AAA attributes as RADIUS attributes. A future document could define the same AAA attributes for a Diameter environment. We also note that there exist proxies that convert from RADIUS to Diameter and back. This makes it possible for both to be deployed in a single Federation Substrate.
精明的读者会注意到半径和直径具有基本相似的特性。为什么不选一个呢？半径和直径部署在不同的环境中。RADIUS通常可以在企业和大学网络中找到；固定网络运营商也使用RADIUS。另一方面，Diameter由移动网络运营商部署。另一个关键区别是，如今RADIUS主要通过UDP传输。关于哪个协议适合部署的决定留给实现者。该协议将所有必需的新AAA属性定义为RADIUS属性。将来的文档可以为Diameter环境定义相同的AAA属性。我们还注意到，存在从半径到直径再到半径的转换代理。这使得两者都可以部署在一个联邦基板中。
Through the integrity-protection mechanisms in the AAA framework, the IdP can establish technical trust that messages are being sent by the appropriate RP. Any given interaction will be associated with one federation at the policy level. The legal or business relationship defines what statements the IdP is trusted to make and how these statements are interpreted by the RP. The AAA framework also permits the RP or elements between the RP and IdP to make statements about the RP.
通过AAA框架中的完整性保护机制，IdP可以建立由适当RP发送消息的技术信任。任何给定的交互都将在策略级别与一个联邦关联。法律或业务关系定义了IdP可以发表哪些声明，以及RP如何解释这些声明。AAA框架还允许RP或RP和IdP之间的元素发表关于RP的声明。
The AAA framework provides transport for attributes. Statements made about the client by the IdP, statements made about the RP, and other information are transported as attributes.
AAA框架为属性提供传输。IdP对客户的陈述、RP的陈述和其他信息作为属性传输。
One demand that the AAA substrate makes of the upper layers is that they must properly identify the endpoints of the communication. It must be possible for the AAA client at the RP to determine where to send each RADIUS or Diameter message. Without this requirement, it
AAA基板对上层的一个要求是，它们必须正确识别通信的端点。RP的AAA客户端必须能够确定每个RADIUS或Diameter消息的发送位置。如果没有这一要求，它将
would be the RP's responsibility to determine the identity of the client on its own, without the assistance of an IdP. This architecture makes use of the Network Access Identifier (NAI), where the IdP is indicated by the realm component [RFC7542]. The NAI is represented and consumed by the GSS-API layer as GSS_C_NT_USER_NAME, as specified in [RFC2743]. The GSS-API EAP mechanism includes the NAI in the EAP Response/Identity message.
RP有责任自行确定客户身份，无需IdP协助。该体系结构使用网络访问标识符（NAI），其中IdP由领域组件[RFC7542]指示。按照[RFC2743]中的规定，NAI由GSS-API层表示并使用为GSS_C_NT_USER_NAME。GSS-API EAP机制在EAP响应/标识消息中包含NAI。
At the time of this writing, no profiles for the use of Diameter have been created.
在撰写本文时，尚未创建使用直径的轮廓。
While we are using the AAA protocols to communicate with the IdP, the RP may have multiple Federation Substrates to select from. The RP has a number of criteria that it will use in selecting which of the different federations to use. The federation selected must
当我们使用AAA协议与IdP通信时，RP可能有多个联邦基板可供选择。RP有许多标准，用于选择要使用的不同联合会。所选的联盟必须是
o be able to communicate with the IdP.
o 能够与IdP进行通信。
o match the business rules and technical policies required for the RP security requirements.
o 匹配RP安全要求所需的业务规则和技术策略。
The RP needs to discover which federation will be used to contact the IdP. The first selection criterion used during discovery is going to be the name of the IdP to be contacted. The second selection criterion used during discovery is going to be the set of business rules and technical policies governing the relationship; this is called "rules determination". The RP also needs to establish technical trust in the communications with the IdP.
RP需要发现哪个联盟将用于联系IdP。发现过程中使用的第一个选择标准是要联系的IdP的名称。发现过程中使用的第二个选择标准是管理关系的业务规则和技术策略集；这被称为“规则确定”。RP还需要在与IdP的通信中建立技术信任。
Rules determination covers a broad range of decisions about the exchange. One of these is whether the given RP is permitted to talk to the IdP using a given federation at all, so rules determination encompasses the basic authorization decision. Other factors are included, such as what policies govern release of information about the client to the RP and what policies govern the RP's use of this information. While rules determination is ultimately a business function, it has a significant impact on the technical exchanges. The protocols need to communicate the result of authorization. When multiple sets of rules are possible, the protocol must disambiguate which set of rules are in play. Some rules have technical enforcement mechanisms; for example, in some federations, intermediaries validate information that is being communicated within the federation.
规则确定涵盖了有关交易所的广泛决策。其中之一是是否允许给定的RP使用给定的联邦与IdP对话，因此规则确定包含基本授权决策。还包括其他因素，例如，哪些政策管理向RP发布有关客户的信息，哪些政策管理RP使用这些信息。虽然规则确定最终是一项业务功能，但它对技术交流具有重大影响。协议需要传递授权的结果。当可能存在多组规则时，协议必须消除对正在使用的规则集的歧义。有些规则有技术性的执行机制；例如，在某些联合体中，中介体验证联合体中正在通信的信息。
At the time of this writing, no protocol mechanism has been specified to allow a AAA client to determine whether a AAA proxy will indeed be able to route AAA requests to a specific IdP. The AAA routing is impacted by business rules and technical policies that may be quite complex; at the present time, the route selection is based on manual configuration.
在撰写本文时，尚未指定任何协议机制来允许AAA客户端确定AAA代理是否确实能够将AAA请求路由到特定IdP。AAA路由受到可能相当复杂的业务规则和技术策略的影响；目前，路线选择基于手动配置。
Several approaches to having messages routed through the Federation Substrate are possible. These routing methods can most easily be classified based on the mechanism for technical trust that is used. The choice of technical trust mechanism constrains how rules determination is implemented. Regardless of what deployment strategy is chosen, it is important that the technical trust mechanism be able to validate the identities of both parties to the exchange. The trust mechanism must ensure that the entity acting as the IdP for a given NAI is permitted to be the IdP for that realm and that any service name claimed by the RP is permitted to be claimed by that entity. Here are the categories of technical trust determination:
有几种方法可以使消息路由通过联合底层。这些路由方法最容易根据所使用的技术信任机制进行分类。技术信任机制的选择限制了规则确定的实现方式。无论选择何种部署策略，技术信任机制都必须能够验证交换双方的身份。信任机制必须确保作为给定NAI的IdP的实体被允许作为该领域的IdP，并且RP声明的任何服务名称被该实体声明。以下是技术信任确定的类别：
AAA Proxy: The simplest model is that an RP is a AAA client and can send the request directly to a AAA proxy. The hop-by-hop integrity protection of the AAA fabric provides technical trust. An RP can submit a request directly to the correct federation. Alternatively, a federation disambiguation fabric can be used. Such a fabric takes information about what federations the RP is part of and what federations the IdP is part of, and it routes a message to the appropriate federation. The routing of messages across the fabric, plus attributes added to requests and responses, together provide rules determination. For example, when a disambiguation fabric routes a message to a given federation, that federation's rules are chosen. Name validation is enforced as messages travel across the fabric. The entities near the RP confirm its identity and validate names it claims. The fabric routes the message towards the appropriate IdP, validating the name of the IdP in the process. The routing can be statically configured. Alternatively, a routing protocol could be developed to exchange reachability information about a given IdP and to apply policy across the AAA fabric. Such a routing protocol could flood naming constraints to the appropriate points in the fabric.
AAA代理：最简单的模型是RP是AAA客户端，可以直接向AAA代理发送请求。AAA结构的逐跳完整性保护提供了技术信任。RP可以直接向正确的联盟提交请求。或者，可以使用联合消歧结构。这种结构获取关于RP所属的联邦以及IdP所属的联邦的信息，并将消息路由到适当的联邦。跨结构的消息路由，加上添加到请求和响应的属性，共同提供了规则确定。例如，当消歧结构将消息路由到给定的联合体时，将选择该联合体的规则。当消息在结构中传输时，将强制进行名称验证。RP附近的实体确认其身份并验证其声称的名称。结构将消息路由到适当的IdP，从而在过程中验证IdP的名称。路由可以静态配置。或者，可以开发路由协议来交换关于给定IdP的可达性信息，并在AAA结构上应用策略。这样的路由协议可以将命名约束应用到结构中的适当点。
Trust Broker: Instead of routing messages through AAA proxies, some trust broker could establish keys between entities near the RP and entities near the IdP. The advantage of this approach is efficiency of message handling. Fewer entities are needed to be involved for each message. Security may be improved by sending individual messages over fewer hops. Rules determination involves decisions made by trust brokers about what keys to grant. Also, associated with each credential is context about rules and about other aspects of technical trust, including names that may be claimed. A routing protocol similar to the one for AAA proxies is likely to be useful to trust brokers in flooding rules and naming constraints.
信任代理：一些信任代理可以在RP附近的实体和IdP附近的实体之间建立密钥，而不是通过AAA代理路由消息。这种方法的优点是消息处理的效率。每个消息需要涉及的实体更少。通过在更少的跃点上发送单个消息，可以提高安全性。规则确定涉及到信托经纪商就授予哪些密钥做出的决定。此外，与每个凭证相关联的是关于规则和技术信任的其他方面的上下文，包括可能声明的名称。类似于AAA代理的路由协议可能有助于在泛洪规则和命名约束中信任代理。
Global Credential: A global credential such as a public key and certificate in a public key infrastructure can be used to establish technical trust. A directory or distributed database such as the Domain Name System is used by the RP to discover the endpoint to contact for a given NAI. Either the database or certificates can provide a place to store information about rules determination and naming constraints. Provided that no intermediates are required (or appear to be required) and that the RP and IdP are sufficient to enforce and determine rules, rules determination is reasonably simple. However, applying certain rules is likely to be quite complex. For example, if multiple sets of rules are possible between an IdP and RP, confirming that the correct set is used may be difficult. This is particularly true if intermediates are involved in making the decision. Also, to the extent that directory information needs to be trusted, rules determination may be more complex.
全局凭证：全局凭证（如公钥基础结构中的公钥和证书）可用于建立技术信任。RP使用目录或分布式数据库（如域名系统）来发现给定NAI要联系的端点。数据库或证书都可以提供一个位置来存储有关规则确定和命名约束的信息。如果不需要（或似乎需要）中间产物，且RP和IdP足以执行和确定规则，则规则确定相当简单。然而，应用某些规则可能相当复杂。例如，如果IdP和RP之间可能存在多组规则，则确认使用了正确的规则集可能很困难。如果中间产物参与决策，则尤其如此。此外，由于目录信息需要信任，规则确定可能更复杂。
Real-world deployments are likely to be mixtures of these basic approaches. For example, it will be quite common for an RP to route traffic to a AAA proxy within an organization. That proxy could then use any of the above three methods to get closer to the IdP. It is also likely that, rather than being directly reachable, the IdP may have a proxy on the edge of its organization. Federations will likely provide a traditional AAA proxy interface even if they also provide another mechanism for increased efficiency or security.
现实世界的部署可能是这些基本方法的混合。例如，RP将流量路由到组织内的AAA代理是非常常见的。然后，该代理可以使用上述三种方法中的任何一种来接近IdP。IdP也有可能在其组织的边缘有一个代理，而不是直接联系。联邦很可能会提供传统的AAA代理接口，即使它们还提供了另一种提高效率或安全性的机制。
For the AAA framework, there are two different places where security needs to be examined. The first is the security that is in place for the links in the AAA backbone being used. The second are the nodes that form the AAA backbone.
对于AAA框架，有两个不同的地方需要检查安全性。第一个是正在使用的AAA主干中的链路的安全性。第二个是形成AAA主干的节点。
The default link security for RADIUS is showing its age, as it uses MD5 and a shared secret to both obfuscate passwords and provide integrity on the RADIUS messages. While some EAP methods include the ability to protect the client authentication credentials, the MSK returned from the IdP to the RP is protected only by RADIUS security. In many environments, this is considered to be insufficient, especially as not all attributes are obfuscated and can thus leak information to a passive eavesdropper. The use of RADIUS with Transport Layer Security (TLS) [RFC6614] and/or Datagram Transport Layer Security (DTLS) [RFC7360] addresses these attacks. The same level of security is included in the base Diameter specifications.
RADIUS的默认链接安全性显示了它的年龄，因为它使用MD5和共享机密来混淆密码并提供RADIUS消息的完整性。虽然某些EAP方法包括保护客户端身份验证凭据的功能，但从IdP返回给RP的MSK仅受RADIUS安全性的保护。在许多环境中，这被认为是不够的，特别是因为并非所有属性都是模糊的，因此可能会将信息泄漏给被动窃听者。将RADIUS与传输层安全性（TLS）[RFC6614]和/或数据报传输层安全性（DTLS）[RFC7360]结合使用可解决这些攻击。底座直径规格中包含相同级别的安全性。
For the traditional use of AAA frameworks, i.e., granting access to a network, an affirmative response from the IdP is sufficient. In the ABFAB world, the RP may need to get significantly more additional information about the client before granting access. ABFAB therefore has a requirement that it can transport an arbitrary set of attributes about the client from the IdP to the RP.
对于AAA框架的传统使用，即允许访问网络，IdP的肯定响应就足够了。在ABFAB世界中，RP可能需要在授予访问权限之前获得更多关于客户的额外信息。因此，ABFAB要求它能够将客户机的任意属性集从IdP传输到RP。
The Security Assertion Markup Language (SAML) [OASIS.saml-core-2.0-os] was designed in order to carry an extensible set of attributes about a subject. Since SAML is extensible in the attribute space, ABFAB has no immediate needs to update the core SAML specifications for our work. It will be necessary to update IdPs that need to return SAML Assertions to RPs and for both the IdP and the RP to implement a new SAML profile designed to carry SAML Assertions in AAA. The new profile can be found in [RFC7833]. As SAML statements will frequently be large, RADIUS servers and clients that deal with SAML statements will need to implement [RFC7499].
安全断言标记语言（SAML）[OASIS.SAML-core-2.0-os]的设计是为了携带一组关于主题的可扩展属性。由于SAML在属性空间中是可扩展的，ABFAB不需要立即为我们的工作更新核心SAML规范。有必要更新需要将SAML断言返回给RPs的IdP，并且IdP和RP都需要实现一个新的SAML配置文件，该配置文件设计用于在AAA中承载SAML断言。新配置文件可在[RFC7833]中找到。由于SAML语句通常很大，处理SAML语句的RADIUS服务器和客户端需要实现[RFC7499]。
There are several issues that need to be highlighted:
有几个问题需要强调：
o The security of SAML Assertions.
o SAML断言的安全性。
o Namespaces and mapping of SAML attributes.
o 名称空间和SAML属性的映射。
o Subject naming of entities.
o 实体的主题命名。
o Making multiple queries about the subject(s).
o 对主题进行多次查询。
o Level of assurance for authentication.
o 身份验证的保证级别。
SAML Assertions have an optional signature that can be used to protect and provide the origination of the assertion. These signatures are normally based on asymmetric key operations and require that the verifier be able to check not only the cryptographic
SAML断言有一个可选的签名，可用于保护和提供断言的起源。这些签名通常基于非对称密钥操作，并且要求验证器不仅能够检查密码
operation but also the binding of the originator's name and the public key. In a federated environment, it will not always be possible for the RP to validate the binding; for this reason, the technical trust established in the federation is used as an alternate method of validating the origination and integrity of the SAML Assertion.
操作，而且还要绑定发起者的名称和公钥。在联邦环境中，RP并不总是能够验证绑定；因此，在联合体中建立的技术信任被用作验证SAML断言的起源和完整性的替代方法。
Attributes in a SAML Assertion are identified by a name string. The name string is either assigned by the SAML issuer context or scoped by a namespace (for example, a URI or object identifier (OID)). This means that the same attribute can have different name strings used to identify it. In many cases, but not all, the federation agreements will determine what attributes and names can be used in a SAML statement. This means that the RP needs to map from the SAML issuer or federation name, type, and semantic to the name, type, and semantics that the policies of the RP are written in. In other cases, the Federation Substrate, in the form of proxies, will modify the SAML Assertions in transit to do the necessary name, type, and value mappings as the assertion crosses boundaries in the federation. If the proxies are modifying the SAML Assertion, then they will remove any signatures on the SAML Assertion, as changing the content of the SAML Assertion would invalidate the signature. In this case, the technical trust is the required mechanism for validating the integrity of the assertion. (The proxy could re-sign the SAML Assertion, but the same issues of establishing trust in the proxy would still exist.) Finally, the attributes may still be in the namespace of the originating IdP. When this occurs, the RP will need to get the required mapping operations from the federation agreements and do the appropriate mappings itself.
SAML断言中的属性由名称字符串标识。名称字符串由SAML颁发者上下文指定，或由命名空间（例如，URI或对象标识符（OID））限定范围。这意味着同一属性可以使用不同的名称字符串来标识它。在许多情况下，但并非所有情况下，联合协议将确定SAML语句中可以使用哪些属性和名称。这意味着RP需要从SAML颁发者或联合体名称、类型和语义映射到RP策略所使用的名称、类型和语义。在其他情况下，联邦基底以代理的形式修改传输中的SAML断言，以便在断言跨越联邦中的边界时进行必要的名称、类型和值映射。如果代理正在修改SAML断言，那么它们将删除SAML断言上的任何签名，因为更改SAML断言的内容将使签名无效。在这种情况下，技术信任是验证断言完整性所需的机制。（代理可以对SAML断言重新签名，但在代理中建立信任的问题仍然存在。）最后，属性可能仍然位于原始IdP的命名空间中。当这种情况发生时，RP将需要从联合协议中获取所需的映射操作，并自己进行适当的映射。
[RFC7833] has defined a new SAML name format that corresponds to the NAI name form defined by [RFC7542]. This allows for easy name matching in many cases, as the name form in the SAML statement and the name form used in RADIUS or Diameter will be the same. In addition to the NAI name form, [RFC7833] also defines a pair of implicit name forms corresponding to the client and the client's machine. These implicit name forms are based on the Identity-Type enumeration defined in the Tunnel Extensible Authentication Protocol (TEAP) specification [RFC7170]. If the name form returned in a SAML statement is not based on the NAI, then it is a requirement on the EAP server that it validate that the subject of the SAML Assertion, if any, is equivalent to the subject identified by the NAI used in the RADIUS or Diameter session.
[RFC7833]定义了一种新的SAML名称格式，该格式与[RFC7542]定义的NAI名称表单相对应。在许多情况下，这允许轻松进行名称匹配，因为SAML语句中的名称形式与RADIUS或Diameter中使用的名称形式相同。除了NAI名称表单之外，[RFC7833]还定义了一对对应于客户端和客户端机器的隐式名称表单。这些隐式名称形式基于隧道可扩展身份验证协议（TEAP）规范[RFC7170]中定义的身份类型枚举。如果SAML语句中返回的名称表单不基于NAI，则EAP服务器上的要求是验证SAML断言的主题（如果有）是否与RADIUS或DIAMER会话中使用的NAI标识的主题等效。
RADIUS has the ability to deal with multiple SAML queries for those EAP servers that follow [RFC5080]. In this case, a State attribute will always be returned with the Access-Accept. The EAP client can then send a new Access-Request with the State attribute and the new
RADIUS能够为遵循[RFC5080]的EAP服务器处理多个SAML查询。在这种情况下，状态属性将始终随Access Accept一起返回。然后，EAP客户端可以发送一个新的访问请求，该请求带有State属性和新的
SAML request. Multiple SAML queries can then be done by making a new Access-Request, using the State attribute returned in the last Access-Accept to link together the different RADIUS sessions.
SAML请求。然后，通过发出新的访问请求，使用上次访问接受中返回的State属性将不同的RADIUS会话链接在一起，可以完成多个SAML查询。
Some RPs need to ensure that specific criteria are met during the authentication process. This need is met by using levels of assurance. A level of assurance is communicated to the RP from the EAP server by using a SAML Authentication Request, using the Authentication Profile described in [RFC7833]. When crossing boundaries between different federations, (1) the policy specified will need to be shared between the two federations, (2) the policy will need to be mapped by the proxy server on the boundary, or (3) the proxy server on the boundary will need to supply information to the EAP server so that the EAP server can do the required mapping. If this mapping is not done, then the EAP server will not be able to enforce the desired level of assurance, as it will not understand the policy requirements.
一些RPs需要确保在身份验证过程中满足特定标准。通过使用保证级别来满足这一需求。通过使用SAML身份验证请求，使用[RFC7833]中描述的身份验证配置文件，从EAP服务器向RP传达一个保证级别。当跨越不同联合体之间的边界时，（1）指定的策略需要在两个联合体之间共享，（2）该策略需要由边界上的代理服务器映射，或（3）边界上的代理服务器需要向EAP服务器提供信息，以便EAP服务器可以执行所需的映射。如果未完成此映射，则EAP服务器将无法强制执行所需的保证级别，因为它无法理解策略要求。
Looking at the communications between the client and the IdP, the following items need to be dealt with:
查看客户和IdP之间的通信，需要处理以下事项：
o The client and the IdP need to mutually authenticate each other.
o 客户端和IdP需要相互认证。
o The client and the IdP need to mutually agree on the identity of the RP.
o 客户和IdP需要就RP的身份达成一致。
ABFAB selected EAP for the purposes of mutual authentication and assisted in creating some new EAP channel-binding documents for dealing with determining the identity of the RP. A framework for the channel-binding mechanism has been defined in [RFC6677] that allows the IdP to check the identity of the RP provided by the AAA framework against the identity provided by the client.
ABFAB选择EAP用于相互认证，并协助创建一些新的EAP渠道绑定文件，用于确定RP的身份。渠道绑定机制的框架已在[RFC6677]中定义这允许IdP根据客户提供的身份检查AAA框架提供的RP的身份。
Traditional web federation does not describe how a client interacts with an IdP for authentication. As a result, this communication is not standardized. There are several disadvantages to this approach. Since the communication is not standardized, it is difficult for machines to recognize which entity is going to do the authentication, and thus which credentials to use and where in the authentication form the credentials are to be entered. It is much easier for humans to correctly deal with these problems. The use of browsers for authentication restricts the deployment of more secure forms of authentication beyond plaintext usernames and passwords known by the server. In a number of cases, the authentication interface may be
传统的web联合不描述客户端如何与IdP交互以进行身份验证。因此，这种交流没有标准化。这种方法有几个缺点。由于通信没有标准化，机器很难识别哪个实体将要进行身份验证，因此很难识别要使用哪些凭据以及在身份验证表单中输入凭据的位置。人类更容易正确处理这些问题。除了服务器已知的明文用户名和密码之外，使用浏览器进行身份验证会限制部署更安全的身份验证形式。在许多情况下，认证接口可能是
presented before the client has adequately validated that they are talking to the intended server. By giving control of the authentication interface to a potential attacker, the security of the system may be reduced, and opportunities for phishing may be introduced.
在客户机充分验证他们是否正在与预期的服务器对话之前显示。通过将身份验证接口的控制权交给潜在的攻击者，系统的安全性可能会降低，并可能引入网络钓鱼。
As a result, it is desirable to choose some standardized approach for communication between the client's end host and the IdP. There are a number of requirements this approach must meet, as noted below.
因此，希望为客户端的终端主机和IdP之间的通信选择一些标准化方法。如下文所述，该方法必须满足许多要求。
Experience has taught us one key security and scalability requirement: it is important that the RP not get possession of the long-term secret of the client. Aside from a valuable secret being exposed, a synchronization problem can develop when the client changes keys with the IdP.
经验告诉我们一个关键的安全性和可伸缩性要求：RP不能掌握客户的长期秘密，这一点很重要。除了暴露有价值的秘密外，当客户端使用IdP更改密钥时，还可能出现同步问题。
Since there is no single authentication mechanism that will be used everywhere, another associated requirement is that the authentication framework must allow for the flexible integration of authentication mechanisms. For instance, some IdPs require hardware tokens, while others use passwords. A service provider wants to provide support for both authentication methods and also for other methods from IdPs not yet seen.
由于没有一种认证机制可以在任何地方使用，因此另一个相关的要求是认证框架必须允许灵活集成认证机制。例如，一些IDP需要硬件令牌，而其他IDP则使用密码。服务提供商希望为身份验证方法以及尚未见到的来自IDP的其他方法提供支持。
These requirements can be met by utilizing standardized and successfully deployed technology, namely the EAP framework [RFC3748]. Figure 3 illustrates the integration graphically.
这些要求可以通过利用标准化和成功部署的技术来满足，即EAP框架[RFC3748]。图3以图形方式说明了集成。
EAP is an end-to-end framework; it provides for two-way communication between a peer (i.e., client or Individual) through the EAP authenticator (i.e., RP) to the back end (i.e., IdP). This is precisely -- and conveniently -- the communication path that is needed for federated identity. Although EAP support is already integrated in AAA systems (see [RFC3579] and [RFC4072]), several challenges remain:
EAP是一个端到端框架；它提供对等方（即客户端或个人）之间通过EAP验证器（即RP）到后端（即IdP）的双向通信。这正是联邦身份所需的通信路径，而且非常方便。尽管EAP支持已经集成在AAA系统中（请参见[RFC3579]和[RFC4072]），但仍存在一些挑战：
o The first is how to carry EAP payloads from the end host to the RP.
o 第一个是如何将EAP有效载荷从终端主机传送到RP。
o Another is to verify statements the RP has made to the client, confirm that these statements are consistent with statements made to the IdP, and confirm that all of the above are consistent with the federation and any federation-specific policy or configuration.
o 另一个是验证RP向客户所做的陈述，确认这些陈述与向IdP所做的陈述一致，并确认上述所有内容与联盟以及任何特定于联盟的政策或配置一致。
o Another challenge is choosing which IdP to use for which service.
o 另一个挑战是选择将哪个IdP用于哪个服务。
The EAP method used for ABFAB needs to meet the following requirements:
ABFAB使用的EAP方法需要满足以下要求：
o It needs to provide mutual authentication of the client and IdP.
o 它需要提供客户端和IdP的相互身份验证。
o It needs to support channel binding.
o 它需要支持通道绑定。
As of this writing, the only EAP method that meets these criteria is TEAP [RFC7170], either alone (if client certificates are used) or with an inner EAP method that does mutual authentication.
在撰写本文时，满足这些标准的唯一EAP方法是TEAP[RFC7170]，它可以单独使用（如果使用客户端证书），也可以与执行相互身份验证的内部EAP方法一起使用。
EAP channel binding is easily confused with a facility in GSS-API that is also called "channel binding". GSS-API channel binding provides protection against man-in-the-middle attacks when GSS-API is used for authentication inside of 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.
EAP通道绑定很容易与GSS-API中也称为“通道绑定”的功能混淆。当GSS-API用于某个隧道内的身份验证时，GSS-API通道绑定提供了针对中间人攻击的保护；它类似于EAP中称为“加密绑定”的功能。有关这两个设施之间差异的讨论，请参见[RFC5056]。
The client knows, in theory, the name of the RP that it attempted to connect to; however, in the event that an attacker has intercepted the protocol, the client and the IdP need to be able to detect this situation. A general overview of the problem, along with a recommended way to deal with the channel-binding issues, can be found in [RFC6677].
理论上，客户知道其试图连接到的RP的名称；但是，如果攻击者拦截了协议，客户端和IdP需要能够检测到这种情况。[RFC6677]中提供了该问题的一般概述，以及处理通道绑定问题的推荐方法。
Since the time that [RFC6677] was published, a number of possible attacks were found. Methods to address these attacks have been outlined in [RFC7029].
自[RFC6677]发布以来，发现了许多可能的攻击。[RFC7029]中概述了解决这些攻击的方法。
The final set of interactions between the parties to consider are those between the client and the RP. In some ways, this is the most complex set, since at least part of it is outside the scope of the ABFAB work. The interactions between these parties include:
考虑各方之间的最后一组交互是客户端和RP之间的交互。在某些方面，这是最复杂的集合，因为至少部分超出ABFAF工作的范围。这些方之间的互动包括：
o Running the protocol that implements the service that is provided by the RP and desired by the client.
o 运行协议，该协议实现由RP提供并由客户端所需的服务。
o Authenticating the client to the RP and the RP to the client.
o 向RP验证客户端，向客户端验证RP。
o Providing the necessary security services to the service protocol that it needs, beyond authentication.
o 除了身份验证之外，还为服务协议提供所需的必要安全服务。
o Dealing with client re-authentication where desired.
o 在需要时处理客户端重新身份验证。
One of the remaining layers is responsible for integration of federated authentication with the application. Applications have adopted a number of approaches for providing security, so multiple strategies for integration of federated authentication with applications may be needed. To this end, we start with a strategy that provides integration with a large number of application protocols.
剩下的一层负责将联邦身份验证与应用程序集成。应用程序采用了许多方法来提供安全性，因此可能需要多种策略来将联邦身份验证与应用程序集成。为此，我们从提供与大量应用程序协议集成的策略开始。
Many applications, such as Secure Shell (SSH) [RFC4462], NFS [RFC7530], DNS [RFC3645], and several non-IETF applications, support GSS-API [RFC2743]. Many applications, such as IMAP, SMTP, the Extensible Messaging and Presence Protocol (XMPP), and the Lightweight Directory Access Protocol (LDAP), support the Simple Authentication and Security Layer (SASL) [RFC4422] framework. These two approaches work together nicely: by creating a GSS-API mechanism, SASL integration is also addressed. In effect, using a GSS-API mechanism with SASL simply requires placing some headers before the mechanism's messages and constraining certain GSS-API options.
许多应用程序，如Secure Shell（SSH）[RFC4462]、NFS[RFC7530]、DNS[RFC3645]和一些非IETF应用程序，都支持GSS-API[RFC2743]。许多应用程序，如IMAP、SMTP、可扩展消息和状态协议（XMPP）和轻量级目录访问协议（LDAP），都支持简单身份验证和安全层（SASL）[RFC4422]框架。这两种方法很好地协同工作：通过创建GSS-API机制，SASL集成也得到了解决。实际上，在SASL中使用GSS-API机制只需要在机制的消息之前放置一些头并约束某些GSS-API选项。
GSS-API is specified in terms of an abstract set of operations that can be mapped into a programming language to form an API. When people are first introduced to GSS-API, they focus on it as an API. However, from the perspective of authentication for non-web applications, GSS-API should be thought of as a protocol as well as an API. When looked at as a protocol, it consists of abstract operations such as the initial context exchange, which includes two sub-operations (GSS_Init_sec_context and GSS_Accept_sec_context) [RFC2743]. An application defines which abstract operations it is going to use and where messages produced by these operations fit into the application architecture. A GSS-API mechanism will define what actual protocol messages result from that abstract message for a given abstract operation. So, since this work is focusing on a particular GSS-API mechanism, we generally focus on protocol elements rather than the API view of GSS-API.
GSS-API是根据一组抽象的操作来指定的，这些操作可以映射到编程语言以形成API。当人们第一次被介绍到GSS-API时，他们把它作为API来关注。然而，从非web应用程序的身份验证角度来看，GSS-API应该被视为一种协议和API。将其视为协议时，它由抽象操作组成，如初始上下文交换，其中包括两个子操作（GSS_Init_sec_context和GSS_Accept_sec_context）[RFC2743]。应用程序定义要使用哪些抽象操作，以及这些操作生成的消息适合应用程序体系结构的位置。GSS-API机制将定义给定抽象操作的抽象消息产生的实际协议消息。因此，由于这项工作的重点是特定的GSS-API机制，因此我们通常关注协议元素，而不是GSS-API的API视图。
The API view of GSS-API does have significant value as well; since the abstract operations are well defined, the information that a mechanism gets from the application is well defined. Also, the set of assumptions the application is permitted to make is generally well defined. As a result, an application protocol that supports GSS-API or SASL is very likely to be usable with a new approach to authentication, including the authentication mechanism defined in this document, with no required modifications. In some cases, support for a new authentication mechanism has been added using plugin interfaces to applications without the application being modified at all. Even when modifications are required, they can
GSS-API的API视图也具有重要价值；由于抽象操作定义良好，因此机制从应用程序获得的信息定义良好。此外，允许应用程序进行的一组假设通常定义良好。因此，支持GSS-API或SASL的应用程序协议很可能可以用于新的身份验证方法，包括本文档中定义的身份验证机制，而无需进行必要的修改。在某些情况下，使用插件接口向应用程序添加了对新身份验证机制的支持，而应用程序根本不需要修改。即使需要修改，它们也可以
often be limited to supporting a new naming and authorization model. For example, this work focuses on privacy; an application that assumes that it will always obtain an identifier for the client will need to be modified to support anonymity, unlinkability, or pseudonymity.
通常仅限于支持新的命名和授权模型。例如，这项工作侧重于隐私；如果应用程序假定它将始终获得客户端的标识符，则需要对其进行修改，以支持匿名性、不可链接性或假名性。
So, we use GSS-API and SASL because a number of the application protocols we wish to federate support these strategies for security integration. What does this mean from a protocol standpoint, and how does this relate to other layers? This means that we need to design a concrete GSS-API mechanism. We have chosen to use a GSS-API mechanism that encapsulates EAP authentication. So, GSS-API (and SASL) encapsulates EAP between the end host and the service. The AAA framework encapsulates EAP between the RP and the IdP. The GSS-API mechanism includes rules about how initiators and services are named as well as per-message security and other facilities required by the applications we wish to support.
所以，我们使用GSS-API和SASL，因为我们希望联合的许多应用程序协议都支持这些安全集成策略。从协议的角度来看，这意味着什么？这与其他层有什么关系？这意味着我们需要设计一个具体的GSS-API机制。我们选择使用GSS-API机制来封装EAP身份验证。因此，GSS-API（和SASL）封装了终端主机和服务之间的EAP。AAA框架封装RP和IdP之间的EAP。GSS-API机制包括有关如何命名启动器和服务的规则，以及我们希望支持的应用程序所需的消息安全性和其他功能。
The transport of data between the client and the RP is not provided by GSS-API. GSS-API creates and consumes messages, but it does not provide the transport itself; instead, the protocol using GSS-API needs to provide the transport. In many cases, HTTP or HTTPS is used for this transport, but other transports are perfectly acceptable. The core GSS-API document [RFC2743] provides some details on what requirements exist.
GSS-API不提供客户和RP之间的数据传输。GSS-API创建和使用消息，但不提供传输本身；相反，使用GSS-API的协议需要提供传输。在许多情况下，HTTP或HTTPS用于此传输，但其他传输完全可以接受。核心GSS-API文件[RFC2743]提供了一些关于存在哪些需求的详细信息。
In addition, we highlight the following:
此外，我们强调以下几点：
o The transport does not need to provide either confidentiality or integrity. After GSS-EAP has finished negotiation, GSS-API can be used to provide both services. If the negotiation process itself needs protection from eavesdroppers, then the transport would need to provide the necessary services.
o 传输不需要提供机密性或完整性。GSS-EAP完成协商后，可以使用GSS-API提供这两种服务。如果谈判过程本身需要防范窃听者，那么运输部门就需要提供必要的服务。
o The transport needs to provide reliable transport of the messages.
o 传输需要提供消息的可靠传输。
o The transport needs to ensure that tokens are delivered in order during the negotiation process.
o 传输需要确保令牌在协商过程中按顺序交付。
o GSS-API messages need to be delivered atomically. If the transport breaks up a message, it must also reassemble the message before delivery.
o GSS-API消息需要以原子方式传递。如果传输中断了消息，它还必须在传递之前重新组装消息。
There are circumstances where the RP will want to have the client re-authenticate itself. These include very long sessions, where the original authentication is time limited or cases where in order to complete an operation a different authentication is required. GSS-EAP does not have any mechanism for the server to initiate a re-authentication, as all authentication operations start from the client. If a protocol using GSS-EAP needs to support re-authentication that is initiated by the server, then a request from the server to the client for the re-authentication to start needs to be placed in the protocol.
在某些情况下，RP希望让客户机重新进行自身身份验证。这些包括非常长的会话，其中原始身份验证是有时间限制的，或者为了完成操作需要不同身份验证的情况。GSS-EAP没有任何机制让服务器启动重新身份验证，因为所有身份验证操作都从客户端开始。如果使用GSS-EAP的协议需要支持由服务器发起的重新身份验证，则需要在协议中放置从服务器到客户端的重新身份验证启动请求。
Clients can reuse the existing secure connection established by GSS-API, and run the new authentication in that connection, by calling GSS_Init_sec_context. At this point, a full re-authentication will be done.
客户端可以重用由GSS-API建立的现有安全连接，并通过调用GSS_Init_sec_上下文在该连接中运行新的身份验证。此时，将进行完全重新身份验证。
One of the key goals is to integrate federated authentication with existing application protocols and, where possible, existing implementations of these protocols. Another goal is to perform this integration while meeting the best security practices of the technologies used to perform the integration. This section describes security services and properties required by the EAP GSS-API mechanism in order to meet these goals. This information could be viewed as specific to that mechanism. However, other future application integration strategies are very likely to need similar services. So, it is likely that these services will be expanded across application integration strategies if new application integration strategies are adopted.
其中一个关键目标是将联邦身份验证与现有应用程序协议集成，并在可能的情况下与这些协议的现有实现集成。另一个目标是执行此集成，同时满足用于执行集成的技术的最佳安全实践。本节介绍EAP GSS-API机制为实现这些目标所需的安全服务和属性。这一信息可被视为该机制特有的信息。然而，其他未来的应用程序集成策略很可能需要类似的服务。因此，如果采用新的应用程序集成策略，这些服务可能会跨应用程序集成策略扩展。
GSS-API provides an optional security service called "mutual authentication". This service means that in addition to the initiator providing (potentially anonymous or pseudonymous) identity to the acceptor, the acceptor confirms its identity to the initiator. In the context of ABFAB in particular, the naming of this service is confusing. We still say that mutual authentication is provided when the identity of an acceptor is strongly authenticated to an anonymous initiator.
GSS-API提供了一种称为“相互认证”的可选安全服务。此服务意味着，除了启动器向接收方提供（可能匿名或假名）身份外，接收方还向启动器确认其身份。特别是在ABFAB的上下文中，此服务的命名令人困惑。我们仍然说，当接受方的身份被强身份验证给匿名发起方时，就提供了相互身份验证。
Unfortunately, [RFC2743] does not explicitly talk about what mutual authentication means. Within this document, we therefore define mutual authentication as follows:
不幸的是，[RFC2743]没有明确讨论相互认证的含义。因此，在本文件中，我们对相互认证的定义如下：
o If a target name is configured for the initiator, then the initiator trusts that the supplied target name describes the acceptor. This implies that (1) appropriate cryptographic exchanges took place for the initiator to make such a trust decision and (2) after evaluating the results of these exchanges, the initiator's policy trusts that the target name is accurate.
o 如果为启动器配置了目标名称，则启动器相信提供的目标名称描述了接受者。这意味着（1）发起方进行了适当的加密交换，以做出这样的信任决定；（2）在评估这些交换的结果后，发起方的策略相信目标名称是准确的。
o If no target name is configured for the initiator, then the initiator trusts that the acceptor name, supplied by the acceptor, correctly names the entity it is communicating with.
o 如果没有为发起程序配置目标名称，则发起程序相信由接受程序提供的接受程序名称正确命名了与之通信的实体。
o Both the initiator and acceptor have the same key material for per-message keys, and both parties have confirmed that they actually have the key material. In EAP terms, there is a protected indication of success.
o 发起者和接受者对于每条消息密钥都具有相同的密钥材料，并且双方都已确认他们实际拥有密钥材料。在EAP术语中，有一个受保护的成功迹象。
Mutual authentication is an important defense against certain aspects of phishing. Intuitively, clients would like to assume that if some party asks for their credentials as part of authentication, successfully gaining access to the resource means that they are talking to the expected party. Without mutual authentication, the server could "grant access" regardless of what credentials are supplied. Mutual authentication better matches this user intuition.
相互认证是针对网络钓鱼的某些方面的重要防御措施。直观地说，客户希望假设，如果某一方在身份验证过程中要求提供他们的凭据，那么成功获得对资源的访问意味着他们正在与预期的一方交谈。在没有相互身份验证的情况下，无论提供什么凭据，服务器都可以“授予访问权限”。相互认证更符合这种用户直觉。
It is important, therefore, that the GSS-EAP mechanism implement mutual authentication. That is, an initiator needs to be able to request mutual authentication. When mutual authentication is requested, only EAP methods capable of providing the necessary service can be used, and appropriate steps need to be taken to provide mutual authentication. While a broader set of EAP methods could be supported by not requiring mutual authentication, it was decided that the client needs to always have the ability to request it. In some cases, the IdP and the RP will not support mutual authentication; however, the client will always be able to detect this and make an appropriate security decision.
因此，GSS-EAP机制实现相互认证非常重要。也就是说，启动器需要能够请求相互身份验证。当请求相互认证时，只能使用能够提供必要服务的EAP方法，并且需要采取适当的步骤来提供相互认证。虽然可以通过不需要相互认证来支持更广泛的EAP方法集，但决定客户机需要始终具有请求该方法的能力。在某些情况下，IdP和RP将不支持相互认证；但是，客户端将始终能够检测到这一点，并做出适当的安全决策。
The AAA infrastructure may hide the initiator's identity from the GSS-API acceptor, providing anonymity between the initiator and the acceptor. At this time, whether the identity is disclosed is determined by EAP server policy rather than by an indication from the initiator. Also, initiators are unlikely to be able to determine whether anonymous communication will be provided. For this reason, initiators are unlikely to set the anonymous return flag from GSS_Init_sec_context (Section 2.2.1 of [RFC2743]).
AAA基础设施可以对GSS-API接受者隐藏发起人的身份，从而在发起人和接受者之间提供匿名性。此时，是否公开身份由EAP服务器策略而不是由来自发起方的指示来确定。此外，发起人不太可能确定是否提供匿名通信。因此，启动器不太可能从GSS_Init_sec_上下文（RFC2743的第2.2.1节）设置匿名返回标志。
[RFC5056] defines a concept of channel binding that is used to prevent man-in-the-middle attacks. This type of channel binding works by taking a cryptographic value from the transport security layer and checks to see that both sides of the GSS-API conversation know this value. Transport Layer Security (TLS) [RFC5246] is the most common transport security layer used for this purpose.
[RFC5056]定义了通道绑定的概念，用于防止中间人攻击。这种类型的通道绑定通过从传输安全层获取加密值并检查GSS-API会话的双方是否都知道该值来工作。传输层安全性（TLS）[RFC5246]是用于此目的的最常见的传输安全层。
It needs to be stressed that channel binding as described in [RFC5056] (also called "GSS-API channel binding" when GSS-API is involved) is not the same thing as EAP channel binding. GSS-API channel binding is used for detecting man-in-the-middle attacks. EAP channel binding is used for mutual authentication and acceptor naming checks. See [RFC7055] for details. A more detailed description of the differences between the facilities can be found in [RFC5056].
需要强调的是，[RFC5056]中描述的通道绑定（涉及GSS-API时也称为“GSS-API通道绑定”）与EAP通道绑定不同。GSS-API通道绑定用于检测中间人攻击。EAP通道绑定用于相互身份验证和接受方命名检查。详见[RFC7055]。有关设施之间差异的更详细说明，请参见[RFC5056]。
The use of TLS can provide both encryption and integrity on the channel. It is common to provide SASL and GSS-API with these other security services.
TLS的使用可以在通道上提供加密和完整性。为SASL和GSS-API提供这些其他安全服务是很常见的。
One of the benefits that the use of TLS provides is that a client has the ability to validate the name of the server. However, this validation is predicated on a couple of things. The TLS session needs to be using certificates and not be an anonymous session. The client and the TLS server need to share a common trust point for the certificate used in validating the server. TLS provides its own server authentication. However, there are a variety of situations where, for policy or usability reasons, this authentication is not checked. When the TLS authentication is checked, if the trust infrastructure behind the TLS authentication is different from the trust infrastructure behind the GSS-API mutual authentication, then confirming the endpoints using both trust infrastructures is likely to enhance security. If the endpoints of the GSS-API authentication are different than the endpoints of the lower layer, this is a strong indication of a problem, such as a man-in-the-middle attack. Channel binding provides a facility to determine whether these endpoints are the same.
使用TLS的好处之一是，客户端能够验证服务器的名称。然而，这种验证是基于以下几点。TLS会话需要使用证书，而不是匿名会话。客户端和TLS服务器需要为用于验证服务器的证书共享一个公共信任点。TLS提供自己的服务器身份验证。但是，在很多情况下，出于策略或可用性原因，此身份验证未被检查。检查TLS身份验证时，如果TLS身份验证背后的信任基础设施与GSS-API相互身份验证背后的信任基础设施不同，则确认使用这两个信任基础设施的端点可能会增强安全性。如果GSS-API身份验证的端点与较低层的端点不同，则这强烈表明存在问题，例如中间人攻击。通道绑定提供了一种工具来确定这些端点是否相同。
The GSS-EAP mechanism needs to support channel binding. When an application provides channel-binding data, the mechanism needs to confirm that this is the same on both sides, consistent with the GSS-API specification.
GSS-EAP机制需要支持通道绑定。当应用程序提供通道绑定数据时，该机制需要确认双方的数据相同，符合GSS-API规范。
IETF security mechanisms typically take a host name and perhaps a service, entered by a user, and make some trust decision about whether the remote party in the interaction is the intended party. This decision can be made via the use of certificates, preconfigured key information, or a previous leap of trust. GSS-API has defined a relatively flexible naming convention; however, most of the IETF applications that use GSS-API (including SSH, NFS, IMAP, LDAP, and XMPP) have chosen to use a more restricted naming convention based on the host name. The GSS-EAP mechanism needs to support host-based service names in order to work with existing IETF protocols.
IETF安全机制通常采用由用户输入的主机名和服务，并对交互中的远程方是否为预期方做出一些信任决策。可以通过使用证书、预配置的密钥信息或以前的信任飞跃来做出此决定。GSS-API定义了相对灵活的命名约定；但是，大多数使用GSS-API的IETF应用程序（包括SSH、NFS、IMAP、LDAP和XMPP）都选择使用基于主机名的更严格的命名约定。GSS-EAP机制需要支持基于主机的服务名称，以便与现有的IETF协议协同工作。
The use of host-based service names leads to a challenging trust delegation problem. Who is allowed to decide whether a particular host name maps to a specific entity? Possible solutions to this problem have been looked at.
使用基于主机的服务名称会导致一个具有挑战性的信任委派问题。允许谁来决定特定主机名是否映射到特定实体？已经研究了这个问题的可能解决办法。
o The Public Key Infrastructure (PKI) used by the web has chosen to have a number of trust anchors (root certificate authorities), each of which can map any host name to a public key.
o web使用的公钥基础设施（PKI）已选择具有多个信任锚（根证书颁发机构），每个信任锚都可以将任何主机名映射到公钥。
o A number of GSS-API mechanisms, such as Kerberos [RFC1964], have split the problem into two parts. [RFC1964] introduced a new concept called a realm; the realm is responsible for host mapping within itself. The mechanism then decides what realm is responsible for a given name. This is the approach adopted by ABFAB.
o 许多GSS-API机制，如Kerberos[RFC1964]，已将问题分为两部分。[RFC1964]引入了一个称为领域的新概念；领域负责自身内的主机映射。然后，该机制决定哪个领域负责给定的名称。这是ABFAB采用的方法。
GSS-EAP defines a host naming convention that takes into account the host name, the realm, the service, and the service parameters. An example of a GSS-API service name is "xmpp/foo@example.com". This identifies the XMPP service on the host foo in the realm example.com. Any of the components, except for the service name, may be omitted from a name. When omitted, a local default would be used for that component of the name.
GSS-EAP定义了一个主机命名约定，该约定考虑了主机名、领域、服务和服务参数。GSS-API服务名称的一个示例是“xmpp”/foo@example.com". 这标识了realmexample.com中主机foo上的XMPP服务。除了服务名称之外，任何组件都可以从名称中省略。省略时，名称的该组件将使用本地默认值。
While there is no requirement that realm names map to Fully Qualified Domain Names (FQDNs) within DNS, in practice this is normally true. Doing so allows the realm portion of service names and the portion of NAIs to be the same. It also allows for the use of DNS in locating the host of a service while establishing the transport channel between the client and the RP.
虽然没有要求域名映射到DNS中的完全限定域名（FQDN），但实际上这通常是正确的。这样做允许服务名称的领域部分和NAI的部分相同。它还允许使用DNS定位服务的主机，同时在客户端和RP之间建立传输通道。
It is the responsibility of the application to determine the server that it is going to communicate with; GSS-API has the ability to help confirm that the server is the desired server but not to determine the name of the server to use. It is also the responsibility of the
应用程序负责确定要与之通信的服务器；GSS-API能够帮助确认服务器是所需的服务器，但不能确定要使用的服务器的名称。这也是联合国的责任
application to determine how much of the information identifying the service needs to be validated by the ABFAB system. The information that needs to be validated is used to construct the service name passed into the GSS-EAP mechanism. What information is to be validated will depend on (1) what information was provided by the client and (2) what information is considered significant. If the client only cares about getting a specific service, then it does not need to validate the host and realm that provides the service.
应用程序确定ABFAB系统需要验证多少标识服务的信息。需要验证的信息用于构造传递到GSS-EAP机制的服务名称。要验证的信息取决于（1）客户提供的信息和（2）重要信息。如果客户机只关心获取特定服务，那么它不需要验证提供服务的主机和领域。
Applications may retrieve information about providers of services from DNS. Service Records (SRVs) [RFC2782] and Naming Authority Pointer (NAPTR) [RFC3401] records are used to help find a host that provides a service; however, the necessity of having DNSSEC on the queries depends on how the information is going to be used. If the host name returned is not going to be validated by EAP channel binding because only the service is being validated, then DNSSEC [RFC4033] is not required. However, if the host name is going to be validated by EAP channel binding, then DNSSEC needs to be used to ensure that the correct host name is validated. In general, if the information that is returned from the DNS query is to be validated, then it needs to be obtained in a secure manner.
应用程序可以从DNS检索有关服务提供商的信息。服务记录（SRV）[RFC2782]和命名机构指针（NAPTR）[RFC3401]记录用于帮助查找提供服务的主机；然而，在查询中使用DNSSEC的必要性取决于信息的使用方式。如果返回的主机名不会由EAP通道绑定验证，因为只有服务正在验证，则不需要DNSSEC[RFC4033]。但是，如果主机名将由EAP通道绑定验证，则需要使用DNSSEC来确保验证正确的主机名。通常，如果要验证从DNS查询返回的信息，则需要以安全的方式获取该信息。
Another issue that needs to be addressed for host-based service names is that they do not work ideally when different instances of a service are running on different ports. If the services are equivalent, then it does not matter. However, if there are substantial differences in the quality of the service, that information needs to be part of the validation process. If one has just a host name and not a port in the information being validated, then this is not going to be a successful strategy.
基于主机的服务名称需要解决的另一个问题是，当一个服务的不同实例在不同的端口上运行时，它们不能理想地工作。如果这些服务是等价的，那就没关系了。但是，如果服务质量存在重大差异，则该信息需要作为验证过程的一部分。如果在正在验证的信息中只有主机名而没有端口，那么这将不是一个成功的策略。
GSS-API provides per-message security services that can provide confidentiality and/or integrity. Some IETF protocols, such as NFS and SSH, take advantage of these services. As a result, GSS-EAP needs to support these services. As with mutual authentication, per-message security services will limit the set of EAP methods that can be used to those that generate a Master Session Key (MSK). Any EAP method that produces an MSK is able to support per-message security services as described in [RFC2743].
GSS-API提供可提供机密性和/或完整性的每条消息安全服务。一些IETF协议（如NFS和SSH）利用了这些服务。因此，GSS-EAP需要支持这些服务。与相互认证一样，每条消息安全服务将限制可用于生成主会话密钥（MSK）的EAP方法集。任何产生MSK的EAP方法都能够支持[RFC2743]中所述的每消息安全服务。
GSS-API provides a pseudorandom function. This function generates a pseudorandom sequence using the shared session key as the seed for the bytes generated. This provides an algorithm that both the initiator and acceptor can run in order to arrive at the same key value. The use of this feature allows an application to generate keys or other shared secrets for use in other places in the protocol.
GSS-API提供了一个伪随机函数。此函数使用共享会话密钥作为生成字节的种子来生成伪随机序列。这提供了一种算法，发起者和接受者都可以运行该算法以获得相同的键值。此功能的使用允许应用程序生成密钥或其他共享机密，以便在协议中的其他位置使用。
In this regard, it is similar in concept to the mechanism (formerly known as "TLS Extractors") described in [RFC5705]. While no current IETF protocols require this feature, non-IETF protocols are expected to take advantage of it in the near future. Additionally, a number of protocols have found the mechanism described in [RFC5705] to be useful in this regard, so it is highly probable that IETF protocols may also start using this feature.
在这方面，它在概念上类似于[RFC5705]中描述的机构（以前称为“TLS提取器”）。虽然目前没有IETF协议需要此功能，但非IETF协议有望在不久的将来利用此功能。此外，许多协议发现[RFC5705]中描述的机制在这方面很有用，因此IETF协议很可能也开始使用此功能。
As an architecture designed to enable federated authentication and allow for the secure transmission of identity information between entities, ABFAB obviously requires careful consideration regarding privacy and the potential for privacy violations.
作为一种旨在实现联邦身份验证并允许在实体之间安全传输身份信息的体系结构，ABFAB显然需要仔细考虑隐私和隐私侵犯的可能性。
This section examines the privacy-related information presented in this document, summarizing the entities that are involved in ABFAB communications and what exposure they have to identity information. In discussing these privacy considerations in this section, we use terminology and ideas from [RFC6973].
本节检查本文件中提供的隐私相关信息，总结参与ABFAB通信的实体以及他们对身份信息的接触情况。在本节讨论这些隐私注意事项时，我们使用[RFC6973]中的术语和思想。
Note that the ABFAB architecture uses at its core several existing technologies and protocols; detailed privacy discussion regarding these topics is not examined. This section instead focuses on privacy considerations specifically related to the overall architecture and usage of ABFAB.
注意，ABFAB架构的核心使用了几种现有技术和协议；关于这些主题的详细隐私讨论未经审查。本节将重点介绍与ABFAB的总体架构和使用相关的隐私注意事项。
+--------+ +---------------+ +--------------+
| Client | <---> | RP | <---> | AAA Client |
+--------+ +---------------+ +--------------+
^
|
v
+---------------+ +----------------+
| SAML Server | | AAA Proxy |
+---------------+ | (or Proxies) |
^ +----------------+
| ^
| |
v v
+------------+ +---------------+ +--------------+
| EAP Server | <---> | IdP | <---> | AAA Server |
+------------+ +---------------+ +--------------+
+--------+ +---------------+ +--------------+
| Client | <---> | RP | <---> | AAA Client |
+--------+ +---------------+ +--------------+
^
|
v
+---------------+ +----------------+
| SAML Server | | AAA Proxy |
+---------------+ | (or Proxies) |
^ +----------------+
| ^
| |
v v
+------------+ +---------------+ +--------------+
| EAP Server | <---> | IdP | <---> | AAA Server |
+------------+ +---------------+ +--------------+
Figure 4: Entities and Data Flow
图4：实体和数据流
Categorizing the ABFAB entities shown in Figure 4 according to the taxonomy of terms from [RFC6973] is somewhat complicated, as the roles of each entity will change during the various phases of ABFAB communications. The three main phases of relevance are the client-to-RP communication phase, the client-to-IdP (via the Federation Substrate) communication phase, and the IdP-to-RP (via the Federation Substrate) communication phase.
根据[RFC6973]中的术语分类法对图4所示的ABFAB实体进行分类有点复杂，因为每个实体的角色在ABFAB通信的各个阶段都会发生变化。相关的三个主要阶段是客户端到RP的通信阶段、客户端到IdP（通过联邦基板）的通信阶段和IdP到RP（通过联邦基板）的通信阶段。
In the client-to-RP communication phase, we have:
在客户与RP的沟通阶段，我们有：
Initiator: Client.
发起人：客户端。
Observers: Client, RP.
观察员：客户，RP。
Recipient: RP.
收件人：RP。
In the client-to-IdP (via the Federation Substrate) communication phase, we have:
在客户端到IdP（通过联邦基板）通信阶段，我们有：
Initiator: Client.
发起人：客户端。
Observers: Client, RP, AAA Client, AAA Proxy (or Proxies), AAA Server, IdP.
观察者：客户端、RP、AAA客户端、AAA代理、AAA服务器、IdP。
Recipient: IdP
收件人：IdP
In the IdP-to-RP (via the Federation Substrate) communication phase, we have:
在IdP到RP（通过联邦基板）通信阶段，我们有：
Initiator: RP.
发起者:RP。
Observers: IdP, AAA Server, AAA Proxy (or Proxies), AAA Client, RP.
观察者：IdP、AAA服务器、AAA代理、AAA客户端、RP。
Recipient: IdP
收件人：IdP
Eavesdroppers and attackers can reside on any or all communication links between the entities shown in Figure 4.
窃听者和攻击者可以驻留在图4所示实体之间的任何或所有通信链路上。
The various entities in the system might also collude or be coerced into colluding. Some of the significant collusions to look at are as follows:
系统中的各种实体也可能相互勾结或被强迫相互勾结。需要研究的一些重大串通行为如下：
o If two RPs are colluding, they have the information available to both nodes. This can be analyzed as if a single RP were offering multiple services.
o 如果两个RP相互勾结，则两个节点都有可用的信息。这可以像单个RP提供多个服务一样进行分析。
o If an RP and a AAA proxy are colluding, then the trust of the system is broken, as the RP would be able to lie about its own identity to the IdP. There is no known way to deal with this situation.
o 如果RP和AAA代理相互勾结，那么系统的信任就会被破坏，因为RP将能够向IdP隐瞒自己的身份。目前还没有已知的方法来处理这种情况。
o If multiple AAA proxies are colluding, they can be treated as a single node for analysis.
o 如果多个AAA代理相互勾结，则可以将它们视为单个节点进行分析。
The Federation Substrate consists of all of the AAA entities. In some cases, the AAA proxies may not exist, as the AAA client can talk directly to the AAA server. Specifications such as the Trust Router Protocol (https://www.ietf.org/proceedings/86/slides/ slides-86-rtgarea-0.pdf) and RADIUS dynamic discovery [RFC7585] can be used to shorten the path between the AAA client and the AAA server (and thus stop these AAA proxies from being observers); however, even in these circumstances, there may be AAA proxies in the path.
联合底层由所有AAA实体组成。在某些情况下，AAA代理可能不存在，因为AAA客户端可以直接与AAA服务器对话。信任路由器协议等规范(https://www.ietf.org/proceedings/86/slides/ slides-86-rtgarea-0.pdf）和RADIUS动态发现[RFC7585]可用于缩短AAA客户端和AAA服务器之间的路径（从而阻止这些AAA代理成为观察者）；但是，即使在这些情况下，路径中也可能存在AAA代理。
In Figure 4, the IdP has been divided into multiple logical pieces;
in actual implementations, these pieces will frequently be tightly
coupled. The links between these pieces provide the greatest
opportunity for attackers and eavesdroppers to acquire information;
however, as they are all under the control of a single entity, they
are also the easiest to have tightly secured.
In Figure 4, the IdP has been divided into multiple logical pieces;
in actual implementations, these pieces will frequently be tightly
coupled. The links between these pieces provide the greatest
opportunity for attackers and eavesdroppers to acquire information;
however, as they are all under the control of a single entity, they
are also the easiest to have tightly secured.
In the ABFAB architecture, there are a few different types of data and identifiers in use. The best way to understand them, and their potential privacy impacts, is to look at each phase of communication in ABFAB.
在ABFAB体系结构中，使用了几种不同类型的数据和标识符。了解它们及其潜在隐私影响的最佳方法是查看ABFAB中的每个通信阶段。
The flow of data between the client and the RP is divided into two parts. The first part consists of all of the data exchanged as part of the ABFAB authentication process. The second part consists of all of the data exchanged after the authentication process has been finished.
客户和RP之间的数据流分为两部分。第一部分包括作为ABFAB身份验证过程一部分交换的所有数据。第二部分包括身份验证过程完成后交换的所有数据。
During the initial communication phase, the client sends an NAI (see [RFC7542]) to the RP. Many EAP methods (but not all) allow the client to disclose an NAI to the RP in a form that includes only a realm component during this communication phase. This is the minimum amount of identity information necessary for ABFAB to work -- it indicates an IdP that the principal has a relationship with. EAP methods that do not allow this will necessarily also reveal an identifier for the principal in the IdP realm (e.g., a username).
在初始通信阶段，客户机向RP发送NAI（参见[RFC7542]）。许多EAP方法（但不是全部）允许客户机在此通信阶段以仅包括领域组件的形式向RP披露NAI。这是ABFAB工作所需的最小身份信息量——它表示委托人与之有关系的IdP。不允许这样做的EAP方法也必然会显示IdP领域中主体的标识符（例如用户名）。
The data shared during the initial communication phase may be protected by a channel protocol such as TLS. This will prevent the leakage of information to passive eavesdroppers; however, an active attacker may still be able to set itself up as a man-in-the-middle. The client may not be able to validate the certificates (if any) provided by the service, deferring the check of the identity of the RP until the completion of the ABFAB authentication protocol (using EAP channel binding rather than certificates).
初始通信阶段期间共享的数据可由诸如TLS的信道协议保护。这将防止信息泄露给被动窃听者；然而，活跃的攻击者可能仍然能够将自己设置为中间人。客户端可能无法验证服务提供的证书（如果有），从而将RP身份检查推迟到ABFAB身份验证协议完成（使用EAP通道绑定而不是证书）。
The data exchanged after the authentication process can have privacy and authentication using the GSS-API services. If the overall application protocol allows for the process of re-authentication, then the same privacy implications as those discussed in previous paragraphs apply.
身份验证过程后交换的数据可以使用GSS-API服务进行隐私和身份验证。如果整个应用程序协议允许重新身份验证过程，则适用与前面段落中讨论的相同的隐私含义。
This phase includes a secure TLS tunnel set up between the client and the IdP via the RP and Federation Substrate. The process is initiated by the RP using the realm information given to it by the client. Once set up, the tunnel is used to send credentials to the IdP to authenticate.
该阶段包括通过RP和联邦基板在客户端和IdP之间建立的安全TLS隧道。RP使用客户端提供给它的领域信息启动该过程。设置后，隧道用于向IdP发送凭据以进行身份验证。
Various operational information is transported between the RP and the IdP over the AAA infrastructure -- for example, using RADIUS headers. As no end-to-end security is provided by AAA, all AAA entities on the path between the RP and IdP have the ability to eavesdrop on this information. Some of this information may form identifiers or explicit identity information:
各种操作信息通过AAA基础设施在RP和IdP之间传输——例如，使用RADIUS报头。由于AAA不提供端到端安全性，RP和IdP之间路径上的所有AAA实体都有能力窃听此信息。其中一些信息可能形成标识符或明确的身份信息：
o The RP knows the IP address of the client. It is possible that the RP could choose to expose this IP address by including it in a RADIUS header (e.g., using the Calling-Station-Id). This is a privacy consideration to take into account for the application protocol.
o RP知道客户端的IP地址。RP可以选择通过将该IP地址包括在RADIUS报头中（例如，使用呼叫站Id）来公开该IP地址。这是应用程序协议需要考虑的隐私问题。
o The EAP MSK is transported between the IdP and the RP over the AAA infrastructure -- for example, through RADIUS headers. This is a particularly important privacy consideration, as any AAA proxy
o EAP MSK通过AAA基础设施在IdP和RP之间传输——例如，通过RADIUS报头。与任何AAA代理一样，这是一个特别重要的隐私考虑事项
that has access to the EAP MSK is able to decrypt and eavesdrop on any traffic encrypted using that EAP MSK (i.e., all communications between the client and RP). This problem can be mitigated if the application protocol sets up a secure tunnel between the client and the RP and performs a cryptographic binding between the tunnel and EAP MSK.
访问EAP MSK的用户能够解密和窃听使用该EAP MSK加密的任何流量（即，客户端和RP之间的所有通信）。如果应用程序协议在客户端和RP之间建立一个安全隧道，并在隧道和EAP MSK之间执行加密绑定，则可以缓解此问题。
o Related to the bullet point above, the AAA server has access to the material necessary to derive the session key; thus, the AAA server can observe any traffic encrypted between the client and RP. This "feature" was chosen as a simplification and to make performance faster; if it was decided that this trade-off was not desirable for privacy and security reasons, then extensions to ABFAB that make use of techniques such as Diffie-Hellman key exchange would mitigate this.
o 与上述要点相关，AAA服务器可以访问导出会话密钥所需的资料；因此，AAA服务器可以观察到客户端和RP之间加密的任何通信量。选择此“功能”是为了简化和提高性能；如果确定出于隐私和安全原因，这种权衡是不可取的，那么使用Diffie-Hellman密钥交换等技术的ABFAB扩展将缓解这种情况。
The choice of EAP method used has other potential privacy implications. For example, if the EAP method in use does not support mutual authentication, then there are no guarantees that the IdP is who it claims to be, and thus the full NAI, including a username and a realm, might be sent to any entity masquerading as a particular IdP.
所用EAP方法的选择还有其他潜在的隐私影响。例如，如果使用中的EAP方法不支持相互认证，则无法保证IdP是其声称的身份，因此完整的NAI（包括用户名和域）可能会发送给伪装为特定IdP的任何实体。
Note that ABFAB has not specified any AAA accounting requirements. Implementations that use the accounting portion of AAA should consider privacy appropriately when designing this aspect.
请注意，ABFAB未规定任何AAA会计要求。使用AAA的会计部分的实现应该在设计这方面时适当考虑隐私。
In this phase, the IdP communicates with the RP, informing it as to the success or failure of authentication of the user and, optionally, the sending of identity information about the principal.
在该阶段中，IdP与RP通信，告知其用户认证的成功或失败，以及可选地，关于主体的身份信息的发送。
As in the previous flow (client to IdP), various operation information is transported between the IdP and RP over the AAA infrastructure, and the same privacy considerations apply. However, in this flow, explicit identity information about the authenticated principal can be sent from the IdP to the RP. This information can be sent through RADIUS headers, or using SAML [RFC7833]. This can include protocol-specific identifiers, such as SAML NameIDs, as well as arbitrary attribute information about the principal. What information will be released is controlled by policy on the IdP. As before, when sending this information through RADIUS headers, all AAA entities on the path between the RP and IdP have the ability to eavesdrop, unless additional security measures are taken (such as the use of TLS for RADIUS [RFC6614]). However, when sending this
与前面的流程（客户端到IdP）一样，各种操作信息通过AAA基础设施在IdP和RP之间传输，同样的隐私考虑也适用。然而，在该流中，可以从IdP向RP发送关于已认证主体的显式标识信息。该信息可以通过RADIUS报头发送，或者使用SAML[RFC7833]。这可以包括特定于协议的标识符，例如SAML名称ID，以及关于主体的任意属性信息。将发布的信息由国内流离失所者政策控制。与之前一样，当通过RADIUS报头发送此信息时，RP和IdP之间路径上的所有AAA实体都具有窃听能力，除非采取额外的安全措施（例如对RADIUS使用TLS[RFC6614]）。但是，当发送此
information using SAML as specified in [RFC7833], confidentiality of the information should be guaranteed, as [RFC7833] requires the use of TLS for RADIUS.
使用[RFC7833]中规定的SAML的信息，应保证信息的机密性，因为[RFC7833]要求对RADIUS使用TLS。
o Between user and IdP - The IdP is an entity the user will have a direct relationship with, created when the organization that operates the entity provisioned and exchanged the user's credentials. Privacy and data protection guarantees may form a part of this relationship.
o 在用户和IdP之间-IdP是一个用户将与之有直接关系的实体，在运营实体的组织提供和交换用户凭证时创建。隐私和数据保护保障可能构成这种关系的一部分。
o Between user and RP - The RP is an entity the user may or may not have a direct relationship with, depending on the service in question. Some services may only be offered to those users where such a direct relationship exists (for particularly sensitive services, for example), while some may not require this and would instead be satisfied with basic federation trust guarantees between themselves and the IdP. This may well include the option that the user stays anonymous with respect to the RP (though, obviously, never anonymous to the IdP). If attempting to preserve privacy via data minimization (Section 1), then the only attribute information about Individuals exposed to the RP should be attribute information that is strictly necessary for the operation of the service.
o 在用户和RP之间-RP是一个实体，用户可能与之有直接关系，也可能与之没有直接关系，这取决于所讨论的服务。有些服务可能只提供给存在这种直接关系的用户（例如，对于特别敏感的服务），而有些服务可能不需要这样做，而是满足于他们自己和IdP之间的基本联邦信任保证。这很可能包括用户对RP保持匿名的选项（尽管，显然，决不会对IdP匿名）。如果试图通过数据最小化（第1节）来保护隐私，那么暴露于RP的个人的唯一属性信息应该是服务运行严格必需的属性信息。
o Between user and Federation Substrate - The user is highly likely to have no knowledge of, or relationship with, any entities involved with the Federation Substrate (not that the IdP and/or RP may, however). Knowledge of attribute information about Individuals for these entities is not necessary, and thus such information should be protected in such a way as to prevent the possibility of access to this information.
o 在用户和联邦基板之间-用户很可能不了解与联邦基板相关的任何实体或与之没有关系（但IdP和/或RP可能不知道）。对这些实体的个人属性信息的了解是不必要的，因此此类信息的保护方式应防止访问此类信息的可能性。
Alongside the core authentication and authorization that occur in AAA communications, accounting information about resource consumption may be delivered as part of the accounting exchange during the lifetime of the granted application session.
除了AAA通信中出现的核心身份验证和授权之外，有关资源消耗的记帐信息也可以在授予的应用程序会话的生命周期内作为记帐交换的一部分进行传递。
In cases where RPs are not required to identify a particular Individual when an Individual wishes to make use of their service, the ABFAB architecture enables anonymous or pseudonymous access. Thus, data and identifiers other than pseudonyms and unlinkable attribute information need not be stored and retained.
在个人希望使用其服务时，RPs不需要识别特定个人的情况下，ABFAB体系结构支持匿名或假名访问。因此，不需要存储和保留除笔名和不可链接的属性信息之外的数据和标识符。
However, in cases where RPs require the ability to identify a particular Individual (e.g., so they can link this identity information to a particular account in their service, or where identity information is required for audit purposes), the service will need to collect and store such information, and to retain it for as long as they require. The de-provisioning of such accounts and information is out of scope for ABFAB, but for privacy protection, it is obvious that any identifiers collected should be deleted when they are no longer needed.
但是，在RPs需要识别特定个人的情况下（例如，他们可以将此身份信息链接到其服务中的特定帐户，或者出于审计目的需要身份信息），服务将需要收集和存储此类信息，并在他们需要的时间内保留这些信息。此类账户和信息的取消配置不在ABFAB的范围内，但为了保护隐私，很明显，收集的任何标识符都应该在不再需要时删除。
In the ABFAB architecture, by its very nature users are active participants in the sharing of their identifiers, as they initiate the communications exchange every time they wish to access a server. They are, however, not involved in the control of information related to them that is transmitted from the IdP to the RP for authorization purposes; rather, this is under the control of policy on the IdP. Due to the nature of the AAA communication flows, with the current ABFAB architecture there is no place for a process of gaining user consent for the information to be released from the IdP to the RP.
在ABFAB体系结构中，用户本质上是共享其标识符的积极参与者，因为他们每次希望访问服务器时都会启动通信交换。但是，他们不参与控制从IdP向RP传输的用于授权目的的与其相关的信息；相反，这是在国内流离失所者政策的控制之下。由于AAA通信流的性质，在当前的ABFAB架构中，没有获得用户同意从IdP向RP发布信息的过程。
This document describes the architecture for Application Bridging for Federated Access Beyond web (ABFAB), and security is therefore the main focus. Many of the items that are security considerations have already been discussed in Section 4 ("Privacy Considerations"). Readers should be sure to read that section as well.
本文档描述了web之外的联合访问（ABFAB）的应用程序桥接体系结构，因此安全性是主要关注点。第4节（“隐私考虑”）中已经讨论了许多安全考虑事项。读者也应该阅读这一部分。
There are many places in this document where TLS is used. While in some places (e.g., client to RP) anonymous connections can be used, it is very important that TLS connections within the AAA infrastructure and between the client and the IdP be fully authenticated and, if using certificates, that revocation be checked as well. When using anonymous connections between the client and the RP, all messages and data exchanged between those two entities will be visible to an active attacker. In situations where the client is not yet on the network, the status_request extension [RFC6066] can be used to obtain revocation-checking data inside of the TLS protocol. Clients also need to get the trust anchor for the IdP configured correctly in order to prevent attacks; this is a difficult problem in general and is going to be even more difficult for kiosk environments.
本文件中有许多地方使用了TLS。虽然在某些地方（例如，客户端到RP）可以使用匿名连接，但AAA基础设施内以及客户端和IdP之间的TLS连接必须经过完全身份验证，并且如果使用证书，还必须检查撤销。在客户端和RP之间使用匿名连接时，主动攻击者将看到这两个实体之间交换的所有消息和数据。在客户端尚未在网络上的情况下，可以使用状态_请求扩展[RFC6066]获取TLS协议内部的撤销检查数据。客户端还需要正确配置IdP的信任锚，以防止攻击；这通常是一个困难的问题，对于kiosk环境来说将更加困难。
Selection of the EAP methods to be permitted by clients and IdPs is important. The use of a tunneling method such as TEAP [RFC7170] allows other EAP methods to be used while hiding the contents of
选择客户和IDP允许的EAP方法非常重要。使用TEAP[RFC7170]等隧道方法允许在隐藏数据内容的同时使用其他EAP方法
those EAP exchanges from the RP and the AAA framework. When considering inner EAP methods, the considerations outlined in [RFC7029] about binding the inner and outer EAP methods need to be taken into account. Finally, one wants to have the ability to support channel binding in those cases where the client needs to validate that it is talking to the correct RP.
这些EAP交换来自RP和AAA框架。在考虑内部EAP方法时，需要考虑[RFC7029]中概述的关于绑定内部和外部EAP方法的注意事项。最后，您希望能够在客户端需要验证它是否与正确的RP对话的情况下支持通道绑定。
In those places where SAML statements are used, RPs will generally be unable to validate signatures on the SAML statement, either because the signature has been stripped off by the IdP or because the RP is unable to validate the binding between the signer, the key used to sign, and the realm represented by the IdP. For these reasons, it is required that IdPs do the necessary trust checking on the SAML statements and that RPs can trust the AAA infrastructure to keep the SAML statements valid.
在使用SAML语句的地方，RPs通常无法验证SAML语句上的签名，这可能是因为签名已被IdP剥离，或者是因为RP无法验证签名者、用于签名的密钥和IdP表示的域之间的绑定。出于这些原因，要求IDP对SAML语句进行必要的信任检查，并且RPs可以信任AAA基础设施以保持SAML语句的有效性。
When a pseudonym is generated as a unique long-term identifier for a client by an IdP, care must be taken in the algorithm that it cannot easily be reverse-engineered by the service provider. If it can be reverse-engineered, then the service provider can consult an oracle to determine if a given unique long-term identifier is associated with a different known identifier.
当IdP将笔名生成为客户端的唯一长期标识符时，在算法中必须注意，服务提供商不容易对其进行反向工程。如果可以进行反向工程，则服务提供商可以咨询oracle，以确定给定的唯一长期标识符是否与不同的已知标识符相关联。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，DOI 10.17487/RFC2743，2000年1月<http://www.rfc-editor.org/info/rfc2743>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<http://www.rfc-editor.org/info/rfc2865>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, DOI 10.17487/RFC3579, September 2003, <http://www.rfc-editor.org/info/rfc3579>.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，DOI 10.17487/RFC3579，2003年9月<http://www.rfc-editor.org/info/rfc3579>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，编辑，“可扩展身份验证协议（EAP）”，RFC 3748，DOI 10.17487/RFC3748，2004年6月<http://www.rfc-editor.org/info/rfc3748>.
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, DOI 10.17487/RFC4072, August 2005, <http://www.rfc-editor.org/info/rfc4072>.
[RFC4072]Eronen，P.，Ed.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，DOI 10.17487/RFC4072，2005年8月<http://www.rfc-editor.org/info/rfc4072>.
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, <http://www.rfc-editor.org/info/rfc6677>.
[RFC6677]Hartman，S.，Ed.，Clancy，T.，和K.Hoeper，“可扩展身份验证协议（EAP）方法的通道绑定支持”，RFC 6677，DOI 10.17487/RFC6677，2012年7月<http://www.rfc-editor.org/info/rfc6677>.
[RFC7055] Hartman, S., Ed., and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", RFC 7055, DOI 10.17487/RFC7055, December 2013, <http://www.rfc-editor.org/info/rfc7055>.
[RFC7055]Hartman，S.，Ed.，和J.Howlett，“可扩展身份验证协议的GSS-API机制”，RFC 7055，DOI 10.17487/RFC7055，2013年12月<http://www.rfc-editor.org/info/rfc7055>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <http://www.rfc-editor.org/info/rfc7542>.
[RFC7542]DeKok，A.，“网络访问标识符”，RFC 7542，DOI 10.17487/RFC7542，2015年5月<http://www.rfc-editor.org/info/rfc7542>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, DOI 10.17487/RFC7833, May 2016, <http://www.rfc-editor.org/info/rfc7833>.
[RFC7833]Howlett，J.，Hartman，S.，和A.Perez Mendez，Ed.，“安全断言标记语言（SAML）的RADIUS属性、绑定、配置文件、名称标识符格式和确认方法”，RFC 7833，DOI 10.17487/RFC7833，2016年5月<http://www.rfc-editor.org/info/rfc7833>.
[NIST-SP.800-63-2] Burr, W., Dodson, D., Newton, E., Perlner, R., Polk, W., Gupta, S., and E. Nabbus, "Electronic Authentication Guideline", NIST Special Publication 800-63-2, August 2013, <http://dx.doi.org/10.6028/NIST.SP.800-63-2>.
[NIST-SP.800-63-2]Burr，W.，Dodson，D.，Newton，E.，Perlner，R.，Polk，W.，Gupta，S.，E.Nabbus，“电子认证指南”，NIST特别出版物800-63-22013年8月<http://dx.doi.org/10.6028/NIST.SP.800-63-2>.
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>.
[OASIS.saml-core-2.0-os]Cantor，S.，Kemp，J.，Philpott，R.，和E.Maler，“OASIS安全断言标记语言（saml）V2.0的断言和协议”，OASIS标准saml-core-2.0-os，2005年3月<http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, DOI 10.17487/RFC1964, June 1996, <http://www.rfc-editor.org/info/rfc1964>.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC 1964，DOI 10.17487/RFC1964，1996年6月<http://www.rfc-editor.org/info/rfc1964>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<http://www.rfc-editor.org/info/rfc2782>.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, DOI 10.17487/RFC3401, October 2002, <http://www.rfc-editor.org/info/rfc3401>.
[RFC3401]Melling，M，“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，DOI 10.17487/RFC3401，2002年10月<http://www.rfc-editor.org/info/rfc3401>.
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and R. Hall, "Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, DOI 10.17487/RFC3645, October 2003, <http://www.rfc-editor.org/info/rfc3645>.
[RFC3645]Kwan，S.，Garg，P.，Gilroy，J.，Esibov，L.，Westhead，J.，和R.Hall，“DNS密钥交易认证的通用安全服务算法（GSS-TSIG）”，RFC 3645，DOI 10.17487/RFC3645，2003年10月<http://www.rfc-editor.org/info/rfc3645>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.
[RFC4422]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<http://www.rfc-editor.org/info/rfc4422>.
[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, DOI 10.17487/RFC4462, May 2006, <http://www.rfc-editor.org/info/rfc4462>.
[RFC4462]Hutzelman，J.，Salowey，J.，Galbraith，J.，和V.Welch，“安全壳（SSH）协议的通用安全服务应用程序接口（GSS-API）认证和密钥交换”，RFC 4462，DOI 10.17487/RFC4462，2006年5月<http://www.rfc-editor.org/info/rfc4462>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, <http://www.rfc-editor.org/info/rfc5056>.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，DOI 10.17487/RFC5056，2007年11月<http://www.rfc-editor.org/info/rfc5056>.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 2007, <http://www.rfc-editor.org/info/rfc5080>.
[RFC5080]Nelson，D.和A.DeKok，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”，RFC 5080，DOI 10.17487/RFC5080，2007年12月<http://www.rfc-editor.org/info/rfc5080>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <http://www.rfc-editor.org/info/rfc5705>.
[RFC5705]Rescorla，E.“传输层安全（TLS）关键材料导出器”，RFC 5705，DOI 10.17487/RFC5705，2010年3月<http://www.rfc-editor.org/info/rfc5705>.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, July 2010, <http://www.rfc-editor.org/info/rfc5801>.
[RFC5801]Josefsson，S.和N.Williams，“在简单身份验证和安全层（SASL）中使用通用安全服务应用程序接口（GSS-API）机制：GS2机制系列”，RFC 5801，DOI 10.17487/RFC5801，2010年7月<http://www.rfc-editor.org/info/rfc5801>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <http://www.rfc-editor.org/info/rfc6614>.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，DOI 10.17487/RFC66142012年5月<http://www.rfc-editor.org/info/rfc6614>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<http://www.rfc-editor.org/info/rfc6733>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<http://www.rfc-editor.org/info/rfc6749>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<http://www.rfc-editor.org/info/rfc6973>.
[RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding", RFC 7029, DOI 10.17487/RFC7029, October 2013, <http://www.rfc-editor.org/info/rfc7029>.
[RFC7029]Hartman，S.，Wasserman，M.，和D.Zhang，“可扩展认证协议（EAP）相互加密绑定”，RFC 7029，DOI 10.17487/RFC7029，2013年10月<http://www.rfc-editor.org/info/rfc7029>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, <http://www.rfc-editor.org/info/rfc7170>.
[RFC7170]Zhou，H.，Cam Winget，N.，Salowey，J.，和S.Hanna，“隧道可扩展认证协议（TEAP）版本1”，RFC 7170，DOI 10.17487/RFC7170，2014年5月<http://www.rfc-editor.org/info/rfc7170>.
[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS", RFC 7360, DOI 10.17487/RFC7360, September 2014, <http://www.rfc-editor.org/info/rfc7360>.
[RFC7360]DeKok，A.，“作为RADIUS传输层的数据报传输层安全性（DTLS）”，RFC 7360，DOI 10.17487/RFC7360，2014年9月<http://www.rfc-editor.org/info/rfc7360>.
[RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/RFC7499, April 2015, <http://www.rfc-editor.org/info/rfc7499>.
[RFC7499]Perez Mendez，A.，Ed.，Marin Lopez，R.，Pereniguez Garcia，F.，Lopez Millan，G.，Lopez，D.，和A.DeKok，“支持RADIUS数据包碎片化”，RFC 7499，DOI 10.17487/RFC7499，2015年4月<http://www.rfc-editor.org/info/rfc7499>.
[RFC7530] Haynes, T., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<http://www.rfc-editor.org/info/rfc7530>.
[RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October 2015, <http://www.rfc-editor.org/info/rfc7585>.
[RFC7585]Winter，S.和M.McCauley，“基于网络访问标识符（NAI）的RADIUS/TLS和RADIUS/DTL动态对等发现”，RFC 7585，DOI 10.17487/RFC7585，2015年10月<http://www.rfc-editor.org/info/rfc7585>.
[WS-TRUST] Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin, M., Turner, D., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS Standard ws-trust-2012-04, April 2012, <http://docs.oasis-open.org/ws-sx/ws-trust/ v1.4/ws-trust.html>.
[WS-TRUST]Lawrence，K.，Kaler，C.，Nadalin，A.，Goodner，M.，Gudgin，M.，Turner，D.，Barbir，A.，和H.Granqvist，“WS-TRUST 1.4”，绿洲标准WS-TRUST-2012-042012年4月<http://docs.oasis-open.org/ws-sx/ws-trust/ v1.4/ws-trust.html>。
Acknowledgments
致谢
We would like to thank Mayutan Arumaithurai, Klaas Wierenga, and Rhys Smith for their feedback. Additionally, we would like to thank Eve Maler, Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul Leach, and Luke Howard for their feedback on the federation terminology question.
我们要感谢Mayutan Arumaithurai、Klaas Wierenga和Rhys Smith的反馈。此外，我们还要感谢伊芙·马勒、尼古拉斯·威廉姆斯、鲍勃·摩根、斯科特·坎托、吉姆·芬顿、保罗·里奇和卢克·霍华德对联邦术语问题的反馈。
Furthermore, we would like to thank Klaas Wierenga for his review of the first draft version of this document. We also thank Eliot Lear for his work on early draft versions of this document.
此外，我们要感谢克拉斯·维伦加对本文件初稿的审查。我们还感谢Eliot Lear为本文件的早期草稿所做的工作。
Authors' Addresses
作者地址
Josh Howlett Jisc Lumen House, Library Avenue, Harwell Oxford OX11 0SG United Kingdom
英国牛津哈维尔图书馆大道Josh Howlett Jisc Lumen House OX11 0SG
Phone: +44 1235 822363
Email: Josh.Howlett@ja.net
Phone: +44 1235 822363
Email: Josh.Howlett@ja.net
Sam Hartman Painless Security
山姆·哈特曼无痛安全
Email: hartmans-ietf@mit.edu
Email: hartmans-ietf@mit.edu
Hannes Tschofenig ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom
Hannes Tschofenig ARM Ltd.英国剑桥CB1 9NJ富尔伯恩路110号
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Jim Schaad August Cellars
吉姆·沙德八月酒窖
Email: ietf@augustcellars.com
Email: ietf@augustcellars.com