idnits 2.17.1 draft-ietf-ntp-cms-for-nts-message-01.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 22, 2015) is 3381 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' == Outdated reference: A later version (-15) exists of draft-ietf-ntp-network-time-security-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: July 26, 2015 Google Inc. 6 K. Teichel 7 PTB 8 R. Housley 9 Vigil Security 10 January 22, 2015 12 Protecting Network Time Security Messages with the Cryptographic Message 13 Syntax (CMS) 14 draft-ietf-ntp-cms-for-nts-message-01.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 July 26, 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 . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 14 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 clientId SubjectKeyIdentifier, 415 digestAlgos DigestAlgorithmIdentifiers, 416 keyEncAlgos KeyEncryptionAlgorithms, 417 contentEncAlgos ContentEncryptionAlgorithms 418 } 420 3.2.1.2. Message Type: "server_assoc" 422 This message is structured according to the NTS-Signed archetype. 423 There is no data necessary besides that which is transported in the 424 NTS message object, which is an ASN.1 object of type 425 "ServerAssocData" and structured as follows: 427 ServerAssocData ::= SEQUENCE { 428 clientId SubjectKeyIdentifier, 429 choiceDigestAlgo DigestAlgorithmIdentifier, 430 choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, 431 choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier 432 } 434 3.2.2. Cookie Messages 436 3.2.2.1. Message Type: "client_cook" 438 This message is structured according to the NTS-Certified archetype. 439 There is no data necessary besides that which is transported in the 440 NTS message object, which is an ASN.1 object of type 441 "ClientCookieData" and structured as follows: 443 ClientCookieData ::= SEQUENCE { 444 nonce NTSNonce, 445 signAlgo SignatureAlgorithmIdentifier, 446 digestAlgo DigestAlgorithmIdentifier, 447 encAlgo ContentEncryptionAlgorithmIdentifier, 448 keyEncAlgo KeyEncryptionAlgorithmIdentifier 449 } 451 It is identified by the following object identifier (fictional 452 values): 454 id-clientCookieData OBJECT IDENTIFIER ::= 455 {nts(??) cookie(3) clientcookiedata(1)} 457 3.2.2.2. Message Type: "server_cook" 459 This message is structured according to the "NTS-Encrypted-and- 460 Signed" archetype. There is no data necessary besides that which is 461 transported in the NTS message object, which is an ASN.1 object of 462 type "ServerCookieData" and structured as follows: 464 ServerCookieData ::= SEQUENCE { 465 nonce NTSNonce, 466 cookie OCTET STRING (SIZE(16)) 467 } 469 It is identified by the following object identifier (fictional 470 values): 472 id-serverCookieData OBJECT IDENTIFIER ::= 473 {nts(??) cookie(3) servercookiedata(2)} 475 3.2.3. Time Synchronization Messages 477 3.2.3.1. Message Type: "time_request" 479 This message is structured according to the "NTS-Plain" archetype. 481 This message type requires additional data to that which is included 482 in the NTS message object, namely it requires regular time 483 synchronization data, as an unsecured packet from a client to a 484 server would contain. The NTS message object itself is an ASN.1 485 object of type "TimeRequestSecurityData", whose structure is as 486 follows: 488 TimeRequestSecurityData ::= 489 SEQUENCE { 490 nonce_t NTSNonce, 491 digestAlgo DigestAlgorithmIdentifier, 492 hashOfClientCert BIT STRING 493 } 495 3.2.3.2. Message Type: "time_response" 497 This message is also structured according to "NTS-Plain". 499 It requires two items of data in addition to that which is 500 transported in the NTS message object. Like "time_request", it 501 requires regular time synchronization data. Furthermore, it requires 502 the Message Authentication Code (MAC) to be generated over the whole 503 rest of the packet (including the NTS message object) and transported 504 in some way. The NTS message object itself is an ASN.1 object of 505 type "TimeResponseSecurityData", with the following structure: 507 TimeResponseSecurityData ::= 508 SEQUENCE { 509 nonce_t NTSNonce, 510 } 512 3.3. Broadcast Messages 514 3.3.1. Broadcast Parameter Messages 516 3.3.1.1. Message Type: "client_bpar" 518 This first broadcast message is structured according to the NTS-Plain 519 archetype. There is no data necessary besides that which is 520 transported in the NTS message object, which is an ASN.1 object of 521 type "BroadcastParameterRequest" and structured as follows: 523 BroadcastParameterRequest ::= 524 SEQUENCE { 525 clientId SubjectKeyIdentifier 526 } 528 3.3.1.2. Message Type: "server_bpar" 530 This message is structured according to "NTS-Signed". There is no 531 data necessary besides that which is transported in the NTS message 532 object, which is an ASN.1 object of type "BroadcastParameterResponse" 533 and structured as follows: 535 BroadcastParameterResponse ::= 536 SEQUENCE { 537 oneWayAlgo1 DigestAlgorithmIdentifier, 538 oneWayAlgo2 DigestAlgorithmIdentifier, 539 lastKey OCTET STRING (SIZE (16)), 540 intervalDuration BIT STRING, 541 disclosureDelay INTEGER, 542 nextIntervalTime BIT STRING, 543 nextIntervalIndex INTEGER 544 } 546 3.3.2. Broadcast Time Synchronization Message 548 3.3.2.1. Message Type: "server_broad" 550 This message is structured according to the "NTS-Plain" archetype. 551 It requires regular broadcast time synchronization data in addition 552 to that which is carried in the NTS message object. Like 553 "time_response", this message type also requires a MAC, generated 554 over all other data, to be transported within the packet. The NTS 555 message object itself is an ASN.1 object of type "BroadcastTime". It 556 has the following structure: 558 BroadcastTime ::= 559 SEQUENCE { 560 thisIntervalIndex INTEGER, 561 disclosedKey OCTET STRING (SIZE (16)), 562 } 564 3.3.3. Broadcast Keycheck 566 3.3.3.1. Message Type: "client_keycheck" 568 This message is structured according to the "NTS-Plain" archetype. 569 There is no data necessary besides that which is transported in the 570 NTS message object, which is an ASN.1 object of type 571 "ClientKeyCheckSecurityData" and structured as follows: 573 ClientKeyCheckSecurityData ::= 574 SEQUENCE { 575 nonce_k NTSNonce, 576 interval_number INTEGER, 577 digestAlgo DigestAlgorithmIdentifier, 578 hashOfClientCert BIT STRING 579 } 581 3.3.3.2. Message Type: "server_keycheck" 583 This message is also structured according to "NTS-Plain". It 584 requires only a MAC, generated over the NTS message object, to be 585 included in the packet in addition to what the NTS message object 586 itself contains. The latter is an ASN.1 object of type 587 "ServerKeyCheckSecurityData", which is structured as follows: 589 ServerKeyCheckSecurityData ::= 590 SEQUENCE { 591 nonce_t NTSNonce, 592 interval_number INTEGER 593 } 595 4. Certificate Conventions 597 The syntax and processing rules for certificates are specified in 598 [RFC5652]. In the NTS protocol, the server certificate MUST contain 599 the following extensions: 601 Subject Key Identifier -- see Section 4.2.1.2 of [RFC5652]. 603 Key Usage -- see Section 4.2.1.3 of [RFC5652]. 605 Extended Key Usage -- see Section 4.2.1.22 of [RFC5652]. 607 The Extended Key Usage extension MUST include the id-kp-NTSserver 608 object identifier. When a certificate issuer includes this object 609 identifier in the extended key usage extension, it provides an 610 attestation that the certificate subject is a time server that 611 supports the NTS protocol. 613 The id-kp-NTSserver object identifier is: 615 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 617 5. IANA Considerations 619 IANA needs to assign an object identifier for the id-kp-NTSserver key 620 purpose and another one for the ASN.1 module in the appendix. 622 6. Security Considerations 624 To be written. 626 7. References 628 7.1. Normative References 630 [ASN1] International Telecommunication Union, "Abstract Syntax 631 Notation One (ASN.1): Specification of basic notation", 632 ITU-T Recommendation X.680, November 2008. 634 [IEEE1588] 635 IEEE Instrumentation and Measurement Society. TC-9 Sensor 636 Technology, "IEEE standard for a precision clock 637 synchronization protocol for networked measurement and 638 control systems", 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 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 647 Time Protocol Version 4: Protocol and Algorithms 648 Specification", RFC 5905, June 2010. 650 7.2. Informative References 652 [I-D.ietf-ntp-network-time-security] 653 Sibold, D., Roettger, S., and K. Teichel, "Network Time 654 Security", draft-ietf-ntp-network-time-security-06 (work 655 in progress), January 2015. 657 Appendix A. ASN.1 Module 659 The ASN.1 module contained in this appendix defines the id-kp- 660 NTSserver object identifier. 662 NTSserverKeyPurpose 663 { TBD } 665 DEFINITIONS IMPLICIT TAGS ::= 666 BEGIN 668 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 670 END 672 Authors' Addresses 674 Dieter Sibold 675 Physikalisch-Technische Bundesanstalt 676 Bundesallee 100 677 Braunschweig D-38116 678 Germany 680 Phone: +49-(0)531-592-8420 681 Fax: +49-531-592-698420 682 Email: dieter.sibold@ptb.de 684 Stephen Roettger 685 Google Inc. 687 Email: stephen.roettger@googlemail.com 689 Kristof Teichel 690 Physikalisch-Technische Bundesanstalt 691 Bundesallee 100 692 Braunschweig D-38116 693 Germany 695 Phone: +49-(0)531-592-8421 696 Email: kristof.teichel@ptb.de 698 Russ Housley 699 Vigil Security