draft-ietf-ntp-network-time-security-13.txt   draft-ietf-ntp-network-time-security-14.txt 
NTP Working Group D. Sibold NTP Working Group D. Sibold
Internet-Draft PTB Internet-Draft PTB
Intended status: Standards Track S. Roettger Intended status: Standards Track S. Roettger
Expires: August 28, 2016 Google Inc. Expires: September 22, 2016 Google Inc.
K. Teichel K. Teichel
PTB PTB
February 25, 2016 March 21, 2016
Network Time Security Network Time Security
draft-ietf-ntp-network-time-security-13 draft-ietf-ntp-network-time-security-14
Abstract Abstract
This document describes Network Time Security (NTS), a collection of This document describes Network Time Security (NTS), a collection of
measures that enable secure time synchronization with time servers measures that enable secure time synchronization with time servers
using protocols like the Network Time Protocol (NTP) or the Precision using protocols like the Network Time Protocol (NTP) or the Precision
Time Protocol (PTP). Its design considers the special requirements Time Protocol (PTP). Its design considers the special requirements
of precise timekeeping which are described in Security Requirements of precise timekeeping which are described in Security Requirements
of Time Protocols in Packet Switched Networks [RFC7384]. of Time Protocols in Packet Switched Networks [RFC7384].
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 28, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 51 skipping to change at page 2, line 51
6.2.2. Goals of the Broadcast Time Synchronization Exchange 11 6.2.2. Goals of the Broadcast Time Synchronization Exchange 11
6.2.3. Message Type: "server_broad" . . . . . . . . . . . . 11 6.2.3. Message Type: "server_broad" . . . . . . . . . . . . 11
6.2.4. Procedure Overview of Broadcast Time Synchronization 6.2.4. Procedure Overview of Broadcast Time Synchronization
Exchange . . . . . . . . . . . . . . . . . . . . . . 12 Exchange . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . . . 13 6.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . . . 13
6.3.1. Preconditions for the Broadcast Keycheck Exchange . . 13 6.3.1. Preconditions for the Broadcast Keycheck Exchange . . 13
6.3.2. Goals of the Broadcast Keycheck Exchange . . . . . . 14 6.3.2. Goals of the Broadcast Keycheck Exchange . . . . . . 14
6.3.3. Message Type: "client_keycheck" . . . . . . . . . . . 14 6.3.3. Message Type: "client_keycheck" . . . . . . . . . . . 14
6.3.4. Message Type: "server_keycheck" . . . . . . . . . . . 14 6.3.4. Message Type: "server_keycheck" . . . . . . . . . . . 14
6.3.5. Procedure Overview of the Broadcast Keycheck Exchange 15 6.3.5. Procedure Overview of the Broadcast Keycheck Exchange 15
7. Server Seed, Hash Algorithms and Generating MACs . . . . . . 16 7. Server Seed, MAC Algorithms and Generating MACs . . . . . . . 16
7.1. Server Seed . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Server Seed . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 16 7.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . . 16
7.3. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Initial Verification of the Server Certificates . . . . . 18 9.2. Initial Verification of the Server Certificates . . . . . 18
9.3. Revocation of Server Certificates . . . . . . . . . . . . 18 9.3. Revocation of Server Certificates . . . . . . . . . . . . 18
9.4. Mitigating Denial-of-Service for broadcast packets . . . 18 9.4. Mitigating Denial-of-Service for broadcast packets . . . 18
9.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 19 9.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 18
9.6. Random Number Generation . . . . . . . . . . . . . . . . 20 9.6. Random Number Generation . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. (informative) TICTOC Security Requirements . . . . . 22 Appendix A. (informative) TICTOC Security Requirements . . . . . 22
Appendix B. (normative) Inherent Association Protocol Messages . 23 Appendix B. (normative) Inherent Association Protocol Messages . 23
B.1. Overview of NTS with Inherent Association Protocol . . . 23 B.1. Overview of NTS with Inherent Association Protocol . . . 23
B.2. Access Message Exchange . . . . . . . . . . . . . . . . . 24 B.2. Access Message Exchange . . . . . . . . . . . . . . . . . 24
B.2.1. Goals of the Access Message Exchange . . . . . . . . 24 B.2.1. Goals of the Access Message Exchange . . . . . . . . 24
B.2.2. Message Type: "client_access" . . . . . . . . . . . . 24 B.2.2. Message Type: "client_access" . . . . . . . . . . . . 24
B.2.3. Message Type: "server_access" . . . . . . . . . . . . 24 B.2.3. Message Type: "server_access" . . . . . . . . . . . . 24
B.2.4. Procedure Overview of the Access Exchange . . . . . . 25 B.2.4. Procedure Overview of the Access Exchange . . . . . . 24
B.3. Association Message Exchange . . . . . . . . . . . . . . 25 B.3. Association Message Exchange . . . . . . . . . . . . . . 25
B.3.1. Goals of the Association Exchange . . . . . . . . . . 25 B.3.1. Goals of the Association Exchange . . . . . . . . . . 25
B.3.2. Message Type: "client_assoc" . . . . . . . . . . . . 26 B.3.2. Message Type: "client_assoc" . . . . . . . . . . . . 25
B.3.3. Message Type: "server_assoc" . . . . . . . . . . . . 26 B.3.3. Message Type: "server_assoc" . . . . . . . . . . . . 26
B.3.4. Procedure Overview of the Association Exchange . . . 27 B.3.4. Procedure Overview of the Association Exchange . . . 26
B.4. Cookie Message Exchange . . . . . . . . . . . . . . . . . 28 B.4. Cookie Message Exchange . . . . . . . . . . . . . . . . . 27
B.4.1. Goals of the Cookie Exchange . . . . . . . . . . . . 28 B.4.1. Goals of the Cookie Exchange . . . . . . . . . . . . 28
B.4.2. Message Type: "client_cook" . . . . . . . . . . . . . 29 B.4.2. Message Type: "client_cook" . . . . . . . . . . . . . 28
B.4.3. Message Type: "server_cook" . . . . . . . . . . . . . 29 B.4.3. Message Type: "server_cook" . . . . . . . . . . . . . 28
B.4.4. Procedure Overview of the Cookie Exchange . . . . . . 30 B.4.4. Procedure Overview of the Cookie Exchange . . . . . . 29
B.4.5. Broadcast Parameter Messages . . . . . . . . . . . . 31 B.4.5. Broadcast Parameter Messages . . . . . . . . . . . . 30
Appendix C. (normative) Using TESLA for Broadcast-Type Messages 33 Appendix C. (normative) Using TESLA for Broadcast-Type Messages 32
C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 33 C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 32
C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 35 C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 34
C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 36 C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 35
C.4. Authentication of Received Packets . . . . . . . . . . . 36 C.4. Authentication of Received Packets . . . . . . . . . . . 35
Appendix D. (informative) Dependencies . . . . . . . . . . . . . 38 Appendix D. (informative) Dependencies . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Time synchronization protocols are increasingly utilized to Time synchronization protocols are increasingly utilized to
synchronize clocks in networked infrastructures. Successful attacks synchronize clocks in networked infrastructures. Successful attacks
against the time synchronization protocol can seriously degrade the against the time synchronization protocol can seriously degrade the
reliable performance of such infrastructures. Therefore, time reliable performance of such infrastructures. Therefore, time
synchronization protocols have to be secured if they are applied in synchronization protocols have to be secured if they are applied in
environments that are prone to malicious attacks. This can be environments that are prone to malicious attacks. This can be
accomplished either by utilization of external security protocols, accomplished either by utilization of external security protocols,
skipping to change at page 4, line 42 skipping to change at page 4, line 41
2.1. Terms and Abbreviations 2.1. Terms and Abbreviations
MITM Man In The Middle MITM Man In The Middle
NTS Network Time Security NTS Network Time Security
TESLA Timed Efficient Stream Loss-tolerant Authentication TESLA Timed Efficient Stream Loss-tolerant Authentication
MAC Message Authentication Code MAC Message Authentication Code
HMAC Keyed-Hash Message Authentication Code
2.2. Common Terminology for PTP and NTP 2.2. Common Terminology for PTP and NTP
This document refers to different time synchronization protocols, in This document refers to different time synchronization protocols, in
particular to both the PTP and the NTP. Throughout the document the particular to both the PTP and the NTP. Throughout the document the
term "server" applies to both a PTP master and an NTP server. term "server" applies to both a PTP master and an NTP server.
Accordingly, the term "client" applies to both a PTP slave and an NTP Accordingly, the term "client" applies to both a PTP slave and an NTP
client. client.
3. Security Threats 3. Security Threats
skipping to change at page 6, line 20 skipping to change at page 6, line 20
cookie and the KIV are exchanged, the client then uses them to cookie and the KIV are exchanged, the client then uses them to
protect the authenticity and the integrity of subsequent unicast-type protect the authenticity and the integrity of subsequent unicast-type
time synchronization packets. In order to do this, a Message time synchronization packets. In order to do this, a Message
Authentication Code (MAC) is attached to each time synchronization Authentication Code (MAC) is attached to each time synchronization
packet. The calculation of the MAC includes the whole time packet. The calculation of the MAC includes the whole time
synchronization packet and the cookie which is shared between client synchronization packet and the cookie which is shared between client
and server. and server.
The cookie is calculated according to: The cookie is calculated according to:
cookie = MSB_<b> (HMAC(server seed, KIV)), cookie = MSB_<b> (MAC(server seed, KIV)),
with the server seed as the key, where KIV is the client's key input with the server seed as the key, where KIV is the client's key input
value, and where the application of the function MSB_<b> returns only value, and where the application of the function MSB_<b> returns only
the b most significant bits. The server seed is a random value of the b most significant bits. The server seed is a random value of
bit length b that the server possesses, which has to remain secret. bit length b that the server possesses, which has to remain secret.
The cookie deterministically depends on KIV as long as the server The cookie deterministically depends on KIV as long as the server
seed stays the same. The server seed has to be refreshed seed stays the same. The server seed has to be refreshed
periodically in order to provide key freshness as required in periodically in order to provide key freshness as required in
[RFC7384]. See Section 7 for details on seed refreshing. [RFC7384]. See Section 7 for details on seed refreshing.
skipping to change at page 7, line 38 skipping to change at page 7, line 38
executed, with the addition of integrity protection for all messages executed, with the addition of integrity protection for all messages
that the server sends. This message exchange can be repeatedly that the server sends. This message exchange can be repeatedly
performed as often as the client desires and as long as the integrity performed as often as the client desires and as long as the integrity
of the server's time responses is verified successfully. of the server's time responses is verified successfully.
6.1.1. Preconditions for the Unicast Time Synchronization Exchange 6.1.1. Preconditions for the Unicast Time Synchronization Exchange
Before this message exchange is available, there are some Before this message exchange is available, there are some
requirements that the client and server need to meet: requirements that the client and server need to meet:
o They MUST negotiate the hash algorithm for the MAC used in the o They MUST negotiate the algorithm for the MAC used in the time
time synchronization messages. Authenticity and integrity of the synchronization messages. Authenticity and integrity of the
communication MUST be ensured. communication MUST be ensured.
o The client MUST know a key input value KIV. Authenticity and o The client MUST know a key input value KIV. Authenticity and
integrity of the communication MUST be ensured. integrity of the communication MUST be ensured.
o Client and server MUST exchange the cookie (which depends on the o Client and server MUST exchange the cookie (which depends on the
KIV as described in section Section 5). Authenticity, KIV as described in section Section 5). Authenticity,
confidentiality and integrity of the communication MUST be confidentiality and integrity of the communication MUST be
ensured. ensured.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
This message is sent by the client when it requests a time exchange. This message is sent by the client when it requests a time exchange.
It contains It contains
o the NTS message ID "time_request", o the NTS message ID "time_request",
o the negotiated version number, o the negotiated version number,
o a nonce, o a nonce,
o the negotiated hash algorithm H, o the negotiated MAC algorithm,
o the client's key input value (for which the client knows the o the client's key input value (for which the client knows the
associated cookie), associated cookie),
o optional: a MAC (generated with the cookie as key) for o optional: a MAC (generated with the cookie as key) for
verification of all of the above data. verification of all of the above data.
6.1.4. Message Type: "time_response" 6.1.4. Message Type: "time_response"
This message is sent by the server after it has received a This message is sent by the server after it has received a
time_request message. Prior to this the server MUST recalculate the time_request message. Prior to this the server MUST recalculate the
client's cookie by using the received key input value and the client's cookie by using the received key input value and the
transmitted hash algorithm. The message contains transmitted MAC algorithm. The message contains
o the NTS message ID "time_response", o the NTS message ID "time_response",
o the version number as transmitted in time_request, o the version number as transmitted in time_request,
o the server's time synchronization response data, o the server's time synchronization response data,
o the nonce transmitted in time_request, o the nonce transmitted in time_request,
o a MAC (generated with the cookie as key) for verification of all o a MAC (generated with the cookie as key) for verification of all
of the above data. of the above data.
skipping to change at page 13, line 36 skipping to change at page 13, line 36
6.3. Broadcast Keycheck 6.3. Broadcast Keycheck
This message exchange is performed for an additional check of packet This message exchange is performed for an additional check of packet
timeliness in the course of the TESLA scheme, see Appendix C. timeliness in the course of the TESLA scheme, see Appendix C.
6.3.1. Preconditions for the Broadcast Keycheck Exchange 6.3.1. Preconditions for the Broadcast Keycheck Exchange
Before this message exchange is available, there are some Before this message exchange is available, there are some
requirements that the client and server need to meet: requirements that the client and server need to meet:
o They MUST negotiate the hash algorithm for the MAC used in the o They MUST negotiate the algorithm for the MAC used in the time
time synchronization messages. Authenticity and integrity of the synchronization messages. Authenticity and integrity of the
communication MUST be ensured. communication MUST be ensured.
o The client MUST know a key input value KIV. Authenticity and o The client MUST know a key input value KIV. Authenticity and
integrity of the communication MUST be ensured. integrity of the communication MUST be ensured.
o Client and server MUST exchange the cookie (which depends on the o Client and server MUST exchange the cookie (which depends on the
KIV as described in section Section 5). Authenticity, KIV as described in section Section 5). Authenticity,
confidentiality and integrity of the communication MUST be confidentiality and integrity of the communication MUST be
ensured. ensured.
skipping to change at page 14, line 31 skipping to change at page 14, line 31
contains contains
o the NTS message ID "client_keycheck", o the NTS message ID "client_keycheck",
o the NTS version number negotiated during association, o the NTS version number negotiated during association,
o a nonce, o a nonce,
o an interval number from the TESLA disclosure schedule, o an interval number from the TESLA disclosure schedule,
o the hash algorithm H negotiated during association, o the MAC algorithm negotiated during association,
o the client's key input value KIV, and o the client's key input value KIV, and
o optional: a MAC (generated with the cookie as key) for o optional: a MAC (generated with the cookie as key) for
verification of all of the above data. verification of all of the above data.
6.3.4. Message Type: "server_keycheck" 6.3.4. Message Type: "server_keycheck"
A message of this type is sent by the server upon receipt of a A message of this type is sent by the server upon receipt of a
client_keycheck message during the broadcast loop of the server. client_keycheck message during the broadcast loop of the server.
Prior to this, the server MUST recalculate the client's cookie by Prior to this, the server MUST recalculate the client's cookie by
using the received key input value and the transmitted hash using the received key input value and the transmitted MAC algorithm.
algorithm. It contains It contains
o the NTS message ID "server_keycheck" o the NTS message ID "server_keycheck"
o the version number as transmitted in "client_keycheck, o the version number as transmitted in "client_keycheck,
o the nonce transmitted in the client_keycheck message, o the nonce transmitted in the client_keycheck message,
o the interval number transmitted in the client_keycheck message, o the interval number transmitted in the client_keycheck message,
and and
o a MAC (generated with the cookie as key) for verification of all o a MAC (generated with the cookie as key) for verification of all
skipping to change at page 16, line 25 skipping to change at page 16, line 25
\ broad keycheck / \ keycheck \ broad keycheck / \ keycheck
\| / \| \| / \|
Client ---------------------------------------------> Client --------------------------------------------->
<-------- Extended broadcast time -------> <-------- Extended broadcast time ------->
synchronization exchange synchronization exchange
<---- Keycheck exchange ---> <---- Keycheck exchange --->
Procedure for extended broadcast time synchronization exchange. Procedure for extended broadcast time synchronization exchange.
7. Server Seed, Hash Algorithms and Generating MACs 7. Server Seed, MAC Algorithms and Generating MACs
7.1. Server Seed 7.1. Server Seed
The server has to calculate a random seed which has to be kept The server has to calculate a random seed which has to be kept
secret. The server MUST generate a seed for each supported hash secret. The server MUST generate a seed for each supported MAC
algorithm, see Section 7.2. algorithm, see Section 7.2.
According to the requirements in [RFC7384], the server MUST refresh According to the requirements in [RFC7384], the server MUST refresh
each server seed periodically. Consequently, the cookie memorized by each server seed periodically. Consequently, the cookie memorized by
the client becomes obsolete. In this case, the client cannot verify the client becomes obsolete. In this case, the client cannot verify
the MAC attached to subsequent time response messages and has to the MAC attached to subsequent time response messages and has to
respond accordingly by re-initiating the protocol with a cookie respond accordingly by re-initiating the protocol with a cookie
request (Appendix B.4). request (Appendix B.4).
7.2. Hash Algorithms 7.2. MAC Algorithms
Hash algorithms are used for calculation of the cookie and the MAC.
The client and the server negotiate a hash algorithm H during the
association phase at the beginning. The selected algorithm H MUST be
used for all hashing processes in that run.
In the TESLA scheme, hash algorithms are used as pseudo-random
functions to construct the one-way key chain. Here, the utilized
hash algorithm is communicated by the server and is non-negotiable.
Note: Any hash algorithm is prone to be compromised in the future.
A successful attack on a hash algorithm would enable any NTS
client to derive the server seed from its own cookie. Therefore,
the server MUST have separate seed values for its different
supported hash algorithms. This way, knowledge gained from an
attack on a hash algorithm H can at least only be used to
compromise such clients who use hash algorithm H as well.
7.3. MAC Calculation MAC algorithms are used for calculation of the cookie and the actual
MAC. The client and the server negotiate a MAC algorithm during the
association phase at the beginning. The selected algorithm MUST be
used for all cookie and MAC creation processes in that run.
For the calculation of the MAC, client and server MUST use a Keyed- Note: Any MAC algorithm is prone to be compromised in the future. A
Hash Message Authentication Code (HMAC) as described in [RFC2104]. successful attack on a MAC algorithm would enable any NTS client
The HMAC is generated with the hash algorithm specified by the client to derive the server seed from its own cookie. Therefore, the
(see Section 7.2). The input values for the HMAC are the cookie and server MUST have separate seed values for its different supported
the content that has to be protected by NTS. MAC algorithms. This way, knowledge gained from an attack on a
MAC algorithm can at least only be used to compromise such clients
who use this algorithm as well.
8. IANA Considerations 8. IANA Considerations
As mentioned, this document generically specifies security measures As mentioned, this document generically specifies security measures
whose utilization for any given specific time synchronization whose utilization for any given specific time synchronization
protocol requires a separate document. Consequently, this document protocol requires a separate document. Consequently, this document
itself does not have any IANA actions (TO BE REVIEWED). itself does not have any IANA actions (TO BE REVIEWED).
9. Security Considerations 9. Security Considerations
skipping to change at page 20, line 40 skipping to change at page 20, line 31
Bellovin, David Mills, Kurt Roeckx, Rainer Bermbach, Martin Langer Bellovin, David Mills, Kurt Roeckx, Rainer Bermbach, Martin Langer
and Florian Weimer for discussions and comments on the design of NTS. and Florian Weimer for discussions and comments on the design of NTS.
Also, thanks go to Harlan Stenn and Richard Welty for their technical Also, thanks go to Harlan Stenn and Richard Welty for their technical
review and specific text contributions to this document. review and specific text contributions to this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, DOI Hashing for Message Authentication", RFC 2104,
10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,
June 2005, <http://www.rfc-editor.org/info/rfc4082>. June 2005, <http://www.rfc-editor.org/info/rfc4082>.
[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,
skipping to change at page 21, line 35 skipping to change at page 21, line 25
Path Time Synchronization", draft-ietf-tictoc-multi-path- Path Time Synchronization", draft-ietf-tictoc-multi-path-
synchronization-02 (work in progress), April 2015. synchronization-02 (work in progress), April 2015.
[IEEE1588] [IEEE1588]
IEEE Instrumentation and Measurement Society. TC-9 Sensor IEEE Instrumentation and Measurement Society. TC-9 Sensor
Technology, "IEEE standard for a precision clock Technology, "IEEE standard for a precision clock
synchronization protocol for networked measurement and synchronization protocol for networked measurement and
control systems", 2008. control systems", 2008.
[Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks [Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks
against time synchronization protocols", in Proceedings of against time synchronization protocols", in Proceedings
Precision Clock Synchronization for Measurement Control of Precision Clock Synchronization for Measurement Control
and Communication, ISPCS 2012, pp. 1-6, September 2012. and Communication, ISPCS 2012, pp. 1-6, September 2012.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[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,
skipping to change at page 22, line 14 skipping to change at page 21, line 48
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>. <http://www.rfc-editor.org/info/rfc6960>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann, Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A "Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624, DOI Threat Model and Problem Statement", RFC 7624,
10.17487/RFC7624, August 2015, DOI 10.17487/RFC7624, August 2015,
<http://www.rfc-editor.org/info/rfc7624>. <http://www.rfc-editor.org/info/rfc7624>.
[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 Precision Clock Protocols", in Proceedings of Precision Clock
Synchronization for Measurement Control and Communication, Synchronization for Measurement Control and Communication,
ISPCS 2013, pp. 1-6, September 2013. ISPCS 2013, pp. 1-6, September 2013.
Appendix A. (informative) TICTOC Security Requirements Appendix A. (informative) TICTOC Security Requirements
The following table compares the NTS specifications against the The following table compares the NTS specifications against the
skipping to change at page 24, line 17 skipping to change at page 24, line 5
A client needs a public/private key pair for encryption, with the A client needs a public/private key pair for encryption, with the
public key enclosed in a certificate. A server needs a public/ public key enclosed in a certificate. A server needs a public/
private key pair for signing, with the public key enclosed in a private key pair for signing, with the public key enclosed in a
certificate. If a participant intends to act as both a client and a certificate. If a participant intends to act as both a client and a
server, it MUST have two different key pairs for these purposes. server, it MUST have two different key pairs for these purposes.
If this protocol is employed, the hash value of the client's If this protocol is employed, the hash value of the client's
certificate is used as the client's key input value, i.e. the cookie certificate is used as the client's key input value, i.e. the cookie
is calculated according to: is calculated according to:
cookie = MSB_<b> (HMAC(server seed, H(certificate of client))). cookie = MSB_<b> (MAC(server seed, H(certificate of client))),
The client's certificate contains the client's public key and enables Where the hash function H is the one used in the MAC algorithm. The
the server to identify the client, if client authorization is client's certificate contains the client's public key and enables the
desired. server to identify the client, if client authorization is desired.
B.2. Access Message Exchange B.2. Access Message Exchange
This message exchange serves only to prevent the next (association) This message exchange serves only to prevent the next (association)
exchange from being abusable for amplification denial-of-service exchange from being abusable for amplification denial-of-service
attacks. attacks.
B.2.1. Goals of the Access Message Exchange B.2.1. Goals of the Access Message Exchange
The access message exchange: The access message exchange:
skipping to change at page 25, line 27 skipping to change at page 25, line 15
correlated with the address of the requester. Note also that if correlated with the address of the requester. Note also that if
the server memorizes the access key for a requester, it has to the server memorizes the access key for a requester, it has to
keep state for a certain amount of time. keep state for a certain amount of time.
3. The client waits for a response in the form of a server_access 3. The client waits for a response in the form of a server_access
message. Upon receipt of one, it MUST memorize the included message. Upon receipt of one, it MUST memorize the included
access key. access key.
B.3. Association Message Exchange B.3. Association Message Exchange
In this message exchange, the participants negotiate the hash and In this message exchange, the participants negotiate the MAC and
encryption algorithms that are used throughout the protocol. In encryption algorithms that are used throughout the protocol. In
addition, the client receives the certification chain up to a trusted addition, the client receives the certification chain up to a trusted
anchor. With the established certification chain the client is able anchor. With the established certification chain the client is able
to verify the server's signatures and, hence, the authenticity of to verify the server's signatures and, hence, the authenticity of
future NTS messages from the server is ensured. future NTS messages from the server is ensured.
B.3.1. Goals of the Association Exchange B.3.1. Goals of the Association Exchange
The association exchange: The association exchange:
skipping to change at page 26, line 19 skipping to change at page 25, line 51
o the NTS message ID "client_assoc", o the NTS message ID "client_assoc",
o a nonce, o a nonce,
o the access key obtained earlier via an access message exchange, o the access key obtained earlier via an access message exchange,
o the version number of NTS that the client wants to use (this o the version number of NTS that the client wants to use (this
SHOULD be the highest version number that it supports), SHOULD be the highest version number that it supports),
o a selection of accepted hash algorithms, and o a selection of accepted MAC algorithms, and
o a selection of accepted encryption algorithms. o a selection of accepted encryption algorithms.
B.3.3. Message Type: "server_assoc" B.3.3. Message Type: "server_assoc"
This message is sent by the server upon receipt of client_assoc. It This message is sent by the server upon receipt of client_assoc. It
contains contains
o the NTS message ID "server_assoc", o the NTS message ID "server_assoc",
o the nonce transmitted in client_assoc, o the nonce transmitted in client_assoc,
o the client's proposal for the version number, selection of o the client's proposal for the version number, selection of
accepted hash algorithms and selection of accepted encryption accepted MAC algorithms and selection of accepted encryption
algorithms, as transmitted in client_assoc, algorithms, as transmitted in client_assoc,
o the version number used for the rest of the protocol (which SHOULD o the version number used for the rest of the protocol (which SHOULD
be determined as the minimum over the client's suggestion in the be determined as the minimum over the client's suggestion in the
client_assoc message and the highest supported by the server), client_assoc message and the highest supported by the server),
o the server's choice of algorithm for encryption and for o the server's choice of algorithm for encryption and for MAC
cryptographic hashing, all of which MUST be chosen from the creation, all of which MUST be chosen from the client's proposals,
client's proposals,
o a signature, calculated over the data listed above, with the o a signature, calculated over the data listed above, with the
server's private key and according to the signature algorithm server's private key and according to the signature algorithm
which is also used for the certificates that are included (see which is also used for the certificates that are included (see
below), and below), and
o a chain of certificates, which starts at the server and goes up to o a chain of certificates, which starts at the server and goes up to
a trusted authority; each certificate MUST be certified by the one a trusted authority; each certificate MUST be certified by the one
directly following it. directly following it.
skipping to change at page 27, line 32 skipping to change at page 27, line 16
message. After receipt of the message it performs the following message. After receipt of the message it performs the following
checks: checks:
* The client checks that the message contains a conforming * The client checks that the message contains a conforming
version number. version number.
* It checks that the nonce sent back by the server matches the * It checks that the nonce sent back by the server matches the
one transmitted in client_assoc, one transmitted in client_assoc,
* It also verifies that the server has chosen the encryption and * It also verifies that the server has chosen the encryption and
hash algorithms from its proposal sent in the client_assoc MAC algorithms from its proposal sent in the client_assoc
message and that this proposal was not altered. message and that this proposal was not altered.
* Furthermore, it performs authenticity checks on the * Furthermore, it performs authenticity checks on the
certificate chain and the signature. certificate chain and the signature.
If one of the checks fails, the client MUST abort the run. If one of the checks fails, the client MUST abort the run.
+------------------------+ +------------------------+
| o Check access key | | o Check access key |
+------------------------+ +------------------------+
skipping to change at page 29, line 21 skipping to change at page 28, line 38
o the NTS message ID "client_cook", o the NTS message ID "client_cook",
o a nonce, o a nonce,
o the negotiated version number, o the negotiated version number,
o the negotiated signature algorithm, o the negotiated signature algorithm,
o the negotiated encryption algorithm, o the negotiated encryption algorithm,
o the negotiated hash algorithm H, o the negotiated MAC algorithm,
o the client's certificate. o the client's certificate.
B.4.3. Message Type: "server_cook" B.4.3. Message Type: "server_cook"
This message is sent by the server upon receipt of a client_cook This message is sent by the server upon receipt of a client_cook
message. The server generates the hash of the client's certificate, message. The server generates the hash (the used hash function is
as conveyed during client_cook, in order to calculate the cookie the one used for the MAC algorithm) of the client's certificate, as
conveyed during client_cook, in order to calculate the cookie
according to Section 5. This message contains according to Section 5. This message contains
o the NTS message ID "server_cook" o the NTS message ID "server_cook"
o the version number as transmitted in client_cook, o the version number as transmitted in client_cook,
o a concatenated datum which is encrypted with the client's public o a concatenated datum which is encrypted with the client's public
key, according to the encryption algorithm transmitted in the key, according to the encryption algorithm transmitted in the
client_cook message. The concatenated datum contains client_cook message. The concatenated datum contains
* the nonce transmitted in client_cook, and * the nonce transmitted in client_cook, and
* the cookie. * the cookie.
o a signature, created with the server's private key, calculated o a signature, created with the server's private key, calculated
over all of the data listed above. This signature MUST be over all of the data listed above. This signature MUST be
 End of changes. 38 change blocks. 
85 lines changed or deleted 68 lines changed or added

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