RFC 4752 - The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism 日本語訳

URL : https://tools.ietf.org/html/rfc4752
タイトル : RFC 4752 - ケルベロスV5（「GSSAPI」）簡易認証セキュリティー層（SASL）メカニズム
翻訳編集 : 自動生成

Network Working Group                                   A. Melnikov, Ed.
Request for Comments: 4752                                         Isode
Obsoletes: 2222                                            November 2006
Category: Standards Track

                       The Kerberos V5 ("GSSAPI")
       Simple Authentication and Security Layer (SASL) Mechanism

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）IETFトラスト（2006）。

Abstract

抽象

The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface (GSS-API) Kerberos V5 in the SASL.

簡易認証セキュリティー層（SASL）は、接続ベースのプロトコルに認証サポートを追加するためのフレームワークです。この文書では、一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）SASLでのKerberos V5を使用するための方法を説明しています。

This document replaces Section 7.2 of RFC 2222, the definition of the "GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222.

この文書は、RFC 2222のセクション7.2、「GSSAPI」SASLメカニズムの定義を置き換えます。この文書では、一緒にRFC 4422で、RFC 2222を廃止します。

Table of Contents

   1. Introduction ....................................................2
      1.1. Relationship to Other Documents ............................2
   2. Conventions Used in This Document ...............................2
   3. Kerberos V5 GSS-API Mechanism ...................................2
      3.1. Client Side of Authentication Protocol Exchange ............3
      3.2. Server Side of Authentication Protocol Exchange ............4
      3.3. Security Layer .............................................6
   4. IANA Considerations .............................................7
   5. Security Considerations .........................................7
   6. Acknowledgements ................................................8
   7. Changes since RFC 2222 ..........................................8
   8. References ......................................................8
      8.1. Normative References .......................................8
      8.2. Informative References .....................................9

1. Introduction

1. はじめに

This specification documents currently deployed Simple Authentication and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5 [KERBEROS] Generic Security Service Application Program Interface ([GSS-API]) mechanism [RFC4121]. The authentication sequence is described in Section 3. Note that the described authentication sequence has known limitations, in particular, it lacks channel bindings and the number of round-trips required to complete authentication exchange is not minimal. SASL WG is working on a separate document that should address these limitations.

この仕様書は、現在のKerberos V5 [KERBEROS]一般的なセキュリティサービスアプリケーションプログラムインターフェイス（[GSS-API]）メカニズム[RFC4121]をサポートする簡易認証セキュリティー層（SASL [SASL]）メカニズムを導入しました。認証シーケンスを説明する認証シーケンスは、制限を知っていることを第3注記に記載され、具体的には、チャネルバインディングを欠いており、認証交換を完了するために必要なラウンドトリップの数は最小ではありません。 SASL WGは、これらの制限に対処すべきである別の文書に取り組んでいます。

1.1. Relationship to Other Documents

1.1. その他の文書との関係

This document, together with RFC 4422, obsoletes RFC 2222 in its entirety. This document replaces Section 7.2 of RFC 2222. The remainder is obsoleted as detailed in Section 1.2 of RFC 4422.

この文書では、一緒にRFC 4422で、全体的にRFC 2222を廃止します。この文書は、RFC 4422のセクション1.2に詳述されるように残りは廃止され、RFC 2222のセクション7.2に取って代わります。

2. Conventions Used in This Document

この文書で使用される2.表記

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].

キーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、およびこのドキュメントの「要件レベルを示すためにRFCsにおける使用のためのキーワード」[キーワード]で定義されるように解釈されるべきである「MAY」。

3. Kerberos V5 GSS-API Mechanism

3.ケルベロスV5 GSS-APIメカニズム

The SASL mechanism name for the Kerberos V5 GSS-API mechanism [RFC4121] is "GSSAPI". Though known as the SASL GSSAPI mechanism, the mechanism is specifically tied to Kerberos V5 and GSS-API's Kerberos V5 mechanism.

ケルベロスV5 GSSAPIメカニズム[RFC4121]のためのSASLメカニズム名は「GSSAPI」です。 SASL GSSAPIメカニズムとして知られているが、メカニズムは、具体的にKerberos V5およびGSSAPIのKerberos V5機構に接続されています。

The GSSAPI SASL mechanism is a "client goes first" SASL mechanism; i.e., it starts with the client sending a "response" created as described in the following section.

GSSAPI SASLメカニズムは、SASL機構「クライアントが最初に行く」です。すなわち、それは次のセクションで説明するように作成した「応答」を送信するクライアントを起動します。

The implementation MAY set any GSS-API flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy.

実装は、そのセキュリティポリシーを強制するために実施するために必要であるとして、この仕様書に記載されていない任意のGSS-APIのフラグまたは引数を設定することができます。

Note that major status codes returned by GSS_Init_sec_context() or GSS_Accept_sec_context() other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED cause authentication failure. Major status codes returned by GSS_Unwrap() other than GSS_S_COMPLETE (without any additional supplementary status codes) cause authentication and/or security layer failure.

GSS_S_COMPLETEまたはGSS_S_CONTINUE_NEEDED原因認証失敗以外の主要なステータスコードは、もしGSS_Init_sec_contextによって返されたことを（）またはのgss_accept_sec_context（）に注意してください。（追加の補助的なステータスコードなし）GSS_S_COMPLETE以外はgss_unwrap（によって返された主な状態コード）原因認証および/またはセキュリティ層の障害。

3.1. Client Side of Authentication Protocol Exchange

3.1. 認証プロトコル交換のクライアント側

The client calls GSS_Init_sec_context, passing in input_context_handle of 0 (initially), mech_type of the Kerberos V5 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name equal to output_name from GSS_Import_Name called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of "service@hostname" where "service" is the service name specified in the protocol's profile, and "hostname" is the fully qualified host name of the server. When calling the GSS_Init_sec_context, the client MUST pass the integ_req_flag of TRUE (**). If the client will be requesting a security layer, it MUST also supply to the GSS_Init_sec_context a mutual_req_flag of TRUE, and a sequence_req_flag of TRUE. If the client will be requesting a security layer providing confidentiality protection, it MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE. The client then responds with the resulting output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client should expect the server to issue a token in a subsequent challenge. The client must pass the token to another call to GSS_Init_sec_context, repeating the actions in this paragraph.

クライアントは、0（初期）のinput_context_handle渡し、もしGSS_Init_sec_contextを呼び出し、のGSS_C_NT_HOSTBASED_SERVICE（*）のinput_name_typeとinput_name_stringと呼ばれるケルベロスV5 GSS-APIメカニズム[KRB5GSS]、NULLのchan_binding、及びGSS_Import_Nameからoutput_nameに等しいtarg_nameのメカニズム種別」サービスは、『プロトコルのプロファイルに指定されたサービス名で、『ホスト名』は、サーバーの完全修飾ホスト名である「』サービス@ホスト名。もしGSS_Init_sec_contextを呼び出す場合、クライアントはTRUE（**）のinteg_req_flagを渡す必要があります。クライアントは、セキュリティ層を要求する場合、それはまた、もしGSS_Init_sec_contextにTRUEのmutual_req_flag、及びTRUEのsequence_req_flagを供給しなければなりません。クライアントは、機密性保護を提供するセキュリティ層を要求する場合、それはまた、もしGSS_Init_sec_contextにTRUEのconf_req_flagを供給しなければなりません。その後、クライアントは結果としてのoutput_tokenで応答します。もしGSS_Init_sec_contextがGSS_S_CONTINUE_NEEDEDを返す場合、クライアントは、サーバがその後のチャレンジでトークンを発行することを期待するべきです。クライアントは、この段落でアクションを繰り返し、もしGSS_Init_sec_contextへの別の呼び出しにトークンを渡す必要があります。

(*) Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but only when they have a priori knowledge that the servers support alternate name types. Otherwise clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.

（*）クライアントは、サーバのアクセプターの名前をインポートするGSS_C_NT_HOSTBASED_SERVICE以外の名前のタイプを使用することができるが、彼らは事前知識を持っている場合にのみ、サーバーは、代替名の種類をサポートしています。そうしないと、クライアントは、アクセプターの名前をインポートするためGSS_C_NT_HOSTBASED_SERVICEを使用しなければなりません。

(**) Note that RFC 2222 [RFC2222] implementations will not work with GSS-API implementations that require integ_req_flag to be true. No implementations of RFC 1964 [KRB5GSS] or RFC 4121 [RFC4121] that require integ_req_flag to be true are believed to exist and it is expected that any future update to [RFC4121] will require that

（**）の実装が真実であるとinteg_req_flagを必要とGSS-APIの実装では動作しませんというRFC 2222 [RFC2222]を注意してください。 [RFC4121]に任意の将来のアップデートがそれを必要とすることは事実であることがinteg_req_flagを必要RFC 1964 [KRB5GSS]またはRFC 4121のいかなる実装[RFC4121]は存在すると考えられていないとそれが期待されています

integrity be available even in not explicitly requested by the application.

整合性にも明示的にアプリケーションが要求しないで利用できます。

When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines the context to ensure that it provides a level of protection permitted by the client's security policy. In particular, if the integ_avail flag is not set in the context, then no security layer can be offered or accepted.

もしGSS_Init_sec_contextがGSS_S_COMPLETEを返すと、クライアントは、クライアントのセキュリティポリシーで許可保護のレベルを提供することを確実にするためのコンテキストを調べます。 integ_availフラグがコンテキストに設定されていない場合、特に、その後はセキュリティ層を提供しないか、または受け入れることができます。

If the conf_avail flag is not set in the context, then no security layer with confidentiality can be offered or accepted. If the context is acceptable, the client takes the following actions: If the last call to GSS_Init_sec_context returned an output_token, then the client responds with the output_token, otherwise the client responds with no data. The client should then expect the server to issue a token in a subsequent challenge. The client passes this token to GSS_Unwrap and interprets the first octet of resulting cleartext as a bit-mask specifying the security layers supported by the server and the second through fourth octets as the maximum size output_message the server is able to receive (in network byte order). If the resulting cleartext is not 4 octets long, the client fails the negotiation. The client verifies that the server maximum buffer is 0 if the server does not advertise support for any security layer.

conf_availフラグがコンテキストで設定されていない場合は、機密性とは、セキュリティの層が提供されていないか、受け入れることができます。コンテキストが許容できる場合、クライアントは次の動作を行います。もしGSS_Init_sec_contextへの最後の呼び出しがたoutput_tokenを返した場合、クライアントはのoutput_tokenで応答し、そうでない場合、クライアントはデータなしで応答します。次に、クライアントは、サーバがその後のチャレンジでトークンを発行することを期待するべきです。クライアントはgss_unwrapにこのトークンを渡し、ネットワークバイト順で（サーバ、サーバが受信することができるoutput_message最大サイズである第4オクテットを介して第2によってサポートされるセキュリティ層を指定するビットマスクとして平文を得られたの最初のオクテットを解釈します）。結果の平文が4つのオクテット長でない場合、クライアントは交渉に失敗しました。クライアントは、サーバがすべてのセキュリティレイヤをサポートすることを通知しない場合は、サーバーの最大バッファが0であることを確認します。

The client then constructs data, with the first octet containing the bit-mask specifying the selected security layer, the second through fourth octets containing in network byte order the maximum size output_message the client is able to receive (which MUST be 0 if the client does not support any security layer), and the remaining octets containing the UTF-8 [UTF8] encoded authorization identity. (Implementation note: The authorization identity is not terminated with the zero-valued (%x00) octet (e.g., the UTF-8 encoding of the NUL (U+0000) character)). The client passes the data to GSS_Wrap with conf_flag set to FALSE and responds with the generated output_message. The client can then consider the server authenticated.

クライアントは、次に、選択されたセキュリティレイヤ、ネットワークバイト順で、クライアントは、クライアントがない場合は0でなければならない（受信することができるoutput_message最大サイズを含む第4オクテットを介して第2の指定ビットマスクを含む最初のオクテットと、データを構築します）いずれかのセキュリティレイヤをサポートし、UTF8 [UTF8]を含む残りのオクテットは、認可IDをエンコードされません。（実装上の注意：認可IDがゼロ値（％X00）オクテットNUL（U + 0000）文字の（例えば、UTF-8エンコーディング）で終端されていません）。クライアントはFALSEに設定conf_flagとにGSS_Wrapにデータを渡し、生成されたoutput_messageで応答します。次に、クライアントは、認証されたサーバーを考慮することができます。

3.2. Server Side of Authentication Protocol Exchange

3.2. 認証プロトコル交換のサーバー側

A server MUST NOT advertise support for the "GSSAPI" SASL mechanism described in this document unless it has acceptor credential for the Kerberos V GSS-API mechanism [KRB5GSS].

それは[KRB5GSS]ケルベロスV GSSAPIメカニズムのアクセプタの資格を持っていない限り、サーバーは、この文書で説明する「GSSAPI」SASLメカニズムをサポートすることを通知してはなりません。

The server passes the initial client response to GSS_Accept_sec_context as input_token, setting input_context_handle to 0 (initially), chan_binding of NULL, and a suitable acceptor_cred_handle (see below). If GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server returns the generated output_token to the client in challenge and passes the resulting response to another call to GSS_Accept_sec_context, repeating the actions in this paragraph.

サーバは、NULLのchan_binding、および適切なacceptor_cred_handle（下記参照）、（最初に）0にinput_context_handle設定、入力トークンとして場合gss_accept_sec_contextに初期クライアントレスポンスを渡します。場合gss_accept_sec_contextはGSS_S_CONTINUE_NEEDEDを返す場合、サーバーは、この段落でアクションを繰り返し、挑戦でクライアントに生成されたoutput_tokenを返し、場合gss_accept_sec_contextに別のコールに結果の応答を渡します。

Servers SHOULD use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the Object Identifier (OID) of the Kerberos V5 GSS-API mechanism [KRB5GSS](*). Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle. Servers MAY use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred for the server's principal name(s) (**) and the Kerberos V5 GSS-API mechanism [KRB5GSS].

サーバは、Kerberos V5 GSS-APIメカニズム[KRB5GSS]（*）のGSS_C_NO_NAMEのたdesired_nameとオブジェクト識別子（OID）のためには、gss_acquire_cred又はGSS_Add_credを呼び出すことによって得られたクレデンシャルを使用すべきです。サーバーは、アクセプター資格ハンドルとしてGSS_C_NO_CREDENTIALを使用するかもしれません。サーバは、サーバのプリンシパル名（複数可）（**）とKerberos V5 GSS-APIメカニズム[KRB5GSS]のためには、gss_acquire_credまたはGSS_Add_credを呼び出すことによって取得資格を使用するかもしれません。

(*) Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of GSS-API mechanism as an input parameter. The OID set can be created by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can be freed by calling the GSS_Release_oid_set.

（*）GSS_Add_cred異なりは、gss_acquire_credは、入力パラメータとしてGSS-API機構のOIDセットを使用します。 OIDセットはGSS_Create_empty_OID_setとGSS_Add_OID_set_memberを使用して作成することができます。それはGSS_Release_oid_setを呼び出すことによって解放することができます。

(**) Use of server's principal names having GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format, where "service" is the service name specified in the protocol's profile, and "hostname" is the fully qualified host name of the server, is RECOMMENDED. The server name is generated by calling GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of "service@hostname".

GSS_C_NT_HOSTBASED_SERVICE名のタイプと「サービス」は、プロトコルのプロファイルに指定されたサービス名で、「ホスト名」は、サーバーの完全修飾ホスト名です「サービス@ホスト名」形式を有するサーバのプリンシパル名の（**）を使用しますお勧めします。サーバー名はGSS_C_NT_HOSTBASED_SERVICEのinput_name_typeと「サービス@ホスト名」のinput_name_stringでGSS_Import_nameを呼び出すことによって生成されます。

Upon successful establishment of the security context (i.e., GSS_Accept_sec_context returns GSS_S_COMPLETE), the server SHOULD verify that the negotiated GSS-API mechanism is indeed Kerberos V5 [KRB5GSS]. This is done by examining the value of the mech_type parameter returned from the GSS_Accept_sec_context call. If the value differs, SASL authentication MUST be aborted.

セキュリティコンテキストの成功確立時に（すなわち、場合gss_accept_sec_contextはGSS_S_COMPLETEを返す）、サーバは、ネゴシエートされたGSS-API機構が実際にKerberos V5 [KRB5GSS]であることを確認してください。これは、場合gss_accept_sec_contextの呼び出しから返されたmech_typeパラメータの値を調べることによって行われます。値が異なる場合は、SASL認証が中止されなければなりません。

Upon successful establishment of the security context and if the server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor credential handle, the server SHOULD also check using the GSS_Inquire_context that the target_name used by the client matches either

セキュリティコンテキストの確立に成功したら、サーバーがアクセプター資格ハンドルを作成するためにGSS_C_NO_NAME / GSS_C_NO_CREDENTIALを使用した場合、サーバーは、クライアントが使用するTARGET_NAMEはどちらかと一致することをGSS_Inquire_contextを使用してチェックする必要があります

- the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax, where "service" is the service name specified in the application protocol's profile,

- 「サービス」は、アプリケーションプロトコルのプロファイルに指定されたサービス名ですGSS_C_NT_HOSTBASED_SERVICE「サービス@ホスト名」名の構文、

または

- the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two-component principal where the first component matches the service name specified in the application protocol's profile.

- 最初のコンポーネントは、アプリケーション・プロトコルのプロファイルに指定されたサービス名と一致する二成分主体のGSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS]名の構文。

When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server examines the context to ensure that it provides a level of protection permitted by the server's security policy. In particular, if the integ_avail flag is not set in the context, then no security layer can be offered or accepted. If the conf_avail flag is not set in the context, then no security layer with confidentiality can be offered or accepted.

場合gss_accept_sec_contextはGSS_S_COMPLETEを返すと、サーバーは、サーバーのセキュリティポリシーで許可されて保護レベルを提供することを確実にするためのコンテキストを調べます。 integ_availフラグがコンテキストに設定されていない場合、特に、その後はセキュリティ層を提供しないか、または受け入れることができます。 conf_availフラグがコンテキストで設定されていない場合は、機密性とは、セキュリティの層が提供されていないか、受け入れることができます。

If the context is acceptable, the server takes the following actions: If the last call to GSS_Accept_sec_context returned an output_token, the server returns it to the client in a challenge and expects a reply from the client with no data. Whether or not an output_token was returned (and after receipt of any response from the client to such an output_token), the server then constructs 4 octets of data, with the first octet containing a bit-mask specifying the security layers supported by the server and the second through fourth octets containing in network byte order the maximum size output_token the server is able to receive (which MUST be 0 if the server does not support any security layer). The server must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE and issue the generated output_message to the client in a challenge.

コンテキストが許容可能である場合、サーバーは次の動作を行います。場合gss_accept_sec_contextへの最後の呼び出しがたoutput_tokenを返した場合、サーバーは、チャレンジで、それをクライアントに返し、データのないクライアントからの応答を期待しています。たoutput_tokenが返された（そのようなたoutput_tokenに対するクライアントからの応答を受信した後）、サーバは、サーバによってサポートされるセキュリティ層を指定するビットマスクを含む最初のオクテットと、データの4つのオクテットを構成するか否かとネットワークバイト順に（サーバが任意のセキュリティ層をサポートしていない場合は0である必要があります）サーバが受信することができたoutput_token最大サイズを含む第4オクテットを介して第2。次に、サーバは挑戦にFALSEに設定conf_flagとにGSS_Wrapに平文を渡すと、クライアントに生成されたoutput_messageを発行する必要があります。

The server must then pass the resulting response to GSS_Unwrap and interpret the first octet of resulting cleartext as the bit-mask for the selected security layer, the second through fourth octets as the maximum size output_message the client is able to receive (in network byte order), and the remaining octets as the authorization identity. The server verifies that the client has selected a security layer that was offered and that the client maximum buffer is 0 if no security layer was chosen. The server must verify that the src_name is authorized to act as the authorization identity. After these verifications, the authentication process is complete. The server is not expected to return any additional data with the success indicator.

サーバは、次にはgss_unwrapに得られた応答を渡し、ネットワークバイト順で（選択されたセキュリティ層のためのビットマスクは、クライアントが受信することができるoutput_message最大サイズである第4オクテットを介して第2の結果として得られる平文の最初のオクテットを解釈しなければなりません）、および認可IDとして残りのオクテット。サーバーは、クライアントが提供され、何のセキュリティ層を選択しなかった場合、クライアントの最大バッファが0であるということでしたセキュリティレイヤを選択したことを確認します。サーバーはsrc_nameが認可IDとして行動する権限をされていることを確認する必要があります。これらの検証後、認証プロセスが完了します。サーバは、成功の指標と追加データを返すことが期待されていません。

3.3. Security Layer

3.3. セキュリティ層

The security layers and their corresponding bit-masks are as follows:

次のようにセキュリティの層とそれに対応するビット・マスクは、次のとおりです。

          1 No security layer
          2 Integrity protection.
            Sender calls GSS_Wrap with conf_flag set to FALSE
          4 Confidentiality protection.
            Sender calls GSS_Wrap with conf_flag set to TRUE

Other bit-masks may be defined in the future; bits that are not understood must be negotiated off.

他のビットマスクは、将来に定義されてもよいです。理解されていないビットがオフネゴシエートされなければなりません。

When decoding any received data with GSS_Unwrap, the major_status other than the GSS_S_COMPLETE MUST be treated as a fatal error.

gss_unwrap有する任意の受信されたデータを復号する際に、GSS_S_COMPLETE以外major_statusは、致命的なエラーとして扱われなければなりません。

Note that SASL negotiates the maximum size of the output_message to send. Implementations can use the GSS_Wrap_size_limit call to determine the corresponding maximum size input_message.

SASLを送信するためにoutput_messageの最大サイズをネゴシエートすることに注意してください。実装は対応する最大サイズinput_messageを決定するためには、gss_wrap_size_limitコールを使用することができます。

4. IANA Considerations

4. IANAの考慮事項

IANA modified the existing registration for "GSSAPI" as follows:

IANAは、次のように「GSSAPI」のために既存の登録を変更しました：

Family of SASL mechanisms: NO

SASLメカニズムのファミリ：NO

SASL mechanism name: GSSAPI

SASLメカニズム名：GSSAPI

Security considerations: See Section 5 of RFC 4752

セキュリティの考慮事項：RFC 4752のセクション5を参照してください。

Published specification: RFC 4752

公開された仕様：RFC 4752

Person & email address to contact for further information: Alexey Melnikov <Alexey.Melnikov@isode.com>

人とEメールアドレスは、詳細のために連絡する：アレクセイ・メルニコフ<Alexey.Melnikov@isode.com>

Intended usage: COMMON

意図している用法：COMMON

Owner/Change controller: iesg@ietf.org

所有者/変更コントローラ：iesg@ietf.org

Additional information: This mechanism is for the Kerberos V5 mechanism of GSS-API.

追加情報：このメカニズムは、GSS-APIのケルベロスV5メカニズムのためです。

5. Security Considerations

5.セキュリティについての考慮事項

Security issues are discussed throughout this memo.

セキュリティの問題は、このメモ中で議論されています。

When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service.

input_name_stringを構築する場合、クライアントは、安全でないか、信頼できないディレクトリサービスを使用して、サーバーの完全修飾ドメイン名を正規化すべきではありません。

For compatibility with deployed software, this document requires that the chan_binding (channel bindings) parameter to GSS_Init_sec_context and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API support for channel bindings. GSS-API channel bindings in SASL is expected to be supported via a new GSS-API family of SASL mechanisms (to be introduced in a future document).

展開ソフトウェアとの互換性のために、この文書は、それゆえ、チャネルバインディングのGSS-APIサポートの使用を許可しない、もしGSS_Init_sec_context及び場合gss_accept_sec_contextにchan_binding（チャネルバインディング）パラメータがNULLであることを必要とします。 SASLでGSS-APIのチャネルバインディングは、（将来の文書に導入される）SASLメカニズムの新しいGSS-APIファミリーを介してサポートされることが期待されます。

Additional security considerations are in the [SASL] and [GSS-API] specifications. Additional security considerations for the GSS-API mechanism can be found in [KRB5GSS] and [KERBEROS].

追加のセキュリティ上の考慮事項は[SASL]と[GSS-API]仕様です。 GSS-APIメカニズムのための追加のセキュリティ上の考慮事項は、[KRB5GSS]と[KERBEROS]で見つけることができます。

6. Acknowledgements

6.謝辞

This document replaces Section 7.2 of RFC 2222 [RFC2222] by John G. Myers. He also contributed significantly to this revision.

この文書では、ジョン・G.マイヤーズによってRFC 2222 [RFC2222]のセクション7.2を置き換えます。彼はまた、この改正に大きく貢献しました。

Lawrence Greenfield converted text of this document to the XML format.

ローレンス・グリーンフィールドは、XML形式に、この文書のテキストを変換します。

Contributions of many members of the SASL mailing list are gratefully acknowledged, in particular comments from Chris Newman, Nicolas Williams, Jeffrey Hutzelman, Sam Hartman, Mark Crispin, and Martin Rex.

SASLメーリングリストの多くのメンバーの貢献は感謝クリス・ニューマン、ニコラス・ウィリアムズ、ジェフリーHutzelman、サム・ハートマン、マーク・クリスピン、そしてマーティン・レックスから特にコメントで、認知されています。

7. Changes since

7.からの変更点

RFC 2078 [RFC2078] specifies the version of GSS-API used by RFC 2222 [RFC2222], which provided the original version of this specification. That version of GSS-API did not provide the integ_integ_avail flag as an input to GSS_Init_sec_context. Instead, integrity was always requested. RFC 4422 [SASL] requires that when possible, the security layer negotiation be integrity protected. To meet this requirement and as part of moving from RFC 2078 [RFC2078] to RFC 2743 [GSS-API], this specification requires that clients request integrity from GSS_Init_sec_context so they can use GSS_Wrap to protect the security layer negotiation. This specification does not require that the mechanism offer the integrity security layer, simply that the security layer negotiation be wrapped.

RFC 2078 [RFC2078]は、本明細書の元のバージョンを提供RFC 2222 [RFC2222]で使用GSS-APIのバージョンを指定します。 GSS-APIのこのバージョンは、もしGSS_Init_sec_contextへの入力としてinteg_integ_availフラグを提供していませんでした。代わりに、整合性が常に要求されました。 RFC 4422 [SASL]は、可能な場合、セキュリティ層の交渉が完全性を保護することが必要です。この要件を満たすために、RFC 2078から移行の一環として、RFC 2743に[RFC2078] [GSS-API]には、この仕様は、彼らがセキュリティ層の交渉を保護するためにGSS_Wrapを使用できるように、クライアントがもしGSS_Init_sec_contextからの整合性を要求することが必要です。この仕様は、メカニズムは、セキュリティ層の折衝がラップするだけであること、整合性のセキュリティ層を提供することを必要としません。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

[GSS-API] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.

[GSS-API]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。

[KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.

[KERBEROS]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 4120、2005年7月。

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.

[KRB5GSS]リン、J.、 "Kerberosバージョン5 GSS-APIメカニズム"、RFC 1964、1996年6月。

[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.

[RFC4121]朱、L.、Jaganathan、K.、およびS.ハートマン、 "Kerberosバージョン5の汎用セキュリティサービスアプリケーションプログラムインタフェース（GSS-API）メカニズム：バージョン2"、RFC 4121、2005年7月。

[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.

[SASL]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。

[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[UTF8] Yergeau、F.、 "UTF8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。

8.2. Informative References

8.2. 参考文献

[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.

[RFC2078]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース、バージョン2"、RFC 2078、1997年1月。

[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.

[RFC2222]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。

Editor's Address

編集者の住所

Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK

アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国

EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/

電子メール：Alexey.Melnikov@isode.com URI：http://www.melnikov.ca/

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（2006）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。