idnits 2.17.00 (12 Aug 2021) /tmp/idnits55920/draft-ietf-ntp-cms-for-nts-message-04.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 (July 06, 2015) is 2510 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) == Missing Reference: 'RFC5280' is mentioned on line 291, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' == Outdated reference: A later version (-15) exists of draft-ietf-ntp-network-time-security-08 Summary: 0 errors (**), 0 flaws (~~), 3 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: January 7, 2016 S. Roettger 6 Google Inc. 7 R. Housley 8 Vigil Security 9 July 06, 2015 11 Protecting Network Time Security Messages with the Cryptographic Message 12 Syntax (CMS) 13 draft-ietf-ntp-cms-for-nts-message-04 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 January 7, 2016. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . 14 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 7.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 This document provides details on how to construct NTS messages in 91 practice. NTS provides secure time synchronization with time servers 92 using Network Time Protocol (NTP) [RFC5905] or Precision Time 93 Protocol (PTP) [IEEE1588]. Among other things, this document 94 describes a convention for using the Cryptographic Message Syntax 95 (CMS) [RFC5652] to protect messages in the Network Time Security 96 (NTS) protocol. Encryption is used to provide confidentiality of 97 secrets, and digital signatures are used to provide authentication 98 and integrity of content. 100 Sometimes CMS is used in an exclusively ASN.1 [ASN1] environment. In 101 this case, the NTS message may use any syntax that facilitates easy 102 implementation. 104 2. CMS Conventions for NTS Message Protection 106 Regarding the usage of CMS, we differentiate between four archetypes 107 according to which the NTS message types can be structured. They are 108 presented below. Note that the NTS Message Object that is at the 109 core of each structure does not necessarily contain all the data 110 needed for the particular message type, but may contain only that 111 data which needs to be secured directly with cryptographic operations 112 using the CMS. Specific information about what is included can be 113 found in Section 3. 115 NTS-Plain: This archetype is used for actual time synchronization 116 messages (explicitly, the following message types: time_request, 117 time_response, server_broad, see 118 [I-D.ietf-ntp-network-time-security], Section 6) as well as for 119 the very first messages of a unicast or a broadcast exchange 120 (client_assoc or client_bpar, respectively) and the broadcast 121 keycheck exchange (client_keycheck and server_keycheck). This 122 archetype does not make use of any CMS structures at all. 123 Figure 1 illustrates this structure. 125 +-----------------------------------------------------+ 126 | | 127 | NTS Message Object | 128 | | 129 | | 130 +-----------------------------------------------------+ 132 NTS-Encrypted-and-Signed: This archetype is used for secure 133 transmission of the cookie (only for the server_cook message type, 134 see [I-D.ietf-ntp-network-time-security], Section 6). For this, 135 the following CMS structure is used: 137 First, the NTS message MUST be encrypted using the 138 EnvelopedData content type. EnvelopedData supports nearly any 139 form of key management. In the NTS protocol the client 140 provides a certificate in an unprotected message, and the 141 public key from this certificate, if it is valid, will be used 142 to establish a pairwise symmetric key for the encryption of the 143 protected NTS message. 145 Second, the EnvelopedData content MUST be digitally signed 146 using the SignedData content type. SignedData supports nearly 147 any form of digital signature, and in the NTS protocol the 148 server will include its certificate within the SignedData 149 content type. 151 Third, the SignedData content type MUST be encapsulated in a 152 ContentInfo content type. 154 Figure 2 illustrates this structure. 156 +---------------------------------------------------------+ 157 | | 158 | ContentInfo | 159 | | 160 | +-----------------------------------------------------+ | 161 | | | | 162 | | SignedData | | 163 | | | | 164 | | +-------------------------------------------------+ | | 165 | | | | | | 166 | | | EnvelopedData | | | 167 | | | | | | 168 | | | +---------------------------------------------+ | | | 169 | | | | | | | | 170 | | | | NTS Message Object | | | | 171 | | | | | | | | 172 | | | | | | | | 173 | | | +---------------------------------------------+ | | | 174 | | | | | | 175 | | +-------------------------------------------------+ | | 176 | | | | 177 | +-----------------------------------------------------+ | 178 | | 179 +---------------------------------------------------------+ 181 NTS-Signed: This archetype is used for server_assoc and server_bpar 182 message types. It uses the following CMS structure: 184 First, the NTS message object MUST be wrapped in a SignedData 185 content type. The messages MUST be digitally signed, and 186 certificates included. SignedData supports nearly any form of 187 digital signature, and in the NTS protocol the server will 188 include its certificate within the SignedData content type. 190 Second, the SignedData content type MUST be encapsulated in a 191 ContentInfo content type. 193 Figure 3 illustrates this structure. 195 +---------------------------------------------------------+ 196 | | 197 | ContentInfo | 198 | | 199 | +-----------------------------------------------------+ | 200 | | | | 201 | | SignedData | | 202 | | | | 203 | | +-------------------------------------------------+ | | 204 | | | | | | 205 | | | NTS Message Object | | | 206 | | | | | | 207 | | | | | | 208 | | +-------------------------------------------------+ | | 209 | | | | 210 | +-----------------------------------------------------+ | 211 | | 212 +---------------------------------------------------------+ 214 NTS-Certified: This archetype is used for the client_cook message 215 type. It uses a CMS structure much like the NTS-Signed archetype 216 (see Figure 3), with the only difference being that messages 217 SHOULD NOT be digitally signed. This archetype employs the CMS 218 structure merely in order to transport certificates. 220 2.1. Fields of the employed CMS Content Types 222 Overall, three CMS content types are used for NTS messages by the 223 archetypes above. Explicitly, those content types are ContentInfo, 224 SignedData and EnvelopedData. The following is a description of how 225 the fields of those content types are used in detail. 227 2.1.1. ContentInfo 229 The ContentInfo content type is used in all archetypes except NTS- 230 Plain. The fields of the ContentInfo content type are used as 231 follows: 233 contentType -- indicates the type of the associated content. For 234 all archetypes which use ContentInfo (these are NTS-Certified, 235 NTS-Signed and NTS-Encrypted-and-Signed), it MUST contain the 236 object identifier for the SignedData content type: 238 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 239 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 241 content -- is the associated content. For all archetypes using 242 ContentInfo, it MUST contain the DER encoded SignedData content 243 type. 245 2.1.2. SignedData 247 The SignedData content type is used in the NTS-Certified, NTS-Signed 248 and NTS-Encrypted-and-Signed archetypes, but not in the NTS-Plain 249 archetype. The fields of the SignedData content type are used as 250 follows: 252 version -- the appropriate value depends on the optional items 253 that are included. In the NTS protocol, the signer certificate 254 MUST be included and other items MAY be included. The 255 instructions in [RFC5652] Section 5.1 MUST be followed to set the 256 correct value. 258 digestAlgorithms -- is a collection of message digest algorithm 259 identifiers. In the NTS protocol, there MUST be exactly one 260 algorithm identifier present. The instructions in Section 5.4 of 261 [RFC5652] MUST be followed. 263 encapContentInfo -- this structure is always present. In the NTS 264 protocol, it MUST follow these conventions: 266 eContentType -- is an object identifier. In the NTS protocol, 267 for the NTS-Certified and NTS-Signed archetypes, it MUST 268 identify the type of the NTS message that was encapsulated. 269 For the NTS-Encrypted-and-Signed archetype, it MUST contain the 270 object identifier for the EnvelopedData content type: 272 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 273 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }. 275 eContent is the content itself, carried as an octet string. 276 For the NTS-Certified and NTS-Signed archetypes, it MUST 277 contain the DER encoded encapsulated NTS message object. The 278 instructions in Section 6.3 of [RFC5652] MUST be followed. For 279 the NTS-Encrypted-and-Signed archetype, it MUST contain the DER 280 encoded EnvelopedData content type. 282 certificates -- is a collection of certificates. In the NTS 283 protocol, it MUST contain the DER encoded certificate [RFC5280] of 284 the sender. It is intended that the collection of certificates be 285 sufficient for the recipient to construct a certification path 286 from a recognized "root" or "top-level certification authority" to 287 the certificate used by the sender. 289 crls -- is a collection of revocation status information. In the 290 NTS protocol, it MAY contain one or more DER encoded CRLs 291 [RFC5280]. It is intended that the collection contain information 292 sufficient to determine whether the certificates in the 293 certificates field are valid. 295 signerInfos -- is a collection of per-signer information. In the 296 NTS protocol, for the NTS-Certified archetype, this SHOULD be left 297 out. For both the NTS-Signed and the NTS-Encrypted-and-Signed 298 archetypes, there MUST be exactly one SignerInfo structure 299 present. The details of the SignerInfo type are discussed in 300 Section 5.3 of [RFC5652]. In the NTS protocol, it MUST follow 301 these conventions: 303 version -- is the syntax version number. In the NTS protocol, 304 the SignerIdentifier is subjectKeyIdentifier, therefore the 305 version MUST be 3. 307 sid -- identifies the signer's certificate. In the NTS 308 protocol, the "sid" field contains the subjectKeyIdentifier 309 from the signer's certificate. 311 digestAlgorithm -- identifies the message digest algorithm and 312 any associated parameters used by the signer. In the NTS 313 protocol, the identifier MUST match the single algorithm 314 identifier present in the digestAlgorithms. 316 signedAttrs -- is a collection of attributes that are signed. 317 In the NTS protocol, it MUST be present, and it MUST contain 318 the following attributes: 320 Content Type -- see Section 11.1 of [RFC5652]. 322 Message Digest -- see Section 11.2 of [RFC5652]. 324 In addition, it MAY contain the following attributes: 326 Signing Time -- see Section 11.3 of [RFC5652]. 328 Binary Signing Time -- see Section 3 of [RFC5652]. 330 signatureAlgorithm -- identifies the signature algorithm and 331 any associated parameters used by the signer to generate the 332 digital signature. 334 signature is the result of digital signature generation using 335 the message digest and the signer's private key. The 336 instructions in Section 5.5 of [RFC5652] MUST be followed. 338 unsignedAttrs -- is an optional collection of attributes that 339 are not signed. In the NTS protocol, it MUST be absent. 341 2.1.3. EnvelopedData 343 The EnvelopedData content type is used only in the NTS-Encrypted-and- 344 Signed archetype. The fields of the EnvelopedData content type are 345 used as follows: 347 version -- the appropriate value depends on the type of key 348 management that is used. The instructions in [RFC5652] 349 Section 6.1 MUST be followed to set the correct value. 351 originatorInfo -- this structure is present only if required by 352 the key management algorithm. In the NTS protocol, it MUST be 353 present when a key agreement algorithm is used, and it MUST be 354 absent when a key transport algorithm is used. The instructions 355 in Section 6.1 of [RFC5652] MUST be followed. 357 recipientInfos -- this structure is always present. In the NTS 358 protocol, it MUST contain exactly one entry that allows the client 359 to determine the key used to encrypt the NTS message. The 360 instructions in Section 6.2 of [RFC5652] MUST be followed. 362 encryptedContentInfo -- this structure is always present. In the 363 NTS protocol, it MUST follow these conventions: 365 contentType -- indicates the type of content. In the NTS 366 protocol, it MUST identify the type of the NTS message that was 367 encrypted. 369 contentEncryptionAlgorithm -- identifies the content-encryption 370 algorithm and any associated parameters used to encrypt the 371 content. 373 encryptedContent -- is the encrypted content. In the NTS 374 protocol, it MUST contain the encrypted NTS message. The 375 instructions in Section 6.3 of [RFC5652] MUST be followed. 377 unprotectedAttrs -- this structure is optional. In the NTS 378 protocol, it MUST be absent. 380 3. Implementation Notes: ASN.1 Structures and Use of the CMS 382 This section presents some hints about the structures of the NTS 383 message objects for the different message types when one wishes to 384 implement the security mechanisms. 386 3.1. Preliminaries 388 The following ASN.1 coded data type "NTSNonce" is needed for other 389 types used below for NTS messages. It specifies a 128 bit nonce as 390 required in several message types: 392 NTSNonce ::= OCTET STRING (SIZE(16)) 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 clientId SubjectKeyIdentifier, 417 digestAlgos DigestAlgorithmIdentifiers, 418 keyEncAlgos KeyEncryptionAlgorithmIdentifiers, 419 contentEncAlgos ContentEncryptionAlgorithmIdentifiers 420 } 422 It is identified by the following object identifier (fictional 423 values): 425 id-clientAssocData OBJECT IDENTIFIER ::= 426 {nts(TBD) association(1) clientassocdata(1)} 428 3.2.1.2. Message Type: "server_assoc" 430 This message is structured according to the NTS-Signed 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 "ServerAssocData" and structured as follows: 435 ServerAssocData ::= SEQUENCE { 436 nonce NTSNonce, 437 clientId SubjectKeyIdentifier, 438 digestAlgos DigestAlgorithmIdentifiers, 439 choiceDigestAlgo DigestAlgorithmIdentifier, 440 keyEncAlgos KeyEncryptionAlgorithmIdentifiers, 441 choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, 442 contentEncAlgos ContentEncryptionAlgorithmIdentifiers 443 choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier 444 } 446 It is identified by the following object identifier (fictional 447 values): 449 id-serverAssocData OBJECT IDENTIFIER ::= 450 {nts(TBD) association(1) serverassocdata(2)} 452 3.2.2. Cookie Messages 454 3.2.2.1. Message Type: "client_cook" 456 This message is structured according to the NTS-Certified archetype. 457 There is no data necessary besides that which is transported in the 458 NTS message object, which is an ASN.1 object of type 459 "ClientCookieData" and structured as follows: 461 ClientCookieData ::= SEQUENCE { 462 nonce NTSNonce, 463 signAlgo SignatureAlgorithmIdentifier, 464 digestAlgo DigestAlgorithmIdentifier, 465 encAlgo ContentEncryptionAlgorithmIdentifier, 466 keyEncAlgo KeyEncryptionAlgorithmIdentifier 467 } 469 It is identified by the following object identifier (fictional 470 values): 472 id-clientCookieData OBJECT IDENTIFIER ::= 473 {nts(TBD) association(1) clientcookiedata(3)} 475 3.2.2.2. Message Type: "server_cook" 477 This message is structured according to the "NTS-Encrypted-and- 478 Signed" archetype. There is no data necessary besides that which is 479 transported in the NTS message object, which is an ASN.1 object of 480 type "ServerCookieData" and structured as follows: 482 ServerCookieData ::= SEQUENCE { 483 nonce NTSNonce, 484 cookie OCTET STRING (SIZE(16)) 485 } 487 It is identified by the following object identifier (fictional 488 values): 490 id-serverCookieData OBJECT IDENTIFIER ::= 491 {nts(TBD) association(3) servercookiedata(4)} 493 3.2.3. Time Synchronization Messages 495 3.2.3.1. Message Type: "time_request" 497 This message is structured according to the "NTS-Plain" archetype. 499 This message type requires additional data to that which is included 500 in the NTS message object, namely it requires regular time 501 synchronization data, as an unsecured packet from a client to a 502 server would contain. The NTS message object itself is an ASN.1 503 object of type "TimeRequestSecurityData", whose structure is as 504 follows: 506 TimeRequestSecurityData ::= 507 SEQUENCE { 508 nonce_t NTSNonce, 509 digestAlgo DigestAlgorithmIdentifier, 510 keyInputValue OCTET STRING (SIZE(16)) 511 } 513 It is identified by the following object identifier (fictional 514 values): 516 id-timeRequestSecurityData OBJECT IDENTIFIER ::= 517 {nts(TBD) time(2) timerequestsecuritydata(1)} 519 3.2.3.2. Message Type: "time_response" 521 This message is also structured according to "NTS-Plain". 523 It requires two items of data in addition to that which is 524 transported in the NTS message object. Like "time_request", it 525 requires regular time synchronization data. Furthermore, it requires 526 the Message Authentication Code (MAC) to be generated over the whole 527 rest of the packet (including the NTS message object) and transported 528 in some way. The NTS message object itself is an ASN.1 object of 529 type "TimeResponseSecurityData", with the following structure: 531 TimeResponseSecurityData ::= 532 SEQUENCE { 533 nonce_t NTSNonce, 534 } 536 It is identified by the following object identifier (fictional 537 values): 539 id-timeResponseSecurityData OBJECT IDENTIFIER ::= 540 {nts(TBD) time(2) timeresponsesecuritydata(2)} 542 3.3. Broadcast Messages 544 3.3.1. Broadcast Parameter Messages 546 3.3.1.1. Message Type: "client_bpar" 548 This first broadcast message is structured according to the NTS-Plain 549 archetype. There is no data necessary besides that which is 550 transported in the NTS message object, which is an ASN.1 object of 551 type "BroadcastParameterRequest" and structured as follows: 553 BroadcastParameterRequest ::= 554 SEQUENCE { 555 nonce NTSNonce, 556 clientId SubjectKeyIdentifier 557 } 559 It is identified by the following object identifier (fictional 560 values): 562 id-broadcastParameterRequest OBJECT IDENTIFIER ::= 563 {nts(TBD) association(1) broadcastparameterrequest(5)} 565 3.3.1.2. Message Type: "server_bpar" 567 This message is structured according to "NTS-Signed". There is no 568 data necessary besides that which is transported in the NTS message 569 object, which is an ASN.1 object of type "BroadcastParameterResponse" 570 and structured as follows: 572 BroadcastParameterResponse ::= 573 SEQUENCE { 574 nonce NTSNonce, 575 oneWayAlgo1 DigestAlgorithmIdentifier, 576 oneWayAlgo2 DigestAlgorithmIdentifier, 577 lastKey OCTET STRING (SIZE (16)), 578 intervalDuration BIT STRING, 579 disclosureDelay INTEGER, 580 nextIntervalTime BIT STRING, 581 nextIntervalIndex INTEGER 582 } 584 It is identified by the following object identifier (fictional 585 values): 587 id-broadcastParameterResponse OBJECT IDENTIFIER ::= 588 {nts(TBD) association(3) broadcastparameterresponse(6)} 590 3.3.2. Broadcast Time Synchronization Message 592 3.3.2.1. Message Type: "server_broad" 594 This message is structured according to the "NTS-Plain" archetype. 595 It requires regular broadcast time synchronization data in addition 596 to that which is carried in the NTS message object. Like 597 "time_response", this message type also requires a MAC, generated 598 over all other data, to be transported within the packet. The NTS 599 message object itself is an ASN.1 object of type "BroadcastTime". It 600 has the following structure: 602 BroadcastTime ::= 603 SEQUENCE { 604 thisIntervalIndex INTEGER, 605 disclosedKey OCTET STRING (SIZE (16)), 606 } 608 It is identified by the following object identifier (fictional 609 values): 611 id-broadcastTime OBJECT IDENTIFIER ::= 612 {nts(TBD) time(1) broadcasttime(3)} 614 3.3.3. Broadcast Keycheck 616 3.3.3.1. Message Type: "client_keycheck" 618 This message is structured according to the "NTS-Plain" archetype. 619 There is no data necessary besides that which is transported in the 620 NTS message object, which is an ASN.1 object of type 621 "ClientKeyCheckSecurityData" and structured as follows: 623 ClientKeyCheckSecurityData ::= 624 SEQUENCE { 625 nonce_k NTSNonce, 626 interval_number INTEGER, 627 digestAlgo DigestAlgorithmIdentifier, 628 keyInputValue OCTET STRING (SIZE(16)) 629 } 631 It is identified by the following object identifier (fictional 632 values): 634 id-clientKeyCheckSecurityData OBJECT IDENTIFIER ::= 635 {nts(TBD) time(1) clientkeychecksecuritydata(6)} 637 3.3.3.2. Message Type: "server_keycheck" 639 This message is also structured according to "NTS-Plain". It 640 requires only a MAC, generated over the NTS message object, to be 641 included in the packet in addition to what the NTS message object 642 itself contains. The latter is an ASN.1 object of type 643 "ServerKeyCheckSecurityData", which is structured as follows: 645 ServerKeyCheckSecurityData ::= 646 SEQUENCE { 647 nonce_t NTSNonce, 648 interval_number INTEGER 649 } 651 It is identified by the following object identifier (fictional 652 values): 654 id-serverKeyCheckSecurityData OBJECT IDENTIFIER ::= 655 {nts(TBD) time(1) serverkeychecksecuritydata(7)} 657 4. Certificate Conventions 659 The syntax and processing rules for certificates are specified in 660 [RFC5652]. In the NTS protocol, the server certificate MUST contain 661 the following extensions: 663 Subject Key Identifier -- see Section 4.2.1.2 of [RFC5652]. 665 Key Usage -- see Section 4.2.1.3 of [RFC5652]. 667 Extended Key Usage -- see Section 4.2.1.22 of [RFC5652]. 669 The Extended Key Usage extension MUST include the id-kp-NTSserver 670 object identifier. When a certificate issuer includes this object 671 identifier in the extended key usage extension, it provides an 672 attestation that the certificate subject is a time server that 673 supports the NTS protocol. 675 The id-kp-NTSserver object identifier is: 677 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 679 5. IANA Considerations 681 IANA needs to assign an object identifier for the id-kp-NTSserver key 682 purpose and another one for the ASN.1 module in the appendix. 684 6. Security Considerations 686 To be written. 688 7. References 690 7.1. Normative References 692 [ASN1] International Telecommunication Union, "Abstract Syntax 693 Notation One (ASN.1): Specification of basic notation", 694 ITU-T Recommendation X.680, November 2008. 696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 697 Requirement Levels", BCP 14, RFC 2119, March 1997. 699 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 700 RFC 5652, September 2009. 702 7.2. Informative References 704 [I-D.ietf-ntp-network-time-security] 705 Sibold, D., Roettger, S., and K. Teichel, "Network Time 706 Security", draft-ietf-ntp-network-time-security-08 (work 707 in progress), March 2015. 709 [IEEE1588] 710 IEEE Instrumentation and Measurement Society. TC-9 Sensor 711 Technology, "IEEE standard for a precision clock 712 synchronization protocol for networked measurement and 713 control systems", 2008. 715 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 716 Time Protocol Version 4: Protocol and Algorithms 717 Specification", RFC 5905, June 2010. 719 Appendix A. ASN.1 Module 721 The ASN.1 module contained in this appendix defines the id-kp- 722 NTSserver object identifier. 724 NTSserverKeyPurpose 725 { TBD } 727 DEFINITIONS IMPLICIT TAGS ::= 728 BEGIN 730 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 732 END 734 Authors' Addresses 736 Dieter Sibold 737 Physikalisch-Technische Bundesanstalt 738 Bundesallee 100 739 Braunschweig D-38116 740 Germany 742 Phone: +49-(0)531-592-8420 743 Fax: +49-531-592-698420 744 Email: dieter.sibold@ptb.de 746 Kristof Teichel 747 Physikalisch-Technische Bundesanstalt 748 Bundesallee 100 749 Braunschweig D-38116 750 Germany 752 Phone: +49-(0)531-592-8421 753 Email: kristof.teichel@ptb.de 754 Stephen Roettger 755 Google Inc. 757 Email: stephen.roettger@googlemail.com 759 Russ Housley 760 Vigil Security 761 918 Spring Knoll Drive 762 Herndon, VA 20170 764 Email: housley@vigilsec.com