MUD-Based RATS Resources Discovery

Introduction Verifiers, Endorsers, and Attesters are roles defined in the RATS Architecture . In the RATS architecture, the Relying Party roles depend on the Verifier to bear the burden of Evidence appraisal and to generate corresponding Attestation Results for them. Attestation Results compose a believable chunk of information that can be digested by Relying Parities in order to assess an Attester's trustworthiness. The assessment of a remote peer's trustworthiness is vital to determine whether any future protocol interaction between a Relying Party and a remote Attester can be considered secure. To create these Attestation Results to be consumed by Relying Parties, the Attestation Evidence an Attester generates has to be appraised by one or more appropriate Verifiers. This document defines a procedure that enables the discovery of resources or services in support of RATS, including:

Reference Values,
Trust Anchors,
Endorsements and Endorsement Distribution APIs,
(remote) Verifier APIs,
Transparency Logs, or
Appraisal Policies.

MUD URIs can be embedded in any data item that was signed with trusted key material. One common way to establish trust in a signed data item is to associate the signing key material with a trust anchor via a certification path (see for trust anchor and certification path). This document defines the use of MUD URIs embedded in two types of signed data items that typically are trusted via certification paths:

Secure Device Identifiers (IEEE 802.1AR DevIDs) as defined by and
Entity Attestation Tokens (EAT) as defined by .

DevIDs and EATs (essentially CWTs ) are two very prominent examples of "trustworthy documents" (TDs) with a binary format and the embedding of MUD URIs in theses TDs can be applied to other TD types, for example, Selective Disclosure CWTs . Other TDs are out-of-scope of this specification, though. The TDs are typically enrolled on Attesters by manufacturers or provisioned by supply chain entities with appropriate authority. The TDs can be presented to local Network Management Systems, AAA-services (e.g., via IEEE 802.1X), or other points of first contact (POFC), for example, . These POFC are typically trusted third parties (TTP) that can digest the TDs and then base trust decisions on the associated certification paths and trust anchors. If a TD presented by the Attester is deemed to be trusted by a local trust authority, the MUD URI embedded is considered to be a trusted source for viable resources and services in support of remote attestation of the Attester. This specification does not define the shape or format of any resource or service that is referenced by the MUD file. In support of a unified mechanism to categorize the formats of referenced resources, a conceptual message wrapper (CMW, is used for each type of resource. An example of a referenced resource is a CoRIM tag .

Requirements Notation 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 when, and only when, they appear in all capitals, as shown here.

MUD URIs in Trusted Documents (TDs) This document does neither modify nor augment the definition about how to compose a MUD URI. The two types of trusted documents (TDs) covered by this specification are Secure Device Identifiers and Entity Attestation Tokens.

MUD URIs in DevIDs defines the format of how to embed MUD URIs in DevIDs and that specification is used in this document.

MUD URIs in EATs To embed a MUD URI in an EAT, the mud-uri claim specified in this document MUST be used.

MUD File Signatures As the resources required by a Verifier's appraisal procedures have to be trustworthy, a MUD signature file for a corresponding MUD File MUST be available. The MUD File MUST include a reference to its MUD signature file via the 'mud-signature' statement. The MUD File Signature generation as specified in applies. If a MUD file changed (i.e., the checking of the MUD File Signature fails) or the corresponding MUD File Signer certificate is expired (see , the reference in the changed MUD File MUST point to a new valid MUD Signature File and that new MUD File Signature MUST be available. If a corresponding MUD File Signer certificate is expired (see ) or a MUD File Signature referenced by a MUD File cannot be checked successfully, the MUD File MUST NOT be trusted.

MUD File Signer in DevIDs defines the format of how to embed a reference to the signing certificate in DevIDs and that specification applies to this specification.

MUD File Signer in EATs To embed a reference to a MUD File Signer in an EAT, the mud-signer claim specified in this document MUST be used and the mud-uri claim MUST be present. The value of the mud-signer claim is a CBOR byte-wrapped subject field of the signing certificate of the MUD File as specified in .

Trusting MUD URIs and MUD Files The level of assurance about the authenticity of a MUD URI embedded in a TD is based on the level of trust put into the corresponding trust anchor associated with the key material that signed the TD. If it is not possible to establish a level of trust towards the entity that signed a TD, the embedded MUD URI SHOULD NOT be trusted. In some usage scenarios it might suffice to trust a MUD File, if the referenced MUD File Signer's certificate is not expired, but that behavior is NOT RECOMMENDED. The level of assurance about the authenticity of a MUD file is based on the level of trust put into the entity that created the corresponding MUD File Signer's certificate. If it is not possible to establish a level of trust into the corresponding trust anchor associated with the MUD Signer's certificate, the MUD File that references that MUD Signer MUST NOT be trusted.

Trusting RATS Resources Referenced by a MUD File Resources, e.g., RATS Conceptual Messages, that are referenced by a MUD File MUST be signed (e.g., via a COSE_Sign1 envelope). The signing procedures, the format of corresponding identity documents, and the establishment of trust relationships associated with these resources are out-of-scope of this document.

Specification of RATS MUD Files Referenced by MUD URIs The MUD URI embedded in a TD presented by an Attester points to a MUD File. MUD URIs typically point to a piece of data that is a YANG-modeled XML file with a structure specified in the style of a YANG module definition ( and corresponding updates: , ). This document specifies a YANG module augment definition for generic MUD files to create RATS MUD files. The following definition MUST be used, if a MUD URI points to a RATS MUD file.

Tree Diagram The following tree diagram provides an overview of the data model for the "ietf-mud-rats" module augment.

YANG Module This YANG module has normative references to and augments . <CODE BEGINS> file ietf-mud-rats@2025-02-09.yang module ietf-mud-rats { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-rats"; prefix "mud-rats"; import ietf-mud { prefix "mud"; } import ietf-inet-types { prefix "inet"; } organization "IETF RATS (Remote ATtestation procedureS) Working Group"; contact "WG Web: http://tools.ietf.org/wg/rats/ WG List: rats@ietf.org Author: Eliot Lear <lear@cisco.com> Author: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>"; description "This YANG module augments the ietf-mud model to provide for three optional lists to enable Remote Attestation Procedures so that this device type may be used as a controller for other MUD-enabled devices. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2020-03-09 { description "Initial proposed standard."; reference "RFC XXXX: MUD Extension to find RATS supply chain entity resources: remote attestation services, endorsement documents, and reference integrity measurement"; } grouping mud-rats-grouping { description "Grouping to locate RATS services"; container ras { description "Lists of Remote Attestation Service (RAS/Verifiers) candidates."; leaf-list ras-uris { type inet:uri; description "A list of Verifiers that can appraise evidence produced by the entity that presents a DevID including this MUD URI."; } } container rim { description "Lists of Reference Integrity Measurement (RIM) candidates."; leaf-list rim-uris { type inet:uri; description "A list of RIM CoSWID that provide reference integrity measurements represented as signed CoSWID using the CoSWID RIM extension."; } } container edt { description "List of Endorsements for Roots of Trusts (e.g. Endorsement Key Certificates)."; leaf-list edt-uris { type inet:uri; description "A list of Endorsements that vouch for the characteristics of Roots of Trusts the entity possesses."; } } } augment "/mud:mud" { uses mud-rats-grouping; description "add mud-rats URI resources"; } } <CODE ENDS>

Privacy Considerations The privacy considerations of RFC 9334 apply.

Security Considerations The trust model and Security Considerations of RFC 8520 and RFC 9334 apply.

IANA Considerations RFC Editor: Please replace "RFCthis" with the RFC number assigned to this document. RFC Editor: This document uses the CPA (code point allocation) convention described in . For each usage of the term "CPA", please remove the prefix "CPA" from the indicated value and replace the residue with the value assigned by IANA; perform an analogous substitution for all other occurrences of the prefix "CPA" in the document. Finally, please remove this note.

CWT mud-uri Claim Registration IANA is requested to add the new mud-uri CBOR Web Token claim to the "CBOR Web Token (CWT) Claims" registry in the Standards Action Range as follows:

Claim Name: mud-uri
Claim Description: A CBOR byte-wrapped MUD URI as specified in
JWT Claim Name: mud-uri
Claim Key: CPA109
Claim Value Type(s): CBOR byte string
Change Controller: IETF
Specification Document(s): of RFCthis

CWT mud-signer Claim Registration IANA is requested to add the new mud-signer CBOR Web Token claim to the "CBOR Web Token (CWT) Claims" registry group in the Standards Action Range as follows:

Claim Name: mud-uri
Claim Description: A CBOR byte-wrapped subject field of the signing certificate for a MUD file as specified in
JWT Claim Name: mud-signer
Claim Key: CPA110
Claim Value Type(s): CBOR byte string
Change Controller: IETF
Specification Document(s): of RFCthis

JWT mud-uri Claim Registration IANA is requested to add the new mud-signer JSON Web Token Claim to the "JSON Web Token (JWT)" registry group as follows:

Claim Name: mud-signer
Claim Description: A MUD signer reference represented via a URI text string as defined by
Change Controller: IETF
Specification Document(s): of RFCthis

JWT mud-signer Claim Registration IANA is requested to add the new mud-signer JSON Web Token Claim to the "JSON Web Token (JWT)" registry group as follows:

Claim Name: mud-signer
Claim Description: A MUD signer reference represented via a URI text string as defined by
Change Controller: IETF
Specification Document(s): of RFCthis