idnits 2.17.1 draft-ietf-ntp-cms-for-nts-message-02.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 (March 06, 2015) is 3337 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 299, 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-07 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 PTB 4 Intended status: Standards Track S. Roettger 5 Expires: September 7, 2015 Google Inc. 6 K. Teichel 7 PTB 8 R. Housley 9 Vigil Security 10 March 06, 2015 12 Protecting Network Time Security Messages with the Cryptographic Message 13 Syntax (CMS) 14 draft-ietf-ntp-cms-for-nts-message-02.txt 16 Abstract 18 This document describes a convention for using the Cryptographic 19 Message Syntax (CMS) to protect the messages in the Network Time 20 Security (NTS) protocol. NTS provides authentication of time servers 21 as well as integrity protection of time synchronization messages 22 using Network Time Protocol (NTP) or Precision Time Protocol (PTP). 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 7, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. CMS Conventions for NTS Message Protection . . . . . . . . . 3 66 2.1. Fields of the employed CMS Content Types . . . . . . . . 5 67 2.1.1. ContentInfo . . . . . . . . . . . . . . . . . . . . . 5 68 2.1.2. SignedData . . . . . . . . . . . . . . . . . . . . . 6 69 2.1.3. EnvelopedData . . . . . . . . . . . . . . . . . . . . 8 70 3. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9 71 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9 73 3.2.1. Association Messages . . . . . . . . . . . . . . . . 9 74 3.2.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10 75 3.2.3. Time Synchronization Messages . . . . . . . . . . . . 11 76 3.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 11 77 3.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 11 78 3.3.2. Broadcast Time Synchronization Message . . . . . . . 12 79 3.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 13 80 4. Certificate Conventions . . . . . . . . . . . . . . . . . . . 13 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 7.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 This document provides details on how to construct NTS messages in 92 practice. NTS provides secure time synchronization with time servers 93 using Network Time Protocol (NTP) [RFC5905] or Precision Time 94 Protocol (PTP) [IEEE1588]. Among other things, this document 95 describes a convention for using the Cryptographic Message Syntax 96 (CMS) [RFC5652] to protect messages in the Network Time Security 97 (NTS) protocol. Encryption is used to provide confidentiality of 98 secrets, and digital signatures are used to provide authentication 99 and integrity of content. 101 Sometimes CMS is used in an exclusively ASN.1 [ASN1] environment. In 102 this case, the NTS message may use any syntax that facilitates easy 103 implementation. 105 2. CMS Conventions for NTS Message Protection 107 Regarding the usage of CMS, we differentiate between four archetypes 108 according to which the NTS message types can be structured. They are 109 presented below. Note that the NTS Message Object that is at the 110 core of each structure does not necessarily contain all the data 111 needed for the particular message type, but may contain only that 112 data which needs to be secured directly with cryptographic operations 113 using the CMS. Specific information about what is included can be 114 found in Section 3. 116 NTS-Plain: This archetype is used for actual time synchronization 117 messages (explicitly, the following message types: time_request, 118 time_response, server_broad, see 119 [I-D.ietf-ntp-network-time-security], Section 6) as well as for 120 the very first messages of a unicast or a broadcast exchange 121 (client_assoc or client_bpar, respectively) and the broadcast 122 keycheck exchange (client_keycheck and server_keycheck). This 123 archetype does not make use of any CMS structures. Figure 1 124 illustrates this structure. 126 +---------------------------------------------------------+ 127 | | 128 | ContentInfo | 129 | | 130 | +-----------------------------------------------------+ | 131 | | | | 132 | | NTS Message Object | | 133 | | | | 134 | | | | 135 | +-----------------------------------------------------+ | 136 | | 137 +---------------------------------------------------------+ 139 NTS-Encrypted-and-Signed: This archetype is used for secure 140 transmission of the cookie (only for the server_cook message type, 141 see [I-D.ietf-ntp-network-time-security], Section 6). For this, 142 the following CMS structure is used: 144 First, the NTS message MUST be encrypted using the 145 EnvelopedData content type. EnvelopedData supports nearly any 146 form of key management. In the NTS protocol the client 147 provides a certificate in an unprotected message, and the 148 public key from this certificate, if it is valid, will be used 149 to establish a pairwise symmetric key for the encryption of the 150 protected NTS message. 152 Second, the EnvelopedData content MUST be digitally signed 153 using the SignedData content type. SignedData supports nearly 154 any form of digital signature, and in the NTS protocol the 155 server will include its certificate within the SignedData 156 content type. 158 Third, the SignedData content type MUST be encapsulated in a 159 ContentInfo content type. 161 Figure 2 illustrates this structure. 163 +---------------------------------------------------------+ 164 | | 165 | ContentInfo | 166 | | 167 | +-----------------------------------------------------+ | 168 | | | | 169 | | SignedData | | 170 | | | | 171 | | +-------------------------------------------------+ | | 172 | | | | | | 173 | | | EnvelopedData | | | 174 | | | | | | 175 | | | +---------------------------------------------+ | | | 176 | | | | | | | | 177 | | | | NTS Message Object | | | | 178 | | | | | | | | 179 | | | | | | | | 180 | | | +---------------------------------------------+ | | | 181 | | | | | | 182 | | +-------------------------------------------------+ | | 183 | | | | 184 | +-----------------------------------------------------+ | 185 | | 186 +---------------------------------------------------------+ 188 NTS-Signed: This archetype is used for server_assoc and server_bpar 189 message types. It uses the following CMS structure: 191 First, the NTS message object MUST be wrapped in a SignedData 192 content type. The messages MUST be digitally signed, and 193 certificates included. SignedData supports nearly any form of 194 digital signature, and in the NTS protocol the server will 195 include its certificate within the SignedData content type. 197 Second, the SignedData content type MUST be encapsulated in a 198 ContentInfo content type. 200 Figure 3 illustrates this structure. 202 +---------------------------------------------------------+ 203 | | 204 | ContentInfo | 205 | | 206 | +-----------------------------------------------------+ | 207 | | | | 208 | | SignedData | | 209 | | | | 210 | | +-------------------------------------------------+ | | 211 | | | | | | 212 | | | NTS Message Object | | | 213 | | | | | | 214 | | | | | | 215 | | +-------------------------------------------------+ | | 216 | | | | 217 | +-----------------------------------------------------+ | 218 | | 219 +---------------------------------------------------------+ 221 NTS-Certified: This archetype is used for the client_cook message 222 type. It uses a CMS structure much like the NTS-Signed archetype 223 (see Figure 3), with the only difference being that messages 224 SHOULD NOT be digitally signed. This archetype employs the CMS 225 structure merely in order to transport certificates. 227 2.1. Fields of the employed CMS Content Types 229 Overall, three CMS content types are used for NTS messages by the 230 archetypes above. Explicitly, those content types are ContentInfo, 231 SignedData and EnvelopedData. The following is a description of how 232 the fields of those content types are used in detail. 234 2.1.1. ContentInfo 236 The ContentInfo content type is used in all four archetypes. The 237 fields of the SignedData content type are used as follows: 239 contentType -- indicates the type of the associated content. For 240 the archetype NTS-Plain, it MUST identify the NTS message object 241 that is included. For all other archetypes (NTS-Certified, NTS- 242 Signed and NTS-Encrypted-and-Signed), it MUST contain the object 243 identifier for the SignedData content type: 245 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 246 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 248 content is the associated content. For the NTS-Plain archetype, 249 it MUST contain the DER encoded NTS message object. For all other 250 archetypes, it MUST contain the DER encoded SignedData content 251 type. 253 2.1.2. SignedData 255 The SignedData content type is used in the NTS-Certified, NTS-Signed 256 and NTS-Encrypted-and-Signed archetypes, but not in the NTS-Plain 257 archetype. The fields of the SignedData content type are used as 258 follows: 260 version -- the appropriate value depends on the optional items 261 that are included. In the NTS protocol, the signer certificate 262 MUST be included and other items MAY be included. The 263 instructions in [RFC5652] Section 5.1 MUST be followed to set the 264 correct value. 266 digestAlgorithms -- is a collection of message digest algorithm 267 identifiers. In the NTS protocol, there MUST be exactly one 268 algorithm identifier present. The instructions in Section 5.4 of 269 [RFC5652] MUST be followed. 271 encapContentInfo -- this structure is always present. In the NTS 272 protocol, it MUST follow these conventions: 274 eContentType -- is an object identifier. In the NTS protocol, 275 for the NTS-Certified and NTS-Signed archetypes, it MUST 276 identify the type of the NTS message that was encapsulated. 277 For the NTS-Encrypted-and-Signed archetype, it MUST contain the 278 object identifier for the EnvelopedData content type: 280 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 281 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }. 283 eContent is the content itself, carried as an octet string. 284 For the NTS-Certified and NTS-Signed archetypes, it MUST 285 contain the DER encoded encapsulated NTS message object. The 286 instructions in Section 6.3 of [RFC5652] MUST be followed. For 287 the NTS-Encrypted-and-Signed archetype, it MUST contain the DER 288 encoded EnvelopedData content type. 290 certificates -- is a collection of certificates. In the NTS 291 protocol, it MUST contain the DER encoded certificate [RFC5280] of 292 the sender. It is intended that the collection of certificates be 293 sufficient for the recipient to construct a certification path 294 from a recognized "root" or "top-level certification authority" to 295 the certificate used by the sender. 297 crls -- is a collection of revocation status information. In the 298 NTS protocol, it MAY contain one or more DER encoded CRLs 299 [RFC5280]. It is intended that the collection contain information 300 sufficient to determine whether the certificates in the 301 certificates field are valid. 303 signerInfos -- is a collection of per-signer information. In the 304 NTS protocol, for the NTS-Certified archetype, this SHOULD be left 305 out. For both the NTS-Signed and the NTS-Encrypted-and-Signed 306 archetypes, there MUST be exactly one SignerInfo structure 307 present. The details of the SignerInfo type are discussed in 308 Section 5.3 of [RFC5652]. In the NTS protocol, it MUST follow 309 these conventions: 311 version -- is the syntax version number. In the NTS protocol, 312 the SignerIdentifier is subjectKeyIdentifier, therefore the 313 version MUST be 3. 315 sid -- identifies the signer's certificate. In the NTS 316 protocol, the "sid" field contains the subjectKeyIdentifier 317 from the signer's certificate. 319 digestAlgorithm -- identifies the message digest algorithm and 320 any associated parameters used by the signer. In the NTS 321 protocol, the identifier MUST match the single algorithm 322 identifier present in the digestAlgorithms. 324 signedAttrs -- is a collection of attributes that are signed. 325 In the NTS protocol, it MUST be present, and it MUST contain 326 the following attributes: 328 Content Type -- see Section 11.1 of [RFC5652]. 330 Message Digest -- see Section 11.2 of [RFC5652]. 332 In addition, it MAY contain the following attributes: 334 Signing Time -- see Section 11.3 of [RFC5652]. 336 Binary Signing Time -- see Section 3 of [RFC5652]. 338 signatureAlgorithm -- identifies the signature algorithm and 339 any associated parameters used by the signer to generate the 340 digital signature. 342 signature is the result of digital signature generation using 343 the message digest and the signer's private key. The 344 instructions in Section 5.5 of [RFC5652] MUST be followed. 346 unsignedAttrs -- is an optional collection of attributes that 347 are not signed. In the NTS protocol, it MUST be absent. 349 2.1.3. EnvelopedData 351 The EnvelopedData content type is used only in the NTS-Encrypted-and- 352 Signed archetype. The fields of the EnvelopedData content type are 353 used as follows: 355 version -- the appropriate value depends on the type of key 356 management that is used. The instructions in [RFC5652] 357 Section 6.1 MUST be followed to set the correct value. 359 originatorInfo -- this structure is present only if required by 360 the key management algorithm. In the NTS protocol, it MUST be 361 present when a key agreement algorithm is used, and it MUST be 362 absent when a key transport algorithm is used. The instructions 363 in Section 6.1 of [RFC5652] MUST be followed. 365 recipientInfos -- this structure is always present. In the NTS 366 protocol, it MUST contain exactly one entry that allows the client 367 to determine the key used to encrypt the NTS message. The 368 instructions in Section 6.2 of [RFC5652] MUST be followed. 370 encryptedContentInfo -- this structure is always present. In the 371 NTS protocol, it MUST follow these conventions: 373 contentType -- indicates the type of content. In the NTS 374 protocol, it MUST identify the type of the NTS message that was 375 encrypted. 377 contentEncryptionAlgorithm -- identifies the content-encryption 378 algorithm and any associated parameters used to encrypt the 379 content. 381 encryptedContent -- is the encrypted content. In the NTS 382 protocol, it MUST contain the encrypted NTS message. The 383 instructions in Section 6.3 of [RFC5652] MUST be followed. 385 unprotectedAttrs -- this structure is optional. In the NTS 386 protocol, it MUST be absent. 388 3. Implementation Notes: ASN.1 Structures and Use of the CMS 390 This section presents some hints about the structures of the NTS 391 message objects for the different message types when one wishes to 392 implement the security mechanisms. 394 3.1. Preliminaries 396 The following ASN.1 coded data type "NTSNonce" is needed for other 397 types used below for NTS messages. It specifies a 128 bit nonce as 398 required in several message types: 400 NTSNonce ::= OCTET STRING (SIZE(16)) 402 3.2. Unicast Messages 404 3.2.1. Association Messages 406 3.2.1.1. Message Type: "client_assoc" 408 This message is structured according to the NTS-Plain archetype. 409 There is no data necessary besides that which is transported in the 410 NTS message object, which is an ASN.1 object of type 411 "ClientAssocData" and structured as follows: 413 ClientAssocData ::= SEQUENCE { 414 nonce NTSNonce, 415 clientId SubjectKeyIdentifier, 416 digestAlgos DigestAlgorithmIdentifiers, 417 keyEncAlgos KeyEncryptionAlgorithms, 418 contentEncAlgos ContentEncryptionAlgorithms 419 } 421 3.2.1.2. Message Type: "server_assoc" 423 This message is structured according to the NTS-Signed archetype. 424 There is no data necessary besides that which is transported in the 425 NTS message object, which is an ASN.1 object of type 426 "ServerAssocData" and structured as follows: 428 ServerAssocData ::= SEQUENCE { 429 nonce NTSNonce, 430 clientId SubjectKeyIdentifier, 431 digestAlgos DigestAlgorithmIdentifiers, 432 choiceDigestAlgo DigestAlgorithmIdentifier, 433 keyEncAlgos KeyEncryptionAlgorithms, 434 choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, 435 contentEncAlgos ContentEncryptionAlgorithms 436 choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier 437 } 439 3.2.2. Cookie Messages 441 3.2.2.1. Message Type: "client_cook" 443 This message is structured according to the NTS-Certified archetype. 444 There is no data necessary besides that which is transported in the 445 NTS message object, which is an ASN.1 object of type 446 "ClientCookieData" and structured as follows: 448 ClientCookieData ::= SEQUENCE { 449 nonce NTSNonce, 450 signAlgo SignatureAlgorithmIdentifier, 451 digestAlgo DigestAlgorithmIdentifier, 452 encAlgo ContentEncryptionAlgorithmIdentifier, 453 keyEncAlgo KeyEncryptionAlgorithmIdentifier 454 } 456 It is identified by the following object identifier (fictional 457 values): 459 id-clientCookieData OBJECT IDENTIFIER ::= 460 {nts(??) cookie(3) clientcookiedata(1)} 462 3.2.2.2. Message Type: "server_cook" 464 This message is structured according to the "NTS-Encrypted-and- 465 Signed" archetype. There is no data necessary besides that which is 466 transported in the NTS message object, which is an ASN.1 object of 467 type "ServerCookieData" and structured as follows: 469 ServerCookieData ::= SEQUENCE { 470 nonce NTSNonce, 471 cookie OCTET STRING (SIZE(16)) 472 } 474 It is identified by the following object identifier (fictional 475 values): 477 id-serverCookieData OBJECT IDENTIFIER ::= 478 {nts(??) cookie(3) servercookiedata(2)} 480 3.2.3. Time Synchronization Messages 482 3.2.3.1. Message Type: "time_request" 484 This message is structured according to the "NTS-Plain" archetype. 486 This message type requires additional data to that which is included 487 in the NTS message object, namely it requires regular time 488 synchronization data, as an unsecured packet from a client to a 489 server would contain. The NTS message object itself is an ASN.1 490 object of type "TimeRequestSecurityData", whose structure is as 491 follows: 493 TimeRequestSecurityData ::= 494 SEQUENCE { 495 nonce_t NTSNonce, 496 digestAlgo DigestAlgorithmIdentifier, 497 hashOfClientCert BIT STRING 498 } 500 3.2.3.2. Message Type: "time_response" 502 This message is also structured according to "NTS-Plain". 504 It requires two items of data in addition to that which is 505 transported in the NTS message object. Like "time_request", it 506 requires regular time synchronization data. Furthermore, it requires 507 the Message Authentication Code (MAC) to be generated over the whole 508 rest of the packet (including the NTS message object) and transported 509 in some way. The NTS message object itself is an ASN.1 object of 510 type "TimeResponseSecurityData", with the following structure: 512 TimeResponseSecurityData ::= 513 SEQUENCE { 514 nonce_t NTSNonce, 515 } 517 3.3. Broadcast Messages 519 3.3.1. Broadcast Parameter Messages 520 3.3.1.1. Message Type: "client_bpar" 522 This first broadcast message is structured according to the NTS-Plain 523 archetype. There is no data necessary besides that which is 524 transported in the NTS message object, which is an ASN.1 object of 525 type "BroadcastParameterRequest" and structured as follows: 527 BroadcastParameterRequest ::= 528 SEQUENCE { 529 nonce NTSNonce, 530 clientId SubjectKeyIdentifier 531 } 533 3.3.1.2. Message Type: "server_bpar" 535 This message is structured according to "NTS-Signed". There is no 536 data necessary besides that which is transported in the NTS message 537 object, which is an ASN.1 object of type "BroadcastParameterResponse" 538 and structured as follows: 540 BroadcastParameterResponse ::= 541 SEQUENCE { 542 nonce NTSNonce, 543 oneWayAlgo1 DigestAlgorithmIdentifier, 544 oneWayAlgo2 DigestAlgorithmIdentifier, 545 lastKey OCTET STRING (SIZE (16)), 546 intervalDuration BIT STRING, 547 disclosureDelay INTEGER, 548 nextIntervalTime BIT STRING, 549 nextIntervalIndex INTEGER 550 } 552 3.3.2. Broadcast Time Synchronization Message 554 3.3.2.1. Message Type: "server_broad" 556 This message is structured according to the "NTS-Plain" archetype. 557 It requires regular broadcast time synchronization data in addition 558 to that which is carried in the NTS message object. Like 559 "time_response", this message type also requires a MAC, generated 560 over all other data, to be transported within the packet. The NTS 561 message object itself is an ASN.1 object of type "BroadcastTime". It 562 has the following structure: 564 BroadcastTime ::= 565 SEQUENCE { 566 thisIntervalIndex INTEGER, 567 disclosedKey OCTET STRING (SIZE (16)), 568 } 570 3.3.3. Broadcast Keycheck 572 3.3.3.1. Message Type: "client_keycheck" 574 This message is structured according to the "NTS-Plain" archetype. 575 There is no data necessary besides that which is transported in the 576 NTS message object, which is an ASN.1 object of type 577 "ClientKeyCheckSecurityData" and structured as follows: 579 ClientKeyCheckSecurityData ::= 580 SEQUENCE { 581 nonce_k NTSNonce, 582 interval_number INTEGER, 583 digestAlgo DigestAlgorithmIdentifier, 584 hashOfClientCert BIT STRING 585 } 587 3.3.3.2. Message Type: "server_keycheck" 589 This message is also structured according to "NTS-Plain". It 590 requires only a MAC, generated over the NTS message object, to be 591 included in the packet in addition to what the NTS message object 592 itself contains. The latter is an ASN.1 object of type 593 "ServerKeyCheckSecurityData", which is structured as follows: 595 ServerKeyCheckSecurityData ::= 596 SEQUENCE { 597 nonce_t NTSNonce, 598 interval_number INTEGER 599 } 601 4. Certificate Conventions 603 The syntax and processing rules for certificates are specified in 604 [RFC5652]. In the NTS protocol, the server certificate MUST contain 605 the following extensions: 607 Subject Key Identifier -- see Section 4.2.1.2 of [RFC5652]. 609 Key Usage -- see Section 4.2.1.3 of [RFC5652]. 611 Extended Key Usage -- see Section 4.2.1.22 of [RFC5652]. 613 The Extended Key Usage extension MUST include the id-kp-NTSserver 614 object identifier. When a certificate issuer includes this object 615 identifier in the extended key usage extension, it provides an 616 attestation that the certificate subject is a time server that 617 supports the NTS protocol. 619 The id-kp-NTSserver object identifier is: 621 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 623 5. IANA Considerations 625 IANA needs to assign an object identifier for the id-kp-NTSserver key 626 purpose and another one for the ASN.1 module in the appendix. 628 6. Security Considerations 630 To be written. 632 7. References 634 7.1. Normative References 636 [ASN1] International Telecommunication Union, "Abstract Syntax 637 Notation One (ASN.1): Specification of basic notation", 638 ITU-T Recommendation X.680, November 2008. 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, March 1997. 643 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 644 RFC 5652, September 2009. 646 7.2. Informative References 648 [I-D.ietf-ntp-network-time-security] 649 Sibold, D., Roettger, S., and K. Teichel, "Network Time 650 Security", draft-ietf-ntp-network-time-security-07 (work 651 in progress), March 2015. 653 [IEEE1588] 654 IEEE Instrumentation and Measurement Society. TC-9 Sensor 655 Technology, "IEEE standard for a precision clock 656 synchronization protocol for networked measurement and 657 control systems", 2008. 659 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 660 Time Protocol Version 4: Protocol and Algorithms 661 Specification", RFC 5905, June 2010. 663 Appendix A. ASN.1 Module 665 The ASN.1 module contained in this appendix defines the id-kp- 666 NTSserver object identifier. 668 NTSserverKeyPurpose 669 { TBD } 671 DEFINITIONS IMPLICIT TAGS ::= 672 BEGIN 674 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 676 END 678 Authors' Addresses 680 Dieter Sibold 681 Physikalisch-Technische Bundesanstalt 682 Bundesallee 100 683 Braunschweig D-38116 684 Germany 686 Phone: +49-(0)531-592-8420 687 Fax: +49-531-592-698420 688 Email: dieter.sibold@ptb.de 690 Stephen Roettger 691 Google Inc. 693 Email: stephen.roettger@googlemail.com 695 Kristof Teichel 696 Physikalisch-Technische Bundesanstalt 697 Bundesallee 100 698 Braunschweig D-38116 699 Germany 701 Phone: +49-(0)531-592-8421 702 Email: kristof.teichel@ptb.de 703 Russ Housley 704 Vigil Security