draft-ietf-ntp-network-time-security-09.txt   draft-ietf-ntp-network-time-security-10.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: January 7, 2016 Google Inc. Expires: April 7, 2016 Google Inc.
K. Teichel K. Teichel
PTB PTB
July 06, 2015 October 05, 2015
Network Time Security Network Time Security
draft-ietf-ntp-network-time-security-09 draft-ietf-ntp-network-time-security-10
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 January 7, 2016. This Internet-Draft will expire on April 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 3, line 18 skipping to change at page 3, line 18
10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Initial Verification of the Server Certificates . . . . 16 10.2. Initial Verification of the Server Certificates . . . . 16
10.3. Revocation of Server Certificates . . . . . . . . . . . 17 10.3. Revocation of Server Certificates . . . . . . . . . . . 17
10.4. Mitigating Denial-of-Service for broadcast packets . . . 17 10.4. Mitigating Denial-of-Service for broadcast packets . . . 17
10.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 17 10.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 17
10.6. Random Number Generation . . . . . . . . . . . . . . . . 19 10.6. Random Number Generation . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. (informative) TICTOC Security Requirements . . . . . 20 Appendix A. (informative) TICTOC Security Requirements . . . . . 21
Appendix B. (normative) Inherent Association Protocol Messages . 22 Appendix B. (normative) Inherent Association Protocol Messages . 22
B.1. Overview of NTS with Inherent Association Protocol . . . 22 B.1. Overview of NTS with Inherent Association Protocol . . . 22
B.2. Association Message Exchange . . . . . . . . . . . . . . 22 B.2. Association Message Exchange . . . . . . . . . . . . . . 22
B.2.1. Goals of the Association Exchange . . . . . . . . . . 22 B.2.1. Goals of the Association Exchange . . . . . . . . . . 23
B.2.2. Message Type: "client_assoc" . . . . . . . . . . . . 23 B.2.2. Message Type: "client_assoc" . . . . . . . . . . . . 23
B.2.3. Message Type: "server_assoc" . . . . . . . . . . . . 23 B.2.3. Message Type: "server_assoc" . . . . . . . . . . . . 23
B.2.4. Procedure Overview of the Association Exchange . . . 24 B.2.4. Procedure Overview of the Association Exchange . . . 24
B.3. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 25 B.3. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 25
B.3.1. Goals of the Cookie Exchange . . . . . . . . . . . . 25 B.3.1. Goals of the Cookie Exchange . . . . . . . . . . . . 25
B.3.2. Message Type: "client_cook" . . . . . . . . . . . . . 26 B.3.2. Message Type: "client_cook" . . . . . . . . . . . . . 26
B.3.3. Message Type: "server_cook" . . . . . . . . . . . . . 26 B.3.3. Message Type: "server_cook" . . . . . . . . . . . . . 26
B.3.4. Procedure Overview of the Cookie Exchange . . . . . . 27 B.3.4. Procedure Overview of the Cookie Exchange . . . . . . 27
B.3.5. Broadcast Parameter Messages . . . . . . . . . . . . 28 B.3.5. Broadcast Parameter Messages . . . . . . . . . . . . 28
Appendix C. (normative) Using TESLA for Broadcast-Type Messages 30 Appendix C. (normative) Using TESLA for Broadcast-Type Messages 30
C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 31 C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 30
C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 32 C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 32
C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 33 C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 33
C.4. Authentication of Received Packets . . . . . . . . . . . 33 C.4. Authentication of Received Packets . . . . . . . . . . . 33
Appendix D. (informative) Dependencies . . . . . . . . . . . . . 35 Appendix D. (informative) Dependencies . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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
skipping to change at page 16, line 32 skipping to change at page 16, line 32
10. Security Considerations 10. Security Considerations
10.1. Privacy 10.1. Privacy
The payload of time synchronization protocol packets of two-way time The payload of time synchronization protocol packets of two-way time
transfer approaches like NTP and PTP consists basically of time transfer approaches like NTP and PTP consists basically of time
stamps, which are not considered secret [RFC7384]. Therefore, stamps, which are not considered secret [RFC7384]. Therefore,
encryption of the time synchronization protocol packet's payload is encryption of the time synchronization protocol packet's payload is
not considered in this document. However, an attacker can exploit not considered in this document. However, an attacker can exploit
the exchange of time synchronization protocol packets for topology the exchange of time synchronization protocol packets for topology
detection and inference attacks as described in detection and inference attacks as described in [RFC7624]. To make
[I-D.iab-privsec-confidentiality-threat]. To make such attacks more such attacks more difficult, that draft recommends the encryption of
difficult, that draft recommends the encryption of the packet the packet payload. Yet, in the case of time synchronization
payload. Yet, in the case of time synchronization protocols the protocols the confidentiality protection of time synchronization
confidentiality protection of time synchronization packet's payload packet's payload is of secondary importance since the packet's meta
is of secondary importance since the packet's meta data (IP data (IP addresses, port numbers, possibly packet size and regular
addresses, port numbers, possibly packet size and regular sending sending intervals) carry more information than the payload. To
intervals) carry more information than the payload. To enhance the enhance the privacy of the time synchronization partners, the usage
privacy of the time synchronization partners, the usage of tunnel of tunnel protocols such as IPsec and MACsec, where applicable, is
protocols such as IPsec and MACsec, where applicable, is therefore therefore more suited than confidentiality protection of the payload.
more suited than confidentiality protection of the payload.
10.2. Initial Verification of the Server Certificates 10.2. Initial Verification of the Server Certificates
The client may wish to verify the validity of certificates during the The client may wish to verify the validity of certificates during the
initial association phase. Since it generally has no reliable time initial association phase. Since it generally has no reliable time
during this initial communication phase, it is impossible to verify during this initial communication phase, it is impossible to verify
the period of validity of the certificates. To solve this chicken- the period of validity of the certificates. To solve this chicken-
and-egg problem, the client has to rely on external means. and-egg problem, the client has to rely on external means.
10.3. Revocation of Server Certificates 10.3. Revocation of Server Certificates
skipping to change at page 19, line 25 skipping to change at page 19, line 25
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 for his technical review and specific Also, thanks go to Harlan Stenn for his technical review and specific
text contributions to this document. text contributions to this document.
12. References 12. References
12.1. Normative References 12.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, February Hashing for Message Authentication", RFC 2104, DOI
1997. 10.17487/RFC2104, February 1997,
<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, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<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, June 2005. Transform Introduction", RFC 4082, DOI 10.17487/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, October 2014. Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>.
12.2. Informative References 12.2. Informative References
[I-D.iab-privsec-confidentiality-threat]
Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", draft-iab-privsec-
confidentiality-threat-07 (work in progress), May 2015.
[I-D.ietf-ntp-cms-for-nts-message] [I-D.ietf-ntp-cms-for-nts-message]
Sibold, D., Teichel, K., Roettger, S., and R. Housley, Sibold, D., Teichel, K., Roettger, S., and R. Housley,
"Protecting Network Time Security Messages with the "Protecting Network Time Security Messages with the
Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms-
for-nts-message-03 (work in progress), April 2015. for-nts-message-04 (work in progress), July 2015.
[I-D.ietf-tictoc-multi-path-synchronization] [I-D.ietf-tictoc-multi-path-synchronization]
Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi- Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi, "Multi-
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 of
Precision Clock Synchronization for Measurement Control 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, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
Requirements for Security", BCP 106, RFC 4086, June 2005. "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[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, June 2013. RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624, DOI
10.17487/RFC7624, August 2015,
<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
TICTOC security requirements [RFC7384]. TICTOC security requirements [RFC7384].
skipping to change at page 23, line 20 skipping to change at page 23, line 35
The protocol sequence starts with the client sending an association The protocol sequence starts with the client sending an association
message, called client_assoc. This message contains message, called client_assoc. This message contains
o the NTS message ID "client_assoc", o the NTS message ID "client_assoc",
o a nonce, o a nonce,
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 the hostname of the client,
o a selection of accepted hash algorithms, and o a selection of accepted hash algorithms, and
o a selection of accepted encryption algorithms. o a selection of accepted encryption algorithms.
B.2.3. Message Type: "server_assoc" B.2.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",
skipping to change at page 23, line 43 skipping to change at page 24, line 9
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 hash 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 hostname of the server,
o the server's choice of algorithm for encryption and for o the server's choice of algorithm for encryption and for
cryptographic hashing, all of which MUST be chosen from the cryptographic hashing, 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
skipping to change at page 29, line 6 skipping to change at page 29, line 6
parameters to the client. parameters to the client.
B.3.5.2. Message Type: "client_bpar" B.3.5.2. Message Type: "client_bpar"
This message is sent by the client in order to establish a secured This message is sent by the client in order to establish a secured
time broadcast association with the server. It contains time broadcast association with the server. It contains
o the NTS message ID "client_bpar", o the NTS message ID "client_bpar",
o the NTS version number negotiated during association, o the NTS version number negotiated during association,
o a nonce, o a nonce, and
o the client's hostname, and
o the signature algorithm negotiated during association. o the signature algorithm negotiated during association.
B.3.5.3. Message Type: "server_bpar" B.3.5.3. Message Type: "server_bpar"
This message is sent by the server upon receipt of a client_bpar This message is sent by the server upon receipt of a client_bpar
message during the broadcast loop of the server. It contains message during the broadcast loop of the server. It contains
o the NTS message ID "server_bpar", o the NTS message ID "server_bpar",
 End of changes. 20 change blocks. 
44 lines changed or deleted 46 lines changed or added

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