draft-ietf-ntp-roughtime-00.txt   draft-ietf-ntp-roughtime-01.txt 
Internet Engineering Task Force A. Malhotra Internet Engineering Task Force A. Malhotra
Internet-Draft Boston University Internet-Draft Boston University
Intended status: Informational A. Langley Intended status: Informational A. Langley
Expires: July 30, 2020 Google Expires: October 3, 2020 Google
W. Ladd W. Ladd
Cloudflare Cloudflare
January 27, 2020 April 1, 2020
Roughtime Roughtime
draft-ietf-ntp-roughtime-00 draft-ietf-ntp-roughtime-01
Abstract Abstract
This document specifies Roughtime - a protocol that aims to achieve This document specifies Roughtime - a protocol that aims to achieve
rough time synchronization while detecting servers that provide rough time synchronization while detecting servers that provide
inaccurate time and providing cryptographic proof of their inaccurate time and providing cryptographic proof of their
malfeasance. malfeasance.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 July 30, 2020. This Internet-Draft will expire on October 3, 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 2, line 12 skipping to change at page 2, line 12
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. The guarantee . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The Guarantee . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. uint32 . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. int32 . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. uint64 . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. uint32 . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.3. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.3. uint64 . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . 7 5.1.4. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.5. Timestamp . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 9 6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 11
6.3.1. Root value validity check algorithm . . . . . . . . . 10 6.3.1. Root Value Validity Check Algorithm . . . . . . . . . 11
6.4. Validity of response . . . . . . . . . . . . . . . . . . 10 6.4. Validity of Response . . . . . . . . . . . . . . . . . . 12
7. Integration into ntp . . . . . . . . . . . . . . . . . . . . 10 7. Integration into NTP . . . . . . . . . . . . . . . . . . . . 12
8. Cheater Detection . . . . . . . . . . . . . . . . . . . . . . 11 8. Cheater Detection . . . . . . . . . . . . . . . . . . . . . . 13
9. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 12 10. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 13
11. Trust anchors and policies . . . . . . . . . . . . . . . . . 12 11. Trust Anchors and Policies . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13.1. Service Name and Transport Protocol Port Number Registry 13 13.1. Service Name and Transport Protocol Port Number Registry 14
13.2. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 13 13.2. Roughtime Version Registry . . . . . . . . . . . . . . . 15
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 13.3. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 15
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
16.1. Normative References . . . . . . . . . . . . . . . . . . 15 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
16.2. Informative References . . . . . . . . . . . . . . . . . 16 16.1. Normative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 17 16.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Time synchronization is essential to Internet security as many Time synchronization is essential to Internet security as many
security protocols and other applications require synchronization security protocols and other applications require synchronization
[RFC7384] [MCBG]. Unfortunately widely deployed protocols such as [RFC7384] [MCBG]. Unfortunately widely deployed protocols such as
the Network Time Protocol (NTP) [RFC5905] lack essential security the Network Time Protocol (NTP) [RFC5905] lack essential security
features, and even newer protocols like Network Time Security (NTS) features, and even newer protocols like Network Time Security (NTS)
[I-D.ietf-ntp-using-nts-for-ntp] fail to ensure that the servers [I-D.ietf-ntp-using-nts-for-ntp] fail to ensure that the servers
behave correctly. Authenticating time servers prevents network behave correctly. Authenticating time servers prevents network
adversaries from modifying time packets, but an authenticated time adversaries from modifying time packets, but an authenticated time
server still has full control over the contents of the time packet server still has full control over the contents of the time packet
and may go rogue. The Roughtime protocol provides cryptographic and may go rogue. The Roughtime protocol provides cryptographic
proof of malfeasance, enabling clients to detect and prove to a third proof of malfeasance, enabling clients to detect and prove to a third
party a server's attempts to influence the time a client computes. party a server's attempts to influence the time a client computes.
+--------------+----------------------+-----------------------------+ +--------------+----------------------+-----------------------------+
| Protocol | Authenticated Server | Server Malfeasance Evidence | | Protocol | Authenticated Server | Server Malfeasance Evidence |
skipping to change at page 5, line 27 skipping to change at page 5, line 31
With only two servers, the client can end up with proof that With only two servers, the client can end up with proof that
something is wrong, but no idea what the correct time is. But with something is wrong, but no idea what the correct time is. But with
half a dozen or more independent servers, the client will end up with half a dozen or more independent servers, the client will end up with
chain of proof of any server's misbehavior, signed by several others, chain of proof of any server's misbehavior, signed by several others,
and (presumably) enough accurate replies to establish what the and (presumably) enough accurate replies to establish what the
correct time is. Furthermore, this proof may be validated by third correct time is. Furthermore, this proof may be validated by third
parties ultimately leading to a revocation of trust in the parties ultimately leading to a revocation of trust in the
misbehaving server. misbehaving server.
4. The guarantee 4. The Guarantee
A Roughtime server guarantees that a response to a query sent at t_1, A Roughtime server guarantees that a response to a query sent at t_1,
received at t_2, and with timestamp t_3 has been created between the received at t_2, and with timestamp t_3 has been created between the
transmission of the query and its reception. If t_3 is not within transmission of the query and its reception. If t_3 is not within
that interval, a server inconsistency may be detected and used to that interval, a server inconsistency may be detected and used to
impeach the server. The propagation of such a guarantee and its use impeach the server. The propagation of such a guarantee and its use
of type synchronization is discussed in Section 7. No delay attacker of type synchronization is discussed in Section 7. No delay attacker
may affect this: they may only expand the interval between t_1 and may affect this: they may only expand the interval between t_1 and
t_2, or of course stop the measurement in the first place. t_2, or of course stop the measurement in the first place.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
. . . .
. Values . . Values .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Roughtime Message Format Figure 1: Roughtime Message Format
5.1. Data Types 5.1. Data Types
5.1.1. uint32 5.1.1. int32
An int32 is a 32 bit signed integer. It is serialized in sign-
magitude representation with the sign bit in the most significant
bit. It is serialized least significant byte first. The negative
zero value (0x80000000) MUST NOT be used.
5.1.2. uint32
A uint32 is a 32 bit unsigned integer. It is serialized with the A uint32 is a 32 bit unsigned integer. It is serialized with the
least significant byte first. least significant byte first.
5.1.2. uint64 5.1.3. uint64
A uint64 is a 64 bit unsigned integer. It is serialized with the A uint64 is a 64 bit unsigned integer. It is serialized with the
least significant byte first. least significant byte first.
5.1.3. Tag 5.1.4. Tag
Tags are used to identify values in Roughtime packets. A tag is a Tags are used to identify values in Roughtime messages. A tag is a
uint32 but may also be listed as a sequence of up to four ASCII uint32 but may also be listed as a sequence of up to four ASCII
characters [RFC0020]. ASCII strings shorter than four characters can characters [RFC0020]. ASCII strings shorter than four characters can
be unambiguously converted to tags by padding them with zero bytes. be unambiguously converted to tags by padding them with zero bytes.
For example, the ASCII string "NONC" would correspond to the tag For example, the ASCII string "NONC" would correspond to the tag
0x434e4f4e and "PAD" would correspond to 0x00444150. 0x434e4f4e and "PAD" would correspond to 0x00444150.
5.1.4. Timestamp 5.1.5. Timestamp
A timestamp is a uint64 interpreted in the following way. The most A timestamp is a uint64 interpreted in the following way. The most
significant 3 bytes contain the integer part of a Modified Julian significant 3 bytes contain the integer part of a Modified Julian
Date (MJD). The least significant 5 bytes is a count of the number Date (MJD). The least significant 5 bytes is a count of the number
of Coordinated Universal Time (UTC) microseconds [ITU-R_TF.460-6] of Coordinated Universal Time (UTC) microseconds [ITU-R_TF.460-6]
since midnight on that day. since midnight on that day.
The MJD is the number of UTC days since 17 November 1858 The MJD is the number of UTC days since 17 November 1858
[ITU-R_TF.457-2]. [ITU-R_TF.457-2].
skipping to change at page 7, line 33 skipping to change at page 7, line 42
the header is the uint32 number of tags N, and hence of (tag, value) the header is the uint32 number of tags N, and hence of (tag, value)
pairs. The following 4*(N-1) bytes are offsets, each a uint32. The pairs. The following 4*(N-1) bytes are offsets, each a uint32. The
last 4*N bytes in the header are tags. last 4*N bytes in the header are tags.
Offsets refer to the positions of the values in the message values Offsets refer to the positions of the values in the message values
section. All offsets MUST be multiples of four and placed in section. All offsets MUST be multiples of four and placed in
increasing order. The first post-header byte is at offset 0. The increasing order. The first post-header byte is at offset 0. The
offset array is considered to have a not explicitly encoded value of offset array is considered to have a not explicitly encoded value of
0 as its zeroth entry. The value associated with the ith tag begins 0 as its zeroth entry. The value associated with the ith tag begins
at offset[i] and ends at offset[i+1]-1, with the exception of the at offset[i] and ends at offset[i+1]-1, with the exception of the
last value which ends at the end of the packet. Values may have zero last value which ends at the end of the message. Values may have
length. zero length.
Tags MUST be listed in the same order as the offsets of their values. Tags MUST be listed in the same order as the offsets of their values.
A tag MUST NOT appear more than once in a header. A tag MUST NOT appear more than once in a header.
6. Protocol 6. Protocol
Roughtime messages are sent between clients and servers as UDP As described in Section 3, clients initiate time synchronization by
packets, or over TCP. When transporting over TCP, the packets are sending requests containing a nonce to servers who send signed time
prefixed with their length as a uint32. Currently no servers exist responses in return. Roughtime packets can be sent between clients
for the TCP version. As described in Section 3, clients initiate and servers either as UDP datagrams or via TCP streams. Servers
time synchronization by sending request packets containing a nonce to SHOULD support the UDP transport mode, while TCP transport is
servers who send signed time responses in return. OPTIONAL.
A Roughtime packet MUST be formatted according to Figure 2 and as
described here. The first field is a uint64 with the value
0x4d49544847554f52 ("ROUGHTIM" in ASCII). The second field is a
uint32 and contains the length of the third field. The third and
last field contains a Roughtime message as specified in Section 5.1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x4d49544847554f52 (uint32) |
| ("ROUGHTIM") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message length (uint32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Roughtime message .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Roughtime Packet Format
Roughtime request and response packets MUST be transmitted in a
single datagram when the UDP transport mode is used. Setting the
packet's don't fragment bit [RFC0791] is OPTIONAL in IPv4 networks.
Multiple requests and responses can be exchanged over an established
TCP connection. Clients MAY send multiple requests at once and
servers MAY send responses out of order. The connection SHOULD be
closed by the client when it has no more requests to send and has
received all expected responses. Either side SHOULD close the
connection in response to synchronization, format, implementation-
defined timeouts, or other errors.
All requests and responses MUST contain the VER tag. It contains a
list of one or more uint32 version numbers. The version of Roughtime
specified by this memo has version number 1.
For testing drafts of this memo, a version number of 0x80000000 plus
the draft number is used.
6.1. Requests 6.1. Requests
A request is a Roughtime message with the tag NONC. The size of the A request is a Roughtime message with the tags NONC and VER. Over a
request message SHOULD be at least 1024 bytes. To attain this size UDP connection the size of the request message SHOULD be at least
the PAD tag SHOULD be added to the message. Tags other than NONC 1024 bytes. To attain this size the PAD tag SHOULD be added to the
SHOULD be ignored by the server. Responding to requests shorter than message. Tags other than NONC and VER SHOULD be ignored by the
1024 bytes is OPTIONAL and servers MUST NOT send responses larger server. Responding to requests shorter than 1024 bytes is OPTIONAL
than the requests they are replying to. and servers MUST NOT send responses larger than the requests they are
replying to.
The value of the NONC tag is a 64 byte nonce. It SHOULD be generated The value of the NONC tag is a 64 byte nonce. It SHOULD be generated
by hashing a previous Roughtime response message together with a by hashing a previous Roughtime response message together with a
blind as described in Section 8. If no previous responses are blind as described in Section 8. If no previous responses are
avaiable to the client, the nonce SHOULD be generated at random. avaiable to the client, the nonce SHOULD be generated at random.
In a request, the VER tag contains a list of versions. The VER tag
MUST include at least one Roughtime version supported by the client.
The client MUST ensure that the version numbers and tags included in
the request are not incompatible with each other or the packet
contents.
The PAD tag SHOULD be used by clients to ensure their request The PAD tag SHOULD be used by clients to ensure their request
messages are at least 1024 bytes in size. Its value SHOULD be all messages are at least 1024 bytes in size. Its value SHOULD be all
zeros. zeros.
6.2. Responses 6.2. Responses
A response contains the tags SREP, SIG, CERT, INDX, and PATH. The A response MUST contain the tags SREP, SIG, CERT, INDX, PATH and VER.
SIG tag is a signature over the SREP value using the public key The SIG tag is a signature over the SREP value using the public key
contained in CERT, as explained below. contained in CERT, as explained below.
The SREP tag contains a time response. Its value is a Roughtime The SREP tag contains a time response. Its value is a Roughtime
message with the tags ROOT, MIDP, and RADI. message with the tags ROOT, MIDP, and RADI, and NONC. The server MAY
include any of the tags DUT1, DTAI and LEAP in the contents of the
SREP tag.
The ROOT tag contains a 32 byte value of a Merkle tree root as The ROOT tag contains a 32 byte value of a Merkle tree root as
described in Section 6.3. described in Section 6.3.
The MIDP tag value is a timestamp of the moment of processing. The MIDP tag value is a timestamp of the moment of processing.
The RADI tag value is a uint32 representing the server's estimate of The RADI tag value is a uint32 representing the server's estimate of
the accuracy of MIDP in microseconds. Servers MUST ensure that the the accuracy of MIDP in microseconds. Servers MUST ensure that the
true time is within (MIDP-RADI, MIDP+RADI) at the time they compose true time is within (MIDP-RADI, MIDP+RADI) at the time they compose
the response packet. the response message.
The NONC tag contains the nonce of the message being responded to.
The DUT1 tag value is an int32 indicating the predicted difference
between UT1 and UTC (UT1 - UTC) in milliseconds as given by the
International Earth Rotation and Reference Systems Service (IERS).
The DTAI tag value is an int32 indicating the current difference
between International Atomic Time (TAI) and UTC (TAI - UTC) in
milliseconds as published in the International Bureau of Weights and
Measures' (BIPM) Circular T.
The LEAP tag contains zero or more int32 values. Each value
represents the MJD of a past or future leap second event. Positive
values represent the addition of a second at the indicated date and
negative values represent the removal of a second at the indicated
(negative) date. The first item in the list MUST be the last (past
or future) leap second event that the server knows about. The leap
second events MUST be sorted in reverse chronological order. A leap
tag with zero int32 values indicates that the server does not hold
any updated leap second information.
The SIG tag value is a 64 byte Ed25519 signature [RFC8032] over a The SIG tag value is a 64 byte Ed25519 signature [RFC8032] over a
signature context concatenated with the entire value of a DELE or signature context concatenated with the entire value of a DELE or
SREP tag. Signatures of DELE tags use the ASCII string "RoughTime v1 SREP tag. Signatures of DELE tags MUST use the ASCII string
delegation signature--" and signatures of SREP tags use the ASCII "RoughTime v1 delegation signature--" and signatures of SREP tags
string "RoughTime v1 response signature" as signature context. Both MUST use the ASCII string "RoughTime v1 response signature" as
strings include a terminating zero byte. signature context. Both strings MUST include a terminating zero
byte.
The CERT tag contains a public-key certificate signed with the The CERT tag contains a public-key certificate signed with the
server's long-term key. Its value is a Roughtime message with the server's long-term key. Its value is a Roughtime message with the
tags DELE and SIG, where SIG is a signature over the DELE value. tags DELE and SIG, where SIG is a signature over the DELE value.
The DELE tag contains a delegated public-key certificate used by the The DELE tag contains a delegated public-key certificate used by the
server to sign the SREP tag. Its value is a Roughtime message with server to sign the SREP tag. Its value is a Roughtime message with
the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to
enable separation of a long-term public key from keys on devices enable separation of a long-term public key from keys on devices
exposed to the public Internet. exposed to the public Internet.
skipping to change at page 9, line 26 skipping to change at page 11, line 15
The INDX tag value is a uint32 determining the position of NONC in The INDX tag value is a uint32 determining the position of NONC in
the Merkle tree used to generate the ROOT value as described in the Merkle tree used to generate the ROOT value as described in
Section 6.3. Section 6.3.
The PATH tag value is a multiple of 32 bytes long and represents a The PATH tag value is a multiple of 32 bytes long and represents a
path of 32 byte hash values in the Merkle tree used to generate the path of 32 byte hash values in the Merkle tree used to generate the
ROOT value as described in Section 6.3. In the case where a response ROOT value as described in Section 6.3. In the case where a response
is prepared for a single request and the Merkle tree contains only is prepared for a single request and the Merkle tree contains only
the root node, the size of PATH is zero. the root node, the size of PATH is zero.
In a response, the VER tag MUST contain a single version number. It
SHOULD be one of the version numbers supplied by the client in its
request. The server MUST ensure that the version number corresponds
with the rest of the packet contents.
6.3. The Merkle Tree 6.3. The Merkle Tree
A Merkle tree is a binary tree where the value of each non-leaf node A Merkle tree is a binary tree where the value of each non-leaf node
is a hash value derived from its two children. The root of the tree is a hash value derived from its two children. The root of the tree
is thus dependent on all leaf nodes. is thus dependent on all leaf nodes.
In Roughtime, each leaf node in the Merkle tree represents the nonce In Roughtime, each leaf node in the Merkle tree represents the nonce
of one request that a response message is sent in reply to. Leaf of one request that a response message is sent in reply to. Leaf
nodes are indexed left to right, beginning with zero. nodes are indexed left to right, beginning with zero.
skipping to change at page 10, line 5 skipping to change at page 11, line 48
of the response. of the response.
The index of a request's nonce node is included in the INDX tag of The index of a request's nonce node is included in the INDX tag of
the response. the response.
The values of all sibling nodes in the path between a request's nonce The values of all sibling nodes in the path between a request's nonce
node and the root node is stored in the PATH tag so that the client node and the root node is stored in the PATH tag so that the client
can reconstruct and validate the value in the ROOT tag using its can reconstruct and validate the value in the ROOT tag using its
nonce. nonce.
6.3.1. Root value validity check algorithm 6.3.1. Root Value Validity Check Algorithm
One starts by computing the hash of the NONC value from the request, One starts by computing the hash of the NONC value from the request,
with 0x00 prepended. Then one walks from the least significant bit with 0x00 prepended. Then one walks from the least significant bit
of INDX to the most significant bit, and also walks towards the end of INDX to the most significant bit, and also walks towards the end
of PATH. of PATH.
If PATH ends then the remaining bits of the INDX MUST be all zero. If PATH ends then the remaining bits of the INDX MUST be all zero.
This indicates the termination of the walk, and the current value This indicates the termination of the walk, and the current value
MUST equal ROOT if the response is valid. MUST equal ROOT if the response is valid.
If the current bit is 0, one hashes 0x01, the current hash, and the If the current bit is 0, one hashes 0x01, the current hash, and the
value from PATH to derive the next current value. value from PATH to derive the next current value.
If the current bit is 1 one hashes 0x01, the value from PATH, and the If the current bit is 1 one hashes 0x01, the value from PATH, and the
current hash to derive the next current value. current hash to derive the next current value.
6.4. Validity of response 6.4. Validity of Response
A client MUST check the following properties when it receives a A client MUST check the following properties when it receives a
response. We assume the long-term server public key is known to the response. We assume the long-term server public key is known to the
client through other means. client through other means.
o The signature in CERT was made with the long-term key of the o The signature in CERT was made with the long-term key of the
server. server.
o The DELE timestamps and the MIDP value are consistent. o The DELE timestamps and the MIDP value are consistent.
skipping to change at page 10, line 44 skipping to change at page 12, line 39
tree with value ROOT using the algorithm in Section 6.3.1. tree with value ROOT using the algorithm in Section 6.3.1.
o The signature of SREP in SIG validates with the public key in o The signature of SREP in SIG validates with the public key in
DELE. DELE.
A response that passes these checks is said to be valid. Validity of A response that passes these checks is said to be valid. Validity of
a response does not prove the time is correct, but merely that the a response does not prove the time is correct, but merely that the
server signed it, and thus guarantees that it began to compute the server signed it, and thus guarantees that it began to compute the
signature at a time in the interval (MIDP-RADI, MIDP+RADI). signature at a time in the interval (MIDP-RADI, MIDP+RADI).
7. Integration into ntp 7. Integration into NTP
We assume that there is a bound PHI on the frequency error in the We assume that there is a bound PHI on the frequency error in the
clock on the machine. Given a measurement taken at a local time t1, clock on the machine. Given a measurement taken at a local time t1,
we know the true time is in [ t1-delta-sigma, t1-delta+sigma ]. we know the true time is in [ t1-delta-sigma, t1-delta+sigma ].
After d seconds have elapsed we know the true time is within [ t1- After d seconds have elapsed we know the true time is within [ t1-
delta-sigma-d*PHI, t1-delta+sigma+d*PHI]. A simple and effective way delta-sigma-d*PHI, t1-delta+sigma+d*PHI]. A simple and effective way
to mix with NTP or PTP discipline of the clock is to trim the to mix with NTP or PTP discipline of the clock is to trim the
observed intervals in NTP to fit entirely within this window or observed intervals in NTP to fit entirely within this window or
reject measurements that fall to far outside. This assumes time has reject measurements that fall to far outside. This assumes time has
not been stepped. If the NTP process decides to step the time, it not been stepped. If the NTP process decides to step the time, it
MUST use roughtime to ensure the new truetime estimate that will be MUST use Roughtime to ensure the new truetime estimate that will be
stepped to is consistent with the true time. stepped to is consistent with the true time.
Should this window become too large, another roughtime measurement is Should this window become too large, another Roughtime measurement is
called for. The definition of "too large" is implementation defined. called for. The definition of "too large" is implementation defined.
Implementations MAY use other, more sophisticated means of adjusting Implementations MAY use other, more sophisticated means of adjusting
the clock respecting roughtime information. the clock respecting Roughtime information.
8. Cheater Detection 8. Cheater Detection
A chain of responses is a series of responses where the SHA-512 hash A chain of responses is a series of responses where the SHA-512 hash
of the preceding response H, is concatenated with a 64 byte blind X, of the preceding response H, is concatenated with a 64 byte blind X,
and then SHA-512(H, X) is the nonce used in the subsequent response. and then SHA-512(H, X) is the nonce used in the subsequent response.
These may be represented as an array of objects in JavaScript Object These may be represented as an array of objects in JavaScript Object
Notation (JSON) format [RFC8259] where each object may have keys Notation (JSON) format [RFC8259] where each object may have keys
"blind" and "response_packet". Packet has the Base64 [RFC4648] "blind" and "response_packet". Packet has the Base64 [RFC4648]
encoded bytes of the packet and blind is the Base64 encoded blind encoded bytes of the packet and blind is the Base64 encoded blind
skipping to change at page 12, line 27 skipping to change at page 14, line 21
long-term key: AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE= long-term key: AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE=
address: roughtime.sandbox.google.com address: roughtime.sandbox.google.com
port: 2002 port: 2002
long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ=
address: roughtime.se address: roughtime.se
port: 2002 port: 2002
long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI= long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI=
11. Trust anchors and policies 11. Trust Anchors and Policies
A trust anchor is any distributor of a list of trusted servers. It A trust anchor is any distributor of a list of trusted servers. It
is RECOMMENDED that trust anchors subscribe to a common public forum is RECOMMENDED that trust anchors subscribe to a common public forum
where evidence of malfeasance may be shared and discussed. Trust where evidence of malfeasance may be shared and discussed. Trust
anchors SHOULD subscribe to a zero-tolerance policy: any generation anchors SHOULD subscribe to a zero-tolerance policy: any generation
of incorrect timestamps will result in removal. To enable this trust of incorrect timestamps will result in removal. To enable this trust
anchors SHOULD list a wide variety of servers so the removal of a anchors SHOULD list a wide variety of servers so the removal of a
server does not result in operational issues for clients. Clients server does not result in operational issues for clients. Clients
SHOULD attempt to detect malfeasance and have a way to report it to SHOULD attempt to detect malfeasance and have a way to report it to
trust anchors. trust anchors.
Because only a single roughtime server is required for successful Because only a single Roughtime server is required for successful
synchronization, Roughtime does not have the incentive problems that synchronization, Roughtime does not have the incentive problems that
have prevented effective enforcement of discipline on the web PKI. have prevented effective enforcement of discipline on the web PKI.
We expect that some clients will aggressively monitor server We expect that some clients will aggressively monitor server
behavior. behavior.
12. Acknowledgements 12. Acknowledgements
Thomas Peterson corrected multiple nits. Marcus Dansarie, Peter Marcus Dansarie contributed many fruitful ideas. Thomas Peterson
Loethberg (Lothberg), Tal Mizrahi, Ragnar Sundblad, Kristof Teichel, corrected multiple nits. Peter Loethberg (Lothberg), Tal Mizrahi,
and the other members of the NTP working group contributed comments Ragnar Sundblad, Kristof Teichel, and the other members of the NTP
and suggestions. working group contributed comments and suggestions.
13. IANA Considerations 13. IANA Considerations
13.1. Service Name and Transport Protocol Port Number Registry 13.1. Service Name and Transport Protocol Port Number Registry
IANA is requested to allocate the following entry in the Service Name IANA is requested to allocate the following entry in the Service Name
and Transport Protocol Port Number Registry [RFC6335]: and Transport Protocol Port Number Registry [RFC6335]:
Service Name: Roughtime Service Name: Roughtime
Transport Protocol: udp Transport Protocol: tcp,udp
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: Roughtime time synchronization Description: Roughtime time synchronization
Reference: [[this memo]] Reference: [[this memo]]
Port Number: [[TBD1]], selected by IANA from the User Port range Port Number: [[TBD1]], selected by IANA from the User Port range
13.2. Roughtime Tag Registry 13.2. Roughtime Version Registry
IANA is requested to create a new registry entitled " Roughtime
Version Registry " Entries shall have the following fields:
Version (REQUIRED): a 32-bit unsigned integer
Reference (REQUIRED): the description of the version
The policy for allocation of new entries SHOULD be IETF consensus.
Versions with the high bit set are reserved.
The initial contents of this registry shall be as follows:
+---------+---------------+
| Version | Reference |
+---------+---------------+
| 1 | [[this memo]] |
+---------+---------------+
13.3. Roughtime Tag Registry
IANA is requested to create a new registry entitled "Roughtime Tag IANA is requested to create a new registry entitled "Roughtime Tag
Registry". Entries SHALL have the following fields: Registry". Entries SHALL have the following fields:
Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format. Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format.
ASCII Representation (OPTIONAL): The ASCII representation of the ASCII Representation (OPTIONAL): The ASCII representation of the
tag in accordance with Section 5.1.3 of this memo, if applicable. tag in accordance with Section 5.1.4 of this memo, if applicable.
Reference (REQUIRED): A reference to a relevant specification Reference (REQUIRED): A reference to a relevant specification
document. document.
The policy for allocation of new entries in this registry SHOULD be: The policy for allocation of new entries in this registry SHOULD be:
Specification Required. Specification Required.
The initial contents of this registry SHALL be as follows: The initial contents of this registry SHALL be as follows:
+------------+----------------------+---------------+ +------------+----------------------+---------------+
| Tag | ASCII Representation | Reference | | Tag | ASCII Representation | Reference |
+------------+----------------------+---------------+ +------------+----------------------+---------------+
| 0x00444150 | PAD | [[this memo]] | | 0x00444150 | PAD | [[this memo]] |
| 0x00474953 | SIG | [[this memo]] | | 0x00474953 | SIG | [[this memo]] |
| 0x00524556 | VER | [[this memo]] |
| 0x31545544 | DUT1 | [[this memo]] |
| 0x434e4f48 | NONC | [[this memo]] | | 0x434e4f48 | NONC | [[this memo]] |
| 0x454c4544 | DELE | [[this memo]] | | 0x454c4544 | DELE | [[this memo]] |
| 0x48544150 | PATH | [[this memo]] | | 0x48544150 | PATH | [[this memo]] |
| 0x49415444 | DTAI | [[this memo]] |
| 0x49444152 | RADI | [[this memo]] | | 0x49444152 | RADI | [[this memo]] |
| 0x4b425550 | PUBK | [[this memo]] | | 0x4b425550 | PUBK | [[this memo]] |
| 0x5041454c | LEAP | [[this memo]] |
| 0x5044494d | MIDP | [[this memo]] | | 0x5044494d | MIDP | [[this memo]] |
| 0x50455253 | SREP | [[this memo]] | | 0x50455253 | SREP | [[this memo]] |
| 0x544e494d | MINT | [[this memo]] | | 0x544e494d | MINT | [[this memo]] |
| 0x544f4f52 | ROOT | [[this memo]] | | 0x544f4f52 | ROOT | [[this memo]] |
| 0x54524543 | CERT | [[this memo]] | | 0x54524543 | CERT | [[this memo]] |
| 0x5458414d | MAXT | [[this memo]] | | 0x5458414d | MAXT | [[this memo]] |
| 0x58444e49 | INDX | [[this memo]] | | 0x58444e49 | INDX | [[this memo]] |
+------------+----------------------+---------------+ +------------+----------------------+---------------+
14. Security Considerations 14. Security Considerations
skipping to change at page 16, line 24 skipping to change at page 18, line 36
[DelayAttacks] [DelayAttacks]
Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks
Against Time Synchronization Protocols", Against Time Synchronization Protocols",
DOI 10.1109/ISPCS.2012.6336612, 2012, DOI 10.1109/ISPCS.2012.6336612, 2012,
<https://ieeexplore.ieee.org/document/6336612>. <https://ieeexplore.ieee.org/document/6336612>.
[I-D.ietf-ntp-using-nts-for-ntp] [I-D.ietf-ntp-using-nts-for-ntp]
Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time Sundblad, "Network Time Security for the Network Time
Protocol", draft-ietf-ntp-using-nts-for-ntp-20 (work in Protocol", draft-ietf-ntp-using-nts-for-ntp-25 (work in
progress), July 2019. progress), March 2020.
[MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
"Attacking the Network Time Protocol", 2015, "Attacking the Network Time Protocol", 2015,
<https://eprint.iacr.org/2015/1020>. <https://eprint.iacr.org/2015/1020>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[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>.
[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>.
skipping to change at page 17, line 24 skipping to change at page 19, line 46
IANA Internet Assigned Numbers Authority IANA Internet Assigned Numbers Authority
JSON JavaScript Object Notation [RFC8259] JSON JavaScript Object Notation [RFC8259]
MJD Modified Julian Date MJD Modified Julian Date
NTP Network Time Protocol [RFC5905] NTP Network Time Protocol [RFC5905]
NTS Network Time Security [I-D.ietf-ntp-using-nts-for-ntp] NTS Network Time Security [I-D.ietf-ntp-using-nts-for-ntp]
TAI International Atomic Time (Temps Atomique International)
[ITU-R_TF.460-6]
TCP Transmission Control Protocol [RFC0793]
UDP User Datagram Protocol [RFC0768] UDP User Datagram Protocol [RFC0768]
UT Universal Time [ITU-R_TF.460-6]
UTC Coordinated Universal Time [ITU-R_TF.460-6] UTC Coordinated Universal Time [ITU-R_TF.460-6]
Authors' Addresses Authors' Addresses
Aanchal Malhotra Aanchal Malhotra
Boston University Boston University
111 Cummington Mall 111 Cummington Mall
Boston 02215 Boston 02215
USA USA
 End of changes. 42 change blocks. 
75 lines changed or deleted 201 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/