draft-ietf-ntp-using-nts-for-ntp-01.txt   draft-ietf-ntp-using-nts-for-ntp-02.txt 
NTP Working Group D. Sibold NTP Working Group D. Sibold
Internet-Draft PTB Internet-Draft PTB
Intended status: Standards Track S. Roettger Intended status: Standards Track S. Roettger
Expires: January 7, 2016 Google Inc Expires: April 7, 2016 Google Inc
K. Teichel K. Teichel
PTB PTB
July 06, 2015 October 05, 2015
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-01 draft-ietf-ntp-using-nts-for-ntp-02
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 42 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 January 7, 2016. This Internet-Draft will expire on April 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 9, line 43 skipping to change at page 9, line 43
the cookie, then computes the necessary time synchronization data the cookie, then computes the necessary time synchronization data
and constructs a time_response message as given in and constructs a time_response message as given in
[I-D.ietf-ntp-network-time-security]. [I-D.ietf-ntp-network-time-security].
The server MUST refresh its server seed periodically (see The server MUST refresh its server seed periodically (see
[I-D.ietf-ntp-network-time-security]). [I-D.ietf-ntp-network-time-security]).
In addition to the server MAY be ready to perform the following In addition to the server MAY be ready to perform the following
action: 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
broadcast association. To support NTS broadcast, the server MUST broadcast association. To support NTS broadcast, the server MUST
additionally be ready to perform the following actions: additionally be ready to perform the following actions:
o Upon receipt of a client_bpar message, the server constructs and o Upon receipt of a client_bpar message, the server constructs and
skipping to change at page 10, line 41 skipping to change at page 10, line 41
6. Implementation Notes: ASN.1 Structures and Use of the CMS 6. Implementation Notes: ASN.1 Structures and Use of the CMS
This section presents some hints about the structures of the This section presents some hints about the structures of the
communication packets for the different message types when one wishes communication packets for the different message types when one wishes
to implement NTS for NTP. See document to implement NTS for NTP. See document
[I-D.ietf-ntp-cms-for-nts-message] for descriptions of the archetypes [I-D.ietf-ntp-cms-for-nts-message] for descriptions of the archetypes
for CMS structures as well as for the ASN.1 structures that are for CMS structures as well as for the ASN.1 structures that are
referenced here. referenced here.
All extension fields mentioned in the following list are notified by
a field type value signalling content related to NTS version 1.0.
6.1. Unicast Messages 6.1. Unicast Messages
6.1.1. Association Messages 6.1.1. Association Messages
6.1.1.1. Message Type: "client_assoc" 6.1.1.1. Message Type: "client_assoc"
This message is realized as an NTP packet with an extension field This message is realized as an NTP packet with an extension field
which holds an "NTS-Plain" archetype structure. This structure which holds an "NTS-Plain" archetype structure. This structure
consists only of an NTS message object of the type consists only of an NTS message object of the type "ClientAssocData",
"ClientAssociationData", which holds all the data necessary for the which holds all the data necessary for the NTS security mechanisms.
NTS security mechanisms.
6.1.1.2. Message Type: "server_assoc" 6.1.1.2. Message Type: "server_assoc"
Like "client_assoc", this message is realized as an NTP packet with Like "client_assoc", this message is realized as an NTP packet with
an extension field which holds an "NTS-Plain" archetype structure, an extension field which holds an "NTS-Plain" archetype structure,
i.e. just an NTS message object of the type "ServerAssociationData". i.e. just an NTS message object of the type "ServerAssocData". The
The latter holds all the data necessary for NTS. latter holds all the data necessary for NTS.
6.1.2. Cookie Messages 6.1.2. Cookie Messages
6.1.2.1. Message Type: "client_cook" 6.1.2.1. Message Type: "client_cook"
This message type is realized as an NTP packet with an extension This message type is realized as an NTP packet with an extension
field which holds a CMS structure of archetype "NTS-Certified", field which holds a CMS structure of archetype "NTS-Certified",
containing in its core an NTS message object of the type containing in its core an NTS message object of the type
"ClientCookieData". The latter holds all the data necessary for the "ClientCookieData". The latter holds all the data necessary for the
NTS security mechanisms. NTS security mechanisms.
skipping to change at page 11, line 46 skipping to change at page 11, line 48
packet from a client to a server would. Furthermore, the packet has packet from a client to a server would. Furthermore, the packet has
an extension field which contains an ASN.1 object of type an extension field which contains an ASN.1 object of type
"TimeRequestSecurityData" (packed in a CMS structure of archetype "TimeRequestSecurityData" (packed in a CMS structure of archetype
"NTS-Plain"). "NTS-Plain").
6.1.3.2. Message Type: "time_response" 6.1.3.2. Message Type: "time_response"
This message is also realized as an NTP packet with regular NTP time This message is also realized as an NTP packet with regular NTP time
synchronization data. The packet also has an extension field which synchronization data. The packet also has an extension field which
contains an ASN.1 object of type "TimeResponseSecurityData". contains an ASN.1 object of type "TimeResponseSecurityData".
Finally, this NTP packet has a MAC field which contains a Message Finally, this NTP packet has another extension field which contains a
Authentication Code generated over the whole packet (including the Message Authentication Code generated over the whole packet
extension field). (including the extension field).
6.2. Broadcast Messages 6.2. Broadcast Messages
6.2.1. Broadcast Parameter Messages 6.2.1. Broadcast Parameter Messages
6.2.1.1. Message Type: "client_bpar" 6.2.1.1. Message Type: "client_bpar"
This first broadcast message is realized as an NTP packet which is This first broadcast message is realized as an NTP packet which is
empty except for an extension field which contains an ASN.1 object of empty except for an extension field which contains an ASN.1 object of
type "BroadcastParameterRequest" (packed in a CMS structure of type "BroadcastParameterRequest" (packed in a CMS structure of
skipping to change at page 12, line 32 skipping to change at page 12, line 32
"BroadcastParameterResponse". "BroadcastParameterResponse".
6.2.2. Broadcast Time Synchronization Message 6.2.2. Broadcast Time Synchronization Message
6.2.2.1. Message Type: "server_broad" 6.2.2.1. Message Type: "server_broad"
This message's realization works via an NTP packet which carries This message's realization works via an NTP packet which carries
regular NTP broadcast time data as well as an extension field, which regular NTP broadcast time data as well as an extension field, which
contains an ASN.1 object of type "BroadcastTime" (packed in a CMS contains an ASN.1 object of type "BroadcastTime" (packed in a CMS
structure with archetype "NTS-Plain"). In addition to all this, this structure with archetype "NTS-Plain"). In addition to all this, this
packet has a MAC field which contains a Message Authentication Code packet has another extension field which contains a Message
generated over the whole packet (including the extension field). Authentication Code generated over the whole packet (including the
extension field).
6.2.3. Broadcast Keycheck 6.2.3. Broadcast Keycheck
6.2.3.1. Message Type: "client_keycheck" 6.2.3.1. Message Type: "client_keycheck"
This message is realized as an NTP packet with an extension field, This message is realized as an NTP packet with an extension field,
which transports a CMS structure of archetype "NTS-Plain", containing which transports a CMS structure of archetype "NTS-Plain", containing
an ASN.1 object of type "ClientKeyCheckSecurityData". an ASN.1 object of type "ClientKeyCheckSecurityData".
6.2.3.2. Message Type: "server_keycheck" 6.2.3.2. Message Type: "server_keycheck"
This message is also realized as an NTP packet with an extension This message is also realized as an NTP packet with an extension
field, which contains an ASN.1 object of type field, which contains an ASN.1 object of type
"ServerKeyCheckSecurityData" (packed in a CMS structure of archetype "ServerKeyCheckSecurityData" (packed in a CMS structure of archetype
"NTS-Plain"). Additionally, this NTP packet has a MAC field which "NTS-Plain"). Additionally, this NTP packet has another extension
contains a Message Authentication Code generated over the whole field which contains a Message Authentication Code generated over the
packet (including the extension field). whole packet (including the extension field).
7. Security Considerations 7. Security Considerations
7.1. Employing Alternative Means for Association and Cookie Exchange 7.1. Employing Alternative Means for Association and Cookie Exchange
If an implementation uses alternative means to perform association If an implementation uses alternative means to perform association
and cookie exchange, it MUST make sure that an adversary cannot abuse and cookie exchange, it MUST make sure that an adversary cannot abuse
the server to obtain a cookie belonging to a chosen KIV. the server to obtain a cookie belonging to a chosen KIV.
7.2. Usage of NTP Pools 7.2. Usage of NTP Pools
skipping to change at page 13, line 45 skipping to change at page 13, line 45
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 for his technical review and NTS. Also, thanks to Harlan Stenn for his technical review and
specific text contributions to this document. specific text contributions to this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005. Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,
June 2005, <http://www.rfc-editor.org/info/rfc4082>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009. RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-ntp-cms-for-nts-message] [I-D.ietf-ntp-cms-for-nts-message]
Sibold, D., Teichel, K., Roettger, S., and R. Housley, Sibold, D., Teichel, K., Roettger, S., and R. Housley,
"Protecting Network Time Security Messages with the "Protecting Network Time Security Messages with the
Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms-
for-nts-message-03 (work in progress), April 2015. for-nts-message-04 (work in progress), July 2015.
[I-D.ietf-ntp-network-time-security] [I-D.ietf-ntp-network-time-security]
Sibold, D., Roettger, S., and K. Teichel, "Network Time Sibold, D., Roettger, S., and K. Teichel, "Network Time
Security", draft-ietf-ntp-network-time-security-08 (work Security", draft-ietf-ntp-network-time-security-09 (work
in progress), March 2015. in progress), July 2015.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, October 2014. Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>.
Appendix A. Flow Diagrams of Client Behaviour Appendix A. Flow Diagrams of Client Behaviour
+---------------------+ +---------------------+
|Association Messages | |Association Messages |
+----------+----------+ +----------+----------+
| |
+------------------------------>o +------------------------------>o
| | | |
| v | v
| +---------------+ | +---------------+
 End of changes. 18 change blocks. 
28 lines changed or deleted 37 lines changed or added

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