draft-ietf-ntp-using-nts-for-ntp-18.txt   draft-ietf-ntp-using-nts-for-ntp-19.txt 
NTP Working Group D. Franke NTP Working Group D. Franke
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track D. Sibold Intended status: Standards Track D. Sibold
Expires: October 19, 2019 K. Teichel Expires: November 1, 2019 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
April 17, 2019 April 30, 2019
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-18 draft-ietf-ntp-using-nts-for-ntp-19
Abstract Abstract
This memo specifies Network Time Security (NTS), a mechanism for This memo specifies Network Time Security (NTS), a mechanism for
using Transport Layer Security (TLS) and Authenticated Encryption using Transport Layer Security (TLS) and Authenticated Encryption
with Associated Data (AEAD) to provide cryptographic security for the with Associated Data (AEAD) to provide cryptographic security for the
client-server mode of the Network Time Protocol (NTP). client-server mode of the Network Time Protocol (NTP).
NTS is structured as a suite of two loosely coupled sub-protocols. NTS is structured as a suite of two loosely coupled sub-protocols.
The first (NTS-KE) handles initial authentication and key The first (NTS-KE) handles initial authentication and key
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 19, 2019. This Internet-Draft will expire on November 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 18, line 17 skipping to change at page 18, line 17
K: For packets sent from the client to the server, the C2S key K: For packets sent from the client to the server, the C2S key
SHALL be used. For packets sent from the server to the client, SHALL be used. For packets sent from the server to the client,
the S2C key SHALL be used. the S2C key SHALL be used.
A: The associated data SHALL consist of the portion of the NTP A: The associated data SHALL consist of the portion of the NTP
packet beginning from the start of the NTP header and ending at packet beginning from the start of the NTP header and ending at
the end of the last extension field which precedes the NTS the end of the last extension field which precedes the NTS
Authenticator and Encrypted Extension Fields extension field. Authenticator and Encrypted Extension Fields extension field.
P: the plaintext SHALL consist of all (if any) NTP extension P: The plaintext SHALL consist of all (if any) NTP extension
fields to be encrypted; if multiple extension fields are present fields to be encrypted; if multiple extension fields are present
they SHALL be joined by concatenation. Each such field SHALL be they SHALL be joined by concatenation. Each such field SHALL be
formatted in accordance with RFC 7822 [RFC7822], except that, formatted in accordance with RFC 7822 [RFC7822], except that,
contrary to the RFC 7822 requirement that fields have a minimum contrary to the RFC 7822 requirement that fields have a minimum
length of 16 or 28 octets, encrypted extension fields MAY be length of 16 or 28 octets, encrypted extension fields MAY be
arbitrarily short (but still MUST be a multiple of 4 octets in arbitrarily short (but still MUST be a multiple of 4 octets in
length). length).
N: The nonce SHALL be formed however required by the negotiated N: The nonce SHALL be formed however required by the negotiated
AEAD algorithm. AEAD algorithm.
skipping to change at page 20, line 13 skipping to change at page 20, line 13
successful volley. successful volley.
In rare circumstances, it may be necessary to include fewer NTS In rare circumstances, it may be necessary to include fewer NTS
Cookie Placeholder extensions than recommended above in order to Cookie Placeholder extensions than recommended above in order to
prevent datagram fragmentation. When cookies adhere the format prevent datagram fragmentation. When cookies adhere the format
recommended in Section 6 and the AEAD in use is the mandatory-to- recommended in Section 6 and the AEAD in use is the mandatory-to-
implement AEAD_AES_SIV_CMAC_256, senders can include a cookie and implement AEAD_AES_SIV_CMAC_256, senders can include a cookie and
seven placeholders and still have packet size fall comfortably below seven placeholders and still have packet size fall comfortably below
1280 octets if no non-NTS-related extensions are used; 1280 octets is 1280 octets if no non-NTS-related extensions are used; 1280 octets is
the minimum prescribed MTU for IPv6 and is in practice also safe for the minimum prescribed MTU for IPv6 and is in practice also safe for
avoiding IPv4 fragmentation. Nonetheless, Nonetheless, senders avoiding IPv4 fragmentation. Nonetheless, senders SHOULD include
SHOULD include fewer cookies and placeholders than otherwise fewer cookies and placeholders than otherwise indicated if doing so
indicated if doing so is necessary to prevent fragmentation. is necessary to prevent fragmentation.
+---------------------------------------+ +---------------------------------------+
| - Verify time request message | | - Verify time request message |
| - Generate time response message | | - Generate time response message |
| - Included NTPv4 extension fields | | - Included NTPv4 extension fields |
| o Unique Identifier EF | | o Unique Identifier EF |
| o NTS Authentication and | | o NTS Authentication and |
| Encrypted Extension Fields EF | | Encrypted Extension Fields EF |
| - NTS Cookie EF | | - NTS Cookie EF |
| - <NTS Cookie EF> | | - <NTS Cookie EF> |
skipping to change at page 32, line 22 skipping to change at page 32, line 22
This implementation was used to verify consistency and to ensure This implementation was used to verify consistency and to ensure
completeness of this specification. completeness of this specification.
8.3.1. Coverage 8.3.1. Coverage
This implementation covers the complete specification. This implementation covers the complete specification.
8.3.2. Licensing 8.3.2. Licensing
Kicensing is GPLv2. Licensing is GPLv2.
The source code is available at: https://github.com/mlichvar/chrony- The source code is available at: https://github.com/mlichvar/chrony-
nts nts
8.3.3. Contact Information 8.3.3. Contact Information
Contact Miroslav Lichvar: mlichvar@redhat.com Contact Miroslav Lichvar: mlichvar@redhat.com
8.3.4. Last Update 8.3.4. Last Update
skipping to change at page 42, line 14 skipping to change at page 42, line 14
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[Shpiner] Mizrahi, A. S. Y. R. A. T., "Multi-path Time Protocols", [Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time
in Proceedings of IEEE International Symposium on Protocols", in Proceedings of IEEE International Symposium
Precision Clock Synchronization for Measurement, Control on Precision Clock Synchronization for Measurement,
and Communication (ISPCS), September 2013. Control and Communication (ISPCS), September 2013.
Appendix A. Terms and Abbreviations Appendix A. Terms and Abbreviations
AEAD Authenticated Encryption with Associated Data [RFC5116] AEAD Authenticated Encryption with Associated Data [RFC5116]
ALPN Application-Layer Protocol Negotiation [RFC7301] ALPN Application-Layer Protocol Negotiation [RFC7301]
C2S Client-to-server C2S Client-to-server
DDoS Distributed Denial-of-Service DDoS Distributed Denial-of-Service
 End of changes. 8 change blocks. 
13 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/