| < draft-moran-suit-mud-02.txt | draft-ietf-suit-mud-00.txt > | |||
|---|---|---|---|---|
| SUIT B. Moran | SUIT B. Moran | |||
| Internet-Draft H. Tschofenig | Internet-Draft H. Tschofenig | |||
| Intended status: Standards Track Arm Limited | Intended status: Standards Track Arm Limited | |||
| Expires: November 26, 2021 May 25, 2021 | Expires: 24 September 2022 23 March 2022 | |||
| Strong Assertions of IoT Network Access Requirements | Strong Assertions of IoT Network Access Requirements | |||
| draft-moran-suit-mud-02 | draft-ietf-suit-mud-00 | |||
| Abstract | Abstract | |||
| The Manufacturer Usage Description (MUD) specification describes the | The Manufacturer Usage Description (MUD) specification describes the | |||
| access and network functionality required a device to properly | access and network functionality required a device to properly | |||
| function. The MUD description has to reflect the software running on | function. The MUD description has to reflect the software running on | |||
| the device and its configuration. Because of this, the most | the device and its configuration. Because of this, the most | |||
| appropriate entity for describing device network access requirements | appropriate entity for describing device network access requirements | |||
| is the same as the entity developing the software and its | is the same as the entity developing the software and its | |||
| configuration. | configuration. | |||
| skipping to change at page 1, line 43 ¶ | skipping to change at page 1, line 43 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on November 26, 2021. | This Internet-Draft will expire on 24 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
| publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
| carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
| to this document. Code Components extracted from this document must | extracted from this document must include Revised BSD License text as | |||
| include Simplified BSD License text as described in Section 4.e of | described in Section 4.e of the Trust Legal Provisions and are | |||
| the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Revised BSD License. | |||
| described in the Simplified BSD License. | ||||
| This document may contain material from IETF Documents or IETF | This document may contain material from IETF Documents or IETF | |||
| Contributions published or made publicly available before November | Contributions published or made publicly available before November | |||
| 10, 2008. The person(s) controlling the copyright in some of this | 10, 2008. The person(s) controlling the copyright in some of this | |||
| material may not have granted the IETF Trust the right to allow | material may not have granted the IETF Trust the right to allow | |||
| modifications of such material outside the IETF Standards Process. | modifications of such material outside the IETF Standards Process. | |||
| Without obtaining an adequate license from the person(s) controlling | Without obtaining an adequate license from the person(s) controlling | |||
| the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
| outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
| not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
| skipping to change at page 2, line 44 ¶ | skipping to change at page 2, line 43 ¶ | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 | 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 1. Introduction | 1. Introduction | |||
| Under [RFC8520], devices report a URL to a MUD manager in the | Under [RFC8520], devices report a URL to a MUD manager in the | |||
| network. RFC 8520 envisions different approaches for conveying the | network. RFC 8520 envisions different approaches for conveying the | |||
| information from the device to the network such as: | information from the device to the network such as: | |||
| - DHCP, | * DHCP, | |||
| - IEEE802.1AB Link Layer Discovery Protocol (LLDP), and | * IEEE802.1AB Link Layer Discovery Protocol (LLDP), and | |||
| - IEEE 802.1X whereby the URL to the MUD file would be contained in | * IEEE 802.1X whereby the URL to the MUD file would be contained in | |||
| the certificate used in an EAP method. | the certificate used in an EAP method. | |||
| The MUD manager then uses the the URL to fetch the MUD file, which | The MUD manager then uses the the URL to fetch the MUD file, which | |||
| contains access and network functionality required a device to | contains access and network functionality required a device to | |||
| properly function. | properly function. | |||
| The MUD manager must trust the service from which the URL is fetched | The MUD manager must trust the service from which the URL is fetched | |||
| and to return an authentic copy of the MUD file. This concern may be | and to return an authentic copy of the MUD file. This concern may be | |||
| mitigated using the optional signature reference in the MUD file. | mitigated using the optional signature reference in the MUD file. | |||
| The MUD manager must also trust the device to report a correct URL. | The MUD manager must also trust the device to report a correct URL. | |||
| skipping to change at page 3, line 43 ¶ | skipping to change at page 3, line 39 ¶ | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 3. Architecture | 3. Architecture | |||
| The intended workflow is as follows: | The intended workflow is as follows: | |||
| - At the time of onboarding, devices report their manifest in use to | * At the time of onboarding, devices report their manifest in use to | |||
| the MUD manager. | the MUD manager. | |||
| - If the SUIT_MUD_container has been severed, the suit-reference-uri | * If the SUIT_MUD_container has been severed, the suit-reference-uri | |||
| can be used to retrieve the complete manifest. | can be used to retrieve the complete manifest. | |||
| - The manifest authenticity is verified by the MUD manager, which | * The manifest authenticity is verified by the MUD manager, which | |||
| enforces that the MUD file presented is also authentic and as | enforces that the MUD file presented is also authentic and as | |||
| intended by the device software vendor. | intended by the device software vendor. | |||
| - Each time a device is updated, rebooted, or otherwise | * Each time a device is updated, rebooted, or otherwise | |||
| substantially changed, it will execute an attestation. | substantially changed, it will execute an attestation. | |||
| o Among other claims in the Entity Attestation Token (EAT) | - Among other claims in the Entity Attestation Token (EAT) | |||
| [I-D.ietf-rats-eat], the device will report its software | [I-D.ietf-rats-eat], the device will report its software | |||
| digest(s), configuration digest(s), primary manifest URI, and | digest(s), configuration digest(s), primary manifest URI, and | |||
| primary manifest digest to the MUD manager. | primary manifest digest to the MUD manager. | |||
| o The MUD manager can then validate these attestation reports in | - The MUD manager can then validate these attestation reports in | |||
| order to check that the device is operating with the expected | order to check that the device is operating with the expected | |||
| version of software and configuration. | version of software and configuration. | |||
| o Since the manifest digest is reported, the MUD manager can look | - Since the manifest digest is reported, the MUD manager can look | |||
| up the corresponding manifest. | up the corresponding manifest. | |||
| - If the MUD manager does not already have a full copy of the | * If the MUD manager does not already have a full copy of the | |||
| manifest, it can be acquired using the reference URI. | manifest, it can be acquired using the reference URI. | |||
| - Once a full copy of the manifest is provided, the MUD manager can | * Once a full copy of the manifest is provided, the MUD manager can | |||
| verify the device attestation report and apply any appropriate | verify the device attestation report and apply any appropriate | |||
| policy as described by the MUD file. | policy as described by the MUD file. | |||
| 4. Extensions to SUIT | 4. Extensions to SUIT | |||
| To enable strong assertions about the network access requirements | To enable strong assertions about the network access requirements | |||
| that a device should have for a particular software/configuration | that a device should have for a particular software/configuration | |||
| pair, we include the ability to add MUD files to the SUIT manifest. | pair, we include the ability to add MUD files to the SUIT manifest. | |||
| However, there are also circumstances in which a device should allow | However, there are also circumstances in which a device should allow | |||
| the MUD to be changed without a firmware update. To enable this, we | the MUD to be changed without a firmware update. To enable this, we | |||
| skipping to change at page 5, line 26 ¶ | skipping to change at page 5, line 24 ¶ | |||
| device may stop functioning. | device may stop functioning. | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| suit-manifest-mud must be added as an extension point to the SUIT | suit-manifest-mud must be added as an extension point to the SUIT | |||
| manifest registry. | manifest registry. | |||
| 7. Normative References | 7. Normative References | |||
| [I-D.ietf-rats-eat] | [I-D.ietf-rats-eat] | |||
| Mandyam, G., Lundblade, L., Ballesteros, M., and J. | Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity | |||
| O'Donoghue, "The Entity Attestation Token (EAT)", draft- | Attestation Token (EAT)", Work in Progress, Internet- | |||
| ietf-rats-eat-09 (work in progress), March 2021. | Draft, draft-ietf-rats-eat-12, 24 February 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-rats-eat- | ||||
| 12.txt>. | ||||
| [I-D.ietf-suit-manifest] | [I-D.ietf-suit-manifest] | |||
| Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, | Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, | |||
| "A Concise Binary Object Representation (CBOR)-based | "A Concise Binary Object Representation (CBOR)-based | |||
| Serialization Format for the Software Updates for Internet | Serialization Format for the Software Updates for Internet | |||
| of Things (SUIT) Manifest", draft-ietf-suit-manifest-12 | of Things (SUIT) Manifest", Work in Progress, Internet- | |||
| (work in progress), February 2021. | Draft, draft-ietf-suit-manifest-16, 25 October 2021, | |||
| <https://www.ietf.org/archive/id/draft-ietf-suit-manifest- | ||||
| 16.txt>. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods | [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods | |||
| for Generating Key Identifiers Values", RFC 7093, | for Generating Key Identifiers Values", RFC 7093, | |||
| DOI 10.17487/RFC7093, December 2013, | DOI 10.17487/RFC7093, December 2013, | |||
| <https://www.rfc-editor.org/info/rfc7093>. | <https://www.rfc-editor.org/info/rfc7093>. | |||
| skipping to change at page 6, line 14 ¶ | skipping to change at page 6, line 14 ¶ | |||
| [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage | [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage | |||
| Description Specification", RFC 8520, | Description Specification", RFC 8520, | |||
| DOI 10.17487/RFC8520, March 2019, | DOI 10.17487/RFC8520, March 2019, | |||
| <https://www.rfc-editor.org/info/rfc8520>. | <https://www.rfc-editor.org/info/rfc8520>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Brendan Moran | Brendan Moran | |||
| Arm Limited | Arm Limited | |||
| Email: Brendan.Moran@arm.com | ||||
| EMail: Brendan.Moran@arm.com | ||||
| Hannes Tschofenig | Hannes Tschofenig | |||
| Arm Limited | Arm Limited | |||
| Email: hannes.tschofenig@arm.com | ||||
| EMail: hannes.tschofenig@arm.com | ||||
| End of changes. 21 change blocks. | ||||
| 31 lines changed or deleted | 33 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||