NTP Working Group D. Sibold
Internet-Draft PTB
Intended status: Standards Track S. Roettger
Expires: September 7, 2015 Google Inc.
K. Teichel
PTB
R. Housley
Vigil Security
March 06, 2015
Protecting Network Time Security Messages with the Cryptographic Message
Syntax (CMS)
draft-ietf-ntp-cms-for-nts-message-02.txt
Abstract
This document describes a convention for using the Cryptographic
Message Syntax (CMS) to protect the messages in the Network Time
Security (NTS) protocol. NTS provides authentication of time servers
as well as integrity protection of time synchronization messages
using Network Time Protocol (NTP) or Precision Time Protocol (PTP).
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2015.
Sibold, et al. Expires September 7, 2015 [Page 1]

Internet-Draft CMS4NTS March 2015
describes a convention for using the Cryptographic Message Syntax
(CMS) [RFC5652] to protect messages in the Network Time Security
(NTS) protocol. Encryption is used to provide confidentiality of
secrets, and digital signatures are used to provide authentication
and integrity of content.
Sometimes CMS is used in an exclusively ASN.1 [ASN1] environment. In
this case, the NTS message may use any syntax that facilitates easy
implementation.
2. CMS Conventions for NTS Message Protection
Regarding the usage of CMS, we differentiate between four archetypes
according to which the NTS message types can be structured. They are
presented below. Note that the NTS Message Object that is at the
core of each structure does not necessarily contain all the data
needed for the particular message type, but may contain only that
data which needs to be secured directly with cryptographic operations
using the CMS. Specific information about what is included can be
found in Section 3.
NTS-Plain: This archetype is used for actual time synchronization
messages (explicitly, the following message types: time_request,
time_response, server_broad, see
[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_assoc or client_bpar, respectively) and the broadcast
keycheck exchange (client_keycheck and server_keycheck). This
archetype does not make use of any CMS structures. Figure 1
illustrates this structure.
+---------------------------------------------------------+
| |
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | | |
| | NTS Message Object | |
| | | |
| | | |
| +-----------------------------------------------------+ |
| |
+---------------------------------------------------------+
NTS-Encrypted-and-Signed: This archetype is used for secure
transmission of the cookie (only for the server_cook message type,
see [I-D.ietf-ntp-network-time-security], Section 6). For this,
the following CMS structure is used:
Sibold, et al. Expires September 7, 2015 [Page 3]

Internet-Draft CMS4NTS March 2015
First, the NTS message object MUST be wrapped in a SignedData
content type. The messages MUST be digitally signed, and
certificates included. SignedData supports nearly any form of
digital signature, and in the NTS protocol the server will
include its certificate within the SignedData content type.
Second, the SignedData content type MUST be encapsulated in a
ContentInfo content type.
Figure 3 illustrates this structure.
+---------------------------------------------------------+
| |
| ContentInfo |
| |
| +-----------------------------------------------------+ |
| | | |
| | SignedData | |
| | | |
| | +-------------------------------------------------+ | |
| | | | | |
| | | 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
Overall, three CMS content types are used for NTS messages by the
archetypes above. Explicitly, those content types are ContentInfo,
SignedData and EnvelopedData. The following is a description of how
the fields of those content types are used in detail.
2.1.1. ContentInfo
The ContentInfo content type is used in all four archetypes. The
fields of the SignedData content type are used as follows:
Sibold, et al. Expires September 7, 2015 [Page 5]

Internet-Draft CMS4NTS March 2015
contentType -- indicates the type of the associated content. For
the archetype NTS-Plain, it MUST identify the NTS message object
that is included. For all other archetypes (NTS-Certified, NTS-
Signed and NTS-Encrypted-and-Signed), it MUST contain the object
identifier for the SignedData content type:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
content is the associated content. For the NTS-Plain archetype,
it MUST contain the DER encoded NTS message object. For all other
archetypes, it MUST contain the DER encoded SignedData content
type.
2.1.2. SignedData
The SignedData content type is used in the NTS-Certified, NTS-Signed
and NTS-Encrypted-and-Signed archetypes, but not in the NTS-Plain
archetype. The fields of the SignedData content type are used as
follows:
version -- the appropriate value depends on the optional items
that are included. In the NTS protocol, the signer certificate
MUST be included and other items MAY be included. The
instructions in [RFC5652] Section 5.1 MUST be followed to set the
correct value.
digestAlgorithms -- is a collection of message digest algorithm
identifiers. In the NTS protocol, there MUST be exactly one
algorithm identifier present. The instructions in Section 5.4 of
[RFC5652] MUST be followed.
encapContentInfo -- this structure is always present. In the NTS
protocol, it MUST follow these conventions:
eContentType -- is an object identifier. In the NTS protocol,
for the NTS-Certified and NTS-Signed archetypes, it MUST
identify the type of the NTS message that was encapsulated.
For the NTS-Encrypted-and-Signed archetype, it MUST contain the
object identifier for the EnvelopedData content type:
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }.
eContent is the content itself, carried as an octet string.
For the NTS-Certified and NTS-Signed archetypes, it MUST
contain the DER encoded encapsulated NTS message object. The
instructions in Section 6.3 of [RFC5652] MUST be followed. For
Sibold, et al. Expires September 7, 2015 [Page 6]

Internet-Draft CMS4NTS March 2015
the NTS-Encrypted-and-Signed archetype, it MUST contain the DER
encoded EnvelopedData content type.
certificates -- is a collection of certificates. In the NTS
protocol, it MUST contain the DER encoded certificate [RFC5280] of
the sender. It is intended that the collection of certificates be
sufficient for the recipient to construct a certification path
from a recognized "root" or "top-level certification authority" to
the certificate used by the sender.
crls -- is a collection of revocation status information. In the
NTS protocol, it MAY contain one or more DER encoded CRLs
[RFC5280]. It is intended that the collection contain information
sufficient to determine whether the certificates in the
certificates field are valid.
signerInfos -- is a collection of per-signer information. In the
NTS protocol, for the NTS-Certified archetype, this SHOULD be left
out. For both the NTS-Signed and the NTS-Encrypted-and-Signed
archetypes, there MUST be exactly one SignerInfo structure
present. The details of the SignerInfo type are discussed in
Section 5.3 of [RFC5652]. In the NTS protocol, it MUST follow
these conventions:
version -- is the syntax version number. In the NTS protocol,
the SignerIdentifier is subjectKeyIdentifier, therefore the
version MUST be 3.
sid -- identifies the signer's certificate. In the NTS
protocol, the "sid" field contains the subjectKeyIdentifier
from the signer's certificate.
digestAlgorithm -- identifies the message digest algorithm and
any associated parameters used by the signer. In the NTS
protocol, the identifier MUST match the single algorithm
identifier present in the digestAlgorithms.
signedAttrs -- is a collection of attributes that are signed.
In the NTS protocol, it MUST be present, and it MUST contain
the following attributes:
Content Type -- see Section 11.1 of [RFC5652].
Message Digest -- see Section 11.2 of [RFC5652].
In addition, it MAY contain the following attributes:
Signing Time -- see Section 11.3 of [RFC5652].
Sibold, et al. Expires September 7, 2015 [Page 7]

Internet-Draft CMS4NTS March 2015
Binary Signing Time -- see Section 3 of [RFC5652].
signatureAlgorithm -- identifies the signature algorithm and
any associated parameters used by the signer to generate the
digital signature.
signature is the result of digital signature generation using
the message digest and the signer's private key. The
instructions in Section 5.5 of [RFC5652] MUST be followed.
unsignedAttrs -- is an optional collection of attributes that
are not signed. In the NTS protocol, it MUST be absent.
2.1.3. EnvelopedData
The EnvelopedData content type is used only in the NTS-Encrypted-and-
Signed archetype. The fields of the EnvelopedData content type are
used as follows:
version -- the appropriate value depends on the type of key
management that is used. The instructions in [RFC5652]
Section 6.1 MUST be followed to set the correct value.
originatorInfo -- this structure is present only if required by
the key management algorithm. In the NTS protocol, it MUST be
present when a key agreement algorithm is used, and it MUST be
absent when a key transport algorithm is used. The instructions
in Section 6.1 of [RFC5652] MUST be followed.
recipientInfos -- this structure is always present. In the NTS
protocol, it MUST contain exactly one entry that allows the client
to determine the key used to encrypt the NTS message. The
instructions in Section 6.2 of [RFC5652] MUST be followed.
encryptedContentInfo -- this structure is always present. In the
NTS protocol, it MUST follow these conventions:
contentType -- indicates the type of content. In the NTS
protocol, it MUST identify the type of the NTS message that was
encrypted.
contentEncryptionAlgorithm -- identifies the content-encryption
algorithm and any associated parameters used to encrypt the
content.
encryptedContent -- is the encrypted content. In the NTS
protocol, it MUST contain the encrypted NTS message. The
instructions in Section 6.3 of [RFC5652] MUST be followed.
Sibold, et al. Expires September 7, 2015 [Page 8]

Internet-Draft CMS4NTS March 2015
unprotectedAttrs -- this structure is optional. In the NTS
protocol, it MUST be absent.
3. Implementation Notes: ASN.1 Structures and Use of the CMS
This section presents some hints about the structures of the NTS
message objects for the different message types when one wishes to
implement the security mechanisms.
3.1. Preliminaries
The following ASN.1 coded data type "NTSNonce" is needed for other
types used below for NTS messages. It specifies a 128 bit nonce as
required in several message types:
NTSNonce ::= OCTET STRING (SIZE(16))
3.2. Unicast Messages3.2.1. Association Messages3.2.1.1. Message Type: "client_assoc"
This message is structured according to the NTS-Plain archetype.
There is no data necessary besides that which is transported in the
NTS message object, which is an ASN.1 object of type
"ClientAssocData" and structured as follows:
ClientAssocData ::= SEQUENCE {
nonce NTSNonce,
clientId SubjectKeyIdentifier,
digestAlgos DigestAlgorithmIdentifiers,
keyEncAlgos KeyEncryptionAlgorithms,
contentEncAlgos ContentEncryptionAlgorithms
}
3.2.1.2. Message Type: "server_assoc"
This message is structured according to the NTS-Signed archetype.
There is no data necessary besides that which is transported in the
NTS message object, which is an ASN.1 object of type
"ServerAssocData" and structured as follows:
Sibold, et al. Expires September 7, 2015 [Page 9]

Internet-Draft CMS4NTS March 2015
id-serverCookieData OBJECT IDENTIFIER ::=
{nts(??) cookie(3) servercookiedata(2)}
3.2.3. Time Synchronization Messages3.2.3.1. Message Type: "time_request"
This message is structured according to the "NTS-Plain" archetype.
This message type requires additional data to that which is included
in the NTS message object, namely it requires regular time
synchronization data, as an unsecured packet from a client to a
server would contain. The NTS message object itself is an ASN.1
object of type "TimeRequestSecurityData", whose structure is as
follows:
TimeRequestSecurityData ::=
SEQUENCE {
nonce_t NTSNonce,
digestAlgo DigestAlgorithmIdentifier,
hashOfClientCert BIT STRING
}
3.2.3.2. Message Type: "time_response"
This message is also structured according to "NTS-Plain".
It requires two items of data in addition to that which is
transported in the NTS message object. Like "time_request", it
requires regular time synchronization data. Furthermore, it requires
the Message Authentication Code (MAC) to be generated over the whole
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
type "TimeResponseSecurityData", with the following structure:
TimeResponseSecurityData ::=
SEQUENCE {
nonce_t NTSNonce,
}
3.3. Broadcast Messages3.3.1. Broadcast Parameter MessagesSibold, et al. Expires September 7, 2015 [Page 11]

Internet-Draft CMS4NTS March 20153.3.1.1. Message Type: "client_bpar"
This first broadcast message is structured according to the NTS-Plain
archetype. There is no data necessary besides that which is
transported in the NTS message object, which is an ASN.1 object of
type "BroadcastParameterRequest" and structured as follows:
BroadcastParameterRequest ::=
SEQUENCE {
nonce NTSNonce,
clientId SubjectKeyIdentifier
}
3.3.1.2. Message Type: "server_bpar"
This message is structured according to "NTS-Signed". There is no
data necessary besides that which is transported in the NTS message
object, which is an ASN.1 object of type "BroadcastParameterResponse"
and structured as follows:
BroadcastParameterResponse ::=
SEQUENCE {
nonce NTSNonce,
oneWayAlgo1 DigestAlgorithmIdentifier,
oneWayAlgo2 DigestAlgorithmIdentifier,
lastKey OCTET STRING (SIZE (16)),
intervalDuration BIT STRING,
disclosureDelay INTEGER,
nextIntervalTime BIT STRING,
nextIntervalIndex INTEGER
}
3.3.2. Broadcast Time Synchronization Message3.3.2.1. Message Type: "server_broad"
This message is structured according to the "NTS-Plain" archetype.
It requires regular broadcast time synchronization data in addition
to that which is carried in the NTS message object. Like
"time_response", this message type also requires a MAC, generated
over all other data, to be transported within the packet. The NTS
message object itself is an ASN.1 object of type "BroadcastTime". It
has the following structure:
Sibold, et al. Expires September 7, 2015 [Page 12]

Internet-Draft CMS4NTS March 2015
BroadcastTime ::=
SEQUENCE {
thisIntervalIndex INTEGER,
disclosedKey OCTET STRING (SIZE (16)),
}
3.3.3. Broadcast Keycheck3.3.3.1. Message Type: "client_keycheck"
This message is structured according to the "NTS-Plain" archetype.
There is no data necessary besides that which is transported in the
NTS message object, which is an ASN.1 object of type
"ClientKeyCheckSecurityData" and structured as follows:
ClientKeyCheckSecurityData ::=
SEQUENCE {
nonce_k NTSNonce,
interval_number INTEGER,
digestAlgo DigestAlgorithmIdentifier,
hashOfClientCert BIT STRING
}
3.3.3.2. Message Type: "server_keycheck"
This message is also structured according to "NTS-Plain". It
requires only a MAC, generated over the NTS message object, to be
included in the packet in addition to what the NTS message object
itself contains. The latter is an ASN.1 object of type
"ServerKeyCheckSecurityData", which is structured as follows:
ServerKeyCheckSecurityData ::=
SEQUENCE {
nonce_t NTSNonce,
interval_number INTEGER
}
4. Certificate Conventions
The syntax and processing rules for certificates are specified in
[RFC5652]. In the NTS protocol, the server certificate MUST contain
the following extensions:
Subject Key Identifier -- see Section 4.2.1.2 of [RFC5652].
Key Usage -- see Section 4.2.1.3 of [RFC5652].
Extended Key Usage -- see Section 4.2.1.22 of [RFC5652].
Sibold, et al. Expires September 7, 2015 [Page 13]