RFC2478 日本語訳
2478 The Simple and Protected GSS-API Negotiation Mechanism. E. Baize,D. Pinkas. December 1998. (Format: TXT=35581 bytes) (Obsoleted by RFC4178) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Baize
Request for Comments: 2478 D. Pinkas
Category: Standards Track Bull
December 1998
コメントを求めるワーキンググループE.ベーズ要求をネットワークでつないでください: 2478年のD.ピンカスカテゴリ: 標準化過程雄牛1998年12月
The Simple and Protected GSS-API Negotiation Mechanism
簡単で保護されたGSS-API交渉メカニズム
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
1. ABSTRACT
1. 要約
This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in [1].
このドキュメントは[1]で説明されるGeneric Security Service Application Program Interface(GSS-API)にSecurity Negotiation Mechanismを指定します。
The GSS-API provides a generic interface which can be layered atop different security mechanisms such that if communicating peers acquire GSS-API credentials for the same security mechanism, then a security context may be established between them (subject to policy). However, GSS-API doesn't prescribe the method by which GSS-API peers can establish whether they have a common security mechanism.
GSS-APIは交信している同輩が同じセキュリティー対策のためにGSS-API資格証明書を取得するならそれら(方針を条件とした)の間でセキュリティ文脈を確立できるように異なったセキュリティー対策の上で層にすることができるジェネリックインタフェースを提供します。 しかしながら、GSS-APIはGSS-API同輩が彼らには共通の安全保障メカニズムがあるかどうかを確証できるメソッドを定めません。
The Simple and Protected GSS-API Negotiation Mechanism defined here is a pseudo-security mechanism, represented by the object identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and if so, to invoke normal security context establishment for a selected common security mechanism. This is most useful for applications that are based on GSS-API implementations which support multiple security mechanisms.
ここで定義されたSimpleとProtected GSS-API Negotiation Mechanismがオブジェクト識別子iso.org.dod.internet.security.mechanism.snegoによって表されたa疑似セキュリティー対策である、(1.3 .6 .1 .5 .5 .2) GSS-API同輩が彼らの資格証明書が一般的なGSS-APIセキュリティー対策を共有するか否かに関係なく、中で組になるように決心して、そうだとすれば、選択された共通の安全保障メカニズムのための通常のセキュリティ文脈設立を呼び出すのを可能にする。 これは複数のセキュリティがメカニズムであるとサポートするGSS-API実行に基づいているアプリケーションの最も役に立ちます。
This allows to negotiate different security mechanisms, different options within a given security mechanism or different options from several security mechanisms.
これで、異なったセキュリティー対策(数個のセキュリティー対策からの与えられたセキュリティー対策か異なったオプションの中の異なったオプション)を交渉します。
Baize & Pinkas Standards Track [Page 1] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[1ページ]。
Once the common security mechanism is identified, the security mechanism may also negotiate mechanism-specific options during its context establishment. This will be inside the mechanism tokens, and invisible to the SPNEGO protocol.
一度、共通の安全保障メカニズムは特定されます、また、セキュリティー対策が文脈設立の間、メカニズム特有のオプションを交渉するかもしれません。 これは、メカニズムトークンにはあって、SPNEGOプロトコルに目に見えないでしょう。
The simple and protected GSS-API mechanism negotiation is based on the following negotiation model : the initiator proposes one security mechanism or an ordered list of security mechanisms, the target either accepts the proposed security mechanism, or chooses one from an offered set, or rejects the proposed value(s). The target then informs the initiator of its choice.
簡単で保護されたGSS-APIメカニズム交渉は以下の交渉モデルに基づいています: 創始者が1台のセキュリティー対策かセキュリティー対策の規則正しいリストを提案して、目標は、提案されたセキュリティー対策を受け入れるか、提供されたセットからの1つを選ぶか、または提案された値を拒絶します。 そして、目標は選択について創始者に知らせます。
In its basic form this protocol requires an extra-round trip. Network connection setup is a critical performance characteristic of any network infrastructure and extra round trips over WAN links, packet radio networks, etc. really make a difference. In order to avoid such an extra round trip the initial security token of the preferred mechanism for the initiator may be embedded in the initial token. If the target preferred mechanism matches the initiator's preferred mechanism, no additional round trips are incurred by using the negotiation protocol.
基本的なフォームでは、このプロトコルは付加的な周遊旅行を必要とします。 ネットワーク接続設定はどんなネットワークインフラのきわどい性能の特性です、そして、WANリンク、パケット無線ネットワークなどの上の付加的な周遊旅行に本当に効果があります。 そのような付加的な周遊旅行を避けるために、創始者にとって、都合のよいメカニズムの初期のセキュリティトークンは初期のトークンに埋め込まれるかもしれません。 目標であるなら、都合のよいメカニズムは創始者の都合のよいメカニズムに合って、どんな追加周遊旅行も、交渉プロトコルを使用することによって、被られません。
The simple and protected GSS-API mechanism negotiation provides a technique to protect the negotiation that must be used when the underlying mechanism selected by the target is capable of integrity protection.
簡単で保護されたGSS-APIメカニズム交渉は、目標によって選択された発症機序が保全保護ができるとき使用しなければならない交渉を保護するためにテクニックを提供します。
When all the mechanisms proposed by the initiator support integrity protection or when the selected mechanism supports integrity protection, then the negotiation mechanism becomes protected since this guarantees that the appropriate mechanism supported by both peers has been selected.
創始者によって提案されたすべてのメカニズムが、保全が保護であるとサポートするか、または選択されたメカニズムが、保全が保護であるとサポートすると、これが、両方の同輩によってサポートされた適切な手段が選択されたのを保証するので、交渉メカニズムは保護されるようになります。
The Simple and Protected GSS-API Negotiation Mechanism uses the concepts developed in the GSS-API specification [1]. The negotiation data is encapsulated in context-level tokens. Therefore, callers of the GSS-API do not need to be aware of the existence of the negotiation tokens but only of the new pseudo-security mechanism. A failure in the negotiation phase causes a major status code to be returned: GSS_S_BAD_MECH.
概念がGSS-API仕様[1]で開発したSimpleとProtected GSS-API Negotiation Mechanism用途。 交渉データは文脈レベルトークンでカプセル化されます。 したがって、交渉トークンの存在が意識しているのが必要であるのではなく、GSS-APIの訪問者は新しい疑似セキュリティー対策だけについて必要です。 交渉フェーズにおける失敗で、主要なステータスコードを返します: _GSS_S悪い_MECH。
Baize & Pinkas Standards Track [Page 2] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[2ページ]。
2. NEGOTIATION MODEL
2. 交渉モデル
2.1. Negotiation description
2.1. 交渉記述
The model for security mechanism negotiation reuses a subset of the concepts specified in [2].
セキュリティー対策交渉のためのモデルは[2]で指定された概念の部分集合を再利用します。
Each OID represents one GSS-API mechanism or one variant of it.
各OIDはそれの1つのGSS-APIメカニズムか1つの異形を表します。
- When one security mechanism is proposed by the initiator, it
represents the only security mechanism supported or selected
(when the additional APIs defined in the Annex A are used) by the
initiator.
- 1台のセキュリティー対策が創始者によって提案されるとき、それは創始者によってサポートされたか、または選択された(Annex Aで定義された追加APIが使用されているとき)唯一のセキュリティー対策を表します。
- When several security mechanisms are proposed by the initiator,
they represent a set of security mechanisms supported or selected
(when the additional APIs defined in the Annex A are used) by the
initiator.
- 数個のセキュリティー対策が創始者によって提案されるとき、彼らは創始者によってサポートされたか、または選択された(Annex Aで定義された追加APIが使用されているとき)1セットのセキュリティー対策を表します。
The first negotiation token sent by the initiator contains an ordered list of mechanisms, a set of options (e.g. deleg, replay, conf flags) that should be supported by the selected mechanism and optionally the initial security token for the desired mechanism of the initiator (i.e. the first of the list).
創始者によって送られた最初の交渉トークンはメカニズムの規則正しいリストを含んでいます、選択されたメカニズムで任意に後押しされているべきである1セットのオプション(例えば、deleg、再生、confは弛みます)。創始者(すなわち、リストの1番目)の必要なメカニズムのための初期のセキュリティトークン。
The first negotiation token sent by the target contains the result of the negotiation (accept_completed, accept_incomplete or reject) and, in case of accept, the agreed security mechanism. It may also include the response to the initial security token from the initiator, when the first proposed mechanism of the initiator has been selected. When the first mechanism is acceptable to the target,it should respond to the initial security token for the desired mechanism of the initiator when it is present. However, if this is not possible, the target can simply ignore it and omit the responseToken from the first reply.
の場合に、目標によって送られた最初の交渉トークンが交渉の結果を含んでいる、(_が完成していると受け入れてくださいといって、_が不完全であると受け入れてください、廃棄物、)、受け入れてください、同意されたセキュリティー対策。 また、それは創始者からの初期のセキュリティトークンへの応答を含むかもしれません、創始者の最初の提案されたメカニズムが選択されたとき。 最初のメカニズムが目標に許容できるとき、存在しているとき、それは創始者の必要なメカニズムのために初期のセキュリティトークンに応じるべきです。 しかしながら、これが可能でないなら、目標は、最初の回答から単にそれを無視して、responseTokenを省略できます。
Implementations that can piggyback the initial token will be rewarded by faster connection setup.
初期のトークンを背負うことができる実装が、より速い接続設定で報酬を与えられるでしょう。
In case of a successful negotiation, the security mechanism represents the value suitable for the target, and picked up from the list offered by the initiator. The policy by which the target chooses a mechanism is an implementation-specific local matter. In the absence of other policy, the target should chose the first mechanism in the list for which valid credentials are available.
うまくいっている交渉の場合には、創始者によってリストから提供されて、セキュリティー対策は目標に適していて、粒選りで値を表します。 目標がメカニズムを選ぶ方針は実装特有の地域にかかわる事柄です。 他の方針がないとき目標は選ぶべきです。正当な証明書が利用可能であるリストにおける最初のメカニズムを選びました。
Once a mechanism has been selected, the tokens specific to the selected mechanism are carried within the negotiation tokens (in the mechToken for the initiator and in the responseToken for the target).
メカニズムがいったん選択されると、選択されたメカニズムに特定のトークンは交渉トークン(創始者のためのmechTokenと目標のためのresponseTokenの)の中で運ばれます。
Baize & Pinkas Standards Track [Page 3] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[3ページ]。
2.2. Negotiation procedure
2.2. 交渉手順
The negotiation procedure is summarised as follows:
以下の通り交渉手順について略言します:
(a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but
requests (either explicitly, with the negotiation mechanism, or
through accepting a default, when the default is the negotiation
mechanism) that the Simple and Protected GSS-API Negotiation
Mechanism be used;
(a) GSS-API創始者は、正常なGSS_Init_同じくらい秒_文脈を呼び出しますが、SimpleとProtected GSS-API Negotiation Mechanismが使用されるよう要求します(明らかかデフォルトが交渉メカニズムであるときに交渉メカニズムか、デフォルトを受け入れることを通して)。
(b) the initiator GSS-API implementation emits a negotiation token
containing a list of supported security mechanisms for the
credentials used for this context establishment, and optionally
an initial security token for the first mechanism from that list
(i.e. the preferred mechanism), and indicates
GSS_S_CONTINUE_NEEDED status;
(b) 創始者GSS-API実行がこの文脈設立に使用される資格証明書のためのサポートしているセキュリティー対策のリストを含む交渉トークンを放って、それからの最初のメカニズムのための初期のセキュリティトークンは、任意に、(すなわち、都合のよいメカニズム)を記載して、GSS_S_CONTINUE_が状態を必要としたのを示します。
(c) The GSS-API initiator sends the token to the target application;
(c) GSS-API創始者は目標アプリケーションにトークンを送ります。
(d) The GSS-API target deposits the token through invoking
GSS_Accept_sec_context. The target GSS-API implementation emits a
negotiation token containing which if any of the proposed
mechanisms it supports (or has selected).
(d) GSS-API目標は、GSS_Accept_秒_文脈を呼び出すことでトークンを預けます。 または、目標GSS-API実行がもしあればどれを含むそれがサポートする提案されたメカニズムの交渉トークンを放つ、(選択した、)
If the mechanism selected by the target matches the preferred mechanism identified by the initiator and the initiator provides a mechToken, the negotiation token response may contain also an initial security token from that mechanism.
また、都合のよいメカニズムが創始者と創始者で特定した目標マッチによって選択されたメカニズムがmechTokenを提供するなら、交渉トークン応答はそのメカニズムからの初期のセキュリティトークンを含むかもしれません。
If the preferred mechanism is accepted, GSS_Accept_sec_context() indicates GSS_S_COMPLETE when unilateral or mutual authentication has been performed and involves a single token in either direction.
都合のよいメカニズムを受け入れるなら、GSS_Accept_秒_文脈()は、一方的であるか互いの認証が実行されたとき、_GSS_S COMPLETEを示して、ただ一つのトークンにどちらの方向にもかかわります。
If a proposed mechanism is accepted, and it was not the preferred mechanism, or if the first negotiation token sent by the initiator did not included a mechToken, then the negotiation token response sent by the target may contain also a response token from that mechanism which transmits mechanism-specific information (e.g. to transmit a certificate). The initiator may ignore such an initial token if it is not prepared to process it.
また、提案されたメカニズムを受け入れて、それが都合のよいメカニズムでなかった、または創始者によって送られたトークンがそうする最初の交渉がmechTokenを含んでいなかったなら、目標によって送られた交渉トークン応答はメカニズム特殊情報(例えば証明書を伝える)を伝えるそのメカニズムからの応答トークンを含むかもしれません。 それがそれを処理するように準備されないなら、創始者はそのような初期のトークンを無視するかもしれません。
If a proposed mechanism other than the preferred mechanism is accepted, or the preferred mechanism is accepted but involves multiple exchanges (e.g. challenge-response authentication), then GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status.
都合のよいメカニズム以外の提案されたメカニズムを受け入れるか、都合のよいメカニズムが受け入れますが、複数の交換(例えば、チャレンジレスポンス認証)にかかわるなら、GSS_Accept_秒_文脈()は、GSS_S_CONTINUE_が状態を必要としたのを示します。
Baize & Pinkas Standards Track [Page 4] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[4ページ]。
If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() indicates GSS_S_BAD_MECH status. The security context initialisation has failed.
提案されたメカニズムが拒絶されるなら、GSS_Accept_秒_文脈()はGSS_S_BAD_MECH状態を示します。 セキュリティ文脈初期化処理は失敗しました。
(e) The GSS-API target returns the token to the initiator
application;
(e) GSS-API目標は創始者アプリケーションにトークンを返します。
(f) The GSS-API initiator deposits the token through invoking
GSS_Init_sec_context.
(f) GSS-API創始者は、GSS_Init_秒_文脈を呼び出すことでトークンを預けます。
GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED, GSS_S_COMPLETE or GSS_S_BAD_MECH status.
次に、GSS_Init_秒_文脈()はCONTINUE_が必要としたGSS_S_を示すかもしれなくて、GSS__S COMPLETEか_GSS_S BAD_MECHは状態です。
The GSS_S_BAD_MECH status is returned when the negotiation token
carries a reject result or when the negotiation token carries an
accept result and the mechanism selected by the target is not
included in the initial list sent by the initiator.
交渉トークンが廃棄物結果を運ぶか、または交渉トークンが運ばれるとき、GSS_S_BAD_MECH状態が返される、中の初期のリストが創始者で送った含まれていなかった目標によって選択された結果とメカニズムを受け入れてください。
The GSS_S_BAD_MIC status is returned when the selected mechanism
supports a MIC token but the MIC computed over the list of
mechanisms sent by the initiator is missing or incorrect.
選択されたメカニズムがMICトークンをサポートするとき、GSS_S_BAD_MIC状態は返されますが、創始者によって送られたメカニズムのリストに関して計算されたMICはなくなるか、または不正確です。
If the negotiation token carries a reject result, the context
establishment is impossible. For example, a rejection will occur
if the target doesn't support the initiator's proposed mechanism
type(s). Upon failure of the mechanism negotiation procedure, the
mech_type output parameter value is the negotiation mechanism
type.
交渉トークンが廃棄物結果を運ぶなら、文脈設立は不可能です。 例えば、目標が、創始者の提案されたメカニズムがタイプ(s)であるとサポートしないと、拒絶は起こるでしょう。 メカニズム交渉手順の失敗では、mech_タイプ出力パラメタ価値は交渉メカニズムタイプです。
The GSS_S_CONTINUE_NEEDED status is returned when the negotiation
token carries an accept result and further tokens must be
transferred in order to complete context establishment for the
selected mechanism. In that case GSS_Init_sec_context() returns an
initial context token as output_token (with the selected
mechanism's context token encapsulated within that output_token).
GSS、_交渉トークンが運ばれるとき必要な状態が返されるS_CONTINUE_、結果を受け入れてください。そうすれば、選択されたメカニズムのための文脈設立を終了するためにさらなるトークンを移さなければなりません。 その場合、Init_秒_文脈()が初期の文脈トークンを返すGSS_は_トークン(選択されたメカニズムの文脈トークンがその出力_トークンの中でカプセル化されている)を出力しました。
The initiator then sends the output_token to the target. The
security context initialisation is then continued according to the
standard GSS-API conventions for the selected mechanism, where the
tokens of the selected mechanism are encapsulated until the
GSS_S_COMPLETE is returned for both the initiator and the target.
When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
parameter is not yet valid.
そして、創始者は出力_トークンを目標に送ります。 そして、選択されたメカニズムのための一般的なGSS-APIコンベンションによると、セキュリティ文脈初期化処理は続けられています。(そこでは、選択されたメカニズムのトークンが創始者と目標の両方のためにGSS_S_COMPLETEを返すまでカプセル化されます)。 CONTINUE_が必要としたGSS_S_を返すとき、mech_タイプ出力パラメタはまだ有効ではありません。
When GSS_S_COMPLETE is returned, the mech_type output parameter
indicates the selected mechanism. When the final negotiation token
does not contain a MIC, the initiator GSS-API implementation must
check the returned/selected mechanism is on the originally
GSS_S_COMPLETEを返すとき、mech_タイプ出力パラメタは選択されたメカニズムを示します。 最終的な交渉トークンがそうしないとき、MICを含んでください、返されたか選択されたメカニズムがある創始者GSS-API実行必須チェック、元々
Baize & Pinkas Standards Track [Page 5] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[5ページ]。
submitted list of mechanisms and also verify that the selected
mechanism is not able to support a MIC. When the final negotiation
token contains a MIC over the initial mechanisms list sent by the
initiator, the MIC must be verified.
提出して、メカニズムについて記載してください、そして、また、選択されたメカニズムがMICをサポートすることができないことを確かめてください。 最終的な交渉トークンが創始者によって送られた初期のメカニズムリストの上にMICを含むとき、MICについて確かめなければなりません。
Note that the *_req_flag input parameters for context establishment are relative to the selected mechanism, as are the *_state output parameters. i.e., these parameters are not applicable to the negotiation process per se.
Note that the *_req_flag input parameters for context establishment are relative to the selected mechanism, as are the *_state output parameters. i.e., these parameters are not applicable to the negotiation process per se.
The initiator GSS-API calling application may need to know when the negotiation exchanges were protected or not. For this, when GSS_S_COMPLETE is returned, it can simply test the integ_avail flag. When this flag is set it indicates that the negotiation was protected.
創始者GSS-API呼ぶアプリケーションは、交渉交換がいつ保護されたかを知る必要があるかもしれません。 GSS_S_COMPLETEを返すとき、これがないかどうか、それは単にinteg_利益旗を検査できます。 この旗が設定されるとき、それは、交渉が保護されたのを示します。
On receipt of a negotiation token on the target side, a GSS-API implementation that does not support negotiation would indicate the GSS_S_BAD_MECH status as if a particular basic security mechanism had been requested but was not supported.
目標側の上の交渉トークンを受け取り次第、交渉をサポートしないGSS-API実行は、しかし、まるで特定の基本的なセキュリティー対策が要求されたかのようにGSS_S_BAD_MECH状態がサポートされなかったのを示すでしょう。
When GSS_Acquire_cred is invoked with the negotiation mechanism as desired_mechs, an implementation-specific default credential is used to carry on the negotiation. A set of mechanisms as specified locally by the system administrator is then available for negotiation. If there is a desire for the caller to make its own choice, then an additional API has to be used (see Appendix A).
GSS_Acquire_信用が必要な_mechsとして交渉メカニズムで呼び出されるとき、実装特有のデフォルト資格証明書は、交渉のときに運ぶのに使用されます。 1セットのメカニズムはその時、システム管理者で局所的に指定するように交渉に利用可能です。 訪問者がそれ自身の選択をする願望があれば、追加APIは使用されなければなりません(Appendix Aを見てください)。
3. DATA ELEMENTS
3. データ要素
3.1. Mechanism Type
3.1. メカニズムタイプ
MechType::= OBJECT IDENTIFIER
MechType:、:= オブジェクト識別子
mechType
Each security mechanism is as defined in [1].
mechType Eachセキュリティー対策が[1]で定義されるようにあります。
3.2. Negotiation Tokens
3.2. 交渉トークン
The syntax of the negotiation tokens follows the InitialContextToken syntax defined in [1]. The security mechanism of the initial negotiation token is identified by the Object Identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
交渉トークンの構文は[1]で定義されたInitialContextToken構文に従います。 初期の交渉トークンのセキュリティー対策がObject Identifier iso.org.dod.internet.security.mechanism.snegoによって特定される、(1.3 .6 .1 .5 .5 .2)。
Baize & Pinkas Standards Track [Page 6] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[6ページ]。
3.2.1. Syntax
3.2.1. 構文
This section specifies the syntax of the corresponding "innerContextToken" field for the first token and subsequent negotiation tokens. During the mechanism negociation, the "innerContextToken" field contains the ASN.1 structure "NegociationToken" given below, encoded using the DER encoding conventions.
このセクションは対応する"innerContextToken"分野の構文を最初のトークンとその後の交渉トークンに指定します。 メカニズムnegociationの間、"innerContextToken"分野はコンベンションをコード化するDERを使用することで以下で、コード化されていた状態で与えられたASN.1構造"NegociationToken"を含んでいます。
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenTarg [1] NegTokenTarg }
NegotiationToken:、:= 選択negTokenInit[0]NegTokenInit、negTokenTarg[1]NegTokenTarg
MechTypeList ::= SEQUENCE OF MechType
MechTypeList:、:= MechTypeの系列
NegTokenInit ::= SEQUENCE {
mechTypes [0] MechTypeList OPTIONAL,
reqFlags [1] ContextFlags OPTIONAL,
mechToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL
}
NegTokenInit:、:= 系列mechTypes[0]MechTypeListの任意の、そして、reqFlags[1]ContextFlags任意のmechToken[2]八重奏は任意の状態で任意のmechListMIC[3]八重奏ストリングを結びます。
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
confFlag (5),
integFlag (6)
}
ContextFlags:、:= ビット列delegFlag(0)、mutualFlag(1)、replayFlag(2)、sequenceFlag(3)、anonFlag(4)、confFlag(5)、integFlag(6)
negTokenInit
Negotiation token sent by the initiator to the target, which
contains, for the first token sent, one or more security mechanisms
supported by the initiator (as indicated in the field mechTypes)
and the service options (reqFlags) that are requested to establish
the context. The context flags should be filled in from the
req_flags parameter of init_sec_context().
創始者によって目標に送られたnegTokenInit Negotiationトークンは、オプションが文脈を確立するよう要求されている(reqFlags)であると創始者(分野mechTypesにみられるように)とサービスでサポートしました。目標は最初のトークンが発信したので1台以上のセキュリティー対策を含みます。 文脈旗はイニット_秒_文脈()に関するreq_フラッグ変数から記入されるべきです。
The mechToken field is optional for the first token sent that all
target implementations would not have to support. However for those
targets that do support piggybacking the initial mechToken, an
optimistic negotiation response is possible. Otherwise the
mechToken is used to carry the tokens specific to the mechanism
selected.
すべての目標実装がサポートする必要はない送られた最初のトークンに、mechToken分野は任意です。 しかしながら、便乗が初期のmechTokenであるとサポートするそれらの目標において、楽観的な交渉応答は可能です。 さもなければ、mechTokenは、選択されたメカニズムに特定のトークンを運ぶのに使用されます。
Baize & Pinkas Standards Track [Page 7] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[7ページ]。
The mechListMIC is an optional field. In the case that the chosen
mechanism supports integrity, the initiator may optionally include
a mechListMIC which is the result of a GetMIC of the MechTypes in
the initial NegTokenInit and return GSS_S_COMPLETE.
mechListMICは任意の分野です。 選ばれたメカニズムが保全をサポートして、創始者は、任意に初期のNegTokenInitのMechTypesのGetMICの結果であるmechListMICを入れて、_GSS_S COMPLETEを返すかもしれません。
When the chosen mechanism uses an odd number of messages, the final
mechanism token will be sent from the initiator to the acceptor. In
this case, there is a tradeoff between using the optimal number of
messages, or using an additional message from the acceptor to the
initiator in order to give the initiator assurance that no
modification of the initiator's mechanism list occurred. The
implementation can choose which tradeoff to make (see section 4.2.2
for further details for the processing of that field).
選ばれたメカニズムがメッセージの奇数を使用すると、最終的なメカニズムトークンを創始者からアクセプタに送るでしょう。 この場合、メッセージの最適の数を使用するか、または創始者のメカニズムリストの変更が全く起こらなかったという創始者保証を与えるのにアクセプタから創始者まで追加メッセージを使用するとき、見返りがあります。 実装は、どの見返りを作ったらよいかを選ぶことができます(さらに詳しい明細についてはその分野の処理に関してセクション4.2.2を見てください)。
NegTokenTarg ::= SEQUENCE {
negResult [0] ENUMERATED {
accept_completed (0),
accept_incomplete (1),
reject (2) } OPTIONAL,
supportedMech [1] MechType OPTIONAL,
responseToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL
}
NegTokenTarg:、:= 系列negResult[0]ENUMERATEDが_完成した(0)を受け入れて、_不完全な(1)、廃棄物(2)を受け入れる、OPTIONAL、supportedMech[1]MechType OPTIONAL、responseToken[2]OCTET STRING OPTIONAL、mechListMIC[3]OCTET STRING OPTIONAL
negTokenTarg
Negotiation token returned by the target to the initiator which
contains, for the first token returned, a global negotiation result
and the security mechanism selected (if any).
negTokenTarg Negotiationトークンは創始者への最初のトークンが戻ったので包括的交渉結果と(もしあれば)選択されたセキュリティー対策を含む目標で戻りました。
negResult
The result accept_completed indicates that a context has been
successfully established, while the result accept_incomplete
indicates that additional token exchanges are needed.
_完成されて、結果が受け入れるnegResultは、文脈が首尾よく確立されたのを示します、結果は、_が不完全であると受け入れますが。追加トークン交換が必要であることを示します。
Note: For the case where (a) a single-token context setup is
used and (b) the preferred mechanism does not support the
integrity facility which would cause a mechListMIC to be
generated and enclosed, this feature allows to make a
difference between a mechToken sent by the initiator but not
processed by the target (accept_incomplete) and a mechToken
sent by the initiator and processed by the target
(accept_completed).
以下に注意してください。 (a) ただ一つのトークン文脈セットアップが使用されていて、(b) 都合のよいメカニズムがmechListMICが生成されて、同封されることを引き起こす保全施設をサポートしないところでは、この特徴が許容するケースのために、創始者によって送られますが、目標によって処理されなかった(_が不完全であると受け入れます)mechTokenとmechTokenの違いを作るのは、創始者で発信して、目標によって処理されました(_が完成していると受け入れてください)。
For those targets that support piggybacking the initial mechToken,
an optimistic negotiation response is possible and includes in that
case a responseToken which may continue the authentication exchange
(e.g. when mutual authentication has been requested or when
unilateral authentication requires several round trips). Otherwise
便乗が初期のmechTokenであるとサポートするそれらの目標のために、楽観的な交渉応答は、可能であり、その場合認証交換を続けるかもしれないresponseTokenを含んでいます(例えば、互いの認証がいつ要求されるか、そして、または一方的な認証はいついくつかの周遊旅行を必要としますか)。 そうではありません
Baize & Pinkas Standards Track [Page 8] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[8ページ]。
the responseToken is used to carry the tokens specific to the
mechanism selected. For subsequent tokens (if any) returned by the
target, negResult, and supportedMech are not present.
responseTokenは、選択されたメカニズムに特定のトークンを運ぶのに使用されます。 目標、negResult、およびsupportedMechによって返されたその後のトークン(もしあれば)が存在していないので。
For the last token returned by the target, the mechListMIC, when
present, is a MIC computed over the MechTypes using the selected
mechanism.
存在しているとき、目標によって返された最後のトークンのために、mechListMICはMechTypesの上で選択されたメカニズムを使用することで計算されたMICです。
negResult
Result of the negotiation exchange, specified by the target.
目標によって指定された交渉交換のnegResult Result。
This can be either :
これはどちらかであるかもしれません:
accept_completed
The target accepts the preferred security mechanism,
and the context is established for the target or,
または受諾、_完成されて、目標が都合のよいセキュリティー対策を受け入れて、文脈が目標のために確立される。
accept_incomplete
The target accepts one of the proposed security
mechanisms and further exchanges are necessary, or,
_が不完全であると受け入れてください。または目標が提案されたセキュリティー対策の1つを受け入れて、さらなる交換が必要である。
reject
The target rejects all the proposed security
mechanisms.
目標を拒絶してください。すべての提案されたセキュリティー対策を拒絶します。
supportedMech
This field has to be present when negResult is "accept_completed"
or "accept_incomplete". It is a choice from the mechanisms offered
by the initiator.
supportedMech This分野は、negResultが「_が完成していると受け入れてください」であるときに、存在しているか、または「_が不完全であると受け入れなければなりません」。 それは創始者によって提供されたメカニズムからの選択です。
responseToken
This field may be used either to transmit the response to the
mechToken when sent by the initiator and when the first mechanism
from the list has been selected by the target or to carry the
tokens specific to the selected security mechanism.
responseToken This分野は、創始者によって送られて、リストからの最初のメカニズムが目標によって選択されたとき、mechTokenへの応答を伝えるか、または選択されたセキュリティー対策に特定のトークンを運ぶのに使用されるかもしれません。
mechListMIC
If the selected mechanism is capable of integrity protection, this
field must be present in the last message of the negotiation,
(i.e., when the underlying mechanism returns a non-empty token and
a major status of GSS_S_COMPLETE); it contains the result of a
GetMIC of the MechTypes field in the initial NegTokenInit. It
allows to verify that the list initially sent by the initiator has
been received unmodified by the target.
mechListMIC If、選択されたメカニズムは保全保護ができる、この分野は交渉に関する最後のメッセージと、(発症機序はすなわち、いつ非空のトークンを返しますか、そして、_GSS_S COMPLETEの主要な状態)に存在していなければなりません。 それは初期のNegTokenInitのMechTypes分野のGetMICの結果を含んでいます。 それは、初めは創始者によって送られたリストが目標によって変更されていなく受け取られたことを確かめるのを許容します。
Baize & Pinkas Standards Track [Page 9] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[9ページ]。
3.2.2. Processing of mechListMIC.
3.2.2. mechListMICの処理。
If the mechanism selected by the negotiation does not support integrity, then no mechListMIC is included, otherwise a mechListMIC must be used and validated as indicated below.
交渉で選択されたメカニズムが保全をサポートしないならどんなmechListMICも含まれていなくて、さもなければ、以下に示すようにmechListMICを使用されて、有効にしなければなりません。
If the mechanism supports integrity and uses an even number of messages, then the target must compute a MIC as described above, and send this in the final NegTokenTarg along with the final mechToken. The initiator when receiving the last token must require that the mechListMIC field be present and valid. In the absence of a valid mechListMIC, the negotiation must fail as if the last context establishment token was invalid.
メカニズムが保全をサポートして、メッセージの偶数を使用するなら、目標は、上で説明されるようにMICを計算して、最終的なmechTokenに伴う最終的なNegTokenTargでこれを送らなければなりません。 最後のトークンを受けるとき、創始者は、mechListMIC分野が現在であって有効であることを必要としなければなりません。 有効なmechListMICが不在のとき、まるで最後の文脈設立トークンが無効であるかのように交渉は失敗しなければなりません。
In the case that the chosen mechanism supports integrity and uses an odd number of messages, the final mechanism token will be sent from the initiator to the target. In this case, there is a tradeoff between using the optimal number of messages, or using an additional message from the target to the initiator in order to give the initiator assurance that no modification of the initiator's mechanism list occurred. The implementation can choose which tradeoff to make.
選ばれたメカニズムが保全をサポートして、メッセージの奇数を使用して、最終的なメカニズムトークンを創始者から目標に送るでしょう。 この場合、メッセージの最適の数を使用するか、または創始者のメカニズムリストの変更が全く起こらなかったという創始者保証を与えるのに目標から創始者まで追加メッセージを使用するとき、見返りがあります。 実装は、どの見返りを作ったらよいかを選ぶことができます。
When generating the final NegTokenInit message, the NegTokenInit may optionally include a mechListMIC which is the result of a GetMIC of the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE. The target must check the presence of the MIC computed over the mechList sent in the initial NegTokenInit. Three cases may then be considered:
最終的なNegTokenInitメッセージを生成するとき、NegTokenInitは任意に初期のNegTokenInitのMechTypesのGetMICの結果であるmechListMICを含んで、_GSS_S COMPLETEを返すかもしれません。 目標は初期のNegTokenInitで送られたmechListの上で計算されたMICの存在をチェックしなければなりません。 次に、3つのケースが考えられるかもしれません:
1) If the mechListMIC is present and correct, then
GSS_S_COMPLETE is returned to the target with no token; the
context is established by the target.
1) mechListMICが現在であって正しいなら、トークンなしでGSS_S_COMPLETEを目標に返します。 文脈は目標によって確立されます。
2) If the mechListMIC is present but invalid, then the context
establishment must fail. An error major status code is
returned to the target.
2) mechListMICが現在ですが、無効であるなら、文脈設立は行き詰まらなければなりません。 誤りの主要なステータスコードを目標に返します。
3) If the mechListMIC is not included in the final NegTokenInit,
then GSS_S_COMPLETE must be returned to the target with a
token. This token must be a NegTokenTarg, with a MIC included
as described above, and no responseToken. The application will
then send this token back to the initiator, which must verify
that the mechListMIC field is present and valid.
3) 最終的なNegTokenInitにmechListMICを含んでいないなら、GSS_S_COMPLETEをトークンがある目標に返さなければなりません。 このトークンは上で説明されるように含まれていたMICにもかかわらず、responseTokenがないNegTokenTargであるに違いありません。 そして、アプリケーションはこのトークンを創始者に送り返すでしょう。(その創始者は、mechListMIC分野が現在であって有効であることを確かめなければなりません)。
Baize & Pinkas Standards Track [Page 10] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[10ページ]。
Note: If the MIC was originally sent by the initiator, but
thenafter deleted by an attacker, the target will send
back a token according to the description above, but the
initiator will be unable to process that returned token
and the context establishment must then fail.
以下に注意してください。 創始者はその返されたトークンを処理できないでしょう、そして、MICが元々創始者、しかし、攻撃者によって削除されたthenafterによって送られたなら、上の記述によると、目標はトークンを返送するでしょうが、次に、文脈設立は行き詰まらなければなりません。
4. EXAMPLES : SECURITY MECHANISM NEGOTIATION
4. 例: セキュリティー対策交渉
Here are some examples of security mechanism negotiation between an initiator (I) and a target (T).
ここに、創始者(I)と目標(T)とのセキュリティー対策交渉に関するいくつかの例があります。
4.1. Initial steps
4.1. 初期段階
(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
(I) 2セキュリティー対策がタイプするサポート(GSS-MECH1とGSS-MECH2)。
(I) invokes GSS_Init_sec_context() with :
(I)はGSS_Init_秒_文脈()を呼び出します:
Input
mech_type = OID for negotiation mechanism or NULL, if the
negotiation mechanism is the default mechanism.
入力mech_タイプは交渉メカニズムがデフォルトメカニズムであるなら交渉メカニズムかNULLのためにOIDと等しいです。
Output
major_status = GSS_S_CONTINUE_NEEDED
output_token = negTokenInit
S_CONTINUE_が必要とした出力GSS主要な_状態=_は_トークン=negTokenInitを出力しました。
The negotiation token (negTokenInit) contains two security mechanisms
with :
mechType = GSS-MECH1 or
mechType = GSS-MECH2
交渉トークン(negTokenInit)は以下で2台のセキュリティー対策を含んでいます。 mechTypeがGSS-MECH1と等しいです、またはmechTypeはGSS-MECH2と等しいです。
(I) sends to (T) the negotiation token.
(I)は(T) 交渉トークンに発信します。
4.2 Successful negotiation steps
4.2 うまくいっている交渉ステップ
(T) supports GSS-MECH2 (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with :
(T) サポートGSS-MECH2(T)は(T)がGSS_Accept_秒_文脈()を呼び出す(I)から交渉トークン(negTokenInit)を受けます:
Input
input_token = negTokenInit
入力入力_トークン=negTokenInit
Output
major_status = GSS_S_CONTINUE_NEEDED
output_token = negTokenTarg
S_CONTINUE_が必要とした出力GSS主要な_状態=_は_トークン=negTokenTargを出力しました。
The negotiation token (negTokenTarg) contains :
negResult = accept (the negotiation result)
supportedMech : mechType = GSS-MECH2
交渉トークン(negTokenTarg)は以下を含んでいます。 negResult=は(交渉結果)supportedMechを受け入れます: mechTypeはGSS-MECH2と等しいです。
Baize & Pinkas Standards Track [Page 11] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[11ページ]。
(T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with :
(T) (I)(I)への交渉トークン(negTokenTarg)がGSS_Init_秒_文脈()を呼び出すリターン:
Input
input_token = negTokenTarg
入力入力_トークン=negTokenTarg
Output
major_status = GSS_S_COMPLETE
output_token = initialContextToken (initial context token
for GSS-MECH2)
mech_type = GSS-MECH2
出力主要な_状態=GSS_S_COMPLETE出力_トークン=initialContextToken(GSS-MECH2のための初期の文脈トークン)mech_は=GSS-MECH2をタイプします。
The subsequent steps are security mechanism specific, and work as specified in [1]. The output tokens from the security mechanism are encapsulated in a NegTokenTarg message (with the supportedMech field omitted, and the mechListMIC included with the last token).
その後のステップは、セキュリティー対策特有であり、[1]で指定されるように利きます。 セキュリティー対策からの出力トークンはNegTokenTargメッセージ(supportedMech分野が省略されて、mechListMICが最後のトークンで含まれている)でカプセル化されます。
4.3. Failed negotiation steps
4.3. 不成功に終わった商談ステップ
(T) supports GSS-MECH3. (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with :
(T)はGSS-MECH3をサポートします。 (T) (T)がGSS_Accept_秒_文脈()を呼び出す(I)から交渉トークン(negTokenInit)を受けます:
Input
input_token = negTokenInit
入力入力_トークン=negTokenInit
Output
major_status = GSS_S_BAD_MECH
output_token = negTokenTarg
出力主要な_状態=GSS_S_BAD_MECH出力_トークン=negTokenTarg
The negotiation token (negTokenTarg) contains :
交渉トークン(negTokenTarg)は以下を含んでいます。
negResult = reject (the negotiation result)
negResult=廃棄物(交渉結果)
(T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with :
(T) (I)(I)への交渉トークン(negTokenTarg)がGSS_Init_秒_文脈()を呼び出すリターン:
Input
input_token = negTokenTarg
入力入力_トークン=negTokenTarg
Output
major_status = GSS_S_BAD_MECH
_出力主要な_状態=GSS_S BAD_MECH
The security context establishment has failed.
セキュリティ文脈設立は行き詰まりました。
Baize & Pinkas Standards Track [Page 12] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[12ページ]。
4.4 Successful Negotiation with preferred mechanism info
4.4 都合のよいメカニズムインフォメーションがあるうまくいっているNegotiation
(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
(I) 2セキュリティー対策がタイプするサポート(GSS-MECH1とGSS-MECH2)。
(I) invokes GSS_Init_sec_context() with :
(I)はGSS_Init_秒_文脈()を呼び出します:
Input
mech_type = OID for negotiation mechanism or NULL, if the
negotiation mechanism is the default mechanism.
入力mech_タイプは交渉メカニズムがデフォルトメカニズムであるなら交渉メカニズムかNULLのためにOIDと等しいです。
Output
major_status = GSS_S_CONTINUE_NEEDED
output_token = negTokenInit
S_CONTINUE_が必要とした出力GSS主要な_状態=_は_トークン=negTokenInitを出力しました。
The negotiation token (negTokenInit) contains two security mechanisms
with :
mechType = GSS-MECH1 or
mechType = GSS-MECH2
交渉トークン(negTokenInit)は以下で2台のセキュリティー対策を含んでいます。 mechTypeがGSS-MECH1と等しいです、またはmechTypeはGSS-MECH2と等しいです。
mechToken = output_token from GSS_Init_sec_context
( first mechType) as described in [1]
mechTokenは中で説明されるようにGSS_Init_秒_文脈(最初に、mechType)から出力_トークンと等しいです。[1]
(I) sends to (T) the negotiation token.
(I)は(T) 交渉トークンに発信します。
(T) supports GSS-MECH1. (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with :
(T)はGSS-MECH1をサポートします。 (T) (T)がGSS_Accept_秒_文脈()を呼び出す(I)から交渉トークン(negTokenInit)を受けます:
Input
input_token = negTokenInit
入力入力_トークン=negTokenInit
Output
major_status = GSS_S_CONTINUE_NEEDED
output_token = negTokenTarg
S_CONTINUE_が必要とした出力GSS主要な_状態=_は_トークン=negTokenTargを出力しました。
The negotiation token (negTokenTarg) contains :
negResult = accept (the negotiation result)
supportedMech : mechType = GSS-MECH1
交渉トークン(negTokenTarg)は以下を含んでいます。 negResult=は(交渉結果)supportedMechを受け入れます: mechTypeはGSS-MECH1と等しいです。
mechToken = output_token from
GSS_Accept_sec_context(mechToken )
mechTokenはGSS_Accept_秒_文脈から出力_トークンと等しいです。(mechToken)
(T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with :
(T) (I)(I)への交渉トークン(negTokenTarg)がGSS_Init_秒_文脈()を呼び出すリターン:
Input
input_token = negTokenTarg
入力入力_トークン=negTokenTarg
Baize & Pinkas Standards Track [Page 13] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[13ページ]。
Output
major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed
output_token = ContextToken (initial or subsequent context token
for GSS-MECH1)
mech_type = GSS-MECH1
CONTINUE_が必要とした出力主要な_状態=GSS_S_COMPLETEかGSS_S_は必要に応じて_トークン=ContextToken(GSS-MECH1のための初期の、または、その後の文脈トークン)mech_タイプ=GSS-MECH1を出力しました。
Specific implementations of the protocol can support the optimistic negotiation by completing the security context establishment using the agreed upon mechanism as described in [1]. As described above in section 5.2, the output tokens from the security mechanisms are encapsulated in a NegTokenTarg message (with the negResult and supportedMech fields omitted, and the mechListMIC included with the last token).
プロトコルの特定の実装は、[1]で説明されるようにメカニズムで同意を使用することでセキュリティ文脈設立を終了することによって、楽観的な交渉をサポートすることができます。 上でセクション5.2で説明されるように、セキュリティー対策からの出力トークンはNegTokenTargメッセージ(negResultとsupportedMech分野が省略されて、mechListMICが最後のトークンで含まれている)でカプセル化されます。
5. SECURITY CONSIDERATIONS
5. セキュリティ問題
When the mechanism selected by the target from the list supplied by the initiator supports integrity protection, then the negotiation is protected.
目標によって創始者によって提供されたリストから選択されたメカニズムが、保全が保護であるとサポートすると、交渉は保護されます。
When one of the mechanisms proposed by the initiator does not support integrity protection, then the negotiation is exposed to all threats a non secured service is exposed. In particular, an active attacker can force to use a security mechanism which is not the common preferred one (when multiple security mechanisms are shared between peers) but which is acceptable anyway to the target.
創始者によって提案されたメカニズムの1つが、保全が保護であるとサポートしないと、交渉は非機密保護しているサービスが暴露されるすべての脅威に暴露されます。 特に、活発な攻撃者は一般的な都合のよい方(複数のセキュリティー対策が同輩の間で共有されるとき)ではありませんが、とにかく目標に許容できるセキュリティー対策は強制的に使用させることができます。
In any case, the communicating peers may be exposed to the denial of service threat.
どのような場合でも、交信している同輩はサービスの脅威の否定にさらされるかもしれません。
6. ACKNOWLEDGMENTS
6. 承認
Acknowledgments are due to Stephen Farrell of SSE, Marc Horowitz of Stonecast, John Linn of RSA Laboratories, Piers McMahon of Platinum Technology, Tom Parker of ICL and Doug Rosenthal of EINet, for reviewing earlier versions of this document and for providing useful inputs. Acknowledgments are also due to Peter Brundrett of Microsoft for his proposal for an optimistic negotiation, and for Bill Sommerfeld of Epilogue Technology for his proposal for protecting the negotiation.
承認はSSEのスティーブン・ファレルとStonecastのマーク・ホロビッツとRSA研究所のジョン・リンとPlatinum TechnologyのPiersマクマホンとICLのトム・パーカーとこのドキュメントの以前のバージョンを見直して、役に立つ入力を提供するためのEINetのダグRosenthalのためです。 承認は楽観的な交渉のための彼の提案、および交渉を保護するための彼の提案のためのEpilogue Technologyのビル・ゾンマーフェルトのためのマイクロソフトのピーターBrundrettのもためです。
Baize & Pinkas Standards Track [Page 14] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[14ページ]。
APPENDIX A
付録A
GSS-API NEGOTIATION SUPPORT API
GSS-API交渉サポートAPI
In order to provide to a GSS-API caller (either the initiator or the target or both) the ability to choose among the set of supported mechanisms a reduced set of mechanisms for negotiation, two additional APIs are defined:
交渉のためにGSS-API訪問者(創始者か目標か両方のどちらか)にサポートしているメカニズムのセットの中で減少しているセットのメカニズムを選ぶ能力を提供するために、2つの追加APIが定義されます:
GSS_Get_neg_mechs() indicates the set of security mechanisms available on the local system to the caller for negotiation.
GSS_Get_neg_mechs()は訪問者にとって、ローカルシステムで交渉に利用可能なセキュリティー対策のセットを示します。
GSS_Set_neg_mechs() specifies the set of security mechanisms to be used on the local system by the caller for negotiation.
交渉にローカルシステムで訪問者によって使用されるように、GSS_Set_neg_mechs()はセキュリティー対策のセットを指定します。
A.1. GSS_Set_neg_mechs call
A.1。 GSS_Set_neg_mechs呼び出し
Input:
cred_handle CREDENTIAL HANDLE
- NULL specifies default credentials
mech_set SET OF OBJECT IDENTIFIER
以下を入力してください。 信用_ハンドルCREDENTIAL HANDLE--NULLはデフォルト資格証明書mech_セットSET OF OBJECT IDENTIFIERを指定します。
Outputs:
major_status INTEGER,
minor_status INTEGER,
出力: 主要な_状態INTEGER、小さい方の_状態INTEGER
Return major_status codes :
GSS_S_COMPLETE indicates that the set of security mechanisms
available for negotiation has been set to mech_set. GSS_S_FAILURE
indicates that the requested operation could not be performed for
reasons unspecified at the GSS-API level.
主要な_ステータスコードを返してください: GSS_S_COMPLETEは、交渉に利用可能なセキュリティー対策のセットが_が設定したmechに設定されたのを示します。 GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったのを示します。
Allows callers to specify the set of security mechanisms that may be negotiated with the credential identified by cred_handle. This call is intended for support of specialised callers who need to restrict the set of negotiable security mechanisms from the set of all security mechanisms available to the caller (based on available credentials). Note that if more than one mechanism is specified in mech_set, the order in which those mechanisms are specified implies a relative mechanism preference for the target.
訪問者が信用_ハンドルによって特定される資格証明書と交渉されるかもしれないセキュリティー対策のセットを指定するのを許容します。 この呼び出しは訪問者(利用可能な資格証明書に基づいている)にとって、利用可能なすべてのセキュリティー対策のセットから交渉可能なセキュリティー対策のセットを制限する必要がある専門化している訪問者のサポートのために意図します。 1つ以上のメカニズムが_が設定したmechで指定されるなら、それらのメカニズムが指定されるオーダーが目標のための相対的なメカニズム優先を含意することに注意してください。
Baize & Pinkas Standards Track [Page 15] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[15ページ]。
A.2. GSS_Get_neg_mechs call
A.2。 GSS_Get_neg_mechs呼び出し
Input:
cred_handle CREDENTIAL HANDLE
- NULL specifies default credentials
以下を入力してください。 信用_ハンドルCREDENTIAL HANDLE--NULLはデフォルト資格証明書を指定します。
Outputs:
major_status INTEGER,
minor_status INTEGER,
mech_set SET OF OBJECT IDENTIFIER
出力: 主要な_状態INTEGER、小さい方の_状態INTEGER、mech_セットSET OF OBJECT IDENTIFIER
Return major_status codes :
GSS_S_COMPLETE indicates that the set of security mechanisms
available for negotiation has been returned in
mech_option_set.
GSS_S_FAILURE indicates that the requested operation could not
be performed for reasons unspecified at the GSS-API level.
主要な_ステータスコードを返してください: GSS_S_COMPLETEは、交渉に利用可能なセキュリティー対策のセットが_が設定したmech_オプションで返されたのを示します。 GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったのを示します。
Allows callers to determine the set of security mechanisms available for negotiation with the credential identified by cred_handle. This call is intended for support of specialised callers who need to reduce the set of negotiable security mechanisms from the set of supported security mechanisms available to the caller (based on available credentials).
訪問者が信用_ハンドルによって特定される資格証明書との交渉に利用可能なセキュリティー対策のセットを決定するのを許容します。 この呼び出しは訪問者(利用可能な資格証明書に基づいている)にとって、利用可能なサポートしているセキュリティー対策のセットから交渉可能なセキュリティー対策のセットを減少させる必要がある専門化している訪問者のサポートのために意図します。
Note: The GSS_Indicate_mechs() function indicates the full set of mechanism types available on the local system. Since this call has no input parameter, the returned set is not necessarily available for all credentials.
以下に注意してください。 GSS_Indicate_mechs()機能はローカルシステムに手があいているメカニズムタイプのフルセットを示します。 この呼び出しには入力パラメタが全くないので、返されたセットは必ずすべての資格証明書に利用可能であるというわけではありません。
REFERENCES
参照
[1] Linn, J., "Generic Security Service Application Program
Interface", RFC 2078, January 1997.
[1] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース」、RFC2078、1997年1月。
[2] Standard ECMA-206, "Association Context Management including
Security Context Management", December 1993. Available on
http://www.ecma.ch
[2]の標準のECMA-206、「Security Context Managementを含む協会Context Management」、1993年12月。 http://www.ecma.ch では、利用可能です。
Baize & Pinkas Standards Track [Page 16] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[16ページ]。
AUTHORS' ADDRESSES
作者のアドレス
Eric Baize Bull - 300 Concord Road Billerica, MA 01821 - USA
エリックベーズ雄牛--Roadビルリカ、300Concord MA 01821--米国
Phone: +1 978 294 61 37 Fax: +1 978 294 61 09 EMail: Eric.Baize@bull.com
以下に電話をしてください。 +1 978 294、61 37、Fax: +1 61 09がメールする978 294: Eric.Baize@bull.com
Denis Pinkas Bull Rue Jean-Jaures BP 68 78340 Les Clayes-sous-Bois - FRANCE
デニスピンカス雄牛悔悟ジーン-ジョーレスBP68 78340レスClayes小銭Bois--フランス
Phone: +33 1 30 80 34 87 Fax: +33 1 30 80 33 21 EMail: Denis.Pinkas@bull.net
以下に電話をしてください。 +33 1 30 80 34 87、Fax: +33 1 30 80 33 21はメールされます: Denis.Pinkas@bull.net
Baize & Pinkas Standards Track [Page 17] RFC 2478 GSS-API Negotiation Mechanism December 1998
ベーズとピンカスStandardsはGSS-API交渉メカニズム1998年12月にRFC2478を追跡します[17ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Baize & Pinkas Standards Track [Page 18]
ベーズとピンカス標準化過程[18ページ]
一覧
スポンサーリンク
