< draft-ietf-ntp-network-time-security-10.txt   draft-ietf-ntp-network-time-security-11.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 7, 2016 Google Inc. Expires: April 21, 2016 Google Inc.
K. Teichel K. Teichel
PTB PTB
October 05, 2015 October 19, 2015
Network Time Security Network Time Security
draft-ietf-ntp-network-time-security-10 draft-ietf-ntp-network-time-security-11
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 7, 2016. This Internet-Draft will expire on April 21, 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 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4
2.2. Common Terminology for PTP and NTP . . . . . . . . . . . 4 2.2. Common Terminology for PTP and NTP . . . . . . . . . . . 4
3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 5
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. NTS Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 5. NTS Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Unicast Time Synchronisation Messages . . . . . . . . . . 7 6.1. Unicast Time Synchronisation Messages . . . . . . . . . . 7
6.1.1. Preconditions for the Unicast Time Synchronization 6.1.1. Preconditions for the Unicast Time Synchronization
Exchange . . . . . . . . . . . . . . . . . . . . . . 7 Exchange . . . . . . . . . . . . . . . . . . . . . . 7
6.1.2. Goals of the Unicast Time Synchronization Exchange . 7 6.1.2. Goals of the Unicast Time Synchronization Exchange . 8
6.1.3. Message Type: "time_request" . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . 8 Synchronization Exchange . . . . . . . . . . . . . . 9
6.2. Broadcast Time Synchronization Exchange . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . 9 Exchange . . . . . . . . . . . . . . . . . . . . . . 10
6.2.2. Goals of the Broadcast Time Synchronization Exchange 10 6.2.2. Goals of the Broadcast Time Synchronization Exchange 11
6.2.3. Message Type: "server_broad" . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . . . 12 6.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . . . 13
6.3.1. Preconditions for the Broadcast Keycheck Exchange . . 12 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 . . . . . . 13
6.3.3. Message Type: "client_keycheck" . . . . . . . . . . . 13 6.3.3. Message Type: "client_keycheck" . . . . . . . . . . . 14
6.3.4. Message Type: "server_keycheck" . . . . . . . . . . . 13 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 14
7. Server Seed Considerations . . . . . . . . . . . . . . . . . 15 7. Server Seed Considerations . . . . . . . . . . . . . . . . . 16
8. Hash Algorithms and MAC Generation . . . . . . . . . . . . . 15 8. Hash Algorithms and MAC Generation . . . . . . . . . . . . . 16
8.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 15 8.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 16
8.2. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 16 8.2. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Initial Verification of the Server Certificates . . . . 16 10.2. Initial Verification of the Server Certificates . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. (informative) TICTOC Security Requirements . . . . . 21 Appendix A. (informative) TICTOC Security Requirements . . . . . 21
Appendix B. (normative) Inherent Association Protocol Messages . 22 Appendix B. (normative) Inherent Association Protocol Messages . 23
B.1. Overview of NTS with Inherent Association Protocol . . . 22 B.1. Overview of NTS with Inherent Association Protocol . . . 23
B.2. Association Message Exchange . . . . . . . . . . . . . . 22 B.2. Access Message Exchange . . . . . . . . . . . . . . . . . 23
B.2.1. Goals of the Association Exchange . . . . . . . . . . 23 B.2.1. Goals of the Access Message Exchange . . . . . . . . 23
B.2.2. Message Type: "client_assoc" . . . . . . . . . . . . 23 B.2.2. Message Type: "client_access" . . . . . . . . . . . . 24
B.2.3. Message Type: "server_assoc" . . . . . . . . . . . . 23 B.2.3. Message Type: "server_access" . . . . . . . . . . . . 24
B.2.4. Procedure Overview of the Association Exchange . . . 24 B.2.4. Procedure Overview of the Access Exchange . . . . . . 24
B.3. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 25 B.3. Association Message Exchange . . . . . . . . . . . . . . 24
B.3.1. Goals of the Cookie Exchange . . . . . . . . . . . . 25 B.3.1. Goals of the Association Exchange . . . . . . . . . . 25
B.3.2. Message Type: "client_cook" . . . . . . . . . . . . . 26 B.3.2. Message Type: "client_assoc" . . . . . . . . . . . . 25
B.3.3. Message Type: "server_cook" . . . . . . . . . . . . . 26 B.3.3. Message Type: "server_assoc" . . . . . . . . . . . . 25
B.3.4. Procedure Overview of the Cookie Exchange . . . . . . 27 B.3.4. Procedure Overview of the Association Exchange . . . 26
B.3.5. Broadcast Parameter Messages . . . . . . . . . . . . 28 B.4. Cookie Message Exchange . . . . . . . . . . . . . . . . . 27
Appendix C. (normative) Using TESLA for Broadcast-Type Messages 30 B.4.1. Goals of the Cookie Exchange . . . . . . . . . . . . 27
C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 30 B.4.2. Message Type: "client_cook" . . . . . . . . . . . . . 28
C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 32 B.4.3. Message Type: "server_cook" . . . . . . . . . . . . . 28
C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 33 B.4.4. Procedure Overview of the Cookie Exchange . . . . . . 29
C.4. Authentication of Received Packets . . . . . . . . . . . 33 B.4.5. Broadcast Parameter Messages . . . . . . . . . . . . 30
Appendix D. (informative) Dependencies . . . . . . . . . . . . . 35 Appendix C. (normative) Using TESLA for Broadcast-Type Messages 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 C.1. Server Preparation . . . . . . . . . . . . . . . . . . . 32
C.2. Client Preparation . . . . . . . . . . . . . . . . . . . 34
C.3. Sending Authenticated Broadcast Packets . . . . . . . . . 35
C.4. Authentication of Received Packets . . . . . . . . . . . 35
Appendix D. (informative) Dependencies . . . . . . . . . . . . . 37
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 5, line 27 skipping to change at page 5, line 33
o Authorization: NTS enables the client to verify its time server's o Authorization: NTS enables the client to verify its time server's
authorization. NTS optionally enables the server to verify the authorization. NTS optionally enables the server to verify the
client's authorization as well. client's authorization as well.
o Request-Response-Consistency: NTS enables a client to match an o Request-Response-Consistency: NTS enables a client to match an
incoming response to a request it has sent. NTS also enables the incoming response to a request it has sent. NTS also enables the
client to deduce from the response whether its request to the client to deduce from the response whether its request to the
server has arrived without alteration. server has arrived without alteration.
o Integration with protocols: NTS can be used to secure different o Applicability to Protocols: NTS can be used to secure different
time synchronization protocols, specifically at least NTP and PTP. time synchronization protocols, specifically at least NTP and PTP.
A client or server running an NTS-secured version of a time
protocol does not negatively affect other participants who are o Integration with Protocols: A client or server running an NTS-
running unsecured versions of that protocol. secured version of a time protocol does not negatively affect
other participants who are running unsecured versions of that
protocol.
o Server-Side Statelessness: All security measures of NTS work
without creating the necessity for a server to keep state of a
connection.
o Prevention of Amplification Attacks: All communication introduced
by NTS offers protection against abuse for amplification denial-
of-service attacks.
5. NTS Overview 5. NTS Overview
NTS initially verifies the authenticity of the time server and NTS initially verifies the authenticity of the time server and
exchanges a symmetric key, the so-called cookie, as well as a key exchanges a symmetric key, the so-called cookie, as well as a key
input value (KIV). After the cookie and the KIV are exchanged, the input value (KIV). The KIV can be opaque for the client. After the
client then uses them to protect the authenticity and the integrity cookie and the KIV are exchanged, the client then uses them to
of subsequent unicast-type time synchronization packets. In order to protect the authenticity and the integrity of subsequent unicast-type
do this, a Message Authentication Code (MAC) is attached to each time time synchronization packets. In order to do this, a Message
synchronization packet. The calculation of the MAC includes the Authentication Code (MAC) is attached to each time synchronization
whole time synchronization packet and the cookie which is shared packet. The calculation of the MAC includes the whole time
between client and server. synchronization packet and the cookie which is shared between client
and server.
The cookie is calculated according to: The cookie is calculated according to:
cookie = MSB_<b> (HMAC(server seed, KIV)), cookie = MSB_<b> (HMAC(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.
Since the server does not keep a state of the client, it has to Since the server does not keep a state of the client, it has to
recalculate the cookie each time it receives a unicast time recalculate the cookie each time it receives a unicast time
synchronization request from the client. To this end, the client has synchronization request from the client. To this end, the client has
to attach its KIV to each request (see Section 6.1). to attach its KIV to each request (see Section 6.1).
skipping to change at page 15, line 36 skipping to change at page 16, line 16
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 hash
algorithm, see Section 8.1. algorithm, see Section 8.1.
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.3). request (Appendix B.4).
8. Hash Algorithms and MAC Generation 8. Hash Algorithms and MAC Generation
8.1. Hash Algorithms 8.1. Hash Algorithms
Hash algorithms are used for calculation of the cookie and the MAC. Hash algorithms are used for calculation of the cookie and the MAC.
The client and the server negotiate a hash algorithm H during the The client and the server negotiate a hash algorithm H during the
association phase at the beginning. The selected algorithm H is used association phase at the beginning. The selected algorithm H is used
for all hashing processes in that run. for all hashing processes in that run.
skipping to change at page 17, line 10 skipping to change at page 17, line 38
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
According to Section 7, it is the client's responsibility to initiate According to Section 7, it is the client's responsibility to initiate
a new association with the server after the server's certificate a new association with the server after the server's certificate
expires. To this end, the client reads the expiration date of the expires. To this end, the client reads the expiration date of the
certificate during the certificate message exchange (Appendix B.2.3). certificate during the certificate message exchange (Appendix B.3.3).
Furthermore, certificates may also be revoked prior to the normal Furthermore, certificates may also be revoked prior to the normal
expiration date. To increase security the client MAY periodically expiration date. To increase security the client MAY periodically
verify the state of the server's certificate via Online Certificate verify the state of the server's certificate via Online Certificate
Status Protocol (OCSP) Online Certificate Status Protocol (OCSP) Status Protocol (OCSP) Online Certificate Status Protocol (OCSP)
[RFC6960]. [RFC6960].
10.4. Mitigating Denial-of-Service for broadcast packets 10.4. Mitigating Denial-of-Service for broadcast packets
TESLA authentication buffers packets for delayed authentication. TESLA authentication buffers packets for delayed authentication.
This makes the protocol vulnerable to flooding attacks, causing the This makes the protocol vulnerable to flooding attacks, causing the
skipping to change at page 22, line 22 skipping to change at page 23, line 7
| | Hybrid mode | SHOULD | - | | | Hybrid mode | SHOULD | - |
+---------+------------------------------+-------------+------------+ +---------+------------------------------+-------------+------------+
*) See discussion in Section 10.5. *) See discussion in Section 10.5.
Comparison of NTS specification against Security Requirements of Time Comparison of NTS specification against Security Requirements of Time
Protocols in Packet Switched Networks (RFC 7384) Protocols in Packet Switched Networks (RFC 7384)
Appendix B. (normative) Inherent Association Protocol Messages Appendix B. (normative) Inherent Association Protocol Messages
One option for completing association, cookie exchange, and also This appendix presents a procedure that performs the association, the
broadcast parameter exchange between a client and server is to use cookie, and also the broadcast parameter message exchanges between a
the message exchanges listed below. client and a server. This procedure is one possible way to achieve
the preconditions listed in Sections Section 6.1.1, Section 6.2.1,
and Section 6.3.1 while taking into account the objectives given in
Section Section 4.
B.1. Overview of NTS with Inherent Association Protocol B.1. Overview of NTS with Inherent Association Protocol
This inherent association protocol applies X.509 certificates to This inherent association protocol applies X.509 certificates to
verify the authenticity of the time server and to exchange the verify the authenticity of the time server and to exchange the
cookie. This is done in two separate message exchanges, described cookie. This is done in two separate message exchanges, described
below. A client needs a public/private key pair for encryption, with below. An additional required exchange in advance serves to limit
the public key enclosed in a certificate. A server needs a public/ the amplification potential of the association message exchange.
A client needs a public/private key pair for encryption, with the
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> (HMAC(server seed, H(certificate of client))).
The client's certificate contains the client's public key and enables The client's certificate contains the client's public key and enables
the server to identify the client, if client authorization is the server to identify the client, if client authorization is
desired. desired.
B.2. Association Message Exchange B.2. Access Message Exchange
This message exchange serves only to prevent the next (association)
exchange from being abusable for amplification denial-of-service
attacks.
B.2.1. Goals of the Access Message Exchange
The access message exchange:
o transfers a secret value from the server to the client
(initiator),
o the secret value permits the client to initiate an association
message exchange.
B.2.2. Message Type: "client_access"
This message is sent by a client who intends to perform an
association exchange with the server in the future. It contains:
o the NTS message ID "client_access".
B.2.3. Message Type: "server_access"
This message is sent by the server on receipt of a client_access
message. It contains:
o the NTS message ID "server_access",
o an access key.
B.2.4. Procedure Overview of the Access Exchange
For an access exchange, the following steps are performed:
1. The client sends a client_access message to the server.
2. Upon receipt of a client_access, the server calculates the access
key according to
access_key = HMAC(server seed; address of client),
then it constructs and sends a reply in the form of a
server_access message. In general the address of the client will
be represented by the IP address of the client.
3. The client waits for a response in the form of a server_access
message. Upon receipt of one, it MUST memorize the included
access key.
B.3. Association Message Exchange
In this message exchange, the participants negotiate the hash and In this message exchange, the participants negotiate the hash 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.2.1. Goals of the Association Exchange B.3.1. Goals of the Association Exchange
The association exchange: The association exchange:
o enables the client to verify any communication with the server as o enables the client to verify any communication with the server as
authentic, authentic,
o lets the participants negotiate NTS version and algorithms, o lets the participants negotiate NTS version and algorithms,
o guarantees authenticity and integrity of the negotiation result to o guarantees authenticity and integrity of the negotiation result to
the client, the client,
o guarantees to the client that the negotiation result is based on o guarantees to the client that the negotiation result is based on
the client's original, unaltered request. the client's original, unaltered request.
B.2.2. Message Type: "client_assoc" B.3.2. Message Type: "client_assoc"
The protocol sequence starts with the client sending an association This message is sent by the client if it wants to perform association
message, called client_assoc. This message contains with a server. It contains
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 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 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.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 hash algorithms and selection of accepted encryption
skipping to change at page 24, line 22 skipping to change at page 26, line 22
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.
B.2.4. Procedure Overview of the Association Exchange B.3.4. Procedure Overview of the Association Exchange
For an association exchange, the following steps are performed: For an association exchange, the following steps are performed:
1. The client sends a client_assoc message to the server. It MUST 1. The client sends a client_assoc message to the server. It MUST
keep the transmitted values for the version number and algorithms keep the transmitted values for the version number and algorithms
available for later checks. available for later checks.
2. Upon receipt of a client_assoc message, the server constructs and 2. Upon receipt of a client_assoc message, the server checks the
sends a reply in the form of a server_assoc message as described validity of the included access key. If it is not valid, the
in Appendix B.2.3. Upon unsuccessful negotiation for version server MUST abort communication. If it is valid, the server
number or algorithms the server_assoc message MUST contain an constructs and sends a reply in the form of a server_assoc
error code. message as described in Appendix B.3.3. Upon unsuccessful
negotiation for version number or algorithms the server_assoc
message MUST contain an error code.
3. The client waits for a reply in the form of a server_assoc 3. The client waits for a reply in the form of a server_assoc
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,
skipping to change at page 25, line 29 skipping to change at page 27, line 32
client_ / \ server_ client_ / \ server_
assoc / \ assoc assoc / \ assoc
/ \| / \|
Client ---------------------------> Client --------------------------->
<------ Association -----> <------ Association ----->
exchange exchange
Procedure for association and cookie exchange. Procedure for association and cookie exchange.
B.3. Cookie Messages B.4. Cookie Message Exchange
During this message exchange, the server transmits a secret cookie to During this message exchange, the server transmits a secret cookie to
the client securely. The cookie will later be used for integrity the client securely. The cookie will later be used for integrity
protection during unicast time synchronization. protection during unicast time synchronization.
B.3.1. Goals of the Cookie Exchange B.4.1. Goals of the Cookie Exchange
The cookie exchange: The cookie exchange:
o enables the server to check the client's authorization via its o enables the server to check the client's authorization via its
certificate (optional), certificate (optional),
o supplies the client with the correct cookie and corresponding KIV o supplies the client with the correct cookie and corresponding KIV
for its association to the server, for its association to the server,
o guarantees to the client that the cookie originates from the o guarantees to the client that the cookie originates from the
server and that it is based on the client's original, unaltered server and that it is based on the client's original, unaltered
request. request.
o guarantees that the received cookie is unknown to anyone but the o guarantees that the received cookie is unknown to anyone but the
server and the client. server and the client.
B.3.2. Message Type: "client_cook" B.4.2. Message Type: "client_cook"
This message is sent by the client upon successful authentication of This message is sent by the client upon successful authentication of
the server. In this message, the client requests a cookie from the the server. In this message, the client requests a cookie from the
server. The message contains server. The message contains
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 hash algorithm H,
o the client's certificate. o the client's certificate.
B.3.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 of the client's certificate,
as conveyed during client_cook, in order to calculate the cookie 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,
skipping to change at page 27, line 5 skipping to change at page 29, line 5
* 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
calculated according to the transmitted signature algorithm from calculated according to the transmitted signature algorithm from
the client_cook message. the client_cook message.
B.3.4. Procedure Overview of the Cookie Exchange B.4.4. Procedure Overview of the Cookie Exchange
For a cookie exchange, the following steps are performed: For a cookie exchange, the following steps are performed:
1. The client sends a client_cook message to the server. The client 1. The client sends a client_cook message to the server. The client
MUST save the included nonce until the reply has been processed. MUST save the included nonce until the reply has been processed.
2. Upon receipt of a client_cook message, the server checks whether 2. Upon receipt of a client_cook message, the server checks whether
it supports the given cryptographic algorithms. It then it supports the given cryptographic algorithms. It then
calculates the cookie according to the formula given in calculates the cookie according to the formula given in
Section 5. The server MAY use the client's certificate to check Section 5. The server MAY use the client's certificate to check
that the client is authorized to use the secure time that the client is authorized to use the secure time
synchronization service. With this, it MUST construct a synchronization service. With this, it MUST construct a
server_cook message as described in Appendix B.3.3. server_cook message as described in Appendix B.4.3.
3. The client awaits a reply in the form of a server_cook message; 3. The client awaits a reply in the form of a server_cook message;
upon receipt it executes the following actions: upon receipt it executes the following actions:
* It verifies that the received version number matches the one * It verifies that the received version number matches the one
negotiated beforehand. negotiated beforehand.
* It verifies the signature using the server's public key. The * It verifies the signature using the server's public key. The
signature has to authenticate the encrypted data. signature has to authenticate the encrypted data.
skipping to change at page 28, line 26 skipping to change at page 30, line 26
/| \ /| \
client_ / \ server_ client_ / \ server_
cook / \ cook cook / \ cook
/ \| / \|
Client ---------------------------> Client --------------------------->
<--- Cookie exchange --> <--- Cookie exchange -->
Procedure for association and cookie exchange. Procedure for association and cookie exchange.
B.3.5. Broadcast Parameter Messages B.4.5. Broadcast Parameter Messages
In this message exchange, the client receives the necessary In this message exchange, the client receives the necessary
information to execute the TESLA protocol in a secured broadcast information to execute the TESLA protocol in a secured broadcast
association. The client can only initiate a secure broadcast association. The client can only initiate a secure broadcast
association after successful association and cookie exchanges and association after successful association and cookie exchanges and
only if it has made sure that its clock is roughly synchronized to only if it has made sure that its clock is roughly synchronized to
the server's. the server's.
See Appendix C for more details on TESLA. See Appendix C for more details on TESLA.
B.3.5.1. Goals of the Broadcast Parameter Exchange B.4.5.1. Goals of the Broadcast Parameter Exchange
The broadcast parameter exchange The broadcast parameter exchange
o provides the client with all the information necessary to process o provides the client with all the information necessary to process
broadcast time synchronization messages from the server, and broadcast time synchronization messages from the server, and
o guarantees authenticity, integrity and freshness of the broadcast o guarantees authenticity, integrity and freshness of the broadcast
parameters to the client. parameters to the client.
B.3.5.2. Message Type: "client_bpar" B.4.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, and o a nonce, and
o the signature algorithm negotiated during association. o the signature algorithm negotiated during association.
B.3.5.3. Message Type: "server_bpar" B.4.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",
o the version number as transmitted in the client_bpar message, o the version number as transmitted in the client_bpar message,
o the nonce transmitted in client_bpar, o the nonce transmitted in client_bpar,
skipping to change at page 29, line 39 skipping to change at page 31, line 39
* the disclosure delay (number of intervals between use and * the disclosure delay (number of intervals between use and
disclosure of a key), disclosure of a key),
* the time at which the next time interval will start, and * the time at which the next time interval will start, and
* the next interval's associated index. * the next interval's associated index.
o The message also contains a signature signed by the server with o The message also contains a signature signed by the server with
its private key, verifying all the data listed above. its private key, verifying all the data listed above.
B.3.5.4. Procedure Overview of the Broadcast Parameter Exchange B.4.5.4. Procedure Overview of the Broadcast Parameter Exchange
A broadcast parameter exchange consists of the following steps: A broadcast parameter exchange consists of the following steps:
1. The client sends a client_bpar message to the server. It MUST 1. The client sends a client_bpar message to the server. It MUST
remember the transmitted values for the nonce, the version number remember the transmitted values for the nonce, the version number
and the signature algorithm. and the signature algorithm.
2. Upon receipt of a client_bpar message, the server constructs and 2. Upon receipt of a client_bpar message, the server constructs and
sends a server_bpar message as described in Appendix B.3.5.3. sends a server_bpar message as described in Appendix B.4.5.3.
3. The client waits for a reply in the form of a server_bpar 3. The client waits for a reply in the form of a server_bpar
message, on which it performs the following checks: message, on which it performs the following checks:
* The message must contain all the necessary information for the * The message must contain all the necessary information for the
TESLA protocol, as listed in Appendix B.3.5.3. TESLA protocol, as listed in Appendix B.4.5.3.
* The message must contain a nonce belonging to a client_bpar * The message must contain a nonce belonging to a client_bpar
message that the client has previously sent. message that the client has previously sent.
* Verification of the message's signature. * Verification of the message's signature.
If any information is missing or if the server's signature cannot If any information is missing or if the server's signature cannot
be verified, the client MUST abort the broadcast run. If all be verified, the client MUST abort the broadcast run. If all
checks are successful, the client MUST remember all the broadcast checks are successful, the client MUST remember all the broadcast
parameters received for later checks. parameters received for later checks.
 End of changes. 45 change blocks. 
91 lines changed or deleted 167 lines changed or added

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