]> Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@ietf.contact

Cisco Systems, Inc.

evoit@cisco.com

Huawei Technologies

101 Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012 China william.panwei@huawei.com

Security RATS Working Group Internet-Draft This document defines how to subscribe to YANG Event Streams for Remote Attestation Procedures (RATS). Specifically, this document defines a YANG module that augments the YANG module for Trusted Platform Module (TPM)-based Challenge-Response Remote Attestation (CHARRA), enabling subscription to RATS Conceptual Messages of the Evidence type and auxiliary Event Logs as part of that Evidence. The module defined requires at least one Trusted Platform Module (TPM) 1.2 or TPM 2.0 (or equivalent hardware implementation providing the same protected capabilities as a TPM) must be available on the Attester on which the YANG server is running.

Introduction and define the operational prerequisites and a YANG Model for acquiring Evidence from a network device containing at least one TPM 1.2 or TPM 2.0 (or equivalent hardware implementations providing the same protected capabilities as a TPM). However, these documents are based on the challenge-response interaction model (CHARRA in ), which has limitations. One such limitation is that it is the responsibility of a Verifier to request signed Evidence from a separate Attester containing a TPM. This means that the interval between a security-relevant change event occurring and the event becoming visible to the interested RATS entities, such as Verifiers or Relying Parties, can be unacceptably long. It is common to convey Conceptual Messages ad-hoc or periodically via requests. As new technologies emerge, some of these solutions require Conceptual Messages to be conveyed from one RATS entity to another without the need for continuous polling. Subscription to YANG Notifications provides a set of standardized tools to facilitate these emerging requirements. This memo specifies a YANG augmentation for subscribing to YANG-modelled remote attestation Evidence, as defined in . Essentially, the limitation of poll-based interactions has two adverse effects:

1. Conceptual Messages are not streamed to interested consumers of information (e.g., Verifiers or Relying Parties) as soon as they are generated.
2. Even if they were streamed, the freshness of Conceptual Messages cannot be appraised in every scenario. This is particularly important for Conceptual Messages, such as Evidence, that depend heavily on freshness.

This specification addresses the first adverse effect by enabling consumers of Conceptual Messages (subscribers) to request a continuous stream of new or updated Conceptual Messages via an subscription to an <attestation> Event Stream. This new Event Stream is defined in this document and is provided by the producer of Conceptual Messages (the publisher). As covered by this document, via a Verifier's subscription to an Attester's Evidence, the Attester will continuously stream a requested set of freshly generated Evidence to the subscribing Verifier. For example, when a network device's Evidence changes following events such as booting, updating, control unit failover, plugging in or out of forwarding units, an attack, or certificate lifetime change, the network device will generate fresh Evidence available to the subscribing Verifier. The second adverse effect stems from the use of nonces in the challenge-response interaction model realized in (CHARRA). According to CHARRA, an Attester must wait for a new nonce from a Verifier before generating a new TPM Quote. To address delays resulting from this wait, this specification allows freshness to be asserted asynchronously via the streaming attestation interaction model . To convey a RATS Conceptual Message, an initial nonce is provided when subscribing to an Event Stream. There are several options to populate or refresh the nonce value provided by the initial subscription. All of these methods are out-of-band of an established subscription to YANG Notifications. Once a subscription has been set up using an initial nonce, two alternative methods can be used to provide freshness handles for the subscription going forward:

1. A central provider supplies new, fresh handles (e.g., via a Handle Provider that distributes Epoch IDs to all entities in a domain, as described in and facilitated by the Uni-Directional Remote Attestation described in ), or
2. A handle can be updated by sending out-of-band TPM Quote requests periodically or ad-hoc, as facilitated by CHARRA.

Both approaches assume that clock drift can occur between the entities involved. Consequently, other conditions arising in different application scenarios ought to be considered in the same way. For example, the time of Claims collection ought to be taken into account as it potentially impacts the freshness of Evidence. The scope of this document is limited to the removal of the two adverse effects described when using the specified YANG augmentation. In essence, the YANG augmentation enables RATS Verifiers to maintain a continuous appraisal procedure of verifiably fresh Attester Evidence without relying on continuous polling.

Terminology The following terms are imported from : Attester, Conceptual Message, Evidence, Relying Party, and Verifier. Also imported are the time definitions time(VG), time(NS), time(EG), time(RG), and time(RA) from that document's Appendix A. The following terms are imported from : Event Stream, Subscription, Publisher, Event Stream Filter, Dynamic Subscription.

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.

Operational Model describes the conveyance of TPM-based Evidence from a Verifier to an Attester using the CHARRA interaction model . The operational model and corresponding sequence diagram described in this section is based on . The basis for interoperability required for additional types of Event Streams is covered in . The following subsection focuses on subscription to YANG Notifications to the <attestation> Event Stream.

Sequence Diagrams This section illustrates the subscription interaction model by mapping terms from and illustrating timing consideration based on Figure 3 of . Both sequence diagrams and highlight TPM-specific aspects and the Dynamic Subscription (as specified in ) to an <attestation> Event Stream. The contents of the <attestation> Event Stream are defined below within .

Binding to the Streaming Remote Attestation Model The following identifies how the abstract parameters of Streaming Remote Attestation without a Broker, as described in , are represented by the CHARRA and YANG elements used by this specification. This binding does not redefine the terminology of either source specification. The protocol bindings used by are as follows:

• handle is represented by the CHARRA information element named nonce. For the initial Evidence, this element carries the fresh Verifier-generated nonce supplied with the subscription. For subsequent Evidence, the same information element carries the freshness handle applicable to Streaming Remote Attestation, as described in and .
• attEnvIDs is represented by TpmName, a TPM "name" text string selected from the tpms Container, as specified in
• claimsSelection is substituted with PcrSelection, an optional "pcr-index" from either the tpm12-challenge-response-attestation RPC or the tpm20-challenge-response-attestation RPC as specified in . For these challenge-response RPCs, if none of the TPM's Platform Configuration Registers (PCR) are selected, all PCR banks are returned. This behavior does not apply to subscriptions: an <establish-subscription> to the <attestation> Event Stream MUST include at least one <pcr-index> (see ).
• claims is substituted with PcrQuotes, which is the "output" of either the tpm12-challenge-response-attestation RPC or the tpm20-challenge-response-attestation RPC, as specified in . Unlike event logs, there is no delta to a previous iteration of PCR Quotes during a subscription; all new (selected) Quotes are conveyed as fresh Evidence.
• eventLogs represents "system-event-logs" that are in the "output" of the log-retrieval RPC, as defined in .
• eventLogsDelta represents "system-event-logs" as specified in the "output" of the log-retrieval RPC as defined in where the "output" is limited as if the "input" were parameterized via an index type (last-entry, index, timestamp) set to the last event in the previously conveyed eventLogs.

YANG Subscription Model for Remote Attestation | | | | | | | ===============[Evidence Generation and Conveyance]================= | | | | | | generateClaims(attestingEnvironment) | | | | => PcrQuotes, eventLogs | | | | | | | collectClaims(PcrQuotes, ?PcrSelection) | | | | => collectedClaims | | | | | | | generateEvidence(nonce, TpmName, collectedClaims) | | | | => evidence | | | | | | | | {evidence, eventLogs} ------------------------------------>| | | | | | | ========================[Evidence Appraisal]======================== | | | | | | | appraiseEvidence(evidence, | | | eventLogs, | | | verInputs) | | | attestationResult <= | | | ~ ~ | | | | | | .--------[loop]----------------------------------------------------. | || | | || || ============[Delta Evidence Generation and Conveyance]============ || || | | || || generateClaims(attestingEnvironment) | || || | => PcrQuotes, eventLogsDelta | || || | | || || collectClaims(PcrQuotes, ?PcrSelection) | || || | => collectedClaimsDelta | || || | | || || generateEvidence(nonce, TpmName, collectedClaimsDelta) | || || | => evidence | || || | | || || | {evidence, eventLogsDelta} ------------------------------->| || || | | || || ====================[Delta Evidence Appraisal]==================== || || | | || || | appraiseEvidence(evidence, || || | eventLogsDelta, || || | verInputs) || || | attestationResult <= | || || | | || | '------------------------------------------------------------------' | '--------------------------------------------------------------------' | | ]]>

Time Considerations Mapping defines "Relevant Events over Time" in RATS which also provides the input for Figure 3 of . The following sequence diagram focuses on matching the defined events with the interactions between the Attester and the Verifying Relying Party. The action of conveying "collectClaims", which is defined in , is not defined by . As a result, that action cannot be matched to a specified event time.

YANG Subscription Model for Remote Attestation PcrQuotes, eventLogs | | | |<---------establish-subscription()------time(NS) | | collectClaims(PcrQuotes, ?PcrSelection) | | => collectedClaims | | | time(EG) | generateEvidence(nonce, PcrSelection, collectedClaims) | | => SignedPcrEvidence(nonce, PcrSelection) | | => LogEvidence(collectedClaims) | | | |--filter()---------------------------------->| |-- or ------------>| |----------------------------------------->| | | | time(RG,RA) | appraiseEvidence(evidence, | eventLogs, | verInputs) | attestationResult <= | ~ ~ time(VG') | generateClaims(attestingEnvironment) | | => PcrQuotes, eventLogsDelta | | | collectClaims(PcrQuotes, ?PcrSelection) | | => collectedClaimsDelta | | | time(EG') | generateEvidence(nonce, TpmName, collectedClaimsDelta) | | => evidence | | | |--filter()---------------------------------->| |-- or ------------>| |----------------------------------------->| | | | time(RG,RA) | appraiseEvidence(evidence, | eventLogs, | verInputs) | attestationResult <= | | | ]]>

• time(VG,RG,RA) are identical to the corresponding time definitions from .
• time(VG',RG',RA') are subsequent instances of the corresponding times from Figure 3 in .
• time(NS) – the subscriber generates a nonce and makes an <establish-subscription> request based on that nonce value. This request also includes the augmentations defined in this document's YANG model. Key subscription RPC parameters include:
  • the nonce,
  • a set of PCRs of interest which the Verifier wants to be appraised, and
  • an optional filter that can reduce the logged events on the <attestation> stream pushed to the Verifier.
• time(EG) – an initial response of Evidence is returned to the Verifier. This includes:
  • a replay of filtered log entries, which have extended into a PCR of interest since boot, are sent in the <pcr-extend> notification, and
  • a signed TPM quote that contains at least the PCRs from the <establish-subscription> RPC are included in a <tpm12-attestation> or <tpm20-attestation>). This quote must have been generated based on the nonce value provided at time(NS).
• time(VG',EG') – this occurs when a PCR is extended after time(EG). Immediately after the extension, the following information needs to be pushed to the Verifier:
  • any values extended into a PCR of interest,
  • a signed TPM Quote showing the result the PCR extension, and
  • a nonce value (see 'handle' above or ), which is either the initially received nonce or a more recently received nonce value, for example, a nonce value extracted or derived from an Epoch ID (see ) that contains a new nonce value or equivalent qualified data used as a nonce value.

One way to acquire a new time synchronisation that allows for the reuse of the initially received nonce as a fresh handle is elaborated on in below.

Continuously Verifying Freshness As there is no new Verifier nonce provided at time(EG'), it is important to validate the freshness of TPM Quotes which are delivered at that time. Methods of doing this verification vary based on the capabilities of the TPM cryptoprocessor used.

TPM 1.2 Quote The notification format includes the <eventTime> object. This can be used to determine the amount of time after the initial subscription each notification was sent. However, this time is not returned as part of the signed results of the TPM Quote and therefore is not as trustworthy as the objects included in the TPM Quote. Therefore, a Verifier MUST obtain a TPM Quote containing a new Verifier-provided nonce at an interval no longer than the maximum Evidence age permitted by its Appraisal Policy. Selecting that interval is a Verifier policy decision; it is independent of <tpm20-subscription-heartbeat>, which bounds how often notifications are sent but does not itself provide freshness. A fresh nonce can be obtained using the <tpm12-challenge-response-attestation> RPC from .

TPM 2 Quote When the Attester includes a TPM2-compliant cryptoprocessor, internal time-related counters are included within the signed TPM Quote and thereby are trustworthy. By including an initial nonce in the subscription request, fresh values for these counters are pushed to the Verifier as part of the first TPM Quote. In order to assess the freshness of the TPM Quotes that the Attester continuously generates over time, the Verifier can acquire separate TPM Quotes via the <tpm20-challenge-response-attestation> RPC from out-of-band. These separate TPM Quotes include fresh time-related counters that can be appraised for freshness based on the predictable incrementing of these time-related counters. An example for how that can be realized is illustrated in . The relevant internal time-related counters defined within can be seen within <tpms-clock-info>. These counters include the <clock>, <reset-counter>, and <restart-counter> objects. The rules for appraising these objects are as follows:

• If the <clock> has incremented for no more than the same duration as both the <eventTime> and the Verifier's internal time since the initial time(EG) and any previous time(EG'), then the TPM Quote is considered fresh. Note that allows for +/- 15% clock drift. However, many hardware implementations significantly improve on this maximum drift. If available, chip specific maximum drifts MUST be considered during the appraisal procedure of the Verifier.
• If either the <reset-counter> or <restart-counter> has incremented, the existing subscription MUST be terminated. If the Verifier intends to continue receiving attestation Evidence, it MUST establish a new subscription.
• If a TPM Quote on any subscribed PCR has not been pushed to the Verifier for the Attester-defined heartbeat interval, a new TPM Quote notification containing that PCR MUST be sent to the Verifier.

------------------------------>| | : | ~ Heartbeat interval ~ | : | time(EG') : | |------------------------------->| | | ]]>

Remote Attestation Event Stream The <attestation> Event Stream is an compliant Event Stream which is defined within this section and within the YANG Module of . This Event Stream contains YANG notifications which carry Evidence to assist a Verifier in appraising the Trustworthiness Level of an Attester. Data Nodes within allow the configuration of this Event Stream's contents on an Attester. This <attestation> Event Stream can only be exposed on Attesters supporting . As with , it is up to the Verifier to understand which types of cryptoprocessors and keys are acceptable.

Subscription to the <attestation> Event Stream To establish a subscription to an Attester in a way which provides provably fresh Evidence, initial randomness must be provided to the Attester. This is done via the augmentation of a <nonce-value> into 's <establish-subscription> RPC. Additionally, a Verifier must ask for PCRs of interest from a platform. The result of the subscription will be the passing of the following information:

1. <tpm12-attestation> and <tpm20-attestation> notifications which include the provided <nonce-value>. These attestation notifications MUST at least include every <pcr-index> as requested in the RPC.
2. a series of <pcr-extend> notifications which reference the requested PCRs on all TPM based cryptoprocessors on the Attester.
3. <tpm12-attestation> and <tpm20-attestation> notifications generated within a few seconds of the <pcr-extend> notifications. These attestation notifications MUST at least include any PCRs extended.

If the Verifier does not want to see the logged extend operations for all PCRs available from an Attester, an Event Stream Filter should be applied. This filter will remove Evidence from any PCRs which are not interesting to the Verifier.

Replaying a History of Previous TPM Extend Operations Unless it is relying on Reference Values for TPM Quotes only, a Verifier will need to acquire a history of PCR extensions since the Attester has been booted. This history may be requested from the Attester as part of the <establish-subscription> RPC. This request is accomplished by placing a very old <replay-start-time> within the original RPC request. As the very old <replay-start-time> will pre-date the time of Attester boot, a <replay-start-time-revision> will be returned in the <establish-subscription> RPC response, indicating when the Attester booted. Immediately following the response (and before the notifications above) one or more <pcr-extend> notifications which document all extend operations which have occurred for the requested PCRs since boot will be sent. Multiple extend operations to a single PCR index on a single TPM can be included within a single notification. Note that if a Verifier has a partial history of extensions, the <replay-start-time> can be adjusted so that already known extensions are not forwarded. The end of this history replay will be indicated with the <replay-completed> notification. For more on this sequence, see Section 2.4.2.1 of . After the <replay-completed> notification is provided, a TPM Quote will be requested and the result passed to the Verifier via a <tpm12-attestation> and <tpm20-attestation> notification. If there have been any additional extend operations which have changed a subscribed PCR value in this quote, these MUST be pushed to the Verifier before the <tpm12-attestation> and <tpm20-attestation> notification. At this point, the Verifier has sufficient Evidence to appraise the reported extend operations for each PCR, as well as to compare a Reference Value derived from the replay of the Event Log history of extensions of the PCR value against those extensions signed by the TPM in its most recent Quote.

TPM2 Heartbeat For TPM 2.0, when <tpm20-subscription-heartbeat> is configured, every requested PCR MUST be sent within an <tpm20-attestation> and no less frequent than once per heartbeat interval. This MAY be done with a single <tpm20-attestation> notification that includes all requested PCRs inside every heartbeat interval. This MAY be done with several <tpm20-attestation> notifications at different times during a heartbeat interval. When <tpm20-subscription-heartbeat> is not configured, <tpm20-attestation> notifications are only sent as a result of PCR extensions. The heartbeat interval is configured on the Attester for the <attestation> Event Stream (see ), not per subscription, and applies independently to each TPM on the Attester.

YANG Notifications Placed on the <attestation> Event Stream

pcr-extend This notification type documents when a subscribed PCR is extended within a single TPM cryptoprocessor. It MUST be emitted no later than the <marshalling-period> after the PCR is first extended, except when the marshalling period is extended as described below. (The reason for the marshalling is that it is quite possible that multiple extensions to the same PCR have been made in quick succession, and these should be reflected in the same notification.) This notification MUST be emitted prior to a <tpm12-attestation> or <tpm20-attestation> notification which has included and signed the results of any specific PCR extension. If PCR extending events occur during the generation of the <tpm12-attestation> or <tpm20-attestation> notification, the marshalling period MUST be extended so that a new <pcr-extend> is not sent until the corresponding notifications have been sent. Each <pcr-extend> MUST include one or more values being extended into the PCR. These are passed within the <extended-with> object. For each extension, details of the event SHOULD be provided within the <event-details> object. The format of any included <event-details> is identified by the <event-type>. This document includes two YANG structures which may be inserted into the <event-details>. These two structures are: <ima-event-log> and <bios-event-log>. Implementations wanting to provide additional documentation of a type of PCR extension may choose to define additional YANG structures which can be placed into <event-details>.

tpm12-attestation This notification contains an instance of a TPM1.2 style signed cryptoprocessor measurement. It is supplemented by Attester information which is not signed. This notification is generated and emitted from an Attester when at least one PCR identified within the subscribed selections of <pcr-index> has changed from the previous <tpm12-attestation> notification. This notification MUST NOT include the results of any PCR extensions not previously reported by a <pcr-extend>. This notification MUST be emitted as soon as a TPM Quote containing the latest PCR hashed values is available, and MUST be emitted prior to a subsequent <pcr-extend>. All YANG objects above are defined within . The <tpm12-attestation> is not replayable.

tpm20-attestation This notification contains an instance of TPM2 style signed cryptoprocessor measurements. It is supplemented by Attester information which is not signed. This notification is generated at two points in time:

• every time at least one PCR has changed from a previous <tpm20-attestation>. In this case, the notification SHOULD be emitted within 10 seconds of the corresponding <pcr-extend> being sent. The 10-second interval is fixed by this specification and is not a configurable parameter.
• after a locally configurable minimum heartbeat period since a previous <tpm20-attestation> was sent.

All YANG objects above are defined within . The <tpm20-attestation> is not replayable.

Filtering Evidence at the Attester It can be useful not to receive all Evidence related to a PCR. An example of this is when a Verifier maintains Reference Values (known good values) of a PCR. In this case, it is not necessary to send a log of each consecutive extend operation. To accomplish this reduction, when an RFC8639 <establish-subscription> RPC is sent, a <stream-filter> as per RFC8639, Section 2.2 can be set to discard a <pcr-extend> notification when the <pcr-index-changed> is uninteresting to the verifier.

Replaying Previous PCR Extend Events To verify the value of a PCR, a Verifier must either know that the value is a "known good" value (see Section 2.3.3 of about Reference Values) or be able to reconstruct the hash value by viewing all the PCR-Extends since the Attester rebooted. Wherever a hash reconstruction might be needed, the <attestation> Event Stream MUST support the RFC8639 <replay> feature. Through the <replay> feature, it is possible for a Verifier to retrieve and sequentially hash all of the PCR extending events since an Attester booted. Thereby, the Verifier has access to all the Evidence needed to verify a PCR's current value.

Configuring the <attestation> Event Stream is a tree diagram which exposes the operator configurable elements of the <attestation> Event Stream. This allows an Attester to select what information should be available on the stream. A fetch operation also allows an external device such as a Verifier to understand the current configuration of the stream. Almost all YANG objects below are defined via reference from . However, there is one object which is new in this model. <tpm2-heartbeat> defines the maximum amount of time which should pass before a subscriber to the Event Stream should get a <tpm20-attestation> notification from devices which contain a TPM2.

Configuring the \<attestation\> Event Stream ../tpm:attester-supported-algos/tpm12-asymmetric-signing | {taa:TPM12}? +--rw tras:tpm20-subscribed-signature-scheme? | -> ../tpm:attester-supported-algos/tpm20-asymmetric-signing | {taa:TPM20}? +--rw tras:tpm20-subscription-heartbeat? uint16 {taa:TPM20}? augment /tpm:rats-support-structures/tpm:tpms: +--rw tras:subscription-aik? tpm:certificate-name-ref +--rw (tras:subscribable)? +--:(tras:tpm12-stream) {taa:tpm12}? | +--rw tras:tpm12-hash-algo? identityref | +--rw tras:tpm12-pcr-index* tpm:pcr +--:(tras:tpm20-stream) {taa:tpm20}? +--rw tras:tpm20-hash-algo? identityref +--rw tras:tpm20-pcr-index* tpm:pcr ]]>

YANG Module This YANG module imports modules from and . RFC Editor: Please replace "XXXX" in the YANG module with the RFC number assigned to this document, update the revision date to the publication date, and remove this note. ietf-tpm-remote-attestation-stream@2026-10-28.yang module ietf-tpm-remote-attestation-stream { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream"; prefix tras; import ietf-subscribed-notifications { prefix sn; reference "RFC 8639: Subscription to YANG Notifications"; } import ietf-tpm-remote-attestation { prefix tpm; reference "RFC 9684: A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)"; } import ietf-tcg-algs { prefix taa; reference "RFC 9684: A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)"; } organization "IETF RATS (Remote ATtestation procedureS) Working Group"; contact "WG Web: WG List: Editor: Eric Voit "; description "This module contains YANG specification for subscribing to attestation streams which contain events that have been generated by TPM chips or equivalent hardware implementations that include the protected capabilities as provided by TPMs. Copyright (c) 2026 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 Revised 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). All published revisions of IETF and IANA YANG modules are available from the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters). 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."; revision 2026-10-28 { description "Initial Version"; reference "RFC XXXX: Attestation Event Stream Subscription. RFC Editor: Please replace XXXX with the RFC number assigned to this document."; } /* * IDENTITIES */ identity pcr-unsubscribable { base sn:establish-subscription-error; description "Requested PCR is unsubscribable by the Attester."; } /* * Groupings */ grouping heartbeat { description "Allows an Attester to push verifiable, current TPM PCR values even when there have been no recent changes to PCRs."; leaf tpm20-subscription-heartbeat { type uint16 { range "1..max"; } units "seconds"; description "Maximum number of seconds between tpm20-attestation notifications for each requested PCR. This platform-wide setting applies to all active TPM 2.0 attestation subscriptions. When this leaf is configured, the Attester sends each requested PCR at least once per interval, including when its value has not changed."; } } /* * RPCs */ augment "/sn:establish-subscription/sn:input" { when 'sn:stream = "attestation"'; description "This augmentation adds a nonce to the subscription parameters that apply specifically to datastore updates to RPC input."; uses tpm:nonce; leaf-list pcr-index { type tpm:pcr; min-elements 1; description "The numbers/indexes of the PCRs. This will act as a filter for the subscription so that 'tpm-extend' notifications related to non-requested PCRs will not be sent to a subscriber."; } } /* * NOTIFICATIONS */ notification pcr-extend { description "This notification indicates that one or more PCRs have been extended within a TPM based cryptoprocessor. In less than the 'marshalling-period', it MUST be followed with either a corresponding tpm12-attestation or tpm20-attestation notification which exposes the result of the PCRs updated."; uses tpm:certificate-name-ref; leaf-list pcr-index-changed { type tpm:pcr; min-elements 1; description "The number of each PCR extended. This list MUST contain the set of PCRs descibed within the event log details. This leaf can be derived from the list of attested events, but exposing it here allows for easy filtering of the notifications of interest to a verifier."; } list attested-event { description "A set of events which extended an Attester PCR. The sequence of elements represented in list must match the sequence of events placed into the TPM's PCR."; container attested-event { description "An instance of an event which extended an Attester PCR"; leaf extended-with { type binary; mandatory true; description "Information extending the PCR."; } choice event-details { description "Contains the event happened the Attester thought was worthy of recording in a PCR. choices are of types defined by the identityref base tpm:attested_event_log_type"; case bios-event-log { if-feature "tpm:bios"; description "BIOS/UEFI event log format"; uses tpm:bios-event-log; } case ima-event-log { if-feature "tpm:ima"; description "IMA event log format"; uses tpm:ima-event-log; } case netequip-boot-event-log { if-feature "tpm:netequip_boot"; description "Network equipment boot event log format"; uses tpm:network-equipment-boot-event-log; } } } } } notification tpm12-attestation { if-feature "taa:tpm12"; description "Contains an instance of TPM1.2 style signed cryptoprocessor measurements. It is supplemented by unsigned Attester information."; leaf certificate-name { type tpm:certificate-name-ref; mandatory true; description "Allows a TPM quote to be associated with a certificate."; } uses tpm:tpm12-attestation; uses tpm:tpm12-hash-algo; list unsigned-pcr-values { description "Allows notifications to be filtered by PCR number or PCR value using XPath expressions as defined in Section 6.4 of RFC 7950. Exposing these values as separate YANG nodes permits filtering without inspecting the TPM-encoded attestation structures defined in RFC 9684."; reference "RFC 7950: The YANG 1.1 Data Modeling Language, Section 6.4; RFC 9684: A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)."; leaf-list pcr-index { type tpm:pcr; min-elements 1; description "PCR index numbers. The producer MUST provide the same number of entries in this leaf-list and the sibling 'pcr-value' leaf-list. Entry N corresponds to entry N in 'pcr-value', following the TPM 1.2 PCR selection/value ordering."; } leaf-list pcr-value { type binary; description "PCR values. The producer MUST provide the same number of entries in this leaf-list and the sibling 'pcr-index' leaf-list. Entry N corresponds to the PCR identified by entry N in 'pcr-index'."; } } } notification tpm20-attestation { if-feature "taa:tpm20"; description "Contains an instance of TPM2 style signed cryptoprocessor measurements. It is supplemented by unsigned Attester information."; leaf certificate-name { type tpm:certificate-name-ref; mandatory true; description "Allows a TPM quote to be associated with a certificate."; } uses tpm:tpm20-attestation { description "Provides the attestation information and exposes the unsigned PCR values as YANG nodes, allowing XPath filtering as described in Section 6.4 of RFC 7950."; reference "RFC 7950: The YANG 1.1 Data Modeling Language, Section 6.4."; refine unsigned-pcr-values { min-elements 1; } refine unsigned-pcr-values/pcr-values { min-elements 1; } } } /* * DATA NODES */ augment "/tpm:rats-support-structures" { description "Defines platform wide 'attestation' stream subscription parameters."; leaf marshalling-period { type uint8; units "seconds"; default 5; description "The maximum number of seconds between the time an event extends a PCR, and the 'tpm-extend' notification which reports it to a subscribed Verifier. This period allows multiple extend operations bundled together and handled as a group."; reference "Section 4.3.1 of RFC XXXX."; } leaf tpm12-subscribed-signature-scheme { if-feature "taa:tpm12"; type leafref { path "../tpm:attester-supported-algos" + "/tpm:tpm12-asymmetric-signing"; } description "A single signature-scheme which will be used to sign the evidence from a TPM 1.2. which is then placed onto the 'attestation' event stream."; } leaf tpm20-subscribed-signature-scheme { if-feature "taa:tpm20"; type leafref { path "../tpm:attester-supported-algos" + "/tpm:tpm20-asymmetric-signing"; } description "A single signature-scheme which will be used to sign the evidence from a TPM 2.0. which is then placed onto the 'attestation' event stream."; } uses heartbeat{ if-feature "taa:tpm20"; } } augment "/tpm:rats-support-structures/tpm:tpms" { description "Allows the configuration 'attestation' stream parameters for a TPM."; leaf subscription-aik { type tpm:certificate-name-ref; description "Identifies the certificate-name associated with the notifications in the 'attestation' stream."; } choice subscribable { description "Indicates that the set of notifications which comprise the 'attestation' event stream can be modified or tuned by a network administrator."; case tpm12-stream { if-feature "taa:tpm12"; description "Configuration elements for a TPM1.2 event stream."; uses tpm:tpm12-hash-algo; leaf-list tpm12-pcr-index { type tpm:pcr; description "The numbers/indexes of the PCRs which can be subscribed."; } } case tpm20-stream { if-feature "taa:tpm20"; description "Configuration elements for a TPM2.0 event stream."; uses tpm:tpm20-hash-algo; leaf-list tpm20-pcr-index { type tpm:pcr; description "The numbers/indexes of the PCRs which can be subscribed."; } } } } } ]]>

Event Streams for Conceptual Messages Analogous to the -compliant <attestation> Event Stream defined in , additional Event Streams can be defined for other RATS Conceptual Messages. Any specification that uses this framework to define an additional RATS Conceptual Message Event Stream MUST define that Event Stream using a YANG module that augments the module defined in this document. The augmentation MAY define the Event Stream content using YANG-modelled notifications or identify the content format used for non-YANG-modelled data.

Privacy Considerations The privacy considerations of (Remote Integrity Verification of Network Devices Containing Trusted Platform Modules) apply. Additionally, the security considerations from (Subscription to YANG Notifications for Datastore Updates) how information about the system's internal structures or capabilities can be leaked, which could impact personally identifiable information (PII), apply. There are no additional privacy considerations introduced by this document.

Security Considerations

Remote ATttestation procedureS (RATS) The security considerations of and apply.

Yet Another Next Generation (YANG) The security requirements and security considerations of (Sections 4.2.5 and 5, respectively) apply. Subscription to YANG Notifications for Datastore Updates () illustrates specific security considerations concerning YANG Notifications for Datastore Updates. For example, it provides guidance on identifying sensitive writable subtrees and sensitive readable nodes.

YANG Management Security The ietf-tpm-remote-attestation-stream YANG module is intended to be accessed using YANG-based management protocols such as NETCONF and RESTCONF . Management access to the module needs to provide confidentiality, integrity protection, and mutual authentication. The Network Configuration Access Control Model (NACM) can be used to restrict access to the configuration, operations, and notification content defined or augmented by this module. The writable data nodes introduced by this module include <marshalling-period>, <tpm12-subscribed-signature-scheme>, <tpm20-subscribed-signature-scheme>, <tpm20-subscription-heartbeat>, <subscription-aik>, <tpm12-pcr-index>, and <tpm20-pcr-index>. Unauthorized modification of these nodes could alter which Evidence is available, the rate at which Evidence is delivered, or the keys and algorithms associated with attestation. Write access to these nodes therefore needs to be restricted to authorized administrators. The <pcr-extend>, <tpm12-attestation>, and <tpm20-attestation> notifications can expose integrity measurements, PCR values, Event Log information, and details of the Attester's hardware and software state. This information can reveal security-relevant platform configuration. Read and subscription access to these notifications therefore needs to be restricted to authorized Verifiers and other authorized consumers. The augmentation to the <establish-subscription> RPC creates long-lived subscription state and can cause continuing TPM operations and notification traffic. Unauthorized or excessive subscription requests can therefore consume processing, TPM, memory, and network resources. Implementations need to authenticate and authorize subscription requests and should apply appropriate resource limits. This security analysis follows the YANG security guidance in .

Security Considerations of Streaming Attestation Moving from request/response polling to a long-lived subscription changes the consequences of lost, delayed, or suppressed messages. In particular, the absence of a new notification is not Evidence that the Attester's state has remained unchanged. If a Verifier does not receive a required attestation notification or heartbeat within the interval required by this specification, the Verifier can no longer establish freshness using that expected notification. The Verifier needs to obtain fresh Evidence, for example through a new TPM Quote or a newly established subscription, before treating subsequent appraisal results as fresh. An attacker that can cause repeated measured events can also increase the rate of <pcr-extend> and attestation notifications. This can increase processing and network load at both the Attester and Verifier. Existing authorization, transport-security, and resource-management protections therefore remain important even when an attacker cannot forge TPM-signed Evidence. The security considerations of , , , and the YANG modules reused by this specification also apply.

IANA Considerations This document registers the following namespace URIs in the as per :

URI:

urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream

Registrant Contact:

The IESG.

XML:

N/A; the requested URI is an XML namespace.

This document registers the following YANG module in the registry as per Section 14 of :

Name:

ietf-tpm-remote-attestation-stream

Namespace:

urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream

Prefix:

tras

Reference:

draft-ietf-rats-network-device-subscription (RFC form)

References Normative References This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. 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. This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules (TPMs), as defined by the Trusted Computing Group (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. This document defines the YANG Remote Procedure Calls (RPCs) and configuration nodes that are required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in RFC 9683 "TPM-based Network Device Remote Integrity Verification". Complementary measurement logs originating from one or more Roots of Trust for Measurement (RTMs) are also provided by the YANG RPCs. The defined module requires the inclusion of the following in the device components of the composite device on which the YANG server is running: at least one Trusted Platform Module (TPM) of either version 1.2 or 2.0 as well as a corresponding TPM Software Stack (TSS), or an equivalent hardware implementation that includes the protected capabilities as provided by TPMs as well as a corresponding software stack. Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules. TCG n.d. 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. 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. Informative References This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Network Configuration Protocol (NETCONF) and RESTCONF). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. Fraunhofer Institute for Secure Information Technology Fraunhofer Institute for Secure Information Technology High North Inc Universität Bremen TZI This document defines the method and bindings used to convey Evidence via Time-based Uni-Directional Attestation (TUDA) in Remote ATtestation procedureS (RATS). TUDA does not require a challenge- response handshake and thereby does not rely on the conveyance of a nonce to prove freshness of remote attestation Evidence. TUDA enables the creation of Secure Audit Logs that can constitute believable Evidence about both current and past operational states of an Attester. In TUDA, RATS entities require access to a Handle Distributor to which a trustable and synchronized time-source is available. The Handle Distributor takes on the role of a Time Stamp Authority (TSA) to distribute Handles incorporating Time Stamp Tokens (TST) to the RATS entities. RATS require an Attesting Environment that generates believable Evidence. While a TPM is used as the corresponding root of trust in this specification, any other type of root of trust can be used with TUDA. TCG TCG n.d. n.d.

Acknowledgements Shout-out to Thomas Fossati, Zhuoyao Lin, Yogesh Deshpande, Jun Zhang, Thanassis Giannetsos, Michael Richardson, Ned Smith, and Chunchi (Peter) Liu for their extensive review feedback that was vital to produce this document.