idnits 2.17.1 draft-ietf-ntp-cms-for-nts-message-03.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 (April 01, 2015) is 3306 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 297, 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. -------------------------------------------------------------------------------- 1 NTP Working Group D. Sibold 2 Internet-Draft K. Teichel 3 Intended status: Standards Track PTB 4 Expires: October 3, 2015 S. Roettger 5 Google Inc. 6 R. Housley 7 Vigil Security 8 April 01, 2015 10 Protecting Network Time Security Messages with the Cryptographic Message 11 Syntax (CMS) 12 draft-ietf-ntp-cms-for-nts-message-03.txt 14 Abstract 16 This document describes a convention for using the Cryptographic 17 Message Syntax (CMS) to protect the messages in the Network Time 18 Security (NTS) protocol. NTS provides authentication of time servers 19 as well as integrity protection of time synchronization messages 20 using Network Time Protocol (NTP) or Precision Time Protocol (PTP). 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 3, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. CMS Conventions for NTS Message Protection . . . . . . . . . 3 64 2.1. Fields of the employed CMS Content Types . . . . . . . . 5 65 2.1.1. ContentInfo . . . . . . . . . . . . . . . . . . . . . 5 66 2.1.2. SignedData . . . . . . . . . . . . . . . . . . . . . 6 67 2.1.3. EnvelopedData . . . . . . . . . . . . . . . . . . . . 8 68 3. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9 69 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9 71 3.2.1. Association Messages . . . . . . . . . . . . . . . . 9 72 3.2.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10 73 3.2.3. Time Synchronization Messages . . . . . . . . . . . . 11 74 3.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 11 75 3.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 11 76 3.3.2. Broadcast Time Synchronization Message . . . . . . . 12 77 3.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 13 78 4. Certificate Conventions . . . . . . . . . . . . . . . . . . . 13 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 7.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 This document provides details on how to construct NTS messages in 90 practice. NTS provides secure time synchronization with time servers 91 using Network Time Protocol (NTP) [RFC5905] or Precision Time 92 Protocol (PTP) [IEEE1588]. Among other things, this document 93 describes a convention for using the Cryptographic Message Syntax 94 (CMS) [RFC5652] to protect messages in the Network Time Security 95 (NTS) protocol. Encryption is used to provide confidentiality of 96 secrets, and digital signatures are used to provide authentication 97 and integrity of content. 99 Sometimes CMS is used in an exclusively ASN.1 [ASN1] environment. In 100 this case, the NTS message may use any syntax that facilitates easy 101 implementation. 103 2. CMS Conventions for NTS Message Protection 105 Regarding the usage of CMS, we differentiate between four archetypes 106 according to which the NTS message types can be structured. They are 107 presented below. Note that the NTS Message Object that is at the 108 core of each structure does not necessarily contain all the data 109 needed for the particular message type, but may contain only that 110 data which needs to be secured directly with cryptographic operations 111 using the CMS. Specific information about what is included can be 112 found in Section 3. 114 NTS-Plain: This archetype is used for actual time synchronization 115 messages (explicitly, the following message types: time_request, 116 time_response, server_broad, see 117 [I-D.ietf-ntp-network-time-security], Section 6) as well as for 118 the very first messages of a unicast or a broadcast exchange 119 (client_assoc or client_bpar, respectively) and the broadcast 120 keycheck exchange (client_keycheck and server_keycheck). This 121 archetype does not make use of any CMS structures. Figure 1 122 illustrates this structure. 124 +---------------------------------------------------------+ 125 | | 126 | ContentInfo | 127 | | 128 | +-----------------------------------------------------+ | 129 | | | | 130 | | NTS Message Object | | 131 | | | | 132 | | | | 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 NTS-Certified: This archetype is used for the client_cook message 220 type. It uses a CMS structure much like the NTS-Signed archetype 221 (see Figure 3), with the only difference being that messages 222 SHOULD NOT be digitally signed. This archetype employs the CMS 223 structure merely in order to transport certificates. 225 2.1. Fields of the employed CMS Content Types 227 Overall, three CMS content types are used for NTS messages by the 228 archetypes above. Explicitly, those content types are ContentInfo, 229 SignedData and EnvelopedData. The following is a description of how 230 the fields of those content types are used in detail. 232 2.1.1. ContentInfo 234 The ContentInfo content type is used in all four archetypes. The 235 fields of the SignedData content type are used as follows: 237 contentType -- indicates the type of the associated content. For 238 the archetype NTS-Plain, it MUST identify the NTS message object 239 that is included. For all other archetypes (NTS-Certified, NTS- 240 Signed and NTS-Encrypted-and-Signed), it MUST contain the object 241 identifier for the SignedData content type: 243 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 244 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 246 content is the associated content. For the NTS-Plain archetype, 247 it MUST contain the DER encoded NTS message object. For all other 248 archetypes, it MUST contain the DER encoded SignedData content 249 type. 251 2.1.2. SignedData 253 The SignedData content type is used in the NTS-Certified, NTS-Signed 254 and NTS-Encrypted-and-Signed archetypes, but not in the NTS-Plain 255 archetype. The fields of the SignedData content type are used as 256 follows: 258 version -- the appropriate value depends on the optional items 259 that are included. In the NTS protocol, the signer certificate 260 MUST be included and other items MAY be included. The 261 instructions in [RFC5652] Section 5.1 MUST be followed to set the 262 correct value. 264 digestAlgorithms -- is a collection of message digest algorithm 265 identifiers. In the NTS protocol, there MUST be exactly one 266 algorithm identifier present. The instructions in Section 5.4 of 267 [RFC5652] MUST be followed. 269 encapContentInfo -- this structure is always present. In the NTS 270 protocol, it MUST follow these conventions: 272 eContentType -- is an object identifier. In the NTS protocol, 273 for the NTS-Certified and NTS-Signed archetypes, it MUST 274 identify the type of the NTS message that was encapsulated. 275 For the NTS-Encrypted-and-Signed archetype, it MUST contain the 276 object identifier for the EnvelopedData content type: 278 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 279 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }. 281 eContent is the content itself, carried as an octet string. 282 For the NTS-Certified and NTS-Signed archetypes, it MUST 283 contain the DER encoded encapsulated NTS message object. The 284 instructions in Section 6.3 of [RFC5652] MUST be followed. For 285 the NTS-Encrypted-and-Signed archetype, it MUST contain the DER 286 encoded EnvelopedData content type. 288 certificates -- is a collection of certificates. In the NTS 289 protocol, it MUST contain the DER encoded certificate [RFC5280] of 290 the sender. It is intended that the collection of certificates be 291 sufficient for the recipient to construct a certification path 292 from a recognized "root" or "top-level certification authority" to 293 the certificate used by the sender. 295 crls -- is a collection of revocation status information. In the 296 NTS protocol, it MAY contain one or more DER encoded CRLs 297 [RFC5280]. It is intended that the collection contain information 298 sufficient to determine whether the certificates in the 299 certificates field are valid. 301 signerInfos -- is a collection of per-signer information. In the 302 NTS protocol, for the NTS-Certified archetype, this SHOULD be left 303 out. For both the NTS-Signed and the NTS-Encrypted-and-Signed 304 archetypes, there MUST be exactly one SignerInfo structure 305 present. The details of the SignerInfo type are discussed in 306 Section 5.3 of [RFC5652]. In the NTS protocol, it MUST follow 307 these conventions: 309 version -- is the syntax version number. In the NTS protocol, 310 the SignerIdentifier is subjectKeyIdentifier, therefore the 311 version MUST be 3. 313 sid -- identifies the signer's certificate. In the NTS 314 protocol, the "sid" field contains the subjectKeyIdentifier 315 from the signer's certificate. 317 digestAlgorithm -- identifies the message digest algorithm and 318 any associated parameters used by the signer. In the NTS 319 protocol, the identifier MUST match the single algorithm 320 identifier present in the digestAlgorithms. 322 signedAttrs -- is a collection of attributes that are signed. 323 In the NTS protocol, it MUST be present, and it MUST contain 324 the following attributes: 326 Content Type -- see Section 11.1 of [RFC5652]. 328 Message Digest -- see Section 11.2 of [RFC5652]. 330 In addition, it MAY contain the following attributes: 332 Signing Time -- see Section 11.3 of [RFC5652]. 334 Binary Signing Time -- see Section 3 of [RFC5652]. 336 signatureAlgorithm -- identifies the signature algorithm and 337 any associated parameters used by the signer to generate the 338 digital signature. 340 signature is the result of digital signature generation using 341 the message digest and the signer's private key. The 342 instructions in Section 5.5 of [RFC5652] MUST be followed. 344 unsignedAttrs -- is an optional collection of attributes that 345 are not signed. In the NTS protocol, it MUST be absent. 347 2.1.3. EnvelopedData 349 The EnvelopedData content type is used only in the NTS-Encrypted-and- 350 Signed archetype. The fields of the EnvelopedData content type are 351 used as follows: 353 version -- the appropriate value depends on the type of key 354 management that is used. The instructions in [RFC5652] 355 Section 6.1 MUST be followed to set the correct value. 357 originatorInfo -- this structure is present only if required by 358 the key management algorithm. In the NTS protocol, it MUST be 359 present when a key agreement algorithm is used, and it MUST be 360 absent when a key transport algorithm is used. The instructions 361 in Section 6.1 of [RFC5652] MUST be followed. 363 recipientInfos -- this structure is always present. In the NTS 364 protocol, it MUST contain exactly one entry that allows the client 365 to determine the key used to encrypt the NTS message. The 366 instructions in Section 6.2 of [RFC5652] MUST be followed. 368 encryptedContentInfo -- this structure is always present. In the 369 NTS protocol, it MUST follow these conventions: 371 contentType -- indicates the type of content. In the NTS 372 protocol, it MUST identify the type of the NTS message that was 373 encrypted. 375 contentEncryptionAlgorithm -- identifies the content-encryption 376 algorithm and any associated parameters used to encrypt the 377 content. 379 encryptedContent -- is the encrypted content. In the NTS 380 protocol, it MUST contain the encrypted NTS message. The 381 instructions in Section 6.3 of [RFC5652] MUST be followed. 383 unprotectedAttrs -- this structure is optional. In the NTS 384 protocol, it MUST be absent. 386 3. Implementation Notes: ASN.1 Structures and Use of the CMS 388 This section presents some hints about the structures of the NTS 389 message objects for the different message types when one wishes to 390 implement the security mechanisms. 392 3.1. Preliminaries 394 The following ASN.1 coded data type "NTSNonce" is needed for other 395 types used below for NTS messages. It specifies a 128 bit nonce as 396 required in several message types: 398 NTSNonce ::= OCTET STRING (SIZE(16)) 400 3.2. Unicast Messages 402 3.2.1. Association Messages 404 3.2.1.1. Message Type: "client_assoc" 406 This message is structured according to the NTS-Plain archetype. 407 There is no data necessary besides that which is transported in the 408 NTS message object, which is an ASN.1 object of type 409 "ClientAssocData" and structured as follows: 411 ClientAssocData ::= SEQUENCE { 412 nonce NTSNonce, 413 clientId SubjectKeyIdentifier, 414 digestAlgos DigestAlgorithmIdentifiers, 415 keyEncAlgos KeyEncryptionAlgorithms, 416 contentEncAlgos ContentEncryptionAlgorithms 417 } 419 3.2.1.2. Message Type: "server_assoc" 421 This message is structured according to the NTS-Signed archetype. 422 There is no data necessary besides that which is transported in the 423 NTS message object, which is an ASN.1 object of type 424 "ServerAssocData" and structured as follows: 426 ServerAssocData ::= SEQUENCE { 427 nonce NTSNonce, 428 clientId SubjectKeyIdentifier, 429 digestAlgos DigestAlgorithmIdentifiers, 430 choiceDigestAlgo DigestAlgorithmIdentifier, 431 keyEncAlgos KeyEncryptionAlgorithms, 432 choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, 433 contentEncAlgos ContentEncryptionAlgorithms 434 choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier 435 } 437 3.2.2. Cookie Messages 439 3.2.2.1. Message Type: "client_cook" 441 This message is structured according to the NTS-Certified archetype. 442 There is no data necessary besides that which is transported in the 443 NTS message object, which is an ASN.1 object of type 444 "ClientCookieData" and structured as follows: 446 ClientCookieData ::= SEQUENCE { 447 nonce NTSNonce, 448 signAlgo SignatureAlgorithmIdentifier, 449 digestAlgo DigestAlgorithmIdentifier, 450 encAlgo ContentEncryptionAlgorithmIdentifier, 451 keyEncAlgo KeyEncryptionAlgorithmIdentifier 452 } 454 It is identified by the following object identifier (fictional 455 values): 457 id-clientCookieData OBJECT IDENTIFIER ::= 458 {nts(??) cookie(3) clientcookiedata(1)} 460 3.2.2.2. Message Type: "server_cook" 462 This message is structured according to the "NTS-Encrypted-and- 463 Signed" archetype. There is no data necessary besides that which is 464 transported in the NTS message object, which is an ASN.1 object of 465 type "ServerCookieData" and structured as follows: 467 ServerCookieData ::= SEQUENCE { 468 nonce NTSNonce, 469 cookie OCTET STRING (SIZE(16)) 470 } 472 It is identified by the following object identifier (fictional 473 values): 475 id-serverCookieData OBJECT IDENTIFIER ::= 476 {nts(??) cookie(3) servercookiedata(2)} 478 3.2.3. Time Synchronization Messages 480 3.2.3.1. Message Type: "time_request" 482 This message is structured according to the "NTS-Plain" archetype. 484 This message type requires additional data to that which is included 485 in the NTS message object, namely it requires regular time 486 synchronization data, as an unsecured packet from a client to a 487 server would contain. The NTS message object itself is an ASN.1 488 object of type "TimeRequestSecurityData", whose structure is as 489 follows: 491 TimeRequestSecurityData ::= 492 SEQUENCE { 493 nonce_t NTSNonce, 494 digestAlgo DigestAlgorithmIdentifier, 495 hashOfClientCert BIT STRING 496 } 498 3.2.3.2. Message Type: "time_response" 500 This message is also structured according to "NTS-Plain". 502 It requires two items of data in addition to that which is 503 transported in the NTS message object. Like "time_request", it 504 requires regular time synchronization data. Furthermore, it requires 505 the Message Authentication Code (MAC) to be generated over the whole 506 rest of the packet (including the NTS message object) and transported 507 in some way. The NTS message object itself is an ASN.1 object of 508 type "TimeResponseSecurityData", with the following structure: 510 TimeResponseSecurityData ::= 511 SEQUENCE { 512 nonce_t NTSNonce, 513 } 515 3.3. Broadcast Messages 517 3.3.1. Broadcast Parameter Messages 518 3.3.1.1. Message Type: "client_bpar" 520 This first broadcast message is structured according to the NTS-Plain 521 archetype. There is no data necessary besides that which is 522 transported in the NTS message object, which is an ASN.1 object of 523 type "BroadcastParameterRequest" and structured as follows: 525 BroadcastParameterRequest ::= 526 SEQUENCE { 527 nonce NTSNonce, 528 clientId SubjectKeyIdentifier 529 } 531 3.3.1.2. Message Type: "server_bpar" 533 This message is structured according to "NTS-Signed". There is no 534 data necessary besides that which is transported in the NTS message 535 object, which is an ASN.1 object of type "BroadcastParameterResponse" 536 and structured as follows: 538 BroadcastParameterResponse ::= 539 SEQUENCE { 540 nonce NTSNonce, 541 oneWayAlgo1 DigestAlgorithmIdentifier, 542 oneWayAlgo2 DigestAlgorithmIdentifier, 543 lastKey OCTET STRING (SIZE (16)), 544 intervalDuration BIT STRING, 545 disclosureDelay INTEGER, 546 nextIntervalTime BIT STRING, 547 nextIntervalIndex INTEGER 548 } 550 3.3.2. Broadcast Time Synchronization Message 552 3.3.2.1. Message Type: "server_broad" 554 This message is structured according to the "NTS-Plain" archetype. 555 It requires regular broadcast time synchronization data in addition 556 to that which is carried in the NTS message object. Like 557 "time_response", this message type also requires a MAC, generated 558 over all other data, to be transported within the packet. The NTS 559 message object itself is an ASN.1 object of type "BroadcastTime". It 560 has the following structure: 562 BroadcastTime ::= 563 SEQUENCE { 564 thisIntervalIndex INTEGER, 565 disclosedKey OCTET STRING (SIZE (16)), 566 } 568 3.3.3. Broadcast Keycheck 570 3.3.3.1. Message Type: "client_keycheck" 572 This message is structured according to the "NTS-Plain" archetype. 573 There is no data necessary besides that which is transported in the 574 NTS message object, which is an ASN.1 object of type 575 "ClientKeyCheckSecurityData" and structured as follows: 577 ClientKeyCheckSecurityData ::= 578 SEQUENCE { 579 nonce_k NTSNonce, 580 interval_number INTEGER, 581 digestAlgo DigestAlgorithmIdentifier, 582 hashOfClientCert BIT STRING 583 } 585 3.3.3.2. Message Type: "server_keycheck" 587 This message is also structured according to "NTS-Plain". It 588 requires only a MAC, generated over the NTS message object, to be 589 included in the packet in addition to what the NTS message object 590 itself contains. The latter is an ASN.1 object of type 591 "ServerKeyCheckSecurityData", which is structured as follows: 593 ServerKeyCheckSecurityData ::= 594 SEQUENCE { 595 nonce_t NTSNonce, 596 interval_number INTEGER 597 } 599 4. Certificate Conventions 601 The syntax and processing rules for certificates are specified in 602 [RFC5652]. In the NTS protocol, the server certificate MUST contain 603 the following extensions: 605 Subject Key Identifier -- see Section 4.2.1.2 of [RFC5652]. 607 Key Usage -- see Section 4.2.1.3 of [RFC5652]. 609 Extended Key Usage -- see Section 4.2.1.22 of [RFC5652]. 611 The Extended Key Usage extension MUST include the id-kp-NTSserver 612 object identifier. When a certificate issuer includes this object 613 identifier in the extended key usage extension, it provides an 614 attestation that the certificate subject is a time server that 615 supports the NTS protocol. 617 The id-kp-NTSserver object identifier is: 619 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 621 5. IANA Considerations 623 IANA needs to assign an object identifier for the id-kp-NTSserver key 624 purpose and another one for the ASN.1 module in the appendix. 626 6. Security Considerations 628 To be written. 630 7. References 632 7.1. Normative References 634 [ASN1] International Telecommunication Union, "Abstract Syntax 635 Notation One (ASN.1): Specification of basic notation", 636 ITU-T Recommendation X.680, November 2008. 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, March 1997. 641 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 642 RFC 5652, September 2009. 644 7.2. Informative References 646 [I-D.ietf-ntp-network-time-security] 647 Sibold, D., Roettger, S., and K. Teichel, "Network Time 648 Security", draft-ietf-ntp-network-time-security-07 (work 649 in progress), March 2015. 651 [IEEE1588] 652 IEEE Instrumentation and Measurement Society. TC-9 Sensor 653 Technology, "IEEE standard for a precision clock 654 synchronization protocol for networked measurement and 655 control systems", 2008. 657 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 658 Time Protocol Version 4: Protocol and Algorithms 659 Specification", RFC 5905, June 2010. 661 Appendix A. ASN.1 Module 663 The ASN.1 module contained in this appendix defines the id-kp- 664 NTSserver object identifier. 666 NTSserverKeyPurpose 667 { TBD } 669 DEFINITIONS IMPLICIT TAGS ::= 670 BEGIN 672 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 674 END 676 Authors' Addresses 678 Dieter Sibold 679 Physikalisch-Technische Bundesanstalt 680 Bundesallee 100 681 Braunschweig D-38116 682 Germany 684 Phone: +49-(0)531-592-8420 685 Fax: +49-531-592-698420 686 Email: dieter.sibold@ptb.de 688 Kristof Teichel 689 Physikalisch-Technische Bundesanstalt 690 Bundesallee 100 691 Braunschweig D-38116 692 Germany 694 Phone: +49-(0)531-592-8421 695 Email: kristof.teichel@ptb.de 697 Stephen Roettger 698 Google Inc. 700 Email: stephen.roettger@googlemail.com 701 Russ Housley 702 Vigil Security 703 918 Spring Knoll Drive 704 Herndon, VA 20170 706 Email: housley@vigilsec.com