RFC 8420 - Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8420
タイトル : RFC 8420 - インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）でのEdwards-Curveデジタル署名アルゴリズム（EdDSA）の使用
翻訳編集 : 自動生成

[要約] RFC 8420は、IKEv2でEdDSAを使用するためのガイドラインです。その目的は、IKEv2においてEdDSAを安全かつ効果的に利用するための手順と要件を提供することです。

Internet Engineering Task Force (IETF)                            Y. Nir
Request for Comments: 8420                                      Dell EMC
Category: Standards Track                                    August 2018
ISSN: 2070-1721

Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)

インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）でのEdwards-Curveデジタル署名アルゴリズム（EdDSA）の使用

Abstract

概要

This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2).

このドキュメントでは、インターネットキー交換プロトコルバージョン2（IKEv2）でのEdwards曲線デジタル署名アルゴリズム（EdDSA）の使用について説明します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

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

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8420で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. The "Identity" Hash Identifier ..................................3
   3. Security Considerations .........................................3
   4. IANA Considerations .............................................3
   5. Normative References ............................................3
   Appendix A.  ASN.1 Objects .........................................4
     A.1.  ASN.1 Object for Ed25519 ...................................4
     A.2.  ASN.1 Object for Ed448 .....................................4
   Author's Address ...................................................5

1. Introduction

1. はじめに

The Internet Key Exchange Protocol Version 2 [RFC7296] can use arbitrary signature algorithms as described in [RFC7427]. [RFC7427] defines the SIGNATURE_HASH_ALGORITHMS notification where each side of the IKE negotiation lists its supported hash algorithms. This assumes that all signature schemes involve a hashing phase followed by a signature phase. This made sense because most signature algorithms either cannot sign messages bigger than their key or truncate messages bigger than their key.

Internet Key Exchange Protocol Version 2 [RFC7296]は、[RFC7427]で説明されている任意の署名アルゴリズムを使用できます。 [RFC7427]はIKEATURE_HASH_ALGORITHMS通知を定義しており、IKEネゴシエーションの各サイドがサポートされているハッシュアルゴリズムをリストしています。これは、すべての署名方式にハッシュ段階とそれに続く署名段階が含まれることを前提としています。ほとんどの署名アルゴリズムは、キーより大きいメッセージに署名できないか、キーより大きいメッセージを切り捨てることができないため、これは理にかなっています。

EdDSA [RFC8032] defines signature methods that do not require prehashing of the message. Unlike other methods, these accept messages of arbitrary size, so no prehashing is required. These methods are called Ed25519 and Ed448; they use the Edwards 25519 and the Edwards 448 ("Goldilocks") curves, respectively. Although that document also defines prehashed versions of these algorithms, those versions are not recommended for protocols where there is minimal burden in buffering the entire message so as to make it practical to make two passes over the message. This is true of IKEv2. See Section 8.5 of [RFC8032] for that recommendation.

EdDSA [RFC8032]は、メッセージの事前ハッシュを必要としない署名方法を定義しています。他の方法とは異なり、これらは任意のサイズのメッセージを受け入れるため、事前ハッシュは必要ありません。これらのメソッドは、Ed25519およびEd448と呼ばれます。それらは、それぞれエドワーズ25519およびエドワーズ448（「ゴルディロックス」）カーブを使用します。このドキュメントでは、これらのアルゴリズムのハッシュ済みバージョンも定義していますが、メッセージ全体をバッファリングする負担が最小限であり、メッセージを2回パスすることが実用的であるプロトコルでは、これらのバージョンは推奨されません。これはIKEv2にも当てはまります。その推奨事項については、[RFC8032]のセクション8.5をご覧ください。

EdDSA defines the binary format of the signatures that should be used in the "Signature Value" field of the Authentication Data Format in Section 3 of RFC 8032. [RFC8410] defines the object identifiers (OIDs) for these signature methods. For convenience, these OIDs are repeated in Appendix A.

EdDSAは、RFC 8032のセクション3の認証データ形式の「署名値」フィールドで使用する必要がある署名のバイナリ形式を定義します。[RFC8410]は、これらの署名メソッドのオブジェクト識別子（OID）を定義します。便宜上、これらのOIDは付録Aで繰り返されています。

In order to signal within IKE that no hashing needs to be done, we define a new value in the SIGNATURE_HASH_ALGORITHMS notification to indicate that no hashing is performed.

ハッシュを実行する必要がないことをIKE内で通知するために、SIGNATURE_HASH_ALGORITHMS通知に新しい値を定義して、ハッシュを実行しないことを示します。

1.1. Conventions Used in This Document

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

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2. The "Identity" Hash Identifier

2. 「アイデンティティ」ハッシュ識別子

This document defines a new value called "Identity" (5) in the "IKEv2 Hash Algorithms" registry for use in the SIGNATURE_HASH_ALGORITHMS notification. Inserting this new value into the notification indicates that the receiver supports at least one signature algorithm that accepts messages of arbitrary size such as Ed25519 and Ed448.

このドキュメントでは、SIGNATURE_HASH_ALGORITHMS通知で使用するために、「IKEv2 Hash Algorithms」レジストリで「Identity」（5）と呼ばれる新しい値を定義しています。この新しい値を通知に挿入することは、受信者がEd25519やEd448などの任意のサイズのメッセージを受け入れる少なくとも1つの署名アルゴリズムをサポートすることを示します。

Ed25519 and Ed448 are only defined with the "Identity" hash and MUST NOT be sent to a receiver that has not indicated support for the "Identity" hash.

Ed25519およびEd448は「Identity」ハッシュでのみ定義されており、「Identity」ハッシュのサポートを示していない受信者に送信してはなりません。

The prehashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph, respectively) MUST NOT be used in IKE.

Ed25519およびEd448のプリハッシュバージョン（それぞれ、Ed25519phおよびEd448ph）は、IKEで使用してはなりません（MUST NOT）。

3. Security Considerations

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

The new "Identity" value is needed only for signature algorithms that accept an input of arbitrary size. It MUST NOT be used if none of the supported and configured algorithms have this property. On the other hand, there is no good reason to prehash the inputs where the signature algorithm has that property. For this reason, implementations MUST have the "Identity" value in the SIGNATURE_HASH_ALGORITHMS notification when EdDSA is supported and configured. Implementations SHOULD NOT have other hash algorithms in the notification if all supported and configured signature algorithms have this property.

新しい「ID」値は、任意のサイズの入力を受け入れる署名アルゴリズムにのみ必要です。サポートおよび構成されたアルゴリズムのいずれにもこのプロパティがない場合は、使用しないでください。一方、署名アルゴリズムがその特性を持っている場合、入力をプリハッシュする正当な理由はありません。このため、EdDSAがサポートおよび構成されている場合、実装はSIGNATURE_HASH_ALGORITHMS通知に「Identity」値を含める必要があります。サポートされ構成されているすべての署名アルゴリズムにこのプロパティがある場合、実装では通知に他のハッシュアルゴリズムを含めないでください。

4. IANA Considerations

4. IANAに関する考慮事項

IANA has assigned the value 5 for the algorithm with the name "Identity" in the "IKEv2 Hash Algorithms" registry with this document as reference.

IANAは、このドキュメントを参照して、「IKEv2 Hash Algorithms」レジストリで「Identity」という名前のアルゴリズムに値5を割り当てました。

5. Normative References

5. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<https://www.rfc-editor.org/info/rfc7296>。

[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, <https://www.rfc-editor.org/info/rfc7427>.

[RFC7427] Kivinen、T。およびJ. Snyder、「インターネットキーエクスチェンジバージョン2（IKEv2）での署名認証」、RFC 7427、DOI 10.17487 / RFC7427、2015年1月、<https://www.rfc-editor.org / info / rfc7427>。

[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.

[RFC8032] Josefsson、S。およびI. Liusvaara、「Edwards-Curve Digital Signature Algorithm（EdDSA）」、RFC 8032、DOI 10.17487 / RFC8032、2017年1月、<https://www.rfc-editor.org/info/ rfc8032>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, <https://www.rfc-editor.org/info/rfc8410>.

[RFC8410] Josefsson、S。およびJ. Schaad、「インターネットX.509公開鍵インフラストラクチャで使用するためのEd25519、Ed448、X25519、およびX448のアルゴリズム識別子」、RFC 8410、DOI 10.17487 / RFC8410、2018年8月、<https ：//www.rfc-editor.org/info/rfc8410>。

Appendix A. ASN.1 Objects

付録A. ASN.1オブジェクト

[RFC8410] is the normative reference for the ASN.1 objects for Ed25519 and Ed448. They are repeated below for convenience.

[RFC8410]は、Ed25519およびEd448のASN.1オブジェクトの規範的な参照です。便宜上、以下に繰り返します。

A.1. ASN.1 Object for Ed25519

A.1. Ed25519のASN.1オブジェクト

   id-Ed25519 OBJECT IDENTIFIER ::= { 1.3.101.112 }

Parameters are absent. Length is 7 bytes.

パラメータはありません。長さは7バイトです。

Binary encoding: 3005 0603 2B65 70

バイナリエンコーディング：3005 0603 2B65 70

A.2. ASN.1 Object for Ed448

A.2. Ed448のASN.1オブジェクト

   id-Ed448 OBJECT IDENTIFIER ::= { 1.3.101.113 }

Parameters are absent. Length is 7 bytes.

パラメータはありません。長さは7バイトです。

Binary encoding: 3005 0603 2B65 71

バイナリエンコーディング：3005 0603 2B65 71

Author's Address

著者のアドレス

Yoav Nir Dell EMC 9 Andrei Sakharov St Haifa 3190500 Israel

   Email: ynir.ietf@gmail.com