draft-ietf-ntp-network-time-security-02.txt   draft-ietf-ntp-network-time-security-03.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 18, 2014 Expires: September 20, 2014
K. Teichel K. Teichel
PTB PTB
February 14, 2014 March 19, 2014
Network Time Security Network Time Security
draft-ietf-ntp-network-time-security-02.txt draft-ietf-ntp-network-time-security-03.txt
Abstract Abstract
This document describes the Network Time Security (NTS) protocol that This document describes the Network Time Security (NTS) protocol that
enables secure authentication of time servers using Network Time enables secure authentication of time servers using Network Time
Protocol (NTP) or Precision Time Protocol (PTP). Its design Protocol (NTP) or Precision Time Protocol (PTP). Its design
considers the special requirements of precise timekeeping, which are considers the special requirements of precise timekeeping, which are
described in Security Requirements of Time Protocols in Packet described in Security Requirements of Time Protocols in Packet
Switched Networks [I-D.ietf-tictoc-security-requirements]. Switched Networks [I-D.ietf-tictoc-security-requirements].
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 18, 2014. This Internet-Draft will expire on September 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 20 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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. Security Threats . . . . . . . . . . . . . . . . . . . . . . 4 2. Security Threats . . . . . . . . . . . . . . . . . . . . . . 4
3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 4. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
5. NTS Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 5. NTS Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Symmetric and Client/Server Mode . . . . . . . . . . . . 5 5.1. Symmetric and Client/Server Mode . . . . . . . . . . . . 5
5.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 5 5.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 5
6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Association Messages . . . . . . . . . . . . . . . . . . 6 6.1. Association Messages . . . . . . . . . . . . . . . . . . 6
6.1.1. Message type: "client_assoc" . . . . . . . . . . . . 6 6.1.1. Message type: "client_assoc" . . . . . . . . . . . . 6
6.1.2. Message type: "server_assoc" . . . . . . . . . . . . 6 6.1.2. Message type: "server_assoc" . . . . . . . . . . . . 7
6.2. Certificate Messages . . . . . . . . . . . . . . . . . . 7 6.2. Certificate Messages . . . . . . . . . . . . . . . . . . 7
6.2.1. Message type: "client_cert" . . . . . . . . . . . . . 7 6.2.1. Message type: "client_cert" . . . . . . . . . . . . . 7
6.2.2. Message type: "server_cert" . . . . . . . . . . . . . 7 6.2.2. Message type: "server_cert" . . . . . . . . . . . . . 8
6.3. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 8 6.3. Cookie Messages . . . . . . . . . . . . . . . . . . . . . 8
6.3.1. Message type: "client_cook" . . . . . . . . . . . . . 8 6.3.1. Message type: "client_cook" . . . . . . . . . . . . . 8
6.3.2. Message type: "server_cook" . . . . . . . . . . . . . 8 6.3.2. Message type: "server_cook" . . . . . . . . . . . . . 8
6.4. Unicast Time Synchronisation Messages . . . . . . . . . . 8 6.4. Unicast Time Synchronisation Messages . . . . . . . . . . 9
6.4.1. Message type: "time_request" . . . . . . . . . . . . 9 6.4.1. Message type: "time_request" . . . . . . . . . . . . 9
6.4.2. Message type: "time_response" . . . . . . . . . . . . 9 6.4.2. Message type: "time_response" . . . . . . . . . . . . 9
6.5. Broadcast Parameter Messages . . . . . . . . . . . . . . 9 6.5. Broadcast Parameter Messages . . . . . . . . . . . . . . 10
6.5.1. Message type: "client_bpar" . . . . . . . . . . . . . 10 6.5.1. Message type: "client_bpar" . . . . . . . . . . . . . 10
6.5.2. Message type: "server_bpar" . . . . . . . . . . . . . 10 6.5.2. Message type: "server_bpar" . . . . . . . . . . . . . 10
6.6. Broadcast Message . . . . . . . . . . . . . . . . . . . . 10 6.6. Broadcast Message . . . . . . . . . . . . . . . . . . . . 11
6.6.1. Message type: "server_broad" . . . . . . . . . . . . 11 6.6.1. Message type: "server_broad" . . . . . . . . . . . . 11
7. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 11 7. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 11
7.1. The client . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. The client . . . . . . . . . . . . . . . . . . . . . . . 11
7.1.1. The client in unicast mode . . . . . . . . . . . . . 11 7.1.1. The client in unicast mode . . . . . . . . . . . . . 11
7.1.2. The client in broadcast mode . . . . . . . . . . . . 12 7.1.2. The client in broadcast mode . . . . . . . . . . . . 13
7.2. The server . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. The server . . . . . . . . . . . . . . . . . . . . . . . 14
7.2.1. The server in unicast mode . . . . . . . . . . . . . 13 7.2.1. The server in unicast mode . . . . . . . . . . . . . 14
7.2.2. The server in broadcast mode . . . . . . . . . . . . 14 7.2.2. The server in broadcast mode . . . . . . . . . . . . 14
7.3. Server Seed Refresh . . . . . . . . . . . . . . . . . . . 14 7.3. Server Seed Refresh . . . . . . . . . . . . . . . . . . . 15
8. Hash Algorithms and MAC Generation . . . . . . . . . . . . . 15 8. Hash Algorithms and MAC Generation . . . . . . . . . . . . . 15
8.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 15 8.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 15
8.2. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 15 8.2. MAC Calculation . . . . . . . . . . . . . . . . . . . . . 16
9. Server Seed Considerations . . . . . . . . . . . . . . . . . 16
9. Server Seed Considerations . . . . . . . . . . . . . . . . . 15
9.1. Server Seed Algorithm . . . . . . . . . . . . . . . . . . 16 9.1. Server Seed Algorithm . . . . . . . . . . . . . . . . . . 16
9.2. Server Seed Live Time . . . . . . . . . . . . . . . . . . 16 9.2. Server Seed Live Time . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11.1. Initial Verification of the Server Certificates . . . . 16 11.1. Initial Verification of the Server Certificates . . . . 16
11.2. Revocation of Server Certificates . . . . . . . . . . . 16 11.2. Revocation of Server Certificates . . . . . . . . . . . 17
11.3. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 17 11.3. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 17
11.4. Denial-of-Service in Broadcast Mode . . . . . . . . . . 17 11.4. Denial-of-Service in Broadcast Mode . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 18 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Extension fields . . . . . . . . . . . . . . . . . . 20 Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 19
Appendix C. TICTOC Security Requirements . . . . . . . . . . . . 21 Appendix B. Extension fields . . . . . . . . . . . . . . . . . . 22
Appendix D. Broadcast Mode . . . . . . . . . . . . . . . . . . . 22 Appendix C. TICTOC Security Requirements . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix D. Broadcast Mode . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Time synchronization protocols are utilized more and more to Time synchronization protocols are utilized more and more to
synchronize clocks in networked infrastructures. The reliable synchronize clocks in networked infrastructures. The reliable
performance of such infrastructures can be degraded seriously by performance of such infrastructures can be degraded seriously by
successful attacks against the time synchronization protocol. successful attacks against the time synchronization protocol.
Therefore, time synchronization protocols applied in critical Therefore, time synchronization protocols applied in critical
infrastructures have to provide security measures to defeat possible infrastructures have to provide security measures to defeat possible
adversaries. Consequently, the widespread Network Time Protocol adversaries. Consequently, the widespread Network Time Protocol
skipping to change at page 5, line 16 skipping to change at page 5, line 23
5.1. Symmetric and Client/Server Mode 5.1. Symmetric and Client/Server Mode
Authenticity of the time server is verified once by utilization of Authenticity of the time server is verified once by utilization of
X.509 certificates. Authenticity and integrity of the NTP packets X.509 certificates. Authenticity and integrity of the NTP packets
are then ensured by a Message Authentication Code (MAC), which is are then ensured by a Message Authentication Code (MAC), which is
attached to the NTP packet. The calculation of the MAC includes the attached to the NTP packet. The calculation of the MAC includes the
whole NTP packet and the cookie which is shared between client and whole NTP packet and the cookie which is shared between client and
server. It is calculated according to: server. It is calculated according to:
cookie = MSB_128 (HMAC(server seed, public key of client)), cookie = MSB_128 (HMAC(server seed, H(public key of client))),
with the server seed as key, and where the function MSB_128 cuts off with the server seed as key, where H is a hash function, and where
the 128 most significant bits of the result of the HMAC function. the function MSB_128 cuts off the 128 most significant bits of the
The server seed is a 128 bit random value of the server, which has to result of the HMAC function. The server seed is a 128 bit random
be kept secret. The cookie thus never changes as long as the server value of the server, which has to be kept secret. The cookie never
seed stays the same. The server seed has to be refreshed changes as long as the server seed stays the same, but the server
periodically in order to provide key freshness as required in seed has to be refreshed periodically in order to provide key
[I-D.ietf-tictoc-security-requirements]. The server does not keep a freshness as required in [I-D.ietf-tictoc-security-requirements].
state of the client. Therefore it has to recalculate the cookie each See Section 9 for details on the seed refresh and Section 7.1.1 for
time it receives a request from the client. To this end, the client the client's reaction to it.
has to attach the hash value of its public key to each request (see
Section 6.4). The server does not keep a state of the client. Therefore it has to
recalculate the cookie each time it receives a request from the
client. To this end, the client has to attach the hash value of its
public key to each request (see Section 6.4).
5.2. Broadcast Mode 5.2. Broadcast Mode
Just as in the case of the client server mode and symmetric mode, Just as in the case of the client server mode and symmetric mode,
authenticity and integrity of the NTP packets are ensured by a MAC, authenticity and integrity of the NTP packets are ensured by a MAC,
which is attached to the NTP packet by the sender. The verification which is attached to the NTP packet by the sender. The verification
of the authenticity is based on the TESLA protocol, in particular on of the authenticity is based on the TESLA protocol, in particular on
its "Not Re-using Keys" scheme, see section 3.7.2 of [RFC4082]. its "Not Re-using Keys" scheme, see section 3.7.2 of [RFC4082].
TESLA is based on a one-way chain of keys, where each key is the TESLA is based on a one-way chain of keys, where each key is the
output of a one-way function applied on the previous key in the output of a one-way function applied on the previous key in the
skipping to change at page 12, line 31 skipping to change at page 12, line 48
receipt, it checks: receipt, it checks:
* that the transmitted nonce belongs to the previous * that the transmitted nonce belongs to the previous
time_request message and . time_request message and .
* that the appended MAC verifies the time data and the * that the appended MAC verifies the time data and the
transmitted nonce. transmitted nonce.
If the nonce is invalid, the client MUST ignore this If the nonce is invalid, the client MUST ignore this
time_response message. If the MAC is invalid, the client MUST do time_response message. If the MAC is invalid, the client MUST do
one of the following: abort the run or go back to step 5. If one of the following: abort the run or go back to step 5 (because
the cookie might have changed due to a server seed refresh). If
both checks are successful, the client SHOULD continue time both checks are successful, the client SHOULD continue time
synchronization by going back to step 7. synchronization by going back to step 7.
The client's behaviour in unicast mode is also expressed in Figure 1. The client's behaviour in unicast mode is also expressed in Figure 1.
7.1.2. The client in broadcast mode 7.1.2. The client in broadcast mode
To establish a secure broadcast association with a broadcast server, To establish a secure broadcast association with a broadcast server,
the client MUST initially authenticate the broadcast server and the client MUST initially authenticate the broadcast server and
securely synchronize its time to it up to an upper bound for its time securely synchronize its time to it up to an upper bound for its time
skipping to change at page 13, line 42 skipping to change at page 14, line 11
corresponding time interval. If authenticity of a packet is corresponding time interval. If authenticity of a packet is
verified it is released from the buffer and the packet's time verified it is released from the buffer and the packet's time
information can be utilized. If the verification fails information can be utilized. If the verification fails
authenticity is no longer given. In this case the client authenticity is no longer given. In this case the client
MUST request authentic time from the server by means of a MUST request authentic time from the server by means of a
unicast time request message. unicast time request message.
See RFC 4082[RFC4082] for a detailed description of the packet See RFC 4082[RFC4082] for a detailed description of the packet
verification process. verification process.
The client's behaviour in broadcast mode can also be seen in Figure The client's behaviour in broadcast mode can also be seen in
2. Figure 2.
7.2. The server 7.2. The server
The server's behaviour is not as easy to express in sequential terms The server's behaviour is not as easy to express in sequential terms
as the client's, not even for a single association with one client. as the client's, not even for a single association with one client.
This is because the server does not keep state of any connection. This is because the server does not keep state of any connection.
7.2.1. The server in unicast mode 7.2.1. The server in unicast mode
A broadcast server MUST also support unicast mode, in order to A broadcast server MUST also support unicast mode, in order to
provide the initial time synchronization is a precondition for any provide the initial time synchronization is a precondition for any
broadcast association. To support unicast mode, the server MUST be broadcast association. To support unicast mode, the server MUST be
ready to perform the following actions: ready to perform the following actions:
o Upon receipt of a client_assoc message, the server constructs and o Upon receipt of a client_assoc message, the server constructs and
sends a reply in the form of a server_assoc message as described sends a reply in the form of a server_assoc message as described
in Section 6.1.2. in Section 6.1.2.
o Upon receipt of a client_cert message, the server checks whether o Upon receipt of a client_cert message, the server checks whether
skipping to change at page 18, line 35 skipping to change at page 19, line 5
[I-D.ietf-tictoc-security-requirements] [I-D.ietf-tictoc-security-requirements]
Mizrahi, T., "Security Requirements of Time Protocols in Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", draft-ietf-tictoc-security- Packet Switched Networks", draft-ietf-tictoc-security-
requirements-05 (work in progress), April 2013. requirements-05 (work in progress), April 2013.
[Roettger] [Roettger]
Roettger, S., "Analysis of the NTP Autokey Procedures", Roettger, S., "Analysis of the NTP Autokey Procedures",
February 2012. February 2012.
Appendix A. Flow Diagrams of Client Behaviour 13.3. URIs
[1] I-D.ietf-tictoc-security-requirements
Appendix A. Flow Diagrams of Client Behaviour
+---------------------+ +---------------------+
|Association Messages | |Association Messages |
+----------+----------+ +----------+----------+
| |
v v
+---------------------+ +---------------------+
|Certificate Messages | |Certificate Messages |
+----------+----------+ +----------+----------+
| |
+------------------------------>o +------------------------------>o
skipping to change at page 21, line 20 skipping to change at page 22, line 40
| "broadcast parameters" | server_bpar | | "broadcast parameters" | server_bpar |
| | | | | |
| "broadcast message" | server_broad | | "broadcast message" | server_broad |
+------------------------+---------------+ +------------------------+---------------+
Appendix C. TICTOC Security Requirements Appendix C. TICTOC Security Requirements
The following table compares the NTS specifications against the The following table compares the NTS specifications against the
TICTOC security requirements [I-D.ietf-tictoc-security-requirements]. TICTOC security requirements [I-D.ietf-tictoc-security-requirements].
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| Section | Requirement from I-D tictoc | Requirement | NTS | | Section | Requirement from I-D tictoc | Requirement | NTS |
| | security-requirements-05 | level | | | | security-requirements-05 | level | |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.1.1 | Authentication of Servers | MUST | OK | | 5.1.1 | Authentication of Servers | MUST | OK |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.1.1 | Authorization of Servers | MUST | OK | | 5.1.1 | Authorization of Servers | MUST | OK |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.1.2 | Recursive Authentication of | MUST | OK | | 5.1.2 | Recursive Authentication of | MUST | OK |
| | Servers (Stratum 1) | | | | | Servers (Stratum 1) | | |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.1.2 | Recursive Authorization of | MUST | OK | | 5.1.2 | Recursive Authorization of Servers | MUST | OK |
| | Servers (Stratum 1) | | | | | (Stratum 1) | | |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.1.3 | Authentication and | MAY | - | | 5.1.3 | Authentication and Authorization | MAY | - |
| | Authorization of Slaves | | | | | of Slaves | | |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.2 | Integrity protection. | MUST | OK | | 5.2 | Integrity protection. | MUST | OK |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.3 | Protection against DoS attacks | SHOULD | OK | | 5.3 | Protection against DoS attacks | SHOULD | OK |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.4 | Replay protection | MUST | OK | | 5.4 | Replay protection | MUST | OK |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.5.1 | Key freshness. | MUST | OK | | 5.5.1 | Key freshness. | MUST | OK |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.5.2 | Security association. | SHOULD | OK | | 5.5.2 | Security association. | SHOULD | OK |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.5.3 | Unicast and multicast | SHOULD | OK | | 5.5.3 | Unicast and multicast | SHOULD | OK |
| | associations. | | | | | associations. | | |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| 5.6 | Performance: no degradation in | MUST | OK | | 5.6 | Performance: no degradation in | MUST | OK |
| | quality of time transfer. | | | | | quality of time transfer. | | |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| | Performance: lightweight | SHOULD | OK | | | Performance: lightweight | SHOULD | OK |
| | computation | | | | | computation | | |
+---------+--------------------------------+---------------+--------+ +---------+------------------------------------+-------------+------+
| | Performance: storage, | SHOULD | OK | | | Performance: storage, bandwidth | SHOULD | OK |
| | bandwidth | | | +---------+------------------------------------+-------------+------+
+---------+--------------------------------+---------------+--------+ | 5.7 | Confidentiality protection | MAY | NO |
| 5.7 | Confidentiality protection | MAY | NO | +---------+------------------------------------+-------------+------+
+---------+--------------------------------+---------------+--------+ | 5.8 | Protection against Packet Delay | SHOULD | NA*) |
| 5.8 | Protection against Packet | SHOULD | NA*) | | | and Interception Attacks | | |
| | Delay and Interception Attacks | | | +---------+------------------------------------+-------------+------+
+---------+--------------------------------+---------------+--------+ | 5.9.1 | Secure mode | MUST | - |
| 5.9.1 | Secure mode | MUST | - | +---------+------------------------------------+-------------+------+
+---------+--------------------------------+---------------+--------+ | 5.9.2 | Hybrid mode | MAY | - |
| 5.9.2 | Hybrid mode | MAY | - | +---------+------------------------------------+-------------+------+
+---------+--------------------------------+---------------+--------+
*) Ensured by NTP via multi-source configuration. *) Ensured by NTP via multi-source configuration.
Comparsion of NTS sepecification against TICTOC security Comparsion of NTS sepecification against TICTOC security
requirements. requirements.
Appendix D. Broadcast Mode Appendix D. Broadcast Mode
Authors' Addresses Authors' Addresses
Dieter Sibold Dieter Sibold
Physikalisch-Technische Bundesanstalt Physikalisch-Technische Bundesanstalt
Bundesallee 100 Bundesallee 100
Braunschweig D-38116 Braunschweig D-38116
Germany Germany
Phone: +49-(0)531-592-8420 Phone: +49-(0)531-592-8420
Fax: +49-531-592-698420 Fax: +49-531-592-698420
Email: dieter.sibold@ptb.de Email: dieter.sibold@ptb.de
 End of changes. 25 change blocks. 
90 lines changed or deleted 96 lines changed or added

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