idnits 2.17.00 (12 Aug 2021) /tmp/idnits65065/draft-ietf-ntp-cms-for-nts-message-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2016) is 2270 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' == Outdated reference: A later version (-15) exists of draft-ietf-ntp-network-time-security-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP Working Group D. Sibold 3 Internet-Draft K. Teichel 4 Intended status: Standards Track PTB 5 Expires: August 28, 2016 S. Roettger 6 Google Inc. 7 R. Housley 8 Vigil Security 9 February 25, 2016 11 Protecting Network Time Security Messages with the Cryptographic Message 12 Syntax (CMS) 13 draft-ietf-ntp-cms-for-nts-message-06 15 Abstract 17 This document describes a convention for using the Cryptographic 18 Message Syntax (CMS) to protect the messages in the Network Time 19 Security (NTS) protocol. NTS provides authentication of time servers 20 as well as integrity protection of time synchronization messages 21 using Network Time Protocol (NTP) or Precision Time Protocol (PTP). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 28, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. CMS Conventions for NTS Message Protection . . . . . . . . . 3 65 2.1. Fields of the employed CMS Content Types . . . . . . . . 5 66 2.1.1. ContentInfo . . . . . . . . . . . . . . . . . . . . . 5 67 2.1.2. SignedData . . . . . . . . . . . . . . . . . . . . . 6 68 2.1.3. EnvelopedData . . . . . . . . . . . . . . . . . . . . 8 69 3. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9 70 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 9 71 3.2. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9 72 3.2.1. Access Messages . . . . . . . . . . . . . . . . . . . 9 73 3.2.2. Association Messages . . . . . . . . . . . . . . . . 10 74 3.2.3. Cookie Messages . . . . . . . . . . . . . . . . . . . 11 75 3.2.4. Time Synchronization Messages . . . . . . . . . . . . 12 76 3.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 13 77 3.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 13 78 3.3.2. Broadcast Time Synchronization Message . . . . . . . 14 79 3.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 14 80 4. Certificate Conventions . . . . . . . . . . . . . . . . . . . 15 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 5.1. SMI Security for S/MIME Module Identifier Registry . . . 16 83 5.2. SMI Security for S/MIME CMS Content Type Registry . . . . 16 84 5.3. SMI Security for PKIX Extended Key Purpose Registry . . . 17 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 89 8.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 This document provides details on how to construct NTS messages in 96 practice. NTS provides secure time synchronization with time servers 97 using Network Time Protocol (NTP) [RFC5905] or Precision Time 98 Protocol (PTP) [IEEE1588]. Among other things, this document 99 describes a convention for using the Cryptographic Message Syntax 100 (CMS) [RFC5652] to protect messages in the Network Time Security 101 (NTS) protocol. Encryption is used to provide confidentiality of 102 secrets, and digital signatures are used to provide authentication 103 and integrity of content. 105 Sometimes CMS is used in an exclusively ASN.1 [ASN1] environment. In 106 this case, the NTS message may use any syntax that facilitates easy 107 implementation. 109 2. CMS Conventions for NTS Message Protection 111 Regarding the usage of CMS, we differentiate between three archetypes 112 according to which the NTS message types can be structured. They are 113 presented below. Note that the NTS Message Object that is at the 114 core of each structure does not necessarily contain all the data 115 needed for the particular message type, but may contain only that 116 data which needs to be secured directly with cryptographic operations 117 using the CMS. Specific information about what is included can be 118 found in Section 3. 120 NTS-Plain: This archetype is used for actual time synchronization 121 messages (explicitly, the following message types: time_request, 122 time_response, server_broad, see 123 [I-D.ietf-ntp-network-time-security], Section 6) as well as for 124 client-side messages of all unicast and broadcast bootstrapping 125 exchanges (explicitly client_assoc, client_cook and client_bpar) 126 as well as the broadcast keycheck exchange (client_keycheck and 127 server_keycheck). This archetype does not make use of any CMS 128 structures at all. Figure 1 illustrates this structure. 130 +-----------------------------------------------------+ 131 | | 132 | NTS Message Object | 133 | | 134 | | 135 +-----------------------------------------------------+ 137 NTS-Encrypted-and-Signed: This archetype is used for secure 138 transmission of the cookie (only for the server_cook message type, 139 see [I-D.ietf-ntp-network-time-security], Section 6). For this, 140 the following CMS structure is used: 142 First, the NTS message MUST be encrypted using the 143 EnvelopedData content type. EnvelopedData supports nearly any 144 form of key management. In the NTS protocol the client 145 provides a certificate in an unprotected message, and the 146 public key from this certificate, if it is valid, will be used 147 to establish a pairwise symmetric key for the encryption of the 148 protected NTS message. 150 Second, the EnvelopedData content MUST be digitally signed 151 using the SignedData content type. SignedData supports nearly 152 any form of digital signature, and in the NTS protocol the 153 server will include its certificate within the SignedData 154 content type. 156 Third, the SignedData content type MUST be encapsulated in a 157 ContentInfo content type. 159 Figure 2 illustrates this structure. 161 +---------------------------------------------------------+ 162 | | 163 | ContentInfo | 164 | | 165 | +-----------------------------------------------------+ | 166 | | | | 167 | | SignedData | | 168 | | | | 169 | | +-------------------------------------------------+ | | 170 | | | | | | 171 | | | EnvelopedData | | | 172 | | | | | | 173 | | | +---------------------------------------------+ | | | 174 | | | | | | | | 175 | | | | NTS Message Object | | | | 176 | | | | | | | | 177 | | | | | | | | 178 | | | +---------------------------------------------+ | | | 179 | | | | | | 180 | | +-------------------------------------------------+ | | 181 | | | | 182 | +-----------------------------------------------------+ | 183 | | 184 +---------------------------------------------------------+ 186 NTS-Signed: This archetype is used for server_assoc and server_bpar 187 message types. It uses the following CMS structure: 189 First, the NTS message object MUST be wrapped in a SignedData 190 content type. The messages MUST be digitally signed, and 191 certificates included. SignedData supports nearly any form of 192 digital signature, and in the NTS protocol the server will 193 include its certificate within the SignedData content type. 195 Second, the SignedData content type MUST be encapsulated in a 196 ContentInfo content type. 198 Figure 3 illustrates this structure. 200 +---------------------------------------------------------+ 201 | | 202 | ContentInfo | 203 | | 204 | +-----------------------------------------------------+ | 205 | | | | 206 | | SignedData | | 207 | | | | 208 | | +-------------------------------------------------+ | | 209 | | | | | | 210 | | | NTS Message Object | | | 211 | | | | | | 212 | | | | | | 213 | | +-------------------------------------------------+ | | 214 | | | | 215 | +-----------------------------------------------------+ | 216 | | 217 +---------------------------------------------------------+ 219 2.1. Fields of the employed CMS Content Types 221 Overall, three CMS content types are used for NTS messages by the 222 archetypes above. Explicitly, those content types are ContentInfo, 223 SignedData and EnvelopedData. The following is a description of how 224 the fields of those content types are used in detail. 226 2.1.1. ContentInfo 228 The ContentInfo content type is used in all archetypes except NTS- 229 Plain. The fields of the ContentInfo content type are used as 230 follows: 232 contentType -- indicates the type of the associated content. For 233 all archetypes which use ContentInfo (these are NTS-Signed and 234 NTS-Encrypted-and-Signed), it MUST contain the object identifier 235 for the SignedData content type: 237 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 238 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 240 content -- is the associated content. For all archetypes using 241 ContentInfo, it MUST contain the DER encoded SignedData content 242 type. 244 2.1.2. SignedData 246 The SignedData content type is used in the NTS-Signed and NTS- 247 Encrypted-and-Signed archetypes, but not in the NTS-Plain archetype. 248 The fields of the SignedData content type are used as follows: 250 version -- the appropriate value depends on the optional items 251 that are included. In the NTS protocol, the signer certificate 252 MUST be included and other items MAY be included. The 253 instructions in [RFC5652] Section 5.1 MUST be followed to set the 254 correct value. 256 digestAlgorithms -- is a collection of message digest algorithm 257 identifiers. In the NTS protocol, there MUST be exactly one 258 algorithm identifier present. The instructions in Section 5.4 of 259 [RFC5652] MUST be followed. 261 encapContentInfo -- this structure is always present. In the NTS 262 protocol, it MUST follow these conventions: 264 eContentType -- is an object identifier. In the NTS protocol, 265 for the NTS-Signed archetype, it MUST identify the type of the 266 NTS message that was encapsulated. For the NTS-Encrypted-and- 267 Signed archetype, it MUST contain the object identifier for the 268 EnvelopedData content type: 270 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 271 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }. 273 eContent is the content itself, carried as an octet string. 274 For the NTS-Signed archetype, it MUST contain the DER encoded 275 encapsulated NTS message object. The instructions in 276 Section 6.3 of [RFC5652] MUST be followed. For the NTS- 277 Encrypted-and-Signed archetype, it MUST contain the DER encoded 278 EnvelopedData content type. 280 certificates -- is a collection of certificates. In the NTS 281 protocol, it MUST contain the DER encoded certificate [RFC5280] of 282 the sender. It is intended that the collection of certificates be 283 sufficient for the recipient to construct a certification path 284 from a recognized "root" or "top-level certification authority" to 285 the certificate used by the sender. 287 crls -- is a collection of revocation status information. In the 288 NTS protocol, it MAY contain one or more DER encoded CRLs 289 [RFC5280]. It is intended that the collection contain information 290 sufficient to determine whether the certificates in the 291 certificates field are valid. 293 signerInfos -- is a collection of per-signer information. In the 294 NTS protocol, for the NTS-Signed and the NTS-Encrypted-and-Signed 295 archetypes, there MUST be exactly one SignerInfo structure 296 present. The details of the SignerInfo type are discussed in 297 Section 5.3 of [RFC5652]. In the NTS protocol, it MUST follow 298 these conventions: 300 version -- is the syntax version number. In the NTS protocol, 301 the SignerIdentifier is subjectKeyIdentifier, therefore the 302 version MUST be 3. 304 sid -- identifies the signer's certificate. In the NTS 305 protocol, the "sid" field contains the subjectKeyIdentifier 306 from the signer's certificate. 308 digestAlgorithm -- identifies the message digest algorithm and 309 any associated parameters used by the signer. In the NTS 310 protocol, the identifier MUST match the single algorithm 311 identifier present in the digestAlgorithms. 313 signedAttrs -- is a collection of attributes that are signed. 314 In the NTS protocol, it MUST be present, and it MUST contain 315 the following attributes: 317 Content Type -- see Section 11.1 of [RFC5652]. 319 Message Digest -- see Section 11.2 of [RFC5652]. 321 In addition, it MAY contain the following attributes: 323 Signing Time -- see Section 11.3 of [RFC5652]. 325 Binary Signing Time -- see Section 3 of [RFC5652]. 327 signatureAlgorithm -- identifies the signature algorithm and 328 any associated parameters used by the signer to generate the 329 digital signature. 331 signature is the result of digital signature generation using 332 the message digest and the signer's private key. The 333 instructions in Section 5.5 of [RFC5652] MUST be followed. 335 unsignedAttrs -- is an optional collection of attributes that 336 are not signed. In the NTS protocol, it MUST be absent. 338 2.1.3. EnvelopedData 340 The EnvelopedData content type is used only in the NTS-Encrypted-and- 341 Signed archetype. The fields of the EnvelopedData content type are 342 used as follows: 344 version -- the appropriate value depends on the type of key 345 management that is used. The instructions in [RFC5652] 346 Section 6.1 MUST be followed to set the correct value. 348 originatorInfo -- this structure is present only if required by 349 the key management algorithm. In the NTS protocol, it MUST be 350 present when a key agreement algorithm is used, and it MUST be 351 absent when a key transport algorithm is used. The instructions 352 in Section 6.1 of [RFC5652] MUST be followed. 354 recipientInfos -- this structure is always present. In the NTS 355 protocol, it MUST contain exactly one entry that allows the client 356 to determine the key used to encrypt the NTS message. The 357 instructions in Section 6.2 of [RFC5652] MUST be followed. 359 encryptedContentInfo -- this structure is always present. In the 360 NTS protocol, it MUST follow these conventions: 362 contentType -- indicates the type of content. In the NTS 363 protocol, it MUST identify the type of the NTS message that was 364 encrypted. 366 contentEncryptionAlgorithm -- identifies the content-encryption 367 algorithm and any associated parameters used to encrypt the 368 content. 370 encryptedContent -- is the encrypted content. In the NTS 371 protocol, it MUST contain the encrypted NTS message. The 372 instructions in Section 6.3 of [RFC5652] MUST be followed. 374 unprotectedAttrs -- this structure is optional. In the NTS 375 protocol, it MUST be absent. 377 3. Implementation Notes: ASN.1 Structures and Use of the CMS 379 This section presents some hints about the structures of the NTS 380 message objects for the different message types when one wishes to 381 implement the security mechanisms. 383 3.1. Preliminaries 385 The following ASN.1 coded data types "NTSAccessKey", "NTSNonce", and 386 "NTSVersion" are needed for other types used below for NTS messages. 387 "NTSAccessKey" specifies an access key, which is required for 388 limitation of client association requests. 390 NTSAccessKey ::= OCTET STRING (SIZE(16)) 392 "NTSNonce" specifies a 128 bit nonce as required in several message 393 types. 395 NTSNonce ::= OCTET STRING (SIZE(16)) 397 "NTSVersion" specifies a version number, which is required for 398 version negotiation. 400 NTSVersion ::= INTEGER (0..255) 402 The following ASN.1 coded data types are also necessary for other 403 types. 405 KeyEncryptionAlgorithmIdentifiers ::= 406 SET OF KeyEncryptionAlgorithmIdentifier 408 ContentEncryptionAlgorithmIdentifiers ::= 409 SET OF ContentEncryptionAlgorithmIdentifier 411 3.2. Unicast Messages 413 3.2.1. Access Messages 415 3.2.1.1. Message Type: "client_access" 417 This message is structured according to the NTS-Plain archetype. 418 There is no data necessary besides that which is transported in the 419 NTS message object, which is an ASN.1 object of type 420 "ClientAccessData" and structured as follows: 422 ClientAccessData ::= NULL 424 It is identified by the following object identifier: 426 id-ct-nts-clientAccess OBJECT IDENTIFIER ::= TBD1 428 3.2.1.2. Message Type: "server_access" 430 This message is structured according to the NTS-Plain archetype. 431 There is no data necessary besides that which is transported in the 432 NTS message object, which is an ASN.1 object of type 433 "ServerAccessData" and structured as follows: 435 ServerAccessData ::= SEQUENCE { 436 accessKey NTSAccessKey 437 } 439 It is identified by the following object identifier: 441 id-ct-nts-serverAccess OBJECT IDENTIFIER ::= TBD2 443 3.2.2. Association Messages 445 3.2.2.1. Message Type: "client_assoc" 447 This message is structured according to the NTS-Plain archetype. 448 There is no data necessary besides that which is transported in the 449 NTS message object, which is an ASN.1 object of type 450 "ClientAssocData" and structured as follows: 452 ClientAssocData ::= SEQUENCE { 453 accessKey NTSAccessKey, 454 nonce NTSNonce, 455 minVersion NTSVersion, 456 hmacHashAlgos DigestAlgorithmIdentifiers, 457 keyEncAlgos KeyEncryptionAlgorithmIdentifiers, 458 contentEncAlgos ContentEncryptionAlgorithmIdentifiers 459 } 461 It is identified by the following object identifier: 463 id-ct-nts-clientAssoc OBJECT IDENTIFIER ::= TBD3 465 3.2.2.2. Message Type: "server_assoc" 467 This message is structured according to the NTS-Signed archetype. It 468 requires additional data besides that which is transported in the NTS 469 message object, namely the signature and certificate chain are 470 included in the appropriate fields of the "SignedData" CMS structure 471 that the NTS message object is wrapped in. The NTS message object 472 itself is an ASN.1 object of type "ServerAssocData" and structured as 473 follows: 475 ServerAssocData ::= SEQUENCE { 476 nonce NTSNonce, 477 proposedVersion NTSVersion, 478 hmacHashAlgos DigestAlgorithmIdentifiers, 479 choiceHmacHashAlgo DigestAlgorithmIdentifier, 480 keyEncAlgos KeyEncryptionAlgorithmIdentifiers, 481 choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, 482 contentEncAlgos ContentEncryptionAlgorithmIdentifiers, 483 choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier 484 } 486 It is identified by the following object identifier: 488 id-ct-nts-serverAssoc OBJECT IDENTIFIER ::= TBD4 490 3.2.3. Cookie Messages 492 3.2.3.1. Message Type: "client_cook" 494 This message is structured according to the NTS-Plain archetype. It 495 requires no additional data besides that which is transported in the 496 NTS message object. The NTS message object itself is an ASN.1 object 497 of type "ClientCookieData" and structured as follows: 499 ClientCookieData ::= SEQUENCE { 500 nonce NTSNonce, 501 signAlgo SignatureAlgorithmIdentifier, 502 hmacHashAlgo DigestAlgorithmIdentifier, 503 encAlgo ContentEncryptionAlgorithmIdentifier, 504 keyEncAlgo KeyEncryptionAlgorithmIdentifier, 505 certificates CertificateSet 506 } 508 It is identified by the following object identifier: 510 id-ct-nts-clientCookie OBJECT IDENTIFIER ::= TBD5 512 3.2.3.2. Message Type: "server_cook" 514 This message is structured according to the "NTS-Encrypted-and- 515 Signed" archetype. It requires additional data besides that which is 516 transported in the NTS message object, namely the signature is 517 included in the appropriate field of the "SignedData" CMS structure 518 that the NTS message object is wrapped in. The NTS message object 519 itself is an ASN.1 sequence of type "ServerCookieData" and structured 520 as follows: 522 ServerCookieData ::= SEQUENCE { 523 nonce NTSNonce, 524 cookie OCTET STRING (SIZE(16)) 525 } 527 It is identified by the following object identifier: 529 id-ct-nts-serverCookie OBJECT IDENTIFIER ::= TBD6 531 3.2.4. Time Synchronization Messages 533 3.2.4.1. Message Type: "time_request" 535 This message is structured according to the "NTS-Plain" archetype. 537 This message type requires additional data to that which is included 538 in the NTS message object, namely it requires regular time 539 synchronization data, as an unsecured packet from a client to a 540 server would contain. Optionally, it requires the Message 541 Authentication Code (MAC) to be generated over the whole rest of the 542 packet (including the NTS message object) and transported in some 543 way. The NTS message object itself is an ASN.1 object of type 544 "TimeRequestSecurityData", whose structure is as follows: 546 TimeRequestSecurityData ::= 547 SEQUENCE { 548 nonce NTSNonce, 549 hmacHashAlgo DigestAlgorithmIdentifier, 550 keyInputValue OCTET STRING (SIZE(16)) 551 } 553 It is identified by the following object identifier: 555 id-ct-nts-securityDataReq OBJECT IDENTIFIER ::= TBD7 557 3.2.4.2. Message Type: "time_response" 559 This message is structured according to the "NTS-Plain" archetype. 561 It requires two items of data in addition to that which is 562 transported in the NTS message object. Like "time_request", it 563 requires regular time synchronization data. Furthermore, it requires 564 the Message Authentication Code (MAC) to be generated over the whole 565 rest of the packet (including the NTS message object) and transported 566 in some way. The NTS message object itself is an ASN.1 object of 567 type "TimeResponseSecurityData", with the following structure: 569 TimeResponseSecurityData ::= 570 SEQUENCE { 571 nonce NTSNonce, 572 } 574 It is identified by the following object identifier: 576 id-ct-nts-securityDataResp OBJECT IDENTIFIER ::= TBD8 578 3.3. Broadcast Messages 580 3.3.1. Broadcast Parameter Messages 582 3.3.1.1. Message Type: "client_bpar" 584 This first broadcast message is structured according to the NTS-Plain 585 archetype. There is no data necessary besides that which is 586 transported in the NTS message object, which is an ASN.1 object of 587 type "BroadcastParameterRequest" and structured as follows: 589 BroadcastParameterRequest ::= 590 SEQUENCE { 591 nonce NTSNonce, 592 clientId SubjectKeyIdentifier 593 } 595 It is identified by the following object identifier: 597 id-ct-nts-broadcastParamReq OBJECT IDENTIFIER ::= TBD9 599 3.3.1.2. Message Type: "server_bpar" 601 This message is structured according to "NTS-Signed". It requires 602 additional data besides that which is transported in the NTS message 603 object, namely the signature is included in the appropriate field of 604 the "SignedData" CMS structure that the NTS message object is wrapped 605 in. The NTS message object itself is an ASN.1 object of type 606 "BroadcastParameterResponse" and structured as follows: 608 BroadcastParameterResponse ::= 609 SEQUENCE { 610 nonce NTSNonce, 611 oneWayAlgo1 DigestAlgorithmIdentifier, 612 oneWayAlgo2 DigestAlgorithmIdentifier, 613 lastKey OCTET STRING (SIZE (16)), 614 intervalDuration BIT STRING, 615 disclosureDelay INTEGER, 616 nextIntervalTime BIT STRING, 617 nextIntervalIndex INTEGER 618 } 620 It is identified by the following object identifier: 622 id-ct-nts-broadcastParamResp OBJECT IDENTIFIER ::= TBD10 624 3.3.2. Broadcast Time Synchronization Message 626 3.3.2.1. Message Type: "server_broad" 628 This message is structured according to the "NTS-Plain" archetype. 629 It requires regular broadcast time synchronization data in addition 630 to that which is carried in the NTS message object. Like 631 "time_response", this message type also requires a MAC, generated 632 over all other data, to be transported within the packet. The NTS 633 message object itself is an ASN.1 object of type "BroadcastTime". It 634 has the following structure: 636 BroadcastTime ::= 637 SEQUENCE { 638 thisIntervalIndex INTEGER, 639 disclosedKey OCTET STRING (SIZE (16)), 640 } 642 It is identified by the following object identifier: 644 id-ct-nts-broadcastTime OBJECT IDENTIFIER ::= TBD11 646 3.3.3. Broadcast Keycheck 648 3.3.3.1. Message Type: "client_keycheck" 650 This message is structured according to the "NTS-Plain" archetype. 651 There is no data necessary besides that which is transported in the 652 NTS message object, which is an ASN.1 object of type 653 "ClientKeyCheckSecurityData" and structured as follows: 655 ClientKeyCheckSecurityData ::= 656 SEQUENCE { 657 nonce_k NTSNonce, 658 interval_number INTEGER, 659 hmacHashAlgo DigestAlgorithmIdentifier, 660 keyInputValue OCTET STRING (SIZE(16)) 661 } 663 It is identified by the following object identifier: 665 id-ct-nts-clientKeyCheck OBJECT IDENTIFIER ::= TBD12 667 3.3.3.2. Message Type: "server_keycheck" 669 This message is also structured according to "NTS-Plain". It 670 requires only a MAC, generated over the NTS message object, to be 671 included in the packet in addition to what the NTS message object 672 itself contains. The latter is an ASN.1 object of type 673 "ServerKeyCheckSecurityData", which is structured as follows: 675 ServerKeyCheckSecurityData ::= 676 SEQUENCE { 677 nonce NTSNonce, 678 interval_number INTEGER 679 } 681 It is identified by the following object identifier: 683 id-ct-nts-serverKeyCheck OBJECT IDENTIFIER ::= TBD13 685 4. Certificate Conventions 687 The syntax and processing rules for certificates are specified in 688 [RFC5280]. In the NTS protocol, the server certificate MUST contain 689 the following extensions: 691 Subject Key Identifier -- see Section 4.2.1.2 of [RFC5280]. 693 Key Usage -- see Section 4.2.1.3 of [RFC5280]. 695 Extended Key Usage -- see Section 4.2.1.12 of [RFC5280]. 697 For a certificate issued to a time server, the Extended Key Usage 698 extension MAY include the id-kp-ntsServerAuth object identifier. 699 When a certificate issuer includes this object identifier in the 700 extended key usage extension, it provides an attestation that the 701 certificate subject is a time server that supports the NTS protocol. 702 The extension MAY also include the id-kp-ntsServerAuthz object 703 identifier. When a certificate issuer includes this object 704 identifier in the extended key usage extension, it provides an 705 attestation that the certificate subject is a time server which the 706 issuer believes to be willing and able to disseminate correct time 707 (for example, this can be used to signal a server's authorization to 708 disseminate legal time). 710 For a certificate issued to a time client, the Extended Key Usage 711 extension MAY include the id-kp-ntsClientAuthz object identifier. 712 When a certificate issuer includes this object identifier in the 713 extended key usage extension, it provides an attestation that the 714 certificate subject is a time client who has authorization from the 715 issuer to access secured time synchronization (for example, this can 716 be used to provide access in the case of a paid service for secure 717 time synchronization). 719 5. IANA Considerations 721 5.1. SMI Security for S/MIME Module Identifier Registry 723 Within the "SMI Security for S/MIME Module Identifier 724 (1.2.840.113549.1.9.16.0)" table, add one module identifier: 726 Decimal Description References 727 ------- -------------------------------------- ---------- 728 TBD0 id-networkTimeSecurity-2015 [this doc] 730 5.2. SMI Security for S/MIME CMS Content Type Registry 732 Within the "SMI Security for S/MIME CMS Content Type 733 (1.2.840.113549.1.9.16.1)" table, add thirteen content type 734 identifiers: 736 Decimal Description References 737 ------- -------------------------------------- ---------- 738 TBD1 id-ct-nts-clientAccess [this doc] 739 TBD2 id-ct-nts-serverAccess [this doc] 740 TBD3 id-ct-nts-clientAssoc [this doc] 741 TBD4 id-ct-nts-serverAssoc [this doc] 742 TBD5 id-ct-nts-clientCookie [this doc] 743 TBD6 id-ct-nts-serverCookie [this doc] 744 TBD7 id-ct-nts-securityDataReq [this doc] 745 TBD8 id-ct-nts-securityDataResp [this doc] 746 TBD9 id-ct-nts-broadcastParamReq [this doc] 747 TBD10 id-ct-nts-broadcastParamResp [this doc] 748 TBD11 id-ct-nts-broadcastTime [this doc] 749 TBD12 id-ct-nts-clientKeyCheck [this doc] 750 TBD13 id-ct-nts-serverKeyCheck [this doc] 752 5.3. SMI Security for PKIX Extended Key Purpose Registry 754 Within the "SMI Security for PKIX Extended Key Purpose Identifiers 755 (1.3.6.1.5.5.7.3)" table, add three key purpose identifiers: 757 Decimal Description References 758 ------- -------------------------------------- ---------- 759 TBD14 id-kp-ntsServerAuth [this doc] 760 TBD15 id-kp-ntsServerAuthz [this doc] 761 TBD16 id-kp-ntsClientAuthz [this doc] 763 6. Security Considerations 765 For authentication the server's certificate MAY contain an extended 766 key purpose identifier (id-kp-ntsServerAuth). Additionally the 767 identifiers id-kp-ntsServerAuthz and id-kp-ntsClientAuthz MAY be used 768 to grant the associated roles to the certified entity in the time 769 dissemination infrastructure (see also Appendix D in 770 [I-D.ietf-ntp-network-time-security]). 772 7. Acknowledgements 774 The authors would like to thank Harlan Stenn, Richard Welty and 775 Martin Langer for their technical review and specific text 776 contributions to this document. 778 8. References 780 8.1. Normative References 782 [ASN1] International Telecommunication Union, "Abstract Syntax 783 Notation One (ASN.1): Specification of basic notation", 784 ITU-T Recommendation X.680, November 2008. 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 788 RFC2119, March 1997, 789 . 791 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 792 Housley, R., and W. Polk, "Internet X.509 Public Key 793 Infrastructure Certificate and Certificate Revocation List 794 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 795 . 797 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 798 RFC 5652, DOI 10.17487/RFC5652, September 2009, 799 . 801 8.2. Informative References 803 [I-D.ietf-ntp-network-time-security] 804 Sibold, D., Roettger, S., and K. Teichel, "Network Time 805 Security", draft-ietf-ntp-network-time-security-13 (work 806 in progress), February 2016. 808 [IEEE1588] 809 IEEE Instrumentation and Measurement Society. TC-9 Sensor 810 Technology, "IEEE standard for a precision clock 811 synchronization protocol for networked measurement and 812 control systems", 2008. 814 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 815 "Network Time Protocol Version 4: Protocol and Algorithms 816 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 817 . 819 Appendix A. ASN.1 Module 821 The ASN.1 module contained in this appendix defines the id-kp- 822 NTSserver object identifier. 824 NTSserverKeyPurpose 825 { TBD } 827 DEFINITIONS IMPLICIT TAGS ::= 828 BEGIN 830 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD17 } 832 END 834 Authors' Addresses 836 Dieter Sibold 837 Physikalisch-Technische Bundesanstalt 838 Bundesallee 100 839 Braunschweig D-38116 840 Germany 842 Phone: +49-(0)531-592-8420 843 Fax: +49-531-592-698420 844 Email: dieter.sibold@ptb.de 845 Kristof Teichel 846 Physikalisch-Technische Bundesanstalt 847 Bundesallee 100 848 Braunschweig D-38116 849 Germany 851 Phone: +49-(0)531-592-8421 852 Email: kristof.teichel@ptb.de 854 Stephen Roettger 855 Google Inc. 857 Email: stephen.roettger@googlemail.com 859 Russ Housley 860 Vigil Security 861 918 Spring Knoll Drive 862 Herndon, VA 20170 864 Email: housley@vigilsec.com