idnits 2.17.1 draft-ietf-opsawg-sbom-access-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 218 has weird spacing: '...on-info str...' -- The document date (18 May 2021) is 1067 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Rose 5 Expires: 19 November 2021 NIST 6 18 May 2021 8 Discovering And Accessing Software Bills of Materials 9 draft-ietf-opsawg-sbom-access-01 11 Abstract 13 Software bills of materials (SBOMs) are formal descriptions of what 14 pieces of software are included in a product. This memo specifies a 15 different means for SBOMs to be retrieved. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 19 November 2021. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Cases Not Addressed . . . . . . . . . . . . . . . . . . . 3 52 1.2. How This Information Is Used . . . . . . . . . . . . . . 4 53 1.3. SBOM formats . . . . . . . . . . . . . . . . . . . . . . 4 54 1.4. Discussion points . . . . . . . . . . . . . . . . . . . . 4 55 2. The .well-known/sbom endpoint set . . . . . . . . . . . . . . 5 56 3. The mud-sbom extension model extension . . . . . . . . . . . 5 57 4. The mud-sbom augmentation to the MUD YANG model . . . . . . . 5 58 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.1. Without ACLS . . . . . . . . . . . . . . . . . . . . . . 8 60 5.2. Located on the Device . . . . . . . . . . . . . . . . . . 9 61 5.3. SBOM Obtained from Contact Information . . . . . . . . . 9 62 5.4. With ACLS . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 7.1. MUD Extension . . . . . . . . . . . . . . . . . . . . . . 13 66 7.2. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 14 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 69 8.2. Informative References . . . . . . . . . . . . . . . . . 14 70 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 Software bills of material (SBOMs) are descriptions of what software, 76 including versioning and dependencies, a device contains. There are 77 different SBOM formats such as Software Package Data Exchange [SPDX] 78 or CycloneDX[CycloneDX12]. 80 This memo specifies means by which SBOMs can be advertised and 81 retrieved. 83 The mechanisms specified in this document are meant to satisfy 84 several use cases: 86 * A network-layer management system retrieving an SBOM from an IoT 87 device as part of its ongoing lifecycle. Such devices may or may 88 not have interfaces available to query SBOM information. 90 * An application-layer management system retrieving an SBOM in order 91 to evaluate the posture of an application server of some form. 92 These application servers may themselves be containers or 93 hypervisors. Discovery of the topology of a server is beyond the 94 scope of this memo. 96 To satisfy these two key use cases, SBOMs may be found in one of 97 three ways: 99 * on devices themselves 101 * on a web site (e.g., via URI) 103 * through some form of out-of-band contact with the supplier. 105 In the first case, devices will have interfaces that permit direct 106 SBOM retrieval. Examples of these interfaces might be an HTTP, COAP 107 or [OpenC2] endpoint for retrieval. There may also be private 108 interfaces as well. 110 In the second case, when a device does not have an appropriate 111 interface to retrieve an SBOM, but one is directly available from the 112 manufacturer, a URI to that information must be discovered. 114 In the third case, a supplier may wish to make an SBOM available 115 under certain circumstances, and may need to individually evaluate 116 requests. The result of that evaluation might be the SBOM itself or 117 a restricted URL or no access. 119 To enable application-layer discovery, this memo defines a well-known 120 URI [RFC8615]. Management or orchestration tools can query this 121 well-known URI to retrieve a system's SBOM. Further queries may be 122 necessary based on the content and structure of a particular SBOM. 124 To enable network-layer discovery, particularly for IOT-based 125 devices, an extension to Manufacturer Usage Descriptions (MUD) may be 126 used[RFC8520]. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 1.1. Cases Not Addressed 136 [ This section to be removed prior to publication ] 138 A separate use case may be addressed in future versions of this 139 document: 141 * Related to the application layer, software as a service may 142 involve multiple backend systems, depending on many factors. One 143 example might be a large cloud-based service that offers 144 spreadsheets, email, and document authoring and management. 145 Depending on what service is being used, a different set of back 146 end services may in turn be invoking different software that 147 should be listed. 149 The reason why this use case isn't addressed here is that it may be 150 better addressed inline within HTML. Further discussion is required. 152 1.2. How This Information Is Used 154 SBOMs are used for numerous purposes, including vulnerability 155 assessment, license management, and inventory management. This memo 156 provides means for either automated or semi-automated collection of 157 that information. For devices that can output a MUD URL or establish 158 a well-known URI, the mechanism may be highly automated. For devices 159 that have a MUD URL in either their documentation or within a QR code 160 on a box, the mechanism is semi-automated (someone has to scan the QR 161 code or enter the URL). 163 Note that SBOMs may change more frequently than access control 164 requirements. A change to software does not necessarily mean a 165 change to control channels that are used. Therefore, it is important 166 to retrieve the MUD file as suggested by the manufacturer in the 167 cache-validity period. In many cases, only the SBOM list will have 168 been updated. 170 1.3. SBOM formats 172 There are multiple ways to express an SBOM. When these are retrieved 173 either directly from the device or directly from a web server, tools 174 will need to observe the content-type header to determine precisely 175 which format is being transmitted. Because IoT devices in particular 176 have limited capabilities, use of a specific Accept: header in HTTP 177 or the Accept Option in CoAP is NOT RECOMMENDED. Instead, backend 178 tooling MUST silently discard SBOM information sent with a media type 179 that is not understood. 181 1.4. Discussion points 183 The following is discussion to be removed at time of RFC publication. 185 * Is the model structured correctly? 187 * Are there other retrieval mechanisms that need to be specified? 189 * Do we need to be more specific in how to authenticate and retrieve 190 SBOMs? 192 * What are the implications if the MUD URL is an extension in a 193 certificate (e.g. an IDevID cert)? 195 2. The .well-known/sbom endpoint set 197 If a host offers this service, it will offer the RESTful endpoint 198 beginning with "{ORIGIN}/.well-known/sbom/base". 200 3. The mud-sbom extension model extension 202 We now formally define this extension. This is done in two parts. 203 First, the extension name "sbom" is listed in the "extensions" array 204 of the MUD file. N.B., this schema extension is intended to be used 205 wherever it might be appropriate (e.g., not just MUD). 207 Second, the "mud" container is augmented with a list of SBOM sources. 209 This is done as follows: 211 module: ietf-mud-sbom 213 augment /mud:mud: 214 +--rw sbom 215 +--rw (sbom-type)? 216 +--:(cloud) 217 | +--rw sboms* [version-info] 218 | +--rw version-info string 219 | +--rw sbom-url? inet:uri 220 +--:(local-well-known) 221 | +--rw local-well-known? empty 222 +--:(contact-info) 223 | +--rw contact-uri inet:uri 224 +--:(openc2) 225 +--rw openc2-uri inet:uri 227 4. The mud-sbom augmentation to the MUD YANG model 229 230 file "ietf-mud-sbom@2021-04-29.yang" 231 module ietf-mud-sbom { 232 yang-version 1.1; 233 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-sbom"; 234 prefix mud-sbom; 236 import ietf-inet-types { 237 prefix inet; 238 } 239 import ietf-mud { 240 prefix mud; 241 } 243 organization 244 "IETF OPSAWG (Ops Area) Working Group"; 245 contact 246 "WG 247 Web: http://tools.ietf.org/wg/opsawg/ 248 WG List: opsawg@ietf.org 249 Author: Eliot Lear lear@cisco.com 250 Author: Scott Rose scott.rose@nist.gov"; 251 description 252 "This YANG module augments the ietf-mud model to provide for 253 reporting of SBOMs. 255 Copyright (c) 2020 IETF Trust and the persons identified as 256 authors of the code. All rights reserved. 258 Redistribution and use in source and binary forms, with or 259 without modification, is permitted pursuant to, and subject to 260 the license terms contained in, the Simplified BSD License set 261 forth in Section 4.c of the IETF Trust's Legal Provisions 262 Relating to IETF Documents 263 (https://trustee.ietf.org/license-info). 265 This version of this YANG module is part of RFC XXXX 266 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 267 for full legal notices. 269 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 270 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 271 'MAY', and 'OPTIONAL' in this document are to be interpreted as 272 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 273 they appear in all capitals, as shown here. "; 275 revision 2021-04-29 { 276 description 277 "Initial proposed standard."; 278 reference 279 "RFC XXXX: Extension for MUD SBOM"; 280 } 282 grouping mud-sbom-extension { 283 description 284 "SBOM extension grouping"; 285 container sbom { 286 description 287 "container of methods to get an SBOM."; 289 choice sbom-type { 290 description 291 "SBOM type"; 292 case cloud { 293 list sboms { 294 key "version-info"; 295 description 296 "A list of SBOMs tied to different s/w 297 or h/w versions."; 298 leaf version-info { 299 type string; 300 description 301 "The version to which this SBOM refers."; 302 } 303 leaf sbom-url { 304 type inet:uri; 305 description 306 "A statically located URI."; 307 } 308 } 309 } 310 case local-well-known { 311 leaf local-well-known { 312 type empty; 313 description 314 "SBOM information is to be retrieved via 315 https from the host on port 443, at 316 https://{hostname}/.well-known/sbom, where 317 hostname is replaced with the host to which 318 this MUD extension refers."; 319 } 320 } 321 case contact-info { 322 leaf contact-uri { 323 type inet:uri; 324 mandatory true; 325 description 326 "This MUST be either a tel, http, https, or 327 mailto uri schema that customers can use to 328 contact someone for SBOM information."; 329 } 330 } 331 case openc2 { 332 leaf openc2-uri { 333 type inet:uri; 334 mandatory true; 335 description 336 "A link to the OpenC2 https RESTful 337 \t mapping. The OpenC2 protocol is then 338 used to retrieve the SBOM"; 339 } 340 } 341 } 342 } 343 } 345 augment "/mud:mud" { 346 description 347 "Add extension for SBOMs."; 348 uses mud-sbom-extension; 349 } 350 } 351 353 5. Examples 355 In this example MUD file that uses a cloud service, the Frobinator 356 presents a location of the SBOM in a URL. Note, the ACLs in a MUD 357 file are NOT required, although they are a very good idea for IP- 358 based devices. The first MUD file demonstrates how to get the SBOM 359 without ACLs, and the second has ACLs. 361 5.1. Without ACLS 362 { 363 "ietf-mud:mud": { 364 "mud-version": 1, 365 "mud-url": "https://iot-device.example.com/dnsname", 366 "last-update": "2019-01-15T10:22:47+00:00", 367 "cache-validity": 48, 368 "is-supported": true, 369 "systeminfo": "device that wants to talk to a cloud service", 370 "mfg-name": "Example, Inc.", 371 "documentation": "https://frob.example.com/doc/frob2000", 372 "model-name": "Frobinator 2000", 373 "extensions" : [ 374 "sbom" 375 ], 376 "sboms" : { "sbom" : [ 377 { 378 "version-info" : "FrobOS Release 1.1", 379 "sbom-url" : "https://frob.example.com/sboms/f20001.1", 380 } 381 ] 382 } 383 } 384 } 386 5.2. Located on the Device 388 { 389 "ietf-mud:mud": { 390 "mud-version": 1, 391 "mud-url": "https://iot-device.example.com/dnsname", 392 "last-update": "2019-01-15T10:22:47+00:00", 393 "cache-validity": 48, 394 "is-supported": true, 395 "systeminfo": "device that wants to talk to a cloud service", 396 "mfg-name": "Example, Inc.", 397 "documentation": "https://frob.example.com/doc/frob2000", 398 "model-name": "Frobinator 2000", 399 "extensions" : [ 400 "sbom" 401 ], 402 "sboms" : "sbom" : { 403 "sbom-local" : "coaps:///.well-known/sbom", 404 } 405 } 406 } 408 5.3. SBOM Obtained from Contact Information 409 { 410 "ietf-mud:mud": { 411 "mud-version": 1, 412 "mud-url": "https://iot-device.example.com/dnsname", 413 "last-update": "2019-01-15T10:22:47+00:00", 414 "cache-validity": 48, 415 "is-supported": true, 416 "systeminfo": "device that wants to talk to a cloud service", 417 "mfg-name": "Example, Inc.", 418 "documentation": "https://frob.example.com/doc/frob2000", 419 "model-name": "Frobinator 2000", 420 "extensions" : [ 421 "sbom" 422 ], 423 "sboms" : { "sbom" : { 424 "contact-uri" : "mailto:sbom-requst@example.com", 425 } 426 } 427 } 428 } 430 5.4. With ACLS 432 { 433 "ietf-mud:mud": { 434 "mud-version": 1, 435 "mud-url": "https://iot-device.example.com/dnsname", 436 "last-update": "2019-01-15T10:22:47+00:00", 437 "cache-validity": 48, 438 "is-supported": true, 439 "systeminfo": "device that wants to talk to a cloud service", 440 "mfg-name": "Example, Inc.", 441 "documentation": "https://frob.example.com/doc/frob2000", 442 "model-name": "Frobinator 2000", 443 "extensions" : [ 444 "sbom" 445 ], 446 "sboms" : "sbom" : [ 447 { 448 "version-info" : "FrobOS Release 1.1", 449 "sbom-url" : "https://frob.example.com/sboms/f20001.1", 450 }, 451 ], 452 }, 453 "from-device-policy": { 454 "access-lists": { 455 "access-list": [ 456 { 457 "name": "mud-96898-v4fr" 458 }, 459 { 460 "name": "mud-96898-v6fr" 461 } 462 ] 463 } 464 }, 465 "to-device-policy": { 466 "access-lists": { 467 "access-list": [ 468 { 469 "name": "mud-96898-v4to" 470 }, 471 { 472 "name": "mud-96898-v6to" 473 } 474 ] 475 } 476 } 477 }, 478 "ietf-access-control-list:acls": { 479 "acl": [ 480 { 481 "name": "mud-96898-v4to", 482 "type": "ipv4-acl-type", 483 "aces": { 484 "ace": [ 485 { 486 "name": "cl0-todev", 487 "matches": { 488 "ipv4": { 489 "ietf-acldns:src-dnsname": "cloud.example.com" 490 } 491 }, 492 "actions": { 493 "forwarding": "accept" 494 } 495 } 496 ] 497 } 498 }, 499 { 500 "name": "mud-96898-v4fr", 501 "type": "ipv4-acl-type", 502 "aces": { 503 "ace": [ 504 { 505 "name": "cl0-frdev", 506 "matches": { 507 "ipv4": { 508 "ietf-acldns:dst-dnsname": "cloud.example.com" 509 } 510 }, 511 "actions": { 512 "forwarding": "accept" 513 } 514 } 515 ] 516 } 517 }, 518 { 519 "name": "mud-96898-v6to", 520 "type": "ipv6-acl-type", 521 "aces": { 522 "ace": [ 523 { 524 "name": "cl0-todev", 525 "matches": { 526 "ipv6": { 527 "ietf-acldns:src-dnsname": "cloud.example.com" 528 } 529 }, 530 "actions": { 531 "forwarding": "accept" 532 } 533 } 534 ] 535 } 536 }, 537 { 538 "name": "mud-96898-v6fr", 539 "type": "ipv6-acl-type", 540 "aces": { 541 "ace": [ 542 { 543 "name": "cl0-frdev", 544 "matches": { 545 "ipv6": { 546 "ietf-acldns:dst-dnsname": "cloud.example.com" 547 } 548 }, 549 "actions": { 550 "forwarding": "accept" 551 } 552 } 554 ] 555 } 556 } 557 ] 558 } 559 } 561 At this point, the management system can attempt to retrieve the 562 SBOM, and determine which format is in use through the content-type 563 header on the response to a GET request. 565 6. Security Considerations 567 SBOMs provide an inventory of software. If firmware is available to 568 an attacker, the attacker may well already be able to derive this 569 very same software inventory. Manufacturers MAY restrict access to 570 SBOM information using appropriate authorization semantics within 571 HTTP. In particular, if a system attempts to retrieve an SBOM via 572 HTTP and the client is not authorized, the server MUST produce an 573 appropriate error, with instructions on how to register a particular 574 client. One example may be to issue a certificate to the client for 575 this purpose after a registration process has taken place. Another 576 example would involve the use of OAUTH in combination with a 577 federations of SBOM servers. 579 Another risk is a skew in the SBOM listing and the actual software 580 inventory of a device/container. For example, a manufacturer may 581 update the SBOM on its server, but an individual device has not be 582 upgraded yet. This may result in an incorrect policy being applied 583 to a device. A unique mapping of a device's firmware version and its 584 SBOM can minimize this risk. 586 To further mitigate attacks against a device, manufacturers SHOULD 587 recommend access controls through the normal MUD mechanism. 589 7. IANA Considerations 591 7.1. MUD Extension 593 The IANA is requested to add "controller-candidate" to the MUD 594 extensions registry as follows: 596 Extension Name: sbom 597 Standard reference: This document 599 7.2. Well-Known Prefix 601 The following well known URI is requested in accordance with 602 [RFC8615]: 604 URI suffix: "sbom" 605 Change controller: "IETF" 606 Specification document: This memo 607 Related information: See ISO/IEC 19970-2 and SPDX.org 609 8. References 611 8.1. Normative References 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 619 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 620 May 2017, . 622 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 623 Description Specification", RFC 8520, 624 DOI 10.17487/RFC8520, March 2019, 625 . 627 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 628 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 629 . 631 8.2. Informative References 633 [CycloneDX12] 634 cylonedx.org, "CycloneDX XML Reference v1.2", May 2020. 636 [OpenC2] Lemire, D., Ed., "Specification for Transfer of OpenC2 637 Messages via HTTPS Version 1.0", July 2019, 638 . 641 [SPDX] The Linux Foundation, "SPDX Specification 2.1", 2016. 643 Appendix A. Changes from Earlier Versions 645 Draft -00: 647 * Initial revision 649 Authors' Addresses 651 Eliot Lear 652 Cisco Systems 653 Richtistrasse 7 654 CH-8304 Wallisellen 655 Switzerland 657 Phone: +41 44 878 9200 658 Email: lear@cisco.com 660 Scott Rose 661 NIST 662 100 Bureau Dr 663 Gaithersburg MD, 20899 664 United States of America 666 Phone: +1 301-975-8439 667 Email: scott.rose@nist.gov