draft-ietf-ntp-using-nts-for-ntp-16.txt   draft-ietf-ntp-using-nts-for-ntp-17.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: August 12, 2019 K. Teichel Expires: August 17, 2019 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
February 08, 2019 February 13, 2019
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-16 draft-ietf-ntp-using-nts-for-ntp-17
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 August 12, 2019. This Internet-Draft will expire on August 17, 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 12, line 14 skipping to change at page 12, line 14
Clients MUST NOT send records of this type. Servers MUST send at Clients MUST NOT send records of this type. Servers MUST send at
least one record of this type, and SHOULD send eight of them, if the least one record of this type, and SHOULD send eight of them, if the
Next Protocol Negotiation response record contains Protocol ID 0 Next Protocol Negotiation response record contains Protocol ID 0
(NTPv4) and the AEAD Algorithm Negotiation response record is not (NTPv4) and the AEAD Algorithm Negotiation response record is not
empty. The Critical Bit SHOULD NOT be set. empty. The Critical Bit SHOULD NOT be set.
4.1.7. NTPv4 Server Negotiation 4.1.7. NTPv4 Server Negotiation
The NTPv4 Server Negotiation record has a Record Type number of 6. The NTPv4 Server Negotiation record has a Record Type number of 6.
Its body consists of an ASCII-encoded [ANSI.X3-4.1986] string Its body consists of an ASCII-encoded [ANSI.X3-4.1986] string. The
conforming to the syntax of the Host subcomponent of a URI contents of the string SHALL be either an IPv4 address in dotted
([RFC3986]). IPv6 addresses MUST NOT include zone identifiers decimal notation, an IPv6 address, or a fully qualified domain name
[RFC6874]. (FQDN). IPv6 addresses MUST conform to the "Text Representation of
Addresses" as specified in [RFC4291] and MUST NOT include zone
identifiers [RFC6874]. If internationalized labels are needed in the
domain name, the A-LABEL syntax specified in [RFC5891] MUST be used.
When NTPv4 is negotiated as a Next Protocol and this record is sent When NTPv4 is negotiated as a Next Protocol and this record is sent
by the server, the body specifies the hostname or IP address of the by the server, the body specifies the hostname or IP address of the
NTPv4 server with which the client should associate and which will NTPv4 server with which the client should associate and which will
accept the supplied cookies. If no record of this type is sent, the accept the supplied cookies. If no record of this type is sent, the
client SHALL interpret this as a directive to associate with an NTPv4 client SHALL interpret this as a directive to associate with an NTPv4
server at the same IP address as the NTS-KE server. Servers MUST NOT server at the same IP address as the NTS-KE server. Servers MUST NOT
send more than one record of this type. send more than one record of this type.
When this record is sent by the client, it indicates that the client When this record is sent by the client, it indicates that the client
skipping to change at page 34, line 47 skipping to change at page 34, line 47
them. them.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Richard Barnes, Steven Bellovin, The authors would like to thank Richard Barnes, Steven Bellovin,
Patrik Faeltstroem (Faltstrom), Scott Fluhrer, Sharon Goldberg, Russ Patrik Faeltstroem (Faltstrom), Scott Fluhrer, Sharon Goldberg, Russ
Housley, Martin Langer, Miroslav Lichvar, Aanchal Malhotra, Dave Housley, Martin Langer, Miroslav Lichvar, Aanchal Malhotra, Dave
Mills, Danny Mayer, Karen O'Donoghue, Eric K. Rescorla, Stephen Mills, Danny Mayer, Karen O'Donoghue, Eric K. Rescorla, Stephen
Roettger, Kurt Roeckx, Kyle Rose, Rich Salz, Brian Sniffen, Susan Roettger, Kurt Roeckx, Kyle Rose, Rich Salz, Brian Sniffen, Susan
Sons, Douglas Stebila, Harlan Stenn, Joachim Stroembergsson Sons, Douglas Stebila, Harlan Stenn, Joachim Stroembergsson
(Strombergsson), Martin Thomson, and Richard Welty for contributions (Strombergsson), Martin Thomson, Richard Welty, and Christer Weinigel
to this document and comments on the design of NTS. for contributions to this document and comments on the design of NTS.
12. References 12. References
12.1. Normative References 12.1. Normative References
[ANSI.X3-4.1986] [ANSI.X3-4.1986]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Resource Identifier (URI): Generic Syntax", STD 66, Architecture", RFC 4291, DOI 10.17487/RFC4291, February
RFC 3986, DOI 10.17487/RFC3986, January 2005, 2006, <https://www.rfc-editor.org/info/rfc4291>.
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV)
Authenticated Encryption Using the Advanced Encryption Authenticated Encryption Using the Advanced Encryption
Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October
2008, <https://www.rfc-editor.org/info/rfc5297>. 2008, <https://www.rfc-editor.org/info/rfc5297>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
 End of changes. 8 change blocks. 
14 lines changed or deleted 21 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/