idnits 2.17.1 draft-lear-opsawg-sbom-access-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2020) is 1284 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) == Unused Reference: 'RFC6991' is defined on line 597, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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: April 16, 2021 NIST 6 October 13, 2020 8 Discovering And Accessing Software Bills of Materials 9 draft-lear-opsawg-sbom-access-00 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 April 16, 2021. 34 Copyright Notice 36 Copyright (c) 2020 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. How This Information Is Used . . . . . . . . . . . . . . 3 53 1.2. SBOM formats . . . . . . . . . . . . . . . . . . . . . . 4 54 1.3. Discussion points . . . . . . . . . . . . . . . . . . . . 4 55 2. The mud-sbom extension model extension . . . . . . . . . . . 4 56 3. The mud-sbom augmentation to the MUD YANG model . . . . . . . 5 57 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.1. Without ACLS . . . . . . . . . . . . . . . . . . . . . . 8 59 4.2. Located on the Device . . . . . . . . . . . . . . . . . . 8 60 4.3. SBOM Obtained from Contact Information . . . . . . . . . 9 61 4.4. With ACLS . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 6.1. MUD Extension . . . . . . . . . . . . . . . . . . . . . . 13 65 6.2. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 13 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 68 7.2. Informative References . . . . . . . . . . . . . . . . . 14 69 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 Software bills of material (SBOMs) are descriptions of what software, 75 including versioning and dependencies, a device contains. There are 76 different SBOM formats such as Software Package Data Exchange [SPDX], 77 Software Identity Tags [SWID], or CycloneDX[CycloneDX12]. 79 This memo specifies means by which SBOMs can be advertised and 80 retrieved. 82 The mechanisms specified in this document are meant to satisfy 83 several use cases: 85 o An application-layer management system retrieving an SBOM in order 86 to evaluate the posture of an application server of some form. 87 These application servers may themselves be containers or 88 hypervisors. Discovery of the topology of a server is beyond the 89 scope of this memo. 91 o A network-layer management system retrieving an SBOM from an IoT 92 device as part of its ongoing lifecycle. Such devices may or may 93 not have interfaces available to query SBOM information. 95 To satisfy these two key use cases, SBOMs may be found in one of 96 three ways: 98 o on devices themselves 100 o on a web site (e.g., via URI) 102 o through some form of out-of-band contact with the supplier. 104 In the first case, devices will have interfaces that permit direct 105 SBOM retrieval. Examples of these interfaces might be an HTTP or 106 COAP endpoint for retrieval. There may also be private interfaces as 107 well. 109 In the second case, when a device does not have an appropriate 110 interface to retrieve an SBOM, but one is directly available from the 111 manufacturer, a URI to that information must be discovered. 113 In the third case, a supplier may wish to make an SBOM available 114 under certain circumstances, and may need to individually evaluate 115 requests. The result of that evaluation might be the SBOM itself or 116 a restricted URL or no access. 118 To enable application-layer discovery, this memo defines a well-known 119 URI [RFC8615]. Management or orchestration tools can query this 120 well-known URI to retrieve a system's SBOM. Further queries may be 121 necessary based on the content and structure of a particular SBOM. 123 To enable network-layer discovery, particularly for IOT-based 124 devices, an extension to Manufacturer Usage Descriptions (MUD) may be 125 used[RFC8520]. 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 1.1. How This Information Is Used 135 SBOMs are used for numerous purposes, including vulnerability 136 assessment, license management, and inventory management. This memo 137 provides means for either automated or semi-automated collection of 138 that information. For devices that can output a MUD URL or establish 139 a well-known URI, the mechanism may be highly automated. For devices 140 that have a MUD URL in either their documentation or within a QR code 141 on a box, the mechanism is semi-automated (someone has to scan the QR 142 code or enter the URL). 144 Note that SBOMs may change more frequently than access control 145 requirements. A change to software does not necessarily mean a 146 change to control channels that are used. Therefore, it is important 147 to retrieve the MUD file as suggested by the manufacturer in the 148 cache-validity period. In many cases, only the SBOM list will have 149 been updated. 151 1.2. SBOM formats 153 There are multiple ways to express an SBOM. When these are retrieved 154 either directly from the device or directly from a web server, tools 155 will need to observe the content-type header to determine precisely 156 which format is being transmitted. Because IoT devices in particular 157 have limited capabilities, use of a specific Accept: header in HTTP 158 or the Accept Option in CoAP is NOT RECOMMENDED. Instead, backend 159 tooling MUST silently discard SBOM information sent with a media type 160 that is not understood. 162 1.3. Discussion points 164 The following is discussion to be removed at time of RFC publication. 166 o Is the model structured correctly? 168 o Are there other retrieval mechanisms that need to be specified? 170 o Do we need to be more specific in how to authenticate and retrieve 171 SBOMs? 173 o What are the implications if the MUD URL is an extension in a 174 certificate (e.g. an IDevID cert)? 176 2. The mud-sbom extension model extension 178 We now formally define this extension. This is done in two parts. 179 First, the extension name "sbom" is listed in the "extensions" array 180 of the MUD file. 182 Second, the "mud" container is augmented with a list of SBOM sources. 184 This is done as follows: 186 module: ietf-mud-sbom 187 augment /mud:mud: 188 +--rw sboms* [version-info] 189 +--rw version-info string 190 +--rw (sbom-type)? 191 +--:(url) 192 | +--rw sbom-url? inet:uri 193 +--:(local-uri) 194 | +--rw sbom-local* enumeration 195 +--:(contact-info) 196 +--rw contact-uri? inet:uri 198 3. The mud-sbom augmentation to the MUD YANG model 200 file "ietf-mud-sbom@2020-03-06.yang" 201 module ietf-mud-sbom { 202 yang-version 1.1; 203 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-sbom"; 204 prefix mud-sbom; 206 import ietf-inet-types { 207 prefix inet; 208 } 209 import ietf-mud { 210 prefix mud; 211 } 213 organization 214 "IETF OPSAWG (Ops Area) Working Group"; 215 contact 216 "WG 217 Web: http://tools.ietf.org/wg/opsawg/ 218 WG List: opsawg@ietf.org 219 Author: Eliot Lear lear@cisco.com "; 220 description 221 "This YANG module augments the ietf-mud model to provide for 222 reporting of SBOMs. 224 Copyright (c) 2019 IETF Trust and the persons identified as 225 authors of the code. All rights reserved. 227 Redistribution and use in source and binary forms, with or 228 without modification, is permitted pursuant to, and subject to 229 the license terms contained in, the Simplified BSD License set 230 forth in Section 4.c of the IETF Trust's Legal Provisions 231 Relating to IETF Documents 232 (https://trustee.ietf.org/license-info). 234 This version of this YANG module is part of RFC XXXX 235 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for 236 full legal notices. 238 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 239 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 240 'MAY', and 'OPTIONAL' in this document are to be interpreted as 241 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 242 they appear in all capitals, as shown here. "; 244 revision 2020-03-06 { 245 description 246 "Initial proposed standard."; 247 reference 248 "RFC XXXX: Extension for MUD Reporting"; 249 } 251 grouping mud-sbom-extension { 252 description 253 "SBOM extension grouping"; 254 list sboms { 255 key "version-info"; 256 leaf version-info { 257 type string; 258 description 259 "A version string that is applicable for this SBOM list entry. 260 The format of this string is left to the device manufacturer. 261 How the network administrator determines the version of 262 software running on the device is beyond the scope of this 263 memo."; 264 } 265 choice sbom-type { 266 case url { 267 leaf sbom-url { 268 type inet:uri; 269 description 270 "A statically located URI."; 271 } 272 } 273 case local-uri { 274 leaf-list sbom-local { 275 type enumeration { 276 enum coap { 277 description 278 "Use COAP schema to retrieve SBOM"; 279 } 280 enum coaps { 281 description 282 "Use COAPS schema to retrieve SBOM"; 283 } 284 enum http { 285 description 286 "Use HTTP schema to retrieve SBOM"; 287 } 288 enum https { 289 description 290 "Use HTTPS schema to retrieve SBOM"; 291 } 292 } 293 description 294 "The choice of sbom-local means that the SBOM resides at 295 a location indicated by an indicted scheme for the 296 device in question, at well known location 297 '/.well-known/sbom'. For example, if the MUD file 298 indicates that coaps is to be used and the host is 299 located at address 10.1.2.3, the SBOM could be retrieved 300 at 'coaps://10.1.2.3/.well-known/sbom'. N.B., coap and 301 http schemes are NOT RECOMMENDED."; 302 } 303 } 304 case contact-info { 305 leaf contact-uri { 306 type inet:uri; 307 description 308 "This MUST be either a tel, http, https, or 309 mailto uri schema that customers can use to 310 contact someone for SBOM information."; 311 } 312 } 313 description 314 "choices for SBOM retrieval."; 315 } 316 description 317 "list of methods to get an SBOM."; 318 } 319 } 321 augment "/mud:mud" { 322 description 323 "Add extension for SBOMs."; 324 uses mud-sbom-extension; 325 } 326 } 328 329 4. Examples 331 In this example MUD file that uses a cloud service, the Frobinator 332 presents a location of the SBOM in a URL. Note, the ACLs in a MUD 333 file are NOT required, although they are a very good idea for IP- 334 based devices. The first MUD file demonstrates how to get the SBOM 335 without ACLs, and the second has ACLs. 337 4.1. Without ACLS 339 { 340 "ietf-mud:mud": { 341 "mud-version": 1, 342 "mud-url": "https://iot-device.example.com/dnsname", 343 "last-update": "2019-01-15T10:22:47+00:00", 344 "cache-validity": 48, 345 "is-supported": true, 346 "systeminfo": "device that wants to talk to a cloud service", 347 "mfg-name": "Example, Inc.", 348 "documentation": "https://frobinator.example.com/doc/frob2000", 349 "model-name": "Frobinator 2000", 350 "extensions" : [ 351 "sbom" 352 ], 353 "sboms" : [ 354 { 355 "version-info" : "FrobOS Release 1.1", 356 "sbom-url" : "https://frobinator.example.com/sboms/f20001.1", 357 } 358 ] 359 } 360 } 362 4.2. Located on the Device 363 { 364 "ietf-mud:mud": { 365 "mud-version": 1, 366 "mud-url": "https://iot-device.example.com/dnsname", 367 "last-update": "2019-01-15T10:22:47+00:00", 368 "cache-validity": 48, 369 "is-supported": true, 370 "systeminfo": "device that wants to talk to a cloud service", 371 "mfg-name": "Example, Inc.", 372 "documentation": "https://frobinator.example.com/doc/frob2000", 373 "model-name": "Frobinator 2000", 374 "extensions" : [ 375 "sbom" 376 ], 377 "sboms" : [ 378 { 379 "version-info" : "FrobOS Release 1.1", 380 "sbom-local" : "coaps:///.well-known/sbom", 381 } 382 ] 383 } 384 } 386 4.3. SBOM Obtained from Contact Information 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://frobinator.example.com/doc/frob2000", 398 "model-name": "Frobinator 2000", 399 "extensions" : [ 400 "sbom" 401 ], 402 "sboms" : [ 403 { 404 "version-info" : "FrobOS Release 1.1", 405 "contact-uri" : "mailto:sbom-requst@example.com", 406 } 407 ] 408 } 409 } 411 4.4. With ACLS 413 { 414 "ietf-mud:mud": { 415 "mud-version": 1, 416 "mud-url": "https://iot-device.example.com/dnsname", 417 "last-update": "2019-01-15T10:22:47+00:00", 418 "cache-validity": 48, 419 "is-supported": true, 420 "systeminfo": "device that wants to talk to a cloud service", 421 "mfg-name": "Example, Inc.", 422 "documentation": "https://frobinator.example.com/doc/frob2000", 423 "model-name": "Frobinator 2000", 424 "extensions" : [ 425 "sbom" 426 ], 427 "sboms" : [ 428 { 429 "version-info" : "FrobOS Release 1.1", 430 "sbom-url" : "https://frobinator.example.com/sboms/f20001.1", 431 } 432 ], 433 "from-device-policy": { 434 "access-lists": { 435 "access-list": [ 436 { 437 "name": "mud-96898-v4fr" 438 }, 439 { 440 "name": "mud-96898-v6fr" 441 } 442 ] 443 } 444 }, 445 "to-device-policy": { 446 "access-lists": { 447 "access-list": [ 448 { 449 "name": "mud-96898-v4to" 450 }, 451 { 452 "name": "mud-96898-v6to" 453 } 454 ] 455 } 456 } 457 }, 458 "ietf-access-control-list:acls": { 459 "acl": [ 460 { 461 "name": "mud-96898-v4to", 462 "type": "ipv4-acl-type", 463 "aces": { 464 "ace": [ 465 { 466 "name": "cl0-todev", 467 "matches": { 468 "ipv4": { 469 "ietf-acldns:src-dnsname": "cloud-service.example.com" 470 } 471 }, 472 "actions": { 473 "forwarding": "accept" 474 } 475 } 476 ] 477 } 478 }, 479 { 480 "name": "mud-96898-v4fr", 481 "type": "ipv4-acl-type", 482 "aces": { 483 "ace": [ 484 { 485 "name": "cl0-frdev", 486 "matches": { 487 "ipv4": { 488 "ietf-acldns:dst-dnsname": "cloud-service.example.com" 489 } 490 }, 491 "actions": { 492 "forwarding": "accept" 493 } 494 } 495 ] 496 } 497 }, 498 { 499 "name": "mud-96898-v6to", 500 "type": "ipv6-acl-type", 501 "aces": { 502 "ace": [ 503 { 504 "name": "cl0-todev", 505 "matches": { 506 "ipv6": { 507 "ietf-acldns:src-dnsname": "cloud-service.example.com" 508 } 509 }, 510 "actions": { 511 "forwarding": "accept" 512 } 513 } 514 ] 515 } 516 }, 517 { 518 "name": "mud-96898-v6fr", 519 "type": "ipv6-acl-type", 520 "aces": { 521 "ace": [ 522 { 523 "name": "cl0-frdev", 524 "matches": { 525 "ipv6": { 526 "ietf-acldns:dst-dnsname": "cloud-service.example.com" 527 } 528 }, 529 "actions": { 530 "forwarding": "accept" 531 } 532 } 533 ] 534 } 535 } 536 ] 537 } 538 } 540 At this point, the management system can attempt to retrieve the 541 SBOM, and determine which format is in use through the content-type 542 header on the response to a GET request. 544 5. Security Considerations 546 SBOMs provide an inventory of software. If firmware is available to 547 an attacker, the attacker may well already be able to derive this 548 very same software inventory. Manufacturers MAY restrict access to 549 SBOM information using appropriate authorization semantics within 550 HTTP. In particular, if a system attempts to retrieve an SBOM via 551 HTTP, if the client is not authorized, the server MUST produce an 552 appropriate error, with instructions on how to register a particular 553 client. One example may be to issue a certificate to the client for 554 this purpose after a registration process has taken place. Another 555 example would involve the use of OAUTH in combination with a 556 federations of SBOM servers. 558 Another risk is a skew in the SBOM listing and the actual software 559 inventory of a device/container. For example, a manufactuer may 560 update the SBOM on its server, but an individual device has not be 561 upgraded yet. This may result in an incorrect policy being applied 562 to a device. A unique mapping of a device's firmware version and its 563 SBOM can minimize this risk. 565 To further mitigate attacks against a device, manufacturers SHOULD 566 recommend access controls through the normal MUD mechanism. 568 6. IANA Considerations 570 6.1. MUD Extension 572 The IANA is requested to add "controller-candidate" to the MUD 573 extensions registry as follows: 575 Extension Name: sbom 576 Standard reference: This document 578 6.2. Well-Known Prefix 580 The following well known URI is requested in accordance with 581 [RFC8615]: 583 URI suffix: "sbom" 584 Change controller: "IETF" 585 Specification document: This memo 586 Related information: See ISO/IEC 19970-2 and SPDX.org 588 7. References 590 7.1. Normative References 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, 594 DOI 10.17487/RFC2119, March 1997, 595 . 597 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 598 RFC 6991, DOI 10.17487/RFC6991, July 2013, 599 . 601 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 602 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 603 May 2017, . 605 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 606 Description Specification", RFC 8520, 607 DOI 10.17487/RFC8520, March 2019, 608 . 610 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 611 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 612 . 614 7.2. Informative References 616 [CycloneDX12] 617 cylonedx.org, "CycloneDX XML Reference v1.2", May 2020. 619 [SPDX] The Linux Foundation, "SPDX Specification 2.1", 2016. 621 [SWID] ISO/IEC, "Information technology -- IT asset management -- 622 Part 2: Software identification tag", ISO 19770-2:2015, 623 2015. 625 Appendix A. Changes from Earlier Versions 627 Draft -00: 629 o Initial revision 631 Authors' Addresses 633 Eliot Lear 634 Cisco Systems 635 Richtistrasse 7 636 Wallisellen CH-8304 637 Switzerland 639 Phone: +41 44 878 9200 640 Email: lear@cisco.com 641 Scott Rose 642 NIST 643 100 Bureau Dr 644 Gaithersburg MD 20899 645 USA 647 Phone: +1 301-975-8439 648 Email: scott.rose@nist.gov