[要約] RFC 2478は、シンプルで安全なGSS-APIネゴシエーションメカニズムに関する規格です。その目的は、異なるセキュリティメカニズム間の認証とセキュリティコンテキストの確立を容易にすることです。
Network Working Group E. Baize
Request for Comments: 2478 D. Pinkas
Category: Standards Track Bull
December 1998
The Simple and Protected GSS-API Negotiation Mechanism
シンプルで保護されたGSS-API交渉メカニズム
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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）のセキュリティネゴシエーションメカニズムを指定します。
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.
ここで定義されているシンプルで保護されたGSS-API交渉メカニズムは、GSS-APIを有効にするオブジェクト識別子iso.org.dod.internet.security.mechanism.snego（1.3.6.1.5.5.2）で表される疑似セキュリティメカニズムです。ピアは、資格情報が共通の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.
これにより、異なるセキュリティメカニズム、特定のセキュリティメカニズム内の異なるオプション、またはいくつかのセキュリティメカニズムの異なるオプションをネゴシエートできます。
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交渉メカニズムは、GSS-API仕様[1]で開発された概念を使用します。交渉データは、コンテキストレベルのトークンにカプセル化されます。したがって、GSS-APIの呼び出し元は、ネゴシエーショントークンの存在を認識する必要はなく、新しい疑似セキュリティメカニズムのみを認識する必要があります。ネゴシエーションフェーズでエラーが発生すると、メジャーステータスコードGSS_S_BAD_MECHが返されます。
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つのセキュリティメカニズムが提案された場合、それはイニシエータによってサポートまたは選択された（付録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.
- イニシエーターによっていくつかのセキュリティメカニズムが提案されている場合、それらはイニシエーターによってサポートまたは選択された（付録Aで定義されている追加のAPIが使用されている場合）セキュリティメカニズムのセットを表します。
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).
イニシエーターによって送信される最初のネゴシエーショントークンには、メカニズムの順序付きリスト、選択されたメカニズムでサポートされるオプションのセット（委任、再生、confフラグなど）と、オプションでイニシエーターの目的のメカニズムの初期セキュリティトークン（つまり、リストの最初）。
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.
ターゲットによって送信される最初のネゴシエーショントークンには、ネゴシエーションの結果（accept_completed、accept_incomplete、またはreject）が含まれ、受け入れの場合は、合意されたセキュリティメカニズムが含まれます。イニシエーターの最初に提案されたメカニズムが選択された場合、イニシエーターからの初期セキュリティトークンへの応答も含まれます。最初のメカニズムがターゲットに受け入れられる場合、それが存在する場合、イニシエーターの目的のメカニズムの初期セキュリティトークンに応答する必要があります。ただし、これが不可能な場合、ターゲットは単にそれを無視して、最初の応答から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で）運ばれます。
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_sec_contextを呼び出しますが、シンプルで保護されたGSS-APIネゴシエーションメカニズムの使用を（明示的に、ネゴシエーションメカニズムを使用して、またはデフォルトを受け入れることにより）要求されます。 ;
(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_NEEDEDステータスを示します。
(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_sec_contextを呼び出してトークンを預けます。ターゲット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_sec_context()は、片側認証または相互認証が実行されたときに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_sec_context()はGSS_S_CONTINUE_NEEDEDステータスを示します。
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_sec_context()は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_sec_contextの呼び出しを通じてトークンを預けます。
GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED, GSS_S_COMPLETE or GSS_S_BAD_MECH status.
GSS_Init_sec_context()は、GSS_S_CONTINUE_NEEDED、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.
GSS_S_BAD_MICステータスは、選択されたメカニズムが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.
ネゴシエーショントークンが拒否結果を運ぶ場合、コンテキストの確立は不可能です。たとえば、ターゲットがイニシエーターが提案したメカニズムタイプをサポートしていない場合、拒否が発生します。メカニズムネゴシエーション手順が失敗した場合、mech_type出力パラメーター値はネゴシエーションメカニズムタイプです。
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_NEEDEDステータスは、ネゴシエーショントークンが受け入れ結果を運んでいるときに返され、選択したメカニズムのコンテキスト確立を完了するために、さらにトークンを転送する必要があります。その場合、GSS_Init_sec_context()は、初期コンテキストトークンをoutput_tokenとして返します（選択したメカニズムのコンテキストトークンは、そのoutput_token内にカプセル化されています）。
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.
次に、イニシエーターはoutput_tokenをターゲットに送信します。その後、セキュリティコンテキストの初期化は、選択されたメカニズムの標準GSS-API規則に従って続行されます。イニシエータとターゲットの両方に対してGSS_S_COMPLETEが返されるまで、選択されたメカニズムのトークンがカプセル化されます。 GSS_S_CONTINUE_NEEDEDが返された場合、mech_type出力パラメーターはまだ有効ではありません。
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 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.
GSS_S_COMPLETEが返されると、mech_type出力パラメーターは選択されたメカニズムを示します。最後のネゴシエーショントークンにMICが含まれていない場合、イニシエーターGSS-API実装は、返された/選択されたメカニズムが最初に送信されたメカニズムのリストにあることを確認し、選択されたメカニズムが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.
コンテキスト確立用の* _req_flag入力パラメーターは、* _ state出力パラメーターと同様に、選択されたメカニズムに関連していることに注意してください。つまり、これらのパラメータは交渉プロセス自体には適用されません。
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_availフラグをテストできます。このフラグが設定されている場合、交渉が保護されたことを示します。
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_credがdesired_mechsとしてネゴシエーションメカニズムで呼び出されると、実装固有のデフォルトの資格が使用されてネゴシエーションが続行されます。その後、システム管理者がローカルで指定した一連のメカニズムをネゴシエーションに使用できます。呼び出し側が独自に選択したい場合は、追加のAPIを使用する必要があります（付録Aを参照）。
MechType::= OBJECT IDENTIFIER
mechType Each security mechanism is as defined in [1].
mechType各セキュリティメカニズムは、[1]で定義されています。
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構文に従います。初期ネゴシエーショントークンのセキュリティメカニズムは、オブジェクト識別子iso.org.dod.internet.security.mechanism.snego（1.3.6.1.5.5.2）によって識別されます。
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」フィールドの構文を指定します。メカニズムのネゴシエーション中、「innerContextToken」フィールドには、DERエンコーディング規則を使用してエンコードされた、下記のASN.1構造「NegociationToken」が含まれています。
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenTarg [1] NegTokenTarg }
MechTypeList ::= SEQUENCE OF MechType
NegTokenInit ::= SEQUENCE {
mechTypes [0] MechTypeList OPTIONAL,
reqFlags [1] ContextFlags OPTIONAL,
mechToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL
}
ContextFlags ::= BIT STRING {
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イニシエーターによってターゲットに送信されたネゴシエーショントークンには、送信された最初のトークンについて、イニシエーターによってサポートされている1つ以上のセキュリティメカニズム（フィールドmechTypesに示されている）と、サービスの確立を要求されるサービスオプション（reqFlags）環境。コンテキストフラグは、init_sec_context()のreq_flagsパラメータから入力する必要があります。
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は、選択されたメカニズムに固有のトークンを運ぶために使用されます。
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 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ターゲットからイニシエーターに返されたネゴシエーショントークン。最初に返されたトークンに対して、グローバルネゴシエーションの結果と選択されたセキュリティメカニズム（存在する場合）が含まれます。
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結果accept_completedはコンテキストが正常に確立されたことを示し、結果accept_incompleteは追加のトークン交換が必要であることを示します。
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（accept_incomplete）、およびイニシエーターによって送信され、ターゲットによって処理されたmechToken（accept_completed）。
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 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.
最初のmechTokenのピギーバックをサポートするターゲットの場合、オプティミスティックネゴシエーション応答が可能であり、その場合、認証交換を継続する可能性があるresponseTokenが含まれます（たとえば、相互認証が要求された場合、または一方的な認証で複数のラウンドトリップが必要な場合）。それ以外の場合、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ターゲットによって指定された交渉交換の結果。
This can be either :
これは次のいずれかです。
accept_completed The target accepts the preferred security mechanism, and the context is established for the target or,
accept_completedターゲットが優先セキュリティメカニズムを受け入れ、コンテキストがターゲットに対して確立されている、または
accept_incomplete The target accepts one of the proposed security mechanisms and further exchanges are necessary, or,
accept_incompleteターゲットは提案されたセキュリティメカニズムの1つを受け入れ、さらなる交換が必要です。または、
reject The target rejects all the proposed security mechanisms.
rejectターゲットは、提案されたすべてのセキュリティメカニズムを拒否します。
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このフィールドは、negResultが「accept_completed」または「accept_incomplete」の場合に存在する必要があります。これは、イニシエーターが提供するメカニズムからの選択です。
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このフィールドは、イニシエーターによって送信されたとき、およびリストからの最初のメカニズムがターゲットによって選択されたときに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選択したメカニズムが整合性保護に対応している場合、このフィールドはネゴシエーションの最後のメッセージに存在する必要があります（つまり、基礎となるメカニズムが空ではないトークンとGSS_S_COMPLETEのメジャーステータスを返す場合）。最初のNegTokenInitのMechTypesフィールドのGetMICの結果が含まれます。イニシエーターによって最初に送信されたリストが、ターゲットによって変更されずに受信されたことを確認できます。
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）mechListMICが最後のNegTokenInitに含まれていない場合、GSS_S_COMPLETEがトークンとともにターゲットに返される必要があります。このトークンは、上記のようにMICが含まれ、responseTokenがないNegTokenTargでなければなりません。次に、アプリケーションはこのトークンをイニシエーターに送り返します。イニシエーターは、mechListMICフィールドが存在し、有効であることを確認する必要があります。
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が最初にイニシエーターによって送信された後、攻撃者によって削除された場合、ターゲットは上記の説明に従ってトークンを送り返しますが、イニシエーターは返されたトークンを処理できず、コンテキストの確立は失敗する必要があります。
Here are some examples of security mechanism negotiation between an initiator (I) and a target (T).
以下は、イニシエーター（I）とターゲット（T）の間のセキュリティメカニズムネゴシエーションの例です。
(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_sec_context()を次のように呼び出します：
Input mech_type = OID for negotiation mechanism or NULL, if the negotiation mechanism is the default mechanism.
入力mech_type =ネゴシエーションメカニズムのOID、またはネゴシエーションメカニズムがデフォルトのメカニズムの場合はNULL。
Output major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenInit
出力major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenInit
The negotiation token (negTokenInit) contains two security mechanisms with : mechType = GSS-MECH1 or mechType = GSS-MECH2
ネゴシエーショントークン（negTokenInit）には、mechType = GSS-MECH1またはmechType = GSS-MECH2の2つのセキュリティメカニズムが含まれています。
(I) sends to (T) the negotiation token.
（I）（T）に交渉トークンを送信します。
(T) supports GSS-MECH2 (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with :
（T）はGSS-MECH2をサポートします（T）は（I）からネゴシエーショントークン（negTokenInit）を受信します（T）はGSS_Accept_sec_context()を呼び出します：
Input input_token = negTokenInit
入力input_token = negTokenInit
Output major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenTarg
出力major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenTarg
The negotiation token (negTokenTarg) contains : negResult = accept (the negotiation result) supportedMech : mechType = GSS-MECH2
ネゴシエーショントークン（negTokenTarg）に含まれるもの：negResult = accept（ネゴシエーション結果）supportedMech：mechType = GSS-MECH2
(T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with :
（T）ネゴシエーショントークン（negTokenTarg）を（I）に返します（I）はGSS_Init_sec_context()を次のように呼び出します：
Input input_token = negTokenTarg
入力input_token = negTokenTarg
Output major_status = GSS_S_COMPLETE output_token = initialContextToken (initial context token for GSS-MECH2) mech_type = GSS-MECH2
出力major_status = GSS_S_COMPLETE output_token = initialContextToken（GSS-MECH2の初期コンテキストトークン）mech_type = 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は最後のトークンに含まれます）。
(T) supports GSS-MECH3. (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with :
（T）GSS-MECH3をサポートします。 （T）が（I）からネゴシエーショントークン（negTokenInit）を受け取る（T）がGSS_Accept_sec_context()を呼び出す：
Input input_token = negTokenInit
入力input_token = negTokenInit
Output major_status = GSS_S_BAD_MECH output_token = negTokenTarg
出力major_status = GSS_S_BAD_MECH output_token = negTokenTarg
The negotiation token (negTokenTarg) contains :
ネゴシエーショントークン（negTokenTarg）には以下が含まれます。
negResult = reject (the negotiation result)
negResult = reject（交渉結果）
(T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with :
（T）ネゴシエーショントークン（negTokenTarg）を（I）に返します（I）はGSS_Init_sec_context()を次のように呼び出します：
Input input_token = negTokenTarg
入力input_token = negTokenTarg
Output major_status = GSS_S_BAD_MECH
出力major_status = GSS_S_BAD_MECH
The security context establishment has failed.
セキュリティコンテキストの確立に失敗しました。
(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_sec_context()を次のように呼び出します：
Input mech_type = OID for negotiation mechanism or NULL, if the negotiation mechanism is the default mechanism.
入力mech_type =ネゴシエーションメカニズムのOID、またはネゴシエーションメカニズムがデフォルトのメカニズムの場合はNULL。
Output major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenInit
出力major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenInit
The negotiation token (negTokenInit) contains two security mechanisms with : mechType = GSS-MECH1 or mechType = GSS-MECH2
ネゴシエーショントークン（negTokenInit）には、mechType = GSS-MECH1またはmechType = GSS-MECH2の2つのセキュリティメカニズムが含まれています。
mechToken = output_token from GSS_Init_sec_context ( first mechType) as described in [1]
[1]で説明されている、mechToken = GSS_Init_sec_contextからのoutput_token（最初のmechType）
(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）が（I）からネゴシエーショントークン（negTokenInit）を受け取る（T）がGSS_Accept_sec_context()を呼び出す：
Input input_token = negTokenInit
入力input_token = negTokenInit
Output major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenTarg
出力major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenTarg
The negotiation token (negTokenTarg) contains : negResult = accept (the negotiation result) supportedMech : mechType = GSS-MECH1
ネゴシエーショントークン（negTokenTarg）に含まれるもの：negResult = accept（ネゴシエーション結果）supportedMech：mechType = GSS-MECH1
mechToken = output_token from GSS_Accept_sec_context(mechToken )
mechToken = GSS_Accept_sec_context（mechToken）からのoutput_token
(T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with :
（T）ネゴシエーショントークン（negTokenTarg）を（I）に返します（I）はGSS_Init_sec_context()を次のように呼び出します：
Input input_token = negTokenTarg
入力input_token = negTokenTarg
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
必要に応じて、major_status = GSS_S_COMPLETEまたはGSS_S_CONTINUE_NEEDEDを出力します。output_token= ContextToken（GSS-MECH1の初期または後続のコンテキストトークン）mech_type = 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は最後のトークンに含まれます）。
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.
いずれの場合でも、通信するピアはサービス拒否の脅威にさらされる可能性があります。
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のスティーブンファレル、ストーンキャストのマークホロウィッツ、RSAラボラトリーズのジョンリン、プラチナテクノロジーのピアスマクマホン、ICLのトムパーカー、およびEINetのダグローゼンタールに感謝します。また、楽観的な交渉の提案に対するマイクロソフトのピーターブランドレットと、交渉を保護するための彼の提案に対するエピローグテクノロジーのビルソマーフェルドによる謝辞も必要です。
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()は、ネゴシエーションのために呼び出し元がローカルシステムで使用するセキュリティメカニズムのセットを指定します。
Input: cred_handle CREDENTIAL HANDLE - NULL specifies default credentials mech_set SET OF OBJECT IDENTIFIER
入力：cred_handle CREDENTIAL HANDLE-NULLはデフォルトの資格情報を指定しますmech_set SET OF OBJECT IDENTIFIER
Outputs: major_status INTEGER, minor_status INTEGER,
出力：major_status INTEGER、minor_status 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.
major_statusコードを返す：GSS_S_COMPLETEは、ネゴシエーションに使用できるセキュリティメカニズムのセットがmech_setに設定されていることを示します。 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.
呼び出し側が、cred_handleで識別される資格情報とネゴシエートできる一連のセキュリティメカニズムを指定できるようにします。この呼び出しは、呼び出し側が利用できるすべてのセキュリティメカニズムのセットから、交渉可能なセキュリティメカニズムのセットを（利用可能な資格情報に基づいて）制限する必要がある専門の呼び出し側のサポートを目的としています。 mech_setで複数のメカニズムが指定されている場合、それらのメカニズムが指定されている順序は、ターゲットの相対的なメカニズム設定を意味します。
Input: cred_handle CREDENTIAL HANDLE - NULL specifies default credentials
入力：cred_handle CREDENTIAL HANDLE-NULLはデフォルトの資格情報を指定します
Outputs: major_status INTEGER, minor_status INTEGER, mech_set SET OF OBJECT IDENTIFIER
出力：major_status INTEGER、minor_status INTEGER、mech_set 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_option_setに返されたことを示します。 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).
呼び出し側が、cred_handleで識別される資格情報とのネゴシエーションに使用できるセキュリティメカニズムのセットを決定できるようにします。この呼び出しは、（利用可能な資格情報に基づいて）呼び出し元が使用できるサポートされているセキュリティメカニズムのセットから交渉可能なセキュリティメカニズムのセットを減らす必要がある専門の呼び出し元のサポートを目的としています。
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] Linn、J。、「Generic Security Service Application Program Interface」、RFC 2078、1997年1月。
[2] Standard ECMA-206, "Association Context Management including Security Context Management", December 1993. Available on http://www.ecma.ch AUTHORS' ADDRESSES
[2]標準ECMA-206、「セキュリティコンテキスト管理を含むアソシエーションコンテキスト管理」、1993年12月。http：//www.ecma.ch著者のアドレスで入手可能
Eric Baize Bull - 300 Concord Road Billerica, MA 01821 - USA
エリックベイズブル-300 Concord Road Billerica、MA 01821-USA
Phone: +1 978 294 61 37
Fax: +1 978 294 61 09
EMail: Eric.Baize@bull.com
Denis Pinkas Bull Rue Jean-Jaures BP 68 78340 Les Clayes-sous-Bois - FRANCE
Denis Pinkas Bull Rue Jean-Jaures BP 68 78340 Les Clayes-sous-Bois-フランス
Phone: +33 1 30 80 34 87
Fax: +33 1 30 80 33 21
EMail: Denis.Pinkas@bull.net
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。