idnits 2.17.1 draft-ietf-opsawg-sbom-access-05.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 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 260 has weird spacing: '...on-info str...' -- The document date (6 March 2022) is 782 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 803, but no explicit reference was found in the text Summary: 1 error (**), 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: 7 September 2022 NIST 6 6 March 2022 8 Discovering and Retrieving Software Transparency and Vulnerability 9 Information 10 draft-ietf-opsawg-sbom-access-05 12 Abstract 14 To improve cybersecurity posture, automation is necessary to locate 15 what software is running on a device, whether that software has known 16 vulnerabilities, and what, if any recommendations suppliers may have. 17 This memo specifies a model to provide access to this information. 18 It may optionally be discovered through manufacturer usage 19 descriptions. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 7 September 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. How This Information Is Retrieved . . . . . . . . . . . . 5 56 1.2. Formats . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.3. Discussion points . . . . . . . . . . . . . . . . . . . . 5 58 2. The well-known transparency endpoint set . . . . . . . . . . 6 59 3. The mud-transparency extension model extension . . . . . . . 6 60 4. The mud-sbom augmentation to the MUD YANG model . . . . . . . 6 61 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5.1. Without ACLS . . . . . . . . . . . . . . . . . . . . . . 10 63 5.2. SBOM Located on the Device . . . . . . . . . . . . . . . 12 64 5.3. Further contact required. . . . . . . . . . . . . . . . . 13 65 5.4. With ACLS . . . . . . . . . . . . . . . . . . . . . . . . 14 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 68 7.1. MUD Extension . . . . . . . . . . . . . . . . . . . . . . 18 69 7.2. YANG Registration . . . . . . . . . . . . . . . . . . . . 18 70 7.3. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 18 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 74 9.2. Informative References . . . . . . . . . . . . . . . . . 20 75 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 20 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 78 1. Introduction 80 A number of activities have been working to improve visibility to 81 what software is running on a system, and what vulnerabilities that 82 software may have[EO2021]. 84 Put simply, we seek to answer two classes of questions *at scale*: 86 * Is this system vulnerable to a particular vulnerability? 88 * Which devices in a particular environment contain vulnerabilities 89 that require some action? 91 This memo doesn't specify the format of this information, but rather 92 only how to locate and retrieve these objects. 94 Software bills of materials (SBOMs) are descriptions of what 95 software, including versioning and dependencies, a device contains. 96 There are different SBOM formats such as Software Package Data 97 Exchange [SPDX] or CycloneDX[CycloneDX12]. 99 System vulnerabilities may similarly be described using several data 100 formats, including the aforementioned CycloneDX, Common Vulnerability 101 Reporting Framework [CVRF], the Common Security Advisory Format 102 [CSAF]. This information is typically used to report to customers 103 the state of a system. 105 These two classes of information can be used in concert. For 106 instance, a network management tool may discover that a system makes 107 use of a particular software component that has a known 108 vulnerability, and a vulnerability report may be used to indicate 109 what if any versions of software correct that vulnerability, or 110 whether the system exercises the vulnerable code at all. 112 Both classes of information elements are optional under the model 113 specified in this memo. One can provide only an SBOM, only 114 vulnerability information, or both an SBOM and vulnerability 115 information. 117 Note that SBOM formats may also carry other information, the most 118 common being any licensing terms. Because this specification is 119 neutral regarding content, it is left for format developers such as 120 the Linux Foundation, OASIS, and ISO to decide what attributes they 121 will support. 123 This memo does not specify how vulnerability information may be 124 retrieved directly from the endpoint. That's because vulnerability 125 information changes occur at different rates to software updates. 126 However, some SBOM formats may also contain vulnerability 127 information. 129 SBOMs and vulnerability information are advertised and retrieved 130 through the use of a YANG augmentation of the Manufacturer User 131 Description (MUD) model [RFC8520]. Note that the schema creates a 132 grouping that can also be used independently of MUD. Moreover, other 133 MUD features, such as access controls, needn't be present. 135 The mechanisms specified in this document are meant to satisfy 136 several use cases: 138 * A network-layer management system retrieving information from an 139 IoT device as part of its ongoing lifecycle. Such devices may or 140 may not have query interfaces available. 142 * An application-layer management system retrieving vulnerability or 143 SBOM information in order to evaluate the posture of an 144 application server of some form. These application servers may 145 themselves be containers or hypervisors. Discovery of the 146 topology of a server is beyond the scope of this memo. 148 To satisfy these two key use cases, objects may be found in one of 149 three ways: 151 * on devices themselves 153 * on a web site (e.g., via URI) 155 * through some form of out-of-band contact with the supplier. 157 In the first case, devices will have interfaces that permit direct 158 retrieval. Examples of these interfaces might be an HTTP, COAP or 159 [OpenC2] endpoint for retrieval. There may also be private 160 interfaces as well. 162 In the second case, when a device does not have an appropriate 163 retrieval interface, but one is directly available from the 164 manufacturer, a URI to that information MUST be discovered. 166 In the third case, a supplier may wish to make an SBOM or 167 vulnerability information available under certain circumstances, and 168 may need to individually evaluate requests. The result of that 169 evaluation might be the SBOM or vulnerability itself or a restricted 170 URL or no access. 172 To enable application-layer discovery, this memo defines a well-known 173 URI [RFC8615]. Management or orchestration tools can query this 174 well-known URI to retrieve a system's SBOM or vulnerability 175 information. Further queries may be necessary based on the content 176 and structure of the response. 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 1.1. How This Information Is Retrieved 186 For devices that can emit a URL or can establish a well-known URI, 187 the mechanism may be highly automated. For devices that have a URL 188 in either their documentation or within a QR code on a box, the 189 mechanism is semi-automated (someone has to scan the QR code or enter 190 the URL). 192 Note that vulnerability and SBOM information is likely to change at 193 different rates. The MUD semantics provide a way for manufacturers 194 to control how often tooling should check for those changes through 195 the cache-validity node. 197 1.2. Formats 199 There are multiple ways to express both SBOMs and vulnerability 200 information. When these are retrieved either directly from the 201 device or directly from a web server, tools will need to observe the 202 content-type header to determine precisely which format is being 203 transmitted. Because IoT devices in particular have limited 204 capabilities, use of a specific Accept: header in HTTP or the Accept 205 Option in CoAP is NOT RECOMMENDED. Instead, backend tooling is 206 encouraged to support all known formats, and SHOULD silently discard 207 SBOM information sent with a media type that is not understood. 209 Some formats may support both vulnerability and software inventory 210 information. When both vulnerability and software inventory 211 information is available from the same location, both sbom and vuln 212 nodes MUST indicate that. Network management systems retrieving this 213 information MUST take note that the identical resource is being 214 retrieved rather than retrieving it twice. 216 1.3. Discussion points 218 The following is discussion to be removed at time of RFC publication. 220 * Is the model structured correctly? 222 * Are there other retrieval mechanisms that need to be specified? 224 * Do we need to be more specific in how to authenticate and retrieve 225 SBOMs? 227 * What are the implications if the MUD URL is an extension in a 228 certificate (e.g. an IDevID cert)? 230 2. The well-known transparency endpoint set 232 Two well known endpoints are defined: 234 * "/.well-known/sbom" retrieves an SBOM. 236 * "/.well-known/openc2" is the HTTPS binding to OpenC2. 238 As discussed previously, the precise format of a response is based on 239 the Content-type provided. 241 3. The mud-transparency extension model extension 243 We now formally define this extension. This is done in two parts. 244 First, the extension name "transparency" is listed in the 245 "extensions" array of the MUD file. N.B., this schema extension is 246 intended to be used wherever it might be appropriate (e.g., not just 247 MUD). 249 Second, the "mud" container is augmented with a list of SBOM sources. 251 This is done as follows: 253 module: ietf-mud-transparency 255 augment /mud:mud: 256 +--rw transparency 257 +--rw (sbom-retrieval-method)? 258 | +--:(cloud) 259 | | +--rw sboms* [version-info] 260 | | +--rw version-info string 261 | | +--rw sbom-url? inet:uri 262 | +--:(local-well-known) 263 | | +--rw sbom-local-well-known? enumeration 264 | +--:(sbom-contact-info) 265 | +--rw sbom-contact-uri inet:uri 266 +--rw (vuln-retrieval-method)? 267 +--:(cloud) 268 | +--rw vuln-url? inet:uri 269 +--:(vuln-contact-info) 270 +--rw contact-uri inet:uri 272 4. The mud-sbom augmentation to the MUD YANG model 273 274 file "ietf-mud-transparency@2021-10-22.yang" 275 module ietf-mud-transparency { 276 yang-version 1.1; 277 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-transparency"; 278 prefix mudtx; 280 import ietf-inet-types { 281 prefix inet; 282 reference "RFC 6991"; 283 } 284 import ietf-mud { 285 prefix mud; 286 reference "RFC 8520"; 287 } 289 organization 290 "IETF OPSAWG (Ops Area) Working Group"; 291 contact 292 "WG Web: http://tools.ietf.org/wg/opsawg/ 293 WG List: opsawg@ietf.org 295 Editor: Eliot Lear lear@cisco.com 296 Editor: Scott Rose scott.rose@nist.gov"; 297 description 298 "This YANG module augments the ietf-mud model to provide for 299 reporting of SBOMs and vulnerability information. 301 Copyright (c) 2020 IETF Trust and the persons identified as 302 authors of the code. All rights reserved. 304 Redistribution and use in source and binary forms, with or 305 without modification, is permitted pursuant to, and subject to 306 the license terms contained in, the Simplified BSD License set 307 forth in Section 4.c of the IETF Trust's Legal Provisions 308 Relating to IETF Documents 309 (https://trustee.ietf.org/license-info). 311 This version of this YANG module is part of RFC XXXX 312 (https://www.rfc-editor.org/info/rfcXXXX); 313 see the RFC itself for full legal notices. 315 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 316 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 317 'MAY', and 'OPTIONAL' in this document are to be interpreted as 318 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 319 they appear in all capitals, as shown here. "; 321 revision 2021-07-06 { 322 description 323 "Initial proposed standard."; 324 reference 325 "RFC XXXX: Discovering and Retrieving Software Transparency 326 and Vulnerability Information"; 327 } 329 grouping transparency-extension { 330 description 331 "Transparency extension grouping"; 332 container transparency { 333 description 334 "container of methods to get an SBOM."; 335 choice sbom-retrieval-method { 336 description 337 "How to find SBOM information"; 338 case cloud { 339 list sboms { 340 key "version-info"; 341 description 342 "A list of SBOMs tied to different s/w 343 or h/w versions."; 344 leaf version-info { 345 type string; 346 description 347 "The version to which this SBOM refers."; 348 } 349 leaf sbom-url { 350 type inet:uri; 351 description 352 "A statically located URI."; 353 } 354 } 355 } 356 case local-well-known { 357 leaf sbom-local-well-known { 358 type enumeration { 359 enum http { 360 description 361 "Use http (insecure) to retrieve 362 SBOM information. This method is NOT RECOMMENDED, 363 but may be unavoidable for certain classes of 364 deployment, where TLS has not or cannot be implemented"; 365 } 366 enum https { 367 description 368 "Use https (secure) to retrieve SBOM information."; 370 } 371 enum coap { 372 description 373 "Use COAP (insecure) to retrieve SBOM. This method 374 is NOT RECOMMENDED, although it may be unavoidable 375 for certain classes of implementations/deployments."; 376 } 377 enum coaps { 378 description 379 "Use COAPS (secure) to retrieve SBOM"; 380 } 381 enum openc2 { 382 description 383 "Use OpenC2 endpoint. 384 This is https://{host}/.well-known/openc2"; 385 } 386 } 387 description 388 "Which communication protocol to choose."; 389 } 390 } 391 case sbom-contact-info { 392 leaf sbom-contact-uri { 393 type inet:uri; 394 mandatory true; 395 description 396 "This MUST be either a tel, http, https, or 397 mailto uri schema that customers can use to 398 contact someone for SBOM information."; 399 } 400 } 401 } 402 choice vuln-retrieval-method { 403 description 404 "How to find vulnerability information"; 405 case cloud { 406 leaf vuln-url { 407 type inet:uri; 408 description 409 "A statically located URL."; 410 } 411 } 412 case vuln-contact-info { 413 leaf contact-uri { 414 type inet:uri; 415 mandatory true; 416 description 417 "This MUST be either a tel, http, https, or 418 mailto uri schema that customers can use to 419 contact someone for vulnerability information."; 420 } 421 } 422 } 423 } 424 } 426 augment "/mud:mud" { 427 description 428 "Add extension for software transparency."; 429 uses transparency-extension; 430 } 431 } 432 434 5. Examples 436 In this example MUD file that uses a cloud service, the modelX 437 presents a location of the SBOM in a URL. Note, the ACLs in a MUD 438 file are NOT required, although they are a very good idea for IP- 439 based devices. 441 5.1. Without ACLS 443 This first MUD file demonstrates how to get SBOM and vulnerability 444 information without ACLs. 446 { 447 "ietf-mud:mud": { 448 "mud-version": 1, 449 "extensions": [ 450 "ol", 451 "transparency" 452 ], 453 "ol": { 454 "owners": [ 455 "Copyright (c) Example, Inc. 2022. All Rights Reserved" 456 ], 457 "spdx-tag": "0BSD" 458 }, 459 "mudtx:transparency": { 460 "sbom-local-well-known": "https", 461 "vuln-url": "https://iot.example.com/info/modelX/csaf.json" 462 }, 463 "mud-url": "https://iot.example.com/modelX.json", 464 "mud-signature": "https://iot.example.com/modelX.p7s", 465 "last-update": "2022-01-05T13:29:12+00:00", 466 "cache-validity": 48, 467 "is-supported": true, 468 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 469 "mfg-name": "Example, Inc.", 470 "documentation": "https://iot.example.com/doc/modelX", 471 "model-name": "modelX" 472 } 473 } 475 The second example demonstrates that just SBOM information is 476 included. 478 { 479 "ietf-mud:mud": { 480 "mud-version": 1, 481 "extensions": [ 482 "ol", 483 "transparency" 484 ], 485 "ol": { 486 "owners": [ 487 "Copyright (c) Example, Inc. 2022. All Rights Reserved" 488 ], 489 "spdx-tag": "0BSD" 490 }, 491 "mudtx:transparency": { 492 "sbom-local-well-known": "https" 493 }, 494 "mud-url": "https://iot.example.com/modelX.json", 495 "mud-signature": "https://iot.example.com/modelX.p7s", 496 "last-update": "2022-01-05T13:29:47+00:00", 497 "cache-validity": 48, 498 "is-supported": true, 499 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 500 "mfg-name": "Example, Inc.", 501 "documentation": "https://iot.example.com/doc/modelX", 502 "model-name": "modelX" 503 } 504 } 506 5.2. SBOM Located on the Device 508 In this example, the SBOM is retrieved from the device, while 509 vulnerability information is available from the cloud. This is 510 likely a common case, because vendors may learn of vulnerability 511 information more frequently than they update software. 513 { 514 "ietf-mud:mud": { 515 "mud-version": 1, 516 "extensions": [ 517 "transparency" 518 ], 519 "mudtx:transparency": { 520 "sbom-local-well-known": "https", 521 "vuln-url": "https://iot-device.example.com/info/modelX/csaf.json" 522 }, 523 "mud-url": "https://iot-device.example.com/modelX.json", 524 "mud-signature": "https://iot-device.example.com/modelX.p7s", 525 "last-update": "2022-01-05T13:25:14+00:00", 526 "cache-validity": 48, 527 "is-supported": true, 528 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 529 "mfg-name": "Example, Inc.", 530 "documentation": "https://iot-device.example.com/doc/modelX", 531 "model-name": "modelX" 532 } 533 } 535 5.3. Further contact required. 537 In this example, the network manager must take further steps to 538 retrieve SBOM information. Vulnerability information is still 539 available. 541 { 542 "ietf-mud:mud": { 543 "mud-version": 1, 544 "extensions": [ 545 "transparency" 546 ], 547 "ietf-mud-transparency:transparency": { 548 "contact-info": "https://iot-device.example.com/contact-info.html", 549 "vuln-url": "https://iot-device.example.com/info/modelX/csaf.json" 550 }, 551 "mud-url": "https://iot-device.example.com/modelX.json", 552 "mud-signature": "https://iot-device.example.com/modelX.p7s", 553 "last-update": "2021-07-09T06:16:42+00:00", 554 "cache-validity": 48, 555 "is-supported": true, 556 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 557 "mfg-name": "Example, Inc.", 558 "documentation": "https://iot-device.example.com/doc/modelX", 559 "model-name": "modelX" 560 } 561 } 563 5.4. With ACLS 565 Finally, here is a complete example where the device provides SBOM 566 and vulnerability information, as well as access-control information. 568 { 569 "ietf-mud:mud": { 570 "mud-version": 1, 571 "extensions": [ 572 "ol", 573 "transparency" 574 ], 575 "ol": { 576 "owners": [ 577 "Copyright (c) Example, Inc. 2022. All Rights Reserved" 578 ], 579 "spdx-tag": "0BSD" 580 }, 581 "mudtx:transparency": { 582 "sbom-local-well-known": "https", 583 "vuln-url": "https://iot.example.com/info/modelX/csaf.json" 584 }, 585 "mud-url": "https://iot.example.com/modelX.json", 586 "mud-signature": "https://iot.example.com/modelX.p7s", 587 "last-update": "2022-01-05T13:30:31+00:00", 588 "cache-validity": 48, 589 "is-supported": true, 590 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 591 "mfg-name": "Example, Inc.", 592 "documentation": "https://iot.example.com/doc/modelX", 593 "model-name": "modelX", 594 "from-device-policy": { 595 "access-lists": { 596 "access-list": [ 597 { 598 "name": "mud-65443-v4fr" 599 } 600 ] 601 } 602 }, 603 "to-device-policy": { 604 "access-lists": { 605 "access-list": [ 606 { 607 "name": "mud-65443-v4to" 608 } 609 ] 610 } 611 } 612 }, 613 "ietf-access-control-list:acls": { 614 "acl": [ 615 { 616 "name": "mud-65443-v4to", 617 "type": "ipv4-acl-type", 618 "aces": { 619 "ace": [ 620 { 621 "name": "cl0-todev", 622 "matches": { 623 "ipv4": { 624 "ietf-acldns:src-dnsname": "iotserver.example.com" 625 } 626 }, 627 "actions": { 628 "forwarding": "accept" 629 } 630 } 631 ] 632 } 633 }, 634 { 635 "name": "mud-65443-v4fr", 636 "type": "ipv4-acl-type", 637 "aces": { 638 "ace": [ 639 { 640 "name": "cl0-frdev", 641 "matches": { 642 "ipv4": { 643 "ietf-acldns:dst-dnsname": "iotserver.example.com" 644 } 645 }, 646 "actions": { 647 "forwarding": "accept" 648 } 649 } 650 ] 651 } 652 } 653 ] 654 } 655 } 657 At this point, the management system can attempt to retrieve the 658 SBOM, and determine which format is in use through the content-type 659 header on the response to a GET request, independently repeat the 660 process for vulnerability information, and apply ACLs, as 661 appropriate. 663 6. Security Considerations 665 The YANG module specified in this document defines a schema for data 666 that is designed to be accessed via network management protocols such 667 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 668 is the secure transport layer, and the mandatory-to-implement secure 669 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 670 is HTTPS, and the mandatory-to-implement secure transport is TLS 671 [RFC8446]. 673 N.B., for MUD, the mandatory method of retrieval is TLS. 675 The Network Configuration Access Control Model (NACM) [RFC8341] 676 provides the means to restrict access for particular NETCONF or 677 RESTCONF users to a preconfigured subset of all available NETCONF or 678 RESTCONF protocol operations and content. 680 There are a number of data nodes defined in this YANG module that are 681 writable/creatable/deletable (i.e., config true, which is the 682 default). These data nodes may be considered sensitive or vulnerable 683 in some network environments. Write operations (e.g., edit-config) 684 to these data nodes without proper protection can have a negative 685 effect on network operations. These are the subtrees and data nodes 686 and their sensitivity/vulnerability: 688 The ietf-mud-transparency module has no operational impact on the 689 element itself, and is used to discover state information that may be 690 available on or off the element. In as much as the module itself is 691 made writeable, this only indicates a change in how to retrieve what 692 read-only elements. However, that does not mean there are no risks. 693 These are discussed below, and are applicable to all nodes within the 694 transparency container. 696 If an attacker modifies the elements, they may misdirect automation 697 to retrieve a different set of URLs than was intended by the 698 designer. This in turn leads to two specific sets of risks: 700 * the information retrieved would be false. 702 * the URLs themselves point to malware. 704 To address either risk, any change in a URL, and in particular to the 705 authority section, should be treated with some suspicion. One 706 mitigation would be to test any cloud-based URL against a reputation 707 service. 709 Some of the readable data nodes in this YANG module may be considered 710 sensitive or vulnerable in some network environments. It is thus 711 important to control read access (e.g., via get, get-config, or 712 notification) to these data nodes. These are the subtrees and data 713 nodes and their sensitivity/vulnerability: 715 SBOMs provide an inventory of software. If software is available to 716 an attacker, the attacker may well already be able to derive this 717 very same software inventory. Manufacturers MAY restrict access to 718 SBOM information using appropriate authorization semantics within 719 HTTP. In particular, if a system attempts to retrieve an SBOM via 720 HTTP and the client is not authorized, the server MUST produce an 721 appropriate error, with instructions on how to register a particular 722 client. One example may be to issue a certificate to the client for 723 this purpose after a registration process has taken place. Another 724 example would involve the use of OAUTH in combination with a 725 federations of SBOM servers. 727 Another risk is a skew in the SBOM listing and the actual software 728 inventory of a device/container. For example, a manufacturer may 729 update the SBOM on its server, but an individual device has not been 730 upgraded yet. This may result in an incorrect policy being applied 731 to a device. A unique mapping of a device's software version and its 732 SBOM can minimize this risk. 734 To further mitigate attacks against a device, manufacturers SHOULD 735 recommend access controls. 737 Vulnerability information is generally made available to such 738 databases as NIST's National Vulnerability Database. It is possible 739 that vendor may wish to release information early to some customers. 740 We do not discuss here whether that is a good idea, but if it is 741 employed, then appropriate access controls and authorization SHOULD 742 be applied to the vulnerability resource. 744 7. IANA Considerations 746 7.1. MUD Extension 748 The IANA is requested to add "transparency" to the MUD extensions 749 registry as follows: 751 Extension Name: transparency 752 Standard reference: This document 754 7.2. YANG Registration 756 The following YANG module should be registered in the "YANG Module 757 Names" registry: 759 Name: ietf-mud 760 URN: urn:ietf:params:xml:ns:yang:ietf-mud-transparency 761 Prefix: mudtx 762 Registrant contact: The IESG 763 Reference: This memo 765 7.3. Well-Known Prefix 767 The following well known URIs are requested in accordance with 768 [RFC8615]: 770 URI suffix: "sbom" 771 Change controller: "IETF" 772 Specification document: This memo 773 Related information: See ISO/IEC 19970-2 and SPDX.org 775 URI suffix: "openc2" 776 Change controller: "IETF" 777 Specification document: This memo 778 Related information: OpenC2 Project 780 8. Acknowledgments 782 Thanks to Russ Housley, Dick Brooks, Tom Petch, Nicolas Comstedt, who 783 provided revew comments. 785 9. References 787 9.1. Normative References 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, 791 DOI 10.17487/RFC2119, March 1997, 792 . 794 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 795 and A. Bierman, Ed., "Network Configuration Protocol 796 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 797 . 799 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 800 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 801 . 803 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 804 RFC 6991, DOI 10.17487/RFC6991, July 2013, 805 . 807 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 808 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 809 . 811 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 812 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 813 May 2017, . 815 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 816 Access Control Model", STD 91, RFC 8341, 817 DOI 10.17487/RFC8341, March 2018, 818 . 820 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 821 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 822 . 824 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 825 Description Specification", RFC 8520, 826 DOI 10.17487/RFC8520, March 2019, 827 . 829 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 830 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 831 . 833 9.2. Informative References 835 [CSAF] OASIS, "Common Security Advisory Format", July 2021, 836 . 838 [CVRF] Santos, O., Ed., "Common Vulnerability Reporting Framework 839 (CVRF) Version 1.2", September 2017, . 842 [CycloneDX12] 843 cylonedx.org, "CycloneDX XML Reference v1.2", May 2020. 845 [EO2021] Biden, J., "Executive Order 14028, Improving the Nations 846 Cybersecurity", May 2021. 848 [OpenC2] Lemire, D., Ed., "Specification for Transfer of OpenC2 849 Messages via HTTPS Version 1.0", July 2019, 850 . 853 [SPDX] The Linux Foundation, "SPDX Specification 2.1", 2016. 855 Appendix A. Changes from Earlier Versions 857 Draft -04: * Address review comments 859 Draft -02: 861 * include vulnerability information 862 Draft -01: 864 * some modest changes 866 Draft -00: 868 * Initial revision 870 Authors' Addresses 872 Eliot Lear 873 Cisco Systems 874 Richtistrasse 7 875 CH-8304 Wallisellen 876 Switzerland 877 Phone: +41 44 878 9200 878 Email: lear@cisco.com 880 Scott Rose 881 NIST 882 100 Bureau Dr 883 Gaithersburg MD, 20899 884 United States of America 885 Phone: +1 301-975-8439 886 Email: scott.rose@nist.gov