[要約] RFC 8573は、ネットワークタイムプロトコル(NTP)のためのメッセージ認証コード(MAC)に関する規格です。その目的は、NTPメッセージの整合性と信頼性を確保するために、メッセージの認証を提供することです。
Internet Engineering Task Force (IETF) A. Malhotra Request for Comments: 8573 S. Goldberg Updates: 5905 Boston University Category: Standards Track June 2019 ISSN: 2070-1721
Message Authentication Code for the Network Time Protocol
ネットワークタイムプロトコルのメッセージ認証コード
Abstract
概要
The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.
RFC 5905に記載されているNetwork Time Protocol(NTP)は、NTPデータを128ビットのキーに追加し、その結果をMD5でハッシュして128ビットのタグを取得することにより、NTPパケットを認証する必要があると述べています。このドキュメントでは、弱すぎると見なされているMD5ベースの認証を廃止し、RFC 4493に記載されているAES-CMACの使用を推奨しています。
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/rfc8573.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8573で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Deprecating the Use of MD5 . . . . . . . . . . . . . . . . . 2 3. Replacement Recommendation . . . . . . . . . . . . . . . . . 2 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 7. Security Considerations . . . . . . . . . . . . . . . . . . . 3 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . 4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
The Network Time Protocol [RFC5905] states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC [RFC4493] as a replacement.
Network Time Protocol [RFC5905]は、NTPデータを128ビットのキーに追加し、その結果をMD5でハッシュして128ビットのタグを取得することにより、NTPパケットを認証する必要があると述べています。このドキュメントは弱すぎると考えられているMD5ベースの認証を廃止し、代わりにAES-CMAC [RFC4493]の使用を推奨します。
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]で説明されているように解釈されます。
RFC 5905 [RFC5905] defines how the MD5 digest algorithm described in RFC 1321 [RFC1321] can be used as a Message Authentication Code (MAC) for authenticating NTP packets. However, as discussed in [BCK] and RFC 6151 [RFC6151], this is not a secure MAC and therefore MUST be deprecated.
RFC 5905 [RFC5905]は、RFC 1321 [RFC1321]で説明されているMD5ダイジェストアルゴリズムを、NTPパケットを認証するためのメッセージ認証コード(MAC)として使用する方法を定義しています。ただし、[BCK]およびRFC 6151 [RFC6151]で説明されているように、これは安全なMACではないため、非推奨にする必要があります。
If NTP authentication is implemented, then AES-CMAC as specified in RFC 4493 [RFC4493] MUST be computed over all fields in the NTP header and any extension fields that are present in the NTP packet as described in RFC 5905 [RFC5905]. The MAC key for NTP MUST be an AES-128 key that is 128 bits in length, and the resulting MAC tag MUST be at least 128 bits in length, as stated in Section 2.4 of RFC 4493 [RFC4493]. NTP makes this transition possible as it supports algorithm agility as described in Section 2.1 of RFC 7696 [RFC7696].
NTP認証が実装されている場合、RFC 4493 [RFC4493]で指定されているAES-CMACは、RFC 5905 [RFC5905]で説明されているように、NTPヘッダーのすべてのフィールドとNTPパケットに存在する拡張フィールドで計算する必要があります。 RFC 4493 [RFC4493]のセクション2.4に記載されているように、NTPのMACキーは長さが128ビットのAES-128キーである必要があり、結果のMACタグは長さが少なくとも128ビットである必要があります。 RFC 7696 [RFC7696]のセクション2.1で説明されているように、NTPはアルゴリズムの俊敏性をサポートするため、この移行を可能にします。
The hosts that wish to use NTP authentication share a symmetric key out of band. So they MUST implement AES-CMAC and share the corresponding symmetric key. A symmetric key is a triplet of ID, type (e.g., MD5 and AES-CMAC) and the key itself. All three have to match in order to successfully authenticate packets between two hosts. Old implementations that don't support AES-CMAC will not accept and will not send packets authenticated with such a key.
NTP認証を使用するホストは、帯域外の対称鍵を共有します。そのため、AES-CMACを実装し、対応する対称鍵を共有する必要があります。対称キーは、ID、タイプ(MD5やAES-CMACなど)とキー自体の3つの要素です。 2つのホスト間でパケットを正常に認証するには、3つすべてが一致する必要があります。 AES-CMACをサポートしない古い実装は、そのようなキーで認証されたパケットを受け入れず、送信しません。
AES-CMAC is recommended for the following reasons:
以下の理由により、AES-CMACが推奨されます。
1. It is an IETF specification that is supported in many open source implementations.
1. これは、多くのオープンソース実装でサポートされているIETF仕様です。
2. It is immune to nonce-reuse vulnerabilities (e.g., [Joux]) because it does not use a nonce.
2. nonceを使用しないため、nonceを再利用する脆弱性([Joux]など)の影響を受けません。
3. It has fine performance in terms of latency and throughput.
3. レイテンシとスループットの点で優れたパフォーマンスを発揮します。
4. It benefits from native hardware support, for instance, Intel's New Instruction set GUE [GUE].
4. たとえば、Intelの新しい命令セットGUE [GUE]などのネイティブハードウェアサポートの恩恵を受けます。
For test vectors and their outputs, refer to Section 4 of RFC 4493 [RFC4493].
テストベクトルとその出力については、RFC 4493 [RFC4493]のセクション4を参照してください。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
Refer to Appendices A, B, and C of the NIST document [NIST] for a recommendation for the CMAC mode of authentication; see the Security Considerations of RFC 4493 [RFC4493] for discussion on security guarantees of AES-CMAC.
認証のCMACモードの推奨事項については、NISTドキュメント[NIST]の付録A、B、Cを参照してください。 AES-CMACのセキュリティ保証については、RFC 4493のセキュリティに関する考慮事項[RFC4493]を参照してください。
[NIST] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", NIST Special Publication 800-38B, DOI 10.6028/NIST.SP.800-38B, October 2016, <https://www.nist.gov/publications/recommendation-block-cipher-modes-operation-cmac-mode-authentication-0>.
[NIST] Dworkin、M。、「Block Cipher Modes of Operation:the CMAC Mode for Authentication」、NIST Special Publication 800-38B、DOI 10.6028 / NIST.SP.800-38B、October 2016、<https:// www.nist.gov/publications/recommendation-block-cipher-modes-operation-cmac-mode-authentication-0>。
[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>。
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006, <https://www.rfc-editor.org/info/rfc4493>.
[RFC4493] Song、JH。、Poovendran、R.、Lee、J.、T。Iwata、「The AES-CMAC Algorithm」、RFC 4493、DOI 10.17487 / RFC4493、2006年6月、<https://www.rfc -editor.org/info/rfc4493>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4:Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月、 <https://www.rfc-editor.org/info/rfc5905>。
[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>。
[BCK] Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash Functions and Message Authentication", Advances in Cryptology - Crypto 96 Proceedings, Lecture Notes in Computer Science, Vol. 1109, N. Koblitz ed, Springer-Verlag, 1996.
[BCK] Bellare、M.、Canetti、R。、およびH. Krawczyk、「Keying Hash Functions and Message Authentication」、Advance in Cryptology-Crypto 96 Proceedings、Lecture Notes in Computer Science、Vol。 1109、N。Koblitz ed、Springer-Verlag、1996。
[GUE] Geuron, S., "Intel Advanced Encryption Standard (AES) New Instructions Set", May 2010, <https://www.intel.com/content/dam/doc/white-paper/ advanced-encryption-standard-new-instructions-set-paper.pdf>.
[GUE] Geuron、S。、「Intel Advanced Encryption Standard(AES)New Instructions Set」、2010年5月、<https://www.intel.com/content/dam/doc/white-paper/ advanced-encryption-standard -new-instructions-set-paper.pdf>。
[Joux] Joux, A., "Authentication Failures in NIST version of GCM", <http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/ comments/800-38_Series-Drafts/GCM/Joux_comments.pdf>.
[Joux] Joux、A。、「NISTバージョンのGCMでの認証の失敗」、<http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Series-Drafts/GCM/Joux_comments .pdf>。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<https://www.rfc-editor.org/info/rfc1321>。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.
[RFC6151]ターナーS.およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、DOI 10.17487 / RFC6151、2011年3月、<https://www.rfc- editor.org/info/rfc6151>。
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <https://www.rfc-editor.org/info/rfc7696>.
[RFC7696] Housley、R。、「暗号化アルゴリズムの敏捷性と実装必須アルゴリズムの選択に関するガイドライン」、BCP 201、RFC 7696、DOI 10.17487 / RFC7696、2015年11月、<https://www.rfc-editor.org / info / rfc7696>。
Acknowledgements
謝辞
The authors wish to acknowledge useful discussions with Leen Alshenibr, Daniel Franke, Ethan Heilman, Kenny Paterson, Leonid Reyzin, Harlan Stenn, and Mayank Varia.
著者は、Leen Alshenibr、Daniel Franke、Ethan Heilman、Kenny Paterson、Leonid Reyzin、Harlan Stenn、およびMayank Variaとの有益な議論を認めたいと思います。
Authors' Addresses
著者のアドレス
Aanchal Malhotra Boston University 111 Cummington St Boston, MA 02215 United States of America
Aanchal Malhotra Boston University 111 Cummington Stボストン、MA 02215アメリカ合衆国
Email: aanchal4@bu.edu
Sharon Goldberg Boston University 111 Cummington St Boston, MA 02215 United States of America
シャロンゴールドバーグボストン大学111カミントンストリートボストン、MA 02215アメリカ合衆国
Email: goldbe@cs.bu.edu