Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7056 Painless Security
Category: Standards Track J. Howlett
ISSN: 2070-1721 JANET(UK)
December 2013
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7056 Painless Security
Category: Standards Track J. Howlett
ISSN: 2070-1721 JANET(UK)
December 2013
Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism
GSS-API可扩展身份验证协议（EAP）机制的名称属性
Abstract
摘要
The naming extensions to the Generic Security Service Application Programming Interface (GSS-API) provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication, Authorization, and Accounting (AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes how to use the Naming Extensions API to access that information.
通用安全服务应用程序编程接口（GSS-API）的命名扩展为应用程序发现与GSS-API名称相关的授权和个性化信息提供了一种机制。可扩展身份验证协议GSS-API机制允许身份验证、授权和记帐（AAA）对等方在身份验证响应的同时提供授权属性。它还提供了处理AAA响应中提供的安全断言标记语言（SAML）消息的机制。本文档介绍如何使用命名扩展API访问该信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7056.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7056.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Naming Extensions and SAML ......................................3
4. Federated Context ...............................................4
5. Name Attributes for GSS-EAP .....................................5
6. Names of SAML Attributes in the Federated Context ...............6
6.1. Assertions .................................................6
6.2. SAML Attributes ............................................6
6.3. SAML Name Identifiers ......................................7
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
8.1. Registration of the GSS URN Namespace ......................9
9. Acknowledgements ................................................9
10. References ....................................................10
10.1. Normative References .....................................10
10.2. Informative References ...................................11
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Naming Extensions and SAML ......................................3
4. Federated Context ...............................................4
5. Name Attributes for GSS-EAP .....................................5
6. Names of SAML Attributes in the Federated Context ...............6
6.1. Assertions .................................................6
6.2. SAML Attributes ............................................6
6.3. SAML Name Identifiers ......................................7
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
8.1. Registration of the GSS URN Namespace ......................9
9. Acknowledgements ................................................9
10. References ....................................................10
10.1. Normative References .....................................10
10.2. Informative References ...................................11
The naming extensions [RFC6680] to the Generic Security Service Application Programming Interface (GSS-API) [RFC2743] provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism [RFC7055] allows an Authentication, Authorization, and Accounting (AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. Other mechanisms such as SAML Enhanced Client (EC) [SASL-SAML] also support SAML assertions and attributes carried in the GSS-API. This document describes how to use the Naming Extensions API to access that information.
通用安全服务应用程序编程接口（GSS-API）[RFC2743]的命名扩展[RFC6680]为应用程序发现与GSS-API名称相关的授权和个性化信息提供了一种机制。可扩展认证协议GSS-API机制[RFC7055]允许认证、授权和计费（AAA）对等方在认证响应的同时提供授权属性。它还提供了处理AAA响应中提供的安全断言标记语言（SAML）消息的机制。其他机制，如SAML增强型客户端（EC）[SASL-SAML]也支持GSS-API中携带的SAML断言和属性。本文档介绍如何使用命名扩展API访问该信息。
The semantics of setting attributes defined in this specification are undefined and left to future work.
本规范中定义的设置属性的语义未定义，留待以后的工作。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
SAML assertions can carry attributes describing properties of the subject of the assertion. For example, an assertion might carry an attribute describing the organizational affiliation or email address of a subject. According to Sections 8.2 and 2.7.3.1 of [OASIS], the name of an attribute has two parts. The first is a Universal Resource Identifier (URI) describing the format of the name. The second part, whose form depends on the format URI, is the actual name. GSS-API name attributes may take a form starting with a URI describing the form of the name; the rest of the name is specified by that URI.
SAML断言可以携带描述断言主题属性的属性。例如，断言可能带有一个属性，描述主题的组织从属关系或电子邮件地址。根据[OASIS]第8.2节和第2.7.3.1节，属性的名称有两部分。第一个是描述名称格式的通用资源标识符（URI）。第二部分是实际名称，其形式取决于格式URI。GSS-API名称属性可以采用以描述名称形式的URI开头的形式；名称的其余部分由该URI指定。
SAML attributes carried in GSS-API names are named with three parts. The first is a Universal Resource Name (URN) indicating that the name is a SAML attribute and describing the context (Section 4). This URN is followed by a space, the URI indicating the format of the SAML name, a space, and the SAML attribute name. The URI indicating the format of the SAML attribute name is not optional and MUST be present.
GSS-API名称中包含的SAML属性由三部分命名。第一个是通用资源名（URN），指示该名称是SAML属性并描述上下文（第4节）。这个URN后面是一个空格，URI指示SAML名称的格式、一个空格和SAML属性名。指示SAML属性名称格式的URI不是可选的，必须存在。
SAML attribute names may not be globally unique. Many names that are named by URNs or URIs are likely to have semantics independent of the issuer. However, other name formats, including unspecified name formats, make it easy for two issuers to choose the same name for attributes with different semantics. Attributes using the federated context (Section 4) are issued by the same party performing the authentication. So, based on who is the subject of the name, the semantics of the attribute can be determined.
SAML属性名称可能不是全局唯一的。许多由URN或URI命名的名称可能具有独立于颁发者的语义。但是，其他名称格式，包括未指定的名称格式，使得两个发行人可以轻松地为具有不同语义的属性选择相同的名称。使用联邦上下文（第4节）的属性由执行身份验证的同一方发布。因此，基于谁是名称的主体，可以确定属性的语义。
GSS-API naming extensions have the concept of an authenticated name attribute. The mechanism guarantees that the contents of an authenticated name attribute are an authenticated statement from the trusted source of the peer credential. The fact that an attribute is authenticated does not imply that the trusted source of the peer credential is authorized to assert the attribute.
GSS-API命名扩展具有经过身份验证的名称属性的概念。该机制保证已验证名称属性的内容是来自对等凭据的受信任源的已验证语句。属性经过身份验证的事实并不意味着对等凭据的受信任源有权断言该属性。
In the federated context, the trusted source of the peer credential is typically some identity provider. In the GSS EAP mechanism, information is combined from AAA and SAML sources. The SAML Identity Provider (IdP) and home AAA server are assumed to be in the same trust domain. However, this trust domain is not typically the same as the trust domain of the service. With other SAML mechanisms using this specification, the SAML assertion also comes from the party performing authentication. Typically, the IdP is run by another organization in the same federation. The IdP is trusted to make some statements, particularly related to the context of a federation. For example, an academic federation's participants would typically trust an IdP's assertions about whether someone was a student or a professor. However, that same IdP would not typically be trusted to make assertions about local entitlements such as group membership. Thus, a service MUST make a policy decision about whether the IdP is permitted to assert a particular attribute and about whether the asserted value is acceptable. This policy can be implemented as local configuration on the service, as rules in AAA proxies, or through other deployment-specific mechanisms.
在联合上下文中，对等凭据的受信任源通常是某个身份提供者。在GSS EAP机制中，信息来自AAA和SAML源。假定SAML身份提供程序（IdP）和家庭AAA服务器位于同一信任域中。但是，此信任域通常与服务的信任域不同。对于使用此规范的其他SAML机制，SAML断言也来自执行身份验证的一方。通常，IdP由同一联邦中的另一个组织运行。IdP可以发表一些声明，特别是与联邦背景相关的声明。例如，学术联盟的参与者通常会相信IdP关于某人是学生还是教授的断言。然而，通常不会信任同一个IdP对本地权利（如团体成员资格）做出断言。因此，服务必须做出关于是否允许IdP断言特定属性以及断言值是否可接受的策略决策。此策略可以作为服务上的本地配置、AAA代理中的规则或通过其他特定于部署的机制来实现。
In contrast, attributes in an enterprise context are often verified by a central authentication infrastructure that is trusted to assert most or all attributes. For example, in a Kerberos infrastructure, the Key Distribution Center (KDC) typically indicates group membership information for clients to a server using KDC-authenticated authorization data.
相反，企业上下文中的属性通常由一个中央身份验证基础结构进行验证，该基础结构被信任来断言大部分或所有属性。例如，在Kerberos基础结构中，密钥分发中心（KDC）通常使用KDC身份验证的授权数据向服务器指示客户端的组成员身份信息。
The context of an attribute is an important property of that attribute; trust context is an important part of this overall context. In order for applications to distinguish the context of
属性的上下文是该属性的一个重要属性；信任上下文是整个上下文的重要组成部分。为了让应用程序区分
attributes, attributes with different contexts need different names. This specification defines attribute names for SAML and AAA attributes in the federated context.
属性，具有不同上下文的属性需要不同的名称。该规范定义了联合上下文中SAML和AAA属性的属性名称。
These names MUST NOT be used for attributes issued by a party other than one closely associated with the source of credentials unless the source of credentials is re-asserting the attributes. For example, a source of credentials can consult whatever sources of attributes it chooses, but acceptors can assume attributes in the federated context are from the source of credentials. This requirement is typically enforced in mechanism specifications. For example, [AAA-SAML] provides enough information that we know the attributes it carries today are in the federated context. Similarly, we know that the requirements of this paragraph are met by SAML mechanisms where the assertion is the means of authentication.
这些名称不得用于由与凭据源密切相关的一方以外的另一方发布的属性，除非凭据源正在重新断言这些属性。例如，凭据源可以查询它选择的任何属性源，但是接受者可以假定联合上下文中的属性来自凭据源。该要求通常在机构规范中强制执行。例如，[AAA-SAML]提供了足够的信息，我们知道它现在所携带的属性是在联邦上下文中。同样，我们知道SAML机制满足了本段的要求，其中断言是身份验证的手段。
This section describes how RADIUS attributes received in an access-accept message by the GSS-EAP [RFC7055] mechanism are named. The use of attributes defined in this section for other RADIUS messages or prior to the access-accept message is undefined at this time. Future specifications can explore these areas giving adequate weight to backward compatibility. In particular, this specification defines the meaning of these attributes for the src_name output of GSS_Accept_sec_context after that function returns GSS_S_COMPLETE. Attributes MAY be absent or values MAY change in other circumstances; future specifications MAY define this behavior.
本节介绍如何命名GSS-EAP[RFC7055]机制在访问接受消息中接收的RADIUS属性。对于其他RADIUS消息或access accept消息之前定义的属性，本节中定义的属性的使用目前尚未定义。未来的规范可以探索这些领域，为向后兼容性提供足够的权重。特别是，在函数返回GSS_S_COMPLETE之后，本规范为GSS_Accept_sec_上下文的src_name输出定义了这些属性的含义。在其他情况下，属性可能不存在或值可能发生变化；未来的规范可能会定义此行为。
The first portion of the name is urn:ietf:params:gss:radius-attribute (a URN indicating that this is a GSS-EAP RADIUS AVP). This is followed by a space and a numeric RADIUS name as described by Section 2.7 of [RFC6929]. For example, the name of the User-Name attribute is "urn:ietf:params:gss:radius-attribute 1". The name of extended type 1 within type 241 would be "urn:ietf:params:gss:radius-attribute 241.1".
名称的第一部分是urn:ietf:params:gss:radius属性（表示这是gss-EAP radius AVP的urn）。后跟[RFC6929]第2.7节所述的空格和数字半径名称。例如，用户名属性的名称是“urn:ietf:params:gss:radius attribute 1”。类型241中扩展类型1的名称为“urn:ietf:params:gss:radius属性241.1”。
Consider a case where the RADIUS access-accept response includes the RADIUS User-Name attribute. An application wishing to retrieve the value of this attribute would first wait until GSS-_Accept_sec_context returned GSS_S_COMPLETE. Then, the application would take the src_name output from GSS_Accept_sec_context and call GSS_Get_name_attribute passing this name and an attribute of "urn:ietf:params:gss:radius-attribute 1" as inputs. After confirming that the authenticated boolean output is true, the application can find the username in the values output.
Consider a case where the RADIUS access-accept response includes the RADIUS User-Name attribute. An application wishing to retrieve the value of this attribute would first wait until GSS-_Accept_sec_context returned GSS_S_COMPLETE. Then, the application would take the src_name output from GSS_Accept_sec_context and call GSS_Get_name_attribute passing this name and an attribute of "urn:ietf:params:gss:radius-attribute 1" as inputs. After confirming that the authenticated boolean output is true, the application can find the username in the values output.translate error, please retry
The value of RADIUS attributes is the raw octets of the packet. Integers are in network byte order. The display value SHOULD be a human-readable string; an implementation can only produce this string if it knows the type of a given RADIUS attribute. If multiple attributes are present with a given name in the RADIUS message, then a multi-valued GSS-API attribute SHOULD be returned. As an exception, implementations SHOULD concatenate RADIUS attributes such as EAP message or large attributes defined in [RFC6929] that use multiple attributes to carry more than 253 octets of information.
RADIUS属性的值是数据包的原始八位字节。整数按网络字节顺序排列。显示值应为人类可读的字符串；实现只有在知道给定RADIUS属性的类型时才能生成此字符串。如果RADIUS消息中存在具有给定名称的多个属性，则应返回多值GSS-API属性。作为例外，实现应连接RADIUS属性，如EAP消息或[RFC6929]中定义的大型属性，这些属性使用多个属性来承载253个八位字节以上的信息。
An assertion generated by the credential source is named by "urn:ietf:params:gss:federated-saml-assertion". The value of this attribute is the assertion carried in the AAA protocol or used for authentication in a SAML mechanism. This attribute is absent from a given acceptor name if no such assertion is present or if the assertion fails local policy checks.
凭证源生成的断言由“urn:ietf:params:gss:federated saml assertion”命名。该属性的值是AAA协议中携带的断言，或用于SAML机制中的身份验证。如果不存在此类断言，或者如果断言未通过本地策略检查，则给定的接受程序名称中不存在此属性。
When GSS_Get_name_attribute is called, this attribute will be returned with the authenticated output set to true only if the mechanism can successfully authenticate the SAML statement. For the GSS-EAP mechanism, this is true if the AAA exchange has successfully authenticated. However, uses of the GSS-API MUST confirm that the attribute is marked authenticated as other mechanisms MAY permit an initiator to provide an unauthenticated SAML statement.
当调用GSS_Get_name_属性时，只有当机制能够成功地对SAML语句进行身份验证时，才会返回此属性，并将已验证的输出设置为true。对于GSS-EAP机制，如果AAA交换已成功进行身份验证，则为真。但是，GSS-API的使用必须确认该属性标记为已验证，因为其他机制可能允许启动器提供未经验证的SAML语句。
Mechanisms MAY perform additional local policy checks and MAY remove the attribute corresponding to assertions that fail these checks.
机制可以执行额外的本地策略检查，并且可以删除与未通过这些检查的断言相对应的属性。
Each attribute carried in the assertion SHOULD also be a GSS name attribute. The name of this attribute has three parts, all separated by an ASCII space character. The first part is urn:ietf:params:gss:federated-saml-attribute. The second part is the URI for the <saml:Attribute> element's NameFormat XML attribute. The final part is the <saml:Attribute> element's Name XML attribute. The SAML attribute name may itself contain spaces. As required by the URI specification [RFC3986], spaces within a URI are encoded as "%20". Spaces within a URI, including either the first or second part of the name, encoded as "%20" do not separate parts of the GSS-API attribute name; they are simply part of the URI.
断言中包含的每个属性也应该是GSS名称属性。此属性的名称有三个部分，全部由ASCII空格字符分隔。第一部分是urn:ietf:params:gss:federated saml属性。第二部分是<saml:Attribute>元素的NameFormat XML属性的URI。最后一部分是<saml:Attribute>元素的Name XML属性。SAML属性名称本身可能包含空格。根据URI规范[RFC3986]的要求，URI中的空格编码为“%20”。URI中编码为“%20”的空格（包括名称的第一部分或第二部分）不分隔GSS-API属性名称的各个部分；它们只是URI的一部分。
As an example, if the eduPersonEntitlement attribute is present in an assertion, then an attribute with the name "urn:ietf:params:gss:federated-saml-attribute urn:oasis:names:tc:SAML:2.0:attrname-format:uri urn:oid:1.3.6.1.4.1.5923.1.1.1.7" could be returned from GSS_Inquire_Name. If an application calls GSS_Get_name_attribute with this attribute in the attr parameter, then the values output would include one or more URIs of entitlements that were associated with the authenticated user.
例如，如果断言中存在EdupersoneTitlement属性，那么可以从gss_Inquire_name返回名为“urn:ietf:params:gss:federated saml attribute urn:oasis:names:tc:saml:2.0:attrname format:uri urn:oid:1.3.6.1.4.1.5923.1.1.1.7”的属性。如果应用程序在attr参数中使用此属性调用GSS_Get_name_属性，则输出的值将包括一个或多个与经过身份验证的用户关联的权限URI。
If the content of each <saml:AttributeValue> element is a simple text node (or nodes), then the raw and "display" values of the GSS name attribute MUST be the text content of the element(s). The raw value MUST be encoded as UTF-8.
如果每个<saml:AttributeValue>元素的内容是一个简单的文本节点，那么GSS name属性的原始值和“显示”值必须是元素的文本内容。原始值必须编码为UTF-8。
If the value is not simple or is empty, then the raw value(s) of the GSS name attribute MUST be a namespace well-formed serialization [XMLNS] of the <saml:AttributeValue> element(s) encoded as UTF-8. The "display" values are implementation defined.
如果该值不简单或为空，则GSS name属性的原始值必须是编码为UTF-8的<saml:AttributeValue>元素的命名空间格式良好的序列化[XMLNS]。“显示”值由实现定义。
These attributes SHOULD be marked authenticated if they are contained in SAML assertions that have been successfully validated back to the trusted source of the peer credential. In the GSS-EAP mechanism, a SAML assertion carried in an integrity-protected and authenticated AAA protocol SHALL be successfully validated; attributes from that assertion SHALL be returned from GSS_Get_name_attribute with the authenticated output set to true. An implementation MAY apply local policy checks to each attribute in this assertion and discard the attribute if it is unacceptable according to these checks.
如果这些属性包含在SAML断言中，并且已成功验证回对等凭据的受信任源，则应将其标记为已验证。在GSS-EAP机制中，应成功验证完整性保护和认证AAA协议中携带的SAML断言；来自该断言的属性应该从GSS_Get_name_属性返回，并且经过身份验证的输出设置为true。实现可以对此断言中的每个属性应用本地策略检查，如果根据这些检查该属性不可接受，则放弃该属性。
The <saml:NameID> carried in the subject of the assertion SHOULD also be a GSS name attribute. The name of this attribute has two parts, separated by an ASCII space character. The first part is urn:ietf:params:gss:federated-saml-nameid. The second part is the URI for the <saml:NameID> element's Format XML attribute.
断言主题中包含的<saml:NameID>也应该是GSS name属性。此属性的名称有两部分，由ASCII空格字符分隔。第一部分是urn:ietf:params:gss:federated saml nameid。第二部分是<saml:NameID>元素的formatxml属性的URI。
The raw value of the GSS name attribute MUST be the well-formed serialization of the <saml:NameID> element encoded as UTF-8. The "display" value is implementation defined. For formats defined by Section 8.3 of [OASIS], missing values of the NameQualifier or SPNameQualifier XML attributes MUST be populated in accordance with the definition of the format prior to serialization. In other words, the defaulting rules specified for the "persistent" and "transient" formats MUST be applied prior to serialization.
GSS name属性的原始值必须是编码为UTF-8的<saml:NameID>元素的格式良好的序列化。“显示”值由实现定义。对于[OASIS]第8.3节定义的格式，在序列化之前，必须根据格式定义填充NameQualifier或SPNameQualifier XML属性的缺失值。换句话说，为“持久”和“暂时”格式指定的默认规则必须在序列化之前应用。
This attribute SHOULD be marked authenticated if the name identifier is contained in a SAML assertion that has been successfully validated back to the trusted source of the peer credential. In the GSS-EAP mechanism, a SAML assertion carried in an integrity-protected and authenticated AAA protocol SHALL be sufficiently validated. An implementation MAY apply local policy checks to this assertion and discard it if it is unacceptable according to these checks.
如果名称标识符包含在已成功验证回对等凭据的受信任源的SAML断言中，则应将此属性标记为已验证。在GSS-EAP机制中，完整性保护和认证AAA协议中的SAML断言应得到充分验证。实现可以对此断言应用本地策略检查，如果根据这些检查不可接受，则放弃该断言。
This document describes how to access RADIUS attributes, SAML attributes, and SAML assertions from some GSS-API mechanisms. These attributes are typically used for one of two purposes. The least sensitive is personalization: a central service MAY provide information about an authenticated user so they need not enter it with each acceptor they access. A more sensitive use is authorization.
本文档描述如何从一些GSS-API机制访问RADIUS属性、SAML属性和SAML断言。这些属性通常用于以下两个目的之一。最不敏感的是个性化：中央服务可以提供关于经过身份验证的用户的信息，这样他们就不需要在访问的每个接收者中输入信息。更敏感的用途是授权。
The mechanism is responsible for authentication and integrity protection of the attributes. However, the acceptor application is responsible for making a decision about whether the credential source is trusted to assert the attribute and validating the asserted value.
该机制负责属性的身份验证和完整性保护。但是，接受者应用程序负责决定是否信任凭证源来断言属性，并验证断言的值。
Mechanisms are permitted to perform local policy checks on SAML assertions, attributes, and name identifiers exposed through name attributes defined in this document. If there is another way to get access to the SAML assertion, for example, the mechanism described in [AAA-SAML], then an application MAY get different results depending on how the SAML is accessed. This is intended behavior; applications who choose to bypass local policy checks SHOULD perform their own evaluation before relying on information.
允许机制对通过本文档中定义的名称属性公开的SAML断言、属性和名称标识符执行本地策略检查。如果有其他方法可以访问SAML断言，例如[AAA-SAML]中描述的机制，那么应用程序可能会根据访问SAML的方式获得不同的结果。这是有意的行为；选择绕过本地策略检查的应用程序应在依赖信息之前执行自己的评估。
A new top-level registry has been created titled "Generic Security Service Application Program Interface Parameters".
已经创建了一个名为“通用安全服务应用程序接口参数”的新顶级注册表。
In this top-level registry, a subregistry titled "GSS-API URN Parameters" has been created. Registration in this registry is by the IETF Review or Expert Review procedures [RFC5226].
在这个顶级注册表中，创建了一个名为“GSS-API URN参数”的子域。通过IETF审查或专家审查程序[RFC5226]在本注册中心注册。
This paragraph gives guidance to Designated Experts. Registrations in this registry are generally only expected as part of protocols published as RFCs on the IETF stream; other URIs are expected to be better choices for non-IETF work. Expert Review is permitted mainly to permit early registration related to specifications under development when the community believes they have reach sufficient maturity. The expert SHOULD evaluate the maturity and stability of
本段为指定专家提供指导。该注册表中的注册通常仅作为IETF流上作为RFC发布的协议的一部分；其他URI有望成为非IETF工作的更好选择。允许专家审查的主要目的是，当社区认为正在开发的规范已达到足够成熟时，允许对其进行早期注册。专家应评估产品的成熟度和稳定性
such an IETF-stream specification. Experts SHOULD review anything not from the IETF stream for consistency and consensus with current practice. Today, such requests would not typically be approved.
这样的IETF流规范。专家应审查IETF流以外的任何内容，以确保与当前实践的一致性和共识。如今，这类请求通常不会得到批准。
If the "paramname" parameter is registered in this registry, then its URN will be "urn:ietf:params:gss:paramname". The initial registrations are as follows:
如果“paramname”参数已在此注册表中注册，则其URN将为“URN:ietf:params:gss:paramname”。初步注册情况如下：
+--------------------------+-------------+
| Parameter | Reference |
+--------------------------+-------------+
| radius-attribute | Section 5 |
| federated-saml-assertion | Section 6.1 |
| federated-saml-attribute | Section 6.2 |
| federated-saml-nameid | Section 6.3 |
+--------------------------+-------------+
+--------------------------+-------------+
| Parameter | Reference |
+--------------------------+-------------+
| radius-attribute | Section 5 |
| federated-saml-assertion | Section 6.1 |
| federated-saml-attribute | Section 6.2 |
| federated-saml-nameid | Section 6.3 |
+--------------------------+-------------+
IANA has registered the "gss" URN sub-namespace in the IETF URN sub-namespace for protocol parameters defined in [RFC3553].
IANA已在[RFC3553]中定义的协议参数的IETF URN子命名空间中注册了“gss”URN子命名空间。
Registry Name: gss
注册名称：gss
Specification: RFC 7056
规格：RFC7056
Repository: GSS-API URN Parameters (Section 8)
存储库：GSS-API URN参数（第8节）
Index Value: Sub-parameters MUST be specified in UTF-8 using standard URI encoding where necessary.
索引值：必要时，必须使用标准URI编码在UTF-8中指定子参数。
Scott Cantor contributed significant text and multiple reviews of this document.
Scott Cantor对本文件提供了重要的文本和多次评论。
The authors would like to thank Stephen Farrell, Luke Howard, and Jim Schaad.
作者要感谢斯蒂芬·法雷尔、卢克·霍华德和吉姆·沙德。
Sam Hartman's work on this specification has been funded by Janet.
Sam Hartman在该规范方面的工作由Janet资助。
[OASIS] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005.
[OASIS]Cantor，S.，Kemp，J.，Philpott，R.，和E.Maler，“OASIS安全断言标记语言（SAML）V2.0的断言和协议”，OASIS标准SAML-core-2.0-os，2005年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，2003年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6680] Williams, N., Johansson, L., Hartman, S., and S. Josefsson, "Generic Security Service Application Programming Interface (GSS-API) Naming Extensions", RFC 6680, August 2012.
[RFC6680]Williams，N.，Johansson，L.，Hartman，S.，和S.Josefsson，“通用安全服务应用程序编程接口（GSS-API）命名扩展”，RFC 66802012年8月。
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.
[RFC6929]DeKok，A.和A.Lior，“远程身份验证拨入用户服务（RADIUS）协议扩展”，RFC 69292013年4月。
[RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", RFC 7055, December 2013.
[RFC7055]Hartman，S.，Ed.和J.Howlett，“可扩展身份验证协议的GSS-API机制”，RFC 7055，2013年12月。
[XMLNS] W3C, "XML Namespaces Conformance", 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208/ #Conformance>.
[XMLNS]W3C，“XML名称空间一致性”，2009年<http://www.w3.org/TR/2009/REC-xml-names-20091208/ #一致性>。
[AAA-SAML] Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML", Work in Progress, July 2013.
[AAA-SAML]Howlett，J.和S.Hartman，“SAML的半径属性、绑定、配置文件、名称标识符格式和确认方法”，正在进行的工作，2013年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[SASL-SAML] Cantor, S. and S. Josefsson, "SAML Enhanced Client SASL and GSS-API Mechanisms", Work in Progress, September 2013.
[SASL-SAML]Cantor，S.和S.Josefsson，“SAML增强型客户端SASL和GSS-API机制”，正在进行的工作，2013年9月。
Authors' Addresses
作者地址
Sam Hartman Painless Security
山姆·哈特曼无痛安全
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Josh Howlett JANET(UK)
Josh Howlett JANET（英国）
EMail: josh.howlett@ja.net
EMail: josh.howlett@ja.net