draft-ietf-suit-mud.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.31 (Ruby 3.2.2) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>

<?rfc rfcedstyle="yes"?>
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-suit-mud-09" category="std" consensus="true" updates="draft-ietf-suit-manifest" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="SUIT MUD Linkage">Strong Assertions of IoT Network Access Requirements</title>

    <author initials="B." surname="Moran" fullname="Brendan Moran">
      <organization>Arm Limited</organization>
      <address>
        <email>brendan.moran.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization></organization>
      <address>
        <email>hannes.tschofenig@gmx.net</email>
      </address>
    </author>

    <date year="2024" month="July" day="08"/>

    <area>Security</area>
    <workgroup>SUIT</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The Manufacturer Usage Description (MUD) specification describes the access and network functionality required for a device to properly function. This description has to reflect the software running on the device and its configuration. Because of this, the most appropriate entity for describing device network access requirements is the same as the entity developing the software and its configuration.</t>

<t>A network presented with a MUD file by a device allows detection of misbehavior by the device software and configuration of access control.</t>

<t>This document defines a way to link the Software Updates for Internet of Things (SUIT) manifest to a MUD file offering a stronger binding between the two.</t>



    </abstract>



  </front>

  <middle>


<section anchor="introduction"><name>Introduction</name>

<t>A Manufacturer Usage Description (MUD) file describes what sort of network communication behavior a device is designed to have. For example,
a manufacturer may use a MUD file to describe that a device uses HTTP, DNS and NTP communication but no other protocols. The communication patterns are
described in a JSON-based format in the MUD file.</t>

<t>The MUD files do, however, need to be presented by the device to a MUD manager in the operational network where the device is deployed.
Under <xref target="RFC8520"/>, devices report a MUD URL to a MUD manager in the operational network. The MUD URL is a URL that can be used by the MUD manager to receive the MUD file from a MUD file server to ultimately obtain the MUD file.</t>

<t><xref target="arch-mud-fig"/> shows the MUD architecture, as defined in RFC 8520.</t>

<figure title="MUD Architecture per RFC 8520." anchor="arch-mud-fig"><artwork><![CDATA[
    .......................................
    .                      ____________   .           _____________
    .                     |            |  .          |             |
    .                     |    MUD     |-->get URL-->|    MUD      |
    .                     |  Manager   |  .(https)   | File Server |
    .  End system network |____________|<-MUD file<-<|_____________|
    .                             .       .
    .                             .       .
    . ________                _________   .
    .|        |              | router  |  .
    .| Device |--->MUD URL-->|   or    |  .
    .|________|              | switch  |  .
    .                        |_________|  .
    .......................................
]]></artwork></figure>

<t>RFC 8520 envisions different approaches for conveying the MUD URL from the device to the operational network. Section 4 of <xref target="I-D.ietf-opsawg-mud-acceptable-urls"/> provides additional description of the MUD URLs sources, which include:</t>

<t><list style="symbols">
  <t>DHCP,</t>
  <t>IEEE 802.1AB Link Layer Discovery Protocol (LLDP), and</t>
  <t>IEEE 802.1X whereby the URL to the MUD file would be contained in the certificate used in an EAP method.</t>
</list></t>

<t>The MUD manager must trust the MUD file server from which the MUD file is fetched to return the most up-to-date MUD file.
It must also trust the device to report the correct MUD URL. In case of DHCP and LLDP the URL is unprotected and not bound
to the device itself.</t>

<t>When the MUD URL is included in a certificate then it is authenticated and integrity protected. However, the certificate only proves possession of a private key and endorsements by the certificate issuer. This does not prove what software is in use, nor does it prove that the MUD file is the correct file for the deployed software: instead, the responsibility falls on the certificate issuer to identify the MUD URL correctly and to supply a MUD Signer correctly.
There is a need to bind the entity that creates the software and configuration to the MUD file. The developer is in the best position to describe
the communication requirements of the software it developed and configured for a device.</t>

<t>This specification defines an extension to the Software Updates for Internet of Things (SUIT) manifest <xref target="I-D.ietf-suit-manifest"/>
to include a MUD URL. A SUIT manifest is
   a bundle of metadata about code/data for an IoT device, where to find the code/data, the
   devices to which it applies, and cryptographic information protecting
   the manifest.</t>

<t>When combining a MUD URL with a manifest used for software/firmware updates then a network operator can gain
more confidence in the description of the communication requirements for a device to properly function.</t>

</section>
<section anchor="terminology"><name>Terminology</name>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>

<t>This document re-uses the terms defined in <xref target="RFC9334"/> related to
remote attestation.  Readers of this document are assumed to be
familiar with the following terms: Evidence, Claim, Attester, Verifier,
and Relying Party (RP).</t>

<t>This document also uses terms defined in <xref target="RFC8520"/>, such as MUD,
MUD file, MUD manager, MUD URL, etc.</t>

</section>
<section anchor="workflow"><name>Workflow</name>

<t><xref target="arch-mud-new-fig"/> shows the architectural extensions introduced by combining
SUIT and MUD. The key elements are that the developer, who produces the
firmware is also generating a manifest and the MUD file. Information
about the MUD file is embedded into the SUIT manifest and provided to the
device via firmware update mechanism. Once this information is available
on the device it can be presented during device onboarding, during
network access authentication, or as part of other interactions that
involve the conveyance of Evidence to the operational network. After
retrieving the manifest, the MUD file can be obtained as well.</t>

<figure title="SUIT-MUD Architecture." anchor="arch-mud-new-fig"><artwork><![CDATA[
                        ____________
                       |            |
                       |  Manifest  |
                       | Repository |
                       |____________|
                  get URL ^      | SUIT manifest
 .........................|......|..........
 .                      __|______v__       .       _____________
 .                     |            |      .      |             |
 .                     |    MUD     |-->get URL-->|    MUD      |
 .                     |  Manager   |  .(https)   | File Server |
 .  End system network |____________|<-MUD file<-<|             |
 .                             ^       +Signature |_____________|
 .                             .           .
 .                             .           .
 .                             .           .
 . ________                _____________   .
 .|        | Attestation  | NAS, AAA or |  .
 .| Device |-->Evidence-->| Onboarding  |  .
 .|________| (+ Manifest  | Server      |  .
 .     ^      Claim)      |_____________|  .
 ......*....................................
       *                                         //-\\
       *                                          \-/
       *                        SUIT Manifest      |
       +************************(+ MUD URL)    ----*-----
                                Firmware          / \
                                                  /  \
                                               Developer
]]></artwork></figure>

<t>The intended workflow is as follows, and assumes an attestation mechanism between the device and the MUD Manager:</t>

<t><list style="symbols">
  <t>At the time of onboarding, devices report their manifest in use to the MUD Manager via some form of attestation Evidence and a conveyance protocol. The device thereby acts as an Attester. The normative specification of these mechanisms is out of scope for this document.</t>
  <t>An example of an Evidence format is the Entity Attestation Token (EAT) <xref target="I-D.ietf-rats-eat"/>, which offers a rich set of claims. This specification assumes that Evidence includes a link to the SUIT manifest via the "manifests" claim (see Section 4.2.15 of <xref target="I-D.ietf-rats-eat"/>) or that the manifest itself is embedded in the Evidence. This Evidence is conveyed to the operational network via some protocol, such as network access authentication protocol (for example using the EAP-TLS 1.3 method <xref target="RFC9190"/> utilizing the attestation extensions <xref target="I-D.fossati-tls-attestation"/>) or an onboarding protocol like FIDO Device Onboard (FDO) <xref target="FDO"/> or Bootstrapping Remote Secure Key Infrastructure (BRSKI) <xref target="RFC8995"/>.</t>
  <t>The MUD Manager, acting as a Relying Party, relays the Evidence to the Verifier and receives an Attestation Result in response. This allows the MUD Manager to check that the device is operating with the expected version of software and configuration.</t>
  <t>Since a URL to the manifest is contained in the Evidence, the MUD Manager can look up the corresponding manifest.</t>
  <t>The MUD Manager acquires the MUD file from the MUD URL found in the SUIT manifest. The SUIT manifest contains the MUD URL and not the MUD file primarily to due the size of the MUD file. This also allows the MUD file to be updated rapidly in response to evolving threats.</t>
  <t>The MUD Manager verifies the MUD file signature using the Subject Key Identifier (SKI) provided in the SUIT manifest.</t>
  <t>Then, the MUD Manager can apply any appropriate policy as described by the MUD file.</t>
</list></t>

<t>Each time a device is updated, rebooted, or otherwise substantially changed, it will execute the remote attestation procedures again.</t>

</section>
<section anchor="operational-considerations"><name>Operational Considerations</name>

<t>This specification assumes that the software/firmware author provides a MUD file that describes the behavior of the software running on a device.</t>

<section anchor="pros"><name>Pros</name>

<t>The approach described in this document has several advantages over the RFC 8520 MUD URL reporting mechanisms:</t>

<t><list style="symbols">
  <t>The MUD URL is tightly coupled to device software/firmware version.</t>
  <t>The device does not report the MUD URL, so the device cannot tamper with the MUD URL.</t>
  <t>The author explicitly authorizes a key to sign MUD files, providing a tight coupling between the party that knows device behavior best (the author of the software/firmware) and the party that declares device behavior (MUD file signer).</t>
  <t>Network operators do not need to know, a priori, which MUD URL to use for each device; this can be harvested from the device's manifest and only replaced if necessary.</t>
  <t>A network operator can still replace a MUD URL in a SUIT manifest:  <list style="symbols">
      <t>By providing a SUIT manifest that overrides the MUD URL.</t>
      <t>By replacing the MUD URL in their network infrastructure.</t>
    </list></t>
  <t>Devices can be quarantined if the Attestation Result indicates that an out-dated or compromised software/firmware version has been used.</t>
  <t>Devices cannot lie about which MUD URL to use.</t>
</list></t>

</section>
<section anchor="cons"><name>Cons</name>

<t>This mechanism relies on the use of SUIT manifests to encode the MUD URL. Conceptually, the MUD file is similar to a Software Bill of Material (SBOM) but focuses on the external visible communication behavior, which is essential for network operators, rather than describing the software libraries contained within the device itself. The SUIT manifest must then be conveyed to the network during onboarding or during the network access authentication step. Attestation Evidence is used to convey the SUIT manifest.</t>

</section>
</section>
<section anchor="suit-extension"><name>Extensions to SUIT</name>

<t>To enable strong assertions about the network access requirements that a device should have for a particular software/configuration pair a MUD URL is added to the SUIT manifest along with a subject key identifier (ski). Note that the subject key identifier refers to a more generic version of SubjectPublicKeyInfo defined in <xref target="RFC5280"/>, which refers to an X.509-based ski.
The subject key identifier MUST be generated according to the process defined in <xref target="I-D.ietf-cose-key-thumbprint"/> and the SUIT_Digest structure MUST be populated with the selected hash algorithm and obtained fingerprint.
The subject key identifier corresponds to the key used in the MUD signature file described in Section 13.2 of <xref target="RFC8520"/>.</t>

<t>Note: A key need not be in COSE Key format to create a COSE Key Thumbprint of it.</t>

<t>The following Concise Data Definition Language (CDDL) <xref target="RFC8610"/> describes the extension to the SUIT_Manifest structure:</t>

<t>The extension to the SUIT_Manifest is described here:</t>

<figure><sourcecode type="CDDL"><![CDATA[
$$unseverable-manifest-member-extensions //= (
  suit-manifest-mud => bstr .cbor SUIT_MUD_container
)
]]></sourcecode></figure>

<t>The SUIT_MUD_container structure is defined as follows:</t>

<figure><sourcecode type="CDDL"><![CDATA[
SUIT_MUD_container = {
    suit-mud-url => #6.32(tstr),
    suit-mud-ski => SUIT_Digest,
}
]]></sourcecode></figure>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>This specification links MUD files to SUIT manifests for improving security protection and ease of use. By including MUD URLs in SUIT manifests an extra layer of protection has been created and synchronization risks can be minimized.</t>

<t>Used in this way, the MUD manager presents an additional layer of security on networks where they are enabled. The MUD manager configures the L2/L3 infrastructure of a Local Area Network to apply restrictive policies to certain devices. The MUD manager only has the ability to elevate or restrict the network privileges of a device. Therefore, attacks on the MUD Manager cannot compromise devices, they can only enable a compromised device to access more of the network. Further security considerations related to the MUD Manager are covered in <xref target="RFC8520"/>.</t>

<t>If the MUD file and the software/firmware loaded onto the device gets out-of-sync a device may be firewalled and, with firewalling by networks in place, the device may stop functioning. This is, however,
not a concern specific to this specification but rather to the use of MUD in general. Below are two mitigations:</t>

<t><list style="symbols">
  <t>A manufacturer must update the MUD file in advance of network service or product changes so 
that the new services can be supported. Because the MUD file is accessed by a URL means that it can be subsequently updated. This requires a MUD file being retrieved again. This handles the case when the device 
is already deployed and in use.</t>
  <t>There is a possibility that an IoT device has remained on-shelf inventory for an extended period, resulting in its MUD file being inaccessible at its previous location. This necessitates a decision on how to implement a fail-safe tailored to the particular environment.</t>
</list></t>

</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>IANA is requested to add a new value to the SUIT manifest elements registry created with <xref target="I-D.ietf-suit-manifest"/>:</t>

<t><list style="symbols">
  <t>Label: TBD1 [[Value allocated from the standards action address range]]</t>
  <t>Name: Manufacturer Usage Description (MUD)</t>
  <t>Reference: [[TBD: This document]]</t>
</list></t>

</section>


  </middle>

  <back>


    <references title='Normative References'>



<reference anchor='RFC8520'>
  <front>
    <title>Manufacturer Usage Description Specification</title>
    <author fullname='E. Lear' initials='E.' surname='Lear'/>
    <author fullname='R. Droms' initials='R.' surname='Droms'/>
    <author fullname='D. Romascanu' initials='D.' surname='Romascanu'/>
    <date month='March' year='2019'/>
    <abstract>
      <t>This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.</t>
      <t>This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8520'/>
  <seriesInfo name='DOI' value='10.17487/RFC8520'/>
</reference>

<reference anchor='RFC2119'>
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname='S. Bradner' initials='S.' surname='Bradner'/>
    <date month='March' year='1997'/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='14'/>
  <seriesInfo name='RFC' value='2119'/>
  <seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference anchor='RFC8174'>
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname='B. Leiba' initials='B.' surname='Leiba'/>
    <date month='May' year='2017'/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='14'/>
  <seriesInfo name='RFC' value='8174'/>
  <seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>


<reference anchor='I-D.ietf-rats-eat'>
   <front>
      <title>The Entity Attestation Token (EAT)</title>
      <author fullname='Laurence Lundblade' initials='L.' surname='Lundblade'>
         <organization>Security Theory LLC</organization>
      </author>
      <author fullname='Giridhar Mandyam' initials='G.' surname='Mandyam'>
         <organization>Mediatek USA</organization>
      </author>
      <author fullname='Jeremy O&#x27;Donoghue' initials='J.' surname='O&#x27;Donoghue'>
         <organization>Qualcomm Technologies Inc.</organization>
      </author>
      <author fullname='Carl Wallace' initials='C.' surname='Wallace'>
         <organization>Red Hound Software, Inc.</organization>
      </author>
      <date day='8' month='July' year='2024'/>
      <abstract>
	 <t>   An Entity Attestation Token (EAT) provides an attested claims set
   that describes state and characteristics of an entity, a device like
   a smartphone, IoT device, network equipment or such.  This claims set
   is used by a relying party, server or service to determine the type
   and degree of trust placed in the entity.

   An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
   attestation-oriented claims.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-rats-eat-29'/>
   
</reference>


<reference anchor='I-D.ietf-suit-manifest'>
   <front>
      <title>A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest</title>
      <author fullname='Brendan Moran' initials='B.' surname='Moran'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
         </author>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Koen Zandberg' initials='K.' surname='Zandberg'>
         <organization>Inria</organization>
      </author>
      <author fullname='Øyvind Rønningstad' initials='O.' surname='Rønningstad'>
         <organization>Nordic Semiconductor</organization>
      </author>
      <date day='5' month='February' year='2024'/>
      <abstract>
	 <t>   This specification describes the format of a manifest.  A manifest is
   a bundle of metadata about code/data obtained by a recipient (chiefly
   the firmware for an IoT device), where to find the code/data, the
   devices to which it applies, and cryptographic information protecting
   the manifest.  Software updates and Trusted Invocation both tend to
   use sequences of common operations, so the manifest encodes those
   sequences of operations, rather than declaring the metadata.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-suit-manifest-25'/>
   
</reference>


<reference anchor='I-D.ietf-cose-key-thumbprint'>
   <front>
      <title>CBOR Object Signing and Encryption (COSE) Key Thumbprint</title>
      <author fullname='Kohei Isobe' initials='K.' surname='Isobe'>
         <organization>SECOM CO., LTD.</organization>
      </author>
      <author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
         </author>
      <author fullname='Orie Steele' initials='O.' surname='Steele'>
         <organization>Transmute</organization>
      </author>
      <date day='8' month='July' year='2024'/>
      <abstract>
	 <t>   This specification defines a method for computing a hash value over a
   CBOR Object Signing and Encryption (COSE) Key. It defines which
   fields in a COSE Key structure are used in the hash computation, the
   method of creating a canonical form of the fields, and how to hash
   the byte sequence.  The resulting hash value can be used for
   identifying or selecting a key that is the subject of the thumbprint.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-cose-key-thumbprint-05'/>
   
</reference>

<reference anchor='RFC8610'>
  <front>
    <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
    <author fullname='H. Birkholz' initials='H.' surname='Birkholz'/>
    <author fullname='C. Vigano' initials='C.' surname='Vigano'/>
    <author fullname='C. Bormann' initials='C.' surname='Bormann'/>
    <date month='June' year='2019'/>
    <abstract>
      <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8610'/>
  <seriesInfo name='DOI' value='10.17487/RFC8610'/>
</reference>

<reference anchor='RFC9334'>
  <front>
    <title>Remote ATtestation procedureS (RATS) Architecture</title>
    <author fullname='H. Birkholz' initials='H.' surname='Birkholz'/>
    <author fullname='D. Thaler' initials='D.' surname='Thaler'/>
    <author fullname='M. Richardson' initials='M.' surname='Richardson'/>
    <author fullname='N. Smith' initials='N.' surname='Smith'/>
    <author fullname='W. Pan' initials='W.' surname='Pan'/>
    <date month='January' year='2023'/>
    <abstract>
      <t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9334'/>
  <seriesInfo name='DOI' value='10.17487/RFC9334'/>
</reference>




    </references>

    <references title='Informative References'>



<reference anchor='RFC9190'>
  <front>
    <title>EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3</title>
    <author fullname='J. Preuß Mattsson' initials='J.' surname='Preuß Mattsson'/>
    <author fullname='M. Sethi' initials='M.' surname='Sethi'/>
    <date month='February' year='2022'/>
    <abstract>
      <t>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9190'/>
  <seriesInfo name='DOI' value='10.17487/RFC9190'/>
</reference>


<reference anchor='I-D.fossati-tls-attestation'>
   <front>
      <title>Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
      <author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
         </author>
      <author fullname='Yaron Sheffer' initials='Y.' surname='Sheffer'>
         <organization>Intuit</organization>
      </author>
      <author fullname='Paul Howard' initials='P.' surname='Howard'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Ionuț Mihalcea' initials='I.' surname='Mihalcea'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Yogesh Deshpande' initials='Y.' surname='Deshpande'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Arto Niemi' initials='A.' surname='Niemi'>
         <organization>Huawei</organization>
      </author>
      <author fullname='Thomas Fossati' initials='T.' surname='Fossati'>
         <organization>Linaro</organization>
      </author>
      <date day='8' month='July' year='2024'/>
      <abstract>
	 <t>   The TLS handshake protocol allows authentication of one or both peers
   using static, long-term credentials.  In some cases, it is also
   desirable to ensure that the peer runtime environment is in a secure
   state.  Such an assurance can be achieved using attestation which is
   a process by which an entity produces evidence about itself that
   another party can use to appraise whether that entity is found in a
   secure state.  This document describes a series of protocol
   extensions to the TLS 1.3 handshake that enables the binding of the
   TLS authentication key to a remote attestation session.  This enables
   an entity capable of producing attestation evidence, such as a
   confidential workload running in a Trusted Execution Environment
   (TEE), or an IoT device that is trying to authenticate itself to a
   network access point, to present a more comprehensive set of security
   metrics to its peer.  These extensions have been designed to allow
   the peers to use any attestation technology, in any remote
   attestation topology, and mutually.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-fossati-tls-attestation-07'/>
   
</reference>


<reference anchor="FDO" target="https://fidoalliance.org/specifications/download-iot-specifications/">
  <front>
    <title>FIDO Device Onboard Specification 1.1</title>
    <author >
      <organization>FIDO Alliance</organization>
    </author>
    <date year="2022" month="April"/>
  </front>
</reference>



<reference anchor='I-D.ietf-opsawg-mud-acceptable-urls'>
   <front>
      <title>Authorized update to MUD URLs</title>
      <author fullname='Michael Richardson' initials='M.' surname='Richardson'>
         <organization>Sandelman Software Works</organization>
      </author>
      <author fullname='Wei Pan' initials='W.' surname='Pan'>
         <organization>Huawei Technologies</organization>
      </author>
      <author fullname='Eliot Lear' initials='E.' surname='Lear'>
         <organization>Cisco Systems</organization>
      </author>
      <date day='1' month='March' year='2024'/>
      <abstract>
	 <t>   This document provides a way for an RFC8520 Manufacturer Usage
   Description (MUD) definitions to declare what are acceptable
   replacement MUD URLs for a device.

   RFCEDITOR-please-remove: this document is being worked on at:
   https://github.com/mcr/iot-mud-acceptable-urls

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-opsawg-mud-acceptable-urls-11'/>
   
</reference>

<reference anchor='RFC8995'>
  <front>
    <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
    <author fullname='M. Pritikin' initials='M.' surname='Pritikin'/>
    <author fullname='M. Richardson' initials='M.' surname='Richardson'/>
    <author fullname='T. Eckert' initials='T.' surname='Eckert'/>
    <author fullname='M. Behringer' initials='M.' surname='Behringer'/>
    <author fullname='K. Watsen' initials='K.' surname='Watsen'/>
    <date month='May' year='2021'/>
    <abstract>
      <t>This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8995'/>
  <seriesInfo name='DOI' value='10.17487/RFC8995'/>
</reference>

<reference anchor='RFC5280'>
  <front>
    <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
    <author fullname='D. Cooper' initials='D.' surname='Cooper'/>
    <author fullname='S. Santesson' initials='S.' surname='Santesson'/>
    <author fullname='S. Farrell' initials='S.' surname='Farrell'/>
    <author fullname='S. Boeyen' initials='S.' surname='Boeyen'/>
    <author fullname='R. Housley' initials='R.' surname='Housley'/>
    <author fullname='W. Polk' initials='W.' surname='Polk'/>
    <date month='May' year='2008'/>
    <abstract>
      <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='5280'/>
  <seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>




    </references>


<section numbered="no" anchor="acknowledgements"><name>Acknowledgements</name>

<t>We would like to thank Roman Danyliw for his excellent review as the responsible security area director, Bahcet Sarikaya for his Genart review, Michael Richardson for his IoT directorate review and Susan Hares for her Opsdir review. During the IESG review Robert Wilton, Eliot Lear, Zaheduzzaman Sarker, Francesca Palombini, John Scudder, Paul Wouters, Éric Vyncke, and Murray Kucherawy.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA7Vb23bbRpZ9x1fUsnutkRyCsuQ4HWuS9FCW3FZHt5HkpGeS
Hq8iUCSrBQLsKkAMIzvv813zY7PPqSqgQEqyM72GDxIJFOpyrvtckKZpUuu6
UPviqjZVORUja5WpdVVaUU3EcXUtzlS9rMyNGGWZslZcqn802qi5KmubyPHY
qFs8/O74Wpy+OxQnuryRU5U0i1zWyu6L3MhJnWpVT1Lb6Dqdy1JPlK2TvMpK
OVf3jGjy9PmrJMPz08qs9oWt8yTRC7MvatPYeu/581fP9xJplMTCKmuMrlcJ
bXFqqmbhNpPcqBUu5fviuKyVKVWdHtI6SWJrWebvZVGVWHulbLLQ+4kQZpKp
3Narwl8Voq6y6Ksuc5w4XLCVqY2a2Pb3at77WRudtYOzas7UCr91WeiyW0b9
UqeFtnWKScZVgWFp9ewL3AGF5nKx0OXUjU1kU88qg92muEsfXWL0wVCcVkaW
/poj6oFRZS7L3p3KTEH8XyVxd1+MzBzcmuta5f6+mktd7Iuxe3Q4p0eHxJd/
m9KdIc6RrK39diiubTarJqrU094G3sqyVHbzbn8T/ZVn/Mywbp/Bwr8Mwbsk
KSszxzO3inh1+eb11y/3nvuve7u7r8LV3T9+SV+P00PeeGpkbVMl697Fnhz2
7mSVVSkkJ61nzXy8MLqsw8xf7Yb1Xr14gUV0OVnb0qvdV8/DbJPKWtxL68Km
soYi1O7AuP3m8Hyfj91yM9BlX7w5PjwXo6LQsswU3/DKyTcO1a3OlDgvx5U0
ubhaqExPdMYzi93hLj9AagfmYu+F2Hu+t+dmkWaqII+zul7Y/Z2dic4r6ZcZ
YuUdG89ld/JqWRaVzFNdQSz795IkTVMhx5BxmYEz1zMlTmXZTPCrMcqIdxYG
AJu1mdEL3tsWLMO26M0jcr4/hojUmEA62wLNFKU3N5OmzGikLKDewjirkwtQ
XUg8zaSoK7Ew1UKZYtWOh0TOtPXzu/Vn0tJQaGihspoXtNWkXsKECNOUJTRM
YBhd9xPTRnRtobrlRE8bI93MByqTjVVkGWssMuBH5pWtBfQUGzEa1BfQddoy
7dSfkhbwM4fj+RObyJoK7YhhoUBCuu9+LjysiopMQX/39+8zSUbtOgujLCYB
5Za6noF0ZKUnulBivOoICWGolkS0WjER6YRzbcdqJm81zoGxEXV6y/eWpuf8
yXAdHqUYkoQQP6qsoVNijokmyyDFUq6ILTCGNzz7VZj2nXMeTMFgvmlmTFRO
rdgiA78tggbTHNGxqslEGSKUJDMMlwaRBANyujQGUZRynAZ5hk6W5zrPC5Uk
T2kxU+UNk4CI+Flyzat24rycyZr9A+04cIFcQFMG2W/J2tLfCayeluATjoPb
aijeYIT6Rc4XhRokks7bbWYO2pEkRgfHc2EXOCA20c6OgVa8vb6+GIjDsyvm
2tn1xfqmmlqUlahAG0NaBZ8HZ0TapNZGLsiiGQAE8CoJS0IOS6z4l6vzs3Qs
rdNU2Ee6TOQO2xx6i+F/kmAMxKxaQsDNAPRyBMAROsHtC1/LbdBDEnP9AmQG
pDMYLdmXOIuKH2Y6L4pqpfJh8g4u3Yi7O+9OPn4c+GGklgvioFvo3eXJ71nV
kSw8qEnSeQZiSSaJ+8SQ9ljxpGykMgWf0qOZmJhqHrMaEO3WDW+KWoPKCgaw
Gtdyk9h3d9JkMwZVUNOPH4WdkaaHUXRTk9JDqgZkdJx6MjdBF0GEwSy//fYb
O5Lh533cWHHv5330WRsV33r/yBwf1n4MH7glPnxqEiIB/0jT7+AhiVH41rv1
qUlOPe/cTrbYxW7zrzfEqivHqnaSIyifXdlazVsp/RAf+8M3aeDeN+k3vVvv
H9tJ+IS7j/LggbERW3qfHr/c2JbOfYLjJzB4TeT4EI31yAVUTr/ziuHJXBk/
SRjbnnV9Xgv/lc3isQ8dqyNaN/Yz5Zbk/G5fPI11xmGwb5/QxkeRugiofqcj
Tz4mSfgBr32rLcdQuSZ3RH6PEYLMZt6vwT3eqlVw6MFasKL3jd2DVubKu+ov
ydHc3f2pRbHVwsrllLdPvnhRy3Gh0sYUFuqPTdzqnPxvnms/ZYyVGNq0G7Lw
ZI2BRRzAlmqQX5dZ0eSAvEkqDt++vhjg//HR0ZH4+vnecHd0wAGgOJEr0OZQ
26yC8K/EhXcnYuvk5PBie0AuqPfgX52p9ibRG9yeCVxWTZGT7SRcIYOJoiEZ
xauMK71hJUdUiqPRhZgrQOw8cjnB0M4bwg2G/8areMPKbHAH7t2GMZ8oSKFz
UkZBDMoOAzaLtK5Sgi6RAT6u3WKysFW0Ysdf72r4JJUxBFA98YfAI/AYDm8S
sdlzEwVbKmFDTUnOGo9hU4yfq1qMqwYE9iQMrq+2qpiAFj/OVNkTOkzi2eqd
eEzRmkbrmv1YQz9qvu7WQnykphR+i3YPQ/E2OPN15lRlwQNvIX0LBEhAiQEy
4rK+pTEIvnhmhKCVsR4Xe7GI59LWNsoErF9hRjo3Tx4QmAeTfDoSDKALQuQ0
Voeh7JTXWRyzwrlfPOco6aBDO/k+RcG1krk7LBDLAkoPvM8xywSo2obAYnPz
xHxNSQU9WfX44dcuHCUwyjaLBf3iEVeEEk03aEjC7c4pO/yk6ckufnDgwyiG
1RsRRB/Cr2megzM+ACHgY4PijQl8g5E6PBawYFJvYMZenONtTMeiup0/721o
Ld4LscR6JOkDihJouValjQ7xfw0p7u7uzxZ8/Eha5bWlg4dDMXIpsHYCTakd
DBhDETkoIVsksQeJ0BkeEkfM1Q7/5hOWnGpzxxwE3FqBAZ6P7XCWNJo7QFWM
8qaZfUyhyVgzEc1qUVdTIxe4Ldp8BQF4p6w4OU3E9svvGxQWbB/APciQC6OC
XPoAsj1j41F+y8idiTZzJrdP/znrIVuk4/wYeT8ceAornswroxy7oQlkpUIY
vuGRHpGnT+cEKLi7Vmauy6qopivnEMjWUI7QCvj2q+snA/dfnJ3z98ujf393
fHl0SN+v3o5OTtovbkSCH+fvTvx9+tY9+fr89PTo7NA9jKti7dLp6D+eOC/4
5Pzi+vj8bHTyxJ09DpWlE4KxYkNrEBGx4bUiDrqSAziG3S9dHEO5MDh5F9Ps
/vFLfIcslU4g2P66nyDoiqRFSY5kYKiSTC50DS/FUQAFCaUgKdyI3w2ghPVW
BJua90IGXpgSZFjYqIIdRV0lYBQkTkSZMIC3S9hNZWxIpvSPLWEi5yEWTCZy
DpOKvbII0sqTijIWDJ9oD/vi6NZJ0EC8LqSeD8SIFyM/9IMysBb4lhAVLhEr
0XMX0sAwbl1ebG8ckX21O+S9BwzRom2gdqAWFGSQBHs5iIHGICjPQAA3sBj+
CEWYYO+90KxUy43wLArNgNFa00bm12UpXAzZamrCFoiOiDWd1SYJV4XXEpam
4O9ae07GhjWGJuSFk1aLyaUQKaaqZPzJ1qBVf+lNU+cojjsbkzgrt+5a1RxC
63BGsNA9s0lzeoSaexueeL2+1TCVffsCm5rN8KidD8U5WQ+Wo9jS0QlupS4I
ASf9FJ9uo/Eu05A3JkrVVS7RiisDfydZy95FiAirDSiagTgspEv+uFQKq67M
XEmF6J/o8rYqfIjvwgDKw9ITQYgfxf2jCSaEStVGY58+gAgUHPRJ7k/oUgPO
dixVUUQR/X2fjTD8viCr9+ORUaeBt4+NulSMIyrECg+P2gyF+x8fwIv/CrP2
ZCt5OAj80PvnEhgPZi/8Nm7bMHnY3uqR7fNSF9EEG6mLfz5v8c8nLX5/xuLz
ThE+nlfiC4K1ksPqjZzH5yUx+Pv/7+BP5ke6HEmcIBl1bo9+no2u4J1GI7IW
H8LgLkPyXTACzNDz1gaJdnCX3dj6IlavwDa/bHdAT2R2jNv+dp/IbjB/nn12
gg+fZ48SMP7s7KQ///z7HxM/pzuffMpVn1tC8PnCQ188e+BDtHO+mUmS4vOM
/qQPmsXweRO8UHc48fMnn9r87Ijf/9hh8NubqSqPIUK6ioiSruesOE1FyIC8
UklOdunhCLtK63GVjyAcCOPIKoJundft1VOiyllwQd7K7CcJWDdyaKDWc3Z1
Pefaz7pjmDZRKMXRexyWButFkMBWcw7Q55xHiHbZ+lI+SexoQ3GjjWw5bPD5
J3hqJgTOHBCkG9dWoNfCTxee2AiMcCGP0A9u2QzM8gmECGJSnCVSEKUMFR7e
frTrUD1xWPDIhfGxJbmubkD5raMR4tYoXA0Vb8KnLi7kghglBwz9si7uzcgW
WJ8/6R8ocJ2xYrsfH/PSPK5gdx98I4bQ1Sfhin3iVhJbVqkuYzncG+6+dGnL
eza+LZhcHql2csAJrDUU6ajjN+mP0+3Zera3YPLeKlErRkEwOmT/KN5rx4ut
SVeqg7AGUHY0ukivT67E7vCFT0X6AGn3FeIH0dQIan4Ng2PZjcC+o9AD/QSe
VpCbTp26XRX6Rt3bObD15vCchAb/sA1McFBVNdXzudkEYIyjNW6tUeJ7xBAA
9kZiQOMS31sHl1ffH9MMf6Jo6NWrlx8/Bom+7uvogBSKAweSnF7sNeAIcWV7
LAx8CjEba6+viUVK6ch0qWxTsIHwmbcgAb6cvW4vMHc2U9lNLwzyZUEvGNhc
G2OqXxYurQqnGjKVD+fNAgGuNBudOIkdZYU209dd4Lq+XQLvRVXdINrpcpJ0
TmZzlLJ5tk51EJ3TI7YfDbTVhbbcQHnisJGeKjub19duv3XbmyKknHsLLYye
S6MLru/njQt1rP5VxeWFkFwMUeYa00JNexyiPciBXOgck0YMpxGKwimnRpTh
tMN7CHLr5GltetuCzk5pr5rx3ynzy3Lv0rMkh1ss8W1sei/N3Lrl/ZyULodb
rnq9Iouq0Nmqn9OJCsO+iHskqRJBnjPuGPBkIT0aQ4HpG3SZo86lBmlsM6Zm
t1qDsitBzmlKYxD4LnVBGQUouMvwi80EDR01Uwh7Se0oVcfJi/PIfL6mVHfu
f9t7U7M9VxKnfLtMoeuCispSEfPpqX6fUNs5sZ5Cjtp4omzx06dUerIO8oQC
XC97tpZ6ok4hS9ULnE/mtyAe+AfjwNV2zNFW+IL4O8jC+ti6//1YI32BpdbT
GWX0s6qBj8hdtrzXTNORxJubIMZ+XFvkiApGbXLJ9ko9EDdWSfgjFeXMQrLa
z+spDysHEdRcbuArUFNiA+WOqPYAFem6NQaeUS4VxIdyR1rvrllwdo05eFO6
1iLeWtdRRBZlq+72scbRlhzbLaSM5swVYAWJ5vq0Wz3dVmabTnu2ln4mhjMp
Q7mEtjhwVSicPwCnqPeDACj7eCc/tOa/OtHxGZaZROhlyUitlXD/xfazW5yE
BQsLSfk7TS1CBC2kWdFOR/enym1NCuufijLyXK3r2aB98kLPxMGqx6i+HWcK
kkgb1rieaPiH3VLr1Wln9IDNwyZ1DxewJzr0WN7T5R+NNGSCSndYmu1eD55z
ZcxbCsIzTZ06o8+18jlOM9c2Kr1tqAvr7pjkj+oSw/5WiNmFVr72ch97nbV4
3VmyLsoBTCHP4dOHvv+vR1KuwsCJV7nqkZPmowJ8QxZ4LTVHxlLPNcTYNRe1
paoD4jVWOMXx4SSALq8Ozk+3uUFrAkNlu70QTjRki6ndYFysF0mCVrTFe0Bn
S6lOmpXEeV3YoN/4P2NjJ9sezY2uw0KPDdy7itEMWRm9lmDlgvM9QGLuq+Cl
r+f3EHrYk8/FRsCWqrfuYjzufmgOVVwMe6IWRwVcuSI0yGvfh37I2R11KBxj
ecDdUy4HtvicomniPOWXfbshOb3QQd8lwR9r++w369kZdzpQC6AvbJHd01lD
ktJKf79ku5DaxGaBuzs6kq7l2IsqoFxJGIHRDll7HaEde6O3h+KsqqOawQNj
jeL4koWYy3lcLtBZDJs9qLpoxvA1QFZUKeiXVSiSeLn39fMubo3mLcVfhy+f
v/KNhdgbF70f2hAX8cYqlC0o7Z0BO7MMeYowuLFrlZ3H2sARJwU3RNR8f6in
RMsuJgqLLqpF4+perd+FGrg4AhYKNC+m8DH1bO7cQcjMYx9TKvFpSg48crgu
CLDhMDQiNL4EE9Mh2157Ko8JYfjui+GeC8LbmhasIPF8H46IZmX/yA0lXJl9
fX51xLjYJydIg7inAJxv7123NKO5de27b7qCHdlEgqeHVPw+JAa4BoIT4NOG
Wmy3Xh8enmz7bX21S6FyHwVulvmJJW0CsGXKvlv6E8N1jL0pC7TP1RHaRPKH
PzSlw4PUQhVUKJ1TBsKkUZi+s/Ot2KI3P+JuAUrLiW+/E9QrL4bZGNrsln53
+D5YTpNscyovuW43Ft+NJEx34tol6qK93vPwt+KOE4ztezWNKWhDT78avtjb
opB/e9AfAN2iAZGMD5KPboNP25dtPgf6U5LIRm2+wYJ2LpOMm54zTIFU2DB3
aE4gJE+NQL7/iVw0IROXh6In2hY1Eun+1K4VxEhRcCMaHo9mbXGCk13XcWJX
ZTaD+fZvpgij7U0LYuYQ0TlgMXWSvbNR3LCUkVcPvWW+nOjSpl2TXbuV9qRY
xrsF23Uqr7hO6zxK3rUSh8nbzhinCSd7Oycv1mCYa6g6qTIsOsIRW/hLlpSD
UDzNLyhRMpMDUO0YRD1K1ELs87GbqzN4nflXE6RvcyLoUyju3qpMO3fP61F3
F6SAQ6lJF6DR/LDyFbce17XMblpksxY9kw3qUGDYoO9jyDj/hZ15Pyx7gDFq
G3e+l32UjzbaouqbxjDuaZmT9UQ8ambY2J7kDhbYiI0OAYjLcT/f0TqRTRhL
79sQ3A2Fcb/vqao5mZxWk5SEtAMK9ArAmOy7UUvgSyfIA+d2wkUOy1admGF/
HEMM4iVoIltXi7ZdBk/5xAy94xKa8xNiAifSISdlq+6OJBv6T2g1YMkqBs5E
CmzDOeeC3qmh6gM3JywrqBqCSkdz7jEdrb320HCfZe47EyM0Xbp43dXRg9xR
OydX8o3vcKh9GoT6WkXSIptSLcPYVump6Q5xNilheO1nHb87gXIZG5fwmyvp
q/xRfwHlYYD3YBMgoz5p4+nrcWAv7TFWxDVf3yeucvbFjcfm88LrPneGLmf9
8kvC2TRofb7q2hVdq6aPclKnda5fkNowQ7tiCL26RjRWdUMv55UsmamdcQYe
oLnkWr1vXWM/SMKLMEJXnJCisI6OoUt+P2ntcLp0pOOYhWllyWwiVmksFCGT
0YtcLj7WNYeHJPyZdqiyJMnkJkpKu7vGHTGRukitnIBZ+FaZTmUjFE3t2bD1
vhDzVByPzkYbPo0veha5yJ5MSJ5zO9tS3MqiUfcD7LbjxqiphjVctZ6GdfPh
3kKW+BM5VsW+uD443BU//fQDL0OpUdd122YX+DVWSc1r0jvLPDccWpB8/+1v
mOmMX8T8nHeYMPhScZ96hid++gmL74teTxQm5HelxjDSRLJRRjkTGJ2pfxP4
bl+UDaEilX/7pKyozvhj6NrmQgSTSpY34rLCiYH+ylWhlyxCtJD6JVMwYtxg
dqtBYO9l2p5a7s72xpne/RW5pgZYim4P5CxTtbhCTHojV7Kd889wCCZMOBCn
iCqkKsQl/QflcPowkmXez0e2JewBinPVWGz3LWebeDjIeL6wGO1HDcVhF5Ue
H139OTx9WYEctfhRFzU1Bx0VGgb0REns+D/lTOXNr79KIgX2fUOVkjeG7JfN
pLhAjMZdXQPxl2qGEVmDeA5DLmRTiB/5DQtY5v/5bwqzfoBXuFGuYnvaGANr
/n2TYZtyuRom/wup9VjP4j0AAA==

-->

</rfc>