< draft-ietf-ntp-cms-for-nts-message-03.txt   draft-ietf-ntp-cms-for-nts-message-04.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: October 3, 2015 S. Roettger Expires: January 7, 2016 S. Roettger
Google Inc. Google Inc.
R. Housley R. Housley
Vigil Security Vigil Security
April 01, 2015 July 06, 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-03.txt draft-ietf-ntp-cms-for-nts-message-04
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 44 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 October 3, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . 11 3.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12
3.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 11 3.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 12
3.3.2. Broadcast Time Synchronization Message . . . . . . . 12 3.3.2. Broadcast Time Synchronization Message . . . . . . . 13
3.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 13 3.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 14
4. Certificate Conventions . . . . . . . . . . . . . . . . . . . 13 4. Certificate Conventions . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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 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. Figure 1 archetype does not make use of any CMS structures at all.
illustrates this structure. Figure 1 illustrates this structure.
+---------------------------------------------------------+ +-----------------------------------------------------+
| | | |
| ContentInfo | | 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,
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
skipping to change at page 5, line 50 skipping to change at page 5, line 44
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 four archetypes. The The ContentInfo content type is used in all archetypes except NTS-
fields of the SignedData content type are used as follows: Plain. The fields of the ContentInfo 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 all archetypes which use ContentInfo (these are NTS-Certified,
that is included. For all other archetypes (NTS-Certified, NTS- NTS-Signed and NTS-Encrypted-and-Signed), it MUST contain the
Signed and NTS-Encrypted-and-Signed), it MUST contain the object 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 all archetypes using
it MUST contain the DER encoded NTS message object. For all other ContentInfo, 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-Encrypted-and-Signed 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
skipping to change at page 9, line 22 skipping to change at page 9, line 19
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 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))
The following ASN.1 coded data types are also necessary for other
types.
KeyEncryptionAlgorithmIdentifiers ::=
SET OF KeyEncryptionAlgorithmIdentifier
ContentEncryptionAlgorithmIdentifiers ::=
SET OF ContentEncryptionAlgorithmIdentifier
3.2. Unicast Messages 3.2. Unicast Messages
3.2.1. Association Messages 3.2.1. Association Messages
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,
clientId SubjectKeyIdentifier, clientId SubjectKeyIdentifier,
digestAlgos DigestAlgorithmIdentifiers, digestAlgos DigestAlgorithmIdentifiers,
keyEncAlgos KeyEncryptionAlgorithms, keyEncAlgos KeyEncryptionAlgorithmIdentifiers,
contentEncAlgos ContentEncryptionAlgorithms contentEncAlgos ContentEncryptionAlgorithmIdentifiers
} }
It is identified by the following object identifier (fictional
values):
id-clientAssocData OBJECT IDENTIFIER ::=
{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.
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
"ServerAssocData" and structured as follows: "ServerAssocData" and structured as follows:
ServerAssocData ::= SEQUENCE { ServerAssocData ::= SEQUENCE {
nonce NTSNonce, nonce NTSNonce,
clientId SubjectKeyIdentifier, clientId SubjectKeyIdentifier,
digestAlgos DigestAlgorithmIdentifiers, digestAlgos DigestAlgorithmIdentifiers,
choiceDigestAlgo DigestAlgorithmIdentifier, choiceDigestAlgo DigestAlgorithmIdentifier,
keyEncAlgos KeyEncryptionAlgorithms, keyEncAlgos KeyEncryptionAlgorithmIdentifiers,
choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier,
contentEncAlgos ContentEncryptionAlgorithms contentEncAlgos ContentEncryptionAlgorithmIdentifiers
choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier
} }
It is identified by the following object identifier (fictional
values):
id-serverAssocData OBJECT IDENTIFIER ::=
{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-Certified 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
"ClientCookieData" and structured as follows: "ClientCookieData" and structured as follows:
ClientCookieData ::= SEQUENCE { ClientCookieData ::= SEQUENCE {
skipping to change at page 10, line 37 skipping to change at page 10, line 50
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(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. 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
type "ServerCookieData" and structured as follows: 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(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. The NTS message object itself is an ASN.1
object of type "TimeRequestSecurityData", whose structure is as object of type "TimeRequestSecurityData", whose structure is as
follows: follows:
TimeRequestSecurityData ::= TimeRequestSecurityData ::=
SEQUENCE { SEQUENCE {
nonce_t NTSNonce, nonce_t NTSNonce,
digestAlgo DigestAlgorithmIdentifier, digestAlgo DigestAlgorithmIdentifier,
hashOfClientCert BIT STRING keyInputValue OCTET STRING (SIZE(16))
} }
It is identified by the following object identifier (fictional
values):
id-timeRequestSecurityData OBJECT IDENTIFIER ::=
{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 also structured according to "NTS-Plain".
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_t NTSNonce,
} }
It is identified by the following object identifier (fictional
values):
id-timeResponseSecurityData OBJECT IDENTIFIER ::=
{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
type "BroadcastParameterRequest" and structured as follows: type "BroadcastParameterRequest" and structured as follows:
BroadcastParameterRequest ::= BroadcastParameterRequest ::=
SEQUENCE { SEQUENCE {
nonce NTSNonce, nonce NTSNonce,
clientId SubjectKeyIdentifier clientId SubjectKeyIdentifier
} }
It is identified by the following object identifier (fictional
values):
id-broadcastParameterRequest OBJECT IDENTIFIER ::=
{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". There is no
data necessary besides that which is transported in the NTS message data necessary besides that which is transported in the NTS message
object, which is an ASN.1 object of type "BroadcastParameterResponse" object, which is an ASN.1 object of type "BroadcastParameterResponse"
and structured as follows: 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
values):
id-broadcastParameterResponse OBJECT IDENTIFIER ::=
{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
message object itself is an ASN.1 object of type "BroadcastTime". It message object itself is an ASN.1 object of type "BroadcastTime". It
has the following structure: has the following structure:
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
values):
id-broadcastTime OBJECT IDENTIFIER ::=
{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, digestAlgo DigestAlgorithmIdentifier,
hashOfClientCert BIT STRING keyInputValue OCTET STRING (SIZE(16))
} }
It is identified by the following object identifier (fictional
values):
id-clientKeyCheckSecurityData OBJECT IDENTIFIER ::=
{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_t NTSNonce,
interval_number INTEGER interval_number INTEGER
} }
It is identified by the following object identifier (fictional
values):
id-serverKeyCheckSecurityData OBJECT IDENTIFIER ::=
{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 [RFC5652]. 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 [RFC5652].
Key Usage -- see Section 4.2.1.3 of [RFC5652]. Key Usage -- see Section 4.2.1.3 of [RFC5652].
skipping to change at page 14, line 42 skipping to change at page 15, line 48
[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, March 1997.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009. RFC 5652, September 2009.
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-07 (work Security", draft-ietf-ntp-network-time-security-08 (work
in progress), March 2015. in progress), March 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., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
 End of changes. 30 change blocks. 
50 lines changed or deleted 108 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/