[要約] RFC 4402は、Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanismのための擬似乱数関数（PRF）に関する仕様です。このRFCの目的は、Kerberosセキュリティメカニズムで使用されるPRFの標準化とセキュリティの向上です。
Network Working Group N. Williams
Request for Comments: 4402 Sun
Category: Standards Track February 2006
A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism
Kerberos v Generic Security Service Application Program Interface（GSS-API）メカニズムの擬似ランダム関数（PRF）
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 (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.
このドキュメントでは、Kerberos v暗号化フレームワークで定義されたPRFに基づいて、Kerberos v Cerperographic Frameworkで定義されたPRFに基づいて、Kerberos v Generic Security Service Application Program Interface（GSS-API）のKerberos Vメカニズムの擬似ランダム機能（PRF）を定義します。v GSS-APIセキュリティコンテキスト。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Kerberos V GSS Mechanism PRF ....................................2
3. IANA Considerations .............................................3
4. Security Considerations .........................................3
5. Normative References ............................................4
This document specifies the Kerberos V GSS-API mechanism's [RFC4121] pseudo-random function corresponding to [RFC4401]. The function is a "PRF+" style construction. For more information see [RFC4401], [RFC2743], [RFC2744], and [RFC4121].
このドキュメントは、[RFC4401]に対応するKerberos v GSS-APIメカニズムの[RFC4121]擬似ランダム機能を指定しています。機能は「PRF」スタイルの構造です。詳細については、[RFC4401]、[RFC2743]、[RFC2744]、および[RFC4121]を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The GSS-API PRF [RFC4401] function for the Kerberos V mechanism [RFC4121] shall be the output of a PRF+ function based on the encryption type's PRF function keyed with the negotiated session key of the security context corresponding to the 'prf_key' input parameter of GSS_Pseudo_random().
Kerberos Vメカニズム[RFC4121]のGSS-API PRF [RFC4401]関数は、「PRF_KEY」入力パラメーターに対応するセキュリティコンテキストのネゴシエートセッションキーにキーを付けた暗号化タイプのPRF関数に基づいたPRF関数の出力とするものとします。gss_pseudo_random（）。
This PRF+ MUST be keyed with the key indicated by the 'prf_key' input parameter as follows:
このPRFは、次のように「PRF_KEY」入力パラメーターで示されるキーを使用してキー化する必要があります。
o GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the acceptor, if any, or the sub-session asserted by the initiator, if any, or the Ticket's session key
o gss_c_prf_key_full-アクセプターによって主張されたサブセッションキーを使用します。
o GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the initiator, if any, or the Ticket's session key
o gss_c_prf_key_partial-イニシエーターによって主張されたサブセッションキーを使用するか、チケットのセッションキーを使用します
The PRF+ function is a simple counter-based extension of the Kerberos V pseudo-random function [RFC3961] for the encryption type of the security context's keys:
PRF関数は、セキュリティコンテキストのキーの暗号化タイプのKerberos v擬似ランダム関数[RFC3961]の単純なカウンターベースの拡張です。
PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
Tn = pseudo-random(K, n || S)
tn =擬似ランダム（k、n || s）
where '||' is the concatenation operator, 'n' is encoded as a network byte order 32-bit unsigned binary number, truncate(L, S) truncates the input octet string S to length L, and pseudo-random() is the Kerberos V pseudo-random function [RFC3961].
ここで '||'連結演算子は、「n」はネットワークバイトの順序32ビットの符号なしバイナリ数としてエンコードされ、トランケート（l、s）は入力オクテット弦sを長さlに切り捨て、擬似ランダム（）はkerberos v擬似 - ランダム関数[RFC3961]。
The maximum output size of the Kerberos V mechanism's GSS-API PRF then is, necessarily, 2^32 times the output size of the pseudo-random() function for the encryption type of the given key.
Kerberos VメカニズムのGSS-API PRFの最大出力サイズは、必然的に、指定されたキーの暗号化タイプのPseudo-Random（）関数の出力サイズの2倍の2倍です。
When the input size is longer than 2^14 octets as per [RFC4401] and exceeds an implementation's resources, then the mechanism MUST return GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status code.
[RFC4401]に従って入力サイズが2^14オクテットよりも長く、実装のリソースを超えている場合、メカニズムはGSS_S_FAILUREとGSS_KRB5_S_KG_INPUT_TOO_LONGをマイナーステータスコードとして返す必要があります。
This document has no IANA considerations currently. If and when a relevant IANA registry of GSS-API symbols and constants is created, then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be added to such a registry.
このドキュメントには現在、IANAの考慮事項はありません。GSS-APIシンボルと定数の関連するIANAレジストリが作成された場合、GSS_KRB5_S_KG_INPUT_TOO_LONGマイナーステータスコードをそのようなレジストリに追加する必要があります。
Kerberos V encryption types' PRF functions use a key derived from contexts' session keys and should preserve the forward security properties of the mechanisms' key exchanges.
Kerberos v暗号化タイプ「PRF関数コンテキスト」セッションキーから派生したキーを使用し、メカニズムのキー交換の前方セキュリティプロパティを保持する必要があります。
Legacy Kerberos V encryption types may be weak, particularly the single-DES encryption types.
Legacy Kerberos v暗号化の種類は、特にシングルデス暗号化の種類が弱い場合があります。
See also [RFC4401] for generic security considerations of GSS_Pseudo_random().
GSS_PSEUDO_RANDOM（）の一般的なセキュリティに関する考慮事項については、[RFC4401]も参照してください。
See also [RFC3961] for generic security considerations of the Kerberos V cryptographic framework.
Kerberos v Cryptographic Frameworkの一般的なセキュリティに関する考慮事項については、[RFC3961]も参照してください。
Use of Ticket session keys, rather than sub-session keys, when initiators and acceptors fail to assert sub-session keys, is dangerous as ticket reuse can lead to key reuse; therefore, initiators should assert sub-session keys always, and acceptors should assert sub-session keys at least when initiators fail to do so.
イニシエーターとアクセプターがサブセッションキーを主張できない場合、サブセッションキーではなくチケットセッションキーの使用は、チケットの再利用がキーの再利用につながるため、危険です。したがって、イニシエーターは常にサブセッションキーを主張する必要があり、アクセプターは少なくともイニシエーターがそうしなかった場合、サブセッションキーをアサブセッションキーに断言する必要があります。
The computational cost of computing this PRF+ may vary depending on the Kerberos V encryption types being used, but generally the computation of this PRF+ gets more expensive as the input and output octet string lengths grow (note that the use of a counter in the PRF+ construction allows for parallelization). This means that if an application can be tricked into providing very large input octet strings and requesting very long output octet strings, then that may constitute a denial of service attack on the application; therefore, applications SHOULD place appropriate limits on the size of any input octet strings received from their peers without integrity protection.
このPRFを計算する計算コストは、使用されているKerberos V暗号化タイプによって異なる場合がありますが、一般に、このPRFの計算は、入力と出力のオクテット文字列の長さが増加するにつれてより高価になります（PRF構造でのカウンターの使用に注意してください並列化を可能にします）。これは、アプリケーションをだまして非常に大きな入力オクテット文字列を提供し、非常に長い出力オクテット文字列を要求できる場合、それがアプリケーションに対するサービス拒否攻撃を構成する可能性があることを意味します。したがって、アプリケーションは、整合性保護なしに同僚から受け取った入力オクテット文字列のサイズに適切な制限を配置する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC2744] Wray、J。、「ジェネリックセキュリティサービスAPIバージョン2：C-Bindings」、RFC 2744、2000年1月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961] Raeburn、K。、「Kerberos 5の暗号化とチェックサム仕様」、RFC 3961、2005年2月。
[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月。
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4401]ウィリアムズ、N。、「一般的なセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）の擬似ランダム関数（PRF）API拡張」、RFC 4401、2006年2月。
Author's Address
著者の連絡先
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US
ニコラス・ウィリアムズサンマイクロシステムズ5300リアタトレースCTオースティン、テキサス78727 US
EMail: Nicolas.Williams@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。