RFC4768 日本語訳
4768 Desired Enhancements to Generic Security Services ApplicationProgram Interface (GSS-API) Version 3 Naming. S. Hartman. December 2006. (Format: TXT=27205 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hartman Request for Comments: 4768 MIT Category: Informational December 2006
コメントを求めるワーキンググループS.ハートマン要求をネットワークでつないでください: 4768年のMITカテゴリ: 情報の2006年12月
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).
IETFが信じる著作権(C)(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回の命名されたパーティーを認証します。 承認決定をするようにアクセスコントロールリスト(ACLs)に名前を保存できます。 セキュリティー対策における進歩とimplementersがGSS-APIを使用したがっている方法は、このモデルがGSS-APIの次のバージョンのために広げられるのを必要とします。 人々が組織の中で移行するか、または彼らの名前を変えるのに従って、GSS-APIによって認証された名前は変化するかもしれません。 ある種の一定の識別子を使用するのに、ACLsは、より安定するようになるでしょう。 公開鍵メカニズムなどのいくつかのメカニズムには、すべての環境の向こう側に使用されるべきただ一つの名前がありません。 ケルベロスなどの他のメカニズムは認証の一部としてグループ会員資格か役割の情報を含むかもしれません。 このドキュメントは、GSS-API命名に拡大を動機づけて、議論で拡大について説明します。
Hartman Informational [Page 1] RFC 4768 GSS Names December 2006
ハートマン情報[1ページ]のRFC4768GSSは2006年12月を命名します。
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
1. 序論…2 2. ケルベロス命名…3 3. X.509名…4 4. 名前を合成してください…5 4.1. 名前属性の用法…6 4.2. 問題を開いてください…6 4.3. 取り扱いgss_は、_が名前であるとエクスポートします…7 5. 資格証明拡大…7 6. 輸出名のためのメカニズム…8 7. ソースのアイデンティティの選択…8 8. GSS-API V2との互換性…9 9. セキュリティ問題…9 10. 承認…10 11. 有益な参照…10
1. Introduction
1. 序論
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.
Generic Security Services API[2]は互いに2回の命名されたパーティーを認証します。 呼ぶというgss_輸入_名を通してさまざまな形式でGSS名をインポートすることができます。 いくつかのメカニズムから独立している名前形式を提供します、ユーザの名前のために_インターネット・ホスト、およびGSS_C NT_USER_NAMEの上で作業するサービスのために_GSS_C NT_HOSTBASED_SERVICEを含んでいて。 また、他のメカニズム種名タイプを提供します。 名前がメカニズムの特定の資格証明書を取得するか、またはセキュリティ文脈を確立する際に使用される時までには、それはこれらのメカニズム種名タイプのひとりに変えられました。 さらに、GSS-APIはGSS-API名を比較に適した2進の一滴に変えるgss_輸出_名と呼ばれる機能を提供します。 ACLsにこの2進の一滴を保存できます、そして、次に、単に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.
名前が、時間がたつにつれて変化する傾向があるので、ACLsに名前を保存するのは問題が多い場合があります。 名前がドメイン部分の組織的な情報を含んでいるか、そして、だれかがどんな部に関して働くかしるし、人が組織の周りで移行するとき、これは変化します。 どんな組織的な情報も名前に含まれないでも、人々が改名するのに応じて、名前は変化するでしょう。 改名を反映するためにACLsをアップデートするのは難しいです。 別の重大な問題はそれらが元々適用した実体以外の実体に適用するために名前を再利用できるということです。 例えば、UnixユーザIDがACL、削除されたアカウント、および次に、新しい古いIDが割り当てられたユーザに置かれるなら、その新しいユーザは年取ったユーザのために意図する特権を獲得するかもしれません。
Hartman Informational [Page 2] RFC 4768 GSS Names December 2006
ハートマン情報[2ページ]のRFC4768GSSは2006年12月を命名します。
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.
この命名アーキテクチャが制限し過ぎている数個のセキュリティー対策が提案されました。 いくつかの場合、インポートされるどんな名前もcanonicalizeするのはいつも可能であるというわけではありません。 他の場合には、どんなただ一つの正準な名前もありません。
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]、ケルベロス承認データ[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.
このドキュメントは2つの重要なクラスのGSS-APIメカニズムに関する特定の命名問題について議論します。また、それは提案された解決とそれらの関連未解決の問題のセットについて議論します。 このドキュメントは、議論をこれらのソリューションに制限して、ソリューションを判断できる問題の記述を提供します。 これらのソリューションはGSS-APIバージョン3への編入のために狙います。
2. Kerberos Naming
2. ケルベロス命名
The Kerberos mechanism demonstrates both the naming stability problem and the authorization extension problem.
ケルベロスメカニズムは命名安定問題と承認拡大問題の両方を示します。
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.
ケルベロスReferralsドキュメント[4]は企業名と呼ばれる新しいタイプのケルベロス名を提案します。 意図は企業名がユーザが自分たちで知って、ログインするのに使用できる別名であるということです。 ケルベロスKey Distributionセンター(KDC)は、正常なケルベロス元本にこの名前を翻訳して、この主体のユーザチケットを与えます。 この正常な主体は承認に使用されます。 意図は彼らが組織の間中移行するとき企業名がユーザを追跡するということです、彼らが異なった命名方針を持っている組織の部分に移行しても。 彼らがログインでタイプする名前は一定のままで残っていますが、サービスにそれらを認証するのに使用されるケルベロス主体は変化します。
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
一般に、Unauthenticatedサービスは企業名から主要な名前までマッピングを実行できません。 認証されたサービスさえ認証されたサービスの名前以外の名前を写像するのは認可されないかもしれません。 また、ケルベロスは企業名としての認証以外に企業名を主体に写像するのにメカニズムを提供しません(そして、計画していません)。 したがって、そのようなどんなマッピングもベンダー特有でしょう。 ケルベロスにおけるこの特徴でそれ
Hartman Informational [Page 3] RFC 4768 GSS Names December 2006
ハートマン情報[3ページ]のRFC4768GSSは2006年12月を命名します。
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.
gssに_を実装するのが企業名前タイプのために_名前をcanonicalizeするのが可能ではありません。 もちろん、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_輸出_名の名前に企業名を含んでいることによって、これを達成できるでしょう。 残念ながら、これをするなら、マッピングが変化したときはいつも、エクスポートしている名前は変化するでしょうに、古いエクスポートしている名前から基づくどんな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.
また、別の開発はケルベロスのためのGSS-API命名を複雑にします。 いくつかのベンダーが、ケルベロス承認データにグループ会員資格情報を含むようにメカニズムを見ています。 これらのグループ名をACLsに置くのは望ましいです。 一方、GSS-APIには、現在、この情報を使用するメカニズムが全くありません。
3. X.509 Names
3. X.509名
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名はケルベロス名より複雑です。 ケルベロス場合には、すべてのケルベロスメッセージで運ばれたただ一つの元本があります。 X.509証明書には、複数のオプションがあります。 GSS-APIメカニズムでエクスポートされるために対象の名前が名前であるかもしれないように思えます名前として使用するのが適切である。 しかしながら、RFC3280[5]は、対象の名前が終わり実体証明書の空の系列であることを許容します。 したがって、subjectAltName拡張子は対象を特定する証明書の唯一の一部であるかもしれません。 ケルベロスグループ会員資格に関するケースのように、証明書で利用可能な多くの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証明書を使用できることへの関心があります。
Hartman Informational [Page 4] RFC 4768 GSS Names December 2006
ハートマン情報[4ページ]のRFC4768GSSは2006年12月を命名します。
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に支えるのも望ましいです。
4. Composite Names
4. 合成名前
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つの提案は1セットの名前属性を含むようにGSS-API名の概念について敷衍することです。 各属性はOIDによってラベルされた八重奏ストリングでしょう。 属性に関する例は証明書にケルベロス企業名、承認インフラストラクチャ、およびケルベロス承認データ属性におけるグループ会員資格、および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.
一般に、エクスポートしている合成名前が2進の比較に適していないことに注意してください。 この操作と既存のgss_輸出_名前操作の間の混乱を避けるのは丁寧な作業を必要とするでしょう。 しかしながら、合成名前の多くの属性が2進の比較に適切になるでしょう。 ちょうどエクスポートしている名前が今日ACLsで使用されるようにACLsでそのような属性を使用できます。 例えば、特定のSubjectAltName拡張子がアプリケーションのための適切なアイデンティティを含んでいるなら、このSubjectAltNameのための名前属性をACLに置くことができます。 名前属性が何らかの標準形に保存される場合にだけ、これは本当です。
Additional utility operations will probably be needed depending on the implementation of name attributes.
名前属性の実装によって、追加ユーティリティ操作がたぶん必要でしょう。
Hartman Informational [Page 5] RFC 4768 GSS Names December 2006
ハートマン情報[5ページ]のRFC4768GSSは2006年12月を命名します。
4.1. Usage of Name Attributes
4.1. 名前属性の用法
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.
ほとんどの名前属性は、属性を名前に追加しにたぶん明白な操作から来ないでしょう。 代わりに、名前属性はたぶんメカニズム特有の資格証明書から来るでしょう。 これらのメカニズム特有の資格証明書のコンポーネントはプラットホームか環境種名から来るかもしれません。 メカニズム実装はメカニズム特有の命名とグループ会員資格を名前属性に写像できます。 一般に、このマッピングの特定のフォームは各メカニズムのためのプロトコル仕様を必要とするでしょう。
4.2. Open Issues
4.2. 未解決の問題
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つの命名された実体を互いに認証します。 これらの名前に関連しているこれらの実体と属性の名前は承認決定に使用されるでしょう。 創始者かアクセプタが名前属性について断言できて、これらの主張の信憑性がメカニズムによって有効にされないと、警備上の問題は結果として生じるでしょう。 他方では、名前属性がメカニズム特有であり、属性という名前を理解しているメカニズムによって運ばれるだけであり、それらを有効にすることができるのが必要であるのがジェネリックAPIとしてGSS-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
別の関連する質問は名前属性がどうそれらのメカニズム特有のフォームに写像されるかということです。例えば、多くのケルベロス承認データ要素を名前属性に写像するのは望ましいでしょう。 マイクロソフトPAC(特権属性証明書)の場合では、いくつかのアプリケーションが得るのにおいてそれは望ましいでしょう。
Hartman Informational [Page 6] RFC 4768 GSS Names December 2006
ハートマン情報[6ページ]のRFC4768GSSは2006年12月を命名します。
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.
全体の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_の目標名への名前属性の効果であることは_秒_文脈を受け入れますか?
4.3. Handling gss_export_name
4.3. 取り扱いgss_輸出_名
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_輸出_名の名前に使用する当然の選択があるでしょう。 例えば、ケルベロスの場合では、主要な名前は、エクスポートしている名前として使用され続けることができます。 これで、既存のGSS-API名前ベースの承認によるアプリケーションは、働き続けることができるでしょう。 しかしながら、gss_輸出_名を意味深長に定義できないGSS-APIメカニズムを許容するのはたぶん望ましいです。 そのような場合、gss_輸出_名の振舞いはたぶん何らかの誤りを返すことであるべきです。 そのようなメカニズムは、既存のアプリケーションで取り組まないかもしれなくて、GSS-APIの最新版に一致できません。
5. Credential Extensions
5. 資格証明拡大
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.
名前属性提案への代替手段は拡大がOIDsによってラベルされている状態で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.
資格証明拡大の上の名前属性提案のプライマリ利点は名前属性が、より一層GSS API承認モデルに収まるように思えるということです。 承認決定をするとき、名前はすべてのポイントで既に利用可能です。 さらに、多くのメカニズムのために、また、名前属性がメカニズムの名前の一部として運ばれるのに従って、情報の種類は運ばれました。
Hartman Informational [Page 7] RFC 4768 GSS Names December 2006
ハートマン情報[7ページ]のRFC4768GSSは2006年12月を命名します。
6. Mechanisms for Export Name
6. 輸出名のためのメカニズム
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意味論への変化であるならもわずかしか必要としないということです。 それは他のソリューションほどフレキシブルではありません。 また、どのようにこのソリューションでエクスポートする明確な名前を持っていないメカニズムを扱うかも明確ではありません。
7. Selection of Source Identity
7. ソースのアイデンティティの選択
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.
今日、メール・クライアントやウェブブラウザなどの応用はマルチターゲットに接続を必要とします。 各目標のために、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資格証明書はただ一つのメカニズム名を表します。 すなわち、資格証明書が後天的である時までには、まるで特定のただ一つのアイデンティティが資格証明書における各メカニズムに選ばれているかのようにそれらは行動しなければなりません。 これらのすべてのアイデンティティがただ一つのメカニズム独立している名に対応しなければなりません。
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.
2つの可能性が、GSS-APIにソースのアイデンティティの品揃えにかかわるために提案されました。 資格証明書が後天的であるときに、まず最初に、メカニズム名を選ばなければならないという規制を緩和されることができました。 何らかの名前フォームが、使用される必要があるでしょうが、この名前フォームは1セットの可能性を表すかもしれません。 文脈設立が起こったとき、特定のアイデンティティは選ばれるでしょう。 これは目標からアイデンティティ選択で受け取られた情報にかかわるかもしれません。
Hartman Informational [Page 8] RFC 4768 GSS Names December 2006
ハートマン情報[8ページ]のRFC4768GSSは2006年12月を命名します。
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に拡大を支持します。
8. Compatibility with GSS-API V2
8. GSS-API V2との互換性
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アプリケーションはこれらのメカニズムを選択しません。
9. Security Considerations
9. セキュリティ問題
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.
2の間のセキュリティ文脈へのGSS-APIセットはパーティーを命名しました。 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は承認に安易な命名モデルを使用します。 アクセスコントロールリストで1セットの名前に対して名前をたとえることができます。 このアーキテクチャは比較的簡単です、そして、セキュリティの特性はよく理解されています。 しかしながら、それはGSS-APIの今後の展開に設定された柔軟性と特徴を提供しません。
Hartman Informational [Page 9] RFC 4768 GSS Names December 2006
ハートマン情報[9ページ]のRFC4768GSSは2006年12月を命名します。
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つの領域がさまざまな原因からの属性の合成名前です。 これは、名前属性がそれら自身の認証を運ぶことができるくらい望ましいかもしれません。 しかしながら、どんなソリューションのデザインも、アプリケーションがコンポーネントを命名するために適切な信頼を割り当てることができるのを確実にする必要があります。
10. Acknowledgements
10. 承認
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.
ニコラス・ウィリアムズは、命名を機能アップするための可能なアプローチについて説明するのを助けました。
11. Informative References
11. 有益な参照
[1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[1] アダムス、C.、「簡単な公開鍵GSS-APIメカニズム(SPKM)」、RFC2025 1996年10月。
[2] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[2] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1インチ、RFC2743、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)」、RFC4120 2005年7月。
[4] Zhu, L., "Generating KDC Referrals to Locate Kerberos Realms", Work in Progress, June 2006.
[4] 「ケルベロス分野の場所を見つけるようにKDCに紹介を生成し」て、朱、L.は進歩、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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[6] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[6] ファレルとS.とR.Housley、「承認のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
Hartman Informational [Page 10] RFC 4768 GSS Names December 2006
ハートマン情報[10ページ]のRFC4768GSSは2006年12月を命名します。
Author's Address
作者のアドレス
Sam Hartman MIT
サムハートマンMIT
EMail: hartmans-ietf@mit.edu
メール: hartmans-ietf@mit.edu
Hartman Informational [Page 11] RFC 4768 GSS Names December 2006
ハートマン情報[11ページ]のRFC4768GSSは2006年12月を命名します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hartman Informational [Page 12]
ハートマンInformationalです。[12ページ]
一覧
スポンサーリンク