[要約] RFC 7056は、GSS-API拡張認証プロトコル（EAP）メカニズムのための名前属性に関する規格です。このRFCの目的は、EAPメカニズムで使用される名前属性の定義と使用方法を提供することです。
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.
Generic Security Serviceアプリケーションプログラミングインターフェイス（GSS-API）の命名拡張機能は、アプリケーションがGSS-API名に関連付けられた承認および個人化情報を検出するためのメカニズムを提供します。 Extensible Authentication Protocol GSS-APIメカニズムを使用すると、認証、承認、およびアカウンティング（AAA）ピアが、認証応答とともに承認属性を提供できます。また、AAA応答で提供されるセキュリティアサーションマークアップ言語（SAML）メッセージを処理するメカニズムも提供します。このドキュメントでは、Naming Extensions APIを使用してその情報にアクセスする方法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
Generic Security Serviceアプリケーションプログラミングインターフェース（GSS-API）[RFC2743]の命名拡張[RFC6680]は、アプリケーションがGSS-API名に関連付けられた承認および個人化情報を発見するためのメカニズムを提供します。拡張認証プロトコルGSS-APIメカニズム[RFC7055]を使用すると、認証、承認、およびアカウンティング（AAA）ピアが、認証応答とともに承認属性を提供できます。また、AAA応答で提供されるセキュリティアサーションマークアップ言語（SAML）メッセージを処理するメカニズムも提供します。 SAML拡張クライアント（EC）[SASL-SAML]などの他のメカニズムも、GSS-APIで伝送されるSAMLアサーションおよび属性をサポートします。このドキュメントでは、Naming Extensions 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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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によると、属性の名前には2つの部分があります。 1つ目は、名前の形式を説明するURI（Universal Resource Identifier）です。 2番目の部分は形式が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属性には、3つの部分で名前が付けられます。 1つは、名前がSAML属性であることを示し、コンテキストを説明するユニバーサルリソース名（URN）です（セクション4）。このURNの後には、スペース、SAML名の形式を示すURI、スペース、および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によって命名された多くの名前は、発行者とは無関係のセマンティクスを持つ可能性があります。ただし、未指定の名前形式を含む他の名前形式を使用すると、2つの発行者が異なるセマンティクスの属性に同じ名前を簡単に選択できます。連合コンテキスト（セクション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.
フェデレーションコンテキストでは、ピア資格情報の信頼できるソースは通常、いくつかのIDプロバイダーです。 GSS EAPメカニズムでは、AAAおよびSAMLソースからの情報が結合されます。 SAML IDプロバイダー（IdP）とホームAAAサーバーは、同じ信頼ドメインにあると想定されます。ただし、この信頼ドメインは通常、サービスの信頼ドメインと同じではありません。この仕様を使用する他のSAMLメカニズムでは、SAMLアサーションも認証を実行するパーティから取得されます。通常、IdPは同じフェデレーション内の別の組織によって実行されます。 IdPは、特にフェデレーションのコンテキストに関連するいくつかのステートメントを作成すると信頼されています。たとえば、アカデミックフェデレーションの参加者は通常、誰かが学生であるか教授であるかに関するIdPの主張を信頼します。ただし、同じIdPは通常、グループメンバーシップなどのローカルの資格についてのアサーションを行うことを信頼されません。したがって、サービスは、IdPが特定の属性をアサートすることを許可されているかどうか、およびアサートされた値が受け入れ可能かどうかについてポリシー決定を行わなければなりません（MUST）。このポリシーは、サービスのローカル構成として、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.
これらの名前は、クレデンシャルのソースが属性を再アサートしない限り、クレデンシャルのソースに密接に関連付けられている者以外の当事者によって発行された属性に使用してはならない（MUST NOT）。たとえば、資格情報のソースは、選択した属性のソースを参照できますが、アクセプターは、フェデレーションコンテキストの属性が資格情報のソースからのものであると想定できます。この要件は、通常、メカニズム仕様で実施されます。たとえば、[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]メカニズムによってaccess-acceptメッセージで受信されたRADIUS属性の命名方法について説明します。このセクションで定義されている他のRADIUSメッセージの属性、またはaccess-acceptメッセージの前の属性の使用は、現時点では未定義です。将来の仕様では、これらの領域を調査して、下位互換性に適切な重みを与えることができます。特に、この仕様は、GSS_S_COMPLETEを返した後のGSS_Accept_sec_contextの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-attribute（これがGSS-EAP RADIUS AVPであることを示すURN）です。 [RFC6929]のセクション2.7で説明されているように、この後にスペースと数字のRADIUS名が続きます。たとえば、User-Name属性の名前は「urn：ietf：params：gss：radius-attribute 1」です。タイプ241内の拡張タイプ1の名前は、「urn：ietf：params：gss：radius-attribute 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.
RADIUS access-accept応答にRADIUS User-Name属性が含まれている場合を考えます。この属性の値を取得しようとするアプリケーションは、GSS-_Accept_sec_contextがGSS_S_COMPLETEを返すまで最初に待機します。次に、アプリケーションはGSS_Accept_sec_contextからのsrc_name出力を取得し、この名前と「urn：ietf：params：gss：radius-attribute 1」の属性を入力として渡してGSS_Get_name_attributeを呼び出します。認証されたブール出力が真であることを確認した後、アプリケーションは値出力でユーザー名を見つけることができます。
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属性の値は、パケットの未加工オクテットです。整数はネットワークバイトオーダーです。表示値は人間が読める文字列であるべきです（SHOULD）。実装は、特定のRADIUS属性のタイプを知っている場合にのみ、この文字列を生成できます。 RADIUSメッセージに特定の名前を持つ複数の属性が存在する場合、複数値のGSS-API属性を返す必要があります（SHOULD）。例外として、実装では、複数の属性を使用して253オクテットを超える情報を運ぶEAPメッセージや[RFC6929]で定義されている大きな属性などのRADIUS属性を連結する必要があります。
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_attributeが呼び出されると、メカニズムがSAMLステートメントを正常に認証できる場合にのみ、認証された出力がtrueに設定されてこの属性が返されます。 GSS-EAPメカニズムの場合、これは、AAA交換が正常に認証された場合に当てはまります。ただし、GSS-APIを使用する場合は、属性が認証済みとマークされていることを確認する必要があります。
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名属性でもある必要があります（SHOULD）。この属性の名前には3つの部分があり、すべてASCIIスペース文字で区切られています。最初の部分はurn：ietf：params：gss：federated-saml-attributeです。 2番目の部分は、<saml：Attribute>要素のNameFormat XML属性のURIです。最後の部分は、<saml：Attribute>要素のName XML属性です。 SAML属性名自体にスペースが含まれる場合があります。 URI仕様[RFC3986]で要求されているように、URI内のスペースは「％20」としてエンコードされます。名前の最初または2番目の部分を含む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.
例として、eduPersonEntitlement属性がアサーションに存在する場合、「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 "がGSS_Inquire_Nameから返される可能性があります。アプリケーションがattrパラメータにこの属性を指定してGSS_Get_name_attributeを呼び出す場合、値の出力には、認証されたユーザーに関連付けられた資格のURIが1つ以上含まれます。
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名属性の未加工の値と「表示」値は、要素のテキストコンテンツである必要があります。生の値は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名属性の未加工の値は、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アサーションが正常に検証される必要があります。そのアサーションからの属性は、認証された出力がtrueに設定されたGSS_Get_name_attributeから返される必要があります。実装は、このアサーションの各属性にローカルポリシーチェックを適用し、これらのチェックに従って許容できない場合はその属性を破棄してもよい（MAY）。
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名属性にする必要があります（SHOULD）。この属性の名前には、ASCIIスペース文字で区切られた2つの部分があります。最初の部分はurn：ietf：params：gss：federated-saml-nameidです。 2番目の部分は、<saml：NameID>要素のFormat XML属性の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>要素の整形式のシリアル化である必要があります。 "display"値は実装で定義されています。 [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アサーションが十分に検証される必要があります。実装は、このアサーションにローカルポリシーチェックを適用して、これらのチェックに従って受け入れられない場合は破棄することができます（MAY）。
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アサーションにアクセスする方法について説明します。これらの属性は通常、2つの目的のいずれかで使用されます。最も機密性が低いのはパーソナライゼーションです。中央サービスは、認証されたユーザーに関する情報を提供できるため、アクセスするアクセプターごとに入力する必要はありません。より機密性の高い使用法は承認です。
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アサーション、属性、および名前識別子に対してローカルポリシーチェックを実行するメカニズムが許可されています。 [AAA-SAML]で説明されているメカニズムなど、SAMLアサーションにアクセスする別の方法がある場合、アプリケーションは、SAMLへのアクセス方法に応じて異なる結果を取得できます（MAY）。これは意図された動作です。ローカルポリシーチェックをバイパスすることを選択したアプリケーションは、情報に依存する前に独自の評価を実行する必要があります。
A new top-level registry has been created titled "Generic Security Service Application Program Interface Parameters".
「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 Parameters」というサブレジストリが作成されています。このレジストリへの登録は、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 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ストリームでRFCとして公開されたプロトコルの一部としてのみ期待されます。他のURIは、IETF以外の作業に適した選択肢であると予想されます。専門家によるレビューは、コミュニティが十分な成熟に達したとコミュニティが考えている場合、主に開発中の仕様に関連する早期登録を許可するために許可されています。専門家は、そのようなIETFストリーム仕様の成熟度と安定性を評価する必要があります（SHOULD）。専門家は、現在の慣行との一貫性とコンセンサスについて、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 |
+--------------------------+-------------+
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
仕様：RFC 7056
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.
著者は、Stephen Farrell、Luke Howard、および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。、「Generic Security Service Application Program Interface Version 2、Update 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、「An Registered Protocol Parameters for IETF URN Sub-namespace for Registered Protocol Parameters」、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、「RFCで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]ウィリアムズN.、ヨハンソンL.、ハートマンS.、およびS.ジョセフソン、「Generic Security Service Application Programming Interface（GSS-API）Naming Extensions」、RFC 6680、2012年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、「Remote Authentication Dial In User Service（RADIUS）Protocol Extensions」、RFC 6929、2013年4月。
[RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", RFC 7055, December 2013.
[RFC7055]ハートマン、S。、エド。およびJ.ハウレット、「Extensible Authentication Protocolの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 Namespaces Conformance」、2009、<http://www.w3.org/TR/2009/REC-xml-names-20091208/ #Conformance>。
[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]ハウレット、J。およびS.ハートマン、「RADIUS属性、バインディング、プロファイル、名前識別子の形式、および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、「Uniform Resource Identifier（URI）：Generic Syntax」、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 Enhanced Client SASL and GSS-API Mechanisms」、Work in Progress、2013年9月。
Authors' Addresses
著者のアドレス
Sam Hartman Painless Security
サムハートマンの痛みのないセキュリティ
EMail: hartmans-ietf@mit.edu
Josh Howlett JANET(UK)
ジョシュハウレットジャネット（英国）
EMail: josh.howlett@ja.net