idnits 2.17.1 draft-ietf-anima-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-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 449 has weird spacing: '...ndatory false...' == Line 453 has weird spacing: '...ndatory false...' == Line 680 has weird spacing: '...ndatory false...' == Line 684 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 (March 25, 2019) is 1852 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: 'ThisRFC' is mentioned on line 871, but not defined == Missing Reference: 'This RFC' is mentioned on line 954, but not defined == Missing Reference: 'Empty' is mentioned on line 1124, but not defined == Unused Reference: 'I-D.ietf-ace-cbor-web-token' is defined on line 985, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-object-security' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: 'ieee802-1AR' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 1045, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-10 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-19 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-05 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-07 -- 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 (~~), 18 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: September 26, 2019 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 March 25, 2019 10 Constrained Voucher Artifacts for Bootstrapping Protocols 11 draft-ietf-anima-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 [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 September 26, 2019. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . 12 71 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 12 72 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 13 73 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 13 74 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 14 75 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 16 76 6.3. CMS format voucher and voucher-request artifacts . . . . 16 77 6.3.1. COSE signing . . . . . . . . . . . . . . . . . . . . 17 78 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 18 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 18 81 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 20 90 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . 24 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 Port numbers, not returned in the example, are assumed to be the 264 default numbers 5683 and 5684 for coap and coaps respectively 265 (sections 12.6 and 12.7 of [RFC7252]. Discoverable port numbers MAY 266 be returned in the of the payload. 268 ct=16 stands for the Content-Format "application/cose", and ct=TBD2 269 stands for Content-Format "application/voucher-cms+cbor, and ct=TBD3 270 stands for Content-Format "application/voucher-cose+cbor". 272 Content-Formats TBD2 and TBD3 are defined in this document. The 273 return of the content-formats allows the client to choose the most 274 appropriate one from multiple content formats. 276 The Content-Format ("application/json") 50 MAY be supported. 277 Content-Formats ("application/cbor") 60, TBD2, TBD3, and 16 MUST be 278 supported. 280 6. Artifacts 282 This section describes the abstract (tree) definition as explained in 283 [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- 284 level view of the contents of each artifact. 286 Then the assigned SID values are presented. These have been assigned 287 using the rules in [I-D.ietf-core-yang-cbor], with an allocation that 288 was made via the http://comi.space service. 290 6.1. Voucher Request artifact 292 6.1.1. Tree Diagram 294 The following diagram is largely a duplicate of the contents of 295 [RFC8366], with the addition of proximity-registrar-subject-public- 296 key-info, proximity-registrar-cert, and prior-signed-voucher-request. 298 prior-signed-voucher-request is only used between the Registrar and 299 the MASA. proximity-registrar-subject-public-key-info replaces 300 proximity-registrar-cert for the extremely constrained cases. 302 module: ietf-constrained-voucher-request 304 grouping voucher-request-constrained-grouping 305 +-- voucher 306 +-- created-on? 307 | yang:date-and-time 308 +-- expires-on? 309 | yang:date-and-time 310 +-- assertion enumeration 311 +-- serial-number string 312 +-- idevid-issuer? binary 313 +-- pinned-domain-cert? binary 314 +-- domain-cert-revocation-checks? boolean 315 +-- nonce? binary 316 +-- last-renewal-date? 317 | yang:date-and-time 318 +-- proximity-registrar-subject-public-key-info? binary 319 +-- proximity-registrar-cert? binary 320 +-- prior-signed-voucher-request? binary 322 6.1.2. SID values 323 Base SID value for voucher request: 1001150. 325 SID Assigned to 326 --------- -------------------------------------------------- 327 1001167 module ietf-constrained-voucher-request 328 1001168 module ietf-restconf 329 1001169 module ietf-voucher 330 1001170 module ietf-yang-types 331 1001171 data /ietf-constrained-voucher-request:voucher 332 1001154 data .../ietf-constrained-voucher-request:voucher 333 1001155 data .../assertion 334 1001156 data .../created-on 335 1001157 data .../domain-cert-revocation-checks 336 1001158 data .../expires-on 337 1001159 data .../idevid-issuer 338 1001160 data .../last-renewal-date 339 1001161 data .../nonce 340 1001162 data .../pinned-domain-cert 341 1001165 data .../prior-signed-voucher-request 342 1001166 data .../proximity-registrar-cert 343 1001163 data .../proximity-registrar-subject-public-key-info 344 1001164 data .../serial-number 345 1001172 data .../assertion 346 1001173 data .../created-on 347 1001174 data .../domain-cert-revocation-checks 348 1001175 data .../expires-on 349 1001176 data .../idevid-issuer 350 1001177 data .../last-renewal-date 351 1001178 data /ietf-constrained-voucher-request:voucher/nonce 352 1001179 data .../pinned-domain-cert 353 1001180 data .../prior-signed-voucher-request 354 1001181 data .../proximity-registrar-cert 355 1001182 data .../proximity-registrar-subject-public-key-info 356 1001183 data .../serial-number 357 1001150 data ietf-constrained-voucher-request 358 1001151 data ietf-restconf 359 1001152 data ietf-voucher 360 1001153 data ietf-yang-types 362 WARNING, obsolete definitions 364 6.1.3. YANG Module 366 In the constrained-voucher-request YANG module, the voucher is 367 "augmented" within the "used" grouping statement such that one 368 continuous set of SID values is generated for the constrained- 369 voucher-request module name, all voucher attributes, and the 370 constrained-voucher-request attribute. Two attributes of the voucher 371 are "refined" to be optional. 373 file "ietf-constrained-voucher-request@2018-09-01.yang" 374 module ietf-constrained-voucher-request { 375 yang-version 1.1; 377 namespace 378 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; 379 prefix "constrained"; 381 import ietf-restconf { 382 prefix rc; 383 description 384 "This import statement is only present to access 385 the yang-data extension defined in RFC 8040."; 386 reference "RFC 8040: RESTCONF Protocol"; 387 } 389 import ietf-voucher { 390 prefix "v"; 391 } 393 organization 394 "IETF ANIMA Working Group"; 396 contact 397 "WG Web: 398 WG List: 399 Author: Michael Richardson 400 401 Author: Peter van der Stok 402 403 Author: Panos Kampanakis 404 "; 405 description 406 "This module defines the format for a voucher request, 407 which is produced by a pledge to request a voucher. 408 The voucher-request is sent to the potential owner's 409 Registrar, which in turn sends the voucher request to 410 the manufacturer or delegate (MASA). 412 A voucher is then returned to the pledge, binding the 413 pledge to the owner. This is a constrained version of the 414 voucher-request present in 415 draft-ietf-anima-bootstrap-keyinfra.txt. 417 This version provides a very restricted subset appropriate 418 for very constrained devices. 419 In particular, it assumes that nonce-ful operation is 420 always required, that expiration dates are rather weak, as no 421 clocks can be assumed, and that the Registrar is identified 422 by a pinned Raw Public Key. 424 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 425 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 426 and 'OPTIONAL' in the module text are to be interpreted as 427 described in RFC 2119."; 429 revision "2018-09-01" { 430 description 431 "Initial version"; 432 reference 433 "RFC XXXX: Voucher Profile for Constrained Devices"; 434 } 436 rc:yang-data voucher-request-constrained-artifact { 437 // YANG data template for a voucher. 438 uses voucher-request-constrained-grouping; 439 } 441 // Grouping defined for future usage 442 grouping voucher-request-constrained-grouping { 443 description 444 "Grouping to allow reuse/extensions in future work."; 446 uses v:voucher-artifact-grouping { 448 refine voucher/created-on { 449 mandatory false; 450 } 452 refine voucher/pinned-domain-cert { 453 mandatory false; 454 } 456 augment "voucher" { 457 description "Base the constrained voucher-request upon the 458 regular one"; 460 leaf proximity-registrar-subject-public-key-info { 461 type binary; 462 description 463 "The proximity-registrar-subject-public-key-info replaces 464 the proximit-registrar-cert in constrained uses of 465 the voucher-request. 466 The proximity-registrar-subject-public-key-info is the 467 Raw Public Key of the Registrar. This field is encoded 468 as specified in RFC7250, section 3. 469 The ECDSA algorithm MUST be supported. 470 The EdDSA algorithm as specified in 471 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 472 Support for the DSA algorithm is not recommended. 473 Support for the RSA algorithm is a MAY."; 474 } 476 leaf proximity-registrar-cert { 477 type binary; 478 description 479 "An X.509 v3 certificate structure as specified by 480 RFC 5280, 481 Section 4 encoded using the ASN.1 distinguished encoding 482 rules (DER), as specified in ITU-T X.690. 484 The first certificate in the Registrar TLS server 485 certificate_list sequence (see [RFC5246]) presented by 486 the Registrar to the Pledge. This MUST be populated in a 487 Pledge's voucher request if the proximity assertion is 488 populated."; 489 } 491 leaf prior-signed-voucher-request { 492 type binary; 493 description 494 "If it is necessary to change a voucher, or re-sign and 495 forward a voucher that was previously provided along a 496 protocol path, then the previously signed voucher 497 SHOULD be included in this field. 499 For example, a pledge might sign a proximity voucher, 500 which an intermediate registrar then re-signs to 501 make its own proximity assertion. This is a simple 502 mechanism for a chain of trusted parties to change a 503 voucher, while maintaining the prior signature 504 information. 506 The pledge MUST ignore all prior voucher information 507 when accepting a voucher for imprinting. Other 508 parties MAY examine the prior signed voucher 509 information for the purposes of policy decisions. 510 For example this information could be useful to a 511 MASA to determine that both pledge and registrar 512 agree on proximity assertions. The MASA SHOULD 513 remove all prior-signed-voucher-request information when 514 signing a voucher for imprinting so as to minimize the 515 final voucher size."; 516 } 517 } 518 } 519 } 520 } 521 523 6.1.4. Example voucher request artifact 525 Below a CBOR serialization of the constrained-voucher-request is 526 shown in diagnostic CBOR notation. The enum value of the assertion 527 field is calculated to be zero by following the algorithm described 528 in section 9.6.4.2 of [RFC7950]. 530 { 531 1001051: { 532 +2 : "2016-10-07T19:31:42Z", / SID= 1001053, created-on / 533 +4 : "2016-10-21T19:31:42Z", / SID= 1001055, expires-on / 534 +1 : 0, / SID= 1001052, assertion / 535 / "verified" / 536 +10: "JADA123456789", / SID= 1001061, serial-number / 537 +5 : h'01020D0F', / SID= 1001056, idevid-issuer / 538 +15: h'01020D0F', / SID=1001066, proximity-registrar-cert/ 539 +3 : true, / SID= 1001054, domain-cert 540 -revocation-checks/ 541 +6 : "2017-10-07T19:31:42Z", / SID= 1001057, last-renewal-date / 542 +9 : h'01020D0F' / SID= 1001060, pinned-domain 543 -subject-public-key-info / 544 } 545 } 547 6.2. Voucher artifact 549 The voucher's primary purpose is to securely assign a pledge to an 550 owner. The voucher informs the pledge which entity it should 551 consider to be its owner. 553 This document defines a voucher that is a CBOR encoded instance of 554 the YANG module defined in Section 5.3 that has been signed with CMS 555 or with COSE. 557 6.2.1. Tree Diagram 559 The following diagram is largely a duplicate of the contents of 560 [RFC8366], with only the addition of pinned-domain-subject-public- 561 key-info. 563 module: ietf-constrained-voucher 565 grouping voucher-constrained-grouping 566 +-- voucher 567 +-- created-on? yang:date-and-time 568 +-- expires-on? yang:date-and-time 569 +-- assertion enumeration 570 +-- serial-number string 571 +-- idevid-issuer? binary 572 +-- pinned-domain-cert? binary 573 +-- domain-cert-revocation-checks? boolean 574 +-- nonce? binary 575 +-- last-renewal-date? yang:date-and-time 576 +-- pinned-domain-subject-public-key-info? binary 578 6.2.2. SID values 580 Base SID value for voucher request: 1001101. 582 SID Assigned to 583 --------- -------------------------------------------------- 584 1001115 module ietf-constrained-voucher 585 1001116 module ietf-restconf 586 1001117 module ietf-voucher 587 1001118 module ietf-yang-types 588 1001119 data /ietf-constrained-voucher:voucher 589 1001104 data .../ietf-constrained-voucher:voucher 590 1001105 data .../assertion 591 1001106 data .../created-on 592 1001107 data .../domain-cert-revocation-checks 593 1001108 data .../expires-on 594 1001109 data .../idevid-issuer 595 1001110 data .../last-renewal-date 596 1001111 data .../nonce 597 1001112 data .../pinned-domain-cert 598 1001113 data .../pinned-domain-subject-public-key-info 599 1001114 data .../serial-number 601 6.2.3. YANG Module 603 In the constraine-voucher YANG module, the voucher is "augmented" 604 within the "used" grouping statement such that one continuous set of 605 SID values is generated for the constrained-voucher module name, all 606 voucher attributes, and the constrained-voucher attribute. Two 607 attributes of the voucher are "refined" to be optional. 609 file "ietf-constrained-voucher@2018-09-01.yang" 610 module ietf-constrained-voucher { 611 yang-version 1.1; 613 namespace 614 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; 615 prefix "constrained"; 617 import ietf-restconf { 618 prefix rc; 619 description 620 "This import statement is only present to access 621 the yang-data extension defined in RFC 8040."; 622 reference "RFC 8040: RESTCONF Protocol"; 623 } 625 import ietf-voucher { 626 prefix "v"; 627 } 629 organization 630 "IETF ANIMA Working Group"; 632 contact 633 "WG Web: 634 WG List: 635 Author: Michael Richardson 636 637 Author: Peter van der Stok 638 639 Author: Panos Kampanakis 640 "; 641 description 642 "This module defines the format for a voucher, which is produced 643 by a pledge's manufacturer or delegate (MASA) to securely assign 644 one or more pledges to an 'owner', so that the pledges may 645 establis a secure connection to the owner's network 646 infrastructure. 648 This version provides a very restricted subset appropriate 649 for very constrained devices. 650 In particular, it assumes that nonce-ful operation is 651 always required, that expiration dates are rather weak, as no 652 clocks can be assumed, and that the Registrar is identified 653 by a pinned Raw Public Key. 655 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 656 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 657 and 'OPTIONAL' in the module text are to be interpreted as 658 described in RFC 2119."; 660 revision "2018-09-01" { 661 description 662 "Initial version"; 663 reference 664 "RFC XXXX: Voucher Profile for Constrained Devices"; 665 } 667 rc:yang-data voucher-constrained-artifact { 668 // YANG data template for a voucher. 669 uses voucher-constrained-grouping; 670 } 672 // Grouping defined for future usage 673 grouping voucher-constrained-grouping { 674 description 675 "Grouping to allow reuse/extensions in future work."; 677 uses v:voucher-artifact-grouping { 679 refine voucher/created-on { 680 mandatory false; 681 } 683 refine voucher/pinned-domain-cert { 684 mandatory false; 685 } 687 augment "voucher" { 688 description "Base the constrained voucher 689 upon the regular one"; 690 leaf pinned-domain-subject-public-key-info { 691 type binary; 692 description 693 "The pinned-domain-subject-public-key-info replaces the 694 pinned-domain-cert in constrained uses of 695 the voucher. The pinned-domain-subject-public-key-info 696 is the Raw Public Key of the Registrar. 698 This field is encoded as specified in RFC7250, 699 section 3. 700 The ECDSA algorithm MUST be supported. 701 The EdDSA algorithm as specified in 702 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 703 Support for the DSA algorithm is not recommended. 704 Support for the RSA algorithm is a MAY."; 705 } 706 } 707 } 708 } 709 } 710 712 6.2.4. Example voucher artifacts 714 Below a the CBOR serialization of the the constrained-voucher and 715 constrained-voucher-request are shown in diagnostic CBOR notation. 716 The enum value of the assertion field is calculated to be zero by 717 following the algorithm described in section 9.6.4.2 of [RFC7950]. 719 { 720 1001101: { 721 +2 : "2016-10-07T19:31:42Z", / SID = 1001103, created-on / 722 +4 : "2016-10-21T19:31:42Z", / SID = 1001105, expires-on / 723 +1 : 0, / SID = 1001102, assertion / 724 / "verified" / 725 +12: "JADA123456789", / SID = 1001113, serial-number / 726 +5 : h'01020D0F', / SID = 1001106, idevid-issuer / 727 +8 : h'01020D0F', / SID = 1001109, pinned-domain-cert/ 728 +3 : true, / SID = 1001104, domain-cert 729 -revocation-checks / 730 +6 : "2017-10-07T19:31:42Z", / SID = 1001107, last-renewal-date / 731 +11: h'01020D0F' / SID = 1001112, proximity 732 -registrar-subject-public-key-info / 733 } 734 } 736 6.3. CMS format voucher and voucher-request artifacts 738 The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed 739 voucher is much like the equivalent voucher defined in [RFC8366]. 741 A different eContentType of TBD1 is used to indicate that the 742 contents are in a different format than in [RFC8366]. 744 The ContentInfo structure contains a payload consisting of the CBOR 745 encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding 746 creates a canonical ordering for the keys on the wire. This 747 canonical ordering is not important as there is no expectation that 748 the content will be reproduced during the validation process. 750 Normally the recipient is the pledge and the signer is the MASA. 752 [I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and 753 unsigned voucher requests from the pledge to the JRC. In this 754 specification, voucher-request artifact is not signed from the pledge 755 to the registrar. From the JRC to the MASA, the voucher-request 756 artifact MUST be signed by the domain owner key which is requesting 757 ownership. 759 The considerations of [RFC5652] section 5.1, concerning validating 760 CMS objects which are really PKCS7 objects (cmsVersion=1) applies. 762 The CMS structure SHOULD also contain all the certificates leading up 763 to and including the signer's trust anchor certificate known to the 764 recipient. The inclusion of the trust anchor is unusual in many 765 applications, but without it third parties can not accurately audit 766 the transaction. 768 The CMS structure MAY also contain revocation objects for any 769 intermediate certificate authorities (CAs) between the voucher-issuer 770 and the trust anchor known to the recipient. However, the use of 771 CRLs and other validity mechanisms is discouraged, as the pledge is 772 unlikely to be able to perform online checks, and is unlikely to have 773 a trusted clock source. As described below, the use of short-lived 774 vouchers and/or pledge provided nonce provides a freshness guarantee. 776 6.3.1. COSE signing 778 The COSE-Sign1 structure discussed in section 4.2 of [RFC8152]. The 779 CBOR object that carries the body, the signature, and the information 780 about the body and signature is called the COSE_Sign1 structure. It 781 is used when only one signature is used on the body. The signature 782 algorithm is ECSDA with three curves P-256, P-384, and P-512. 784 Support for EdDSA is encouraged. 786 Unlike with the CMS structure, the COSE-Sign1 structure does not 787 provide a standard way for the signing keys to be included in the 788 structure. This will not, in general, be a problem for the Pledge, 789 as the key needed to verify the signature MUST be included at 790 manufacturing time. 792 A problem arises for the Registrar: to verify the voucher, the 793 Registrar must have access to the MASA's public key. This document 794 does not specify how to transfer the relevant key. 796 7. Design Considerations 798 The design considerations for the CBOR encoding of vouchers is much 799 the same as for [RFC8366]. 801 One key difference is that the names of the leaves in the YANG does 802 not have a material effect on the size of the resulting CBOR, as the 803 SID translation process assigns integers to the names. 805 8. Security Considerations 807 8.1. Clock Sensitivity 809 TBD. 811 8.2. Protect Voucher PKI in HSM 813 TBD. 815 8.3. Test Domain Certificate Validity when Signing 817 TBD. 819 9. IANA Considerations 821 9.1. Resource Type Registry 823 Additions to the sub-registry "CoAP Resource Type", within the "CoRE 824 parameters" registry are specified below. These can be registered 825 either in the Expert Review range (0-255) or IETF Review range 826 (256-9999). 828 ace.rt.rv needs registration with IANA 829 ace.rt.vs needs registration with IANA 830 ace.rt.es needs registration with IANA 831 ace.rt.ra needs registration with IANA 833 9.2. The IETF XML Registry 835 This document registers two URIs in the IETF XML registry [RFC3688]. 836 Following the format in [RFC3688], the following registration is 837 requested: 839 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 840 Registrant Contact: The ANIMA WG of the IETF. 841 XML: N/A, the requested URI is an XML namespace. 843 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request 844 Registrant Contact: The ANIMA WG of the IETF. 845 XML: N/A, the requested URI is an XML namespace. 847 9.3. The YANG Module Names Registry 849 This document registers two YANG modules in the YANG Module Names 850 registry [RFC6020]. Following the format defined in [RFC6020], the 851 the following registration is requested: 853 name: ietf-constrained-voucher 854 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 855 prefix: vch 856 reference: RFC XXXX 858 name: ietf-constrained-voucher-request 859 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained 860 -voucher-request 861 prefix: vch 862 reference: RFC XXXX 864 9.4. The SMI Security for S/MIME CMS Content Type Registry 866 This document registers an OID in the "SMI Security for S/MIME CMS 867 Content Type" registry (1.2.840.113549.1.9.16.1), with the value: 869 Decimal Description References 870 ------- -------------------------------------- ---------- 871 TBD1 id-ct-animaCBORVoucher [ThisRFC] 873 EDNOTE: should a separate value be used for Voucher Requests? 875 9.5. The SID registry 877 The SID range 1001100 was allocated by comi.space to the IETF- 878 CONSTRAINED-VOUCHER yang module. 880 The SID range 1001150 was allocated by comi.space to the IETF- 881 CONSTRAINED-VOUCHER-REQUEST yang module. 883 EDNOTE: it is unclear if there is further IANA work required. 885 9.6. Media-Type Registry 887 This section registers the 'application/voucher-cms+cbor' media type 888 and the 'application/voucher-cose+cbor'in the "Media Types" registry. 889 These media types are used to indicate that the content is a CBOR 890 voucher either signed with a cms structure or a COSE_Sign1 structure 891 [RFC8152]. 893 9.6.1. application/voucher-cms+cbor 895 Type name: application 896 Subtype name: voucher-cms+cbor 897 Required parameters: none 898 Optional parameters: none 899 Encoding considerations: CMS-signed CBOR vouchers are CBOR 900 encoded. 901 Security considerations: See Security Considerations, Section 902 Interoperability considerations: The format is designed to be 903 broadly interoperable. 904 Published specification: THIS RFC. 905 Applications that use this media type: ANIMA, 6tisch, and other 906 zero-touch imprinting systems 907 Additional information: 908 Magic number(s): None 909 File extension(s): .vch 910 Macintosh file type code(s): none 911 Person & email address to contact for further information: IETF 912 ANIMA WG 913 Intended usage: LIMITED 914 Restrictions on usage: NONE 915 Author: ANIMA WG 916 Change controller: IETF 917 Provisional registration? (standards tree only): NO 919 9.6.2. application/voucher-cose+cbor 920 Type name: application 921 Subtype name: voucher-cose+cbor 922 Required parameters: none 923 Optional parameters: cose-type 924 Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects 925 signed with one signer. 926 Security considerations: See Security Considerations, Section 927 Interoperability considerations: The format is designed to be 928 broadly interoperable. 929 Published specification: THIS RFC. 930 Applications that use this media type: ANIMA, 6tisch, and other 931 zero-touch imprinting systems 932 Additional information: 933 Magic number(s): None 934 File extension(s): .vch 935 Macintosh file type code(s): none 936 Person & email address to contact for further information: IETF 937 ANIMA WG 938 Intended usage: LIMITED 939 Restrictions on usage: NONE 940 Author: ANIMA WG 941 Change controller: IETF 942 Provisional registration? (standards tree only): NO 944 9.7. CoAP Content-Format Registry 946 Additions to the sub-registry "CoAP Content-Formats", within the 947 "CoRE Parameters" registry are needed for two media types. These can 948 be registered either in the Expert Review range (0-255) or IETF 949 Review range (256-9999). 951 Media type mime type Encoding ID References 952 ---------------------------- ----------- --------- ---- ---------- 953 application/voucher-cms+cbor - - CBOR TBD2 [This RFC] 954 application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] 956 10. Acknowledgements 958 We are very grateful to Jim Schaad for explaining COSE and CMS 959 choices. 961 Michel Veillette did extensive work on pyang to extend it to support 962 the SID allocation process, and this document was among the first 963 users. 965 We are grateful for the suggestions done by Esko Dijk. 967 11. Changelog 969 -02 971 Example of requestvoucher with unsigned appllication/cbor is added 972 attributes of voucher "refined" to optional 973 CBOR serialization of vouchers improved 974 Discovery port numbers are specified 976 -01 978 application/json is optional, application/cbor is compulsory 979 Cms and cose mediatypes are introduced 981 12. References 983 12.1. Normative References 985 [I-D.ietf-ace-cbor-web-token] 986 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 987 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 988 (work in progress), March 2018. 990 [I-D.ietf-ace-coap-est] 991 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 992 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 993 est-10 (work in progress), March 2019. 995 [I-D.ietf-anima-bootstrapping-keyinfra] 996 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 997 S., and K. Watsen, "Bootstrapping Remote Secure Key 998 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 999 keyinfra-19 (work in progress), March 2019. 1001 [I-D.ietf-core-object-security] 1002 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1003 "Object Security for Constrained RESTful Environments 1004 (OSCORE)", draft-ietf-core-object-security-16 (work in 1005 progress), March 2019. 1007 [I-D.ietf-core-sid] 1008 Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item 1009 iDentifier (SID)", draft-ietf-core-sid-05 (work in 1010 progress), December 2018. 1012 [I-D.ietf-core-yang-cbor] 1013 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 1014 Minaburo, "CBOR Encoding of Data Modeled with YANG", 1015 draft-ietf-core-yang-cbor-07 (work in progress), September 1016 2018. 1018 [ieee802-1AR] 1019 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 1020 2009, . 1023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1024 Requirement Levels", BCP 14, RFC 2119, 1025 DOI 10.17487/RFC2119, March 1997, 1026 . 1028 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1029 DOI 10.17487/RFC3688, January 2004, 1030 . 1032 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1033 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1034 . 1036 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1037 the Network Configuration Protocol (NETCONF)", RFC 6020, 1038 DOI 10.17487/RFC6020, October 2010, 1039 . 1041 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1042 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1043 October 2013, . 1045 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1046 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1047 Transport Layer Security (TLS) and Datagram Transport 1048 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1049 June 2014, . 1051 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1052 Application Protocol (CoAP)", RFC 7252, 1053 DOI 10.17487/RFC7252, June 2014, 1054 . 1056 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1057 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1058 . 1060 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1061 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1062 . 1064 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1065 "A Voucher Artifact for Bootstrapping Protocols", 1066 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1067 . 1069 12.2. Informative References 1071 [duckling] 1072 Stajano, F. and R. Anderson, "The resurrecting duckling: 1073 security issues for ad-hoc wireless networks", 1999, 1074 . 1077 [I-D.ietf-netmod-yang-tree-diagrams] 1078 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1079 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1080 February 2018. 1082 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 1083 . 1085 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1086 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1087 . 1089 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1090 "Enrollment over Secure Transport", RFC 7030, 1091 DOI 10.17487/RFC7030, October 2013, 1092 . 1094 Appendix A. EST messages to EST-coaps 1096 This section extends the examples from Appendix A of 1097 [I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for 1098 the enrollstatus example. 1100 A.1. enrollstatus 1102 A coaps enrollstatus message can be : 1104 GET coaps://[192.0.2.1:8085]/est/es 1106 The corresponding coap header fields are shown below. 1108 Ver = 1 1109 T = 0 (CON) 1110 Code = 0x01 (0.01 is GET) 1111 Options 1112 Option1 (Uri-Host) 1113 Option Delta = 0x3 (option nr = 3) 1114 Option Length = 0x9 1115 Option Value = 192.0.2.1 1116 Option2 (Uri-Port) 1117 Option Delta = 0x4 (option nr = 4+3=7) 1118 Option Length = 0x4 1119 Option Value = 8085 1120 Option3 (Uri-Path) 1121 Option Delta = 0x4 (option nr = 7+4= 11) 1122 Option Length = 0x7 1123 Option Value = /est/es 1124 Payload = [Empty] 1126 A 2.05 Content response with an unsigned JSON voucher (ct=50) will 1127 then be: 1129 2.05 Content (Content-Format: application/json) 1130 {payload} 1132 With CoAP fields and payload: 1134 Ver=1 1135 T=2 (ACK) 1136 Code = 0x45 (2.05 Content) 1137 Options 1138 Option1 (Content-Format) 1139 Option Delta = 0xC (option nr 12) 1140 Option Length = 0x2 1141 Option Value = 0x32 (application/json) 1143 Payload = 1144 [EDNOTE: put here voucher payload ] 1146 A.2. voucher_status 1148 A coaps voucher_status message can be : 1150 GET coaps://[2001:db8::2:1]:61616]/est/vs 1152 A 2.05 Content response with a non signed CBOR voucher (ct=60) will 1153 then be: 1155 2.05 Content (Content-Format: application/cbor) 1156 Payload = 1157 [EDNOTE: put here voucher payload ] 1159 A.3. requestvoucher 1161 Two request-voucher request payloads are possible from pledge to 1162 Registrar, a signed one and an unsigned one, as explained in 1163 Section 5.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. 1165 A.3.1. signed requestvoucher 1167 A coaps signed requestvoucher message from RA to MASA can be : 1169 POST coaps://[2001:db8::2:1]:61616]/est/rv 1171 A 2.04 Changed response returning CBOR voucher signed with a cms 1172 structure(ct=TBD2) will then be: 1174 2.04 Changed (Content-Format: application/voucher-cms+cbor) 1175 Payload = 1176 [EDNOTE: put here encrypted voucher payload ] 1178 A.3.2. unsigned requestvoucher 1180 A coaps unsigned requestvoucher message from pledge to Registrar can 1181 be : 1183 POST coaps://[2001:db8::2:1]:61616]/est/rv 1185 A 2.04 Changed response returning CBOR voucher (ct=60) will then be: 1187 2.04 Changed (Content-Format: application/cbor) 1188 Payload = 1189 [EDNOTE: put here encrypted voucher payload ] 1191 A.4. requestauditing 1193 A coaps requestauditing message can be : 1195 GET coaps://[2001:db8::2:1]:61616]/est/ra 1197 A 2.05 Content response returning a COSE_Sign1 object (ct=TBD3) will 1198 then be: 1200 2.05 Content (Content-Format: application/voucher-cose+cbor) 1201 Payload = 1202 [EDNOTE: put here COSE_Sign1 voucher payload ] 1204 Authors' Addresses 1206 Michael Richardson 1207 Sandelman Software Works 1209 Email: mcr+ietf@sandelman.ca 1211 Peter van der Stok 1212 vanderstok consultancy 1214 Email: consultancy@vanderstok.org 1216 Panos Kampanakis 1217 Cisco Systems 1219 Email: pkampana@cisco.com