draft-ietf-ntp-using-nts-for-ntp-21.txt   draft-ietf-ntp-using-nts-for-ntp-22.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 2, 2020 K. Teichel Expires: August 16, 2020 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
January 30, 2020 February 13, 2020
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-21 draft-ietf-ntp-using-nts-for-ntp-22
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 2, 2020. This Internet-Draft will expire on August 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 3, line 43 skipping to change at page 3, line 43
8.5.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 33 8.5.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 33
8.5.3. Contact Information . . . . . . . . . . . . . . . . . 33 8.5.3. Contact Information . . . . . . . . . . . . . . . . . 33
8.5.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33 8.5.4. Last Update . . . . . . . . . . . . . . . . . . . . . 33
8.6. Implementation 6 . . . . . . . . . . . . . . . . . . . . 33 8.6. Implementation 6 . . . . . . . . . . . . . . . . . . . . 33
8.6.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 34 8.6.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 34
8.6.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34 8.6.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 34
8.6.3. Contact Information . . . . . . . . . . . . . . . . . 34 8.6.3. Contact Information . . . . . . . . . . . . . . . . . 34
8.6.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34 8.6.4. Last Update . . . . . . . . . . . . . . . . . . . . . 34
8.7. Interoperability . . . . . . . . . . . . . . . . . . . . 34 8.7. Interoperability . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9.1. Sensitivity to DDoS attacks . . . . . . . . . . . . . . . 34 9.1. Protected Modes . . . . . . . . . . . . . . . . . . . . . 34
9.2. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 35 9.2. Sensitivity to DDoS Attacks . . . . . . . . . . . . . . . 35
9.3. Initial Verification of Server Certificates . . . . . . . 35 9.3. Avoiding DDoS Amplification . . . . . . . . . . . . . . . 35
9.4. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 37 9.4. Initial Verification of Server Certificates . . . . . . . 36
9.5. Random Number Generation . . . . . . . . . . . . . . . . 37 9.5. Delay Attacks . . . . . . . . . . . . . . . . . . . . . . 37
9.6. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 37 9.6. Random Number Generation . . . . . . . . . . . . . . . . 37
9.7. NTS Stripping . . . . . . . . . . . . . . . . . . . . . . 38
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38
10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 38 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 38
10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 38 10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 39
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 39 12.1. Normative References . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 42 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This memo specifies Network Time Security (NTS), a cryptographic This memo specifies Network Time Security (NTS), a cryptographic
skipping to change at page 5, line 11 skipping to change at page 5, line 13
implementations) may avoid acting as distributed denial-of-service implementations) may avoid acting as distributed denial-of-service
(DDoS) amplifiers by never responding to a request with a packet (DDoS) amplifiers by never responding to a request with a packet
larger than the request packet. larger than the request packet.
o Scalability: Server implementations may serve large numbers of o Scalability: Server implementations may serve large numbers of
clients without having to retain any client-specific state. clients without having to retain any client-specific state.
1.2. Protocol Overview 1.2. Protocol Overview
The Network Time Protocol includes many different operating modes to The Network Time Protocol includes many different operating modes to
support various network topologies. In addition to its best-known support various network topologies (see RFC 5905, Section 3
and most-widely-used client-server mode, it also includes modes for [RFC5905]). In addition to its best-known and most-widely-used
synchronization between symmetric peers, a control mode for server client-server mode, it also includes modes for synchronization
monitoring and administration, and a broadcast mode. These various between symmetric peers, a control mode for server monitoring and
modes have differing and partly contradictory requirements for administration, and a broadcast mode. These various modes have
security and performance. Symmetric and control modes demand mutual differing and partly contradictory requirements for security and
performance. Symmetric and control modes demand mutual
authentication and mutual replay protection. Additionally, for authentication and mutual replay protection. Additionally, for
certain message types control mode may require confidentiality as certain message types control mode may require confidentiality as
well as authentication. Client-server mode places more stringent well as authentication. Client-server mode places more stringent
requirements on resource utilization than other modes, because requirements on resource utilization than other modes, because
servers may have vast number of clients and be unable to afford to servers may have vast number of clients and be unable to afford to
maintain per-client state. However, client-server mode also has more maintain per-client state. However, client-server mode also has more
relaxed security needs, because only the client requires replay relaxed security needs, because only the client requires replay
protection: it is harmless for stateless servers to process replayed protection: it is harmless for stateless servers to process replayed
packets. The security demands of symmetric and control modes, on the packets. The security demands of symmetric and control modes, on the
other hand, are in conflict with the resource-utilization demands of other hand, are in conflict with the resource-utilization demands of
skipping to change at page 14, line 24 skipping to change at page 14, line 24
server MAY incorporate this request when deciding what NTPv4 Server server MAY incorporate this request when deciding what NTPv4 Server
Negotiation and NTPv4 Port Negotiation records to respond with, but Negotiation and NTPv4 Port Negotiation records to respond with, but
honoring the client's preference is OPTIONAL. honoring the client's preference is OPTIONAL.
Servers MAY set the Critical Bit on records of this type; clients Servers MAY set the Critical Bit on records of this type; clients
SHOULD NOT. SHOULD NOT.
4.2. Key Extraction (generally) 4.2. Key Extraction (generally)
Following a successful run of the NTS-KE protocol, key material SHALL Following a successful run of the NTS-KE protocol, key material SHALL
be extracted according to RFC 5705 [RFC5705]. Inputs to the exporter be extracted using the TLS pseudorandom function (PRF) [RFC5705] for
function are to be constructed in a manner specific to the negotiated TLS version 1.2, or the HMAC-based Extract-and-Expand Key Derivation
Next Protocol. However, all protocols which utilize NTS-KE MUST Function (HKDF) [RFC5869] in accordance with RFC 8446, Section 7.5
conform to the following two rules: [RFC8446] for TLS version 1.3. Inputs to the exporter function are
to be constructed in a manner specific to the negotiated Next
Protocol. However, all protocols which utilize NTS-KE MUST conform
to the following two rules:
The disambiguating label string MUST be "EXPORTER-network-time- The disambiguating label string MUST be "EXPORTER-network-time-
security/1". security/1".
The per-association context value MUST be provided and MUST begin The per-association context value MUST be provided and MUST begin
with the two-octet Protocol ID which was negotiated as a Next with the two-octet Protocol ID which was negotiated as a Next
Protocol. Protocol.
5. NTS Extension Fields for NTPv4 5. NTS Extension Fields for NTPv4
5.1. Key Extraction (for NTPv4) 5.1. Key Extraction (for NTPv4)
Following a successful run of the NTS-KE protocol wherein Protocol ID Following a successful run of the NTS-KE protocol wherein Protocol ID
0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be 0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be
extracted: a client-to-server (C2S) key and a server-to-client (S2C) extracted: a client-to-server (C2S) key and a server-to-client (S2C)
key. These keys SHALL be computed according to RFC 5705 [RFC5705], key. These keys SHALL be computed with the PRF defined in RFC 5705
using the following inputs. [RFC5705] for TLS version 1.2, or the HKDF defined in RFC 8446,
Section 7.5 [RFC8446] for TLS version 1.3, using the following
inputs.
The disambiguating label string SHALL be "EXPORTER-network-time- The disambiguating label string (for PRF) or label (for HKDF)
security/1". SHALL be "EXPORTER-network-time-security/1".
The per-association context value SHALL consist of the following The context value SHALL consist of the following five octets:
five octets:
The first two octets SHALL be zero (the Protocol ID for NTPv4). The first two octets SHALL be zero (the Protocol ID for NTPv4).
The next two octets SHALL be the Numeric Identifier of the The next two octets SHALL be the Numeric Identifier of the
negotiated AEAD Algorithm in network byte order. negotiated AEAD Algorithm in network byte order.
The final octet SHALL be 0x00 for the C2S key and 0x01 for the The final octet SHALL be 0x00 for the C2S key and 0x01 for the
S2C key. S2C key.
Implementations wishing to derive additional keys for private or Implementations wishing to derive additional keys for private or
skipping to change at page 34, line 40 skipping to change at page 34, line 40
key establishment protocol and exchange of NTS protected NTP messages key establishment protocol and exchange of NTS protected NTP messages
have been verified successfully. The implementation 2 was able to have been verified successfully. The implementation 2 was able to
successfully perform the key establishment protocol against the successfully perform the key establishment protocol against the
server side of the implementation 5. server side of the implementation 5.
These tests successfully demonstrate that there are at least four These tests successfully demonstrate that there are at least four
running implementations of this draft which are able to interoperate. running implementations of this draft which are able to interoperate.
9. Security Considerations 9. Security Considerations
9.1. Sensitivity to DDoS attacks 9.1. Protected Modes
NTP provides many different operating modes in order to support
different network topologies and to adapt to various requirements.
This memo only specifies NTS for NTP modes 3 (client) and 4 (server)
(see Section 1.2). The best current practice for authenticating the
other NTP modes is using the symmetric message authentication code
feature as described in RFC 5905 [RFC5905] and RFC 8573 [RFC8573].
9.2. Sensitivity to DDoS Attacks
The introduction of NTS brings with it the introduction of asymmetric The introduction of NTS brings with it the introduction of asymmetric
cryptography to NTP. Asymmetric cryptography is necessary for cryptography to NTP. Asymmetric cryptography is necessary for
initial server authentication and AEAD key extraction. Asymmetric initial server authentication and AEAD key extraction. Asymmetric
cryptosystems are generally orders of magnitude slower than their cryptosystems are generally orders of magnitude slower than their
symmetric counterparts. This makes it much harder to build systems symmetric counterparts. This makes it much harder to build systems
that can serve requests at a rate corresponding to the full line that can serve requests at a rate corresponding to the full line
speed of the network connection. This, in turn, opens up a new speed of the network connection. This, in turn, opens up a new
possibility for DDoS attacks on NTP services. possibility for DDoS attacks on NTP services.
The main protection against these attacks in NTS lies in that the use The main protection against these attacks in NTS lies in that the use
of asymmetric cryptosystems is only necessary in the initial NTS-KE of asymmetric cryptosystems is only necessary in the initial NTS-KE
phase of the protocol. Since the protocol design enables separation phase of the protocol. Since the protocol design enables separation
of the NTS-KE and NTP servers, a successful DDoS attack on an NTS-KE of the NTS-KE and NTP servers, a successful DDoS attack on an NTS-KE
server separated from the NTP service it supports will not affect NTP server separated from the NTP service it supports will not affect NTP
users that have already performed initial authentication, AEAD key users that have already performed initial authentication, AEAD key
extraction, and cookie exchange. extraction, and cookie exchange.
NTS users should also consider that they are not fully protected NTS users should also consider that they are not fully protected
against DDoS attacks by on-path adversaries. In addition to dropping against DDoS attacks by on-path adversaries. In addition to dropping
packets and attacks such as those described in Section 9.4, an on- packets and attacks such as those described in Section 9.5, an on-
path attacker can send spoofed kiss-o'-death replies, which are not path attacker can send spoofed kiss-o'-death replies, which are not
authenticated, in response to NTP requests. This could result in authenticated, in response to NTP requests. This could result in
significantly increased load on the NTS-KE server. Implementers have significantly increased load on the NTS-KE server. Implementers have
to weigh the user's need for unlinkability against the added to weigh the user's need for unlinkability against the added
resilience that comes with cookie reuse in cases of NTS-KE server resilience that comes with cookie reuse in cases of NTS-KE server
unavailability. unavailability.
9.2. Avoiding DDoS Amplification 9.3. Avoiding DDoS Amplification
Certain non-standard and/or deprecated features of the Network Time Certain non-standard and/or deprecated features of the Network Time
Protocol enable clients to send a request to a server which causes Protocol enable clients to send a request to a server which causes
the server to send a response much larger than the request. Servers the server to send a response much larger than the request. Servers
which enable these features can be abused in order to amplify traffic which enable these features can be abused in order to amplify traffic
volume in DDoS attacks by sending them a request with a spoofed volume in DDoS attacks by sending them a request with a spoofed
source IP. In recent years, attacks of this nature have become an source IP. In recent years, attacks of this nature have become an
endemic nuisance. endemic nuisance.
NTS is designed to avoid contributing any further to this problem by NTS is designed to avoid contributing any further to this problem by
skipping to change at page 35, line 43 skipping to change at page 36, line 10
sent by the client. In particular, this is why the client is sent by the client. In particular, this is why the client is
required to send a separate and appropriately padded-out NTS Cookie required to send a separate and appropriately padded-out NTS Cookie
Placeholder extension field for every cookie it wants to get back, Placeholder extension field for every cookie it wants to get back,
rather than being permitted simply to specify a desired quantity. rather than being permitted simply to specify a desired quantity.
Due to the RFC 7822 [RFC7822] requirement that extensions be padded Due to the RFC 7822 [RFC7822] requirement that extensions be padded
and aligned to four-octet boundaries, response size may still in some and aligned to four-octet boundaries, response size may still in some
cases exceed request size by up to three octets. This is cases exceed request size by up to three octets. This is
sufficiently inconsequential that we have declined to address it. sufficiently inconsequential that we have declined to address it.
9.3. Initial Verification of Server Certificates 9.4. Initial Verification of Server Certificates
NTS's security goals are undermined if the client fails to verify NTS's security goals are undermined if the client fails to verify
that the X.509 certificate chain presented by the NTS-KE server is that the X.509 certificate chain presented by the NTS-KE server is
valid and rooted in a trusted certificate authority. RFC 5280 valid and rooted in a trusted certificate authority. RFC 5280
[RFC5280] and RFC 6125 [RFC6125] specify how such verification is to [RFC5280] and RFC 6125 [RFC6125] specify how such verification is to
be performed in general. However, the expectation that the client be performed in general. However, the expectation that the client
does not yet have a correctly-set system clock at the time of does not yet have a correctly-set system clock at the time of
certificate verification presents difficulties with verifying that certificate verification presents difficulties with verifying that
the certificate is within its validity period, i.e., that the current the certificate is within its validity period, i.e., that the current
time lies between the times specified in the certificate's notBefore time lies between the times specified in the certificate's notBefore
skipping to change at page 37, line 5 skipping to change at page 37, line 16
server, for example by picking a random time in the week preceding server, for example by picking a random time in the week preceding
certificate expiry to perform the new handshake. certificate expiry to perform the new handshake.
Use multiple time sources. The ability to pass off an expired Use multiple time sources. The ability to pass off an expired
certificate is only useful to an adversary who has compromised the certificate is only useful to an adversary who has compromised the
corresponding private key. If the adversary has compromised only corresponding private key. If the adversary has compromised only
a minority of servers, NTP's selection algorithm (RFC 5905 section a minority of servers, NTP's selection algorithm (RFC 5905 section
11.2.1 [RFC5905]) will protect the client from accepting bad time 11.2.1 [RFC5905]) will protect the client from accepting bad time
from the adversary-controlled servers. from the adversary-controlled servers.
9.4. Delay Attacks 9.5. Delay Attacks
In a packet delay attack, an adversary with the ability to act as a In a packet delay attack, an adversary with the ability to act as a
man-in-the-middle delays time synchronization packets between client man-in-the-middle delays time synchronization packets between client
and server asymmetrically [RFC7384]. Since NTP's formula for and server asymmetrically [RFC7384]. Since NTP's formula for
computing time offset relies on the assumption that network latency computing time offset relies on the assumption that network latency
is roughly symmetrical, this leads to the client to compute an is roughly symmetrical, this leads to the client to compute an
inaccurate value [Mizrahi]. The delay attack does not reorder or inaccurate value [Mizrahi]. The delay attack does not reorder or
modify the content of the exchanged synchronization packets. modify the content of the exchanged synchronization packets.
Therefore, cryptographic means do not provide a feasible way to Therefore, cryptographic means do not provide a feasible way to
mitigate this attack. However, the maximum error that an adversary mitigate this attack. However, the maximum error that an adversary
skipping to change at page 37, line 32 skipping to change at page 37, line 43
client will tolerate before concluding that the server is unsuitable client will tolerate before concluding that the server is unsuitable
for synchronization. The standard value for MAXDIST is one second, for synchronization. The standard value for MAXDIST is one second,
although some implementations use larger values. Whatever value a although some implementations use larger values. Whatever value a
client chooses, the maximum error which can be introduced by a delay client chooses, the maximum error which can be introduced by a delay
attack is MAXDIST/2. attack is MAXDIST/2.
Usage of multiple time sources, or multiple network paths to a given Usage of multiple time sources, or multiple network paths to a given
time source [Shpiner], may also serve to mitigate delay attacks if time source [Shpiner], may also serve to mitigate delay attacks if
the adversary is in control of only some of the paths. the adversary is in control of only some of the paths.
9.5. Random Number Generation 9.6. Random Number Generation
At various points in NTS, the generation of cryptographically secure At various points in NTS, the generation of cryptographically secure
random numbers is required. Whenever this draft specifies the use of random numbers is required. Whenever this draft specifies the use of
random numbers, cryptographically secure random number generation random numbers, cryptographically secure random number generation
MUST be used. RFC 4086 [RFC4086] contains guidelines concerning this MUST be used. RFC 4086 [RFC4086] contains guidelines concerning this
topic. topic.
9.6. NTS Stripping 9.7. NTS Stripping
Implementers must be aware of the possibility of "NTS stripping" Implementers must be aware of the possibility of "NTS stripping"
attacks, where an attacker tricks clients into reverting to plain attacks, where an attacker tricks clients into reverting to plain
NTP. Naive client implementations might, for example, revert NTP. Naive client implementations might, for example, revert
automatically to plain NTP if the NTS-KE handshake fails. A man-in- automatically to plain NTP if the NTS-KE handshake fails. A man-in-
the-middle attacker can easily cause this to happen. Even clients the-middle attacker can easily cause this to happen. Even clients
that already hold valid cookies can be vulnerable, since an attacker that already hold valid cookies can be vulnerable, since an attacker
can force a client to repeat the NTS-KE handshake by sending faked can force a client to repeat the NTS-KE handshake by sending faked
NTP mode 4 replies with the NTS NAK kiss code. Forcing a client to NTP mode 4 replies with the NTS NAK kiss code. Forcing a client to
repeat the NTS-KE handshake can also be the first step in more repeat the NTS-KE handshake can also be the first step in more
skipping to change at page 42, line 14 skipping to change at page 42, line 30
[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>.
[RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code
for the Network Time Protocol", RFC 8573,
DOI 10.17487/RFC8573, June 2019,
<https://www.rfc-editor.org/info/rfc8573>.
[Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time [Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time
Protocols", in Proceedings of IEEE International Symposium Protocols", in Proceedings of IEEE International Symposium
on Precision Clock Synchronization for Measurement, on Precision Clock Synchronization for Measurement,
Control 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]
skipping to change at page 42, line 46 skipping to change at page 43, line 19
IP Internet Protocol IP Internet Protocol
KoD Kiss-o'-Death [RFC5905] KoD Kiss-o'-Death [RFC5905]
NTP Network Time Protocol [RFC5905] NTP Network Time Protocol [RFC5905]
NTS Network Time Security NTS Network Time Security
NTS-KE Network Time Security Key Exchange NTS-KE Network Time Security Key Exchange
PRF Pseudorandom Function
S2C Server-to-client S2C Server-to-client
SCSV Signaling Cipher Suite Value [RFC7507] SCSV Signaling Cipher Suite Value [RFC7507]
TCP Transmission Control Protocol [RFC0793] TCP Transmission Control Protocol [RFC0793]
TLS Transport Layer Security [RFC8446] TLS Transport Layer Security [RFC8446]
UDP User Datagram Protocol [RFC0768] UDP User Datagram Protocol [RFC0768]
Authors' Addresses Authors' Addresses
Daniel Fox Franke Daniel Fox Franke
Akamai Technologies Akamai Technologies
150 Broadway 150 Broadway
Cambridge, MA 02142 Cambridge, MA 02142
United States United States
skipping to change at page 43, line 41 skipping to change at page 44, line 28
Bundesallee 100 Bundesallee 100
Braunschweig D-38116 Braunschweig D-38116
Germany Germany
Phone: +49-(0)531-592-4471 Phone: +49-(0)531-592-4471
Email: kristof.teichel@ptb.de Email: kristof.teichel@ptb.de
Marcus Dansarie Marcus Dansarie
Email: marcus@dansarie.se Email: marcus@dansarie.se
URI: https://orcid.org/0000-0001-9246-0263
Ragnar Sundblad Ragnar Sundblad
Netnod Netnod
Email: ragge@netnod.se Email: ragge@netnod.se
 End of changes. 22 change blocks. 
35 lines changed or deleted 58 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/