idnits 2.17.1 draft-ietf-ntp-mac-00.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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC5905], [RFC4493]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 23, 2016) is 2710 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) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 4493 ** Downref: Normative reference to an Informational RFC: RFC 6151 Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 Intended status: Standards Track Boston University 5 Expires: May 27, 2017 November 23, 2016 7 Message Authentication Code for the Network Time Protocol 8 draft-ietf-ntp-mac-00 10 Abstract 12 RFC 5905 [RFC5905] states that Network Time Protocol (NTP) packets 13 should be authenticated by appending a 128-bit key to the NTP data, 14 and hashing the result with MD5 to obtain a 128-bit tag. This 15 document deprecates the authentication of NTP packets with MD5 and 16 recommends the use of AES-CMAC [RFC4493] as a replacement. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 27, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Deprecating MD5 . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Replacement Recommendation . . . . . . . . . . . . . . . . . 2 56 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 60 6.2. Informative References . . . . . . . . . . . . . . . . . 4 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 RFC 5905 [RFC5905] states that Network Time Protocol (NTP) packets 66 should be authenticated by appending a 128-bit key to the NTP data, 67 and hashing the result with MD5 to obtain a 128-bit tag. This 68 document deprecates the authentication of NTP packets with MD5 and 69 recommends the use of AES-CMAC RFC 4493 [RFC4493] as a replacement. 71 1.1. Requirements Language 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 2. Deprecating MD5 79 RFC 5905 [RFC5905] defines how the MD5 digest algorithm in RFC 1321 80 [RFC1321] can be used as a message authentication code (MAC) for 81 authenticating NTP packets. However, as discussed in [BCK] and RFC 82 6151 [RFC6151], this is not a secure MAC and therefore MUST be 83 deprecated. 85 3. Replacement Recommendation 87 If authentication is implemented, then AES-CMAC as specified in RFC 88 4493 [RFC4493] should be computed over all fields in the NTP header, 89 as well as the NTP key-id field, and any NTP extension fields that 90 are present in the NTP packet. We recommend that the MAC key for NTP 91 should be 128 bits long AES-128 key and the resulting MAC tag should 92 be 128 bits long as stated in section 2.4 of RFC 4493 [RFC4493]. 94 4. Motivation 96 AES-CMAC is recommended for the following reasons: 98 1. It is an IETF standard that is available in many open source 99 implementations. 101 2. It is immune to nonce-reuse vulnerabilities (e.g. [Joux]) 102 because it does not use a nonce. 104 3. It has fine performance in terms of latency and throughput. 105 These are important considerations for NTP, since latency 106 directly affects jitter and therefore the accuracy of time 107 synchronization. 109 4. It benefits from native hardware support, for instance, Intel's 110 New Instruction set. 112 5. Acknowledgements 114 The authors wish to acknowledge useful discussions with Leen 115 Alshenibr, Daniel Franke, Ethan Heilman, Kenny Paterson, Leonid 116 Reyzin, Harlan Stenn, and Mayank Varia. 118 6. References 120 6.1. Normative References 122 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 123 DOI 10.17487/RFC1321, April 1992, 124 . 126 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 127 Requirement Levels", BCP 14, RFC 2119, 128 DOI 10.17487/RFC2119, March 1997, 129 . 131 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 132 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 133 2006, . 135 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 136 "Network Time Protocol Version 4: Protocol and Algorithms 137 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 138 . 140 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 141 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 142 RFC 6151, DOI 10.17487/RFC6151, March 2011, 143 . 145 6.2. Informative References 147 [BCK] Bellare, M., Canetti, R., and H. Krawczyk, "Keyed Hash 148 Functions and Message Authentication", in Proceedings of 149 Crypto'96, 1996. 151 [Joux] Joux, A., "Authentication Failures in NIST version of 152 GCM", 153 . 156 Authors' Addresses 158 Aanchal Malhotra 159 Boston University 160 111 Cummington St 161 Boston, MA 02215 162 US 164 Email: aanchal4@bu.edu 166 Sharon Goldberg 167 Boston University 168 111 Cummington St 169 Boston, MA 02215 170 US 172 Email: goldbe@cs.bu.edu