1. November 14, 2016
Secure MAC algorithms for use with NTP draft-aanchal4-ntp-mac-03 CFRG: IETF97
Aanchal Malhotra
Sharon Goldberg

2. Message Digest = 324a4b23130fff3eab4581931ee6fa5d4
NTP packet v4
IHL
TOS
Length
IPID
Frag Offset
TTL
Protocol = 17
IP Header Checksum
Source IP
Destination IP
Source Port
Dest Port = 123
Checksum LI v
Mode 5
Stratum
Poll
Precision
Root Delay
Root Dispersion
Reference ID
Reference Timestamp
Origin Timestamp
Receive Timestamp
Transmit Timestamp
Key ID =
Message Digest = 324a4b23130fff3eab ee6fa5d4
IP header
UDP header
NTP data
NTP packet. Fill in the TOS field – ask Aanchal.
NTP MAC

3. RFC5905 suggests MD5 (key||message) for NTP
Why is this bad?
MD5 as a hash function is not collision resistant
vulnerable to length extension attack
Consequently, RFC 6151 says not to use MD5 for authentication this way

4. Updating NTP’s MAC: potential algorithms
Input Key-Length (bytes)
Output Tag Length (bytes)
Legacy MD5 16
HMAC-MD5 [RFC 4868]
HMAC -SHA224 [RFC 4868]
CMAC (AES) [RFC 4493]
GMAC (AES) [RFC 4543]
Poly1305 (ChaCha20) [RFC 7539]
We try to include a mix of hash based and cipher based MAC algorithms. Part of the reason for choosing these is the standardization and open source implementations available for these.
The upper bound on the security is by 2^128
We include these just for performance comparison

5. NTP’s performance requirements for its MAC
Constant Computational Latency:
fewer clock cycles for computation is better
this directly translates to a reduction in jitter
Throughput:
NTP servers deal with thousands of requests per second
NIST's NTP stratum 1 servers cater to 28,000 requests/second/server on an average

6. Performance: latency in clock cycles per byte
Hardware Platform: x86_64, Intel(R) Xeon(R) CPU E GHz with one core CPU
Algorithm
with AES-NI
w/o AES-NI
Legacy MD5
16.0
15.7
HMAC –MD5
18.2
18.1
HMAC -SHA224
39.4
39.0
CMAC (AES)
6.6
11.3
GMAC (AES)
3.0
10.8
Poly1305-ChaCha20
14.4
15.0
Latency in terms of number of CPU cycles per byte (cpb)
when processing a 48-byte NTP payload.

7. Performance: latency in clock cycles per byte
Apple 1.5GHz
ARM 1GHz (dual core)
ARM 1.2GHz (quad core)
Marvell 1.2GHz 88FR131
Algorithm
PPC74xx
ARM Cortex-A9
ARM Cortex-A53
Marvell
Legacy MD5
52.1
38.4
33.4
65.3
HMAC (MD5)
67.4
50.3
29.0
57.1
HMAC (SHA224)
113.3
85.2
70.1
166.5
CMAC (AES)
54.2
50.5
40.7
101.2
GMAC (AES)
50.0
15.3
11.4
55.1
Poly1305-ChaCha20
93.1
55.0
43.1
91.7
Latency in terms of number of CPU cycles per byte (cpb)
when processing a 48-byte NTP payload.

8. NTP-specific constraints with using GMAC
NTP servers are stateless
Symmetric key is shared by many servers (typically at the same stratum)
Why is this a problem?
Nonce Reuse vulnerability of GMAC : can recover authentication key
Nonce length = 96 bits
High probability of collision after 2^48 messages (birthday bound)
NTP server is stateless - does not know when to refresh keys for a client
An MiTM can replay messages and exhaust this number very fast
Because there is no good mechanism to share keys.

9. We recommend CMAC for now!
Recommendations
Algorithm
Performance
Security
GMAC
best
weak
CMAC
medium
good
HMAC
poor
We recommend CMAC for now!
CMAC (AES) – based on cipher block chaining (CBC) mode
Less implementation pitfalls (no nonce use/reuse issues)

10. Other potential MAC candidates
IETF draft for Network Time Security [1] suggests using AEAD_AES_SIV_CMAC_256 [RFC5297] because:
Requires unlinkability property for privacy
robust against accidental nonce-reuse
GCM-SIV
Nonce misuse resistant
GMAC-SIV takes ~5.9 CPU cycles/byte (compared to ~3 on GMAC and ~6.6 on CMAC)
Still an Internet draft. Not widely implemented?
SipHash (PRF?) - Optimized to work with short messages
Other CAESAR AEAD competition candidates
References
[1]

11. Questions for cfrg? Is there a better option?
Can we use GCM/GMAC in a way that is nonce misuse resistant?
Any other insights?