[要約] RFC 4768は、GSS-APIバージョン3の名前付けに関する改善を提案している。 目的は、GSS-APIの名前付け機能を拡張し、セキュリティサービスのアプリケーションプログラムインターフェースの利便性を向上させることである。
Network Working Group S. Hartman
Request for Comments: 4768 MIT
Category: Informational December 2006
Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming
ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）バージョン3ネーミングへの望ましい拡張機能
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion.
Generic Security Services API（GSS-API）は、名前ベースの承認をサポートする命名アーキテクチャを提供します。GSS-APIは、2つの指名されたパーティーを互いに認証します。名前をアクセス制御リスト（ACL）に保存して、許可決定を下すことができます。セキュリティメカニズムの進歩と、実装者がGSS-APIの使用を希望する方法では、このモデルをGSS-APIの次のバージョンに拡張する必要があります。人々が組織内で移動したり、名前を変更したりすると、GSS-APIによって認証された名前が変更される可能性があります。何らかの一定の識別子を使用すると、ACLSがより安定します。パブリックキーメカニズムなどのいくつかのメカニズムには、すべての環境で使用される単一の名前がありません。Kerberosなどの他のメカニズムには、認証の一部としてグループメンバーシップまたはロール情報が含まれる場合があります。このドキュメントは、GSS-APIネーミングの拡張機能を動機付け、議論中の拡張機能について説明します。
Table of Contents
目次
1. Introduction ....................................................2
2. Kerberos Naming .................................................3
3. X.509 Names .....................................................4
4. Composite Names .................................................5
4.1. Usage of Name Attributes ...................................6
4.2. Open Issues ................................................6
4.3. Handling gss_export_name ...................................7
5. Credential Extensions ...........................................7
6. Mechanisms for Export Name ......................................8
7. Selection of Source Identity ....................................8
8. Compatibility with GSS-API V2 ...................................9
9. Security Considerations .........................................9
10. Acknowledgements ..............................................10
11. Informative References ........................................10
The Generic Security Services API [2] authenticates two named parties to each other. GSS names can be imported in a variety of formats through the gss_import_name call. Several mechanism-independent name formats are provided, including GSS_C_NT_HOSTBASED_SERVICE for services running on an Internet host, and GSS_C_NT_USER_NAME for the names of users. Other mechanism-specific name types are also provided. By the time a name is used in acquiring a mechanism-specific credential or establishing a security context, it has been transformed into one of these mechanism-specific name types. In addition, the GSS-API provides a function called gss_export_name that will transform a GSS-API name into a binary blob suitable for comparisons. This binary blob can be stored on ACLs and then authorization decisions can be made simply by comparing the name exported from a newly accepted context to the name on the ACL.
ジェネリックセキュリティサービスAPI [2]は、2つの指定されたパーティーを互いに認証します。GSS名は、gss_import_nameコールを通じてさまざまな形式でインポートできます。インターネットホストで実行されているサービスのgss_c_nt_hostbased_serviceや、ユーザーの名前のgss_c_nt_user_nameなど、いくつかのメカニズムに依存しない名前形式が提供されています。他のメカニズム固有の名前のタイプも提供されます。メカニズム固有の資格情報の取得またはセキュリティコンテキストの確立に名前が使用されるまでに、これらのメカニズム固有の名前タイプの1つに変換されました。さらに、GSS-APIは、GSS-API名を比較に適したバイナリBLOBに変換するGSS_EXPORT_NAMEと呼ばれる関数を提供します。このバイナリBLOBはACLSに保存でき、その後、認可されたコンテキストからエクスポートされた名前をACLの名前と比較するだけで、許可決定を行うことができます。
Storing names on ACLs can be problematic because names tend to change over time. If the name contains organizational information, such as a domain part or an indication of what department someone works for, this changes as the person moves around the organization. Even if no organizational information is included in the name, the name will change as people change their names. Updating ACLs to reflect name changes is difficult. Another significant problem is that names can be reused to apply to an entity other than the entity to which they originally applied. For example, if a Unix user ID is placed on an ACL, the account deleted and then a new user assigned the old ID, then that new user may gain privileges intended for the old user.
ACLに名前を保存するには、名前が時間とともに変化する傾向があるため、問題が発生する可能性があります。名前に、ドメインのパーツや誰かがどの部門で働いているかを示すなどの組織情報が含まれている場合、これは、その人が組織の周りに移動するにつれて変わります。名前に組織情報が含まれていなくても、人々が名前を変更するにつれて名前が変更されます。名前の変更を反映するようにACLを更新することは困難です。別の重要な問題は、名前を再利用して、元々適用されたエンティティ以外のエンティティに適用できることです。たとえば、UNIXユーザーIDがACLに配置され、アカウントが削除され、新しいユーザーが古いIDを割り当てた場合、新しいユーザーが古いユーザー向けの特権を取得する場合があります。
Inherent in the GSS naming model is the idea that mechanism names need to be able to be represented in a single canonical form. Anyone importing that name needs to be able to retrieve the canonical form of that name.
GSSネーミングモデルに固有のものは、メカニズム名を単一の標準形式で表現できる必要があるという考えです。その名前をインポートしている人は誰でも、その名前の正規の形を取得できる必要があります。
Several security mechanisms have been proposed for which this naming architecture is too restrictive. In some cases, it is not always possible to canonicalize any name that is imported. In other cases, there is no single canonical name.
この命名アーキテクチャが制限が強すぎるため、いくつかのセキュリティメカニズムが提案されています。場合によっては、インポートされている名前を正規化することが常に可能ではありません。他の場合には、単一の正規の名前はありません。
Also, as GSS-API is used in more complex environments, there is a desire to use attribute certificates [6], Kerberos authorization data [3], or other non-name-based authorization models. GSS-API needs to be enhanced in order to support these uses in a mechanism-independent manner.
また、GSS-APIはより複雑な環境で使用されているため、属性証明書[6]、Kerberos Authorizationデータ[3]、またはその他の非名前に基づく認証モデルを使用したいという願望があります。これらの使用をメカニズムに依存しない方法でサポートするには、GSS-APIを強化する必要があります。
This document discusses the particular naming problems with two important classes of GSS-API mechanisms. It also discusses the set of proposed solutions and their associated open issues. This document limits discussion to these solutions and provides a description of the problem against which the solutions can be judged. These solutions are targeted for incorporation into GSS-API Version 3.
このドキュメントでは、GSS-APIメカニズムの2つの重要なクラスで特定の命名問題について説明します。また、提案されたソリューションのセットとそれに関連するオープンな問題についても説明します。このドキュメントは、これらのソリューションへの議論を制限し、ソリューションを審査できる問題の説明を提供します。これらのソリューションは、GSS-APIバージョン3への組み込みを対象としています。
The Kerberos mechanism demonstrates both the naming stability problem and the authorization extension problem.
Kerberosメカニズムは、命名安定性の問題と承認拡張の問題の両方を示しています。
The Kerberos Referrals document [4] proposes a new type of Kerberos name called an enterprise name. The intent is that the enterprise name is an alias that the user knows for themselves and can use to log in. The Kerberos Key Distribution Center (KDC) translates this name into a normal Kerberos principal and gives the user tickets for this principal. This normal principal is used for authorization. The intent is that the enterprise name tracks the user as they moves throughout the organization, even if they move to parts of the organization that have different naming policies. The name they type at login remains constant, but the Kerberos principal used to authenticate them to services changes.
Kerberos紹介文書[4]は、エンタープライズ名と呼ばれる新しいタイプのKerberos名を提案しています。意図は、エンタープライズ名がユーザーが自分で知っているエイリアスであり、ログインに使用できるエイリアスです。Kerberosキーディストリビューションセンター（KDC）は、この名前を通常のKerberosプリンシパルに変換し、このプリンシパルのユーザーチケットを提供します。この通常のプリンシパルは許可に使用されます。意図は、エンタープライズ名が、異なる命名ポリシーを持つ組織の一部に移動したとしても、組織全体に移動する際にユーザーを追跡することです。ログイン時に入力する名前は一定のままですが、Kerberosの校長はサービスの変更に認証するために使用されていました。
Unauthenticated services cannot generally perform a mapping from enterprise name to principal name. Even authenticated services may not be authorized to map names other than the name of the authenticated service. Also, Kerberos does not (and does not plan to) provide a mechanism for mapping enterprise names to principals besides authentication as the enterprise name. Thus, any such mapping would be vendor-specific. With this feature in Kerberos, it is not possible to implement gss_canonicalize_name for enterprise name types. Of course, other name types such as traditional principal names could be used for GSS-API applications. Naturally, this loses the benefits of enterprise names.
認可されていないサービスは、通常、エンタープライズ名からプリンシパル名へのマッピングを実行することはできません。認証されたサービスでさえ、認証されたサービスの名前以外の名前をマッピングすることを許可されていない場合があります。また、Kerberosは、エンタープライズ名として認証以外に、エンタープライズ名をプリンシパルにマッピングするメカニズムを提供していません（および計画していません）。したがって、そのようなマッピングはベンダー固有のものになります。Kerberosのこの機能を使用すると、エンタープライズ名タイプにGSS_Canonicalize_Nameを実装することはできません。もちろん、従来の主要な名前などの他の名前は、GSS-APIアプリケーションに使用できます。当然、これはエンタープライズ名の利点を失います。
Another issue arises with enterprise names. In some cases, it would be desirable to put the enterprise name on the ACL instead of a principal name for greater ACL stability. At first glance, this could be accomplished by including the enterprise name in the name exported by gss_export_name. Unfortunately, if this were done, the exported name would change whenever the mapping changed, invalidating any ACL entries based off the old exported name and defeating the purpose of including the enterprise name in the exported name. In some cases, it would be desirable to have the exported name be based on the enterprise name and, in others, based on the principal name, but this is not permitted by the current GSS-API.
エンタープライズ名で別の問題が発生します。場合によっては、ACLの安定性を高めるために主名ではなく、ACLにエンタープライズ名を配置することが望ましいでしょう。一見すると、これはgss_export_nameによってエクスポートされた名前にエンタープライズ名を含めることで実現できます。残念ながら、これが行われた場合、マッピングが変更されるたびにエクスポートされた名前が変更され、古いエクスポート名に基づいてACLエントリを無効にし、エンタープライズ名をエクスポート名に含める目的を打ち負かします。場合によっては、エクスポートされた名前をエンタープライズ名に基づいており、他の名前では主名に基づいていることが望ましい場合がありますが、これは現在のGSS-APIでは許可されていません。
Another development also complicates GSS-API naming for Kerberos. Several vendors have been looking at mechanisms to include group membership information in Kerberos authorization data. It is desirable to put these group names on ACLs. Again, GSS-API currently has no mechanism to use this information.
別の開発は、KerberosのGSS-API命名も複雑にしています。いくつかのベンダーは、Kerberos認証データにグループメンバーシップ情報を含めるメカニズムを検討しています。これらのグループ名をACLに配置することが望ましいです。繰り返しますが、GSS-APIには現在、この情報を使用するメカニズムがありません。
X.509 names are more complicated than Kerberos names. In the Kerberos case, there is a single principal carried in all Kerberos messages. X.509 certificates have multiple options. It seems the subject name might be the appropriate name to use as the name to be exported in a GSS-API mechanism. However, RFC 3280 [5] allows the subject name to be an empty sequence in end-entity certificates. Therefore, the subjectAltName extension might be the only portion of the certificate that identifies the subject. As in the case of Kerberos group memberships, there may be many subjectAltName extensions available in a certificate. Different applications will care about different name forms. One possible candidate for an exported name would be all the names from the subject field, and the subjectAltName extension from a certificate. However, as new names are added, existing ACL entries would be invalidated; this is undesirable. Thus, there is no single value that can be defined as the exported GSS-API name that will be useful in all environments.
X.509名はKerberosの名前よりも複雑です。Kerberosの場合、すべてのKerberosメッセージに1つの校長が運ばれています。X.509証明書には複数のオプションがあります。主題名は、GSS-APIメカニズムでエクスポートされる名前として使用するのに適切な名前であるようです。ただし、RFC 3280 [5]により、サブジェクト名はエンドエンティティ証明書の空のシーケンスにすることができます。したがって、件名を識別する証明書の唯一の部分である可能性があります。Kerberos Groupメンバーシップの場合のように、証明書には多くのsubjectaltname拡張機能があるかもしれません。さまざまなアプリケーションは、異なる名前フォームに関心があります。エクスポートされた名前の候補の1つは、被験者フィールドからのすべての名前と、証明書からのsubjectaltname拡張機能です。ただし、新しい名前が追加されると、既存のACLエントリは無効になります。これは望ましくありません。したがって、すべての環境で役立つエクスポートされたGSS-API名として定義できる単一の値はありません。
A profile of a particular X.509 GSS-API mechanism could require that a specific name be used. However, this would limit that mechanism to require a particular type of certificate. There is interest in being able to use arbitrary X.509 certificates with GSS-API for some applications.
特定のX.509 GSS-APIメカニズムのプロファイルでは、特定の名前を使用する必要があります。ただし、これにより、特定のタイプの証明書を必要とするメカニズムが制限されます。一部のアプリケーションでは、GSS-APIを使用して任意のX.509証明書を使用できることに関心があります。
Experience so far has not led to sufficient interoperability with GSS-API X.509 mechanisms. Even if the subject name is used, there is ambiguity in how to handle sorting of name components. Martin Rex said that he was aware of several SPKM [1] implementations, but that no two were fully interoperable on names.
これまでの経験は、GSS-API X.509メカニズムとの十分な相互運用性につながっていません。サブジェクト名が使用されていても、名前コンポーネントのソートを処理する方法には曖昧さがあります。Martin Rexは、いくつかのSPKM [1]の実装を知っているが、名前に完全に相互運用可能な2つの実装はないと述べた。
Also, as discussed in the introduction, it is desirable to support X.509 attribute certificates.
また、紹介で説明したように、X.509属性証明書をサポートすることが望ましいです。
One proposal to solve these problems is to extend the concept of a GSS-API name to include a set of name attributes. Each attribute would be an octet-string labeled by an OID. Examples of attributes would include Kerberos enterprise names, group memberships in an authorization infrastructure, and Kerberos authorization data attributes and subjectAltName attributes in a certificate. Several new operations would be needed:
これらの問題を解決するための提案の1つは、GSS-API名の概念を拡張して、一連の名前属性を含めることです。各属性は、oidによってラベル付けされたオクテット弦です。属性の例には、Kerberos Enterprise名、承認インフラストラクチャのグループメンバーシップ、および証明書のKerberos認証データ属性およびSubjectAltName属性が含まれます。いくつかの新しい操作が必要です：
1. Add an attribute to name.
1. 名前に属性を追加します。
2. Query attributes of name.
2. 名前のクエリ属性。
3. Query values of an attribute.
3. 属性のクエリ値。
4. Delete an attribute from a name.
4. 名前から属性を削除します。
5. Export a complete composite name and all its attributes for transport between processes.
5. 完全な複合名とプロセス間の輸送のすべての属性をエクスポートします。
Note that an exported composite name would not generally be suitable for binary comparison. Avoiding confusion between this operation and the existing gss_export_name operation will require careful work. However, many attributes of composite names will be appropriate for binary comparisons. Such attributes can be used on ACLs, just as exported names are used on ACLs today. For example, if a particular SubjectAltName extension contains the appropriate identity for an application, then the name attribute for this SubjectAltName can be placed on the ACL. This is only true if the name attribute is stored in some canonical form.
エクスポートされた複合名は、一般にバイナリ比較には適していないことに注意してください。この操作と既存のGSS_EXPORT_NAME操作との間の混乱を回避するには、慎重な作業が必要です。ただし、複合名の多くの属性は、バイナリ比較に適しています。このような属性は、今日のACLSでエクスポートされた名前が使用されているように、ACLSで使用できます。たとえば、特定のsubjectaltname拡張機能にアプリケーションの適切なIDが含まれている場合、このsumberaltnameの名前属性をACLに配置できます。これは、名前属性が標準形式に保存されている場合にのみ当てはまります。
Additional utility operations will probably be needed depending on the implementation of name attributes.
名前属性の実装に応じて、おそらく追加のユーティリティ操作が必要になるでしょう。
Since attributes are part of GSS-API names, the acceptor can retrieve the attributes of the initiator's and acceptor's name from the context. These attributes can then be used for authorization.
属性はGSS-API名の一部であるため、アクセプターはコンテキストからイニシエーターとアクセプターの名前の属性を取得できます。これらの属性は、許可に使用できます。
Most name attributes will probably not come from explicit operations to add attributes to a name. Instead, name attributes will probably come from mechanism-specific credentials. Components of these mechanism-specific credentials may come from platform or environment-specific names. Mechanism-specific naming and group membership can be mapped into name attributes by the mechanism implementation. The specific form of this mapping will generally require protocol specification for each mechanism.
ほとんどの名前の属性は、おそらく名前に属性を追加する明示的な操作からは得られないでしょう。代わりに、名前の属性はおそらくメカニズム固有の資格情報から得られます。これらのメカニズム固有の資格情報のコンポーネントは、プラットフォームまたは環境固有の名前から得られる場合があります。メカニズム固有のネーミングとグループメンバーシップは、メカニズムの実装によって名前属性にマッピングできます。このマッピングの特定の形式では、通常、各メカニズムのプロトコル仕様が必要です。
This section describes parts of the proposal to add attributes to names that will need to be explored before the proposal can become a protocol specification.
このセクションでは、提案がプロトコル仕様になる前に調査する必要がある名前に属性を追加する提案の一部について説明します。
Are mechanisms expected to be able to carry arbitrary name attributes as part of a context establishment? At first, it seems like this would be desirable. However, the purpose of GSS-API is to establish an authenticated context between two peers. In particular, a context authenticates two named entities to each other. The names of these entities and attributes associated with these names will be used for authorization decisions. If an initiator or acceptor is allowed to assert name attributes, and the authenticity of these assertions is not validated by the mechanisms, then security problems will result. On the other hand, requiring that name attributes be mechanism-specific and only be carried by mechanisms that understand the name attributes and can validate them compromises GSS-API's place as a generic API. Application authors would be forced to understand mechanism-specific attributes to make authorization decisions. In addition, if mechanisms are not required to transport arbitrary attributes, then application authors will need to deal with different implementations of the same mechanism that support different sets of name attributes. One possible solution is to carry a source along with each name attribute; this source could indicate whether the attribute comes from a mechanism data structure or from the other party in the authentication.
メカニズムは、コンテキスト確立の一部として任意の名前属性を運ぶことができると予想されていますか？最初は、これが望ましいようです。ただし、GSS-APIの目的は、2人のピア間で認証されたコンテキストを確立することです。特に、コンテキストは2つの名前のエンティティを互いに認証します。これらのエンティティの名前とこれらの名前に関連付けられた属性は、許可決定に使用されます。イニシエーターまたはアクセプターが名前の属性を主張することが許可され、これらのアサーションの信頼性がメカニズムによって検証されない場合、セキュリティの問題が発生します。一方、名前属性はメカニズム固有であり、名前属性を理解し、GSS-APIの妥協を一般的なAPIとして妥協するメカニズムによってのみ運ばれることを要求します。アプリケーション著者は、許可決定を下すためにメカニズム固有の属性を理解することを余儀なくされます。さらに、任意の属性を輸送するためにメカニズムが必要ない場合、アプリケーション著者は、異なる名前の属性をサポートする同じメカニズムの異なる実装を処理する必要があります。考えられる解決策の1つは、各名前属性とともにソースを運ぶことです。このソースは、属性がメカニズムデータ構造から来ているのか、認証における相手の関係者から来るのかを示すことができます。
Another related question is how name attributes will be mapped into their mechanism-specific forms. For example, it would be desirable to map many Kerberos authorization data elements into name attributes. In the case of the Microsoft PAC (privilege attribute certificate), it would be desirable for some applications to get the entire PAC. However, in many cases, the specific lists of security IDs contained in the PAC would be more directly useful to an application. So there may not be a good one-to-one mapping between the mechanism-specific elements and the representation desirable at the GSS-API layer.
別の関連する質問は、名前属性がメカニズム固有の形式にマッピングされる方法です。たとえば、多くのKerberos認証データ要素を名前属性にマッピングすることが望ましいでしょう。Microsoft PAC（特権属性証明書）の場合、一部のアプリケーションがPAC全体を取得することが望ましいでしょう。ただし、多くの場合、PACに含まれるセキュリティIDの特定のリストは、アプリケーションにとってより直接的に役立ちます。したがって、メカニズム固有の要素とGSS-API層で望ましい表現の間には、1対1のマッピングがない場合があります。
Specific name matching rules need to be developed. How do names with attributes compare? What is the effect of a name attribute on a target name in gss_accept_sec_context?
特定の名前マッチングルールを開発する必要があります。属性のある名前はどのように比較されますか？gss_accept_sec_contextのターゲット名に対する名前属性の効果は何ですか？
For many mechanisms, there will be an obvious choice to use for the name exported by gss_export_name. For example, in the case of Kerberos, the principal name can continue to be used as the exported name. This will allow applications that depend on existing GSS-API name-based authorization to continue to work. However, it is probably desirable to allow GSS-API mechanisms for which gss_export_name cannot meaningfully be defined. In such cases, the behavior of gss_export_name should probably be to return some error. Such mechanisms may not work with existing applications and cannot conform to the current version of the GSS-API.
多くのメカニズムでは、GSS_EXPORT_NAMEによってエクスポートされる名前に使用することは明らかです。たとえば、Kerberosの場合、主名はエクスポートされた名前として引き続き使用できます。これにより、既存のGSS-APIネームベースの承認に依存するアプリケーションが機能し続けることができます。ただし、GSS_EXPORT_NAMEを意味に定義できないGSS-APIメカニズムを許可することがおそらく望ましいです。そのような場合、GSS_EXPORT_NAMEの動作は、おそらく何らかのエラーを返すことでなければなりません。このようなメカニズムは、既存のアプリケーションでは機能せず、GSS-APIの現在のバージョンに準拠することはできません。
An alternative to the name attributes proposal is to extend GSS-API credentials with extensions labeled by OIDs. Interfaces would be needed to manipulate these credential extensions and to retrieve the credential extensions for credentials used to establish a context. Even if name attributes are used, credential extensions may be useful for other unrelated purposes.
名前属性の提案に代わるものは、GSS-API資格情報をOIDSによってラベル付けされた拡張機能を拡張することです。これらの資格情報拡張機能を操作し、コンテキストを確立するために使用される資格情報の資格情報拡張機能を取得するには、インターフェイスが必要です。名前属性が使用されていても、資格情報拡張機能は他の無関係な目的に役立つ場合があります。
It is possible to solve problems discussed in this document using some credential extension mechanism. Doing so will have many of the same open issues as discussed in the composite names proposal. The main advantage of a credential extensions proposal is that it avoids specifying how name attributes interact with name comparison or target names.
いくつかの資格情報拡張メカニズムを使用して、このドキュメントで議論された問題を解決することが可能です。そうすることで、複合名の提案で議論されているのと同じオープンな問題がたくさんあります。資格情報拡張提案の主な利点は、名前属性が名前の比較またはターゲット名と対話する方法を指定しないことです。
The primary advantage of the name attributes proposal over credential extensions is that name attributes seem to fit better into the GSS-API authorization model. Names are already available at all points when authorization decisions are made. In addition, for many mechanisms, the sort of information carried as name attributes will also be carried as part of the name in the mechanism.
名前属性の提案の主な利点は、資格情報拡張に対する提案の提案です。名前属性はGSS-API認証モデルにより適しているように見えることです。許可決定が行われると、すべての時点で名前が既に利用可能です。さらに、多くのメカニズムでは、名前の属性として伝達される種類の情報も、メカニズムの名前の一部として運ばれます。
Another proposal is to define some GSS-API mechanisms whose only purpose is to have an exportable name form that is useful. For example, you might be able to export a name as a local machine user ID with such a mechanism.
別の提案は、有用なエクスポート可能な名前フォームを持つことの唯一の目的であるGSS-APIメカニズムを定義することです。たとえば、このようなメカニズムを使用してローカルマシンユーザーIDとして名前をエクスポートできる場合があります。
This solution works well for name information that can be looked up in a directory. It was unclear whether this solution would allow mechanism-specific name information to be extracted from a context. If so, then this solution would meet many of the goals of this document.
このソリューションは、ディレクトリで調べることができる名前情報に適しています。このソリューションがメカニズム固有の名前情報をコンテキストから抽出できるかどうかは不明でした。もしそうなら、このソリューションはこのドキュメントの多くの目標を満たします。
One advantage of this solution is that it requires few, if any, changes to GSS-API semantics. It is not as flexible as other solutions. Also, it is not clear how to handle mechanisms that do not have a well-defined name to export with this solution.
このソリューションの利点の1つは、GSS-APIセマンティクスに変更が必要な場合はほとんど必要ありません。他のソリューションほど柔軟ではありません。また、このソリューションでエクスポートするために明確に定義された名前を持たないメカニズムを処理する方法は明確ではありません。
Today, applications such as e-mail clients and Web browsers require connections to multiple targets. For each target, there may be one or more source identities that is appropriate for the connection. Currently each application must choose the source name to use when acquiring credentials or initiating a security context. However, the rules that applications use can be generalized to a large extent. GSS-API could simplify application design and implementation by taking a larger role in selection of source identity to use when connecting to a particular target.
今日、電子メールクライアントやWebブラウザーなどのアプリケーションには、複数のターゲットへの接続が必要です。各ターゲットについて、接続に適した1つ以上のソースアイデンティティがある場合があります。現在、各アプリケーションは、資格情報を取得したり、セキュリティコンテキストを開始するときに使用するソース名を選択する必要があります。ただし、アプリケーションが使用するルールは、大部分が一般化できます。GSS-APIは、特定のターゲットに接続するときに使用するソースIDの選択においてより大きな役割を果たすことにより、アプリケーションの設計と実装を簡素化できます。
Currently, GSS-API credentials represent a single mechanism name. That is, by the time credentials are acquired, they must act as if a particular single identity is chosen for each mechanism in the credential. All these identities must correspond to a single mechanism independent name.
現在、GSS-API資格情報は単一のメカニズム名を表しています。つまり、資格情報が取得されるまでに、資格情報の各メカニズムに対して特定の単一のアイデンティティが選択されるかのように行動する必要があります。これらのすべてのアイデンティティは、単一のメカニズム独立名に対応する必要があります。
Two possibilities have been proposed for involving GSS-API in the selection of source identities. First, the restriction that a mechanism name must be chosen when credentials are acquired could be relaxed. Some name form would need to be used, but this name form could represent a set of possibilities. The particular identity would be chosen when context establishment happened. This could involve information received from the target in identity selection.
ソースIDの選択にGSS-APIを含む2つの可能性が提案されています。まず、資格情報が取得されたときにメカニズム名を選択する必要があるという制限を緩和することができます。いくつかの名前フォームを使用する必要がありますが、この名前フォームは一連の可能性を表すことができます。コンテキストの確立が起こったときに、特定のアイデンティティが選択されます。これには、アイデンティティの選択においてターゲットから受け取った情報が含まれる場合があります。
Another possibility is to provide a mechanism to acquire credentials and to provide information about the target when credentials are acquired. This would be much less of a change to GSS-API, but would not allow information received from the target to choose identity selection.
別の可能性は、資格情報を取得するメカニズムを提供し、資格情報が取得されたときにターゲットに関する情報を提供することです。これはGSS-APIへの変更はそれほど少ないでしょうが、ターゲットから受け取った情報がID選択を選択することは許可されません。
With both approaches, information to communicate the needs of the application to the GSS-API mechanism will be required. For example, hinting about whether information can be cached and about the scope of cache entries is required.
両方のアプローチでは、アプリケーションのニーズをGSS-APIメカニズムに伝える情報が必要です。たとえば、情報をキャッシュできるかどうか、およびキャッシュエントリの範囲を示唆する必要があります。
Another possibility can be implemented in GSS-API V2 today: Do not bind the credentials to a mechanism name until either the credentials are queried or they are used to set up a context. This is undesirable because if an application uses the credential inquiry interface, then it will get different behavior than cases where this interface is not used. For this reason, the working group favors an extension to GSS-API V3.
別の可能性は、今日のGSS-API V2で実装できます。資格情報が照会されるか、コンテキストのセットアップに使用されるまで、資格情報をメカニズム名にバインドしないでください。アプリケーションが資格情報インターフェイスを使用する場合、このインターフェイスが使用されない場合とは異なる動作が得られるため、これは望ましくありません。このため、ワーキンググループはGSS-API V3の拡張機能を支持しています。
In order to avoid breaking existing applications or mechanisms, the following backward compatibility requirements need to be met:
既存のアプリケーションやメカニズムを壊すことを避けるために、次の後方互換性要件を満たす必要があります。
1. Existing APIs must continue to behave as they do in GSS-API V2.
1. 既存のAPIは、GSS-API V2のように動作し続ける必要があります。
2. GSS-API V2 mechanisms must produce the same exported name forms; composite names cannot change the existing exported name forms.
2. GSS-API V2メカニズムは、同じエクスポートされた名前フォームを生成する必要があります。複合名は、既存のエクスポートされた名前フォームを変更できません。
3. Extensions add new optional behavior.
3. 拡張機能新しいオプションの動作が追加されます。
If GSS-API V3 mechanisms are more permissive than GSS-API V2 mechanisms, then care must be taken so that GSS-API V2 applications do not select these mechanisms.
GSS-API V3メカニズムがGSS-API V2メカニズムよりも許容度が高い場合、GSS-API V2アプリケーションがこれらのメカニズムを選択しないように注意する必要があります。
GSS-API sets up a security context between two named parties. The GSS-API names are security assertions that are authenticated by the context establishment process. As such, the GSS naming architecture is critical to the security of GSS-API.
GSS-APIは、2つの指定されたパーティー間でセキュリティコンテキストを設定します。GSS-API名は、コンテキスト確立プロセスによって認証されるセキュリティアサーションです。そのため、GSSアーキテクチャの命名は、GSS-APIのセキュリティにとって重要です。
Currently, GSS-API uses a simplistic naming model for authorization. Names can be compared against a set of names on an access control list. This architecture is relatively simple, and its security properties are well understood. However, it does not provide the flexibility and feature set for future deployments of GSS-API.
現在、GSS-APIは、承認のために単純な命名モデルを使用しています。名前は、アクセス制御リストの一連の名前と比較できます。このアーキテクチャは比較的単純であり、そのセキュリティプロパティはよく理解されています。ただし、GSS-APIの将来の展開に柔軟性と機能セットを提供しません。
This proposal will significantly increase the complexity of the GSS naming architecture. As this proposal is fleshed out, we need to consider ways of managing security exposures created by this increased complexity.
この提案は、GSSネーミングアーキテクチャの複雑さを大幅に増加させます。この提案は具体化されているため、この複雑さの増加によって生み出されたセキュリティエクスポージャーを管理する方法を検討する必要があります。
One area where the complexity may lead to security problems is composite names with attributes from different sources. This may be desirable so that name attributes can carry their own authentication. However, the design of any solutions needs to make sure that applications can assign appropriate trust to name components.
複雑さがセキュリティの問題につながる可能性のある領域の1つは、さまざまなソースからの属性を持つ複合名です。これは、名前属性が独自の認証を運ぶことができるように望ましい場合があります。ただし、ソリューションの設計では、アプリケーションがコンポーネントに名前を付けるために適切な信頼を割り当てることができることを確認する必要があります。
John Brezak, Paul Leach, and Nicolas Williams all participated in discussions that led to a desire to enhance GSS naming. Martin Rex provided descriptions of the current naming architecture and pointed out many ways in which proposed enhancements would create interoperability problems or increase complexity. Martin also provided excellent information on what aspects of GSS naming have tended to be implemented badly or have not met the needs of some customers.
ジョン・ブレザック、ポール・リーチ、ニコラス・ウィリアムズはすべて、GSSの命名を強化したいという欲求につながった議論に参加しました。Martin Rexは、現在の命名アーキテクチャの説明を提供し、提案された機能強化が相互運用性の問題を引き起こすか、複雑さを高める多くの方法を指摘しました。マーティンはまた、GSSネーミングのどの側面がひどく実装される傾向があるか、一部の顧客のニーズを満たしていないかについての優れた情報を提供しました。
Nicolas Williams helped describe the possible approaches for enhancing naming.
ニコラス・ウィリアムズは、命名を強化するための可能なアプローチを説明するのを手伝いました。
[1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[1] Adams、C。、「シンプルなパブリックキーGSS-APIメカニズム（SPKM）」、RFC 2025、1996年10月。
[2] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[2] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[3] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[4] Zhu, L., "Generating KDC Referrals to Locate Kerberos Realms", Work in Progress, June 2006.
[4] Zhu、L。、「Kerberos Realmsを見つけるためのKDC紹介の生成」、2006年6月、進行中の作業。
[5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[5] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[6] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[6] Farrell、S。およびR. Housley、「認証のためのインターネット属性証明書プロファイル」、RFC 3281、2002年4月。
Author's Address
著者の連絡先
Sam Hartman MIT
サム・ハートマン・ミット
EMail: hartmans-ietf@mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。