idnits 2.17.1 draft-richardson-anima-ace-constrained-voucher-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-anima-voucher], [I-D.vanderstok-ace-coap-est]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 14, 2018) is 2262 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3688' is mentioned on line 590, but not defined == Missing Reference: 'RFC6020' is mentioned on line 604, but not defined == Missing Reference: 'ThisRFC' is mentioned on line 624, but not defined == Missing Reference: 'Empty' is mentioned on line 811, but not defined == Unused Reference: 'I-D.ietf-ace-cbor-web-token' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-object-security' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'ieee802-1AR' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 746, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-ace-cbor-web-token-12 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-09 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-08 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-03 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-06 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-05 Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6tisch Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational P. van der Stok 5 Expires: August 18, 2018 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 February 14, 2018 10 Constrained Voucher Profile for Bootstrapping Protocols 11 draft-richardson-anima-ace-constrained-voucher-03 13 Abstract 15 This document defines a strategy to securely assign a pledge to an 16 owner, using an artifact signed, directly or indirectly, by the 17 pledge's manufacturer. This artifact is known as a "voucher". 19 This document builds upon the work in [I-D.ietf-anima-voucher], 20 encoding the resulting artifact in CBOR. Use with two signature 21 technologies are described. 23 Additionally, this document explains how constrained vouchers may be 24 transported in the [I-D.vanderstok-ace-coap-est] protocol. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 18, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 64 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 4 65 6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 6 67 6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 6 68 6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 6 69 6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 7 70 6.1.4. Example voucher request artifacts . . . . . . . . . . 9 71 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 9 72 6.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 9 73 6.4. SID values . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.5.1. Example voucher artifacts . . . . . . . . . . . . . . 12 76 6.6. CMS format voucher and voucher-request artifacts . . . . 12 77 6.7. COSE format voucher and voucher-request artifacts . . . . 13 78 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 13 81 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 13 82 8.3. Test Domain Certificate Validity when Signing . . . . . . 13 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 13 85 9.2. The YANG Module Names Registry . . . . . . . . . . . . . 13 86 9.3. The SMI Security for S/MIME CMS Content Type Registry . . 14 87 9.4. The SID registry . . . . . . . . . . . . . . . . . . . . 14 88 9.5. Media-Type Registry . . . . . . . . . . . . . . . . . . . 14 89 9.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 15 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 11.2. Informative References . . . . . . . . . . . . . . . . . 17 94 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 17 95 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 18 96 A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 19 97 A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 19 98 A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction 103 Enrollment of new nodes into constrained networks with constrained 104 nodes present unique challenges. 106 There are bandwidth and code space issues to contend. A solution 107 such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in 108 terms of code space or bandwidth required. 110 This document defines a constrained version of 111 [I-D.ietf-anima-voucher]. Rather than serializing the YANG 112 definition in JSON, it is serialized into CBOR ([RFC7049]). 114 This document follows a similar, but not identical structure as 115 [I-D.ietf-anima-voucher]. Some sections are left out entirely. 116 Additional sections to [I-D.ietf-anima-voucher] concern: - Addition 117 of voucher-request specification as defined in 118 [I-D.ietf-anima-bootstrapping-keyinfra], - Addition to 119 [I-D.vanderstok-ace-coap-est] of voucher transport requests over 120 coap. 122 The CBOR definitions for this constrained voucher format are defined 123 using the mechanism describe in [I-D.ietf-core-yang-cbor] using the 124 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 125 convert YANG documents into an list of SID keys is still in its 126 infancy, the table of SID values presented here should be considered 127 normative rather than the output of the pyang tool. 129 Two methods of signing the resulting CBOR object are described in 130 this document. One is CMS [RFC5652]. The other is COSE [RFC8152] 131 signatures. 133 2. Terminology 135 The following terms are defined in [I-D.ietf-anima-voucher], and are 136 used identically as in that document: artifact, imprint, domain, Join 137 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 138 Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher. 140 3. Requirements Language 142 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 143 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 144 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 145 [RFC2119] and indicate requirement levels for compliant STuPiD 146 implementations. 148 4. Survey of Voucher Types 150 [I-D.ietf-anima-voucher] provides for vouchers that assert proximity, 151 that authenticate the registrar and that include different amounts of 152 anti-replay protection. 154 This document does not make any extensions to the types of vouchers. 156 Time based vouchers are included in this definition, but given that 157 constrained devices are extremely unlikely to know the correct time, 158 their use is very unlikely. Most users of these constrained vouchers 159 will be online and will use live nonces to provide anti-replay 160 protection. 162 [I-D.ietf-anima-voucher] defined only the voucher artifact, and not 163 the Voucher Request artifact, which was defined in 164 [I-D.ietf-anima-bootstrapping-keyinfra]. 166 This document defines both a constrained voucher and a constrained 167 voucher-request. They are presented in the order voucher-request, 168 followed by voucher response as this is the time order that they 169 occur. 171 5. Discovery and URI 173 This section describes the BRSKI extensions to EST-coaps 174 [I-D.vanderstok-ace-coap-est] to transport the voucher between 175 registrar, proxy and pledge over CoAP. 177 The extension is targeted to low-resource networks with small 178 packets. Saving header space is important and the EST-coaps URI is 179 shorter than the EST URI. 181 The presence and location of (path to) the management data are 182 discovered by sending a GET request to "/.well-known/core" including 183 a resource type (RT) parameter with the value "ace.est" [RFC6690]. 184 Upon success, the return payload will contain the root resource of 185 the EST resources. It is up to the implementation to choose its root 186 resource; throughout this document the example root resource /est is 187 used. The example below shows the discovery of the presence and 188 location of voucher resources. 190 REQ: GET /.well-known/core?rt=ace.est 192 RES: 2.05 Content 193 ; rt="ace.est" 195 The EST-coaps server URIs differ from the EST URI by replacing the 196 scheme https by coaps and by specifying shorter resource path names: 198 coaps://www.example.com/est/short-name 200 Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and 201 corresponding paths which are supported by EST. Table 1 provides the 202 mapping from the BRSKI extension URI path to the EST-coaps URI path. 204 +------------------+-----------+ 205 | BRSKI | EST-coaps | 206 +------------------+-----------+ 207 | /requestvoucher | /rv | 208 | | | 209 | /voucher-status | /vs | 210 | | | 211 | /enrollstatus | /es | 212 | | | 213 | /requestauditlog | /ra | 214 +------------------+-----------+ 216 Table 1: BRSKI path to EST-coaps path 218 /requestvoucher and /enrollstatus are needed between pledge and 219 Registrar. 221 When discovering the root path for the EST resources, the server MAY 222 return the full resource paths and the used content types. This is 223 useful when multiple content types are specified for EST-coaps 224 server. For example, the following more complete response is 225 possible. 227 REQ: GET /.well-known/core?rt=ace.est 229 RES: 2.05 Content 230 ; rt="ace.est" 231 ; rt="ace.est";ct=50 TBD2 16 232 ; rt="ace.est";ct=50 233 ; rt="ace.est";ct=50 234 ; rt="ace.est";ct= TBD2 16 236 ct=50 stands for the Content-Format "application/json", ct=16 stands 237 for the Content-Format "application/cose", and ct=TBD2 stands for 238 Content-Format "application/voucher-cms+cbor defined in this 239 document. 241 The return of the content-types allows the client to choose the most 242 appropriate one from multiple content types. 244 6. Artifacts 246 This section describes the abstract (tree) definition as explained in 247 [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- 248 level view of the contents of each artifact. 250 Then the assigned SID values are presented. These have been assigned 251 using the rules in [I-D.ietf-core-yang-cbor], with an allocation that 252 was made via the http://comi.space service. 254 ((EDNOTE: it is unclear if there is further IANA work)) 256 6.1. Voucher Request artifact 258 6.1.1. Tree Diagram 260 module: ietf-cwt-voucher-request 262 grouping voucher-request-cwt-grouping 263 +---- voucher 264 +---- created-on 265 | yang:date-and-time 266 +---- expires-on? 267 | yang:date-and-time 268 +---- assertion 269 | enumeration 270 +---- serial-number string 271 +---- idevid-issuer? binary 272 +---- pinned-domain-cert binary 273 +---- domain-cert-revocation-checks? boolean 274 +---- nonce? binary 275 +---- last-renewal-date? 276 | yang:date-and-time 277 +---- proximity-registrar-subject-public-key-info? binary 279 6.1.2. SID values 281 [EDNote: the appropriate generation of the SID values is under 282 discussion] 283 SID Assigned to 284 --------- -------------------------------------------------- 285 1001150 module ietf-cwt-voucher-request 286 1001151 module ietf-restconf 287 1001152 module ietf-voucher 288 1001153 module ietf-yang-types 289 1001154 data .../ietf-cwt-voucher-request:voucher 290 1001155 data .../assertion 291 1001156 data .../created-on 292 1001157 data .../domain-cert-revocation-checks 293 1001158 data .../expires-on 294 1001159 data .../idevid-issuer 295 1001160 data .../last-renewal-date 296 1001161 data .../nonce 297 1001162 data .../pinned-domain-cert 298 1001163 data .../proximity-registrar-subject-public-key-info 299 1001164 data .../serial-number 301 6.1.3. YANG Module 303 [EDNote: the appropriate syntax of the module is under discussion] 305 file "ietf-cwt-voucher-request@2017-12-11.yang" 306 /* -*- c -*- */ 307 module ietf-cwt-voucher-request { 308 yang-version 1.1; 310 namespace 311 "urn:ietf:params:xml:ns:yang:ietf-cwt-voucher-request"; 312 prefix "vcwt"; 314 import ietf-voucher { 315 prefix "v"; 316 } 318 organization 319 "IETF 6tisch Working Group"; 321 contact 322 "WG Web: 323 WG List: 324 Author: Michael Richardson 325 "; 327 description 328 "This module defines the format for a voucher, which is produced by 329 a pledge's manufacturer or delegate (MASA) to securely assign one 330 or more pledges to an 'owner', so that the pledges may establish a 331 secure connection to the owner's network infrastructure. 333 This version provides a very restricted subset appropriate 334 for very constrained devices. 335 In particular, it assumes that nonce-ful operation is 336 always required, that expiration dates are rather weak, as no 337 clocks can be assumed, and that the Registrar is identified 338 by a pinned Raw Public Key. 340 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 341 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 342 the module text are to be interpreted as described in RFC 2119."; 344 revision "2017-12-11" { 345 description 346 "Initial version"; 347 reference 348 "RFC XXXX: Voucher Profile for Constrained Devices"; 349 } 351 // Grouping defined for future usage 352 grouping voucher-request-cwt-grouping { 353 description 354 "Grouping to allow reuse/extensions in future work."; 356 uses v:voucher-artifact-grouping { 357 augment "voucher" { 358 description "Base the CWT voucher-request upon the regular one"; 359 leaf proximity-registrar-subject-public-key-info { 360 type binary; 361 description 362 "The proximity-registrar-subject-public-key-info replaces 363 the proximit-registrar-cert in constrained uses of 364 the voucher-request. 365 The proximity-registrar-subject-public-key-info is the 366 Raw Public Key of the Registrar. This field is encoded 367 as specified in RFC7250, section 3. 368 The ECDSA algorithm MUST be supported. 369 The EdDSA algorithm as specified in 370 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 371 Support for the DSA algorithm is not recommended. 372 Support for the RSA algorithm is a MAY."; 373 } 374 } 375 } 376 } 377 } 378 379 6.1.4. Example voucher request artifacts 381 TBD 383 6.2. Voucher artifact 385 The voucher's primary purpose is to securely assign a pledge to an 386 owner. The voucher informs the pledge which entity it should 387 consider to be its owner. 389 This document defines a voucher that is a CBOR encoded instance of 390 the YANG module defined in Section 5.3 that has been signed with CMS 391 or with COSE. 393 6.3. Tree Diagram 395 module: ietf-cwt-voucher 397 grouping voucher-cwt-grouping 398 +---- voucher 399 +---- created-on 400 | yang:date-and-time 401 +---- expires-on? 402 | yang:date-and-time 403 +---- assertion enumeration 404 +---- serial-number string 405 +---- idevid-issuer? binary 406 +---- pinned-domain-cert binary 407 +---- domain-cert-revocation-checks? boolean 408 +---- nonce? binary 409 +---- last-renewal-date? 410 | yang:date-and-time 411 +---- pinned-domain-subject-public-key-info? binary 413 6.4. SID values 415 [EDNote: the appropriate generation of the SID values is under 416 discussion] 417 SID Assigned to 418 --------- -------------------------------------------------- 419 1001100 module ietf-cwt-voucher 420 1001101 module ietf-restconf 421 1001102 module ietf-voucher 422 1001103 module ietf-yang-types 423 1001104 data .../ietf-cwt-voucher:voucher 424 1001105 data .../assertion 425 1001106 data .../created-on 426 1001107 data .../domain-cert-revocation-checks 427 1001108 data .../expires-on 428 1001109 data .../idevid-issuer 429 1001110 data .../last-renewal-date 430 1001111 data .../nonce 431 1001112 data .../pinned-domain-cert 432 1001113 data .../pinned-domain-subject-public-key-info 433 1001114 data .../serial-number 435 6.5. YANG Module 437 [EDNote: the appropriate syntax of the module is under discussion] 439 file "ietf-cwt-voucher@2017-12-11.yang" 440 /* -*- c -*- */ 441 module ietf-cwt-voucher { 442 yang-version 1.1; 444 namespace 445 "urn:ietf:params:xml:ns:yang:ietf-cwt-voucher"; 446 prefix "vcwt"; 448 import ietf-voucher { 449 prefix "v"; 450 } 452 organization 453 "IETF 6tisch Working Group"; 455 contact 456 "WG Web: 457 WG List: 458 Author: Michael Richardson 459 "; 461 description 462 "This module defines the format for a voucher, which is produced by 463 a pledge's manufacturer or delegate (MASA) to securely assign one 464 or more pledges to an 'owner', so that the pledges may establish a 465 secure connection to the owner's network infrastructure. 467 This version provides a very restricted subset appropriate 468 for very constrained devices. 469 In particular, it assumes that nonce-ful operation is 470 always required, that expiration dates are rather weak, as no 471 clocks can be assumed, and that the Registrar is identified 472 by a pinned Raw Public Key. 474 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 475 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 476 the module text are to be interpreted as described in RFC 2119."; 478 revision "2017-12-11" { 479 description 480 "Initial version"; 481 reference 482 "RFC XXXX: Voucher Profile for Constrained Devices"; 483 } 485 // Grouping defined for future usage 486 grouping voucher-cwt-grouping { 487 description 488 "Grouping to allow reuse/extensions in future work."; 490 uses v:voucher-artifact-grouping { 491 augment "voucher" { 492 description "Base the CWT voucher upon the regular one"; 493 leaf pinned-domain-subject-public-key-info { 494 type binary; 495 description 496 "The pinned-domain-subject replaces the 497 pinned-domain-certificate in constrained uses of 498 the voucher. The pinned-domain-public-key-info is the 499 Raw Public Key of the Registrar. This field is encoded 500 as specified in RFC7250, section 3. 501 The ECDSA algorithm MUST be supported. 502 The EdDSA algorithm as specified in 503 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 504 Support for the DSA algorithm is not recommended. 505 Support for the RSA algorithm is a MAY."; 506 } 507 } 508 } 509 } 510 } 511 513 6.5.1. Example voucher artifacts 515 TBD 517 6.6. CMS format voucher and voucher-request artifacts 519 The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed 520 voucher is much like the equivalent voucher defined in 521 [I-D.ietf-anima-voucher]. 523 A different eContentType of TBD1 is used to indicate that the 524 contents are in a different format than in [I-D.ietf-anima-voucher]. 526 The ContentInfo structure contains a payload consisting of the CBOR 527 encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding 528 creates a canonical ordering for the keys on the wire. This 529 canonical ordering is not important as there is no expectation that 530 the content will be reproduced during the validation process. 532 Normally the recipient is the pledge and the signer is the MASA. 534 [I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and 535 unsigned voucher requests from the pledge to the JRC. In this 536 specification, voucher-request artifact is not signed from the pledge 537 to the registrar. From the JRC to the MASA, the voucher-request 538 artifact MUST be signed by the domain owner key which is requesting 539 ownership. 541 The considerations of [RFC5652] section 5.1, concerning validating 542 CMS objects which are really PKCS7 objects (cmsVersion=1) applies. 544 The CMS structure SHOULD also contain all the certificates leading up 545 to and including the signer's trust anchor certificate known to the 546 recipient. The inclusion of the trust anchor is unusual in many 547 applications, but without it third parties can not accurately audit 548 the transaction. 550 The CMS structure MAY also contain revocation objects for any 551 intermediate certificate authorities (CAs) between the voucher-issuer 552 and the trust anchor known to the recipient. However, the use of 553 CRLs and other validity mechanisms is discouraged, as the pledge is 554 unlikely to be able to perform online checks, and is unlikely to have 555 a trusted clock source. As described below, the use of short-lived 556 vouchers and/or pledge provided nonce provides a freshness guarantee. 558 6.7. COSE format voucher and voucher-request artifacts 560 This section to be added. 562 7. Design Considerations 564 The design considerations for the CBOR encoding of vouchers is much 565 the same as for [I-D.ietf-anima-voucher]. 567 One key difference is that the names of the leaves in the YANG does 568 not have a material effect on the size of the resulting CBOR, as the 569 SID translation process assigns integers to the names. 571 8. Security Considerations 573 8.1. Clock Sensitivity 575 TBD. 577 8.2. Protect Voucher PKI in HSM 579 TBD. 581 8.3. Test Domain Certificate Validity when Signing 583 TBD. 585 9. IANA Considerations 587 9.1. The IETF XML Registry 589 This document registers two URIs in the IETF XML registry [RFC3688]. 590 Following the format in [RFC3688], the following registration is 591 requested: 593 URI: urn:ietf:params:xml:ns:yang:ietf-cwt-voucher 594 Registrant Contact: The ANIMA WG of the IETF. 595 XML: N/A, the requested URI is an XML namespace. 597 URI: urn:ietf:params:xml:ns:yang:ietf-cwt-voucher-request 598 Registrant Contact: The ANIMA WG of the IETF. 599 XML: N/A, the requested URI is an XML namespace. 601 9.2. The YANG Module Names Registry 603 This document registers two YANG modules in the YANG Module Names 604 registry [RFC6020]. Following the format defined in [RFC6020], the 605 the following registration is requested: 607 name: ietf-cwt-voucher 608 namespace: urn:ietf:params:xml:ns:yang:ietf-cwt-voucher 609 prefix: vch 610 reference: RFC XXXX 612 name: ietf-cwt-voucher-request 613 namespace: urn:ietf:params:xml:ns:yang:ietf-cwt-voucher-request 614 prefix: vch 615 reference: RFC XXXX 617 9.3. The SMI Security for S/MIME CMS Content Type Registry 619 This document registers an OID in the "SMI Security for S/MIME CMS 620 Content Type" registry (1.2.840.113549.1.9.16.1), with the value: 622 Decimal Description References 623 ------- -------------------------------------- ---------- 624 TBD1 id-ct-animaCBORVoucher [ThisRFC] 626 EDNOTE: should a separate value be used for Voucher Requests? 628 9.4. The SID registry 630 The SID range 1001100 was allocated by comi.space to the IETF-CWT- 631 VOUCHER yang module. 633 The SID range 1001150 was allocated by comi.space to the IETF-CWT- 634 VOUCHER-REQUEST yang module. 636 EDNOTE: it is unclear if there is further IANA work required. 638 9.5. Media-Type Registry 640 This section registers the 'application/voucher-cms+cbor' media type 641 in the "Media Types" registry. These media types are used to 642 indicate that the content is a CBOR voucher signed with a cms 643 structure. 645 Type name: application 646 Subtype name: voucher-cms+cbor 647 Required parameters: none 648 Optional parameters: none 649 Encoding considerations: CMS-signed CBOR vouchers are CBOR 650 encoded. 651 Security considerations: See Security Considerations, Section 652 Interoperability considerations: The format is designed to be 653 broadly interoperable. 654 Published specification: THIS RFC. 655 Applications that use this media type: ANIMA, 6tisch, and other 656 zero-touch imprinting systems 657 Additional information: 658 Magic number(s): None 659 File extension(s): .cbor 660 Macintosh file type code(s): none 661 Person & email address to contact for further information: IETF 662 ANIMA WG 663 Intended usage: LIMITED 664 Restrictions on usage: NONE 665 Author: ANIMA WG 666 Change controller: IETF 667 Provisional registration? (standards tree only): NO 669 9.6. CoAP Content-Format Registry 671 Additions to the sub-registry "CoAP Content-Formats", within the 672 "CoRE Parameters" registry are needed for the below media types. 673 These can be registered either in the Expert Review range (0-255) or 674 IETF Review range (256-9999). Addition: Type name: application 675 Subtype name: voucher-cms+cbor ID: TBD2 Required parameters: None 676 Optional parameters: None Encoding considerations: CBOR Security 677 considerations: As defined in this specification Published 678 specification: this document Applications that use this media type: 679 ANIMA bootstrap (BRSKI) 681 10. Acknowledgements 683 TBD 685 11. References 687 11.1. Normative References 689 [I-D.ietf-ace-cbor-web-token] 690 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 691 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-12 692 (work in progress), February 2018. 694 [I-D.ietf-anima-bootstrapping-keyinfra] 695 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 696 S., and K. Watsen, "Bootstrapping Remote Secure Key 697 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 698 keyinfra-09 (work in progress), October 2017. 700 [I-D.ietf-anima-voucher] 701 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 702 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 703 anima-voucher-07 (work in progress), January 2018. 705 [I-D.ietf-core-object-security] 706 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 707 "Object Security for Constrained RESTful Environments 708 (OSCORE)", draft-ietf-core-object-security-08 (work in 709 progress), January 2018. 711 [I-D.ietf-core-sid] 712 Veillette, M. and A. Pelov, "YANG Schema Item iDentifier 713 (SID)", draft-ietf-core-sid-03 (work in progress), 714 December 2017. 716 [I-D.ietf-core-yang-cbor] 717 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 718 Minaburo, "CBOR Encoding of Data Modeled with YANG", 719 draft-ietf-core-yang-cbor-06 (work in progress), February 720 2018. 722 [I-D.vanderstok-ace-coap-est] 723 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 724 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 725 coaps)", draft-vanderstok-ace-coap-est-04 (work in 726 progress), January 2018. 728 [ieee802-1AR] 729 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 730 2009, . 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, 735 DOI 10.17487/RFC2119, March 1997, 736 . 738 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 739 RFC 5652, DOI 10.17487/RFC5652, September 2009, 740 . 742 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 743 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 744 October 2013, . 746 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 747 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 748 Transport Layer Security (TLS) and Datagram Transport 749 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 750 June 2014, . 752 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 753 RFC 8152, DOI 10.17487/RFC8152, July 2017, 754 . 756 11.2. Informative References 758 [duckling] 759 Stajano, F. and R. Anderson, "The resurrecting duckling: 760 security issues for ad-hoc wireless networks", 1999, 761 . 764 [I-D.ietf-netmod-yang-tree-diagrams] 765 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 766 ietf-netmod-yang-tree-diagrams-05 (work in progress), 767 January 2018. 769 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 770 . 772 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 773 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 774 . 776 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 777 "Enrollment over Secure Transport", RFC 7030, 778 DOI 10.17487/RFC7030, October 2013, 779 . 781 Appendix A. EST messages to EST-coaps 783 This section extends the examples from Appendix A of 784 [I-D.vanderstok-ace-coap-est]. The CoAP headers are only worked out 785 for the enrollstatus example. 787 A.1. enrollstatus 789 A coaps enrollstatus message can be : 791 GET coaps://[192.0.2.1:8085]/est/es 793 The corresponding coap header fields are shown below. 795 Ver = 1 796 T = 0 (CON) 797 Code = 0x01 (0.01 is GET) 798 Options 799 Option1 (Uri-Host) 800 Option Delta = 0x3 (option nr = 3) 801 Option Length = 0x9 802 Option Value = 192.0.2.1 803 Option2 (Uri-Port) 804 Option Delta = 0x4 (option nr = 4+3=7) 805 Option Length = 0x4 806 Option Value = 8085 807 Option3 (Uri-Path) 808 Option Delta = 0x4 (option nr = 7+4= 11) 809 Option Length = 0x7 810 Option Value = /est/es 811 Payload = [Empty] 813 A 2.05 Content response with an unsigned JSON voucher (ct=50) will 814 then be: 816 2.05 Content (Content-Format: application/json) 817 {payload} 819 With CoAP fields and payload: 821 Ver=1 822 T=2 (ACK) 823 Code = 0x45 (2.05 Content) 824 Options 825 Option1 (Content-Format) 826 Option Delta = 0xC (option nr 12) 827 Option Length = 0x2 828 Option Value = 0x32 (application/json) 830 Payload = 831 [EDNOTE: put here voucher payload ] 833 A.2. voucher_status 835 A coaps voucher_status message can be : 837 GET coaps://[2001:db8::2:1]:61616]/est/vs 839 A 2.05 Content response with a non signed JSON voucher (ct=50) will 840 then be: 842 2.05 Content (Content-Format: application/json) 843 Payload = 844 [EDNOTE: put here voucher payload ] 846 A.3. requestvoucher 848 A coaps requestvoucher message can be : 850 GET coaps://[2001:db8::2:1]:61616]/est/rv 852 A 2.05 Content response returning CBOR voucher signed with a cms 853 structure(ct=TBD2) will then be: 855 2.05 Content (Content-Format: application/voucher-cms+cbor) 856 Payload = 857 [EDNOTE: put here encrypted voucher payload ] 859 A.4. requestauditing 861 A coaps requestauditing message can be : 863 GET coaps://[2001:db8::2:1]:61616]/est/ra 865 A 2.05 Content response with a COSE voucher (ct=16) will then be: 867 2.05 Content (Content-Format: application/cose) 868 Payload = 869 [EDNOTE: put here COSE voucher payload ] 871 Authors' Addresses 873 Michael Richardson 874 Sandelman Software Works 876 Email: mcr+ietf@sandelman.ca 877 Peter van der Stok 878 vanderstok consultancy 880 Email: consultancy@vanderstok.org 882 Panos Kamapanakis 883 Cisco Systems 885 Email: pkampana@cisco.com