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).
著作権（C）IETFトラスト（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.
一般的なセキュリティサービスAPI（GSS-API）は、名前ベースの認証をサポートして命名アーキテクチャを提供します。 GSS-APIは、お互いに2人の名前付きの当事者を認証します。名前は、許可の決定を行うために、アクセス制御リスト（ACL）に保存することができます。セキュリティ機構や実装がGSS-APIを使用したい方法の進歩により、このモデルはGSS-APIの次のバージョンのために拡張されることを必要とします。人々が組織内で移動したり、自分の名前を変更すると、GSS-APIによって認証された名前が変更されることがあります。定数識別子のいくつかの並べ替えを使用すると、ACLがより安定するだろう。こうした公開鍵のメカニズムのようないくつかのメカニズムは、単一の名前は、すべての環境にまたがって使用する必要はありません。 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.
[2]一般的なセキュリティサービスAPIは、お互いに2人の名前付きの当事者を認証します。 GSS名はgss_import_nameコールを通じてさまざまな形式でインポートすることができます。いくつかのメカニズムに依存しない名前の形式は、ユーザーの名前のためのインターネットホスト上で実行中のサービスのためのGSS_C_NT_HOSTBASED_SERVICE、およびGSS_C_NT_USER_NAME含めて、提供されています。他の機構固有の名前タイプも用意されています。名前は、機構固有の資格を取得するか、セキュリティコンテキストを確立するのに使用される時間によって、これらの機構固有の名前のタイプのいずれかに変換されています。また、GSS-APIは、比較のために適したバイナリブロブにGSS-API名を変えていくgss_export_nameと呼ばれる機能を提供します。このバイナリブロブはACLに保存することができ、その後の認可決定が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認証データ[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メカニズムの二つの重要なクラスを持つ特定の命名の問題について説明します。また、提案されたソリューションとそれに関連する未解決の問題のセットについて説明します。これらの溶液および溶液を判断することができ、それに対して、問題の説明を提供し、この文書を制限ディスカッション。これらのソリューションは、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.
ケルベロス照会文書[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はない（とする予定はありません）、企業名などの認証以外のプリンシパルにマッピングする企業名のメカニズムを提供します。したがって、このようなマッピングはベンダ固有であろう。ケルベロスでこの機能を使用すると、企業名の種類の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メッセージで運ばれ、単一のプリンシパルがあります。 X.509証明書は、複数のオプションを持っています。サブジェクト名は、GSS-APIメカニズムにエクスポートする名前として使用するために適切な名前であるかもしれないようです。しかし、RFC 3280 [5]サブジェクト名は、エンドエンティティ証明書内の空の配列にすることができます。したがって、subjectAltName拡張は、対象を識別する証明書の一部だけかもしれません。ケルベロスのグループメンバシップの場合のように、証明書に利用可能な多くのsubjectAltName拡張があってもよいです。異なるアプリケーションは異なる名前形式を気にします。エクスポートされた名前のための一つの可能性のある候補者は、すべての被写界からの名前、および証明書の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メカニズムと十分な相互運用性につながっていません。サブジェクト名が使用されている場合でも、名前コンポーネントのソートを処理する方法で曖昧さがあります。マーティン・レックスは、彼はいくつかの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、企業名、認証インフラストラクチャでのグループメンバーシップ、およびKerberos認証用データ属性が含まれるであろうとのsubjectAltNameは証明書の属性。いくつかの新しい操作が必要とされるであろう。
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操作の間に混乱を回避することは、慎重な作業が必要になります。しかし、複合名の多くの属性は、バイナリ比較のために適切であろう。このような属性は、エクスポートされた名前は、今日のACLで使用されているのと同様に、ACLに使用することができます。特定のsubjectAltName拡張は、アプリケーションのための適切なIDが含まれている場合たとえば、こののSubjectAltNameのname属性はACLに配置することができます。 name属性は、いくつかの標準的な形式で保存されている場合にのみ当てはまります。
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.
ほとんどのname属性は、おそらく名前に属性を追加するための明示的な操作から来ることはありません。代わりに、name属性は、おそらく機構固有の資格情報から来ます。これらの機構固有の資格証明書のコンポーネントは、プラットフォームや環境固有の名前から来るかもしれません。機構固有の命名およびグループメンバーシップは、機構の実装によって、name属性にマッピングすることができます。このマッピングの具体的な形態は、一般的に、各機構のためのプロトコル仕様を必要とするであろう。
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つの名前付きエンティティを認証します。これらの名前に関連付けられているこれらのエンティティと属性の名前は、認可の決定のために使用されます。イニシエータまたはアクセプターは、name属性をアサートさせ、これらの主張の信憑性は、メカニズムによって検証されていない場合、セキュリティ上の問題が発生します。一方、その名前を必要とする属性は、機構固有のことしかname属性を理解し、彼らは汎用APIとしてGSS-APIの場所を損なう検証できるメカニズムによって運ばれます。アプリケーションの作成者は、許可決定を行うためのメカニズム固有の属性を理解することを余儀なくされるだろう。メカニズムは任意の属性を輸送するために必要とされていない場合はさらに、そのアプリケーションの作成者は、name属性の異なるセットをサポートするのと同じメカニズムの異なる実装に対処する必要があります。一つの可能な解決策は、それぞれの名前の属性と一緒にソースを運ぶことです。このソースは、属性が認証メカニズムのデータ構造から、または他の当事者から来ているかどうかを示すことができます。
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.
別の関連の質問は、name属性は、その機構固有の形式にマッピングされる方法です。例えば、name属性に多くのKerberos認証データ要素をマッピングすることが望ましいであろう。一部のアプリケーションでは、全体のPACを取得するために、Microsoft PAC（特権属性証明書）の場合には、それが望ましいであろう。しかし、多くの場合、PACに含まれるセキュリティIDの特定のリストには、より多くのアプリケーションに直接有用であろう。そう機構固有の要素とGSS-API層における望ましい表現との間の良好な一対一のマッピングが存在しなくてもよいです。
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でのターゲット名にname属性の効果は何ですか？
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によってエクスポートされた名前に使用する明白な選択肢があるでしょう。例えば、ケルベロスの場合、プリンシパル名は、エクスポート名として使用し続けることができます。これは、既存の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.
name属性の提案に代わるものではOIDのでラベルされた拡張子を持つGSS-API資格を拡張することです。インタフェースは、これらの資格の拡張機能を操作すると、コンテキストを確立するために使用する資格情報の資格の拡張機能を取得するために必要とされるであろう。名前の属性が使用されている場合でも、資格の拡張機能は、他の無関係な目的のために有用であり得ます。
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.
資格拡張子オーバーname属性案の主な利点は、名前属性は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.
この解決策の一つの利点は、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は、特定のターゲットに接続するときに使用するソースのアイデンティティの選択に大きな役割を取ることによって、アプリケーションの設計と実装を簡素化することができます。
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資格は単一のメカニズム名を表します。これは、時間によって資格情報が取得され、特定の単一のIDをクレデンシャルに各機構のために選択されているかのように、彼らは行動しなければなりません。すべてのこれらのIDは、単一のメカニズムの独立した名前に対応する必要があります。
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を含むために提案されています。まず、資格情報が取得されたときにメカニズム名が選ばれなければならない制約を緩和することができました。いくつかの名前の形式を使用する必要があるだろうが、この名前の形式は、可能性の集合を表すことができます。コンテキストの確立が起こったときに、特定のアイデンティティが選択されるであろう。これはアイデンティティの選択でターゲットから受信した情報を必要とすることができます。
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への変更のはるかに少ないだろうが、ターゲットから受信した情報は、アイデンティティの選択を選択することができません。
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:
既存のアプリケーションやメカニズムを破る避けるために、以下の下位互換性の要件が満たされる必要があります。
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メカニズム。複合名は、既存のエクスポートされた名前形式を変更することはできません。
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.
複雑さはセキュリティ上の問題につながる可能性の一つの領域は、異なるソースからの属性を持つ複合名です。 name属性は、独自の認証を運ぶことができるように、これは望ましいことであろう。しかし、いずれのソリューションの設計は、アプリケーションが名前のコンポーネントに適切な信頼を割り当てることができることを確認する必要があります。
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.
ジョンBrezak、ポールリーチ、そしてニコラス・ウィリアムズすべてはGSSの命名を強化したいという願望につながった議論に参加しました。マーティン・レックスは、現在の名前付けアーキテクチャの記述を提供し、相互運用性の問題を作成したり、複雑さを増加させる機能強化を提案している多くの方法を指摘しました。マーティンはまたひどく実装される傾向にあったか、一部の顧客のニーズを満たしていない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]アダムス、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]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート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]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 4120、2005年7月。
[4] Zhu, L., "Generating KDC Referrals to Locate Kerberos Realms", Work in Progress, June 2006.
[4]朱、L.、進歩、2006年6月ワーク "の生成KDCの紹介は、Kerberosレルムを検索するには"。
[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.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネット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]ファレル、S.とR. Housley氏、 "認可のためのインターネット属性証明書プロフィール"、RFC 3281、2002年4月。
Author's Address
著者のアドレス
Sam Hartman MIT
サム・ハートマンMIT
EMail: hartmans-ietf@mit.edu
メールアドレス：hartmans-ietf@mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。