idnits 2.17.1 draft-ietf-ntp-cms-for-nts-message-05.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 (January 26, 2016) is 3014 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-12 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: July 29, 2016 S. Roettger 6 Google Inc. 7 R. Housley 8 Vigil Security 9 January 26, 2016 11 Protecting Network Time Security Messages with the Cryptographic Message 12 Syntax (CMS) 13 draft-ietf-ntp-cms-for-nts-message-05 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 July 29, 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. Association Messages . . . . . . . . . . . . . . . . 9 73 3.2.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10 74 3.2.3. Time Synchronization Messages . . . . . . . . . . . . 11 75 3.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12 76 3.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 12 77 3.3.2. Broadcast Time Synchronization Message . . . . . . . 13 78 3.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 14 79 4. Certificate Conventions . . . . . . . . . . . . . . . . . . . 15 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 5.1. SMI Security for S/MIME Module Identifier Registry . . . 15 82 5.2. SMI Security for S/MIME CMS Content Type Registry . . . . 16 83 5.3. SMI Security for PKIX Extended Key Purpose Registry . . . 16 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 7.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 This document provides details on how to construct NTS messages in 94 practice. NTS provides secure time synchronization with time servers 95 using Network Time Protocol (NTP) [RFC5905] or Precision Time 96 Protocol (PTP) [IEEE1588]. Among other things, this document 97 describes a convention for using the Cryptographic Message Syntax 98 (CMS) [RFC5652] to protect messages in the Network Time Security 99 (NTS) protocol. Encryption is used to provide confidentiality of 100 secrets, and digital signatures are used to provide authentication 101 and integrity of content. 103 Sometimes CMS is used in an exclusively ASN.1 [ASN1] environment. In 104 this case, the NTS message may use any syntax that facilitates easy 105 implementation. 107 2. CMS Conventions for NTS Message Protection 109 Regarding the usage of CMS, we differentiate between three archetypes 110 according to which the NTS message types can be structured. They are 111 presented below. Note that the NTS Message Object that is at the 112 core of each structure does not necessarily contain all the data 113 needed for the particular message type, but may contain only that 114 data which needs to be secured directly with cryptographic operations 115 using the CMS. Specific information about what is included can be 116 found in Section 3. 118 NTS-Plain: This archetype is used for actual time synchronization 119 messages (explicitly, the following message types: time_request, 120 time_response, server_broad, see 121 [I-D.ietf-ntp-network-time-security], Section 6) as well as for 122 client-side messages of all unicast and broadcast bootstrapping 123 exchanges (explicitly client_assoc, client_cook and client_bpar) 124 as well as the broadcast keycheck exchange (client_keycheck and 125 server_keycheck). This archetype does not make use of any CMS 126 structures at all. Figure 1 illustrates this structure. 128 +-----------------------------------------------------+ 129 | | 130 | NTS Message Object | 131 | | 132 | | 133 +-----------------------------------------------------+ 135 NTS-Encrypted-and-Signed: This archetype is used for secure 136 transmission of the cookie (only for the server_cook message type, 137 see [I-D.ietf-ntp-network-time-security], Section 6). For this, 138 the following CMS structure is used: 140 First, the NTS message MUST be encrypted using the 141 EnvelopedData content type. EnvelopedData supports nearly any 142 form of key management. In the NTS protocol the client 143 provides a certificate in an unprotected message, and the 144 public key from this certificate, if it is valid, will be used 145 to establish a pairwise symmetric key for the encryption of the 146 protected NTS message. 148 Second, the EnvelopedData content MUST be digitally signed 149 using the SignedData content type. SignedData supports nearly 150 any form of digital signature, and in the NTS protocol the 151 server will include its certificate within the SignedData 152 content type. 154 Third, the SignedData content type MUST be encapsulated in a 155 ContentInfo content type. 157 Figure 2 illustrates this structure. 159 +---------------------------------------------------------+ 160 | | 161 | ContentInfo | 162 | | 163 | +-----------------------------------------------------+ | 164 | | | | 165 | | SignedData | | 166 | | | | 167 | | +-------------------------------------------------+ | | 168 | | | | | | 169 | | | EnvelopedData | | | 170 | | | | | | 171 | | | +---------------------------------------------+ | | | 172 | | | | | | | | 173 | | | | NTS Message Object | | | | 174 | | | | | | | | 175 | | | | | | | | 176 | | | +---------------------------------------------+ | | | 177 | | | | | | 178 | | +-------------------------------------------------+ | | 179 | | | | 180 | +-----------------------------------------------------+ | 181 | | 182 +---------------------------------------------------------+ 184 NTS-Signed: This archetype is used for server_assoc and server_bpar 185 message types. It uses the following CMS structure: 187 First, the NTS message object MUST be wrapped in a SignedData 188 content type. The messages MUST be digitally signed, and 189 certificates included. SignedData supports nearly any form of 190 digital signature, and in the NTS protocol the server will 191 include its certificate within the SignedData content type. 193 Second, the SignedData content type MUST be encapsulated in a 194 ContentInfo content type. 196 Figure 3 illustrates this structure. 198 +---------------------------------------------------------+ 199 | | 200 | ContentInfo | 201 | | 202 | +-----------------------------------------------------+ | 203 | | | | 204 | | SignedData | | 205 | | | | 206 | | +-------------------------------------------------+ | | 207 | | | | | | 208 | | | NTS Message Object | | | 209 | | | | | | 210 | | | | | | 211 | | +-------------------------------------------------+ | | 212 | | | | 213 | +-----------------------------------------------------+ | 214 | | 215 +---------------------------------------------------------+ 217 2.1. Fields of the employed CMS Content Types 219 Overall, three CMS content types are used for NTS messages by the 220 archetypes above. Explicitly, those content types are ContentInfo, 221 SignedData and EnvelopedData. The following is a description of how 222 the fields of those content types are used in detail. 224 2.1.1. ContentInfo 226 The ContentInfo content type is used in all archetypes except NTS- 227 Plain. The fields of the ContentInfo content type are used as 228 follows: 230 contentType -- indicates the type of the associated content. For 231 all archetypes which use ContentInfo (these are NTS-Signed and 232 NTS-Encrypted-and-Signed), it MUST contain the object identifier 233 for the SignedData content type: 235 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 236 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 238 content -- is the associated content. For all archetypes using 239 ContentInfo, it MUST contain the DER encoded SignedData content 240 type. 242 2.1.2. SignedData 244 The SignedData content type is used in the NTS-Signed and NTS- 245 Encrypted-and-Signed archetypes, but not in the NTS-Plain archetype. 246 The fields of the SignedData content type are used as follows: 248 version -- the appropriate value depends on the optional items 249 that are included. In the NTS protocol, the signer certificate 250 MUST be included and other items MAY be included. The 251 instructions in [RFC5652] Section 5.1 MUST be followed to set the 252 correct value. 254 digestAlgorithms -- is a collection of message digest algorithm 255 identifiers. In the NTS protocol, there MUST be exactly one 256 algorithm identifier present. The instructions in Section 5.4 of 257 [RFC5652] MUST be followed. 259 encapContentInfo -- this structure is always present. In the NTS 260 protocol, it MUST follow these conventions: 262 eContentType -- is an object identifier. In the NTS protocol, 263 for the NTS-Signed archetype, it MUST identify the type of the 264 NTS message that was encapsulated. For the NTS-Encrypted-and- 265 Signed archetype, it MUST contain the object identifier for the 266 EnvelopedData content type: 268 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 269 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }. 271 eContent is the content itself, carried as an octet string. 272 For the NTS-Signed archetype, it MUST contain the DER encoded 273 encapsulated NTS message object. The instructions in 274 Section 6.3 of [RFC5652] MUST be followed. For the NTS- 275 Encrypted-and-Signed archetype, it MUST contain the DER encoded 276 EnvelopedData content type. 278 certificates -- is a collection of certificates. In the NTS 279 protocol, it MUST contain the DER encoded certificate [RFC5280] of 280 the sender. It is intended that the collection of certificates be 281 sufficient for the recipient to construct a certification path 282 from a recognized "root" or "top-level certification authority" to 283 the certificate used by the sender. 285 crls -- is a collection of revocation status information. In the 286 NTS protocol, it MAY contain one or more DER encoded CRLs 287 [RFC5280]. It is intended that the collection contain information 288 sufficient to determine whether the certificates in the 289 certificates field are valid. 291 signerInfos -- is a collection of per-signer information. In the 292 NTS protocol, for the NTS-Signed and the NTS-Encrypted-and-Signed 293 archetypes, there MUST be exactly one SignerInfo structure 294 present. The details of the SignerInfo type are discussed in 295 Section 5.3 of [RFC5652]. In the NTS protocol, it MUST follow 296 these conventions: 298 version -- is the syntax version number. In the NTS protocol, 299 the SignerIdentifier is subjectKeyIdentifier, therefore the 300 version MUST be 3. 302 sid -- identifies the signer's certificate. In the NTS 303 protocol, the "sid" field contains the subjectKeyIdentifier 304 from the signer's certificate. 306 digestAlgorithm -- identifies the message digest algorithm and 307 any associated parameters used by the signer. In the NTS 308 protocol, the identifier MUST match the single algorithm 309 identifier present in the digestAlgorithms. 311 signedAttrs -- is a collection of attributes that are signed. 312 In the NTS protocol, it MUST be present, and it MUST contain 313 the following attributes: 315 Content Type -- see Section 11.1 of [RFC5652]. 317 Message Digest -- see Section 11.2 of [RFC5652]. 319 In addition, it MAY contain the following attributes: 321 Signing Time -- see Section 11.3 of [RFC5652]. 323 Binary Signing Time -- see Section 3 of [RFC5652]. 325 signatureAlgorithm -- identifies the signature algorithm and 326 any associated parameters used by the signer to generate the 327 digital signature. 329 signature is the result of digital signature generation using 330 the message digest and the signer's private key. The 331 instructions in Section 5.5 of [RFC5652] MUST be followed. 333 unsignedAttrs -- is an optional collection of attributes that 334 are not signed. In the NTS protocol, it MUST be absent. 336 2.1.3. EnvelopedData 338 The EnvelopedData content type is used only in the NTS-Encrypted-and- 339 Signed archetype. The fields of the EnvelopedData content type are 340 used as follows: 342 version -- the appropriate value depends on the type of key 343 management that is used. The instructions in [RFC5652] 344 Section 6.1 MUST be followed to set the correct value. 346 originatorInfo -- this structure is present only if required by 347 the key management algorithm. In the NTS protocol, it MUST be 348 present when a key agreement algorithm is used, and it MUST be 349 absent when a key transport algorithm is used. The instructions 350 in Section 6.1 of [RFC5652] MUST be followed. 352 recipientInfos -- this structure is always present. In the NTS 353 protocol, it MUST contain exactly one entry that allows the client 354 to determine the key used to encrypt the NTS message. The 355 instructions in Section 6.2 of [RFC5652] MUST be followed. 357 encryptedContentInfo -- this structure is always present. In the 358 NTS protocol, it MUST follow these conventions: 360 contentType -- indicates the type of content. In the NTS 361 protocol, it MUST identify the type of the NTS message that was 362 encrypted. 364 contentEncryptionAlgorithm -- identifies the content-encryption 365 algorithm and any associated parameters used to encrypt the 366 content. 368 encryptedContent -- is the encrypted content. In the NTS 369 protocol, it MUST contain the encrypted NTS message. The 370 instructions in Section 6.3 of [RFC5652] MUST be followed. 372 unprotectedAttrs -- this structure is optional. In the NTS 373 protocol, it MUST be absent. 375 3. Implementation Notes: ASN.1 Structures and Use of the CMS 377 This section presents some hints about the structures of the NTS 378 message objects for the different message types when one wishes to 379 implement the security mechanisms. 381 3.1. Preliminaries 383 The following ASN.1 coded data types "NTSNonce" and "NTSVersion" are 384 needed for other types used below for NTS messages. "NTSNonce" 385 specifies a 128 bit nonce as required in several message types: 387 NTSNonce ::= OCTET STRING (SIZE(16)) 389 "NTSVersion" specifies a version number, which is required for 390 version negotiation. 392 NTSVersion ::= INTEGER (0..255) 394 The following ASN.1 coded data types are also necessary for other 395 types. 397 KeyEncryptionAlgorithmIdentifiers ::= 398 SET OF KeyEncryptionAlgorithmIdentifier 400 ContentEncryptionAlgorithmIdentifiers ::= 401 SET OF ContentEncryptionAlgorithmIdentifier 403 3.2. Unicast Messages 405 3.2.1. Association Messages 407 3.2.1.1. Message Type: "client_assoc" 409 This message is structured according to the NTS-Plain archetype. 410 There is no data necessary besides that which is transported in the 411 NTS message object, which is an ASN.1 object of type 412 "ClientAssocData" and structured as follows: 414 ClientAssocData ::= SEQUENCE { 415 nonce NTSNonce, 416 minVersion NTSVersion, 417 clientId SubjectKeyIdentifier, 418 hmacHashAlgos DigestAlgorithmIdentifiers, 419 keyEncAlgos KeyEncryptionAlgorithmIdentifiers, 420 contentEncAlgos ContentEncryptionAlgorithmIdentifiers 421 } 422 It is identified by the following object identifier (fictional 423 values): 425 id-ct-nts-clientAssoc OBJECT IDENTIFIER ::= TBD1 427 3.2.1.2. Message Type: "server_assoc" 429 This message is structured according to the NTS-Signed archetype. It 430 requires additional data besides that which is transported in the NTS 431 message object, namely the signature and certificate chain are 432 included in the appropriate fields of the "SignedData" CMS structure 433 that the NTS message object is wrapped in. The NTS message object 434 itself is an ASN.1 object of type "ServerAssocData" and structured as 435 follows: 437 ServerAssocData ::= SEQUENCE { 438 nonce NTSNonce, 439 proposedVersion NTSVersion, 440 clientId SubjectKeyIdentifier, 441 hmacHashAlgos DigestAlgorithmIdentifiers, 442 choiceHmacHashAlgo DigestAlgorithmIdentifier, 443 keyEncAlgos KeyEncryptionAlgorithmIdentifiers, 444 choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, 445 contentEncAlgos ContentEncryptionAlgorithmIdentifiers, 446 choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier 447 } 449 It is identified by the following object identifier (fictional 450 values): 452 id-ct-nts-serverAssoc OBJECT IDENTIFIER ::= TBD2 454 3.2.2. Cookie Messages 456 3.2.2.1. Message Type: "client_cook" 458 This message is structured according to the NTS-Plain archetype. It 459 requires no additional data besides that which is transported in the 460 NTS message object. The NTS message object itself is an ASN.1 object 461 of type "ClientCookieData" and structured as follows: 463 ClientCookieData ::= SEQUENCE { 464 nonce NTSNonce, 465 signAlgo SignatureAlgorithmIdentifier, 466 hmacHashAlgo DigestAlgorithmIdentifier, 467 encAlgo ContentEncryptionAlgorithmIdentifier, 468 keyEncAlgo KeyEncryptionAlgorithmIdentifier, 469 certificates CertificateSet 470 } 472 It is identified by the following object identifier (fictional 473 values): 475 id-ct-nts-clientCookie OBJECT IDENTIFIER ::= TBD3 477 3.2.2.2. Message Type: "server_cook" 479 This message is structured according to the "NTS-Encrypted-and- 480 Signed" archetype. It requires additional data besides that which is 481 transported in the NTS message object, namely the signature is 482 included in the appropriate field of the "SignedData" CMS structure 483 that the NTS message object is wrapped in. The NTS message object 484 itself is an ASN.1 sequence of type "ServerCookieData" and structured 485 as follows: 487 ServerCookieData ::= SEQUENCE { 488 nonce NTSNonce, 489 cookie OCTET STRING (SIZE(16)) 490 } 492 It is identified by the following object identifier (fictional 493 values): 495 id-ct-nts-serverCookie OBJECT IDENTIFIER ::= TBD4 497 3.2.3. Time Synchronization Messages 499 3.2.3.1. Message Type: "time_request" 501 This message is structured according to the "NTS-Plain" archetype. 503 This message type requires additional data to that which is included 504 in the NTS message object, namely it requires regular time 505 synchronization data, as an unsecured packet from a client to a 506 server would contain. Optionally, it requires the Message 507 Authentication Code (MAC) to be generated over the whole rest of the 508 packet (including the NTS message object) and transported in some 509 way. The NTS message object itself is an ASN.1 object of type 510 "TimeRequestSecurityData", whose structure is as follows: 512 TimeRequestSecurityData ::= 513 SEQUENCE { 514 nonce NTSNonce, 515 hmacHashAlgo DigestAlgorithmIdentifier, 516 keyInputValue OCTET STRING (SIZE(16)) 517 } 519 It is identified by the following object identifier (fictional 520 values): 522 id-ct-nts-securityDataReq OBJECT IDENTIFIER ::= TBD5 524 3.2.3.2. Message Type: "time_response" 526 This message is structured according to the "NTS-Plain" archetype. 528 It requires two items of data in addition to that which is 529 transported in the NTS message object. Like "time_request", it 530 requires regular time synchronization data. Furthermore, it requires 531 the Message Authentication Code (MAC) to be generated over the whole 532 rest of the packet (including the NTS message object) and transported 533 in some way. The NTS message object itself is an ASN.1 object of 534 type "TimeResponseSecurityData", with the following structure: 536 TimeResponseSecurityData ::= 537 SEQUENCE { 538 nonce NTSNonce, 539 } 541 It is identified by the following object identifier (fictional 542 values): 544 id-ct-nts-securityDataResp OBJECT IDENTIFIER ::= TBD6 546 3.3. Broadcast Messages 548 3.3.1. Broadcast Parameter Messages 550 3.3.1.1. Message Type: "client_bpar" 552 This first broadcast message is structured according to the NTS-Plain 553 archetype. There is no data necessary besides that which is 554 transported in the NTS message object, which is an ASN.1 object of 555 type "BroadcastParameterRequest" and structured as follows: 557 BroadcastParameterRequest ::= 558 SEQUENCE { 559 nonce NTSNonce, 560 clientId SubjectKeyIdentifier 561 } 563 It is identified by the following object identifier (fictional 564 values): 566 id-ct-nts-broadcastParamReq OBJECT IDENTIFIER ::= TBD7 568 3.3.1.2. Message Type: "server_bpar" 570 This message is structured according to "NTS-Signed". It requires 571 additional data besides that which is transported in the NTS message 572 object, namely the signature is included in the appropriate field of 573 the "SignedData" CMS structure that the NTS message object is wrapped 574 in. The NTS message object itself is an ASN.1 object of type 575 "BroadcastParameterResponse" and structured as follows: 577 BroadcastParameterResponse ::= 578 SEQUENCE { 579 nonce NTSNonce, 580 oneWayAlgo1 DigestAlgorithmIdentifier, 581 oneWayAlgo2 DigestAlgorithmIdentifier, 582 lastKey OCTET STRING (SIZE (16)), 583 intervalDuration BIT STRING, 584 disclosureDelay INTEGER, 585 nextIntervalTime BIT STRING, 586 nextIntervalIndex INTEGER 587 } 589 It is identified by the following object identifier (fictional 590 values): 592 id-ct-nts-broadcastParamResp OBJECT IDENTIFIER ::= TBD8 594 3.3.2. Broadcast Time Synchronization Message 596 3.3.2.1. Message Type: "server_broad" 598 This message is structured according to the "NTS-Plain" archetype. 599 It requires regular broadcast time synchronization data in addition 600 to that which is carried in the NTS message object. Like 601 "time_response", this message type also requires a MAC, generated 602 over all other data, to be transported within the packet. The NTS 603 message object itself is an ASN.1 object of type "BroadcastTime". It 604 has the following structure: 606 BroadcastTime ::= 607 SEQUENCE { 608 thisIntervalIndex INTEGER, 609 disclosedKey OCTET STRING (SIZE (16)), 610 } 612 It is identified by the following object identifier (fictional 613 values): 615 id-ct-nts-broadcastTime OBJECT IDENTIFIER ::= TBD9 617 3.3.3. Broadcast Keycheck 619 3.3.3.1. Message Type: "client_keycheck" 621 This message is structured according to the "NTS-Plain" archetype. 622 There is no data necessary besides that which is transported in the 623 NTS message object, which is an ASN.1 object of type 624 "ClientKeyCheckSecurityData" and structured as follows: 626 ClientKeyCheckSecurityData ::= 627 SEQUENCE { 628 nonce_k NTSNonce, 629 interval_number INTEGER, 630 hmacHashAlgo DigestAlgorithmIdentifier, 631 keyInputValue OCTET STRING (SIZE(16)) 632 } 634 It is identified by the following object identifier (fictional 635 values): 637 id-ct-nts-clientKeyCheck OBJECT IDENTIFIER ::= TBD10 639 3.3.3.2. Message Type: "server_keycheck" 641 This message is also structured according to "NTS-Plain". It 642 requires only a MAC, generated over the NTS message object, to be 643 included in the packet in addition to what the NTS message object 644 itself contains. The latter is an ASN.1 object of type 645 "ServerKeyCheckSecurityData", which is structured as follows: 647 ServerKeyCheckSecurityData ::= 648 SEQUENCE { 649 nonce NTSNonce, 650 interval_number INTEGER 651 } 653 It is identified by the following object identifier: 655 id-ct-nts-serverKeyCheck OBJECT IDENTIFIER ::= TBD11 657 4. Certificate Conventions 659 The syntax and processing rules for certificates are specified in 660 [RFC5280]. In the NTS protocol, the server certificate MUST contain 661 the following extensions: 663 Subject Key Identifier -- see Section 4.2.1.2 of [RFC5280]. 665 Key Usage -- see Section 4.2.1.3 of [RFC5280]. 667 Extended Key Usage -- see Section 4.2.1.12 of [RFC5280]. 669 For a certificate issued to a time server, the Extended Key Usage 670 extension MAY include the id-kp-ntsServerAuth object identifier. 671 When a certificate issuer includes this object identifier in the 672 extended key usage extension, it provides an attestation that the 673 certificate subject is a time server that supports the NTS protocol. 674 The extension MAY also include the id-kp-ntsServerAuthz object 675 identifier. When a certificate issuer includes this object 676 identifier in the extended key usage extension, it provides an 677 attestation that the certificate subject is a time server which the 678 issuer believes to be willing and able to disseminate correct time 679 (for example, this can be used to signal a server's authorization to 680 disseminate legal time). 682 For a certificate issued to a time client, the Extended Key Usage 683 extension MAY include the id-kp-ntsClientAuthz object identifier. 684 When a certificate issuer includes this object identifier in the 685 extended key usage extension, it provides an attestation that the 686 certificate subject is a time client who has authorization from the 687 issuer to access secured time synchronization (for example, this can 688 be used to provide access in the case of a paid service for secure 689 time synchronization). 691 5. IANA Considerations 693 5.1. SMI Security for S/MIME Module Identifier Registry 695 Within the "SMI Security for S/MIME Module Identifier 696 (1.2.840.113549.1.9.16.0)" table, add one module identifier: 698 Decimal Description References 699 ------- -------------------------------------- ---------- 700 TBD0 id-networkTimeSecurity-2015 [this doc] 702 5.2. SMI Security for S/MIME CMS Content Type Registry 704 Within the "SMI Security for S/MIME CMS Content Type 705 (1.2.840.113549.1.9.16.1)" table, add eleven content type 706 identifiers: 708 Decimal Description References 709 ------- -------------------------------------- ---------- 710 TBD1 id-ct-nts-clientAssoc [this doc] 711 TBD2 id-ct-nts-serverAssoc [this doc] 712 TBD3 id-ct-nts-clientCookie [this doc] 713 TBD4 id-ct-nts-serverCookie [this doc] 714 TBD5 id-ct-nts-securityDataReq [this doc] 715 TBD6 id-ct-nts-securityDataResp [this doc] 716 TBD7 id-ct-nts-broadcastParamReq [this doc] 717 TBD8 id-ct-nts-broadcastParamResp [this doc] 718 TBD9 id-ct-nts-broadcastTime [this doc] 719 TBD10 id-ct-nts-clientKeyCheck [this doc] 720 TBD11 id-ct-nts-serverKeyCheck [this doc] 722 5.3. SMI Security for PKIX Extended Key Purpose Registry 724 Within the "SMI Security for PKIX Extended Key Purpose Identifiers 725 (1.3.6.1.5.5.7.3)" table, add three key purpose identifiers: 727 Decimal Description References 728 ------- -------------------------------------- ---------- 729 TBD12 id-kp-ntsServerAuth [this doc] 730 TBD13 id-kp-ntsServerAuthz [this doc] 731 TBD14 id-kp-ntsClientAuthz [this doc] 733 6. Security Considerations 735 To be written. 737 7. References 739 7.1. Normative References 741 [ASN1] International Telecommunication Union, "Abstract Syntax 742 Notation One (ASN.1): Specification of basic notation", 743 ITU-T Recommendation X.680, November 2008. 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 747 RFC2119, March 1997, 748 . 750 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 751 Housley, R., and W. Polk, "Internet X.509 Public Key 752 Infrastructure Certificate and Certificate Revocation List 753 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 754 . 756 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 757 RFC 5652, DOI 10.17487/RFC5652, September 2009, 758 . 760 7.2. Informative References 762 [I-D.ietf-ntp-network-time-security] 763 Sibold, D., Roettger, S., and K. Teichel, "Network Time 764 Security", draft-ietf-ntp-network-time-security-12 (work 765 in progress), December 2015. 767 [IEEE1588] 768 IEEE Instrumentation and Measurement Society. TC-9 Sensor 769 Technology, "IEEE standard for a precision clock 770 synchronization protocol for networked measurement and 771 control systems", 2008. 773 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 774 "Network Time Protocol Version 4: Protocol and Algorithms 775 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 776 . 778 Appendix A. ASN.1 Module 780 The ASN.1 module contained in this appendix defines the id-kp- 781 NTSserver object identifier. 783 NTSserverKeyPurpose 784 { TBD } 786 DEFINITIONS IMPLICIT TAGS ::= 787 BEGIN 789 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 791 END 793 Authors' Addresses 794 Dieter Sibold 795 Physikalisch-Technische Bundesanstalt 796 Bundesallee 100 797 Braunschweig D-38116 798 Germany 800 Phone: +49-(0)531-592-8420 801 Fax: +49-531-592-698420 802 Email: dieter.sibold@ptb.de 804 Kristof Teichel 805 Physikalisch-Technische Bundesanstalt 806 Bundesallee 100 807 Braunschweig D-38116 808 Germany 810 Phone: +49-(0)531-592-8421 811 Email: kristof.teichel@ptb.de 813 Stephen Roettger 814 Google Inc. 816 Email: stephen.roettger@googlemail.com 818 Russ Housley 819 Vigil Security 820 918 Spring Knoll Drive 821 Herndon, VA 20170 823 Email: housley@vigilsec.com