RFC 6542 - Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6542
タイトル : RFC 6542 - Kerberosバージョン5ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）チャネルバインディングハッシュアジリティ
翻訳編集 : 自動生成

[要約] RFC 6542は、Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agilityに関する仕様です。このRFCの目的は、GSS-APIのチャネルバインディングハッシュの柔軟性を向上させることです。

Internet Engineering Task Force (IETF)                          S. Emery
Request for Comments: 6542                                        Oracle
Updates: 4121                                                 March 2012
Category: Standards Track
ISSN: 2070-1721

Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility

Kerberosバージョン5ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）チャネルバインディングハッシュアジリティ

Abstract

概要

Currently, channel bindings are implemented using an MD5 hash in the Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism (RFC 4121). This document updates RFC 4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions.

現在、チャネルバインディングは、Kerberosバージョン5ジェネリックセキュリティサービスアプリケーションプログラミングインターフェイス（GSS-API）メカニズム（RFC 4121）でMD5ハッシュを使用して実装されています。このドキュメントは、RFC 4121を更新して、RFC 3961で定義されているKerberos Crypto Frameworkに基づいて交渉されたアルゴリズムを使用してチャネルバインディングを許可します。さらに、この更新はKerberosクライアントサーバーエクスチェンジメッセージの最後の拡張フィールドを利用しているため、拡張機能は拡張機能を使用して定義されています。将来のプロトコル拡張。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6542.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6542で取得できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは必須です

include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、簡素化されたBSDライセンスに記載されている保証なしで提供される簡略化されたBSDライセンステキストを含めます。

Table of Contents

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................2
   3. Channel Binding Hash Agility ....................................2
      3.1. Structure of the Exts Field ................................3
      3.2. The Channel Binding Extension ..............................4
   4. Security Considerations .........................................4
   5. IANA Considerations .............................................4
   6. Acknowledgments .................................................5
   7. References ......................................................5
      7.1. Normative References .......................................5
      7.2. Informative References .....................................5

1. Introduction

1. はじめに

With the recently discovered weaknesses in the MD5 hash algorithm (see [RFC6151]), there is a need to use stronger hash algorithms. The Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism [RFC4121] uses MD5 to calculate channel binding verifiers. This document specifies an update to the mechanism that allows it to create channel binding information based on negotiated algorithms. This will allow deploying new algorithms incrementally without breaking interoperability with older implementations when new attacks arise in the future.

MD5ハッシュアルゴリズムで最近発見された弱点（[RFC6151]を参照）では、より強力なハッシュアルゴリズムを使用する必要があります。Kerberosバージョン5ジェネリックセキュリティサービスアプリケーションプログラミングインターフェイス（GSS-API）メカニズム[RFC4121]は、MD5を使用してチャネル結合検証を計算します。このドキュメントは、ネゴシエートされたアルゴリズムに基づいてチャネルバインディング情報を作成できるメカニズムの更新を指定します。これにより、新しい攻撃が将来発生したときに、古い実装との相互運用性を破ることなく、新しいアルゴリズムを段階的に展開できます。

2. Conventions Used in This Document

2. このドキュメントで使用されている規則

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 term "little-endian order" is used for brevity to refer to the least-significant-octet-first encoding, while the term "big-endian order" is used for the most-significant-octet-first encoding.

「リトルエンディアン秩序」という用語は、最も重要なオクセットファーストエンコードを指すために簡潔に使用されますが、「ビッグエンディアンオーダー」という用語は、最も重要なオクセットファーストエンコードに使用されます。

3. Channel Binding Hash Agility

3. チャネル結合ハッシュアジリティ

When generating a channel binding verifier, Bnd, a hash is computed from the channel binding fields. Initiators MUST populate the Bnd field in order to maintain interoperability with existing acceptors. In addition, initiators MUST populate the extension field (Exts) defined below.

チャネル結合検証剤BNDを生成すると、ハッシュがチャネル結合フィールドから計算されます。イニシエーターは、既存のアクセプターとの相互運用性を維持するために、BNDフィールドに入力する必要があります。さらに、イニシエーターは、以下に定義する拡張フィールド（exts）を埋める必要があります。

3.1. Structure of the Exts Field

3.1. extsフィールドの構造

The 0x8003 GSS checksum has the same structure described in [RFC4121] except that the Exts field is now defined; the entire structure of the 0x8003 checksum, including the now defined Exts field, follows:

0x8003 GSSチェックサムは、[RFC4121]で説明されている構造と同じ構造を持っています。現在定義されているextsフィールドを含む0x8003チェックサムの構造全体が続きます。

      Octet     Name       Description
      -----------------------------------------------------------------
      0..3      Lgth       Number of octets in Bnd field, represented
                            in little-endian order;  currently contains
                            hex value 10 00 00 00 (16).
      4..19     Bnd        Channel binding information, as described in
                            Section 4.1.1.2 of [RFC4121].
      20..23    Flags      Four-octet context-establishment flags in
                            little-endian order as described in Section
                            4.1.1.1 of [RFC4121].
      24..25    DlgOpt     The delegation option identifier (=1) in
                            little-endian order [optional].  This field
                            and the next two fields are present if and
                            only if GSS_C_DELEG_FLAG is set as described
                            in Section 4.1.1.1 of [RFC4121].
      26..27    Dlgth      The length of the Deleg field in
                            little-endian order [optional].
      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
      n..last   Exts       Extensions.

where Exts is the concatenation of zero, one, or more individual extensions, each of which consists of the following, in order:

ここで、extsはゼロ、1つ、またはより個別の拡張機能の連結であり、それぞれが次の順に構成されています。

type -- big-endian-order unsigned integer, 32 bits, which contains the type of extension length -- big-endian-order unsigned integer, 32 bits, which contains the length, in octets, of the extension data encoded as an array of octets immediately following this field data -- octet string of extension information

タイプ - 拡張長のタイプを含む32ビット、32ビット - アレイとしてエンコードされた拡張データのオクテット内の長さを含む32ビット、ビッグエンディアン装飾整数、32ビット32ビットこのフィールドデータの直後のオクテットの - 拡張情報のオクテット文字列

If multiple extensions are present, then there MUST be at most one instance of a given extension type.

複数の拡張機能が存在する場合は、最大で特定の拡張型のインスタンスが必要です。

3.2. The Channel Binding Extension

3.2. チャネル結合拡張

When channel binding is used, the Exts MUST include the following extension:

チャネルバインディングを使用する場合、extsには次の拡張機能を含める必要があります。

data-type 0x00000000

データタイプ0x00000000

data-value

データ値

The output obtained by applying the Kerberos V get_mic operation [RFC3961] with key usage number 43 to the channel binding data as described in [RFC4121], Section 4.1.1.2 (using get_mic instead of MD5). The key used is the sub-session key from the authenticator, if it is present; otherwise, the key used is the session key from the ticket. The get_mic algorithm is chosen as the "required checksum mechanism" for the encryption type of the key used.

Kerberos v get_mic操作[RFC3961]をキー使用法番号43で[RFC4121]に記載されているように、セクション4.1.1.2（MD5の代わりにget_micを使用）に適用することによって得られた出力。使用されるキーは、存在する場合、認証器からのサブセッションキーです。それ以外の場合、使用されるキーはチケットのセッションキーです。get_micアルゴリズムは、使用されるキーの暗号化タイプの「必要なチェックサムメカニズム」として選択されます。

Initiators that are unwilling to use an MD5 hash of the channel bindings MUST set the Bnd field to sixteen octets of hex value FF.

チャネルバインディングのMD5ハッシュを使用したくないイニシエーターは、BNDフィールドを16分の1ヘクス値FFに設定する必要があります。

4. Security Considerations

4. セキュリティに関する考慮事項

With this mechanism, initiators get no indication as to whether the acceptors check or ignore channel bindings.

このメカニズムを使用すると、イニシエーターは、アクセプターがチャネルバインディングをチェックするか無視するかについての兆候を得ません。

It is up to the application whether or not to enforce the use of channel bindings. [RFC5056] and [RFC5554] give guidance for application developers on channel binding usage.

チャネルバインディングの使用を実施するかどうかは、アプリケーション次第です。[RFC5056]および[RFC5554]は、チャネルバインディングの使用に関するアプリケーション開発者にガイダンスを提供します。

5. IANA Considerations

5. IANAの考慮事項

IANA has created a new top-level registry titled "Kerberos V GSS-API Mechanism Parameters," separate from the existing Kerberos parameters registry. Within this registry, IANA has created a sub-registry of "Kerberos V GSS-API Mechanism Extension Types" with four-field entries (Type Number, Type Name, Description, and Reference) and, initially, a single registration: 0x00000000, "Channel Binding MIC," "Extension for the verifier of the channel bindings," [RFC6542].

IANAは、既存のKerberosパラメーターレジストリとは別に、「Kerberos v GSS-APIメカニズムパラメーター」というタイトルの新しいトップレベルレジストリを作成しました。このレジストリ内で、IANAは、4フィールドエントリ（タイプ番号、タイプ名、説明、参照）を備えた「Kerberos v GSS-APIメカニズム拡張タイプ」のサブレジストリを作成しました。チャネル結合マイク、「チャネルバインディングの検証者の拡張」[RFC6542]。

Using the guidelines for allocation as described in [RFC5226], type number assignments are as follows:

[RFC5226]で説明されている割り当てのガイドラインを使用すると、タイプ番号の割り当ては次のとおりです。

0x00000000 - 0x000003FF IETF Review

0x00000000-0x000003ff IETFレビュー

0x00000400 - 0xFFFFF3FF Specification Required

0x00000400-0xffffff3ff仕様が必要です

0xFFFFF400 - 0xFFFFFFFF Private Use

0xffffff400-0xffffffffプライベート使用

6. Acknowledgments

6. 謝辞

The author would like to thank Larry Zhu, Nicolas Williams, Sam Hartman, Jeffrey Hutzelman, and Simon Josefsson for their help in reviewing and providing valuable feedback on this document.

著者は、この文書に関する貴重なフィードバックをレビューして提供してくれたことを、Larry Zhu、Nicolas Williams、Sam Hartman、Jeffrey Hutzelman、Simon Josefssonに感謝したいと思います。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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月。

[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月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。

7.2. Informative References

7.2. 参考引用

[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.

[RFC5056]ウィリアムズ、N。、「チャンネルを保護するためのチャネルバインディングの使用について」、RFC 5056、2007年11月。

[RFC5554] Williams, N., "Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings", RFC 5554, May 2009.

[RFC5554]ウィリアムズ、N。、「チャネルバインディングの使用のための一般的なセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）の明確化と拡張」、2009年5月、RFC 5554。

[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.

[RFC6151] Turner、S。およびL. Chen、「MD5 Message-DigestおよびHMAC-MD5アルゴリズムのセキュリティ上の考慮事項を更新しました」、RFC 6151、2011年3月。

Author's Address

著者の連絡先

Shawn Emery Oracle 500 Eldorado Blvd, Building 1 Broomfield, CO 80021 USA

ショーン・エメリー・オラクル500エルドラド・ブルバード、建物1ブルームフィールド、CO 80021 USA

   EMail: shawn.emery@oracle.com