RFC 6680 - Generic Security Service Application Programming Interface (GSS-API) Naming Extensions 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6680
タイトル : RFC 6680 - Generic Security Serviceアプリケーションプログラミングインターフェイス（GSS-API）の名前付け拡張
翻訳編集 : 自動生成

[要約] RFC 6680は、GSS-APIの命名拡張に関する規格であり、セキュリティサービスのアプリケーションプログラミングインターフェースの拡張を提供します。目的は、GSS-APIを使用してセキュリティ関連の情報を効果的に扱い、ネットワークアプリケーションのセキュリティを向上させることです。

Internet Engineering Task Force (IETF)                       N. Williams
Request for Comments: 6680                             Cryptonector, LLC
Category: Standards Track                                   L. Johansson
ISSN: 2070-1721                                                    SUNET
                                                              S. Hartman
                                                       Painless Security
                                                            S. Josefsson
                                                                  SJD AB
                                                             August 2012

Generic Security Service Application Programming Interface (GSS-API) Naming Extensions

Generic Security Serviceアプリケーションプログラミングインターフェイス（GSS-API）の名前付け拡張

Abstract

概要

The Generic Security Service Application Programming Interface (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers.

Generic Security Serviceアプリケーションプログラミングインターフェイス（GSS-API）は、名前ベースの承認をサポートするシンプルな命名アーキテクチャを提供します。このドキュメントでは、GSS-APIピア間の名前属性転送をサポートするためにGSS-APIネーミングモデルを拡張する新しい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/rfc6680.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6680で入手できます。

著作権表示

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

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.eで説明されているSimplified BSD Licenseテキストが含まれている必要があります。

the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Trust Legal ProvisionsおよびSimplified BSD Licenseに記載されているように保証なしで提供されます。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   3.  Name Attribute Authenticity  . . . . . . . . . . . . . . . . .  4
   4.  Name Attributes/Values as ACL Subjects . . . . . . . . . . . .  4
   5.  Naming Contexts  . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Representation of Attribute Names  . . . . . . . . . . . . . .  6
   7.  API  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1.  SET OF OCTET STRING  . . . . . . . . . . . . . . . . . . .  7
     7.2.  Const Types  . . . . . . . . . . . . . . . . . . . . . . .  8
     7.3.  GSS_Display_name_ext() . . . . . . . . . . . . . . . . . .  8
       7.3.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . .  9
     7.4.  GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . .  9
       7.4.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . 10
     7.5.  GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 10
       7.5.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . 11
     7.6.  GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 12
       7.6.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . 13
     7.7.  GSS_Delete_name_attribute()  . . . . . . . . . . . . . . . 14
       7.7.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . 14
     7.8.  GSS_Export_name_composite()  . . . . . . . . . . . . . . . 14
       7.8.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2. Informative References . . . . . . . . . . . . . . . . . . 17

1. Introduction

1. はじめに

As described in [RFC4768], the GSS-API's naming architecture suffers from certain limitations. This document attempts to overcome these limitations.

[RFC4768]で説明されているように、GSS-APIの命名アーキテクチャには特定の制限があります。このドキュメントは、これらの制限を克服することを試みます。

A number of extensions to the GSS-API [RFC2743] and its C-bindings [RFC2744] are described herein. The goal is to make information modeled as "name attributes" available to applications. Such information MAY, for instance, be used by applications to make authorization decisions. For example, Kerberos V authorization data elements, both in their raw forms as well as mapped to more useful value types, can be made available to GSS-API applications through these interfaces.

GSS-API [RFC2743]とそのCバインディング[RFC2744]に対する多数の拡張機能がここで説明されています。目標は、「名前属性」としてモデル化された情報をアプリケーションで使用できるようにすることです。そのような情報は、たとえば、承認の決定を行うためにアプリケーションによって使用される場合があります。たとえば、Kerberos V承認データ要素は、それらの生の形式であるだけでなく、より有用な値の型にマップされているため、これらのインターフェースを通じてGSS-APIアプリケーションで利用できます。

The model is that GSS names have attributes. The attributes of a name may be authenticated (e.g., an X509 attribute certificate or signed Security Assertion Markup Language (SAML) attribute assertion) or may have been set on a GSS name for the purpose of locally "asserting" the attribute during credential acquisition or security context exchange. Name attributes' values are network representations thereof (e.g., the actual value octets of the contents of an X.509 certificate extension, for example) and are intended to be useful for constructing portable access control facilities. Applications may often require language- or platform-specific data types, rather than network representations of name attributes, so a function is provided to obtain objects of such types associated with names and name attributes.

モデルは、GSS名に属性があることです。名前の属性は、認証されている場合（X509属性証明書または署名済みのセキュリティアサーションマークアップ言語（SAML）属性アサーションなど）、または資格の取得中に属性をローカルで「アサート」する目的でGSS名に設定されている場合があります。セキュリティコンテキスト交換。名前属性の値は、そのネットワーク表現（たとえば、X.509証明書拡張のコンテンツの実際の値のオクテットなど）であり、ポータブルアクセス制御機能の構築に役立つことを目的としています。アプリケーションは、名前属性のネットワーク表現ではなく、言語またはプラットフォーム固有のデータ型を必要とすることがよくあります。そのため、名前と名前属性に関連付けられたそのような型のオブジェクトを取得する関数が提供されています。

Future updates of this specification may involve adding an attribute namespace for attributes that only have application-specific semantics. Note that mechanisms will still need to know how to transport such attributes. The IETF may also wish to add functions by which to inquire whether a mechanism(s) understands a given attribute name or namespace and to list which attributes or attribute namespaces a mechanism understands. Finally, the IETF may want to consider adding a function by which to determine the name of the issuer of a name attribute.

この仕様の将来の更新には、アプリケーション固有のセマンティクスのみを持つ属性の属性名前空間の追加が含まれる可能性があります。メカニズムは、そのような属性を転送する方法を知る必要があることに注意してください。 IETFは、メカニズムが特定の属性名または名前空間を理解しているかどうかを問い合わせ、メカニズムが理解する属性または属性名前空間をリストする機能を追加することもできます。最後に、IETFは、名前属性の発行者の名前を判別するための関数を追加することを検討する場合があります。

2. Conventions Used in This Document

2. このドキュメントで使用される規則

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]で説明されているように解釈されます。

3. Name Attribute Authenticity

3. 名前属性の信頼性

An attribute is "authenticated" if and only if there is a secure association between the attribute (and its values) and the trusted source of the peer credential. Examples of authenticated attributes are (any part of) the signed portion of an X.509 certificate or AD-KDCIssued authorization data elements (Section 5.2.6.2 of [RFC4120]) in Kerberos V Tickets, provided, of course, that the authenticity of the respective security associations (e.g., signatures) has been verified.

属性は、属性（およびその値）とピア資格情報の信頼できるソースとの間に安全な関連付けがある場合にのみ「認証」されます。認証された属性の例は、X.509証明書の署名部分（の一部）またはKerberos VチケットのAD-KDCIで発行された承認データ要素（[RFC4120]のセクション5.2.6.2）です。それぞれのセキュリティアソシエーション（署名など）が確認されている。

Note that the fact that an attribute is authenticated does not imply anything about the semantics of the attribute nor that the trusted credential source was authorized to assert the attribute. Such interpretations SHOULD be the result of applying local policy to the attribute.

属性が認証されるという事実は、属性のセマンティクスについて何も意味せず、信頼できる資格情報ソースが属性を表明することを承認されていることに注意してください。このような解釈は、属性にローカルポリシーを適用した結果である必要があります（SHOULD）。

An unauthenticated attribute is called _asserted_ in what follows. This is not to be confused with other uses of the words "asserted" or "assertion" such as "SAML attribute assertion", the attributes of which may be authenticated in the sense of this document, for instance, if the SAML attribute assertion was signed by a key trusted by the peer.

認証されていない属性は、以下では_asserted_と呼ばれます。これは、「SAML属性アサーション」などの「アサート」または「アサーション」という単語の他の使用と混同しないでください。たとえば、SAML属性アサーションがこのドキュメントの意味で認証される場合があります。ピアが信頼する鍵で署名されています。

4. Name Attributes/Values as ACL Subjects

4. ACLサブジェクトとしての名前属性/値

To facilitate the development of portable applications that make use of name attributes to construct and evaluate portable Access Control Lists (ACLs), the GSS-API makes name attribute values available in canonical network encodings thereof.

名前属性を使用してポータブルアクセスコントロールリスト（ACL）を構築および評価するポータブルアプリケーションの開発を容易にするために、GSS-APIは名前属性値をその標準的なネットワークエンコーディングで使用できるようにします。

5. Naming Contexts

5. コンテキストの命名

Several factors influence the context in which a name attribute is interpreted. One is the trust context.

名前属性が解釈されるコンテキストには、いくつかの要因が影響します。 1つは信頼コンテキストです。

As discussed previously, applications apply local policy to determine whether a particular peer credential issuer is trusted to make a given statement. Different GSS-API mechanisms and deployments have different trust models surrounding attributes they provide about a name.

前述のように、アプリケーションはローカルポリシーを適用して、特定のピア資格情報発行者が特定のステートメントを発行することを信頼できるかどうかを判断します。異なるGSS-APIメカニズムと配備には、名前について提供する属性を取り巻く異なる信頼モデルがあります。

For example, Kerberos deployments in the enterprise typically trust a Key Distribution Center (KDC) to make any statement about principals in a realm. This includes attributes such as group membership.

たとえば、企業でのKerberos展開は通常、レルム内のプリンシパルについての発言を行うためにキー配布センター（KDC）を信頼します。これには、グループメンバーシップなどの属性が含まれます。

In contrast, in a federated SAML environment, the identity provider typically exists in a different organization than the acceptor. In this case, the set of group memberships or entitlements that the IDP is permitted to make needs to be filtered by the policy of the acceptor and federation.

対照的に、フェデレーテッドSAML環境では、IDプロバイダーは通常、アクセプターとは異なる組織に存在します。この場合、IDPが作成を許可されているグループメンバーシップまたは資格のセットは、アクセプターおよびフェデレーションのポリシーによってフィルター処理する必要があります。

So even an attribute containing the same information, such as email address, would need to be treated differently by the application in the context of an enterprise deployment from the context of a federation.

したがって、電子メールアドレスなどの同じ情報を含む属性であっても、企業の展開のコンテキストでは、フェデレーションのコンテキストとは異なる方法でアプリケーションで処理する必要があります。

Another aspect related to trust is the role of the credential issuer in providing the attribute. Consider Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC4556]. In this protocol, a public key and associated certificate are used to authenticate to a Kerberos KDC. Consider how attributes related to a PKINIT certificate should be made available in GSS-API authentications based on the Kerberos ticket. In some deployments, the certificate may be fully trusted; by including the certificate information in the ticket, the KDC permits the acceptor to trust the information in the certificate just as if the KDC itself had made these statements. In other deployments, the KDC may have authorized a hash of the certificate without evaluating the content of the certificate or generally trusting the issuing certification authority. In this case, if the certificate were included in the issued ticket, the KDC would only be making the statement that the certificate was used in the authentication. This statement would be authenticated but would not imply that the KDC asserted that particular attributes of the certificate accurately described the initiator.

信頼に関連するもう1つの側面は、属性を提供する際の資格情報発行者の役割です。 Kerberosでの初期認証（PKINIT）[RFC4556]の公開鍵暗号化を検討してください。このプロトコルでは、公開鍵と関連する証明書を使用して、Kerberos KDCに対する認証を行います。 PKINIT証明書に関連する属性を、Kerberosチケットに基づくGSS-API認証でどのように使用できるようにするかを検討します。一部の展開では、証明書が完全に信頼されている場合があります。チケットに証明書情報を含めることにより、KDCは、KDC自体がこれらのステートメントを作成したかのように、アクセプターが証明書の情報を信頼することを許可します。他の展開では、KDCは、証明書の内容を評価したり、一般に発行元の証明機関を信頼したりせずに、証明書のハッシュを承認している場合があります。この場合、発行されたチケットに証明書が含まれていると、KDCは、証明書が認証で使用されたという記述のみを行います。このステートメントは認証されますが、証明書の特定の属性が開始者を正確に説明しているとKDCが主張したことを意味するものではありません。

Another aspect of context is encoding of the attribute information. An attribute containing an ASCII [ANSI.X3-4.1986] or UTF-8 [RFC3629] version of an email address could not be interpreted the same as an ASN.1 Distinguished Encoding Rules email address in a certificate.

コンテキストのもう1つの側面は、属性情報のエンコードです。電子メールアドレスのASCII [ANSI.X3-4.1986]またはUTF-8 [RFC3629]バージョンを含む属性は、証明書のASN.1 Distinguished Encoding Rules電子メールアドレスと同じように解釈できませんでした。

All of these contextual aspects of a name attribute affect whether two attributes can be treated the same by an application and thus whether they should be considered the same name attribute. In the GSS-API naming extensions, attributes that have different contexts MUST have different names so they can be distinguished by applications. As an unfortunate consequence of this requirement, multiple attribute names will exist for the same basic information. That is, there is no single attribute name for the email address of an initiator. Other aspects of how mechanisms describe information about subjects would already make this true. For example, some mechanisms use OIDs to name attributes; others use URIs.

名前属性のこれらのコンテキストのすべての側面は、2つの属性をアプリケーションで同じように処理できるかどうか、したがって同じ名前属性と見なすべきかどうかに影響します。 GSS-APIネーミング拡張では、異なるコンテキストを持つ属性は、アプリケーションで区別できるように、異なる名前を持つ必要があります。この要件の残念な結果として、同じ基本情報に複数の属性名が存在します。つまり、イニシエーターのEメール・アドレスの単一の属性名はありません。メカニズムが被験者に関する情報を記述する方法の他の側面は、これをすでに実現しています。たとえば、一部のメカニズムはOIDを使用して属性に名前を付けます。他はURIを使用します。

Local implementations or platforms are likely to have sufficient policy and information to know when contexts can be treated as the same. For example, the GSS-API implementation may know that a particular certification authority can be trusted in the context of a PKINIT authentication. The local implementation may have sufficient policy to know that a particular credential issuer is trusted to make a given statement. In order to take advantage of this local knowledge within the GSS-API implementation, naming extensions support the concept of local attributes in addition to standard attributes. For example, an implementation might provide a local attribute for email address. The implementation would specify the encoding and representation of this attribute; mechanism-specific standards attributes would be re-encoded if necessary to meet this representation. Only email addresses in contexts that meet the requirements of local policy would be mapped into this local attribute.

ローカル実装またはプラットフォームには、コンテキストを同じものとして扱うことができる時期を知るための十分なポリシーと情報が含まれている可能性があります。たとえば、GSS-API実装は、特定の認証局がPKINIT認証のコンテキストで信頼できることを知っている場合があります。ローカル実装には、特定の資格情報発行者が特定のステートメントを発行することを信頼されていることを知るのに十分なポリシーがある場合があります。 GSS-API実装内でこのローカル知識を利用するために、ネーミング拡張は、標準属性に加えてローカル属性の概念をサポートします。たとえば、実装ではメールアドレスのローカル属性を提供する場合があります。実装では、この属性のエンコーディングと表現を指定します。メカニズム固有の標準属性は、この表現を満たすために必要であれば再エンコードされます。ローカルポリシーの要件を満たすコンテキストの電子メールアドレスのみが、このローカル属性にマップされます。

Such local attributes inherently expose a trade-off between interoperability and usability. Using a local attribute in an application requires knowledge of the local implementation. However, using a standardized attribute in an application requires more knowledge of policy and more validation logic in the application. Sharing this logic in the local platform provides more consistency across applications as well as reduces implementation costs. Both options are needed.

このようなローカル属性は本質的に、相互運用性と使いやすさのトレードオフを露呈しています。アプリケーションでローカル属性を使用するには、ローカル実装の知識が必要です。ただし、アプリケーションで標準化された属性を使用するには、アプリケーションのポリシーと検証ロジックの知識が必要です。このロジックをローカルプラットフォームで共有すると、アプリケーション全体の一貫性が向上し、実装コストが削減されます。両方のオプションが必要です。

6. Representation of Attribute Names

6. 属性名の表現

Different underlying mechanisms (e.g., SAML or X.509 certificates) provide different representations for the names of their attributes. In X.509 certificates, most objects are named by object identifiers (OIDs). The type of object (certificate extension, name constraint, keyPurposeID, etc.) along with the OID is sufficient to identify the attribute. By contrast, according to Sections 8.2 and 2.7.3.1 of [OASIS.saml-core-2.0-os], the name of an attribute has two parts. The first is a URI describing the format of the name. The second part, whose form depends on the format URI, is the actual name. In other cases, an attribute might represent a certificate that plays some particular role in a GSS-API mechanism; such attributes might have a simple mechanism-defined name.

基盤となるメカニズム（SAMLやX.509証明書など）によって、属性の名前の表現が異なります。 X.509証明書では、ほとんどのオブジェクトはオブジェクト識別子（OID）によって名前が付けられます。オブジェクトのタイプ（証明書の拡張子、名前の制約、keyPurposeIDなど）とOIDで属性を識別できます。対照的に、[OASIS.saml-core-2.0-os]のセクション8.2および2.7.3.1によると、属性の名前は2つの部分に分かれています。 1つ目は、名前の形式を説明するURIです。 2番目の部分は、形式がフォーマットURIに依存し、実際の名前です。他の場合では、属性は、GSS-APIメカニズムで特定の役割を果たす証明書を表す場合があります。そのような属性は、単純なメカニズム定義の名前を持つ場合があります。

Attribute names MUST support multiple components. If there is more than one component in an attribute name, the more significant components define the semantics of the less significant components.

属性名は複数のコンポーネントをサポートする必要があります。属性名に複数のコンポーネントがある場合、重要度の高いコンポーネントは重要度の低いコンポーネントのセマンティクスを定義します。

Attribute names are represented as OCTET STRING elements in the API described below. These attribute names have syntax and semantics that are understood by the application and by the lower-layer implementations (some of which are described below).

属性名は、以下で説明するAPIではOCTET STRING要素として表されます。これらの属性名には、アプリケーションと下位層の実装（一部は以下で説明）が理解できる構文とセマンティクスがあります。

If an attribute name contains a space (ASCII 0x20), the first space separates the most significant or primary component of the name from the remainder. We may refer to the primary component of the attribute name as the attribute name's "prefix". If there is no space, the primary component is the entire name; otherwise, it defines the interpretation of the remainder of the names.

属性名にスペース（ASCII 0x20）が含まれている場合、最初のスペースは、名前の最も重要なコンポーネントまたは主要なコンポーネントを残りのスペースから分離します。属性名の主要コンポーネントを属性名の「プレフィックス」と呼ぶ場合があります。スペースがない場合、主要コンポーネントは名前全体です。それ以外の場合は、残りの名前の解釈を定義します。

If the primary component contains a ":" (ASCII 0x3a), then the primary component is a URI. Otherwise, the attribute is a local attribute and the primary component has meaning to the implementation of GSS-API or to the specific configuration of the application. Local attribute names with an "at" sign ("@") in them are reserved for future allocation by the IETF.

プライマリコンポーネントに「：」（ASCII 0x3a）が含まれている場合、プライマリコンポーネントはURIです。それ以外の場合、属性はローカル属性であり、主要コンポーネントはGSS-APIの実装またはアプリケーションの特定の構成にとって意味があります。「アット」マーク（「@」）が含まれるローカル属性名は、IETFによる将来の割り当て用に予約されています。

Since attribute names are split at the first space into prefix and suffix, there is a potential for ambiguity if a mechanism blindly passes through a name attribute whose name it does not understand. In order to prevent such ambiguities, the mechanism MUST always prefix raw name attributes with a prefix that reflects the context of the attribute.

属性名は最初のスペースで接頭辞と接尾辞に分割されるため、メカニズムが名前が理解できない名前属性を盲目的に通過させると、あいまいになる可能性があります。そのようなあいまいさを防ぐために、メカニズムは常に属性のコンテキストを反映する接頭辞を生の名前属性に接頭辞付けしなければなりません。

Local attribute names under the control of an administrator or a sufficiently trusted part of the platform need not have a prefix to describe context.

管理者またはプラットフォームの十分に信頼された部分の制御下にあるローカル属性名には、コンテキストを説明する接頭辞を付ける必要はありません。

7. API

7. 火

7.1. SET OF OCTET STRING

7.1. オクテット弦のセット

The construct "SET OF OCTET STRING" occurs once in RFC 2743 [RFC2743], where it is used to represent a set of status strings in the GSS_Display_status call. The Global Grid Forum has defined SET OF OCTET STRING as a buffer set type in GFD.024 [GFD.024], which also provides one API for memory management of these structures. The normative reference to GFD.024 [GFD.024] is for the buffer set functions defined in Section 2.5 and the associated buffer set C types defined in Section 6 (namely gss_buffer_set_desc, gss_buffer_set_t, gss_create_empty_buffer_set, gss_add_buffer_set_member, gss_release_buffer_set). Nothing else from GFD.024 is required to implement this document. In particular, that document specifies changes to the behavior of existing GSS-API functions in Section 3: implementing those changes are not required to implement this document. Any implementation of SET OF OCTET STRING for use by this specification MUST preserve order.

構成「SET OF OCTET STRING」はRFC 2743 [RFC2743]で1回発生し、GSS_Display_status呼び出しでステータス文字列のセットを表すために使用されます。グローバルグリッドフォーラムは、GFD.024 [GFD.024]のバッファセットタイプとしてSET OF OCTET STRINGを定義しています。これは、これらの構造のメモリ管理に1つのAPIも提供します。 GFD.024 [GFD.024]への規範的な参照は、セクション2.5で定義されたバッファーセット関数とセクション6で定義された関連するバッファーセットCタイプ（つまり、gss_buffer_set_desc、gss_buffer_set_t、gss_create_empty_buffer_set、gss_add_buffer_set_member、gss_release_buffer_set）に対するものです。このドキュメントを実装するために、GFD.024からの他の何も必要ありません。特に、このドキュメントでは、セクション3の既存のGSS-API関数の動作の変更を指定しています。これらの変更の実装は、このドキュメントの実装には必要ありません。この仕様で使用するSET OF OCTET STRINGの実装では、順序を維持する必要があります。

7.2. Const Types

7.2. 定数タイプ

The C-bindings for the new APIs use some types from [RFC5587] to avoid issues with the use of "const". The normative reference to [RFC5587] is for the C types specified in Figure 1 of Section 3.4.6. Nothing else from that document is required to implement this document.

新しいAPIのCバインディングは、「const」の使用に関する問題を回避するために、[RFC5587]のいくつかのタイプを使用します。 [RFC5587]への規範的な参照は、セクション3.4.6の図1で指定されたCタイプ用です。このドキュメントを実装するために、そのドキュメントの他に何も必要ありません。

7.3. GSS_Display_name_ext()

Inputs:

入力：

o name INTERNAL NAME

o 名前内部名

o display_as_name_type OBJECT IDENTIFIER

Outputs:

出力：

o major_status INTEGER

o minor_status INTEGER

o display_name OCTET STRING -- caller must release with GSS_Release_buffer()

o display_name OCTET STRING-呼び出し元はGSS_Release_buffer()で解放する必要があります

Return major_status codes:

major_statusコードを返します。

o GSS_S_COMPLETE indicates no error.

o GSS_S_COMPLETEはエラーがないことを示します。

o GSS_S_UNAVAILABLE indicates that the given name could not be displayed using the syntax of the given name type.

o GSS_S_UNAVAILABLEは、指定された名前タイプの構文を使用して、指定された名前を表示できなかったことを示します。

o GSS_S_FAILURE indicates a general error.

o GSS_S_FAILUREは一般的なエラーを示します。

This function displays a given name using the given name syntax, if possible. This operation may require mapping Mechanism Names (MNs) to generic name syntaxes or generic name syntaxes to mechanism-specific name syntaxes. Such mappings may not always be feasible and MAY be inexact or lossy; therefore, this function may fail.

この関数は、可能であれば、指定された名前の構文を使用して指定された名前を表示します。この操作では、機構名（MN）を総称名構文に、または総称名構文を機構固有の名前構文にマッピングする必要がある場合があります。そのようなマッピングは常に実行可能であるとは限らず、不正確または不可逆かもしれません。したがって、この関数は失敗する可能性があります。

7.3.1. C-Bindings

7.3.1. Cバインディング

The display_name buffer is de-allocated by the caller with gss_release_buffer.

display_nameバッファーは、gss_release_bufferを使用して呼び出し元によって割り当て解除されます。

OM_uint32 gss_display_name_ext( OM_uint32 *minor_status, gss_const_name_t name, gss_const_OID display_as_name_type, gss_buffer_t display_name );

OM_uint32 gss_display_name_ext（OM_uint32 * minor_status、gss_const_name_t name、gss_const_OID display_as_name_type、gss_buffer_t display_name）;

7.4. GSS_Inquire_name()

Inputs:

入力：

o name INTERNAL NAME

o 名前内部名

Outputs:

出力：

o major_status INTEGER

o minor_status INTEGER

o name_is_MN BOOLEAN

o name_is_MNブール値

o mn_mech OBJECT IDENTIFIER

o 彼の軍隊とそばかす

o attrs SET OF OCTET STRING -- the caller is responsible for de-allocating memory using GSS_Release_buffer_set

o attrs SET OF OCTET STRING-呼び出し元はGSS_Release_buffer_setを使用してメモリの割り当てを解除します

Return major_status codes:

major_statusコードを返します。

o GSS_S_COMPLETE indicates no error.

o GSS_S_COMPLETEはエラーがないことを示します。

o GSS_S_FAILURE indicates a general error.

o GSS_S_FAILUREは一般的なエラーを示します。

This function outputs the set of attributes of a name. It also indicates if a given name is an Mechanism Name (MN) or not and, if it is, the mechanism of which it's an MN.

この関数は、名前の属性のセットを出力します。また、指定された名前がメカニズム名（MN）であるかどうかを示し、そうである場合は、それがMNであるメカニズムを示します。

7.4.1. C-Bindings

7.4.1. Cバインディング

OM_uint32 gss_inquire_name( OM_uint32 *minor_status, gss_const_name_t name, int *name_is_MN, gss_OID *MN_mech, gss_buffer_set_t *attrs );

OM_uint32 gss_inquire_name（OM_uint32 * minor_status、gss_const_name_t name、int * name_is_MN、gss_OID * MN_mech、gss_buffer_set_t * attrs）;

The gss_buffer_set_t is used here as the C representation of SET OF OCTET STRING. This type is used to represent a set of attributes and is a NULL-terminated array of gss_buffer_t. The gss_buffer_set_t type and associated API is defined in GFD.024 [GFD.024]. The "attrs" buffer set is de-allocated by the caller using gss_release_buffer_set().

gss_buffer_set_tは、SET OF OCTET STRINGのC表現としてここで使用されます。このタイプは、属性のセットを表すために使用され、gss_buffer_tのNULL終了配列です。 gss_buffer_set_tタイプおよび関連するAPIは、GFD.024 [GFD.024]で定義されています。「attrs」バッファセットは、gss_release_buffer_set()を使用して呼び出し元によって割り当て解除されます。

7.5. GSS_Get_name_attribute()

Inputs:

入力：

o name INTERNAL NAME

o 名前内部名

o attr OCTET STRING

Outputs:

出力：

o major_status INTEGER

o minor_status INTEGER

o authenticated BOOLEAN -- TRUE if and only if authenticated by the trusted peer credential source

o authentication BOOLEAN-信頼できるピアの資格情報ソースによって認証された場合にのみTRUE

o complete BOOLEAN -- TRUE if and only if this represents a complete set of values for the name

o complete BOOLEAN-これが名前の値の完全なセットを表す場合にのみTRUE

o values SET OF OCTET STRING -- the caller is responsible for de-allocating memory using GSS_Release_buffer_set

o 値SET OF OCTET STRING-呼び出し側はGSS_Release_buffer_setを使用してメモリの割り当てを解除します

o display_values SET OF OCTET STRING -- the caller is responsible for de-allocating memory using GSS_Release_buffer_set

o display_values SET OF OCTET STRING-呼び出し元は、GSS_Release_buffer_setを使用してメモリの割り当てを解除します

Return major_status codes:

major_statusコードを返します。

o GSS_S_COMPLETE indicates no error.

o GSS_S_COMPLETEはエラーがないことを示します。

o GSS_S_UNAVAILABLE indicates that the given attribute OID is not known or set.

o GSS_S_UNAVAILABLEは、指定された属性OIDが不明または設定されていないことを示します。

o GSS_S_FAILURE indicates a general error.

o GSS_S_FAILUREは一般的なエラーを示します。

This function outputs the value(s) associated with a given GSS name object for a given name attribute.

この関数は、特定の名前属性の特定のGSS名オブジェクトに関連付けられた値を出力します。

The complete flag denotes that (if TRUE) the set of values represents a complete set of values for this name. The peer being an authoritative source of information for this attribute is a sufficient condition for the complete flag to be set by the peer.

完全なフラグは、（TRUEの場合）値のセットがこの名前の値の完全なセットを表すことを示します。ピアがこの属性の信頼できる情報源であることは、ピアが完了フラグを設定するのに十分な条件です。

In the federated case, when several peers may hold some of the attributes about a name, this flag may be highly dangerous and SHOULD NOT be used.

フェデレーションの場合、複数のピアが名前に関する属性の一部を保持している場合、このフラグは非常に危険な場合があるため、使用しないでください。

NOTE: This function relies on the GSS-API notion of "SET OF" allowing for order preservation; this has been discussed on the KITTEN WG mailing list, and the consensus seems to be that, indeed, that was always the intention. It should be noted, however, that the order presented does not always reflect an underlying order of the mechanism-specific source of the attribute values.

注：この関数は、GSS-APIの「SET OF」の概念に依存しており、注文を保存できます。これはKITTEN WGメーリングリストで議論されており、コンセンサスは確かに、それは常に意図されていたようです。ただし、提示された順序は、必ずしも属性値のメカニズム固有のソースの基本的な順序を反映しているわけではないことに注意してください。

7.5.1. C-Bindings

7.5.1. Cバインディング

The C-bindings of GSS_Get_name_attribute() require one function call per attribute value for multi-valued name attributes. This is done by using a single gss_buffer_t for each value and an input/output integer parameter to distinguish initial and subsequent calls and to indicate when all values have been obtained.

GSS_Get_name_attribute()のCバインディングでは、複数値の名前属性の属性値ごとに1つの関数呼び出しが必要です。これは、各値に対して1つのgss_buffer_tを使用し、入出力の整数パラメーターを使用して、最初の呼び出しと後続の呼び出しを区別し、すべての値が取得された時期を示すことによって行われます。

The "more" input/output parameter should point to an integer variable whose value, on first call to gss_get_name_attribute(), MUST be -1 and whose value upon function call return will be non-zero to indicate that additional values remain or zero to indicate that no values remain. The caller should not modify this parameter after the initial call. The status of the complete and authenticated flags MUST NOT change between multiple calls to iterate over values for an attribute.

"more"入出力パラメーターは、gss_get_name_attribute()への最初の呼び出し時に値が-1でなければならず、追加の値が残っているか0であることを示すために関数呼び出しの戻り時にその値が非ゼロになる整数変数を指す必要があります値が残っていないことを示します。呼び出し元は、最初の呼び出し後にこのパラメーターを変更しないでください。完全および認証済みフラグのステータスは、属性の値を反復する複数の呼び出し間で変更してはなりません（MUST NOT）。

The output buffers "value" and "display_value" are de-allocated by the caller using gss_release_buffer().

出力バッファー「value」と「display_value」は、gss_release_buffer()を使用して呼び出し元によって割り当て解除されます。

OM_uint32 gss_get_name_attribute( OM_uint32 *minor_status, gss_const_name_t name, gss_const_buffer_t attr, int *authenticated, int *complete, gss_buffer_t value, gss_buffer_t display_value, int *more );

OM_uint32 gss_get_name_attribute（OM_uint32 * minor_status、gss_const_name_t name、gss_const_buffer_t attr、int * authenticated、int * complete、gss_buffer_t value、gss_buffer_t display_value、int * more）;

7.6. GSS_Set_name_attribute()

Inputs:

入力：

o name INTERNAL NAME

o 名前内部名

o complete BOOLEAN -- TRUE if and only if this represents a complete set of values for the name

o complete BOOLEAN-これが名前の値の完全なセットを表す場合にのみTRUE

o attr OCTET STRING

o values SET OF OCTET STRING

o オクテット文字列の値セット

Outputs:

出力：

o major_status INTEGER

o minor_status INTEGER

Return major_status codes:

major_statusコードを返します。

o GSS_S_COMPLETE indicates no error.

o GSS_S_COMPLETEはエラーがないことを示します。

o GSS_S_UNAVAILABLE indicates that the given attribute NAME is not known or could not be set.

o GSS_S_UNAVAILABLEは、指定された属性NAMEが不明であるか、設定できなかったことを示します。

o GSS_S_FAILURE indicates a general error.

o GSS_S_FAILUREは一般的なエラーを示します。

When the given NAME object is an MN, this function MUST fail (with GSS_S_FAILURE) if the mechanism for which the name is an MN does not recognize the attribute name or the namespace it belongs to. This is because name attributes generally have some semantics that mechanisms must understand.

指定されたNAMEオブジェクトがMNである場合、名前がMNであるメカニズムが属性名またはそれが属する名前空間を認識しない場合、この関数は（GSS_S_FAILUREで）失敗する必要があります。これは、名前属性には通常、メカニズムが理解しなければならないセマンティクスがいくつかあるためです。

On the other hand, when the given name is not an MN, this function MAY succeed even if none of the available mechanisms understand the given attribute, in which subsequent credential acquisition attempts (via GSS_Acquire_cred() or GSS_Add_cred()) with the resulting name MUST fail for mechanisms that do not understand any one or more name attributes set with this function. Applications may wish to use a non-MN, then acquire a credential with that name as the desired name. The acquired credentials will have elements only for the mechanisms that can carry the name attributes set on the name.

一方、指定された名前がMNではない場合、使用可能なメカニズムのいずれもが指定された属性を理解していなくても、この関数は成功する可能性があります。その場合、結果の名前で（GSS_Acquire_cred()またはGSS_Add_cred()を介して）資格情報の取得が試行されます。この関数で設定された1つ以上の名前属性を理解しないメカニズムでは失敗する必要があります。アプリケーションは非MNを使用したい場合があり、その名前を使用して目的の名前の資格を取得します。取得した資格情報には、名前に設定された名前属性を伝達できるメカニズムの要素のみが含まれます。

Note that this means that all name attributes are locally critical: the mechanism(s) must understand them. The reason for this is that name attributes must necessarily have some meaning that the mechanism must understand, even in the case of application-specific attributes (in which case the mechanism must know to transport the attribute to any peer). However, there is no provision to ensure that peers understand any given name attribute. Individual name attributes may be critical with respect to peers, and the specification of the attribute will have to indicate whether the mechanism's protocol or the application is expected to enforce criticality.

これは、すべての名前属性がローカルで重要であることを意味します。メカニズムはそれらを理解する必要があります。これは、アプリケーション固有の属性の場合（メカニズムが属性をピアにトランスポートすることを認識している必要がある）の場合でも、名前属性はメカニズムが理解する必要のある意味を持つ必要があるためです。ただし、ピアが特定の名前属性を確実に理解するための規定はありません。個々の名前属性はピアに関して重要である場合があり、属性の仕様は、メカニズムのプロトコルまたはアプリケーションが重要性を強制することが期待されるかどうかを示す必要があります。

完全なフラグは、（TRUEの場合）値のセットがこの名前の値の完全なセットを表すことを示します。ピアがこの属性の信頼できる情報源であることは、完全なフラグがピアによって設定されるのに十分な条件です。

In the federated case, when several peers may hold some of the attributes about a name, this flag may be highly dangerous and SHOULD NOT be used.

連合の場合、複数のピアが名前に関する属性の一部を保持している可能性がある場合、このフラグは非常に危険な場合があるため、使用しないでください。

NOTE: This function relies on the GSS-API notion of "SET OF" allowing for order preservation; this has been discussed on the KITTEN WG mailing list, and the consensus seems to be that, indeed, that was always the intention. It should be noted that underlying mechanisms may not respect the given order.

注：この関数は、GSS-APIの「SET OF」の概念に依存しており、注文を保持できます。これはKITTEN WGメーリングリストで議論されており、コンセンサスは確かに、それは常に意図されていたようです。基礎となるメカニズムは、指定された順序を尊重しない場合があることに注意してください。

7.6.1. C-Bindings

7.6.1. Cバインディング

The C-bindings of GSS_Set_name_attribute() requires one function call per attribute value for multi-valued name attributes. Each call adds one value. To replace an attribute's every value, delete the attribute's values first with GSS_Delete_name_attribute().

GSS_Set_name_attribute()のCバインディングでは、複数値の名前属性の属性値ごとに1つの関数呼び出しが必要です。呼び出しごとに1つの値が追加されます。属性のすべての値を置き換えるには、最初にGSS_Delete_name_attribute()を使用して属性の値を削除します。

OM_uint32 gss_set_name_attribute( OM_uint32 *minor_status, gss_const_name_t name, int complete, gss_const_buffer_t attr, gss_const_buffer_t value );

OM_uint32 gss_set_name_attribute（OM_uint32 * minor_status、gss_const_name_t name、int complete、gss_const_buffer_t attr、gss_const_buffer_t value）;

7.7. GSS_Delete_name_attribute()

Inputs:

入力：

o name INTERNAL NAME

o 名前内部名

o attr OCTET STRING

Outputs:

出力：

o major_status INTEGER

o minor_status INTEGER

Return major_status codes:

major_statusコードを返します。

o GSS_S_COMPLETE indicates no error.

o GSS_S_COMPLETEはエラーがないことを示します。

o GSS_S_UNAVAILABLE indicates that the given attribute NAME is not known.

o GSS_S_UNAVAILABLEは、指定された属性NAMEが不明であることを示します。

o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was attempted, such as deleting a negative attribute.

o GSS_S_UNAUTHORIZEDは、否定的な属性の削除など、禁止された削除操作が試行されたことを示します。

o GSS_S_FAILURE indicates a general error.

o GSS_S_FAILUREは一般的なエラーを示します。

Deletion of negative authenticated attributes from NAME objects MUST NOT be allowed and must result in a GSS_S_UNAUTHORIZED.

NAMEオブジェクトからの否定的な認証済み属性の削除は許可されてはならず（MUST）、GSS_S_UNAUTHORIZEDが発生する必要があります。

7.7.1. C-Bindings

7.7.1. Cバインディング

OM_uint32 gss_delete_name_attribute( OM_uint32 *minor_status, gss_const_name_t name, gss_const_buffer_t attr );

OM_uint32 gss_delete_name_attribute（OM_uint32 * minor_status、gss_const_name_t name、gss_const_buffer_t attr）;

7.8. GSS_Export_name_composite()

Inputs:

入力：

o name INTERNAL NAME

o 名前内部名

Outputs:

出力：

o major_status INTEGER

o minor_status INTEGER o exp_composite_name OCTET STRING -- the caller is responsible for de-allocating memory using GSS_Release_buffer

o minor_status INTEGER o exp_composite_name OCTET STRING-呼び出し元はGSS_Release_bufferを使用してメモリの割り当てを解除します

Return major_status codes:

major_statusコードを返します。

o GSS_S_COMPLETE indicates no error.

o GSS_S_COMPLETEはエラーがないことを示します。

o GSS_S_FAILURE indicates a general error.

o GSS_S_FAILUREは一般的なエラーを示します。

This function outputs a token that can be imported with GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type and that preserves any name attribute information (including the authenticated/complete flags) associated with the input name (which GSS_Export_name() may well not). The token format is not specified here as this facility is intended for inter-process communication only; however, all such tokens MUST start with a two-octet token ID, hex 04 02, in network byte order.

この関数は、GSS_C_NT_COMPOSITE_EXPORTを名前のタイプとして使用し、GSS_Import_name()でインポートできるトークンを出力します。このトークンは、入力名（GSS_Export_name()が適切でない可能性がある）に関連付けられた名前属性情報（認証済み/完全フラグを含む）を保持します。この機能はプロセス間通信のみを目的としているため、トークンの形式はここでは指定しません。ただし、そのようなトークンはすべて、ネットワークバイトオーダーで、2オクテットのトークンID、hex 04 02で始まる必要があります。

The OID for GSS_C_NT_COMPOSITE_EXPORT is 1.3.6.1.5.6.6.

GSS_C_NT_COMPOSITE_EXPORTのOIDは1.3.6.1.5.6.6です。

7.8.1. C-Bindings

7.8.1. Cバインディング

The "exp_composite_name" buffer is de-allocated by the caller with gss_release_buffer.

「exp_composite_name」バッファーは、gss_release_bufferを使用して呼び出し元によって割り当て解除されます。

OM_uint32 gss_export_name_composite( OM_uint32 *minor_status, gss_const_name_t name, gss_buffer_t exp_composite_name );

OM_uint32 gss_export_name_composite（OM_uint32 * minor_status、gss_const_name_t name、gss_buffer_t exp_composite_name）;

8. IANA Considerations

8. IANAに関する考慮事項

IANA has registered a new name-type OID in "SMI Security for Name System Designators Codes (nametypes)":

IANAは、「名前システム指定子コード（nametypes）のSMIセキュリティ」に新しい名前タイプOIDを登録しました。

6 gss-composite-export [RFC6680]

(The absolute OID is 1.3.6.1.5.6.6.)

（絶対OIDは1.3.6.1.5.6.6です。）

This document creates a namespace of GSS-API name attributes. Attributes are named by URIs, so no single authority is technically needed for allocation. However, future deployment experience may indicate the need for an IANA registry for URIs used to reference names specified by IETF standards. It is expected that this will be a registry of URNs, but this document provides no further guidance on this registry.

このドキュメントでは、GSS-APIの名前属性の名前空間を作成します。属性はURIで名前が付けられるため、技術的に割り当てに単一の権限は必要ありません。ただし、将来の展開経験により、IETF標準で指定された名前を参照するために使用されるURIのIANAレジストリが必要になる可能性があります。これはURNのレジストリになることが予想されますが、このドキュメントでは、このレジストリに関するこれ以上のガイダンスは提供していません。

9. Security Considerations

9. セキュリティに関する考慮事項

This document extends the GSS-API naming model to include support for name attributes. The intention is that name attributes are to be used as a basis for (among other things) authorization decisions or personalization for applications relying on GSS-API security contexts.

このドキュメントでは、GSS-API命名モデルを拡張して、名前属性のサポートを含めています。名前属性は、GSS-APIセキュリティコンテキストに依存するアプリケーションの承認決定またはパーソナライゼーション（特に）の基礎として使用されることが意図されています。

The security of the application may be critically dependent on the security of the attributes. This document classifies attributes as asserted or authenticated. Asserted (non-authenticated) attributes MUST NOT be used if the attribute has security implications for the application (e.g., authorization decisions) since asserted attributes may easily be controlled by the peer directly.

アプリケーションのセキュリティは、属性のセキュリティに大きく依存している場合があります。このドキュメントでは、属性をアサートまたは認証済みとして分類します。アサートされた属性はピアによって直接簡単に制御される可能性があるため、アサートされた（認証されていない）属性は、アプリケーションにセキュリティの影響（承認の決定など）がある場合は使用しないでください。

It is important to understand the meaning of "authenticated" in this setting. Authenticated does not imply that any semantic of the attribute is claimed to be true. The only implication is that a trusted third party has asserted the attribute as opposed to the attribute being asserted by the peer itself. Any additional semantics are always the result of applying policy. For instance, in a given deployment, the mail attribute of the subject may be authenticated and sourced from an email system where "authoritative" values are kept. In another situation, users may be allowed to modify their mail addresses freely. In both cases, the "mail" attribute may be authenticated by virtue of being included in signed SAML attribute assertions or by other means authenticated by the underlying mechanism.

この設定では、「認証済み」の意味を理解することが重要です。 Authenticatedは、属性のセマンティクスが真であると主張されていることを意味しません。唯一の含意は、ピア自体によってアサートされている属性とは対照的に、信頼できるサードパーティが属性をアサートしていることです。追加のセマンティクスは、常にポリシーを適用した結果です。たとえば、特定の展開では、件名のメール属性が認証され、「信頼できる」値が保持されている電子メールシステムから送信されます。別の状況では、ユーザーは自分のメールアドレスを自由に変更できる場合があります。どちらの場合も、「メール」属性は、署名されたSAML属性アサーションに含まれているため、または基礎となるメカニズムによって認証される他の方法によって認証されます。

When the underlying security mechanism does not provide a permanent unique identity (e.g., anonymous Kerberos), GSS-API naming extensions may be used to provide a permanent unique identity attribute. This may be a globally unique identifier, a value unique within the namespace of the attribute issuer, or a "directed" identifier that is unique per peer acceptor identity. SAML, to use one example technology, offers a number of built-in constructs for this purpose, such as a <NameID> with a Format of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent". SAML deployments also typically make use of domain-specific attribute types that can serve as identifiers.

基盤となるセキュリティメカニズムが永続的な一意のID（匿名のKerberosなど）を提供しない場合、GSS-APIネーミング拡張を使用して永続的な一意のID属性を提供できます。これは、グローバルに一意の識別子、属性発行者の名前空間内で一意の値、またはピアのアクセプターIDごとに一意の「指定された」識別子の場合があります。 SAMLは、1つのサンプルテクノロジーを使用するために、この目的のために、フォーマットが "urn：oasis：names：tc：SAML：2.0：nameid-format：persistent"の<NameID>など、多くの組み込み構造を提供しています。 SAMLデプロイメントでは、通常、識別子として機能するドメイン固有の属性タイプも利用します。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[GFD.024] Meder, S., Welch, V., Tuecke, S., and D. Engert, "GSS-API Extensions", Global Grid Forum GFD.024, June 2004, <http://www.ggf.org/documents/GFD.24.pdf>.

[GFD.024] Meder、S.、Welch、V.、Tuecke、S。、およびD. Engert、「GSS-API Extensions」、グローバルグリッドフォーラムGFD.024、2004年6月、<http：//www.ggf .org / documents / GFD.24.pdf>。

[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月。

[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.

[RFC2744] Wray、J。、「Generic Security Service API Version 2：C-bindings」、RFC 2744、2000年1月。

[RFC5587] Williams, N., "Extended Generic Security Service Mechanism Inquiry APIs", RFC 5587, July 2009.

[RFC5587]ウィリアムズ、N。、「拡張Generic Security Serviceメカニズム照会API」、RFC 5587、2009年7月。

10.2. Informative References

10.2. 参考引用

[ANSI.X3-4.1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.

[ANSI.X3-4.1986] American National Standards Institute、「Coded Character Set-7-bit American Standard Code for Information Interchange」、ANSI X3.4、1986。

[OASIS.saml-core-2.0-os] 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.saml-core-2.0-os] Cantor、S.、Kemp、J.、Philpott、R.、and E. Maler、 "Assertions and Protocol for the OASIS Security Assertion Markup Language（SAML）V2.0"、 OASIS標準saml-core-2.0-os、2005年3月。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.

[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。

[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.

[RFC4556] Zhu、L。およびB. Tung、「Kerberosでの初期認証のための公開鍵暗号化（PKINIT）」、RFC 4556、2006年6月。

[RFC4768] Hartman, S., "Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming", RFC 4768, December 2006.

[RFC4768] Hartman、S。、「Generic Security Services Application Program Interface（GSS-API）Version 3 Namingへの望ましい拡張機能」、RFC 4768、2006年12月。

Authors' Addresses

著者のアドレス

Nicolas Williams Cryptonector, LLC

ニコラスウィリアムズクリプトネクター、LLC

   EMail: nico@cryptonector.com

Leif Johansson Swedish University Network Thulegatan 11 Stockholm Sweden

Leif Johansson Swedish University Network Thulegatan 11ストックホルムスウェーデン

   EMail: leifj@sunet.se
   URI:   http://www.sunet.se

Sam Hartman Painless Security

サムハートマンの痛みのないセキュリティ

   EMail: hartmans-ietf@mit.edu

Simon Josefsson SJD AB Johan Olof Wallins Vaeg 13 171 64 Solna Sweden

Simon Josefsson SJD AB Johan Olof Wallins Vaeg 13171 64 Solnaスウェーデン

   EMail: simon@josefsson.org
   URI:   http://josefsson.org/