[要約] RFC 4752は、Kerberos V5のGSSAPI SASLメカニズムに関する規格です。このRFCの目的は、Kerberosを使用してセキュアな認証とセッションの確立を提供するための仕組みを定義することです。
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
Kerberos V5（ "gssapi"）シンプルな認証とセキュリティ層（SASL）メカニズム
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 IETF Trust (2006).
Copyright（c）The IETF Trust（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.
Simple Authentication and Security Layer（SASL）は、接続ベースのプロトコルに認証サポートを追加するためのフレームワークです。このドキュメントでは、SASLでジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）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.
このドキュメントは、「GSSAPI」SASLメカニズムの定義であるRFC 2222のセクション7.2を置き換えます。このドキュメントは、RFC 4422とともに、Obsoletes 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
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は、これらの制限に対処する別のドキュメントに取り組んでいます。
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とともに、obsoletes RFC 2222全体があります。このドキュメントは、RFC 2222のセクション7.2に置き換えられます。残りは、RFC 4422のセクション1.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].
このドキュメントの「必須」、「必要はない」、「そうはない」、「すべきではない」、「必要はない」は、「要件レベルを示すためにRFCで使用するためのキーワード」で定義されていると解釈されます[キーワード]。
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.
Kerberos V5 GSS-APIメカニズム[RFC4121]のSASLメカニズム名は「GSSAPI」です。SASL GSSAPIメカニズムとして知られていますが、メカニズムはKerberos V5およびGSS-APIの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_init_sec_context（）またはgss_cect_sec_context（）によってgss_sec_cectex_context（）によって返された主要なステータスコードは、GSS_S_completeまたはgss_s_s_continue_needed原因認証障害です。GSS_S_Complete以外のGSS_UNWRAP（）によって返される主要なステータスコード（追加の補足ステータスコードなし）は、認証および/またはセキュリティレイヤーの障害を引き起こします。
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.
クライアントはGSS_INIT_SEC_CONTEXTを呼び出し、入力_Context_handleを0（最初に）、Kerberos V5 GSS-APIメカニズム[KRB5GSS]、NULLのCHAN_BINDING、およびTARG_NAMEのMECH_TYPEをGSSS_NAME_NAMEの出力_NAMEと呼んだoutput_nameの出力に等しいtarg_nameを呼び出します。 ervice（*）およびinput_name_stringの "service@hostname "where" service "は、プロトコルのプロファイルで指定されたサービス名であり、「hostname」はサーバーの完全な資格のあるホスト名です。gss_init_sec_contextを呼び出すとき、クライアントはtrue（**）のinteg_req_flagを渡す必要があります。クライアントがセキュリティレイヤーを要求する場合、GSS_INIT_SEC_CONTEXTにTrueの相互_REQ_FLAG、およびTrueのSequence_Req_flagにも供給する必要があります。クライアントが機密保護を提供するセキュリティレイヤーを要求する場合、gss_init_sec_contextにconf_req_flagにも供給する必要があります。次に、クライアントは結果のoutput_tokenで応答します。gss_init_sec_contextがgss_s_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_HOSTBASET_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 integrity be available even in not explicitly requested by the application.
（**）RFC 2222 [RFC2222]実装は、INTEG_REQ_FLAGを真である必要があるGSS-API実装では機能しないことに注意してください。INTEG_REQ_FLAGを真であることを要求するRFC 1964 [KRB5GSS]またはRFC 4121 [RFC4121]の実装は存在すると考えられておらず、[RFC4121]への将来の更新は、アプリケーションによって明示的に要求されていない整合性を必要とすることが期待されると予想されます。。
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に渡し、サーバーがサポートするセキュリティレイヤーを指定し、2番目から4番目のオクテットを最大サイズのoutput_messageとして（ネットワークバイト順序の順序で指定するビットマスクとして、結果のクリアテキストの最初のオクテットをインターフレットします）。結果のクリアテキストが長さ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.
次に、クライアントはデータを構築し、選択したセキュリティレイヤーを指定するビットマスクを含む最初のオクテット、ネットワークバイトに含まれる2番目の4番目のオクテットは、クライアントが受信できる最大サイズのoutput_messageセキュリティレイヤーをサポートしない）、およびUTF-8 [UTF8]を含む残りのオクテットは、認証IDをエンコードしました。（実装注：認証IDは、ゼロ値（％x00）オクテット（例えば、nul（u 0000）文字のUTF-8エンコード）で終了しません）。クライアントは、conf_flagがfalseに設定されたgss_wrapにデータを渡し、生成されたoutput_messageで応答します。その後、クライアントはサーバーが認証されていると考えることができます。
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].
サーバーは、Kerberos v GSS-APIメカニズム[KRB5GSS]のアクセプター資格情報を持たない限り、このドキュメントで説明されている「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.
サーバーは、gss_accept_sec_contextに対する最初のクライアント応答をinput_tokenとして渡し、input_context_handleを0（最初）、nullのchan_binding、および適切なAccedor_cred_handle（以下を参照）に設定します。gss_accept_sec_contextがgss_s_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およびObject Identifier（OID）のGSS_ACQUIRE_CREDまたはGSS_ADD_CREDを呼び出して取得した資格情報を使用する必要があります。サーバーは、GSS_C_NO_CREDENTIALをAccedor資格認定ハンドルとして使用できます。サーバーは、サーバーの主名（**）および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名タイプと「service@hostname」形式を持つサーバーの主名の使用。「service」はプロトコルのプロファイルで指定されたサービス名であり、「hostname」は完全に適格なホスト名であり、サーバーの完全なホスト名です。おすすめされた。サーバー名は、GSS_C_NT_HOSTBASET_SERVICEおよびinput_Name_Stringのinput_name_typeをwith input_name_typeで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を使用してAccector資格情報ハンドルを作成した場合、サーバーは、クライアントが使用する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 "service@hostname" name syntax。ここで、「サービス」はアプリケーションプロトコルのプロファイルで指定されたサービス名です。
or
また
- 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]名前構文は、最初のコンポーネントがアプリケーションプロトコルのプロファイルで指定されたサービス名と一致する2成分プリンシパルのsyntaxです。
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オクテットのデータを構築し、最初のオクテットには、サーバーがサポートするセキュリティレイヤーを指定するビットマスクを含む最初のオクテットを構築します。ネットワークバイトに含まれる2番目から4番目のオクテットは、サーバーが受信できる最大サイズの出力_Token（サーバーがセキュリティレイヤーをサポートしていない場合は0でなければなりません）。サーバーは、conf_flagをfalseに設定して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への結果の応答を渡し、選択したセキュリティレイヤーのビットマスクとして結果のクリアテキストの最初のオクテットを解釈する必要があります。）、および残りのオクテットは、認証アイデンティティとして。サーバーは、クライアントが提供されたセキュリティレイヤーを選択したこと、およびセキュリティレイヤーが選択されていない場合、クライアントの最大バッファーが0であることを確認します。サーバーは、SRC_NAMEが認証IDとして機能することを許可されていることを確認する必要があります。これらの検証の後、認証プロセスが完了します。サーバーは、成功指標を備えた追加データを返すことは期待されていません。
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
1セキュリティレイヤー2整合性保護。送信者は、conf_flagをfalse 4の機密保護に設定してGSS_WRAPを呼び出します。送信者は、conf_flagがtrueに設定されたgss_wrapを呼び出します
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の最大サイズを交渉していることに注意してください。実装では、gss_wrap_size_limitコールを使用して、対応する最大サイズの入力_messageを決定できます。
IANA modified the existing registration for "GSSAPI" as follows:
IANAは、次のように「GSSAPI」の既存の登録を変更しました。
Family of SASL mechanisms: NO
SASLメカニズムの家族：いいえ
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>
Intended usage: 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のKerberos V5メカニズム向けです。
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_init_sec_contextおよびgss_accept_sec_contextへのchan_binding（チャネルバインディング）パラメーターがnullであるため、チャネルバインディングのGSS-APIサポートの使用を許可する必要があります。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].
This document replaces Section 7.2 of RFC 2222 [RFC2222] by John G. Myers. He also contributed significantly to this revision.
このドキュメントは、RFC 2222 [RFC2222]のセクション7.2をJohn G. Myersに置き換えます。彼はまた、この改訂に大きく貢献しました。
Lawrence Greenfield converted text of this document to the XML format.
Lawrence Greenfieldは、このドキュメントのテキストを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メーリングリストの多くのメンバーの貢献は、特にクリス・ニューマン、ニコラス・ウィリアムズ、ジェフリー・ハッツェルマン、サム・ハートマン、マーク・クリスピン、マーティン・レックスからのコメントに感謝しています。
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 [RFC2078]からRFC 2743 [GSS-API]への移行の一環として、この仕様では、クライアントがGSS_INIT_SEC_CONTEXTからGSS_WRAPを使用してセキュリティ層の交渉を保護できるように整合性を要求する必要があります。この仕様では、メカニズムが整合性セキュリティレイヤーを提供する必要はありません。単にセキュリティレイヤーのネゴシエーションをラップすることです。
[GSS-API] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[GSS-API] Linn、J。、「Generic Security Service Application Program Interface Version 2、Update 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] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network認証サービス（V5）」、RFC 4120、2005年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[KRB5GSS] Linn、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] Zhu、L.、Jaganathan、K。、およびS. Hartman、「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] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（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。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC2078] Linn、J。、「ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス、バージョン2」、RFC 2078、1997年1月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
Editor's Address
編集者のアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。