idnits 2.17.1 draft-lear-opsawg-mud-sbom-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 (May 18, 2020) is 1436 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: November 19, 2020 NIST 6 May 18, 2020 8 SBOM Extension for MUD 9 draft-lear-opsawg-mud-sbom-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 means for manufacturers to state how SBOMs may be retrieved through 16 an extension to manufacturer usage descriptions (MUD). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 19, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. How This Information Is Used . . . . . . . . . . . . . . 3 54 1.2. SBOM formats . . . . . . . . . . . . . . . . . . . . . . 3 55 1.3. Discussion points . . . . . . . . . . . . . . . . . . . . 3 56 2. The mud-sbom extension model extension . . . . . . . . . . . 4 57 3. The mud-sbom augmentation to the MUD YANG model . . . . . . . 4 58 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. Without ACLS . . . . . . . . . . . . . . . . . . . . . . 7 60 4.2. Located on the Device . . . . . . . . . . . . . . . . . . 8 61 4.3. SBOM Obtained from Contact Information . . . . . . . . . 9 62 4.4. With ACLS . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 6.1. MUD Extension . . . . . . . . . . . . . . . . . . . . . . 12 66 6.2. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 12 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 7.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 Manufacturer Usage Descriptions (MUD) [RFC8520] provides a means for 76 devices to identify what they are and what sort of network access 77 they need. This memo specifies a YANG model [RFC6991] for reporting 78 and a means for transmitting the report, and appropriate extensions 79 to the MUD file to indicate how to report and how often. 81 Software bills of material (SBOMs) are descriptions of what software, 82 including versionioning and dependencies, a device contains. There 83 are different SBOM formats such as Software Package Data Exchange 84 [SPDX] and Software Identity Tags [SWID]. 86 This memo extends the MUD YANG schema to provide location information 87 of an SBOM. 89 These SBOMs are typically found in one of three ways: 91 o on devices themselves 93 o on a web site (e.g., via URI) 95 o through direct contact with the manufacturer. 97 Some devices will have interfaces that permit direct SBOM retrieval. 98 Examples of these interfaces might be 'ssh' or an HTTP endpoint for 99 retrieval. There may also be private interfaces as well. 101 When a web site is used, versioning information about the SBOM is 102 implicit based on the MUD file. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 1.1. How This Information Is Used 112 SBOMs are used for numerous purposes, including vulnerability 113 assessment, license management, and inventory management. This memo 114 provides means for either automated or semi-automated collection of 115 that information. For devices that can output a MUD URL, the 116 mechanism may be highly automated. For devices that have a MUD URL 117 in either their documentation or within a QR code on a box, the 118 mechanism is semi-automated (someone has to scan the QR code or enter 119 the URL). 121 Note that SBOMs may change more frequently than access control 122 requirements. A change to software does not necessarily mean a 123 change to control channels that are used. Therefore, it is important 124 to retrieve the MUD file as suggested by the manufacturer in the 125 cache-validity period. In many cases, only the SBOM list will have 126 been updated. 128 1.2. SBOM formats 130 There are multiple ways to express an SBOM. When these are retrieved 131 either directly from the device or directly from a web server, tools 132 will need to observe the content-type header to determine precisely 133 which format is being transmitted. Because IoT devices in particular 134 have limited capabilities, use of a specific Accept: header in HTTP 135 or the Accept Option in CoAP is NOT RECOMMENDED. Instead, backend 136 tooling MUST silently discard SBOM information sent with a media type 137 that is not understood. 139 1.3. Discussion points 141 The following is discussion to be removed at time of RFC publication. 143 o Is the model structured correctly? 144 o Are there other retrieval mechanisms that need to be specified? 146 o Do we need to be more specific in how to authenticate and retrieve 147 SBOMs? 149 o What are the implications if the MUD URL is an extension in a 150 certificate (e.g. an IDevID cert)? 152 2. The mud-sbom extension model extension 154 We now formally define this extension. This is done in two parts. 155 First, the extension name "sbom" is listed in the "extensions" array 156 of the MUD file. 158 Second, the "mud" container is augmented with a list of SBOM sources. 160 This is done as follows: 162 module: ietf-mud-sbom 163 augment /mud:mud: 164 +--rw sboms* [version-info] 165 +--rw version-info string 166 +--rw (sbom-type)? 167 +--:(url) 168 | +--rw sbom-url? inet:uri 169 +--:(local-uri) 170 | +--rw sbom-local* enumeration 171 +--:(contact-info) 172 +--rw contact-uri? inet:uri 174 3. The mud-sbom augmentation to the MUD YANG model 176 file "ietf-mud-sbom@2020-03-06.yang" 177 module ietf-mud-sbom { 178 yang-version 1.1; 179 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-sbom"; 180 prefix mud-sbom; 182 import ietf-inet-types { 183 prefix inet; 184 } 185 import ietf-mud { 186 prefix mud; 187 } 189 organization 190 "IETF OPSAWG (Ops Area) Working Group"; 191 contact 192 "WG 193 Web: http://tools.ietf.org/wg/opsawg/ 194 WG List: opsawg@ietf.org 195 Author: Eliot Lear lear@cisco.com "; 196 description 197 "This YANG module augments the ietf-mud model to provide for 198 reporting of SBOMs. 200 Copyright (c) 2019 IETF Trust and the persons identified as 201 authors of the code. All rights reserved. 203 Redistribution and use in source and binary forms, with or 204 without modification, is permitted pursuant to, and subject to 205 the license terms contained in, the Simplified BSD License set 206 forth in Section 4.c of the IETF Trust's Legal Provisions 207 Relating to IETF Documents 208 (https://trustee.ietf.org/license-info). 210 This version of this YANG module is part of RFC XXXX 211 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for 212 full legal notices. 214 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 215 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 216 'MAY', and 'OPTIONAL' in this document are to be interpreted as 217 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 218 they appear in all capitals, as shown here. "; 220 revision 2020-03-06 { 221 description 222 "Initial proposed standard."; 223 reference 224 "RFC XXXX: Extension for MUD Reporting"; 225 } 227 grouping mud-sbom-extension { 228 description 229 "SBOM extension grouping"; 230 list sboms { 231 key "version-info"; 232 leaf version-info { 233 type string; 234 description 235 "A version string that is applicable for this SBOM list entry. 236 The format of this string is left to the device manufacturer. 237 How the network administrator determines the version of 238 software running on the device is beyond the scope of this 239 memo."; 241 } 242 choice sbom-type { 243 case url { 244 leaf sbom-url { 245 type inet:uri; 246 description 247 "A statically located URI."; 248 } 249 } 250 case local-uri { 251 leaf-list sbom-local { 252 type enumeration { 253 enum coap { 254 description 255 "Use COAP schema to retrieve SBOM"; 256 } 257 enum coaps { 258 description 259 "Use COAPS schema to retrieve SBOM"; 260 } 261 enum http { 262 description 263 "Use HTTP schema to retrieve SBOM"; 264 } 265 enum https { 266 description 267 "Use HTTPS schema to retrieve SBOM"; 268 } 269 } 270 description 271 "The choice of sbom-local means that the SBOM resides at 272 a location indicated by an indicted scheme for the 273 device in question, at well known location 274 '/.well-known/sbom'. For example, if the MUD file 275 indicates that coaps is to be used and the host is 276 located at address 10.1.2.3, the SBOM could be retrieved 277 at 'coaps://10.1.2.3/.well-known/sbom'. N.B., coap and 278 http schemes are NOT RECOMMENDED."; 279 } 280 } 281 case contact-info { 282 leaf contact-uri { 283 type inet:uri; 284 description 285 "This MUST be either a tel, http, https, or 286 mailto uri schema that customers can use to 287 contact someone for SBOM information."; 288 } 290 } 291 description 292 "choices for SBOM retrieval."; 293 } 294 description 295 "list of methods to get an SBOM."; 296 } 297 } 299 augment "/mud:mud" { 300 description 301 "Add extension for SBOMs."; 302 uses mud-sbom-extension; 303 } 304 } 306 308 4. Examples 310 In this example MUD file that uses a cloud service, the Frobinator 311 presents a location of the SBOM in a URL. Note, the ACLs in a MUD 312 file are NOT required, although they are a very good idea for IP- 313 based devices. The first MUD file demonstrates how to get the SBOM 314 without ACLs, and the second has ACLs. 316 4.1. Without ACLS 317 { 318 "ietf-mud:mud": { 319 "mud-version": 1, 320 "mud-url": "https://iot-device.example.com/dnsname", 321 "last-update": "2019-01-15T10:22:47+00:00", 322 "cache-validity": 48, 323 "is-supported": true, 324 "systeminfo": "device that wants to talk to a cloud service", 325 "mfg-name": "Example, Inc.", 326 "documentation": "https://frobinator.example.com/doc/frob2000", 327 "model-name": "Frobinator 2000", 328 "extensions" : [ 329 "sbom" 330 ], 331 "sboms" : [ 332 { 333 "version-info" : "FrobOS Release 1.1", 334 "sbom-url" : "https://frobinator.example.com/sboms/f20001.1", 335 } 336 ] 337 } 338 } 340 4.2. Located on the Device 342 { 343 "ietf-mud:mud": { 344 "mud-version": 1, 345 "mud-url": "https://iot-device.example.com/dnsname", 346 "last-update": "2019-01-15T10:22:47+00:00", 347 "cache-validity": 48, 348 "is-supported": true, 349 "systeminfo": "device that wants to talk to a cloud service", 350 "mfg-name": "Example, Inc.", 351 "documentation": "https://frobinator.example.com/doc/frob2000", 352 "model-name": "Frobinator 2000", 353 "extensions" : [ 354 "sbom" 355 ], 356 "sboms" : [ 357 { 358 "version-info" : "FrobOS Release 1.1", 359 "sbom-local" : "coaps:///.well-known/sbom", 360 } 361 ] 362 } 363 } 365 4.3. SBOM Obtained from Contact Information 367 { 368 "ietf-mud:mud": { 369 "mud-version": 1, 370 "mud-url": "https://iot-device.example.com/dnsname", 371 "last-update": "2019-01-15T10:22:47+00:00", 372 "cache-validity": 48, 373 "is-supported": true, 374 "systeminfo": "device that wants to talk to a cloud service", 375 "mfg-name": "Example, Inc.", 376 "documentation": "https://frobinator.example.com/doc/frob2000", 377 "model-name": "Frobinator 2000", 378 "extensions" : [ 379 "sbom" 380 ], 381 "sboms" : [ 382 { 383 "version-info" : "FrobOS Release 1.1", 384 "contact-uri" : "mailto:sbom-requst@example.com", 385 } 386 ] 387 } 388 } 390 4.4. With ACLS 392 { 393 "ietf-mud:mud": { 394 "mud-version": 1, 395 "mud-url": "https://iot-device.example.com/dnsname", 396 "last-update": "2019-01-15T10:22:47+00:00", 397 "cache-validity": 48, 398 "is-supported": true, 399 "systeminfo": "device that wants to talk to a cloud service", 400 "mfg-name": "Example, Inc.", 401 "documentation": "https://frobinator.example.com/doc/frob2000", 402 "model-name": "Frobinator 2000", 403 "extensions" : [ 404 "sbom" 405 ], 406 "sboms" : [ 407 { 408 "version-info" : "FrobOS Release 1.1", 409 "sbom-url" : "https://frobinator.example.com/sboms/f20001.1", 410 } 411 ], 412 "from-device-policy": { 413 "access-lists": { 414 "access-list": [ 415 { 416 "name": "mud-96898-v4fr" 417 }, 418 { 419 "name": "mud-96898-v6fr" 420 } 421 ] 422 } 423 }, 424 "to-device-policy": { 425 "access-lists": { 426 "access-list": [ 427 { 428 "name": "mud-96898-v4to" 429 }, 430 { 431 "name": "mud-96898-v6to" 432 } 433 ] 434 } 435 } 436 }, 437 "ietf-access-control-list:acls": { 438 "acl": [ 439 { 440 "name": "mud-96898-v4to", 441 "type": "ipv4-acl-type", 442 "aces": { 443 "ace": [ 444 { 445 "name": "cl0-todev", 446 "matches": { 447 "ipv4": { 448 "ietf-acldns:src-dnsname": "cloud-service.example.com" 449 } 450 }, 451 "actions": { 452 "forwarding": "accept" 453 } 454 } 455 ] 456 } 457 }, 458 { 459 "name": "mud-96898-v4fr", 460 "type": "ipv4-acl-type", 461 "aces": { 462 "ace": [ 463 { 464 "name": "cl0-frdev", 465 "matches": { 466 "ipv4": { 467 "ietf-acldns:dst-dnsname": "cloud-service.example.com" 468 } 469 }, 470 "actions": { 471 "forwarding": "accept" 472 } 473 } 474 ] 475 } 476 }, 477 { 478 "name": "mud-96898-v6to", 479 "type": "ipv6-acl-type", 480 "aces": { 481 "ace": [ 482 { 483 "name": "cl0-todev", 484 "matches": { 485 "ipv6": { 486 "ietf-acldns:src-dnsname": "cloud-service.example.com" 487 } 488 }, 489 "actions": { 490 "forwarding": "accept" 491 } 492 } 493 ] 494 } 495 }, 496 { 497 "name": "mud-96898-v6fr", 498 "type": "ipv6-acl-type", 499 "aces": { 500 "ace": [ 501 { 502 "name": "cl0-frdev", 503 "matches": { 504 "ipv6": { 505 "ietf-acldns:dst-dnsname": "cloud-service.example.com" 506 } 507 }, 508 "actions": { 509 "forwarding": "accept" 510 } 511 } 512 ] 513 } 514 } 515 ] 516 } 517 } 519 At this point, the management system can attempt to retrieve the 520 SBOM, and determine which format is in use through the content-type 521 header on the response to a GET request. 523 5. Security Considerations 525 SBOMs provide an inventory of software. If firmware is available to 526 an attacker, the attacker may well already be able to derive this 527 very same software inventory. Manufacturers MAY restrict access to 528 SBOM information using appropriate authorization semantics within 529 HTTP. In particular, if a system attempts to retrieve an SBOM via 530 HTTP, if the client is not authorized, the server MUST produce an 531 appropriate error, with instructions on how to register a particular 532 client. One example may be to issue a certificate to the client for 533 this purpose after a registration process has taken place. Another 534 example would involve the use of OAUTH in combination with a 535 federations of SBOM servers. 537 To further mitigate attacks against a device, manufacturers SHOULD 538 recommend access controls through the normal MUD mechanism. 540 6. IANA Considerations 542 6.1. MUD Extension 544 The IANA is requested to add "controller-candidate" to the MUD 545 extensions registry as follows: 547 Extension Name: sbom 548 Standard reference: This document 550 6.2. Well-Known Prefix 552 The following well known URI is requested in accordance with 553 [RFC8615]: 555 URI suffix: "sbom" 556 Change controller: "IETF" 557 Specification document: This memo 558 Related information: See ISO/IEC 19970-2 and SPDX.org 560 7. References 562 7.1. Normative References 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, 566 DOI 10.17487/RFC2119, March 1997, 567 . 569 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 570 RFC 6991, DOI 10.17487/RFC6991, July 2013, 571 . 573 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 574 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 575 May 2017, . 577 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 578 Description Specification", RFC 8520, 579 DOI 10.17487/RFC8520, March 2019, 580 . 582 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 583 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 584 . 586 7.2. Informative References 588 [SPDX] The Linux Foundation, "SPDX Specification 2.1", 2016. 590 [SWID] ISO/IEC, "Information technology -- IT asset management -- 591 Part 2: Software identification tag", ISO 19770-2:2015, 592 2015. 594 Appendix A. Changes from Earlier Versions 596 Draft -00: 598 o Initial revision 600 Authors' Addresses 602 Eliot Lear 603 Cisco Systems 604 Richtistrasse 7 605 Wallisellen CH-8304 606 Switzerland 608 Phone: +41 44 878 9200 609 Email: lear@cisco.com 611 Scott Rose 612 NIST 613 100 Bureau Dr 614 Gaithersburg MD 20899 615 USA 617 Phone: +1 301-975-8439 618 Email: scott.rose@nist.gov