]> Boston University

111 Cummington St Boston, MA 02215 US aanchal4@bu.edu

Boston University

111 Cummington St Boston, MA 02215 US goldbe@cs.bu.edu

General Internet Engineering Task Force NTP RFC 5905 states that Network Time Protocol (NTP) packets should be authenticated by appending a 128-bit key to the NTP data, and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered to be too weak, and recommends the use of AES-CMAC as a replacement.

RFC 5905 states that Network Time Protocol (NTP) packets should be authenticated by appending a 128-bit key to the NTP data, and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered to be too weak, and recommends the use of AES-CMAC as a replacement.

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 RFC 2119.

RFC 5905 defines how the MD5 digest algorithm in RFC 1321 can be used as a message authentication code (MAC) for authenticating NTP packets. However, as discussed in and RFC 6151 , this is not a secure MAC and therefore MUST be deprecated.

If authentication is implemented, then AES-CMAC as specified in RFC 4493 SHOULD 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 . The MAC key for NTP SHOULD be 128 bits long AES-128 key and the resulting MAC tag SHOULD be 128 bits long as stated in section 2.4 of RFC 4493. NTP makes this transition possible as it supports algorithm agility as described in Section 2.1 of RFC 7696.

AES-CMAC is recommended for the following reasons: It is an IETF standard that is available in many open source implementations. It is immune to nonce-reuse vulnerabilities (e.g. ) because it does not use a nonce. It has fine performance in terms of latency and throughput. It benefits from native hardware support, for instance, Intel's New Instruction set.

For test vectors and their outputs refer to Section 4 of RFC 4493

The authors wish to acknowledge useful discussions with Leen Alshenibr, Daniel Franke, Ethan Heilman, Kenny Paterson, Leonid Reyzin, Harlan Stenn, and Mayank Varia.

This memo includes no request to IANA.

&RFC2119; &RFC5905; &RFC1321; &RFC6151; &RFC4493; &RFC7696;