draft-ietf-ntp-roughtime-01.txt   draft-ietf-ntp-roughtime-02.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: October 3, 2020 Google Expires: December 3, 2020 Google
W. Ladd W. Ladd
Cloudflare Cloudflare
April 1, 2020 June 01, 2020
Roughtime Roughtime
draft-ietf-ntp-roughtime-01 draft-ietf-ntp-roughtime-02
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 October 3, 2020. This Internet-Draft will expire on December 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 21 skipping to change at page 2, line 21
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. int32 . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. int32 . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. uint32 . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. uint32 . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.3. uint64 . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.3. uint64 . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.4. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.4. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.5. Timestamp . . . . . . . . . . . . . . . . . . . . . . 7 5.1.5. Timestamp . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 11 6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 11
6.3.1. Root Value Validity Check Algorithm . . . . . . . . . 11 6.3.1. Root Value Validity Check Algorithm . . . . . . . . . 12
6.4. Validity of Response . . . . . . . . . . . . . . . . . . 12 6.4. Validity of Response . . . . . . . . . . . . . . . . . . 12
7. Integration into NTP . . . . . . . . . . . . . . . . . . . . 12 7. Integration into NTP . . . . . . . . . . . . . . . . . . . . 12
8. Cheater Detection . . . . . . . . . . . . . . . . . . . . . . 13 8. Cheater Detection . . . . . . . . . . . . . . . . . . . . . . 13
9. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 13 10. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 14
11. Trust Anchors and Policies . . . . . . . . . . . . . . . . . 14 11. Trust Anchors and Policies . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13.1. Service Name and Transport Protocol Port Number Registry 14 13.1. Service Name and Transport Protocol Port Number Registry 15
13.2. Roughtime Version Registry . . . . . . . . . . . . . . . 15 13.2. Roughtime Version Registry . . . . . . . . . . . . . . . 15
13.3. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 15 13.3. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 15
14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
16.1. Normative References . . . . . . . . . . . . . . . . . . 17 16.1. Normative References . . . . . . . . . . . . . . . . . . 17
16.2. Informative References . . . . . . . . . . . . . . . . . 18 16.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 19 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 7, line 23 skipping to change at page 7, line 23
5.1.5. 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]. It is useful to note that 1 January 1970 is 40,587
days after 17 November 1858.
Note that, unlike NTP, this representation does not use the full Note that, unlike NTP, this representation does not use the full
number of bits in the fractional part and that days with leap seconds number of bits in the fractional part and that days with leap seconds
will have more or fewer than the nominal 86,400,000,000 microseconds. will have more or fewer than the nominal 86,400,000,000 microseconds.
5.2. Header 5.2. Header
All Roughtime messages start with a header. The first four bytes of All Roughtime messages start with a header. The first four bytes of
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
skipping to change at page 7, line 46 skipping to change at page 7, line 47
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 message. Values may have last value which ends at the end of the message. Values may have
zero 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. Tags MUST also be
sorted by numeric value.
6. Protocol 6. Protocol
As described in Section 3, clients initiate time synchronization by As described in Section 3, clients initiate time synchronization by
sending requests containing a nonce to servers who send signed time sending requests containing a nonce to servers who send signed time
responses in return. Roughtime packets can be sent between clients responses in return. Roughtime packets can be sent between clients
and servers either as UDP datagrams or via TCP streams. Servers and servers either as UDP datagrams or via TCP streams. Servers
SHOULD support the UDP transport mode, while TCP transport is SHOULD support the UDP transport mode, while TCP transport is
OPTIONAL. OPTIONAL.
A Roughtime packet MUST be formatted according to Figure 2 and as A Roughtime packet MUST be formatted according to Figure 2 and as
described here. The first field is a uint64 with the value described here. The first field is a uint64 with the value
0x4d49544847554f52 ("ROUGHTIM" in ASCII). The second field is a 0x4d49544847554f52 ("ROUGHTIM" in ASCII). The second field is a
uint32 and contains the length of the third field. The third and uint32 and contains the length of the third field. The third and
last field contains a Roughtime message as specified in Section 5.1. last field contains a Roughtime message as specified in Section 5.1.
0 1 2 3 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 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) | | 0x4d49544847554f52 (uint64) |
| ("ROUGHTIM") | | ("ROUGHTIM") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message length (uint32) | | Message length (uint32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Roughtime message . . Roughtime message .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 32 skipping to change at page 11, line 35
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.
The values of all nodes are calculated from the leaf nodes and up The values of all nodes are calculated from the leaf nodes and up
towards the root node using the first 32 bytes of the output of the towards the root node using the first 32 bytes of the output of the
SHA-512 hash algorithm [RFC6234]. For leaf nodes, the byte 0x00 is SHA-512/256 hash algorithm [SHS]. For leaf nodes, the byte 0x00 is
prepended to the nonce before applying the hash function. For all prepended to the nonce before applying the hash function. For all
other nodes, the byte 0x01 is concatenated with first the left and other nodes, the byte 0x01 is concatenated with first the left and
then the right child node value before applying the hash function. then the right child node value before applying the hash function.
The value of the Merkle tree's root node is included in the ROOT tag The value of the Merkle tree's root node is included in the ROOT tag
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.
skipping to change at page 13, line 13 skipping to change at page 13, line 17
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/256
of the preceding response H, is concatenated with a 64 byte blind X, hash of the preceding response H, is concatenated with a 64 byte
and then SHA-512(H, X) is the nonce used in the subsequent response. blind X, and then SHA-512/256(H, X) is the nonce used in the
These may be represented as an array of objects in JavaScript Object subsequent response. These may be represented as an array of objects
Notation (JSON) format [RFC8259] where each object may have keys in JavaScript Object Notation (JSON) format [RFC8259] where each
"blind" and "response_packet". Packet has the Base64 [RFC4648] object may have keys "blind" and "response_packet". Packet has the
encoded bytes of the packet and blind is the Base64 encoded blind Base64 [RFC4648] encoded bytes of the packet and blind is the Base64
used for the next nonce. The last packet needs no blind. encoded blind used for the next nonce. The last packet needs no
blind.
A pair of responses (r_1, r_2) is invalid if MIDP_1-RADI_1 > A pair of responses (r_1, r_2) is invalid if MIDP_1-RADI_1 >
MIDP_2+RADI_2. A chain of longer length is invalid if for any i, j MIDP_2+RADI_2. A chain of longer length is invalid if for any i, j
such that i < j, (r_i, r_j) is an invalid pair. such that i < j, (r_i, r_j) is an invalid pair.
Invalidity of a chain is proof that causality has been violated if Invalidity of a chain is proof that causality has been violated if
all servers were reporting correct time. An invalid chain where all all servers were reporting correct time. An invalid chain where all
individual responses are valid is cryptographic proof of malfeasance individual responses are valid is cryptographic proof of malfeasance
of at least one server: if all servers had the correct time in the of at least one server: if all servers had the correct time in the
chain, causality would imply that MIDP_1-RADI_1 < MIDP_2+RADI_2. chain, causality would imply that MIDP_1-RADI_1 < MIDP_2+RADI_2.
skipping to change at page 18, line 22 skipping to change at page 18, line 22
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[SHS] NIST, "Secure Hash Standard", FIPS 180-4, August 2015.
16.2. Informative References 16.2. Informative References
[Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures",
2012, <https://zero-entropy.de/autokey_analysis.pdf>. 2012, <https://zero-entropy.de/autokey_analysis.pdf>.
[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>.
 End of changes. 14 change blocks. 
21 lines changed or deleted 26 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/