draft-ietf-ntp-network-time-security-11.txt   draft-ietf-ntp-network-time-security-12.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: April 21, 2016 Google Inc. Expires: June 23, 2016 Google Inc.
K. Teichel K. Teichel
PTB PTB
October 19, 2015 December 21, 2015
Network Time Security Network Time Security
draft-ietf-ntp-network-time-security-11 draft-ietf-ntp-network-time-security-12
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 April 21, 2016. This Internet-Draft will expire on June 23, 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 2, line 44 skipping to change at page 2, line 44
6.1.3. Message Type: "time_request" . . . . . . . . . . . . 8 6.1.3. Message Type: "time_request" . . . . . . . . . . . . 8
6.1.4. Message Type: "time_response" . . . . . . . . . . . . 8 6.1.4. Message Type: "time_response" . . . . . . . . . . . . 8
6.1.5. Procedure Overview of the Unicast Time 6.1.5. Procedure Overview of the Unicast Time
Synchronization Exchange . . . . . . . . . . . . . . 9 Synchronization Exchange . . . . . . . . . . . . . . 9
6.2. Broadcast Time Synchronization Exchange . . . . . . . . . 10 6.2. Broadcast Time Synchronization Exchange . . . . . . . . . 10
6.2.1. Preconditions for the Broadcast Time Synchronization 6.2.1. Preconditions for the Broadcast Time Synchronization
Exchange . . . . . . . . . . . . . . . . . . . . . . 10 Exchange . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . 13 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 14 6.3.5. Procedure Overview of the Broadcast Keycheck Exchange 15
7. Server Seed Considerations . . . . . . . . . . . . . . . . . 16 7. Server Seed Considerations . . . . . . . . . . . . . . . . . 16
8. Hash Algorithms and MAC Generation . . . . . . . . . . . . . 16 8. Hash Algorithms and MAC Generation . . . . . . . . . . . . . 16
8.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 16 8.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 16
8.2. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 16 8.2. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Initial Verification of the Server Certificates . . . . 17 10.2. Initial Verification of the Server Certificates . . . . 17
10.3. Revocation of Server Certificates . . . . . . . . . . . 17 10.3. Revocation of Server Certificates . . . . . . . . . . . 18
10.4. Mitigating Denial-of-Service for broadcast packets . . . 17 10.4. Mitigating Denial-of-Service for broadcast packets . . . 18
10.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 18 10.5. Delay Attack . . . . . . . . . . . . . . . . . . . . . . 18
10.6. Random Number Generation . . . . . . . . . . . . . . . . 19 10.6. Random Number Generation . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. (informative) TICTOC Security Requirements . . . . . 21 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 . . . . . . . . . . . . . . . . . 23 B.2. Access Message Exchange . . . . . . . . . . . . . . . . . 24
B.2.1. Goals of the Access Message Exchange . . . . . . . . 23 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 . . . . . . 24 B.2.4. Procedure Overview of the Access Exchange . . . . . . 24
B.3. Association Message Exchange . . . . . . . . . . . . . . 24 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" . . . . . . . . . . . . 25 B.3.2. Message Type: "client_assoc" . . . . . . . . . . . . 25
B.3.3. Message Type: "server_assoc" . . . . . . . . . . . . 25 B.3.3. Message Type: "server_assoc" . . . . . . . . . . . . 26
B.3.4. Procedure Overview of the Association Exchange . . . 26 B.3.4. Procedure Overview of the Association Exchange . . . 26
B.4. Cookie Message Exchange . . . . . . . . . . . . . . . . . 27 B.4. Cookie Message Exchange . . . . . . . . . . . . . . . . . 27
B.4.1. Goals of the Cookie Exchange . . . . . . . . . . . . 27 B.4.1. Goals of the Cookie Exchange . . . . . . . . . . . . 28
B.4.2. Message Type: "client_cook" . . . . . . . . . . . . . 28 B.4.2. Message Type: "client_cook" . . . . . . . . . . . . . 28
B.4.3. Message Type: "server_cook" . . . . . . . . . . . . . 28 B.4.3. Message Type: "server_cook" . . . . . . . . . . . . . 28
B.4.4. Procedure Overview of the Cookie Exchange . . . . . . 29 B.4.4. Procedure Overview of the Cookie Exchange . . . . . . 29
B.4.5. Broadcast Parameter Messages . . . . . . . . . . . . 30 B.4.5. Broadcast Parameter Messages . . . . . . . . . . . . 30
Appendix C. (normative) Using TESLA for Broadcast-Type Messages 32 Appendix C. (normative) Using TESLA for Broadcast-Type Messages 32
C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 32 C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 32
C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 34 C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 34
C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 35 C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 35
C.4. Authentication of Received Packets . . . . . . . . . . . 35 C.4. Authentication of Received Packets . . . . . . . . . . . 35
Appendix D. (informative) Dependencies . . . . . . . . . . . . . 37 Appendix D. (informative) Dependencies . . . . . . . . . . . . . 37
skipping to change at page 7, line 46 skipping to change at page 7, line 46
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.
One way of realising these requirements is to use the Association and One way of realizing these requirements is to use the Association and
Cookie Message Exchanges described in Appendix B. Cookie Message Exchanges described in Appendix B.
6.1.2. Goals of the Unicast Time Synchronization Exchange 6.1.2. Goals of the Unicast Time Synchronization Exchange
The unicast time synchronization exchange: The unicast time synchronization exchange:
o exchanges (unicast) time synchronization data as specified by the o exchanges time synchronization data as specified by the
appropriate time synchronization protocol, appropriate time synchronization protocol,
o guarantees authenticity and integrity of the request to the
server,
o guarantees authenticity and integrity of the response to the o guarantees authenticity and integrity of the response to the
client, client,
o guarantees request-response-consistency to the client. o guarantees request-response-consistency to the client.
6.1.3. Message Type: "time_request" 6.1.3. Message Type: "time_request"
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 hash algorithm H,
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
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 hash algorithm. The message contains
o the NTS message ID "time_response", o the NTS message ID "time_response",
skipping to change at page 9, line 13 skipping to change at page 9, line 15
of the above data. of the above data.
6.1.5. Procedure Overview of the Unicast Time Synchronization Exchange 6.1.5. Procedure Overview of the Unicast Time Synchronization Exchange
For a unicast time synchronization exchange, the following steps are For a unicast time synchronization exchange, the following steps are
performed: performed:
1. The client sends a time_request message to the server. The 1. The client sends a time_request message to the server. The
client MUST save the included nonce and the transmit_timestamp client MUST save the included nonce and the transmit_timestamp
(from the time synchronization data) as a correlated pair for (from the time synchronization data) as a correlated pair for
later verification steps. later verification steps. Optionally, the client protects the
request message with an appended MAC.
2. Upon receipt of a time_request message, the server re-calculates 2. Upon receipt of a time_request message, the server performs the
the cookie, then computes the necessary time synchronization data following steps:
and constructs a time_response message as given in Section 6.1.4.
* It re-calculates the cookie.
* If the request message contains a MAC the server verifies the
received data.
+ If falsified the server MUST stop the processing of the
request.
+ If verified the server continuous to process the request.
* The server computes the necessary time synchronization data
and constructs a time_response message as given in
Section 6.1.4.
3. The client awaits a reply in the form of a time_response message. 3. The client awaits a reply in the form of a time_response message.
Upon receipt, it checks: Upon receipt, it checks:
* that the transmitted version number matches the one negotiated * that the transmitted version number matches the one negotiated
previously, previously,
* that the transmitted nonce belongs to a previous time_request * that the transmitted nonce belongs to a previous time_request
message, message,
skipping to change at page 13, line 42 skipping to change at page 13, line 45
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.
These requirements conform to those for the unicast time These requirements conform to those for the unicast time
synchronization exchange. Accordingly, they too can be realised via synchronization exchange. Accordingly, they too can be realized via
the Association and Cookie Message Exchanges described in Appendix B the Association and Cookie Message Exchanges described in Appendix B
(Appendix B). (Appendix B).
6.3.2. Goals of the Broadcast Keycheck Exchange 6.3.2. Goals of the Broadcast Keycheck Exchange
The keycheck exchange: The keycheck exchange:
o guarantees to the client that the key belonging to the respective o guarantees to the client that the key belonging to the respective
TESLA interval communicated in the exchange had not been disclosed TESLA interval communicated in the exchange had not been disclosed
before the client_keycheck message was sent. before the client_keycheck message was sent.
 End of changes. 22 change blocks. 
28 lines changed or deleted 48 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/