idnits 2.17.1 draft-ietf-ntp-mac-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5905], [RFC4493]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5905, but the abstract doesn't seem to directly say this. It does mention RFC5905 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5905, updated by this document, for RFC5378 checks: 2005-07-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 3, 2018) is 2003 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST' ** Downref: Normative reference to an Informational RFC: RFC 4493 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Malhotra 3 Internet-Draft S. Goldberg 4 Updates: 5905 (if approved) Boston University 5 Intended status: Standards Track October 3, 2018 6 Expires: April 6, 2019 8 Message Authentication Code for the Network Time Protocol 9 draft-ietf-ntp-mac-05 11 Abstract 13 RFC 5905 [RFC5905] states that Network Time Protocol (NTP) packets 14 should be authenticated by appending a 128-bit key to the NTP data, 15 and hashing the result with MD5 to obtain a 128-bit tag. This 16 document deprecates MD5-based authentication, which is considered to 17 be too weak, and recommends the use of AES-CMAC [RFC4493] as a 18 replacement. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 6, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. Deprecating the use of MD5 . . . . . . . . . . . . . . . . . 2 57 3. Replacement Recommendation . . . . . . . . . . . . . . . . . 2 58 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 3 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 65 9.2. Informative References . . . . . . . . . . . . . . . . . 4 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 RFC 5905 [RFC5905] states that Network Time Protocol (NTP) packets 71 should be authenticated by appending a 128-bit key to the NTP data, 72 and hashing the result with MD5 to obtain a 128-bit tag. This 73 document deprecates MD5-based authentication, which is considered to 74 be too weak, and recommends the use of AES-CMAC [RFC4493] as a 75 replacement. 77 1.1. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 2. Deprecating the use of MD5 85 RFC 5905 [RFC5905] defines how the MD5 digest algorithm in RFC 1321 86 [RFC1321] can be used as a message authentication code (MAC) for 87 authenticating NTP packets. However, as discussed in [BCK] and RFC 88 6151 [RFC6151], this is not a secure MAC and therefore MUST be 89 deprecated. 91 3. Replacement Recommendation 93 If authentication is implemented, then AES-CMAC as specified in RFC 94 4493 [RFC4493] SHOULD be computed over all fields in the NTP header, 95 and any extension fields that are present in the NTP packet as 96 described in RFC 5905 [RFC5905]. The MAC key for NTP MUST be at 97 least 128 bits long AES-128 key and the resulting MAC tag MUST be at 98 least 128 bits long as stated in section 2.4 of RFC 4493 [RFC4493]. 99 NTP makes this transition possible as it supports algorithm agility 100 as described in Section 2.1 of RFC 7696 [RFC7696]. 102 The hosts who wish to use NTP authentication share a symmetric key 103 out-of-band. So they MUST implement AES-CMAC and share the 104 corresponding symmetric key. A symmetric key is a triplet of ID, 105 type (e.g. MD5, AES-CMAC) and the key itself. All three have to 106 match in order to succesfully authenticate packets between two hosts. 107 Old implementations that don't support AES-CMAC will not accept and 108 will not send packets authenticated with such a key. 110 4. Motivation 112 AES-CMAC is recommended for the following reasons: 114 1. It is an IETF standard that is available in many open source 115 implementations. 117 2. It is immune to nonce-reuse vulnerabilities (e.g. [Joux]) 118 because it does not use a nonce. 120 3. It has fine performance in terms of latency and throughput. 122 4. It benefits from native hardware support, for instance, Intel's 123 New Instruction set. 125 5. Test Vectors 127 For test vectors and their outputs refer to Section 4 of RFC 4493 128 [RFC4493] 130 6. Security Considerations 132 Refer to the Appendices A, B and C of NIST document [NIST] and 133 Security Considerations Section of RFC 4493 [RFC4493] for discussion 134 on security guarantees of AES-CMAC. 136 7. Acknowledgements 138 The authors wish to acknowledge useful discussions with Leen 139 Alshenibr, Daniel Franke, Ethan Heilman, Kenny Paterson, Leonid 140 Reyzin, Harlan Stenn, and Mayank Varia. 142 8. IANA Considerations 144 This memo includes no request to IANA. 146 9. References 148 9.1. Normative References 150 [NIST] Dworkin, M., "Recommendation for Block Cipher Modes of 151 Operation: The CMAC Mode for Authentication", 152 . 155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 156 Requirement Levels", BCP 14, RFC 2119, 157 DOI 10.17487/RFC2119, March 1997, 158 . 160 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 161 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 162 2006, . 164 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 165 "Network Time Protocol Version 4: Protocol and Algorithms 166 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 167 . 169 9.2. Informative References 171 [BCK] Bellare, M., Canetti, R., and H. Krawczyk, "Keyed Hash 172 Functions and Message Authentication", in Proceedings of 173 Crypto'96, 1996. 175 [Joux] Joux, A., "Authentication Failures in NIST version of 176 GCM", 177 . 180 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 181 DOI 10.17487/RFC1321, April 1992, 182 . 184 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 185 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 186 RFC 6151, DOI 10.17487/RFC6151, March 2011, 187 . 189 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 190 Agility and Selecting Mandatory-to-Implement Algorithms", 191 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 192 . 194 Authors' Addresses 196 Aanchal Malhotra 197 Boston University 198 111 Cummington St 199 Boston, MA 02215 200 US 202 Email: aanchal4@bu.edu 204 Sharon Goldberg 205 Boston University 206 111 Cummington St 207 Boston, MA 02215 208 US 210 Email: goldbe@cs.bu.edu