< draft-ietf-ntp-cms-for-nts-message-00.txt   draft-ietf-ntp-cms-for-nts-message-01.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: April 26, 2015 Google Inc Expires: July 26, 2015 Google Inc.
K. Teichel K. Teichel
PTB PTB
R. Housley R. Housley
Vigil Security Vigil Security
October 23, 2014 January 22, 2015
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-00.txt draft-ietf-ntp-cms-for-nts-message-01.txt
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 46 skipping to change at page 1, line 46
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 April 26, 2015. This Internet-Draft will expire on July 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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. Certificate Conventions . . . . . . . . . . . . . . . . . . . 9 3. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9
4. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9
4.2. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Association Messages . . . . . . . . . . . . . . . . 9
4.2.1. Association Messages . . . . . . . . . . . . . . . . 9 3.2.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10
4.2.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10 3.2.3. Time Synchronization Messages . . . . . . . . . . . . 10
4.2.3. Time Synchronization Messages . . . . . . . . . . . . 11 3.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 11
4.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12 3.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 11
4.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 12 3.3.2. Broadcast Time Synchronization Message . . . . . . . 12
4.3.2. Broadcast Time Synchronization Message . . . . . . . 12 3.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 12
4.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 13 4. Certificate Conventions . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document provides detail 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 four archetypes
according to which the NTS message types can be structured: 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 NTS-Plain: This archetype is used for actual time synchronization
messages (explicitly, the 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 the very first messages of a unicast or a broadcast exchange
(client_assoc or client_bpar, respectively) and the broadcast (client_assoc or client_bpar, respectively) and the broadcast
keycheck exchange (client_keycheck and server_keycheck). This keycheck exchange (client_keycheck and server_keycheck). This
archetype does not make use of any CMS structures. archetype does not make use of any CMS structures. Figure 1
illustrates this structure.
NTS-Signed-and-Encrypted: This archetype is used for secure +---------------------------------------------------------+
| |
| 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, transmission of the cookie (only for the server_cook message type,
see [I-D.ietf-ntp-network-time-security], section 6). For this, see [I-D.ietf-ntp-network-time-security], Section 6). For this,
the following CMS structure is used: the following CMS structure is used:
First, the NTS message MUST be encrypted using the First, the NTS message MUST be encrypted using the
EnvelopedData content type. EnvelopedData supports nearly any EnvelopedData content type. EnvelopedData supports nearly any
form of key management. In the NTS protocol the client form of key management. In the NTS protocol the client
provides a certificate in an unprotected message, and the provides a certificate in an unprotected message, and the
public key from this certificate, if it is valid, will be used public key from this certificate, if it is valid, will be used
to establish a pairwise symmetric key for the encryption of the to establish a pairwise symmetric key for the encryption of the
protected NTS message. protected NTS message.
Second, the EnvelopedData content MUST be digitally signed Second, the EnvelopedData content MUST be digitally signed
using the SignedData content type. SignedData supports nearly using the SignedData content type. SignedData supports nearly
any form of digital signature, and in the NTS protocol the any form of digital signature, and in the NTS protocol the
server will include its certificate within the SignedData server will include its certificate within the SignedData
content type. content type.
Third, the SignedData content type MUST be encapsulated in a Third, the SignedData content type MUST be encapsulated in a
ContentInfo content type. ContentInfo content type.
Figure 1 illustrates this structure. Figure 2 illustrates this structure.
+---------------------------------------------------------+ +---------------------------------------------------------+
| | | |
| ContentInfo | | ContentInfo |
| | | |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| | | | | | | |
| | SignedData | | | | SignedData | |
| | | | | | | |
| | +-------------------------------------------------+ | | | | +-------------------------------------------------+ | |
skipping to change at page 4, line 42 skipping to change at page 5, line 14
First, the NTS message object MUST be wrapped in a SignedData First, the NTS message object MUST be wrapped in a SignedData
content type. The messages MUST be digitally signed, and content type. The messages MUST be digitally signed, and
certificates included. SignedData supports nearly any form of certificates included. SignedData supports nearly any form of
digital signature, and in the NTS protocol the server will digital signature, and in the NTS protocol the server will
include its certificate within the SignedData content type. include its certificate within the SignedData content type.
Second, the SignedData content type MUST be encapsulated in a Second, the SignedData content type MUST be encapsulated in a
ContentInfo content type. ContentInfo content type.
Figure 2 illustrates this structure. Figure 3 illustrates this structure.
+---------------------------------------------------------+ +---------------------------------------------------------+
| | | |
| ContentInfo | | ContentInfo |
| | | |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| | | | | | | |
| | SignedData | | | | SignedData | |
| | | | | | | |
| | +-------------------------------------------------+ | | | | +-------------------------------------------------+ | |
skipping to change at page 5, line 26 skipping to change at page 5, line 37
| | | | | | | | | | | |
| | | | | | | | | | | |
| | +-------------------------------------------------+ | | | | +-------------------------------------------------+ | |
| | | | | | | |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
| | | |
+---------------------------------------------------------+ +---------------------------------------------------------+
NTS-Certified: This archetype is used for the client_cook message NTS-Certified: This archetype is used for the client_cook message
type. It uses a CMS structure much like the NTS-Signed archetype type. It uses a CMS structure much like the NTS-Signed archetype
(see Figure 2), with the only difference being that messages (see Figure 3), with the only difference being that messages
SHOULD NOT be digitally signed. This archetype employs the CMS SHOULD NOT be digitally signed. This archetype employs the CMS
structure merely in order to transport certificates. structure merely in order to transport certificates.
Whichever archetype is used, the resulting structure is always
transported in an extension field of an NTP packet. In the case of
messages that also need to carry time synchronization data, this data
is written into the regular fields of the NTP packet.
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: Overall, three CMS content types are used for NTS messages by the
ContentInfo, SignedData and EnvelopedData. The following is a archetypes above. Explicitly, those content types are ContentInfo,
description of how the fields of those content types are used in SignedData and EnvelopedData. The following is a description of how
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 four archetypes. The The ContentInfo content type is used in all four archetypes. The
fields of the SignedData content type are used as follows: fields of the SignedData content type are used as follows:
contentType -- indicates the type of the associated content. For contentType -- indicates the type of the associated content. For
the archetype NTS-Plain, it MUST identify the NTS message object the archetype NTS-Plain, it MUST identify the NTS message object
that is included. For all other archetypes (NTS-Certified, NTS- that is included. For all other archetypes (NTS-Certified, NTS-
Signed and NTS-Signed-and-Encrypted), it MUST contain the object Signed and NTS-Encrypted-and-Signed), it MUST contain the object
identifier for the SignedData content type: identifier 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 the NTS-Plain archetype, content is the associated content. For the NTS-Plain archetype,
it MUST contain the DER encoded NTS message object. For all other it MUST contain the DER encoded NTS message object. For all other
archetypes, it MUST contain the DER encoded SignedData content archetypes, 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-Certified, NTS-Signed
and NTS-Signed-and-Encrypted archetypes but not in the NTS-Plain and NTS-Encrypted-and-Signed archetypes, but not in the NTS-Plain
archetype. The fields of the SignedData content type are used as archetype. 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-Certified and NTS-Signed archetypes, it MUST
identify the type of the NTS message that was encapsulated. identify the type of the NTS message that was encapsulated.
For the NTS-Signed-and-Encrypted archetype, it MUST contain the For the NTS-Encrypted-and-Signed archetype, it MUST contain the
object identifier for the EnvelopedData content type: object identifier for the 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-Certified and NTS-Signed archetypes, it MUST
contain the DER encoded encapsulated NTS message object. The contain the DER encoded encapsulated NTS message object. The
instructions in Section 6.3 of [RFC5652] MUST be followed. For instructions in Section 6.3 of [RFC5652] MUST be followed. For
the NTS-Signed-and-Encrypted archetype, it MUST contain the DER the NTS-Encrypted-and-Signed archetype, it MUST contain the DER
encoded EnvelopedData content type. encoded 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-Certified archetype, this SHOULD be left
out. For both the NTS-Signed and the NTS-Signed-and-Encrypted 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
protocol, the sid field contains the subjectKeyIdentifier from protocol, the "sid" field contains the subjectKeyIdentifier
the signer's certificate. from the signer's certificate.
digestAlgorithm -- identifies the message digest algorithm, and digestAlgorithm -- identifies the message digest algorithm and
any associated parameters, used by the signer. In the NTS any associated parameters used by the signer. In the NTS
protocol, the identifier MUST match the single algorithm protocol, the identifier MUST match the single algorithm
identifier present in the digestAlgorithms. identifier present in the digestAlgorithms.
signedAttrs -- is a collection of attributes that are signed. signedAttrs -- is a collection of attributes that are signed.
In the NTS protocol, it MUST be present, and it MUST contain In the NTS protocol, it MUST be present, and it MUST contain
the following attributes: the following attributes:
Content Type -- see Section 11.1 of [RFC5652]. Content Type -- see Section 11.1 of [RFC5652].
Message Digest -- see Section 11.2 of [RFC5652]. Message Digest -- see Section 11.2 of [RFC5652].
In addition, it MAY contain the following attributes: In addition, it MAY contain the following attributes:
Signing Time -- see Section 11.3 of [RFC5652]. Signing Time -- see Section 11.3 of [RFC5652].
Binary Signing Time -- see Section 3 of [RFC5652]. Binary Signing Time -- see Section 3 of [RFC5652].
signatureAlgorithm -- identifies the signature algorithm, and signatureAlgorithm -- identifies the signature algorithm and
any associated parameters, used by the signer to generate the any associated parameters used by the signer to generate the
digital signature. digital signature.
signature is the result of digital signature generation, using signature is the result of digital signature generation using
the message digest and the signer's private key. The the message digest and the signer's private key. The
instructions in Section 5.5 of [RFC5652] MUST be followed. instructions in Section 5.5 of [RFC5652] MUST be followed.
unsignedAttrs -- is an optional collection of attributes that unsignedAttrs -- is an optional collection of attributes that
are not signed. In the NTS protocol, the it MUST be absent. are not signed. In the NTS protocol, it MUST be absent.
2.1.3. EnvelopedData 2.1.3. EnvelopedData
The EnvelopedData content type is used only in the NTS-Signed-and- The EnvelopedData content type is used only in the NTS-Encrypted-and-
Encrypted archetype. The fields of the EnvelopedData content type Signed archetype. The fields of the EnvelopedData content type are
are used as follows: used as follows:
version -- the appropriate value depends on the type of key version -- the appropriate value depends on the type of key
management that is used. The instructions in [RFC5652] section management that is used. The instructions in [RFC5652]
6.1 MUST be followed to set the correct value. Section 6.1 MUST be followed to set the correct value.
originatorInfo -- this structure is present only if required by originatorInfo -- this structure is present only if required by
the key management algorithm. In the NTS protocol, it MUST be the key management algorithm. In the NTS protocol, it MUST be
present when a key agreement algorithm is used, and it MUST absent present when a key agreement algorithm is used, and it MUST be
when a key transport algorithm is used. The instructions in absent when a key transport algorithm is used. The instructions
Section 6.1 of [RFC5652] MUST be followed. in Section 6.1 of [RFC5652] MUST be followed.
recipientInfos -- this structure is always present. In the NTS recipientInfos -- this structure is always present. In the NTS
protocol, it MUST contain exactly one entry that allows the client protocol, it MUST contain exactly one entry that allows the client
to determine the key used to encrypt the NTS message. The to determine the key used to encrypt the NTS message. The
instructions in Section 6.2 of [RFC5652] MUST be followed. instructions in Section 6.2 of [RFC5652] MUST be followed.
encryptedContentInfo -- this structure is always present. In the encryptedContentInfo -- this structure is always present. In the
NTS protocol, it MUST follow these conventions: NTS protocol, it MUST follow these conventions:
contentType -- indicates the type of content. In the NTS contentType -- indicates the type of content. In the NTS
protocol, it MUST identify the type of the NTS message that was protocol, it MUST identify the type of the NTS message that was
encrypted. encrypted.
contentEncryptionAlgorithm -- identifies the content-encryption contentEncryptionAlgorithm -- identifies the content-encryption
algorithm, and any associated parameters, used to encrypt the algorithm and any associated parameters used to encrypt the
content. content.
encryptedContent -- is the encrypted the content. In the NTS encryptedContent -- is the encrypted content. In the NTS
protocol, it MUST contain the encrypted NTS message. The protocol, it MUST contain the encrypted NTS message. The
instructions in Section 6.3 of [RFC5652] MUST be followed. instructions in Section 6.3 of [RFC5652] MUST be followed.
unprotectedAttrs -- this structure is optional. In the NTS unprotectedAttrs -- this structure is optional. In the NTS
protocol, it MUST be absent. protocol, it MUST be absent.
3. Certificate Conventions 3. Implementation Notes: ASN.1 Structures and Use of the CMS
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].
The Extended Key Usage extension MUST include the id-kp-NTSserver
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 id-kp-NTSserver object identifier is:
id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD }
4. Implementation Notes: ASN.1 Structures and Use of the CMS
This section gives some hints on the structures of the NTS message This section presents some hints about the structures of the NTS
objects for the different message types when one wishes to implement message objects for the different message types when one wishes to
the protocol. implement the security mechanisms.
4.1. Preliminaries 3.1. Preliminaries
The following ASN.1 coded data type "NTSNonce" is needed for other 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 types used below for NTS messages. It specifies a 128 bit nonce as
required in several message types: required in several message types:
NTSNonce ::= OCTET STRING (SIZE(16)) NTSNonce ::= OCTET STRING (SIZE(16))
4.2. Unicast Messages 3.2. Unicast Messages
4.2.1. Association Messages 3.2.1. Association Messages
4.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. It This message is structured according to the NTS-Plain archetype.
is realized as an NTP packet with an extension field which holds all There is no data necessary besides that which is transported in the
the data relevant for NTS. Explicitly, the extension field contains NTS message object, which is an ASN.1 object of type
an ASN.1 object of type "ClientAssocData", which is structured as "ClientAssocData" and structured as follows:
follows:
ClientAssocData ::= SEQUENCE { ClientAssocData ::= SEQUENCE {
clientId SubjectKeyIdentifier, clientId SubjectKeyIdentifier,
digestAlgos DigestAlgorithmIdentifiers, digestAlgos DigestAlgorithmIdentifiers,
keyEncAlgos KeyEncryptionAlgorithms, keyEncAlgos KeyEncryptionAlgorithms,
contentEncAlgos ContentEncryptionAlgorithms contentEncAlgos ContentEncryptionAlgorithms
} }
4.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.
The NTS message object in this case is an ASN.1 object of type There is no data necessary besides that which is transported in the
"ServerAssocData", which is structured as follows: NTS message object, which is an ASN.1 object of type
"ServerAssocData" and structured as follows:
ServerAssocData ::= SEQUENCE { ServerAssocData ::= SEQUENCE {
clientId SubjectKeyIdentifier, clientId SubjectKeyIdentifier,
choiceDigestAlgo DigestAlgorithmIdentifier, choiceDigestAlgo DigestAlgorithmIdentifier,
choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier,
choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier
} }
4.2.2. Cookie Messages 3.2.2. Cookie Messages
4.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-Certified archetype.
The NTS message object is a "ClientCookieData" type ASN.1 object, There is no data necessary besides that which is transported in the
structured as follows: NTS message object, which is an ASN.1 object of type
"ClientCookieData" and structured as follows:
ClientCookieData ::= SEQUENCE { ClientCookieData ::= SEQUENCE {
nonce NTSNonce, nonce NTSNonce,
signAlgo SignatureAlgorithmIdentifier, signAlgo SignatureAlgorithmIdentifier,
digestAlgo DigestAlgorithmIdentifier, digestAlgo DigestAlgorithmIdentifier,
encAlgo ContentEncryptionAlgorithmIdentifier, encAlgo ContentEncryptionAlgorithmIdentifier,
keyEncAlgo KeyEncryptionAlgorithmIdentifier keyEncAlgo KeyEncryptionAlgorithmIdentifier
} }
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-clientCookieData OBJECT IDENTIFIER ::=
{nts(??) cookie(3) clientcookiedata(1)} {nts(??) cookie(3) clientcookiedata(1)}
4.2.2.2. Message Type: "server_cook" 3.2.2.2. Message Type: "server_cook"
This message is structured according to the "NTS-Signed-and- This message is structured according to the "NTS-Encrypted-and-
Encrypted" archetype. The NTS message object is a "ServerCookieData" Signed" archetype. There is no data necessary besides that which is
object, specified as: transported in the NTS message object, which is an ASN.1 object 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-serverCookieData OBJECT IDENTIFIER ::=
{nts(??) cookie(3) servercookiedata(2)} {nts(??) cookie(3) servercookiedata(2)}
4.2.3. Time Synchronization Messages 3.2.3. Time Synchronization Messages
4.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.
It is realized as an NTP packet which actually contains regular NTP
time synchronization data, as an unsecured NTP packet from a client This message type requires additional data to that which is included
to a server would. Furthermore, the packet has an extension field in the NTS message object, namely it requires regular time
which contains an ASN.1 object of type "TimeRequestSecurityData", synchronization data, as an unsecured packet from a client to a
whose structure is as follows: server would contain. 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_t NTSNonce,
digestAlgo DigestAlgorithmIdentifier, digestAlgo DigestAlgorithmIdentifier,
hashOfClientCert BIT STRING hashOfClientCert BIT STRING
} }
4.2.3.2. Message Type: "time_response" 3.2.3.2. Message Type: "time_response"
This message is also structured according to "NTS-Plain". It is This message is also structured according to "NTS-Plain".
realized as an NTP packet which, like "time_request", contains
regular NTP time synchronization data, as an unsecured NTP packet It requires two items of data in addition to that which is
from a server back to a client would. The packet also has an transported in the NTS message object. Like "time_request", it
extension field which contains an ASN.1 object of type requires regular time synchronization data. Furthermore, it requires
"TimeResponseSecurityData", with the following structure: 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 ::= TimeResponseSecurityData ::=
SEQUENCE { SEQUENCE {
nonce_t NTSNonce, nonce_t NTSNonce,
} }
Finally, this NTP packet has a MAC field which contains a Message 3.3. Broadcast Messages
Authentication Code generated over the whole packet (including the
extension field).
4.3. Broadcast Messages
4.3.1. Broadcast Parameter Messages 3.3.1. Broadcast Parameter Messages
4.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. It is realized as an NTP packet which is empty except for archetype. There is no data necessary besides that which is
an extension field which contains ans ASN.1 object of type transported in the NTS message object, which is an ASN.1 object of
"BroadcastParameterRequest", which is structured as follows: type "BroadcastParameterRequest" and structured as follows:
BroadcastParameterRequest ::= BroadcastParameterRequest ::=
SEQUENCE { SEQUENCE {
clientId SubjectKeyIdentifier clientId SubjectKeyIdentifier
} }
4.3.1.2. Message Type: "server_bpar" 3.3.1.2. Message Type: "server_bpar"
This message is structured according to "NTS-Signed". It is realized This message is structured according to "NTS-Signed". There is no
as an NTP packet whose extension field carries the necessary CMS data necessary besides that which is transported in the NTS message
structure. The NTS message object in this case is an ASN.1 object of object, which is an ASN.1 object of type "BroadcastParameterResponse"
type "BroadcastParameterResponse", with the following structure: and structured as follows:
BroadcastParameterRequest ::= BroadcastParameterResponse ::=
SEQUENCE { SEQUENCE {
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
} }
4.3.2. Broadcast Time Synchronization Message 3.3.2. Broadcast Time Synchronization Message
4.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.
Its realization works via an NTP packet which carries regular NTP It requires regular broadcast time synchronization data in addition
broadcast time data as well as an extension field, which contains an to that which is carried in the NTS message object. Like
ASN.1 object of type "BroadcastTime". It has the following "time_response", this message type also requires a MAC, generated
structure: 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:
BroadcastTime ::= BroadcastTime ::=
SEQUENCE { SEQUENCE {
thisIntervalIndex INTEGER, thisIntervalIndex INTEGER,
disclosedKey OCTET STRING (SIZE (16)), disclosedKey OCTET STRING (SIZE (16)),
} }
In addition, this packet has a MAC field which contains a Message 3.3.3. Broadcast Keycheck
Authentication Code generated over the whole packet (including the
extension field).
4.3.3. Broadcast Keycheck
4.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.
It is realized as an NTP packet with an extension field, which There is no data necessary besides that which is transported in the
contains an ASN.1 object of type "ClientKeyCheckSecurityData", whose NTS message object, which is an ASN.1 object of type
structure is 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, digestAlgo DigestAlgorithmIdentifier,
hashOfClientCert BIT STRING hashOfClientCert BIT STRING
} }
4.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 is also This message is also structured according to "NTS-Plain". It
realized as an NTP packet with an extension field, which contains an requires only a MAC, generated over the NTS message object, to be
ASN.1 object of type "ServerKeyCheckSecurityData", with the following included in the packet in addition to what the NTS message object
structure: itself contains. The latter is an ASN.1 object of type
"ServerKeyCheckSecurityData", which is structured as follows:
ServerKeyCheckSecurityData ::= ServerKeyCheckSecurityData ::=
SEQUENCE { SEQUENCE {
nonce_t NTSNonce, nonce_t NTSNonce,
interval_number INTEGER interval_number INTEGER
} }
Additionally, this NTP packet has a MAC field which contains a 4. Certificate Conventions
Message Authentication Code generated over the whole packet
(including the extension field). 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].
The Extended Key Usage extension MUST include the id-kp-NTSserver
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 id-kp-NTSserver object identifier is:
id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD }
5. IANA Considerations 5. IANA Considerations
IANA needs to assign an object identifier for id-kp-NTSserver key IANA needs to assign an object identifier for the id-kp-NTSserver key
purpose and another one for the ASN.1 module in the appendix. purpose and another one for the ASN.1 module in the appendix.
6. Security Considerations 6. Security Considerations
To be written. To be written.
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 14, line 42 skipping to change at page 14, line 42
RFC 5652, September 2009. RFC 5652, September 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
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-04 (work Security", draft-ietf-ntp-network-time-security-06 (work
in progress), July 2014. in progress), January 2015.
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 ::=
skipping to change at page 15, line 28 skipping to change at page 15, line 28
Physikalisch-Technische Bundesanstalt Physikalisch-Technische Bundesanstalt
Bundesallee 100 Bundesallee 100
Braunschweig D-38116 Braunschweig D-38116
Germany Germany
Phone: +49-(0)531-592-8420 Phone: +49-(0)531-592-8420
Fax: +49-531-592-698420 Fax: +49-531-592-698420
Email: dieter.sibold@ptb.de Email: dieter.sibold@ptb.de
Stephen Roettger Stephen Roettger
Google Inc Google Inc.
Email: stephen.roettger@googlemail.com Email: stephen.roettger@googlemail.com
Kristof Teichel Kristof Teichel
Physikalisch-Technische Bundesanstalt Physikalisch-Technische Bundesanstalt
Bundesallee 100 Bundesallee 100
Braunschweig D-38116 Braunschweig D-38116
Germany Germany
Phone: +49-(0)531-592-8421 Phone: +49-(0)531-592-8421
 End of changes. 72 change blocks. 
164 lines changed or deleted 177 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/