< draft-ietf-ntp-cms-for-nts-message-04.txt   draft-ietf-ntp-cms-for-nts-message-05.txt >
NTP Working Group D. Sibold NTP Working Group D. Sibold
Internet-Draft K. Teichel Internet-Draft K. Teichel
Intended status: Standards Track PTB Intended status: Standards Track PTB
Expires: January 7, 2016 S. Roettger Expires: July 29, 2016 S. Roettger
Google Inc. Google Inc.
R. Housley R. Housley
Vigil Security Vigil Security
July 06, 2015 January 26, 2016
Protecting Network Time Security Messages with the Cryptographic Message Protecting Network Time Security Messages with the Cryptographic Message
Syntax (CMS) Syntax (CMS)
draft-ietf-ntp-cms-for-nts-message-04 draft-ietf-ntp-cms-for-nts-message-05
Abstract Abstract
This document describes a convention for using the Cryptographic This document describes a convention for using the Cryptographic
Message Syntax (CMS) to protect the messages in the Network Time Message Syntax (CMS) to protect the messages in the Network Time
Security (NTS) protocol. NTS provides authentication of time servers Security (NTS) protocol. NTS provides authentication of time servers
as well as integrity protection of time synchronization messages as well as integrity protection of time synchronization messages
using Network Time Protocol (NTP) or Precision Time Protocol (PTP). using Network Time Protocol (NTP) or Precision Time Protocol (PTP).
Requirements Language Requirements Language
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 July 29, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. CMS Conventions for NTS Message Protection . . . . . . . . . 3 2. CMS Conventions for NTS Message Protection . . . . . . . . . 3
2.1. Fields of the employed CMS Content Types . . . . . . . . 5 2.1. Fields of the employed CMS Content Types . . . . . . . . 5
2.1.1. ContentInfo . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. ContentInfo . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. SignedData . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. SignedData . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. EnvelopedData . . . . . . . . . . . . . . . . . . . . 8 2.1.3. EnvelopedData . . . . . . . . . . . . . . . . . . . . 8
3. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9 3. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9
3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9 3.2. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Association Messages . . . . . . . . . . . . . . . . 9 3.2.1. Association Messages . . . . . . . . . . . . . . . . 9
3.2.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10 3.2.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10
3.2.3. Time Synchronization Messages . . . . . . . . . . . . 11 3.2.3. Time Synchronization Messages . . . . . . . . . . . . 11
3.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12 3.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12
3.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 12 3.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 12
3.3.2. Broadcast Time Synchronization Message . . . . . . . 13 3.3.2. Broadcast Time Synchronization Message . . . . . . . 13
3.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 14 3.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 14
4. Certificate Conventions . . . . . . . . . . . . . . . . . . . 14 4. Certificate Conventions . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5.1. SMI Security for S/MIME Module Identifier Registry . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. SMI Security for S/MIME CMS Content Type Registry . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 5.3. SMI Security for PKIX Extended Key Purpose Registry . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document provides details on how to construct NTS messages in This document provides details on how to construct NTS messages in
practice. NTS provides secure time synchronization with time servers practice. NTS provides secure time synchronization with time servers
using Network Time Protocol (NTP) [RFC5905] or Precision Time using Network Time Protocol (NTP) [RFC5905] or Precision Time
Protocol (PTP) [IEEE1588]. Among other things, this document Protocol (PTP) [IEEE1588]. Among other things, this document
describes a convention for using the Cryptographic Message Syntax describes a convention for using the Cryptographic Message Syntax
(CMS) [RFC5652] to protect messages in the Network Time Security (CMS) [RFC5652] to protect messages in the Network Time Security
(NTS) protocol. Encryption is used to provide confidentiality of (NTS) protocol. Encryption is used to provide confidentiality of
secrets, and digital signatures are used to provide authentication secrets, and digital signatures are used to provide authentication
and integrity of content. and integrity of content.
Sometimes CMS is used in an exclusively ASN.1 [ASN1] environment. In Sometimes CMS is used in an exclusively ASN.1 [ASN1] environment. In
this case, the NTS message may use any syntax that facilitates easy this case, the NTS message may use any syntax that facilitates easy
implementation. implementation.
2. CMS Conventions for NTS Message Protection 2. CMS Conventions for NTS Message Protection
Regarding the usage of CMS, we differentiate between four archetypes Regarding the usage of CMS, we differentiate between three archetypes
according to which the NTS message types can be structured. They are according to which the NTS message types can be structured. They are
presented below. Note that the NTS Message Object that is at the presented below. Note that the NTS Message Object that is at the
core of each structure does not necessarily contain all the data core of each structure does not necessarily contain all the data
needed for the particular message type, but may contain only that needed for the particular message type, but may contain only that
data which needs to be secured directly with cryptographic operations data which needs to be secured directly with cryptographic operations
using the CMS. Specific information about what is included can be using the CMS. Specific information about what is included can be
found in Section 3. found in Section 3.
NTS-Plain: This archetype is used for actual time synchronization NTS-Plain: This archetype is used for actual time synchronization
messages (explicitly, the following message types: time_request, messages (explicitly, the following message types: time_request,
time_response, server_broad, see time_response, server_broad, see
[I-D.ietf-ntp-network-time-security], Section 6) as well as for [I-D.ietf-ntp-network-time-security], Section 6) as well as for
the very first messages of a unicast or a broadcast exchange client-side messages of all unicast and broadcast bootstrapping
(client_assoc or client_bpar, respectively) and the broadcast exchanges (explicitly client_assoc, client_cook and client_bpar)
keycheck exchange (client_keycheck and server_keycheck). This as well as the broadcast keycheck exchange (client_keycheck and
archetype does not make use of any CMS structures at all. server_keycheck). This archetype does not make use of any CMS
Figure 1 illustrates this structure. structures at all. Figure 1 illustrates this structure.
+-----------------------------------------------------+ +-----------------------------------------------------+
| | | |
| NTS Message Object | | NTS Message Object |
| | | |
| | | |
+-----------------------------------------------------+ +-----------------------------------------------------+
NTS-Encrypted-and-Signed: This archetype is used for secure NTS-Encrypted-and-Signed: This archetype is used for secure
transmission of the cookie (only for the server_cook message type, transmission of the cookie (only for the server_cook message type,
skipping to change at page 5, line 29 skipping to change at page 5, line 38
| | | | | | | | | | | |
| | | NTS Message Object | | | | | | NTS Message Object | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | +-------------------------------------------------+ | | | | +-------------------------------------------------+ | |
| | | | | | | |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| | | |
+---------------------------------------------------------+ +---------------------------------------------------------+
NTS-Certified: This archetype is used for the client_cook message
type. It uses a CMS structure much like the NTS-Signed archetype
(see Figure 3), with the only difference being that messages
SHOULD NOT be digitally signed. This archetype employs the CMS
structure merely in order to transport certificates.
2.1. Fields of the employed CMS Content Types 2.1. Fields of the employed CMS Content Types
Overall, three CMS content types are used for NTS messages by the Overall, three CMS content types are used for NTS messages by the
archetypes above. Explicitly, those content types are ContentInfo, archetypes above. Explicitly, those content types are ContentInfo,
SignedData and EnvelopedData. The following is a description of how SignedData and EnvelopedData. The following is a description of how
the fields of those content types are used in detail. the fields of those content types are used in detail.
2.1.1. ContentInfo 2.1.1. ContentInfo
The ContentInfo content type is used in all archetypes except NTS- The ContentInfo content type is used in all archetypes except NTS-
Plain. The fields of the ContentInfo content type are used as Plain. The fields of the ContentInfo content type are used as
follows: follows:
contentType -- indicates the type of the associated content. For contentType -- indicates the type of the associated content. For
all archetypes which use ContentInfo (these are NTS-Certified, all archetypes which use ContentInfo (these are NTS-Signed and
NTS-Signed and NTS-Encrypted-and-Signed), it MUST contain the NTS-Encrypted-and-Signed), it MUST contain the object identifier
object identifier for the SignedData content type: for the SignedData content type:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
content -- is the associated content. For all archetypes using content -- is the associated content. For all archetypes using
ContentInfo, it MUST contain the DER encoded SignedData content ContentInfo, it MUST contain the DER encoded SignedData content
type. type.
2.1.2. SignedData 2.1.2. SignedData
The SignedData content type is used in the NTS-Certified, NTS-Signed The SignedData content type is used in the NTS-Signed and NTS-
and NTS-Encrypted-and-Signed archetypes, but not in the NTS-Plain Encrypted-and-Signed archetypes, but not in the NTS-Plain archetype.
archetype. The fields of the SignedData content type are used as The fields of the SignedData content type are used as follows:
follows:
version -- the appropriate value depends on the optional items version -- the appropriate value depends on the optional items
that are included. In the NTS protocol, the signer certificate that are included. In the NTS protocol, the signer certificate
MUST be included and other items MAY be included. The MUST be included and other items MAY be included. The
instructions in [RFC5652] Section 5.1 MUST be followed to set the instructions in [RFC5652] Section 5.1 MUST be followed to set the
correct value. correct value.
digestAlgorithms -- is a collection of message digest algorithm digestAlgorithms -- is a collection of message digest algorithm
identifiers. In the NTS protocol, there MUST be exactly one identifiers. In the NTS protocol, there MUST be exactly one
algorithm identifier present. The instructions in Section 5.4 of algorithm identifier present. The instructions in Section 5.4 of
[RFC5652] MUST be followed. [RFC5652] MUST be followed.
encapContentInfo -- this structure is always present. In the NTS encapContentInfo -- this structure is always present. In the NTS
protocol, it MUST follow these conventions: protocol, it MUST follow these conventions:
eContentType -- is an object identifier. In the NTS protocol, eContentType -- is an object identifier. In the NTS protocol,
for the NTS-Certified and NTS-Signed archetypes, it MUST for the NTS-Signed archetype, it MUST identify the type of the
identify the type of the NTS message that was encapsulated. NTS message that was encapsulated. For the NTS-Encrypted-and-
For the NTS-Encrypted-and-Signed archetype, it MUST contain the Signed archetype, it MUST contain the object identifier for the
object identifier for the EnvelopedData content type: EnvelopedData content type:
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }. us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }.
eContent is the content itself, carried as an octet string. eContent is the content itself, carried as an octet string.
For the NTS-Certified and NTS-Signed archetypes, it MUST For the NTS-Signed archetype, it MUST contain the DER encoded
contain the DER encoded encapsulated NTS message object. The encapsulated NTS message object. The instructions in
instructions in Section 6.3 of [RFC5652] MUST be followed. For Section 6.3 of [RFC5652] MUST be followed. For the NTS-
the NTS-Encrypted-and-Signed archetype, it MUST contain the DER Encrypted-and-Signed archetype, it MUST contain the DER encoded
encoded EnvelopedData content type. EnvelopedData content type.
certificates -- is a collection of certificates. In the NTS certificates -- is a collection of certificates. In the NTS
protocol, it MUST contain the DER encoded certificate [RFC5280] of protocol, it MUST contain the DER encoded certificate [RFC5280] of
the sender. It is intended that the collection of certificates be the sender. It is intended that the collection of certificates be
sufficient for the recipient to construct a certification path sufficient for the recipient to construct a certification path
from a recognized "root" or "top-level certification authority" to from a recognized "root" or "top-level certification authority" to
the certificate used by the sender. the certificate used by the sender.
crls -- is a collection of revocation status information. In the crls -- is a collection of revocation status information. In the
NTS protocol, it MAY contain one or more DER encoded CRLs NTS protocol, it MAY contain one or more DER encoded CRLs
[RFC5280]. It is intended that the collection contain information [RFC5280]. It is intended that the collection contain information
sufficient to determine whether the certificates in the sufficient to determine whether the certificates in the
certificates field are valid. certificates field are valid.
signerInfos -- is a collection of per-signer information. In the signerInfos -- is a collection of per-signer information. In the
NTS protocol, for the NTS-Certified archetype, this SHOULD be left NTS protocol, for the NTS-Signed and the NTS-Encrypted-and-Signed
out. For both the NTS-Signed and the NTS-Encrypted-and-Signed
archetypes, there MUST be exactly one SignerInfo structure archetypes, there MUST be exactly one SignerInfo structure
present. The details of the SignerInfo type are discussed in present. The details of the SignerInfo type are discussed in
Section 5.3 of [RFC5652]. In the NTS protocol, it MUST follow Section 5.3 of [RFC5652]. In the NTS protocol, it MUST follow
these conventions: these conventions:
version -- is the syntax version number. In the NTS protocol, version -- is the syntax version number. In the NTS protocol,
the SignerIdentifier is subjectKeyIdentifier, therefore the the SignerIdentifier is subjectKeyIdentifier, therefore the
version MUST be 3. version MUST be 3.
sid -- identifies the signer's certificate. In the NTS sid -- identifies the signer's certificate. In the NTS
skipping to change at page 9, line 13 skipping to change at page 9, line 13
protocol, it MUST be absent. protocol, it MUST be absent.
3. Implementation Notes: ASN.1 Structures and Use of the CMS 3. Implementation Notes: ASN.1 Structures and Use of the CMS
This section presents some hints about the structures of the NTS This section presents some hints about the structures of the NTS
message objects for the different message types when one wishes to message objects for the different message types when one wishes to
implement the security mechanisms. implement the security mechanisms.
3.1. Preliminaries 3.1. Preliminaries
The following ASN.1 coded data type "NTSNonce" is needed for other The following ASN.1 coded data types "NTSNonce" and "NTSVersion" are
types used below for NTS messages. It specifies a 128 bit nonce as needed for other types used below for NTS messages. "NTSNonce"
required in several message types: specifies a 128 bit nonce as required in several message types:
NTSNonce ::= OCTET STRING (SIZE(16)) NTSNonce ::= OCTET STRING (SIZE(16))
"NTSVersion" specifies a version number, which is required for
version negotiation.
NTSVersion ::= INTEGER (0..255)
The following ASN.1 coded data types are also necessary for other The following ASN.1 coded data types are also necessary for other
types. types.
KeyEncryptionAlgorithmIdentifiers ::= KeyEncryptionAlgorithmIdentifiers ::=
SET OF KeyEncryptionAlgorithmIdentifier SET OF KeyEncryptionAlgorithmIdentifier
ContentEncryptionAlgorithmIdentifiers ::= ContentEncryptionAlgorithmIdentifiers ::=
SET OF ContentEncryptionAlgorithmIdentifier SET OF ContentEncryptionAlgorithmIdentifier
3.2. Unicast Messages 3.2. Unicast Messages
skipping to change at page 9, line 41 skipping to change at page 9, line 46
3.2.1.1. Message Type: "client_assoc" 3.2.1.1. Message Type: "client_assoc"
This message is structured according to the NTS-Plain archetype. This message is structured according to the NTS-Plain archetype.
There is no data necessary besides that which is transported in the There is no data necessary besides that which is transported in the
NTS message object, which is an ASN.1 object of type NTS message object, which is an ASN.1 object of type
"ClientAssocData" and structured as follows: "ClientAssocData" and structured as follows:
ClientAssocData ::= SEQUENCE { ClientAssocData ::= SEQUENCE {
nonce NTSNonce, nonce NTSNonce,
minVersion NTSVersion,
clientId SubjectKeyIdentifier, clientId SubjectKeyIdentifier,
digestAlgos DigestAlgorithmIdentifiers, hmacHashAlgos DigestAlgorithmIdentifiers,
keyEncAlgos KeyEncryptionAlgorithmIdentifiers, keyEncAlgos KeyEncryptionAlgorithmIdentifiers,
contentEncAlgos ContentEncryptionAlgorithmIdentifiers contentEncAlgos ContentEncryptionAlgorithmIdentifiers
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-clientAssocData OBJECT IDENTIFIER ::= id-ct-nts-clientAssoc OBJECT IDENTIFIER ::= TBD1
{nts(TBD) association(1) clientassocdata(1)}
3.2.1.2. Message Type: "server_assoc" 3.2.1.2. Message Type: "server_assoc"
This message is structured according to the NTS-Signed archetype. This message is structured according to the NTS-Signed archetype. It
There is no data necessary besides that which is transported in the requires additional data besides that which is transported in the NTS
NTS message object, which is an ASN.1 object of type message object, namely the signature and certificate chain are
"ServerAssocData" and structured as follows: included in the appropriate fields of the "SignedData" CMS structure
that the NTS message object is wrapped in. The NTS message object
itself is an ASN.1 object of type "ServerAssocData" and structured as
follows:
ServerAssocData ::= SEQUENCE { ServerAssocData ::= SEQUENCE {
nonce NTSNonce, nonce NTSNonce,
proposedVersion NTSVersion,
clientId SubjectKeyIdentifier, clientId SubjectKeyIdentifier,
digestAlgos DigestAlgorithmIdentifiers, hmacHashAlgos DigestAlgorithmIdentifiers,
choiceDigestAlgo DigestAlgorithmIdentifier, choiceHmacHashAlgo DigestAlgorithmIdentifier,
keyEncAlgos KeyEncryptionAlgorithmIdentifiers, keyEncAlgos KeyEncryptionAlgorithmIdentifiers,
choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier,
contentEncAlgos ContentEncryptionAlgorithmIdentifiers contentEncAlgos ContentEncryptionAlgorithmIdentifiers,
choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-serverAssocData OBJECT IDENTIFIER ::= id-ct-nts-serverAssoc OBJECT IDENTIFIER ::= TBD2
{nts(TBD) association(1) serverassocdata(2)}
3.2.2. Cookie Messages 3.2.2. Cookie Messages
3.2.2.1. Message Type: "client_cook" 3.2.2.1. Message Type: "client_cook"
This message is structured according to the NTS-Certified archetype. This message is structured according to the NTS-Plain archetype. It
There is no data necessary besides that which is transported in the requires no additional data besides that which is transported in the
NTS message object, which is an ASN.1 object of type NTS message object. The NTS message object itself is an ASN.1 object
"ClientCookieData" and structured as follows: of type "ClientCookieData" and structured as follows:
ClientCookieData ::= SEQUENCE { ClientCookieData ::= SEQUENCE {
nonce NTSNonce, nonce NTSNonce,
signAlgo SignatureAlgorithmIdentifier, signAlgo SignatureAlgorithmIdentifier,
digestAlgo DigestAlgorithmIdentifier, hmacHashAlgo DigestAlgorithmIdentifier,
encAlgo ContentEncryptionAlgorithmIdentifier, encAlgo ContentEncryptionAlgorithmIdentifier,
keyEncAlgo KeyEncryptionAlgorithmIdentifier keyEncAlgo KeyEncryptionAlgorithmIdentifier,
certificates CertificateSet
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-clientCookieData OBJECT IDENTIFIER ::= id-ct-nts-clientCookie OBJECT IDENTIFIER ::= TBD3
{nts(TBD) association(1) clientcookiedata(3)}
3.2.2.2. Message Type: "server_cook" 3.2.2.2. Message Type: "server_cook"
This message is structured according to the "NTS-Encrypted-and- This message is structured according to the "NTS-Encrypted-and-
Signed" archetype. There is no data necessary besides that which is Signed" archetype. It requires additional data besides that which is
transported in the NTS message object, which is an ASN.1 object of transported in the NTS message object, namely the signature is
type "ServerCookieData" and structured as follows: included in the appropriate field of the "SignedData" CMS structure
that the NTS message object is wrapped in. The NTS message object
itself is an ASN.1 sequence of type "ServerCookieData" and structured
as follows:
ServerCookieData ::= SEQUENCE { ServerCookieData ::= SEQUENCE {
nonce NTSNonce, nonce NTSNonce,
cookie OCTET STRING (SIZE(16)) cookie OCTET STRING (SIZE(16))
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-serverCookieData OBJECT IDENTIFIER ::= id-ct-nts-serverCookie OBJECT IDENTIFIER ::= TBD4
{nts(TBD) association(3) servercookiedata(4)}
3.2.3. Time Synchronization Messages 3.2.3. Time Synchronization Messages
3.2.3.1. Message Type: "time_request" 3.2.3.1. Message Type: "time_request"
This message is structured according to the "NTS-Plain" archetype. This message is structured according to the "NTS-Plain" archetype.
This message type requires additional data to that which is included This message type requires additional data to that which is included
in the NTS message object, namely it requires regular time in the NTS message object, namely it requires regular time
synchronization data, as an unsecured packet from a client to a synchronization data, as an unsecured packet from a client to a
server would contain. The NTS message object itself is an ASN.1 server would contain. Optionally, it requires the Message
object of type "TimeRequestSecurityData", whose structure is as Authentication Code (MAC) to be generated over the whole rest of the
follows: packet (including the NTS message object) and transported in some
way. The NTS message object itself is an ASN.1 object of type
"TimeRequestSecurityData", whose structure is as follows:
TimeRequestSecurityData ::= TimeRequestSecurityData ::=
SEQUENCE { SEQUENCE {
nonce_t NTSNonce, nonce NTSNonce,
digestAlgo DigestAlgorithmIdentifier, hmacHashAlgo DigestAlgorithmIdentifier,
keyInputValue OCTET STRING (SIZE(16)) keyInputValue OCTET STRING (SIZE(16))
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-timeRequestSecurityData OBJECT IDENTIFIER ::= id-ct-nts-securityDataReq OBJECT IDENTIFIER ::= TBD5
{nts(TBD) time(2) timerequestsecuritydata(1)}
3.2.3.2. Message Type: "time_response" 3.2.3.2. Message Type: "time_response"
This message is also structured according to "NTS-Plain". This message is structured according to the "NTS-Plain" archetype.
It requires two items of data in addition to that which is It requires two items of data in addition to that which is
transported in the NTS message object. Like "time_request", it transported in the NTS message object. Like "time_request", it
requires regular time synchronization data. Furthermore, it requires requires regular time synchronization data. Furthermore, it requires
the Message Authentication Code (MAC) to be generated over the whole the Message Authentication Code (MAC) to be generated over the whole
rest of the packet (including the NTS message object) and transported rest of the packet (including the NTS message object) and transported
in some way. The NTS message object itself is an ASN.1 object of in some way. The NTS message object itself is an ASN.1 object of
type "TimeResponseSecurityData", with the following structure: type "TimeResponseSecurityData", with the following structure:
TimeResponseSecurityData ::= TimeResponseSecurityData ::=
SEQUENCE { SEQUENCE {
nonce_t NTSNonce, nonce NTSNonce,
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-timeResponseSecurityData OBJECT IDENTIFIER ::= id-ct-nts-securityDataResp OBJECT IDENTIFIER ::= TBD6
{nts(TBD) time(2) timeresponsesecuritydata(2)}
3.3. Broadcast Messages 3.3. Broadcast Messages
3.3.1. Broadcast Parameter Messages 3.3.1. Broadcast Parameter Messages
3.3.1.1. Message Type: "client_bpar" 3.3.1.1. Message Type: "client_bpar"
This first broadcast message is structured according to the NTS-Plain This first broadcast message is structured according to the NTS-Plain
archetype. There is no data necessary besides that which is archetype. There is no data necessary besides that which is
transported in the NTS message object, which is an ASN.1 object of transported in the NTS message object, which is an ASN.1 object of
skipping to change at page 12, line 48 skipping to change at page 13, line 14
BroadcastParameterRequest ::= BroadcastParameterRequest ::=
SEQUENCE { SEQUENCE {
nonce NTSNonce, nonce NTSNonce,
clientId SubjectKeyIdentifier clientId SubjectKeyIdentifier
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-broadcastParameterRequest OBJECT IDENTIFIER ::= id-ct-nts-broadcastParamReq OBJECT IDENTIFIER ::= TBD7
{nts(TBD) association(1) broadcastparameterrequest(5)}
3.3.1.2. Message Type: "server_bpar" 3.3.1.2. Message Type: "server_bpar"
This message is structured according to "NTS-Signed". There is no This message is structured according to "NTS-Signed". It requires
data necessary besides that which is transported in the NTS message additional data besides that which is transported in the NTS message
object, which is an ASN.1 object of type "BroadcastParameterResponse" object, namely the signature is included in the appropriate field of
and structured as follows: the "SignedData" CMS structure that the NTS message object is wrapped
in. The NTS message object itself is an ASN.1 object of type
"BroadcastParameterResponse" and structured as follows:
BroadcastParameterResponse ::= BroadcastParameterResponse ::=
SEQUENCE { SEQUENCE {
nonce NTSNonce, nonce NTSNonce,
oneWayAlgo1 DigestAlgorithmIdentifier, oneWayAlgo1 DigestAlgorithmIdentifier,
oneWayAlgo2 DigestAlgorithmIdentifier, oneWayAlgo2 DigestAlgorithmIdentifier,
lastKey OCTET STRING (SIZE (16)), lastKey OCTET STRING (SIZE (16)),
intervalDuration BIT STRING, intervalDuration BIT STRING,
disclosureDelay INTEGER, disclosureDelay INTEGER,
nextIntervalTime BIT STRING, nextIntervalTime BIT STRING,
nextIntervalIndex INTEGER nextIntervalIndex INTEGER
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-broadcastParameterResponse OBJECT IDENTIFIER ::= id-ct-nts-broadcastParamResp OBJECT IDENTIFIER ::= TBD8
{nts(TBD) association(3) broadcastparameterresponse(6)}
3.3.2. Broadcast Time Synchronization Message 3.3.2. Broadcast Time Synchronization Message
3.3.2.1. Message Type: "server_broad" 3.3.2.1. Message Type: "server_broad"
This message is structured according to the "NTS-Plain" archetype. This message is structured according to the "NTS-Plain" archetype.
It requires regular broadcast time synchronization data in addition It requires regular broadcast time synchronization data in addition
to that which is carried in the NTS message object. Like to that which is carried in the NTS message object. Like
"time_response", this message type also requires a MAC, generated "time_response", this message type also requires a MAC, generated
over all other data, to be transported within the packet. The NTS over all other data, to be transported within the packet. The NTS
skipping to change at page 13, line 51 skipping to change at page 14, line 14
BroadcastTime ::= BroadcastTime ::=
SEQUENCE { SEQUENCE {
thisIntervalIndex INTEGER, thisIntervalIndex INTEGER,
disclosedKey OCTET STRING (SIZE (16)), disclosedKey OCTET STRING (SIZE (16)),
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-broadcastTime OBJECT IDENTIFIER ::= id-ct-nts-broadcastTime OBJECT IDENTIFIER ::= TBD9
{nts(TBD) time(1) broadcasttime(3)}
3.3.3. Broadcast Keycheck 3.3.3. Broadcast Keycheck
3.3.3.1. Message Type: "client_keycheck" 3.3.3.1. Message Type: "client_keycheck"
This message is structured according to the "NTS-Plain" archetype. This message is structured according to the "NTS-Plain" archetype.
There is no data necessary besides that which is transported in the There is no data necessary besides that which is transported in the
NTS message object, which is an ASN.1 object of type NTS message object, which is an ASN.1 object of type
"ClientKeyCheckSecurityData" and structured as follows: "ClientKeyCheckSecurityData" and structured as follows:
ClientKeyCheckSecurityData ::= ClientKeyCheckSecurityData ::=
SEQUENCE { SEQUENCE {
nonce_k NTSNonce, nonce_k NTSNonce,
interval_number INTEGER, interval_number INTEGER,
digestAlgo DigestAlgorithmIdentifier, hmacHashAlgo DigestAlgorithmIdentifier,
keyInputValue OCTET STRING (SIZE(16)) keyInputValue OCTET STRING (SIZE(16))
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier (fictional
values): values):
id-clientKeyCheckSecurityData OBJECT IDENTIFIER ::= id-ct-nts-clientKeyCheck OBJECT IDENTIFIER ::= TBD10
{nts(TBD) time(1) clientkeychecksecuritydata(6)}
3.3.3.2. Message Type: "server_keycheck" 3.3.3.2. Message Type: "server_keycheck"
This message is also structured according to "NTS-Plain". It This message is also structured according to "NTS-Plain". It
requires only a MAC, generated over the NTS message object, to be requires only a MAC, generated over the NTS message object, to be
included in the packet in addition to what the NTS message object included in the packet in addition to what the NTS message object
itself contains. The latter is an ASN.1 object of type itself contains. The latter is an ASN.1 object of type
"ServerKeyCheckSecurityData", which is structured as follows: "ServerKeyCheckSecurityData", which is structured as follows:
ServerKeyCheckSecurityData ::= ServerKeyCheckSecurityData ::=
SEQUENCE { SEQUENCE {
nonce_t NTSNonce, nonce NTSNonce,
interval_number INTEGER interval_number INTEGER
} }
It is identified by the following object identifier (fictional It is identified by the following object identifier:
values):
id-serverKeyCheckSecurityData OBJECT IDENTIFIER ::= id-ct-nts-serverKeyCheck OBJECT IDENTIFIER ::= TBD11
{nts(TBD) time(1) serverkeychecksecuritydata(7)}
4. Certificate Conventions 4. Certificate Conventions
The syntax and processing rules for certificates are specified in The syntax and processing rules for certificates are specified in
[RFC5652]. In the NTS protocol, the server certificate MUST contain [RFC5280]. In the NTS protocol, the server certificate MUST contain
the following extensions: the following extensions:
Subject Key Identifier -- see Section 4.2.1.2 of [RFC5652]. Subject Key Identifier -- see Section 4.2.1.2 of [RFC5280].
Key Usage -- see Section 4.2.1.3 of [RFC5652]. Key Usage -- see Section 4.2.1.3 of [RFC5280].
Extended Key Usage -- see Section 4.2.1.22 of [RFC5652]. Extended Key Usage -- see Section 4.2.1.12 of [RFC5280].
The Extended Key Usage extension MUST include the id-kp-NTSserver For a certificate issued to a time server, the Extended Key Usage
object identifier. When a certificate issuer includes this object extension MAY include the id-kp-ntsServerAuth object identifier.
When a certificate issuer includes this object identifier in the
extended key usage extension, it provides an attestation that the
certificate subject is a time server that supports the NTS protocol.
The extension MAY also include the id-kp-ntsServerAuthz object
identifier. When a certificate issuer includes this object
identifier in the extended key usage extension, it provides an identifier in the extended key usage extension, it provides an
attestation that the certificate subject is a time server that attestation that the certificate subject is a time server which the
supports the NTS protocol. issuer believes to be willing and able to disseminate correct time
(for example, this can be used to signal a server's authorization to
The id-kp-NTSserver object identifier is: disseminate legal time).
id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } For a certificate issued to a time client, the Extended Key Usage
extension MAY include the id-kp-ntsClientAuthz object identifier.
When a certificate issuer includes this object identifier in the
extended key usage extension, it provides an attestation that the
certificate subject is a time client who has authorization from the
issuer to access secured time synchronization (for example, this can
be used to provide access in the case of a paid service for secure
time synchronization).
5. IANA Considerations 5. IANA Considerations
IANA needs to assign an object identifier for the id-kp-NTSserver key 5.1. SMI Security for S/MIME Module Identifier Registry
purpose and another one for the ASN.1 module in the appendix.
Within the "SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0)" table, add one module identifier:
Decimal Description References
------- -------------------------------------- ----------
TBD0 id-networkTimeSecurity-2015 [this doc]
5.2. SMI Security for S/MIME CMS Content Type Registry
Within the "SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1)" table, add eleven content type
identifiers:
Decimal Description References
------- -------------------------------------- ----------
TBD1 id-ct-nts-clientAssoc [this doc]
TBD2 id-ct-nts-serverAssoc [this doc]
TBD3 id-ct-nts-clientCookie [this doc]
TBD4 id-ct-nts-serverCookie [this doc]
TBD5 id-ct-nts-securityDataReq [this doc]
TBD6 id-ct-nts-securityDataResp [this doc]
TBD7 id-ct-nts-broadcastParamReq [this doc]
TBD8 id-ct-nts-broadcastParamResp [this doc]
TBD9 id-ct-nts-broadcastTime [this doc]
TBD10 id-ct-nts-clientKeyCheck [this doc]
TBD11 id-ct-nts-serverKeyCheck [this doc]
5.3. SMI Security for PKIX Extended Key Purpose Registry
Within the "SMI Security for PKIX Extended Key Purpose Identifiers
(1.3.6.1.5.5.7.3)" table, add three key purpose identifiers:
Decimal Description References
------- -------------------------------------- ----------
TBD12 id-kp-ntsServerAuth [this doc]
TBD13 id-kp-ntsServerAuthz [this doc]
TBD14 id-kp-ntsClientAuthz [this doc]
6. Security Considerations 6. Security Considerations
To be written. To be written.
7. References 7. References
7.1. Normative References 7.1. Normative References
[ASN1] International Telecommunication Union, "Abstract Syntax [ASN1] International Telecommunication Union, "Abstract Syntax
Notation One (ASN.1): Specification of basic notation", Notation One (ASN.1): Specification of basic notation",
ITU-T Recommendation X.680, November 2008. ITU-T Recommendation X.680, November 2008.
[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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[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>.
7.2. Informative References 7.2. Informative References
[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-12 (work
in progress), March 2015. in progress), December 2015.
[IEEE1588] [IEEE1588]
IEEE Instrumentation and Measurement Society. TC-9 Sensor IEEE Instrumentation and Measurement Society. TC-9 Sensor
Technology, "IEEE standard for a precision clock Technology, "IEEE standard for a precision clock
synchronization protocol for networked measurement and synchronization protocol for networked measurement and
control systems", 2008. control systems", 2008.
[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>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
The ASN.1 module contained in this appendix defines the id-kp- The ASN.1 module contained in this appendix defines the id-kp-
NTSserver object identifier. NTSserver object identifier.
NTSserverKeyPurpose NTSserverKeyPurpose
{ TBD } { TBD }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
 End of changes. 59 change blocks. 
124 lines changed or deleted 183 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/