draft-ietf-ntp-using-nts-for-ntp-04.txt   draft-ietf-ntp-using-nts-for-ntp-05.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 29, 2016 Google Inc Expires: September 22, 2016 Google Inc
K. Teichel K. Teichel
PTB PTB
February 26, 2016 March 21, 2016
Using the Network Time Security Specification to Secure the Network Time Using the Network Time Security Specification to Secure the Network Time
Protocol Protocol
draft-ietf-ntp-using-nts-for-ntp-04 draft-ietf-ntp-using-nts-for-ntp-05
Abstract Abstract
This document describes how to use the measures described in the This document describes how to use the measures described in the
Network Time Security (NTS) specification to secure time Network Time Security (NTS) specification to secure time
synchronization with servers using the Network Time Protocol (NTP). synchronization with servers using the Network Time Protocol (NTP).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 41 skipping to change at page 1, line 42
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 29, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 5
5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 5 5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 5
5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 8 5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 8
5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 9 5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 9
5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 10 5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 10
6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 11 6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 11
6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 13 6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Access Messages . . . . . . . . . . . . . . . . . . . 13 6.1.1. Access Messages . . . . . . . . . . . . . . . . . . . 13
6.1.2. Association Messages . . . . . . . . . . . . . . . . 13 6.1.2. Association Messages . . . . . . . . . . . . . . . . 14
6.1.3. Cookie Messages . . . . . . . . . . . . . . . . . . . 14 6.1.3. Cookie Messages . . . . . . . . . . . . . . . . . . . 14
6.1.4. Time Synchronization Messages . . . . . . . . . . . . 14 6.1.4. Time Synchronization Messages . . . . . . . . . . . . 14
6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 15 6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 15
6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 15 6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 15
6.2.2. Broadcast Time Synchronization Message . . . . . . . 15 6.2.2. Broadcast Time Synchronization Message . . . . . . . 15
6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 15 6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. Field Type Registry . . . . . . . . . . . . . . . . . . . 16 7.1. Field Type Registry . . . . . . . . . . . . . . . . . . . 16
7.2. SMI Security for S/MIME CMS Content Type Registry . . . . 16 7.2. SMI Security for S/MIME CMS Content Type Registry . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Employing Alternative Means for Access, Association and 8.1. Employing Alternative Means for Access, Association and
Cookie Exchange . . . . . . . . . . . . . . . . . . . . . 16 Cookie Exchange . . . . . . . . . . . . . . . . . . . . . 17
8.2. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 16 8.2. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 17
8.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 17 8.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 17
8.4. Supported Hash Algorithms . . . . . . . . . . . . . . . . 17 8.4. Supported MAC Algorithms . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 8.5. Protection for Initial Messages . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 18 Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 19
Appendix B. Bit Lengths for Employed Primitives . . . . . . . . 21 Appendix B. Bit Lengths for Employed Primitives . . . . . . . . 22
Appendix C. Error Codes . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Error Codes . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
One of the most popular time synchronization protocols, the Network One of the most popular time synchronization protocols, the Network
Time Protocol (NTP) [RFC5905], currently does not provide adequate Time Protocol (NTP) [RFC5905], currently does not provide adequate
intrinsic security precautions. The Network Time Security draft intrinsic security precautions. The Network Time Security draft
[I-D.ietf-ntp-network-time-security] specifies security measures [I-D.ietf-ntp-network-time-security] specifies security measures
which can be used to enable time synchronization protocols to verify which can be used to enable time synchronization protocols to verify
authenticity of the time server and integrity of the time authenticity of the time server and integrity of the time
synchronization protocol packets. synchronization protocol packets.
skipping to change at page 4, line 5 skipping to change at page 4, line 7
server has arrived without alteration. server has arrived without alteration.
o Modes of operation: Both the unicast and the broadcast mode of NTP o Modes of operation: Both the unicast and the broadcast mode of NTP
are supported. are supported.
o Hybrid mode: Both secure and insecure communication modes are o Hybrid mode: Both secure and insecure communication modes are
possible for both NTP servers and clients. possible for both NTP servers and clients.
o Compatibility: o Compatibility:
* Unsecured NTP associations are not affected. * NTP associations which are not secured by NTS are not affected
by NTS-secured communication.
* An NTP server that does not support NTS is not affected by NTS- * An NTP server that does not support NTS is not affected by NTS-
secured authentication requests. secured authentication requests.
3. Terms and Abbreviations 3. Terms and Abbreviations
CMS Cryptographic Message Syntax [RFC5652] CMS Cryptographic Message Syntax [RFC5652]
HMAC Keyed-Hash Message Authentication Code
MAC Message Authentication Code MAC Message Authentication Code
MITM Man In The Middle MITM Man In The Middle
NTP Network Time Protocol [RFC5905] NTP Network Time Protocol [RFC5905]
NTS Network Time Security NTS Network Time Security
TESLA Timed Efficient Stream Loss-Tolerant Authentication [RFC4082] TESLA Timed Efficient Stream Loss-Tolerant Authentication [RFC4082]
skipping to change at page 6, line 28 skipping to change at page 6, line 28
Step 4: It waits for a reply in the form of a server_assoc message. Step 4: It waits for a reply in the form of a server_assoc message.
After receipt of the message it performs the following checks: After receipt of the message it performs the following checks:
* The client checks that the message contains a conforming * The client checks that the message contains a conforming
version number. version number.
* It checks that the nonce sent back by the server matches the * It checks that the nonce sent back by the server matches the
one transmitted in client_assoc, one transmitted in client_assoc,
* It also verifies that the server has chosen the encryption and * It also verifies that the server has chosen the encryption and
hash algorithms from its proposal sent in the client_assoc MAC algorithms from its proposal sent in the client_assoc
message and that this proposal was not altered. message and that this proposal was not altered.
* Furthermore, it performs authenticity checks on the certificate * Furthermore, it performs authenticity checks on the certificate
chain and the signature. chain and the signature.
If one of the checks fails, the client MUST abort the run. If one of the checks fails, the client MUST abort the run.
Discussion: Note that by performing the above message exchange Discussion: Note that by performing the above message exchange
and checks, the client validates the authenticity of its and checks, the client validates the authenticity of its
immediate NTP server only. It does not recursively validate immediate NTP server only. It does not recursively validate
skipping to change at page 9, line 50 skipping to change at page 9, line 50
5.2.1. The Server in Unicast Mode 5.2.1. The Server in Unicast Mode
To support unicast mode, the server MUST be ready to perform the To support unicast mode, the server MUST be ready to perform the
following actions: following actions:
o Upon receipt of a client_access message, the server constructs and o Upon receipt of a client_access message, the server constructs and
sends a reply in the form of a server_access message as described sends a reply in the form of a server_access message as described
in Appendix B of[I-D.ietf-ntp-network-time-security]. The server in Appendix B of[I-D.ietf-ntp-network-time-security]. The server
MUST construct the access key according to: MUST construct the access key according to:
access_key = MSB _<B_accesskey> (HMAC(server seed; Client's IP access_key = MSB _<B_accesskey> (MAC(server seed; Client's IP
address)). address)).
o Upon receipt of a client_assoc message, the server checks the o Upon receipt of a client_assoc message, the server checks the
included access key. To this end it reconstructs the access key included access key. To this end it reconstructs the access key
and compares it against the received one. If they match, the and compares it against the received one. If they match, the
server constructs and sends a reply in the form of a server_assoc server constructs and sends a reply in the form of a server_assoc
message as described in [I-D.ietf-ntp-network-time-security]. In message as described in [I-D.ietf-ntp-network-time-security]. In
the case where the validity of the included access key can not be the case where the validity of the included access key can not be
verified, the server MUST NOT reply to the received request. verified, the server MUST NOT reply to the received request.
skipping to change at page 10, line 32 skipping to change at page 10, line 32
this value with the MAC in the received data. this value with the MAC in the received data.
* If the re-calculated MAC does not match the MAC in the received * If the re-calculated MAC does not match the MAC in the received
data the server MUST stop the processing of the request. data the server MUST stop the processing of the request.
* If the re-calculated MAC matches the MAC in the received data * If the re-calculated MAC matches the MAC in the received data
the server computes the necessary time synchronization data and the server computes the necessary time synchronization data and
constructs a time_response message as given in constructs a time_response message as given in
[I-D.ietf-ntp-network-time-security]. [I-D.ietf-ntp-network-time-security].
If the time_request message was received in the context of an NTP
peer association, the server MUST look up whether it has information
about the authentication and authorization status for the given hash
value of the client's certificate. If it does not, it MUST NOT use
the NTP message contents for adjusting its own clock.
In addition to items above, the server MAY be ready to perform the In addition to items above, the server MAY be ready to perform the
following action: following action:
o If an external mechanism for association and key exchange is used, o If an external mechanism for association and key exchange is used,
the server has to react accordingly. the server has to react accordingly.
5.2.2. The Server in Broadcast Mode 5.2.2. The Server in Broadcast Mode
A broadcast server MUST also support unicast mode in order to provide A broadcast server MUST also support unicast mode in order to provide
the initial time synchronization, which is a precondition for any the initial time synchronization, which is a precondition for any
skipping to change at page 12, line 22 skipping to change at page 12, line 22
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) | | Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All extension fields mentioned in the rest of this section do not All extension fields mentioned in the rest of this section do not
require an NTP MAC field. If nothing else is explicitly stated, all require an NTP MAC field. If nothing else is explicitly stated, all
of those extension fields MUST have a length of at least 28 octets. of those extension fields MUST have a length of at least 28 octets.
Furthermore, all extension fields mentioned in the rest of this Furthermore, all extension fields mentioned in the rest of this
section are notified by a Field Type identifier signaling content section are notified by one of three Field Type identifiers,
related to NTS (see IANA considerations (Section 7)). signaling content related to NTS:
+------------+------------------------------------------------------+
| Field Type | ASN.1 Object of NTS Message |
+------------+------------------------------------------------------+
| TBD1 | ClientAccessData, ServerAccessData |
| TBD1 | ClientAssocData, ServerAssocData |
| TBD1 | ClientCookieData, ServerCookieData |
| TBD1 | BroadcastParameterRequest, |
| | BroadcastParameterResponse |
| TBD2 | TimeRequestSecurityData, TimeResponseSecurityData |
| TBD2 | BroadcastTime |
| TBD2 | ClientKeyCheckSecurityData, |
| | ServerKeyCheckSecurityData |
| TBD3 | NTSMessageAuthenticationCode |
+------------+------------------------------------------------------+
(see IANA considerations (Section 7)).
The outermost structure of the extension field's Value field MUST be The outermost structure of the extension field's Value field MUST be
an ASN.1 object that is structured as follows: an ASN.1 object that is structured as follows:
NTSExtensionFieldContent := SEQUENCE { NTSExtensionFieldContent := SEQUENCE {
oid OBJECT IDENTIFIER, oid OBJECT IDENTIFIER,
errnum OCTET STRING (SIZE(2)), errnum OCTET STRING (SIZE(2)),
content ANY DEFINED BY oid content ANY DEFINED BY oid
} }
skipping to change at page 13, line 15 skipping to change at page 13, line 32
The MAC-carrying extension field contains an NTSExtensionFieldContent The MAC-carrying extension field contains an NTSExtensionFieldContent
object, whose content field is structured according to NTS-Plain. object, whose content field is structured according to NTS-Plain.
The included NTS message object is as follows: The included NTS message object is as follows:
NTSMessageAuthenticationCode := SEQUENCE { NTSMessageAuthenticationCode := SEQUENCE {
mac OCTET STRING (SIZE(16)) mac OCTET STRING (SIZE(16))
} }
It is identified by the following object identifier: It is identified by the following object identifier:
id-ct-nts-ntsForNtpMessageAuthenticationCode OBJECT IDENTIFIER id-ct-nts-ntsForNtpMessageAuthenticationCode OBJECT IDENTIFIER ::= TBD4
::= TBD2
Note: In the following sections the word MAC is always used as Note: In the following sections the word MAC is always used as
described above. In particular it is not to be confused with described above. In particular it is not to be confused with
NTP's MAC field. NTP's MAC field.
6.1. Unicast Messages 6.1. Unicast Messages
6.1.1. Access Messages 6.1.1. Access Messages
6.1.1.1. Message Type: "client_access" 6.1.1.1. Message Type: "client_access"
skipping to change at page 16, line 16 skipping to change at page 16, line 32
Note: In this message, the first extension field (the one not Note: In this message, the first extension field (the one not
containing the MAC) only needs to have a length of at least 16 containing the MAC) only needs to have a length of at least 16
octets. The extension field holding the MACs needs to have the octets. The extension field holding the MACs needs to have the
usual length of at least 28 octets. usual length of at least 28 octets.
7. IANA Considerations 7. IANA Considerations
7.1. Field Type Registry 7.1. Field Type Registry
Within the "NTP Extensions Field Types" registry table, add one field Within the "NTP Extensions Field Types" registry table, add the field
type: types:
Field Type Meaning References Field Type Meaning References
---------- ------------------------------------ ---------- ---------- ------------------------------------ ----------
TBD1 NTS-Related Content [this doc] TBD1 NTS-Related Content [this doc]
TBD2 NTS-Related Content [this doc]
TBD3 NTS-Related Content [this doc]
7.2. SMI Security for S/MIME CMS Content Type Registry 7.2. SMI Security for S/MIME CMS Content Type Registry
Within the "SMI Security for S/MIME CMS Content Type Within the "SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1)" table, add one content type identifier: (1.2.840.113549.1.9.16.1)" table, add one content type identifier:
Decimal Description References Decimal Description References
------- -------------------------------------------- ---------- ------- -------------------------------------------- ----------
TBD2 id-ct-nts-ntsForNtpMessageAuthenticationCode [this doc] TBD4 id-ct-nts-ntsForNtpMessageAuthenticationCode [this doc]
8. Security Considerations 8. Security Considerations
All security considerations described in All security considerations described in
[I-D.ietf-ntp-network-time-security] have to be taken into account. [I-D.ietf-ntp-network-time-security] have to be taken into account.
The application of NTS to NTP requires the following additional The application of NTS to NTP requires the following additional
considerations. considerations.
8.1. Employing Alternative Means for Access, Association and Cookie 8.1. Employing Alternative Means for Access, Association and Cookie
Exchange Exchange
skipping to change at page 17, line 11 skipping to change at page 17, line 32
[I-D.ietf-ntp-network-time-security] is not applicable to the concept [I-D.ietf-ntp-network-time-security] is not applicable to the concept
of NTP pools. Therefore, NTS is unable to provide secure usage of of NTP pools. Therefore, NTS is unable to provide secure usage of
NTP pools. NTP pools.
8.3. Server Seed Lifetime 8.3. Server Seed Lifetime
According to Clause 5.6.1 in RFC 7384 [RFC7384] the server MUST According to Clause 5.6.1 in RFC 7384 [RFC7384] the server MUST
provide a means to refresh the value of its server seed from time to provide a means to refresh the value of its server seed from time to
time. A generally valid value for the server seed lifetime cannot be time. A generally valid value for the server seed lifetime cannot be
given. The value depends on the required security level, the current given. The value depends on the required security level, the current
threat situation, and the chosen hash mechanisms. threat situation, and the chosen MAC mechanisms.
As guidance, a value for the lifetime can be determined by As guidance, a value for the lifetime can be determined by
stipulating a maximum number of time requests for which the exchanged stipulating a maximum number of time requests for which the exchanged
cookie remains unchanged. For example, if this value is 1000 and the cookie remains unchanged. For example, if this value is 1000 and the
client sends a time request every 64 seconds, the server seed client sends a time request every 64 seconds, the server seed
lifetime should be no longer than 64000 seconds. Corresponding lifetime should be no longer than 64000 seconds. Corresponding
considerations can be made for a minimum number of requests. considerations can be made for a minimum number of requests.
8.4. Supported Hash Algorithms 8.4. Supported MAC Algorithms
The list of the hash algorithms supported by the server has to The list of the MAC algorithms supported by the server has to fulfill
fulfill the following requirements: the following requirements:
o it MUST NOT include SHA-1 or weaker algorithms, o it MUST NOT include HMAC with SHA-1 or weaker algorithms,
o it MUST include SHA-256 or stronger algorithms. o it MUST include HMAC with SHA-256 or stronger algorithms.
8.5. Protection for Initial Messages
Any NTS message providing access, association, or cookie exchange can
be encapsulated in NTP an extension field which is piggybacked onto
an NTP packet. NTS does not itself provide MAC protection to the NTP
header of such a packet, because it only offers MAC protection to the
NTP header once the cookie has been successfully exchanged.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Russ Housley, Steven Bellovin, David The authors would like to thank Russ Housley, Steven Bellovin, David
Mills and Kurt Roeckx for discussions and comments on the design of Mills and Kurt Roeckx for discussions and comments on the design of
NTS. Also, thanks to Harlan Stenn, Danny Mayer, Richard Welty and NTS. Also, thanks to Harlan Stenn, Danny Mayer, Richard Welty and
Martin Langer for their technical review and specific text Martin Langer for their technical review and specific text
contributions to this document. contributions to this document.
10. References 10. References
 End of changes. 25 change blocks. 
37 lines changed or deleted 69 lines changed or added

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