idnits 2.17.1 draft-ietf-anima-constrained-voucher-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-ace-coap-est], [RFC8366]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 419 has weird spacing: '...ndatory false...' == Line 423 has weird spacing: '...ndatory false...' == Line 642 has weird spacing: '...ndatory false...' == Line 646 has weird spacing: '...ndatory false...' == 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 (September 11, 2018) is 2054 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: 'RFC3688' is mentioned on line 797, but not defined == Missing Reference: 'RFC6020' is mentioned on line 811, but not defined == Missing Reference: 'ThisRFC' is mentioned on line 832, but not defined == Missing Reference: 'This RFC' is mentioned on line 914, but not defined == Missing Reference: 'Empty' is mentioned on line 1070, but not defined == Unused Reference: 'I-D.ietf-ace-cbor-web-token' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-object-security' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'ieee802-1AR' is defined on line 978, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 996, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-05 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-16 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-14 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-04 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 3 errors (**), 0 flaws (~~), 21 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track P. van der Stok 5 Expires: March 15, 2019 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 September 11, 2018 10 Constrained Voucher Artifacts for Bootstrapping Protocols 11 draft-ietf-anima-constrained-voucher-02 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 [RFC8366], encoding the 20 resulting artifact in CBOR. Use with two signature technologies are 21 described. 23 Additionally, this document explains how constrained vouchers may be 24 transported in the [I-D.ietf-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 March 15, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 64 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 7 67 6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 7 68 6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 7 69 6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 8 70 6.1.4. Example voucher request artifact . . . . . . . . . . 11 71 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 12 72 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 12 73 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 13 74 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 13 75 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 15 76 6.3. CMS format voucher and voucher-request artifacts . . . . 16 77 6.3.1. COSE signing . . . . . . . . . . . . . . . . . . . . 17 78 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 17 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 17 81 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 17 82 8.3. Test Domain Certificate Validity when Signing . . . . . . 18 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 18 85 9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 18 86 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 18 87 9.4. The SMI Security for S/MIME CMS Content Type Registry . . 19 88 9.5. The SID registry . . . . . . . . . . . . . . . . . . . . 19 89 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 19 90 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 19 91 9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 20 92 9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 21 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 94 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 97 12.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 24 99 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 24 100 A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 25 101 A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 26 102 A.3.1. signed requestvoucher . . . . . . . . . . . . . . . . 26 103 A.3.2. unsigned requestvoucher . . . . . . . . . . . . . . . 26 104 A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 107 1. Introduction 109 Enrollment of new nodes into constrained networks with constrained 110 nodes present unique challenges. 112 There are bandwidth and code space issues to contend. A solution 113 such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in 114 terms of code space or bandwidth required. 116 This document defines a constrained version of [RFC8366]. Rather 117 than serializing the YANG definition in JSON, it is serialized into 118 CBOR ([RFC7049]). 120 This document follows a similar, but not identical structure as 121 [RFC8366]. Some sections are left out entirely. Additional sections 122 have been added concerning: 124 1. Addition of voucher-request specification as defined in 125 [I-D.ietf-anima-bootstrapping-keyinfra], 127 2. Addition to [I-D.ietf-ace-coap-est] of voucher transport requests 128 over coap. 130 The CBOR definitions for this constrained voucher format are defined 131 using the mechanism describe in [I-D.ietf-core-yang-cbor] using the 132 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 133 convert YANG documents into an list of SID keys is still in its 134 infancy, the table of SID values presented here should be considered 135 normative rather than the output of the pyang tool. 137 Two methods of signing the resulting CBOR object are described in 138 this document: 140 1. One is CMS [RFC5652]. 142 2. The other is COSE [RFC8152] signatures. 144 2. Terminology 146 The following terms are defined in [RFC8366], and are used 147 identically as in that document: artifact, imprint, domain, Join 148 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 149 Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher. 151 3. Requirements Language 153 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 154 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 155 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 156 [RFC2119] and indicate requirement levels for compliant STuPiD 157 implementations. 159 4. Survey of Voucher Types 161 [RFC8366] provides for vouchers that assert proximity, that 162 authenticate the registrar and that include different amounts of 163 anti-replay protection. 165 This document does not make any extensions to the types of vouchers. 167 Time based vouchers are included in this definition, but given that 168 constrained devices are extremely unlikely to know the correct time, 169 their use is very unlikely. Most users of these constrained vouchers 170 will be online and will use live nonces to provide anti-replay 171 protection. 173 [RFC8366] defined only the voucher artifact, and not the Voucher 174 Request artifact, which was defined in 175 [I-D.ietf-anima-bootstrapping-keyinfra]. 177 This document defines both a constrained voucher and a constrained 178 voucher-request. They are presented in the order voucher-request, 179 followed by voucher response as this is the time order that they 180 occur. 182 This document defines both CMS-signed voucher requests and responses, 183 and COSE signed voucher requests and responses. The use of CMS 184 signatures implies the use of PKIX format certificates. The pinned- 185 domain-cert present in such a voucher, is the certificate of the 186 Registrar. 188 The use of COSE signatures permits the use of both PKIX format 189 certificates, and also raw public keys (RPK). When RPKs are used, 190 the voucher produced by the MASA pins the raw public key of the 191 Registrar: the pinned-domain-subject-public-key-info in such a 192 voucher, is the raw public key of the Registrar. This is described 193 in the YANG definition for the constrained voucher. 195 5. Discovery and URI 197 This section describes the BRSKI extensions to EST-coaps 198 [I-D.ietf-ace-coap-est] to transport the voucher between registrar, 199 proxy and pledge over CoAP. The extensions are targeted to low- 200 resource networks with small packets. Saving header space is 201 important and the EST-coaps URI is shorter than the EST URI. 203 The presence and location of (path to) the management data are 204 discovered by sending a GET request to "/.well-known/core" including 205 a resource type (RT) parameter with the value "ace.est" [RFC6690]. 206 Upon success, the return payload will contain the root resource of 207 the EST resources. It is up to the implementation to choose its root 208 resource; throughout this document the example root resource /est is 209 used. The example below shows the discovery of the presence and 210 location of voucher resources. 212 REQ: GET /.well-known/core?rt=ace.est 214 RES: 2.05 Content 215 ; rt="ace.est" 217 The EST-coaps server URIs differ from the EST URI by replacing the 218 scheme https by coaps and by specifying shorter resource path names: 220 coaps://www.example.com/est/short-name 222 Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and 223 corresponding paths which are supported by EST. Table 1 provides the 224 mapping from the BRSKI extension URI path to the EST-coaps URI path. 226 +------------------+-----------+ 227 | BRSKI | EST-coaps | 228 +------------------+-----------+ 229 | /requestvoucher | /rv | 230 | | | 231 | /voucher-status | /vs | 232 | | | 233 | /enrollstatus | /es | 234 | | | 235 | /requestauditlog | /ra | 236 +------------------+-----------+ 238 Table 1: BRSKI path to EST-coaps path 240 /requestvoucher and /enrollstatus are needed between pledge and 241 Registrar. 243 When discovering the root path for the EST resources, the server MAY 244 return the full resource paths and the used content types. This is 245 useful when multiple content types are specified for EST-coaps 246 server. For example, the following more complete response is 247 possible. 249 REQ: GET /.well-known/core?rt=ace.est* 251 RES: 2.05 Content 252 ; rt="ace.est" 253 ; rt="ace.est/rv";ct=50 60 TBD2 TBD3 16 254 ; rt="ace.est/vs";ct=50 60 255 ; rt="ace.est/es";ct=50 60 256 ; rt="ace.est/ra";ct=TBD2 TBD3 16 258 The first line MUST be returned in response to the GET, The following 259 four lines MAY be returned to show the supported Content-Formats. 260 The return of the content-types allows the client to choose the most 261 appropriate one from multiple content types. 263 ct=16 stands for the Content-Format "application/cose", and ct=TBD2 264 stands for Content-Format "application/voucher-cms+cbor, and ct=TBD3 265 stands for Content-Format "application/voucher-cose+cbor". 267 Content-Formats TBD2 and TBD3 are defined in this document. The 268 return of the content-formats allows the client to choose the most 269 appropriate one from multiple content formats. 271 The Content-Format ("application/json") 50 MAY be supported. 272 Content-Formats ("application/cbor") 60, TBD2, TBD3, and 16 MUST be 273 supported. 275 6. Artifacts 277 This section describes the abstract (tree) definition as explained in 278 [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- 279 level view of the contents of each artifact. 281 Then the assigned SID values are presented. These have been assigned 282 using the rules in [I-D.ietf-core-yang-cbor], with an allocation that 283 was made via the http://comi.space service. 285 6.1. Voucher Request artifact 287 6.1.1. Tree Diagram 289 The following diagram is largely a duplicate of the contents of 290 [RFC8366], with the addition of proximity-registrar-subject-public- 291 key-info, proximity-registrar-cert, and prior-signed-voucher-request. 293 prior-signed-voucher-request is only used between the Registrar and 294 the MASA. proximity-registrar-subject-public-key-info replaces 295 proximity-registrar-cert for the extremely constrained cases. 297 module: ietf-constrained-voucher-request 299 grouping voucher-request-constrained-grouping 300 +-- voucher 301 +-- created-on? 302 | yang:date-and-time 303 +-- expires-on? 304 | yang:date-and-time 305 +-- assertion enumeration 306 +-- serial-number string 307 +-- idevid-issuer? binary 308 +-- pinned-domain-cert? binary 309 +-- domain-cert-revocation-checks? boolean 310 +-- nonce? binary 311 +-- last-renewal-date? 312 | yang:date-and-time 313 +-- proximity-registrar-subject-public-key-info? binary 314 +-- proximity-registrar-cert? binary 315 +-- prior-signed-voucher-request? binary 317 6.1.2. SID values 318 SID Assigned to 319 --------- -------------------------------------------------- 320 1001154 data /ietf-constrained-voucher-request:voucher 321 1001155 data .../assertion 322 1001156 data .../created-on 323 1001157 data .../domain-cert-revocation-checks 324 1001158 data .../expires-on 325 1001159 data .../idevid-issuer 326 1001160 data .../last-renewal-date 327 1001161 data /ietf-constrained-voucher-request:voucher/nonce 328 1001162 data .../pinned-domain-cert 329 1001163 data .../prior-signed-voucher-request 330 1001164 data .../proximity-registrar-cert 331 1001165 data .../proximity-registrar-subject-public-key-info 332 1001166 data .../serial-number 334 6.1.3. YANG Module 336 In the constrained-voucher-request YANG module, the voucher is 337 "augmented" within the "used" grouping statement such that one 338 continuous set of SID values is generated for the constrained- 339 voucher-request module name, all voucher attributes, and the 340 constrained-voucher-request attribute. Two attributes of the voucher 341 are "refined" to be optional. 343 file "ietf-constrained-voucher-request@2018-09-01.yang" 344 module ietf-constrained-voucher-request { 345 yang-version 1.1; 347 namespace 348 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; 349 prefix "constrained"; 351 import ietf-restconf { 352 prefix rc; 353 description 354 "This import statement is only present to access 355 the yang-data extension defined in RFC 8040."; 356 reference "RFC 8040: RESTCONF Protocol"; 357 } 359 import ietf-voucher { 360 prefix "v"; 361 } 363 organization 364 "IETF ANIMA Working Group"; 366 contact 367 "WG Web: 368 WG List: 369 Author: Michael Richardson 370 371 Author: Peter van der Stok 372 373 Author: Panos Kampanakis 374 "; 375 description 376 "This module defines the format for a voucher request, 377 which is produced by a pledge to request a voucher. 378 The voucher-request is sent to the potential owner's 379 Registrar, which in turn sends the voucher request to 380 the manufacturer or delegate (MASA). 382 A voucher is then returned to the pledge, binding the 383 pledge to the owner. This is a constrained version of the 384 voucher-request present in 385 draft-ietf-anima-bootstrap-keyinfra.txt. 387 This version provides a very restricted subset appropriate 388 for very constrained devices. 389 In particular, it assumes that nonce-ful operation is 390 always required, that expiration dates are rather weak, as no 391 clocks can be assumed, and that the Registrar is identified 392 by a pinned Raw Public Key. 394 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 395 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 396 and 'OPTIONAL' in the module text are to be interpreted as 397 described in RFC 2119."; 399 revision "2018-09-01" { 400 description 401 "Initial version"; 402 reference 403 "RFC XXXX: Voucher Profile for Constrained Devices"; 404 } 406 rc:yang-data voucher-request-constrained-artifact { 407 // YANG data template for a voucher. 408 uses voucher-request-constrained-grouping; 409 } 411 // Grouping defined for future usage 412 grouping voucher-request-constrained-grouping { 413 description 414 "Grouping to allow reuse/extensions in future work."; 416 uses v:voucher-artifact-grouping { 418 refine voucher/created-on { 419 mandatory false; 420 } 422 refine voucher/pinned-domain-cert { 423 mandatory false; 424 } 426 augment "voucher" { 427 description "Base the constrained voucher-request upon the 428 regular one"; 430 leaf proximity-registrar-subject-public-key-info { 431 type binary; 432 description 433 "The proximity-registrar-subject-public-key-info replaces 434 the proximit-registrar-cert in constrained uses of 435 the voucher-request. 436 The proximity-registrar-subject-public-key-info is the 437 Raw Public Key of the Registrar. This field is encoded 438 as specified in RFC7250, section 3. 439 The ECDSA algorithm MUST be supported. 440 The EdDSA algorithm as specified in 441 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 442 Support for the DSA algorithm is not recommended. 443 Support for the RSA algorithm is a MAY."; 444 } 446 leaf proximity-registrar-cert { 447 type binary; 448 description 449 "An X.509 v3 certificate structure as specified by 450 RFC 5280, 451 Section 4 encoded using the ASN.1 distinguished encoding 452 rules (DER), as specified in ITU-T X.690. 454 The first certificate in the Registrar TLS server 455 certificate_list sequence (see [RFC5246]) presented by 456 the Registrar to the Pledge. This MUST be populated in a 457 Pledge's voucher request if the proximity assertion is 458 populated."; 459 } 460 leaf prior-signed-voucher-request { 461 type binary; 462 description 463 "If it is necessary to change a voucher, or re-sign and 464 forward a voucher that was previously provided along a 465 protocol path, then the previously signed voucher 466 SHOULD be included in this field. 468 For example, a pledge might sign a proximity voucher, 469 which an intermediate registrar then re-signs to 470 make its own proximity assertion. This is a simple 471 mechanism for a chain of trusted parties to change a 472 voucher, while maintaining the prior signature 473 information. 475 The pledge MUST ignore all prior voucher information 476 when accepting a voucher for imprinting. Other 477 parties MAY examine the prior signed voucher 478 information for the purposes of policy decisions. 479 For example this information could be useful to a 480 MASA to determine that both pledge and registrar 481 agree on proximity assertions. The MASA SHOULD 482 remove all prior-signed-voucher-request information when 483 signing a voucher for imprinting so as to minimize the 484 final voucher size."; 485 } 486 } 487 } 488 } 489 } 490 492 6.1.4. Example voucher request artifact 494 Below a CBOR serialization of the constrained-voucher-request is 495 shown in diagnostic CBOR notation. The enum value of the assertion 496 field is calculated to be zero by following the algorithm described 497 in section 9.6.4.2 of [RFC7950]. 499 { 500 1001101: { 501 +2 : "2016-10-07T19:31:42Z", / SID = 1001103, created-on / 502 +4 : "2016-10-21T19:31:42Z", / SID = 1001105, expires-on / 503 +1 : 0, / SID = 1001102, assertion / 504 / "verified" / 505 +12: "JADA123456789", / SID = 1001113, serial-number / 506 +5 : h'01020D0F', / SID = 1001106, idevid-issuer / 507 +8 : h'01020D0F', / SID = 1001109, pinned-domain-cert/ 508 +3 : true, / SID = 1001104, domain-cert 509 -revocation-checks / 510 +6 : "2017-10-07T19:31:42Z", / SID = 1001107, last-renewal-date / 511 +11: h'01020D0F' / SID = 1001112, proximity 512 -registrar-subject-public-key-info / 513 } 514 } 516 6.2. Voucher artifact 518 The voucher's primary purpose is to securely assign a pledge to an 519 owner. The voucher informs the pledge which entity it should 520 consider to be its owner. 522 This document defines a voucher that is a CBOR encoded instance of 523 the YANG module defined in Section 5.3 that has been signed with CMS 524 or with COSE. 526 6.2.1. Tree Diagram 528 The following diagram is largely a duplicate of the contents of 529 [RFC8366], with only the addition of pinned-domain-subject-public- 530 key-info. 532 module: ietf-constrained-voucher 534 grouping voucher-constrained-grouping 535 +-- voucher 536 +-- created-on? yang:date-and-time 537 +-- expires-on? yang:date-and-time 538 +-- assertion enumeration 539 +-- serial-number string 540 +-- idevid-issuer? binary 541 +-- pinned-domain-cert? binary 542 +-- domain-cert-revocation-checks? boolean 543 +-- nonce? binary 544 +-- last-renewal-date? yang:date-and-time 545 +-- pinned-domain-subject-public-key-info? binary 547 6.2.2. SID values 549 SID Assigned to 550 --------- -------------------------------------------------- 551 1001104 data .../voucher 552 1001105 data .../assertion 553 1001106 data .../created-on 554 1001107 data .../domain-cert-revocation-checks 555 1001108 data .../expires-on 556 1001109 data .../idevid-issuer 557 1001110 data .../last-renewal-date 558 1001111 data .../nonce 559 1001112 data .../pinned-domain-cert 560 1001113 data .../pinned-domain-subject-public-key-info 561 1001114 data .../serial-number 563 6.2.3. YANG Module 565 In the constraine-voucher YANG module, the voucher is "augmented" 566 within the "used" grouping statement such that one continuous set of 567 SID values is generated for the constrained-voucher module name, all 568 voucher attributes, and the constrained-voucher attribute. Two 569 attributes of the voucher are "refined" to be optional. 571 file "ietf-constrained-voucher@2018-09-01.yang" 572 module ietf-constrained-voucher { 573 yang-version 1.1; 575 namespace 576 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; 577 prefix "constrained"; 579 import ietf-restconf { 580 prefix rc; 581 description 582 "This import statement is only present to access 583 the yang-data extension defined in RFC 8040."; 584 reference "RFC 8040: RESTCONF Protocol"; 585 } 587 import ietf-voucher { 588 prefix "v"; 589 } 591 organization 592 "IETF ANIMA Working Group"; 594 contact 595 "WG Web: 596 WG List: 597 Author: Michael Richardson 598 599 Author: Peter van der Stok 600 601 Author: Panos Kampanakis 602 "; 603 description 604 "This module defines the format for a voucher, which is produced 605 by a pledge's manufacturer or delegate (MASA) to securely assign 606 one or more pledges to an 'owner', so that the pledges may 607 establis a secure connection to the owner's network 608 infrastructure. 610 This version provides a very restricted subset appropriate 611 for very constrained devices. 612 In particular, it assumes that nonce-ful operation is 613 always required, that expiration dates are rather weak, as no 614 clocks can be assumed, and that the Registrar is identified 615 by a pinned Raw Public Key. 617 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 618 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 619 and 'OPTIONAL' in the module text are to be interpreted as 620 described in RFC 2119."; 622 revision "2018-09-01" { 623 description 624 "Initial version"; 625 reference 626 "RFC XXXX: Voucher Profile for Constrained Devices"; 627 } 629 rc:yang-data voucher-constrained-artifact { 630 // YANG data template for a voucher. 631 uses voucher-constrained-grouping; 632 } 634 // Grouping defined for future usage 635 grouping voucher-constrained-grouping { 636 description 637 "Grouping to allow reuse/extensions in future work."; 639 uses v:voucher-artifact-grouping { 641 refine voucher/created-on { 642 mandatory false; 643 } 645 refine voucher/pinned-domain-cert { 646 mandatory false; 647 } 649 augment "voucher" { 650 description "Base the constrained voucher 651 upon the regular one"; 652 leaf pinned-domain-subject-public-key-info { 653 type binary; 654 description 655 "The pinned-domain-subject-public-key-info replaces the 656 pinned-domain-cert in constrained uses of 657 the voucher. The pinned-domain-subject-public-key-info 658 is the Raw Public Key of the Registrar. 659 This field is encoded as specified in RFC7250, 660 section 3. 661 The ECDSA algorithm MUST be supported. 662 The EdDSA algorithm as specified in 663 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 664 Support for the DSA algorithm is not recommended. 665 Support for the RSA algorithm is a MAY."; 666 } 667 } 668 } 669 } 670 } 671 673 6.2.4. Example voucher artifacts 675 Below a the CBOR serialization of the the constrained-voucher and 676 constrained-voucher-request are shown in diagnostic CBOR notation. 677 The enum value of the assertion field is calculated to be zero by 678 following the algorithm described in section 9.6.4.2 of [RFC7950]. 680 { 681 1001051: { 682 +2 : "2016-10-07T19:31:42Z", / SID = 1001053, created-on / 683 +4 : "2016-10-21T19:31:42Z", / SID = 1001055, expires-on / 684 +1 : 0, / SID = 1001052, assertion / 685 / "verified" / 686 +10: "JADA123456789", / SID = 1001061, serial-number / 687 +5 : h'01020D0F', / SID = 1001056, idevid-issuer / 688 +8 : h'01020D0F', / SID = 1001059, pinned-domain-cert/ 689 +3 : true, / SID = 1001054, domain-cert 690 -revocation-checks/ 691 +6 : "2017-10-07T19:31:42Z", / SID = 1001057, last-renewal-date / 692 +9 : h'01020D0F' / SID = 1001060, pinned-domain 693 -subject-public-key-info / 694 } 695 } 697 6.3. CMS format voucher and voucher-request artifacts 699 The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed 700 voucher is much like the equivalent voucher defined in [RFC8366]. 702 A different eContentType of TBD1 is used to indicate that the 703 contents are in a different format than in [RFC8366]. 705 The ContentInfo structure contains a payload consisting of the CBOR 706 encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding 707 creates a canonical ordering for the keys on the wire. This 708 canonical ordering is not important as there is no expectation that 709 the content will be reproduced during the validation process. 711 Normally the recipient is the pledge and the signer is the MASA. 713 [I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and 714 unsigned voucher requests from the pledge to the JRC. In this 715 specification, voucher-request artifact is not signed from the pledge 716 to the registrar. From the JRC to the MASA, the voucher-request 717 artifact MUST be signed by the domain owner key which is requesting 718 ownership. 720 The considerations of [RFC5652] section 5.1, concerning validating 721 CMS objects which are really PKCS7 objects (cmsVersion=1) applies. 723 The CMS structure SHOULD also contain all the certificates leading up 724 to and including the signer's trust anchor certificate known to the 725 recipient. The inclusion of the trust anchor is unusual in many 726 applications, but without it third parties can not accurately audit 727 the transaction. 729 The CMS structure MAY also contain revocation objects for any 730 intermediate certificate authorities (CAs) between the voucher-issuer 731 and the trust anchor known to the recipient. However, the use of 732 CRLs and other validity mechanisms is discouraged, as the pledge is 733 unlikely to be able to perform online checks, and is unlikely to have 734 a trusted clock source. As described below, the use of short-lived 735 vouchers and/or pledge provided nonce provides a freshness guarantee. 737 6.3.1. COSE signing 739 The COSE-Sign1 structure discussed in section 4.2 of [RFC8152]. The 740 CBOR object that carries the body, the signature, and the information 741 about the body and signature is called the COSE_Sign1 structure. It 742 is used when only one signature is used on the body. The signature 743 algorithm is ECSDA with three curves P-256, P-384, and P-512. 745 Support for EdDSA is encouraged. 747 Unlike with the CMS structure, the COSE-Sign1 structure does not 748 provide a standard way for the signing keys to be included in the 749 structure. This will not, in general, be a problem for the Pledge, 750 as the key needed to verify the signature MUST be included at 751 manufacturing time. 753 A problem arises for the Registrar: to verify the voucher, the 754 Registrar must have access to the MASA's public key. This document 755 does not specify how to transfer the relevant key. 757 7. Design Considerations 759 The design considerations for the CBOR encoding of vouchers is much 760 the same as for [RFC8366]. 762 One key difference is that the names of the leaves in the YANG does 763 not have a material effect on the size of the resulting CBOR, as the 764 SID translation process assigns integers to the names. 766 8. Security Considerations 768 8.1. Clock Sensitivity 770 TBD. 772 8.2. Protect Voucher PKI in HSM 774 TBD. 776 8.3. Test Domain Certificate Validity when Signing 778 TBD. 780 9. IANA Considerations 782 9.1. Resource Type Registry 784 Additions to the sub-registry "CoAP Resource Type", within the "CoRE 785 parameters" registry are specified below. These can be registered 786 either in the Expert Review range (0-255) or IETF Review range 787 (256-9999). 789 ace.rt.rv needs registration with IANA 790 ace.rt.vs needs registration with IANA 791 ace.rt.es needs registration with IANA 792 ace.rt.ra needs registration with IANA 794 9.2. The IETF XML Registry 796 This document registers two URIs in the IETF XML registry [RFC3688]. 797 Following the format in [RFC3688], the following registration is 798 requested: 800 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 801 Registrant Contact: The ANIMA WG of the IETF. 802 XML: N/A, the requested URI is an XML namespace. 804 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request 805 Registrant Contact: The ANIMA WG of the IETF. 806 XML: N/A, the requested URI is an XML namespace. 808 9.3. The YANG Module Names Registry 810 This document registers two YANG modules in the YANG Module Names 811 registry [RFC6020]. Following the format defined in [RFC6020], the 812 the following registration is requested: 814 name: ietf-constrained-voucher 815 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 816 prefix: vch 817 reference: RFC XXXX 819 name: ietf-constrained-voucher-request 820 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained 821 -voucher-request 822 prefix: vch 823 reference: RFC XXXX 825 9.4. The SMI Security for S/MIME CMS Content Type Registry 827 This document registers an OID in the "SMI Security for S/MIME CMS 828 Content Type" registry (1.2.840.113549.1.9.16.1), with the value: 830 Decimal Description References 831 ------- -------------------------------------- ---------- 832 TBD1 id-ct-animaCBORVoucher [ThisRFC] 834 EDNOTE: should a separate value be used for Voucher Requests? 836 9.5. The SID registry 838 The SID range 1001100 was allocated by comi.space to the IETF- 839 CONSTRAINED-VOUCHER yang module. 841 The SID range 1001150 was allocated by comi.space to the IETF- 842 CONSTRAINED-VOUCHER-REQUEST yang module. 844 EDNOTE: it is unclear if there is further IANA work required. 846 9.6. Media-Type Registry 848 This section registers the 'application/voucher-cms+cbor' media type 849 and the 'application/voucher-cose+cbor'in the "Media Types" registry. 850 These media types are used to indicate that the content is a CBOR 851 voucher either signed with a cms structure or a COSE_Sign1 structure 852 [RFC8152]. 854 9.6.1. application/voucher-cms+cbor 855 Type name: application 856 Subtype name: voucher-cms+cbor 857 Required parameters: none 858 Optional parameters: none 859 Encoding considerations: CMS-signed CBOR vouchers are CBOR 860 encoded. 861 Security considerations: See Security Considerations, Section 862 Interoperability considerations: The format is designed to be 863 broadly interoperable. 864 Published specification: THIS RFC. 865 Applications that use this media type: ANIMA, 6tisch, and other 866 zero-touch imprinting systems 867 Additional information: 868 Magic number(s): None 869 File extension(s): .vch 870 Macintosh file type code(s): none 871 Person & email address to contact for further information: IETF 872 ANIMA WG 873 Intended usage: LIMITED 874 Restrictions on usage: NONE 875 Author: ANIMA WG 876 Change controller: IETF 877 Provisional registration? (standards tree only): NO 879 9.6.2. application/voucher-cose+cbor 880 Type name: application 881 Subtype name: voucher-cose+cbor 882 Required parameters: none 883 Optional parameters: cose-type 884 Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects 885 signed with one signer. 886 Security considerations: See Security Considerations, Section 887 Interoperability considerations: The format is designed to be 888 broadly interoperable. 889 Published specification: THIS RFC. 890 Applications that use this media type: ANIMA, 6tisch, and other 891 zero-touch imprinting systems 892 Additional information: 893 Magic number(s): None 894 File extension(s): .vch 895 Macintosh file type code(s): none 896 Person & email address to contact for further information: IETF 897 ANIMA WG 898 Intended usage: LIMITED 899 Restrictions on usage: NONE 900 Author: ANIMA WG 901 Change controller: IETF 902 Provisional registration? (standards tree only): NO 904 9.7. CoAP Content-Format Registry 906 Additions to the sub-registry "CoAP Content-Formats", within the 907 "CoRE Parameters" registry are needed for two media types. These can 908 be registered either in the Expert Review range (0-255) or IETF 909 Review range (256-9999). 911 Media type mime type Encoding ID References 912 ---------------------------- ----------- --------- ---- ---------- 913 application/voucher-cms+cbor - - CBOR TBD2 [This RFC] 914 application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] 916 10. Acknowledgements 918 We are very grateful to Jim Schaad for explaining COSE and CMS 919 choices. 921 Michel Veillette did extensive work on pyang to extend it to support 922 the SID allocation process, and this document was among the first 923 users. 925 We are grateful for the suggestions done by Esko Dijk. 927 11. Changelog 929 -02 931 Example of requestvoucher with unsigned appllication/cbor is added 932 attributes of voucher "refined" to optional 933 CBOR serialization of vouchers improved 935 -01 937 application/json is optional, application/cbor is compulsory 938 Cms and cose mediatypes are introduced 940 12. References 942 12.1. Normative References 944 [I-D.ietf-ace-cbor-web-token] 945 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 946 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 947 (work in progress), March 2018. 949 [I-D.ietf-ace-coap-est] 950 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 951 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 952 coaps)", draft-ietf-ace-coap-est-05 (work in progress), 953 July 2018. 955 [I-D.ietf-anima-bootstrapping-keyinfra] 956 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 957 S., and K. Watsen, "Bootstrapping Remote Secure Key 958 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 959 keyinfra-16 (work in progress), June 2018. 961 [I-D.ietf-core-object-security] 962 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 963 "Object Security for Constrained RESTful Environments 964 (OSCORE)", draft-ietf-core-object-security-14 (work in 965 progress), July 2018. 967 [I-D.ietf-core-sid] 968 Veillette, M. and A. Pelov, "YANG Schema Item iDentifier 969 (SID)", draft-ietf-core-sid-04 (work in progress), June 970 2018. 972 [I-D.ietf-core-yang-cbor] 973 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 974 Minaburo, "CBOR Encoding of Data Modeled with YANG", 975 draft-ietf-core-yang-cbor-06 (work in progress), February 976 2018. 978 [ieee802-1AR] 979 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 980 2009, . 983 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 984 Requirement Levels", BCP 14, RFC 2119, 985 DOI 10.17487/RFC2119, March 1997, 986 . 988 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 989 RFC 5652, DOI 10.17487/RFC5652, September 2009, 990 . 992 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 993 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 994 October 2013, . 996 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 997 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 998 Transport Layer Security (TLS) and Datagram Transport 999 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1000 June 2014, . 1002 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1003 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1004 . 1006 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1007 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1008 . 1010 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1011 "A Voucher Artifact for Bootstrapping Protocols", 1012 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1013 . 1015 12.2. Informative References 1017 [duckling] 1018 Stajano, F. and R. Anderson, "The resurrecting duckling: 1019 security issues for ad-hoc wireless networks", 1999, 1020 . 1023 [I-D.ietf-netmod-yang-tree-diagrams] 1024 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1025 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1026 February 2018. 1028 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 1029 . 1031 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1032 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1033 . 1035 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1036 "Enrollment over Secure Transport", RFC 7030, 1037 DOI 10.17487/RFC7030, October 2013, 1038 . 1040 Appendix A. EST messages to EST-coaps 1042 This section extends the examples from Appendix A of 1043 [I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for 1044 the enrollstatus example. 1046 A.1. enrollstatus 1048 A coaps enrollstatus message can be : 1050 GET coaps://[192.0.2.1:8085]/est/es 1052 The corresponding coap header fields are shown below. 1054 Ver = 1 1055 T = 0 (CON) 1056 Code = 0x01 (0.01 is GET) 1057 Options 1058 Option1 (Uri-Host) 1059 Option Delta = 0x3 (option nr = 3) 1060 Option Length = 0x9 1061 Option Value = 192.0.2.1 1062 Option2 (Uri-Port) 1063 Option Delta = 0x4 (option nr = 4+3=7) 1064 Option Length = 0x4 1065 Option Value = 8085 1066 Option3 (Uri-Path) 1067 Option Delta = 0x4 (option nr = 7+4= 11) 1068 Option Length = 0x7 1069 Option Value = /est/es 1070 Payload = [Empty] 1072 A 2.05 Content response with an unsigned JSON voucher (ct=50) will 1073 then be: 1075 2.05 Content (Content-Format: application/json) 1076 {payload} 1078 With CoAP fields and payload: 1080 Ver=1 1081 T=2 (ACK) 1082 Code = 0x45 (2.05 Content) 1083 Options 1084 Option1 (Content-Format) 1085 Option Delta = 0xC (option nr 12) 1086 Option Length = 0x2 1087 Option Value = 0x32 (application/json) 1089 Payload = 1090 [EDNOTE: put here voucher payload ] 1092 A.2. voucher_status 1094 A coaps voucher_status message can be : 1096 GET coaps://[2001:db8::2:1]:61616]/est/vs 1098 A 2.05 Content response with a non signed CBOR voucher (ct=60) will 1099 then be: 1101 2.05 Content (Content-Format: application/cbor) 1102 Payload = 1103 [EDNOTE: put here voucher payload ] 1105 A.3. requestvoucher 1107 Two request-voucher request payloads are possible from pledge to 1108 Registrar, a signed one and an unsigned one, as explained in 1109 Section 5.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. 1111 A.3.1. signed requestvoucher 1113 A coaps signed requestvoucher message from RA to MASA can be : 1115 POST coaps://[2001:db8::2:1]:61616]/est/rv 1117 A 2.04 Changed response returning CBOR voucher signed with a cms 1118 structure(ct=TBD2) will then be: 1120 2.04 Changed (Content-Format: application/voucher-cms+cbor) 1121 Payload = 1122 [EDNOTE: put here encrypted voucher payload ] 1124 A.3.2. unsigned requestvoucher 1126 A coaps unsigned requestvoucher message from pledge to Registrar can 1127 be : 1129 POST coaps://[2001:db8::2:1]:61616]/est/rv 1131 A 2.04 Changed response returning CBOR voucher (ct=60) will then be: 1133 2.04 Changed (Content-Format: application/cbor) 1134 Payload = 1135 [EDNOTE: put here encrypted voucher payload ] 1137 A.4. requestauditing 1139 A coaps requestauditing message can be : 1141 GET coaps://[2001:db8::2:1]:61616]/est/ra 1143 A 2.05 Content response returning a COSE_Sign1 object (ct=TBD3) will 1144 then be: 1146 2.05 Content (Content-Format: application/voucher-cose+cbor) 1147 Payload = 1148 [EDNOTE: put here COSE_Sign1 voucher payload ] 1150 Authors' Addresses 1152 Michael Richardson 1153 Sandelman Software Works 1155 Email: mcr+ietf@sandelman.ca 1157 Peter van der Stok 1158 vanderstok consultancy 1160 Email: consultancy@vanderstok.org 1162 Panos Kampanakis 1163 Cisco Systems 1165 Email: pkampana@cisco.com