idnits 2.17.1 draft-ietf-ntp-cms-for-nts-message-00.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 (October 23, 2014) is 3466 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 284, 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-04 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: April 26, 2015 Google Inc 6 K. Teichel 7 PTB 8 R. Housley 9 Vigil Security 10 October 23, 2014 12 Protecting Network Time Security Messages with the Cryptographic Message 13 Syntax (CMS) 14 draft-ietf-ntp-cms-for-nts-message-00.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 April 26, 2015. 47 Copyright Notice 49 Copyright (c) 2014 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. Certificate Conventions . . . . . . . . . . . . . . . . . . . 9 71 4. Implementation Notes: ASN.1 Structures and Use of the CMS . . 9 72 4.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2. Unicast Messages . . . . . . . . . . . . . . . . . . . . 9 74 4.2.1. Association Messages . . . . . . . . . . . . . . . . 9 75 4.2.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 10 76 4.2.3. Time Synchronization Messages . . . . . . . . . . . . 11 77 4.3. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12 78 4.3.1. Broadcast Parameter Messages . . . . . . . . . . . . 12 79 4.3.2. Broadcast Time Synchronization Message . . . . . . . 12 80 4.3.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 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 detail 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: 110 NTS-Plain: This archetype is used for actual time synchronization 111 messages (explicitly, the message types: time_request, 112 time_response, server_broad, see 113 [I-D.ietf-ntp-network-time-security], section 6) as well as for 114 the very first messages of a unicast or a broadcast exchange 115 (client_assoc or client_bpar, respectively) and the broadcast 116 keycheck exchange (client_keycheck and server_keycheck). This 117 archetype does not make use of any CMS structures. 119 NTS-Signed-and-Encrypted: This archetype is used for secure 120 transmission of the cookie (only for the server_cook message type, 121 see [I-D.ietf-ntp-network-time-security], section 6). For this, 122 the following CMS structure is used: 124 First, the NTS message MUST be encrypted using the 125 EnvelopedData content type. EnvelopedData supports nearly any 126 form of key management. In the NTS protocol the client 127 provides a certificate in an unprotected message, and the 128 public key from this certificate, if it is valid, will be used 129 to establish a pairwise symmetric key for the encryption of the 130 protected NTS message. 132 Second, the EnvelopedData content MUST be digitally signed 133 using the SignedData content type. SignedData supports nearly 134 any form of digital signature, and in the NTS protocol the 135 server will include its certificate within the SignedData 136 content type. 138 Third, the SignedData content type MUST be encapsulated in a 139 ContentInfo content type. 141 Figure 1 illustrates this structure. 143 +---------------------------------------------------------+ 144 | | 145 | ContentInfo | 146 | | 147 | +-----------------------------------------------------+ | 148 | | | | 149 | | SignedData | | 150 | | | | 151 | | +-------------------------------------------------+ | | 152 | | | | | | 153 | | | EnvelopedData | | | 154 | | | | | | 155 | | | +---------------------------------------------+ | | | 156 | | | | | | | | 157 | | | | NTS Message Object | | | | 158 | | | | | | | | 159 | | | | | | | | 160 | | | +---------------------------------------------+ | | | 161 | | | | | | 162 | | +-------------------------------------------------+ | | 163 | | | | 164 | +-----------------------------------------------------+ | 165 | | 166 +---------------------------------------------------------+ 168 NTS-Signed: This archetype is used for server_assoc and server_bpar 169 message types. It uses the following CMS structure: 171 First, the NTS message object MUST be wrapped in a SignedData 172 content type. The messages MUST be digitally signed, and 173 certificates included. SignedData supports nearly any form of 174 digital signature, and in the NTS protocol the server will 175 include its certificate within the SignedData content type. 177 Second, the SignedData content type MUST be encapsulated in a 178 ContentInfo content type. 180 Figure 2 illustrates this structure. 182 +---------------------------------------------------------+ 183 | | 184 | ContentInfo | 185 | | 186 | +-----------------------------------------------------+ | 187 | | | | 188 | | SignedData | | 189 | | | | 190 | | +-------------------------------------------------+ | | 191 | | | | | | 192 | | | NTS Message Object | | | 193 | | | | | | 194 | | | | | | 195 | | +-------------------------------------------------+ | | 196 | | | | 197 | +-----------------------------------------------------+ | 198 | | 199 +---------------------------------------------------------+ 201 NTS-Certified: This archetype is used for the client_cook message 202 type. It uses a CMS structure much like the NTS-Signed archetype 203 (see Figure 2), with the only difference being that messages 204 SHOULD NOT be digitally signed. This archetype employs the CMS 205 structure merely in order to transport certificates. 207 Whichever archetype is used, the resulting structure is always 208 transported in an extension field of an NTP packet. In the case of 209 messages that also need to carry time synchronization data, this data 210 is written into the regular fields of the NTP packet. 212 2.1. Fields of the employed CMS Content Types 214 Overall, three CMS content types are used for NTS messages: 215 ContentInfo, SignedData and EnvelopedData. The following is a 216 description of how the fields of those content types are used in 217 detail. 219 2.1.1. ContentInfo 221 The ContentInfo content type is used in all four archetypes. The 222 fields of the SignedData content type are used as follows: 224 contentType -- indicates the type of the associated content. For 225 the archetype NTS-Plain, it MUST identify the NTS message object 226 that is included. For all other archetypes (NTS-Certified, NTS- 227 Signed and NTS-Signed-and-Encrypted), it MUST contain the object 228 identifier for the SignedData content type: 230 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 231 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 233 content is the associated content. For the NTS-Plain archetype, 234 it MUST contain the DER encoded NTS message object. For all other 235 archetypes, it MUST contain the DER encoded SignedData content 236 type. 238 2.1.2. SignedData 240 The SignedData content type is used in the NTS-Certified, NTS-Signed 241 and NTS-Signed-and-Encrypted archetypes but not in the NTS-Plain 242 archetype. The fields of the SignedData content type are used as 243 follows: 245 version -- the appropriate value depends on the optional items 246 that are included. In the NTS protocol, the signer certificate 247 MUST be included, and other items MAY be included. The 248 instructions in [RFC5652] section 5.1 MUST be followed to set the 249 correct value. 251 digestAlgorithms -- is a collection of message digest algorithm 252 identifiers. In the NTS protocol, there MUST be exactly one 253 algorithm identifier present. The instructions in Section 5.4 of 254 [RFC5652] MUST be followed. 256 encapContentInfo -- this structure is always present. In the NTS 257 protocol, it MUST follow these conventions: 259 eContentType -- is an object identifier. In the NTS protocol, 260 for the NTS-Certified and NTS-Signed archetypes, it MUST 261 identify the type of the NTS message that was encapsulated. 262 For the NTS-Signed-and-Encrypted archetype, it MUST contain the 263 object identifier for the EnvelopedData content type: 265 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 266 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }. 268 eContent is the content itself, carried as an octet string. 269 For the NTS-Certified and NTS-Signed archetypes, it MUST 270 contain the DER encoded encapsulated NTS message object. The 271 instructions in Section 6.3 of [RFC5652] MUST be followed. For 272 the NTS-Signed-and-Encrypted archetype, it MUST contain the DER 273 encoded EnvelopedData content type. 275 certificates -- is a collection of certificates. In the NTS 276 protocol, it MUST contain the DER encoded certificate [RFC5280] of 277 the sender. It is intended that the collection of certificates be 278 sufficient for the recipient to construct a certification path 279 from a recognized "root" or "top-level certification authority" to 280 the certificate used by the sender. 282 crls -- is a collection of revocation status information. In the 283 NTS protocol, it MAY contain one or more DER encoded CRLs 284 [RFC5280]. It is intended that the collection contain information 285 sufficient to determine whether the certificates in the 286 certificates field are valid. 288 signerInfos -- is a collection of per-signer information. In the 289 NTS protocol, for the NTS-Certified archetype, this SHOULD be left 290 out. For both the NTS-Signed and the NTS-Signed-and-Encrypted 291 archetypes, there MUST be exactly one SignerInfo structure 292 present. The details of the SignerInfo type are discussed in 293 Section 5.3 of [RFC5652]. In the NTS protocol, it MUST follow 294 these conventions: 296 version -- is the syntax version number. In the NTS protocol, 297 the SignerIdentifier is subjectKeyIdentifier, therefore the 298 version MUST be 3. 300 sid -- identifies the signer's certificate. In the NTS 301 protocol, the sid field contains the subjectKeyIdentifier from 302 the signer's certificate. 304 digestAlgorithm -- identifies the message digest algorithm, and 305 any associated parameters, used by the signer. In the NTS 306 protocol, the identifier MUST match the single algorithm 307 identifier present in the digestAlgorithms. 309 signedAttrs -- is a collection of attributes that are signed. 310 In the NTS protocol, it MUST be present, and it MUST contain 311 the following attributes: 313 Content Type -- see Section 11.1 of [RFC5652]. 315 Message Digest -- see Section 11.2 of [RFC5652]. 317 In addition, it MAY contain the following attributes: 319 Signing Time -- see Section 11.3 of [RFC5652]. 321 Binary Signing Time -- see Section 3 of [RFC5652]. 323 signatureAlgorithm -- identifies the signature algorithm, and 324 any associated parameters, used by the signer to generate the 325 digital signature. 327 signature is the result of digital signature generation, using 328 the message digest and the signer's private key. The 329 instructions in Section 5.5 of [RFC5652] MUST be followed. 331 unsignedAttrs -- is an optional collection of attributes that 332 are not signed. In the NTS protocol, the it MUST be absent. 334 2.1.3. EnvelopedData 336 The EnvelopedData content type is used only in the NTS-Signed-and- 337 Encrypted archetype. The fields of the EnvelopedData content type 338 are used as follows: 340 version -- the appropriate value depends on the type of key 341 management that is used. The instructions in [RFC5652] section 342 6.1 MUST be followed to set the correct value. 344 originatorInfo -- this structure is present only if required by 345 the key management algorithm. In the NTS protocol, it MUST be 346 present when a key agreement algorithm is used, and it MUST absent 347 when a key transport algorithm is used. The instructions in 348 Section 6.1 of [RFC5652] MUST be followed. 350 recipientInfos -- this structure is always present. In the NTS 351 protocol, it MUST contain exactly one entry that allows the client 352 to determine the key used to encrypt the NTS message. The 353 instructions in Section 6.2 of [RFC5652] MUST be followed. 355 encryptedContentInfo -- this structure is always present. In the 356 NTS protocol, it MUST follow these conventions: 358 contentType -- indicates the type of content. In the NTS 359 protocol, it MUST identify the type of the NTS message that was 360 encrypted. 362 contentEncryptionAlgorithm -- identifies the content-encryption 363 algorithm, and any associated parameters, used to encrypt the 364 content. 366 encryptedContent -- is the encrypted the content. In the NTS 367 protocol, it MUST contain the encrypted NTS message. The 368 instructions in Section 6.3 of [RFC5652] MUST be followed. 370 unprotectedAttrs -- this structure is optional. In the NTS 371 protocol, it MUST be absent. 373 3. Certificate Conventions 375 The syntax and processing rules for certificates are specified in 376 [RFC5652]. In the NTS protocol, the server certificate MUST contain 377 the following extensions: 379 Subject Key Identifier -- see Section 4.2.1.2 of [RFC5652]. 381 Key Usage -- see Section 4.2.1.3 of [RFC5652]. 383 Extended Key Usage -- see Section 4.2.1.22 of [RFC5652]. 385 The Extended Key Usage extension MUST include the id-kp-NTSserver 386 object identifier. When a certificate issuer includes this object 387 identifier in the extended key usage extension, it provides an 388 attestation that the certificate subject is a time server that 389 supports the NTS protocol. 391 The id-kp-NTSserver object identifier is: 393 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 395 4. Implementation Notes: ASN.1 Structures and Use of the CMS 397 This section gives some hints on the structures of the NTS message 398 objects for the different message types when one wishes to implement 399 the protocol. 401 4.1. Preliminaries 403 The following ASN.1 coded data type "NTSNonce" is needed for other 404 types used below for NTS messages. It specifies a 128 bit nonce as 405 required in several message types: 407 NTSNonce ::= OCTET STRING (SIZE(16)) 409 4.2. Unicast Messages 411 4.2.1. Association Messages 413 4.2.1.1. Message Type: "client_assoc" 415 This message is structured according to the NTS-Plain archetype. It 416 is realized as an NTP packet with an extension field which holds all 417 the data relevant for NTS. Explicitly, the extension field contains 418 an ASN.1 object of type "ClientAssocData", which is structured as 419 follows: 421 ClientAssocData ::= SEQUENCE { 422 clientId SubjectKeyIdentifier, 423 digestAlgos DigestAlgorithmIdentifiers, 424 keyEncAlgos KeyEncryptionAlgorithms, 425 contentEncAlgos ContentEncryptionAlgorithms 426 } 428 4.2.1.2. Message Type: "server_assoc" 430 This message is structured according to the NTS-Signed archetype. 431 The NTS message object in this case is an ASN.1 object of type 432 "ServerAssocData", which is structured as follows: 434 ServerAssocData ::= SEQUENCE { 435 clientId SubjectKeyIdentifier, 436 choiceDigestAlgo DigestAlgorithmIdentifier, 437 choiceKeyEncAlgo KeyEncryptionAlgorithmIdentifier, 438 choiceContentEncAlgo ContentEncryptionAlgorithmIdentifier 439 } 441 4.2.2. Cookie Messages 443 4.2.2.1. Message Type: "client_cook" 445 This message is structured according to the NTS-Certified archetype. 446 The NTS message object is a "ClientCookieData" type ASN.1 object, 447 structured as follows: 449 ClientCookieData ::= SEQUENCE { 450 nonce NTSNonce, 451 signAlgo SignatureAlgorithmIdentifier, 452 digestAlgo DigestAlgorithmIdentifier, 453 encAlgo ContentEncryptionAlgorithmIdentifier, 454 keyEncAlgo KeyEncryptionAlgorithmIdentifier 455 } 457 It is identified by the following object identifier (fictional 458 values): 460 id-clientCookieData OBJECT IDENTIFIER ::= 461 {nts(??) cookie(3) clientcookiedata(1)} 463 4.2.2.2. Message Type: "server_cook" 465 This message is structured according to the "NTS-Signed-and- 466 Encrypted" archetype. The NTS message object is a "ServerCookieData" 467 object, specified as: 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 4.2.3. Time Synchronization Messages 482 4.2.3.1. Message Type: "time_request" 484 This message is structured according to the "NTS-Plain" archetype. 485 It is realized as an NTP packet which actually contains regular NTP 486 time synchronization data, as an unsecured NTP packet from a client 487 to a server would. Furthermore, the packet has an extension field 488 which contains an ASN.1 object of type "TimeRequestSecurityData", 489 whose structure is as follows: 491 TimeRequestSecurityData ::= 492 SEQUENCE { 493 nonce_t NTSNonce, 494 digestAlgo DigestAlgorithmIdentifier, 495 hashOfClientCert BIT STRING 496 } 498 4.2.3.2. Message Type: "time_response" 500 This message is also structured according to "NTS-Plain". It is 501 realized as an NTP packet which, like "time_request", contains 502 regular NTP time synchronization data, as an unsecured NTP packet 503 from a server back to a client would. The packet also has an 504 extension field which contains an ASN.1 object of type 505 "TimeResponseSecurityData", with the following structure: 507 TimeResponseSecurityData ::= 508 SEQUENCE { 509 nonce_t NTSNonce, 510 } 512 Finally, this NTP packet has a MAC field which contains a Message 513 Authentication Code generated over the whole packet (including the 514 extension field). 516 4.3. Broadcast Messages 518 4.3.1. Broadcast Parameter Messages 520 4.3.1.1. Message Type: "client_bpar" 522 This first broadcast message is structured according to the NTS-Plain 523 archetype. It is realized as an NTP packet which is empty except for 524 an extension field which contains ans ASN.1 object of type 525 "BroadcastParameterRequest", which is structured as follows: 527 BroadcastParameterRequest ::= 528 SEQUENCE { 529 clientId SubjectKeyIdentifier 530 } 532 4.3.1.2. Message Type: "server_bpar" 534 This message is structured according to "NTS-Signed". It is realized 535 as an NTP packet whose extension field carries the necessary CMS 536 structure. The NTS message object in this case is an ASN.1 object of 537 type "BroadcastParameterResponse", with the following structure: 539 BroadcastParameterRequest ::= 540 SEQUENCE { 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 4.3.2. Broadcast Time Synchronization Message 552 4.3.2.1. Message Type: "server_broad" 554 This message is structured according to the "NTS-Plain" archetype. 555 Its realization works via an NTP packet which carries regular NTP 556 broadcast time data as well as an extension field, which contains an 557 ASN.1 object of type "BroadcastTime". It has the following 558 structure: 560 BroadcastTime ::= 561 SEQUENCE { 562 thisIntervalIndex INTEGER, 563 disclosedKey OCTET STRING (SIZE (16)), 564 } 566 In addition, this packet has a MAC field which contains a Message 567 Authentication Code generated over the whole packet (including the 568 extension field). 570 4.3.3. Broadcast Keycheck 572 4.3.3.1. Message Type: "client_keycheck" 574 This message is structured according to the "NTS-Plain" archetype. 575 It is realized as an NTP packet with an extension field, which 576 contains an ASN.1 object of type "ClientKeyCheckSecurityData", whose 577 structure is as follows: 579 ClientKeyCheckSecurityData ::= 580 SEQUENCE { 581 nonce_k NTSNonce, 582 interval_number INTEGER, 583 digestAlgo DigestAlgorithmIdentifier, 584 hashOfClientCert BIT STRING 585 } 587 4.3.3.2. Message Type: "server_keycheck" 589 This message is also structured according to "NTS-Plain". It is also 590 realized as an NTP packet with an extension field, which contains an 591 ASN.1 object of type "ServerKeyCheckSecurityData", with the following 592 structure: 594 ServerKeyCheckSecurityData ::= 595 SEQUENCE { 596 nonce_t NTSNonce, 597 interval_number INTEGER 598 } 600 Additionally, this NTP packet has a MAC field which contains a 601 Message Authentication Code generated over the whole packet 602 (including the extension field). 604 5. IANA Considerations 606 IANA needs to assign an object identifier for id-kp-NTSserver key 607 purpose and another one for the ASN.1 module in the appendix. 609 6. Security Considerations 611 To be written. 613 7. References 615 7.1. Normative References 617 [ASN1] International Telecommunication Union, "Abstract Syntax 618 Notation One (ASN.1): Specification of basic notation", 619 ITU-T Recommendation X.680, November 2008. 621 [IEEE1588] 622 IEEE Instrumentation and Measurement Society. TC-9 Sensor 623 Technology, "IEEE standard for a precision clock 624 synchronization protocol for networked measurement and 625 control systems", 2008. 627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 628 Requirement Levels", BCP 14, RFC 2119, March 1997. 630 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 631 RFC 5652, September 2009. 633 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 634 Time Protocol Version 4: Protocol and Algorithms 635 Specification", RFC 5905, June 2010. 637 7.2. Informative References 639 [I-D.ietf-ntp-network-time-security] 640 Sibold, D., Roettger, S., and K. Teichel, "Network Time 641 Security", draft-ietf-ntp-network-time-security-04 (work 642 in progress), July 2014. 644 Appendix A. ASN.1 Module 646 The ASN.1 module contained in this appendix defines the id-kp- 647 NTSserver object identifier. 649 NTSserverKeyPurpose 650 { TBD } 652 DEFINITIONS IMPLICIT TAGS ::= 653 BEGIN 655 id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD } 657 END 659 Authors' Addresses 661 Dieter Sibold 662 Physikalisch-Technische Bundesanstalt 663 Bundesallee 100 664 Braunschweig D-38116 665 Germany 667 Phone: +49-(0)531-592-8420 668 Fax: +49-531-592-698420 669 Email: dieter.sibold@ptb.de 671 Stephen Roettger 672 Google Inc 674 Email: stephen.roettger@googlemail.com 676 Kristof Teichel 677 Physikalisch-Technische Bundesanstalt 678 Bundesallee 100 679 Braunschweig D-38116 680 Germany 682 Phone: +49-(0)531-592-8421 683 Email: kristof.teichel@ptb.de 685 Russ Housley 686 Vigil Security