1.1.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 inBCP 14[RFC2119][RFC8174] when, and only when, they appear in allcapitals, as shown here.¶

1.2.Terminology

A number of terms are reused from[RFC9334]. These include: Appraisal Policy for Evidence, Attestation Result, Attester, Evidence, Reference Value, Relying Party, Verifier, and Verifier Owner.¶

Additionally, this document defines the following term:¶

Attestation: the process of generating, conveying and appraisingclaims, backed by evidence, about device trustworthiness characteristics, including supply chain trust,identity, device provenance, software configuration, devicecomposition, compliance to test suites, functional and assurance evaluations, etc.¶

The goal of attestation is simply to assure an administrator or auditor that the device configuration and softwarethat was launched when the device was last started is authentic and untampered-with.The determination of software authenticity is not prescribed in this document, but it's typically taken to meana software image generated by an authority trusted by the administrator, such as the device manufacturer.¶

Within the Trusted Computing Group (TCG) context, the scope of attestation is typically narrowed to describe the process bywhich an independent Verifier can obtain cryptographic proof as to the identityof the device in question, and evidence of the integrity of software loaded onthat device when it started up, and then verify that what's there matches the intended configuration. For network equipment, a Verifier capability canbe embedded in a Network Management Station (NMS), a posture collection server,or other network analytics tool (such as a software asset management solution,or a threat detection and mitigation tool, etc.). While informally referredto as attestation, this document focuses on a specific subset of attestation tasks, defined here as RemoteIntegrity Verification (RIV). RIV in this document takes a network-equipment-centric perspectivethat includes a set of protocols and procedures for determining whether aparticular device was launched with authentic software, starting from Rootsof Trust. While there are many ways to accomplish attestation, RIV setsout a specific set of protocols and tools that work in environments commonlyfound in network equipment. RIV does not cover other device characteristicsthat could be attested (e.g., geographic location, connectivity; see[RATS-USECASES]), although it does provide evidence of a secure infrastructureto increase the level of trust in other device characteristics attestedby other means (e.g., by Entity Attestation Tokens[RATS-EAT]).¶

In line with[RFC9334] definitions, this document uses the term Endorser to refer to the role that signs identity and attestation certificates used by the Attester, while Reference Values are signed by a Reference Value Provider. Typically, the manufacturer of a network device would be accepted as both the Endorser and Reference Value Provider, although the choice is ultimately up to the Verifier Owner.¶

1.3.Document Organization

The remainder of this document is organized into several sections:¶

• The remainder of this section covers goals and requirements, plus a top-level description of RIV.¶
• The Solution Overview section outlines how Remote Integrity Verification works.¶
• The Standards Components section links components of RIV to normative standards.¶
• Privacy and Security shows how specific features of RIV contribute to the trustworthiness of the Attestation Result.¶
• Supporting material is in an appendix at the end.¶

1.4.Goals

Network operators benefit from a trustworthy attestation mechanism that providesassurance that their network comprises authentic equipment, and has loaded softwarefree of known vulnerabilities and unauthorized tampering. In line with the overall goal of assuring integrity, attestation can be used to assist in asset management, vulnerability and complianceassessment, plus configuration management.¶

The RIV attestation workflow outlined in this document is intended to meet the following high-level goals:¶

• Provable Device Identity - This specification requires that an Attester (i.e., the attesting device) includesa cryptographic identifier unique to each device. Effectively this means that the device's TPMmust be so provisioned during the manufacturing cycle.¶
• Software Inventory - A key goal is to identify the software release(s) installedon the Attester, and to provide evidence that the software stored within hasn'tbeen altered without authorization.¶
• Verifiability - Verification of software and configuration of the device showsthat the software that the administrator authorized for use was actually launched.¶

In addition, RIV is designed to operate either in a centralized environment, such as with a central authority that manages and configures a number of network devices, or 'peer-to-peer', where network devices independently verify one another to establish a trust relationship. (SeeSection 3.3 below)¶

1.5.Description of Remote Integrity Verification (RIV)

Attestation requires two interlocking mechanisms between the Attester network device and the Verifier:¶

• Device Identity, the mechanism providing trusted identity, can reassure networkmanagers that the specific devices they ordered from authorized manufacturers forattachment to their network are those that were installed, and that they continue tobe present in their network. As part of the mechanism for Device Identity,cryptographic proof of the identity of the manufacturer is also provided.¶
• Software Measurement is the mechanism that reports the state of mutable software componentson the device, and can assure administrators that they have known, authenticsoftware configured to run in their network.¶

Using these two interlocking mechanisms, RIV is a component in a chain of procedures that can assure a network operator that the equipment intheir network can be reliably identified, and that authentic software ofa known version is installed on each device. Equipment in the network includesdevices that make up the network itself, such as routers, switches and firewalls.¶

Software used to boot a device can be identified by a chainof measurements, anchored at the start by a Root of Trust for Measurement (seeSection 9.2), each measuring the next stage and recording the result in tamper-resistant storage,normally ending when the system software is fully loaded.A measurement signifies the identity, integrity and version of eachsoftware component registered with an Attester's TPM[TPM1.2],[TPM2.0], so that asubsequent verification stage can determine if the softwareinstalled is authentic, up-to-date, and free of tampering.¶

RIV includes several major processes, split between the Attester and Verifier:¶

1. Generation of Evidence is the process whereby an Attester generates cryptographicproof (Evidence) of claims about device properties. In particular, thedevice identity and its software configuration are both of critical importance.¶
2. Device Identification refers to the mechanism assuring theRelying Party (ultimately, a network administrator) of the identity of devices that make up their network,and that their manufacturers are known.¶
3. Conveyance of Evidence reliably transports the collected Evidence from Attester to a Verifier to allow a management station to perform a meaningful appraisal in Step 4. The transport is typically carried out via a management network. While not required for reliable attestation, an encrypted channel may be used to provide integrity, authenticity, or confidentiality once attestation is complete. It should be noted that critical attestation evidence from the TPM is signed by a key known only to TPM, and is not dependent on encyption carried out as part of a reliable transport.¶
4. Finally, Appraisal of Evidence occurs. This is the process of verifying the Evidence received by a Verifier from the Attester, and using an Appraisal Policy to develop an Attestation Result, used to inform decision-making. In practice, this means comparing the Attester's measurements reported as Evidence with the device configuration expected by the Verifier. Subsequently, the Appraisal Policy for Evidence might match Evidence found against Reference Values (aka Golden Measurements), which represent the intended configured state of the connected device.¶

All implementations supporting this RIV specification require the support of the following three technologies:¶

1. Identity: Device identity in RIV is based on IEEE 802.1AR Device Identity (DevID)[IEEE-802-1AR],coupled with careful supply-chain management by the manufacturer. TheInitial DevID (IDevID) certificate contains a statement by the manufacturer that establishesthe identity of the device as it left the factory. Some applications witha more-complex post-manufacture supply chain (e.g., Value Added Resellers),or with different privacy concerns, may want to use alternative mechanisms for platformauthentication (for example, TCG Platform Certificates[Platform-Certificates], or post-manufacture installation of Local Device ID (LDevID)).¶
2. Platform Attestation provides evidence of configuration of software elementspresent in the device. This form of attestation can be implementedwith TPM Platform Configuration Registers (PCRs), Quote and Log mechanisms, which provide cryptographically authenticated evidenceto report what software was started on the device through the boot cycle. Successful attestation requires an unbroken chain from a boot-time root of trust through all layers of software needed to bring the device to an operational state, in which each stage computes the hash of components of the next stage, then updates the attestation log and the TPM. The TPM can then report the hashes of all the measured hashes as signed evidence called a Quote (seeSection 9.1 for an overview of TPM operation, or[TPM1.2] and[TPM2.0] for many more details).¶
3. Signed Reference Values (aka Reference Integrity Measurements) must be conveyed from the Reference Value Provider (the entity accepted as the software authority,often the manufacturer of the network device) to the Verifier.¶

1.6.Solution Requirements

Remote Integrity Verification must address the "Lying Endpoint"problem, in which malicious software on an endpoint may subvert theintended function, and also prevent the endpoint from reporting its compromisedstatus. (SeeSection 5 for further Security Considerations.)¶

RIV attestation is designed to be simpleto deploy at scale. RIV should work "out of the box" as far as possible,that is, with the fewest possible provisioning steps or configuration databasesneeded at the end-user's site. Network equipment is often required to "self-configure",to reliably reach out without manual intervention to prove its identity andoperating posture, then download its own configuration, a process which precludes pre-installation configuration. See[RFC8572] for anexample of Secure Zero Touch Provisioning.¶

1.7.Scope

The need for assurance of software integrity, addressed by Remote Attestation, is a very general problem that could apply to most network-connected computing devices. However, this document includes several assumptions that limit the scope to network equipment (e.g., routers, switches and firewalls):¶

• This solution is for use in non-privacy-preserving applications (for example,networking, Industrial IoT), avoiding the need for a Privacy CertificateAuthority (also called an Attestation CA) for attestation keys[AK-Enrollment] or TCG PlatformCertificates[Platform-Certificates].¶
• This document assumes network protocols that are common in network equipment such as YANG[RFC7950] and NETCONF[RFC6241],but not generally used in other applications.¶
• The approach outlined in this document mandates the use of a TPM[TPM1.2],[TPM2.0], or a compatible cryptoprocessor.¶

2.1.RIV Software Configuration Attestation using TPM

RIV Attestation is a process which can be used to determine the identity of software runningon a specifically-identified device. The Remote Attestation steps ofSection 1.5 are broken into twophases, shown in Figure 1:¶

• During system startup, or boot phase, each distinct software object is "measured" by the Attester.The object's identity, hash (i.e., cryptographic digest) and version information are recorded in a log.Hashes are also extended into the TPM (seeSection 9.1 for more on 'extending hashes'), in a way that can be used to validate the log entries. The measurement process generallyfollows the layered chain-of-trust model used in Measured Boot, where each stageof the system measures the next one, and extends its measurement into the TPM,before launching it. SeeSection 3.2 of [RFC9334],"Layered Attestation Environments," for an architectural definitionof this model.¶
• Once the device is running and has operational network connectivity, verification can take place. A separate Verifier, running in its own trusted environment, will interrogate the networkdevice to retrieve the logs and a copy of the digests collected by hashingeach software object, signed by an attestation private key secured by, but never released by,the TPM. The YANG model described in[RFCYYY1] facilitates this operation.¶

The result is that the Verifier can verify the device's identity by checkingthe subject[RFC5280] and signature of the certificate containing the TPM's attestation public key, and canvalidate the software that was launched by verifying the correctness of the logs by comparing with thesigned digests from the TPM, and comparing digests in the log withReference Values.¶

It should be noted that attestation and identity are inextricably linked;signed Evidence that a particular version of software was loaded is of littlevalue without cryptographic proof of the identity of the Attester producingthe Evidence.¶

    +-------------------------------------------------------+    | +---------+    +--------+   +--------+    +---------+ |    | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |    | +---------+    +--------+   +--------+    +---------+ |    |     |            |           |                        |    |     |            |           |                        |    |     +------------+-----------+-+                      |    |                    Boot Phase  |                      |    |                                V                      |    |                            +--------+                 |    |                            |  TPM   |                 |    |                            +--------+                 |    |   Router                       |                      |    +--------------------------------|----------------------+                                     |                                     |  Verification Phase                                     |    +-----------+                                     +--->| Verifier  |                                          +-----------+    Reset---------------flow-of-time-during-boot...--------->

In the Boot phase, measurements are "extended", or hashed, into the TPM as processes start, with the result that the TPM ends up containing hashes of all the measured hashes. Later, once the system is operational, during the Verification phase, signed digests are retrieved from the TPM for off-box analysis.¶

2.2.RIV Keying

RIV attestation relies on two credentials:¶

• An identity key pair and matching certificate is required to certify the identity of the Attester itself.RIV specifies the use of an IEEE 802.1AR Device Identity (DevID)[IEEE-802-1AR],signed by the device manufacturer, containing the device serial number. This requirement goes slightlybeyond 802.1AR; seeSection 2.4 for notes.¶
• An Attestation key pair and matching certificate is required to sign the Quote generated by the TPM to report evidenceof software configuration.¶

In a TPM application, both the Attestation private key and the DevID private keyMUST be protected by the TPM.Depending on other TPM configuration procedures,the two keys are likely to be different; some of the considerations are outlined in TCG"TPM 2.0 Keys for Device Identity and Attestation"[Platform-DevID-TPM-2.0].¶

The TCG TPM 2.0 Keys document[Platform-DevID-TPM-2.0] specifies further conventions for these keys:¶

• When separate Identity and Attestation keys are used, the AttestationKey (AK) and its X.509 certificate should parallel the DevID, with the same uniquedevice identification as the DevID certificate (that is, the same subject and subjectAltName (if present), even though the key pairs are different). This allowsa quote from the device, signed by an AK, to be linked directly to thedevice that provided it, by examining the corresponding AK certificate. If thesubject in the AK certificate doesn't match the corresponding DevID certificate, or they're signed by differing authorities the Verifier may signal the detection of an Asokan-style person-in-the-middle attack (seeSection 5.2).¶
• Network devices that are expected to use secure zero touch provisioning asspecified in[RFC8572]MUST be shipped by the manufacturer with pre-provisioned keys (Initial DevID and Initial AK,called IDevID and IAK). IDevID and IAK certificatesMUST both be signed by the Endorser (typically the device manufacturer). Inclusion of an IDevID and IAK by a vendor does notpreclude a mechanism whereby an administrator can define Local Identity andAttestation Keys (LDevID and LAK) if desired.¶

2.3.RIV Information Flow

RIV workflow for network equipment is organized around a simple use casewhere a network operator wishes to verify the integrity of software installedin specific, fielded devices. A normative taxonomy of terms is given in[RFC9334], but as a reminder, this use case implies several roles and objects:¶

The Attester,

the device which the network operator wants to examine.¶

A Verifier (which might be a network management station)

somewhere separate from the Device that will retrieve the signed evidence and measurement logs, and analyze them to pass judgment on the security posture of the device.¶

A Relying Party,

which can act on Attestation Results. Interaction between the Relying Party and the Verifier is considered out of scope for RIV.¶

Signed Reference Integrity Manifests (RIMs),

containing Reference Values, can either be created by the device manufacturer and shipped along with the device as part of its software image, or alternatively, could be obtained several other ways (direct to the Verifier from the manufacturer, from a third party, from the owner's observation of what's thought to be a "known good system", etc.). Retrieving RIMs from the device itself allows attestation to be done in systems that may not have access to the public internet, or by other devices that are not management stations per se (e.g., a peer device; seeSection 3.1.3). If Reference Values are obtained from multiple sources, the Verifier may need to evaluate the relative level of trust to be placed in each source in case of a discrepancy.¶

These components are illustrated inFigure 2.¶

+----------------+        +-------------+        +---------+--------+|Reference Value |        | Attester    | Step 1 | Verifier|        ||Provider        |        | (Device     |<-------| (Network| Relying||(Device         |        | under       |------->| Mngmt   | Party  ||Manufacturer    |        | attestation)| Step 2 | Station)|        ||or other        |        |             |        |         |        ||authority)      |        |             |        |         |        |+----------------+        +-------------+        +---------+--------+       |                                             /\       |                  Step 0                      |       -----------------------------------------------

• In Step 0, The Reference Value Provider (the device manufacturer or other authority) makes one or more Reference Integrity Manifests (RIMs), corresponding to the software image expected to be found on the device, signed by the Reference Value Provider, available to the Verifier (seeSection 3.1.3 for "in-band" and "out of band" ways to make this happen).¶
• In Step 1, the Verifier (Network Management Station), on behalf of a Relying Party, requests Identity,Measurement Values, and possibly RIMs, from the Attester.¶
• In Step 2, theAttester responds to the request by providing a DevID, quotes (measured values, signed by the Attester),and optionally RIMs.¶

Use of the following standards components allows for interoperability:¶

1. TPM KeysMUST be configured according to[Platform-DevID-TPM-2.0], or[Platform-ID-TPM-1.2].¶
2. For devices using UEFI and Linux, measurements of firmware and bootable modulesMUST be taken according to TCG PC Client[PC-Client-EFI-TPM-1.2] or[PC-Client-BIOS-TPM-2.0], and Linux IMA[IMA].¶
3. Device IdentityMUST be managed as specified in IEEE 802.1AR Device Identity certificates[IEEE-802-1AR], with keys protected by TPMs.¶
4. Attestation logs from Linux-based systemsMUST be formatted according to the Canonical Event Log format[Canonical-Event-Log]. UEFI-based systemsMUST use the TCG UEFI BIOS event log[PC-Client-EFI-TPM-1.2] for TPM1.2 systems, and TCG PC Client Platform Firmware Profile[PC-Client-BIOS-TPM-2.0] for TPM2.0.¶
5. QuotesMUST be retrieved from the TPM according to TCG TAP Information Model[TAP] and the CHARRA YANG model[RFCYYY1]. While the TAP IM gives a protocol-independent description of the data elements involved, it's important to note that quotes from the TPM are signed inside the TPM, andMUST be retrieved in a way that does not invalidate the signature, to preserve the trust model. The[RFCYYY1] is used for this purpose. (SeeSection 5 Security Considerations).¶
6. Reference ValuesMUST be encoded as defined in the TCG RIM document[RIM], typically using SWID[SWID],[NIST-IR-8060] or CoSWID tags[RFC9393].¶

2.4.RIV Simplifying Assumptions

This document makes the following simplifying assumptions to reduce complexity:¶

• The product to be attestedMUST be shipped by the equipment vendor with both an IEEE 802.1AR Device Identity and an InitialAttestation Key (IAK), with certificates in place. The IAK certificate must contain the same identityinformation as the DevID (specifically, the same subject and subjectAltName (if used), signed by the manufacturer). The IAK is a type of key that can beused to sign a TPM Quote, but not other objects (i.e., it's marked as a TCG "Restricted" key; this convention is described in "TPM 2.0 Keys for Device Identity and Attestation"[Platform-DevID-TPM-2.0]). For network equipment, which is generally non-privacy-sensitive, shippinga device with both an IDevID and an IAK already provisioned substantiallysimplifies initial startup.¶

• IEEE 802.1AR does not require a product serial number as part of the subject, but RIV-compliantdevicesMUST include their serial numbers in the DevID/IAK certificates to simplify tracking logistics for network equipment users. All other optional802.1AR fields remain optional in RIV.¶

  It should be noted that 802.1AR use of X.509 certificate fields is not identical to those descsribed in[RFC9525] for representation of application service identity.¶

• The productMUST be equipped with a Root of Trust for Measurement (RTM), Root of Trustfor Storage and Root of Trust for Reporting (as defined in[SP800-155]) which together arecapable of conforming to TCG Trusted Attestation Protocol Information Model[TAP].¶
• The authorized software supplierMUST make available Reference Valuesin the form of signed SWID or CoSWID tags.¶

3.1.Prerequisites for RIV

The Reference Interaction Model for Challenge-Response-based Remote Attestation ([RATS-REF-INTER-MODELS])is based on the standard roles defined in[RFC9334]. However, additional prerequisites have been established to allow for interoperable RIV use case implementations. These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurements collected by the Attester.¶

3.2.Reference Model for Challenge-Response

Once the prerequisites for RIV are met, a Verifier is able to acquire Evidence from an Attester. The following diagram illustrates a RIV information flow between a Verifier and an Attester, derived from Section 7.1 of[RATS-REF-INTER-MODELS]. In this diagram, each event with itsinput and output parameters is shown as "Event(input-params)=>(outputs)".Event times shown correspond to the time types described within Appendix A of[RFC9334]:¶

.----------.                               .-----------------------.| Attester |                              | Relying Party/Verifier |'----------'                              '------------------------'  time(VG)                                                      |generateClaims(attestingEnvironment)                            |   | => claims, eventLogs                                       |   |                                                            |   |                                                        time(NS)   | <-- requestAttestation(handle, authSecIDs, claimSelection) |   |                                                            | time(EG)                                                       |collectClaims(claims, claimSelection)                           |   | => collectedClaims                                         |   |                                                            |generateEvidence(handle, authSecIDs, collectedClaims)           |   | => evidence                                                |   |                                                    time(RG,RA)   | evidence, eventLogs -------------------------------------> |   |                                                            |   |               appraiseEvidence(evidence, eventLogs, refValues)   |                                       attestationResult <= |   |                                                            |   ~                                                            ~   |                                                       time(RX)

Step 1 (time(VG)):

One or more Attesting Network Device PCRs are extended with measurements. RIV provides no direct link between the time at which the event takes place and the time that it's attested, although streaming attestation as in[RATS-NET-DEV-SUB] could.¶

Step 2 (time(NS)):

The Verifier generates a unique random nonce ("number used once"), and makes a request for one or more PCRs from an Attester. For interoperability, this must be accomplished as specified in the YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs[RFCYYY1]. TPM1.2 and TPM2.0 both allow nonces as large as the operative digest size (i.e., 20 or 32 bytes; see[TPM1.2] Part 2, Section 5.5 and[TPM2.0] Part 2, Section 10.4.4).¶

Step 3 (time(EG)):

On the Attester, measured values are retrieved from the Attester's TPM. This requested PCR evidence,along with the Verifier's nonce, called a Quote, is signed by the Attestation Key (AK) associated with the DevID. Quotes are retrieved according to CHARRA YANG model[RFCYYY1]. At the same time, the Attester collects log evidence showing the values have been extended into that PCR.Section 9.1 gives more detail on how this works, including references to the structure and contents of quotes in TPM documents.¶

Step 4:

Collected Evidence is passed from the Attester to the Verifier¶

Step 5 (time(RG,RA)):

The Verifier reviews the Evidence and takes action as needed. As the interaction between Relying Party and Verifier is out of scope for RIV, this can be described as one step.¶

• If the signature covering TPM Evidence is not correct, the deviceSHOULD NOT be trusted.¶
• If the nonce in the response doesn't match the Verifier's nonce, the response may be a replay, and deviceSHOULD NOT be trusted.¶
• If the signed PCR values do not match the set of log entries which have extended a particular PCR, the deviceSHOULD NOT be trusted.¶
• If the log entries that the Verifier considers important do not match known good values, the deviceSHOULD NOT be trusted. We note that the process of collecting and analyzing the log can be omitted if the value in the relevant PCR is already a known-good value.¶
• If the set of log entries are not seen as acceptable by the Appraisal Policy for Evidence, the deviceSHOULD NOT be trusted.¶
• If time(RG)-time(NS) is greater than the Appraisal Policy for Evidence's threshold for assessing freshness, the Evidence is considered stale andSHOULD NOT be trusted.¶

3.3.Centralized vs Peer-to-Peer

Figure 3 above assumes that the Verifier is trusted, while the Attester is not. In a Peer-to-Peer application such as two routers negotiating a trust relationship, the two peers can each ask the other to prove software integrity. In this application, the information flow is the same, but each side plays a role both as an Attester and a Verifier. Each device issues a challenge, and each device responds to the other's challenge, as shown inFigure 4. Peer-to-peer challenges, particularly if used to establish a trust relationship between routers, require devices to carry their own signed reference measurements (RIMs). Devices may also have to carry Appraisal Policy for Evidence for each possible peer device so that each device has everything needed for remote attestation, without having to resort to a central authority.¶

+---------------+                            +---------------+| RefVal        |                            | RefVal        || Provider A    |                            | Provider B    || Firmware      |                            | Firmware      || Configuration |                            | Configuration || Authority     |                            | Authority     ||               |                            |               |+---------------+                            +---------------+      |                                             |      |                                             |Step 0B      |       +------------+        +------------+  |      |       |            | Step 1 |            |  |   \      |       | Attester   |<------>| Verifier   |  |   |      |       |            |<------>|            |  |   |  Router B      +------>|            | Step 2 |            |  |   |- Challenges       Step 0A|            |        |            |  |   |  Router A              |            |------->|            |  |   |              |- Router A -| Step 3 |- Router B -|  |   /              |            |        |            |  |              |            |        |            |  |              |            | Step 1 |            |  |   \              | Verifier   |<------>| Attester   |<-+   |  Router A              |            |<------>|            |      |- Challenges              |            | Step 2 |            |      |  Router B              |            |        |            |      |              |            |<-------|            |      |              +------------+ Step 3 +------------+      /

In this application, each device may need to be equipped with signed RIMs to act as an Attester, and also an Appraisal Policy for Evidence and a selection of trusted X.509 root certificates, to allow the device to act as a Verifier. An existing link layer protocol such as 802.1X[IEEE-802.1X] or 802.1AE[IEEE-802.1AE], with Evidence being enclosed over a variant of EAP[RFC3748] or LLDP[LLDP] are suitable methods for such an exchange.Details of peer-to-peer operation are out of scope for this document.¶

5.1.Keys Used in RIV

Trustworthiness of RIV attestation depends strongly on the validity of keys used for identityand attestation reports. RIV takes full advantage of TPM capabilities to ensure that evidence can be trusted.¶

Two sets of key-pairs are relevant to RIV attestation:¶

• A DevID key-pair is used to certify the identity of the device in which the TPM is installed.¶
• An Attestation Key-pair (AK) key is used to certify attestation Evidence (called 'quotes' in TCG documents),used to provide evidence for integrity of the software on the device¶

TPM practices usually require that these keys be different, as a way of ensuring that a general-purposesigning key cannot be used to spoof an attestation quote.¶

In each case, the private half of the key is known only to the TPM, and cannot beretrieved externally, even by a trusted party. To ensure that's the case,specification-compliant private/public key-pairs are generated inside the TPM, where they are neverexposed, and cannot be extracted (See[Platform-DevID-TPM-2.0]).¶

Keeping keys safe is a critical enabler of trustworthiness, but it's just part of attestation security; knowing which keys are boundto the device in question is just as important in an environment where private keys are never exposed.¶

While there are many ways to manage keys in a TPM (see[Platform-DevID-TPM-2.0]), RIV includessupport for "zero touch" provisioning (also known as zero-touch onboarding) of fieldeddevices (e.g., Secure ZTP,[RFC8572]), where keys which have predictable trust properties areprovisioned by the device vendor.¶

Device identity in RIV is based on IEEE 802.1AR Device Identity (DevID). This specification provides several elements:¶

• A DevID requires a unique key pair for each device, accompanied by an X.509 certificate,¶
• The private portion of the DevID key is to be stored in the device, in a manner that provides confidentiality (Section 6.2.5[IEEE-802-1AR])¶

The X.509 certificate contains several components:¶

• The public part of the unique DevID key assigned to that device allows a challenge of identity.¶
• An identifying string that's unique to the manufacturer of the device. This is normally theserial number of the unit, which might also be printed on a label on the device.¶
• The certificate must be signed by a key traceable to the manufacturer's root key.¶

With these elements, the device's manufacturer and serial number can be identified by analyzing theDevID certificate plus the chain of intermediate certificates leading back to the manufacturer's rootcertificate. As is conventional in TLS or SSH connections, a random nonce must be signed by the devicein response to a challenge,proving possession of its DevID private key.¶

RIV uses the DevID to validate a TLS or SSH connection to the device as the attestation session begins. Security ofthis process derives from TLS or SSH security, with the DevID, containing a device serial number, providing proof that the session terminates onthe intended device. See[RFC8446],[RFC4253].¶

Evidence of software integrity is delivered in the form of a quote signed by the TPMitself, accompanied by an IAK certificate containing the same identity information as the DevID. Because the contents of the quote are signed inside the TPM, any externalmodification (including reformatting to a different data format) after measurements have been taken will be detectedas tampering. An unbroken chain of trust is essential to ensuring that blocks of code that are takingmeasurements have been verified before execution (seeFigure 1).¶

Requiring measurements of the operating software to be signed by a key known only to the TPM alsoremoves the need to trust the device's operating software (beyond the first measurement in the RTM; see below); anychanges to the quote, generated and signed by the TPM itself, made by malicious device software, or inthe path back to the Verifier, will invalidate the signature on the quote.¶

A critical feature of the YANG model described in[RFCYYY1] is the ability to carry TPM data structures in their TCG-defined format, without requiring any changes to the structures as they were signed and delivered by the TPM. While alternate methods of conveying TPM quotes could compress out redundant information, or add another layer of signing using external keys, the implementationMUST preserve the TPM signing, so that tampering anywhere in the path between the TPM itself and the Verifier can be detected.¶

5.2.Prevention of Spoofing and Person-in-the-Middle Attacks

Prevention of spoofing attacks against attestation systems is also important. There are several cases to consider:¶

• The entire device could be spoofed. If the Verifier goes to appraise a specific Attester, it might be redirected to a different Attester.¶
• A compromised device could have a valid DevID, but substitute a quote from a knonwn-good device, instead of returning its own, as described in[RFC6813].¶
• A device with a compromised OS could return a fabricated quote providing spoofed attestation Evidence.¶

Use of the 802.1AR Device Identity (DevID) in the TPM provides protection against the case of a spoofed device, by ensuring that the Verifier's TLS or SSH session is in fact terminating on the right device.¶

Protection against spoofed quotes from a device with valid identity is a bit more complex.An identity key must be available to sign any kind of nonce or hash offered by the Verifier,and consequently, could be used to sign a fabricated quote. To block a spoofed AttestationResult, the quote generated inside the TPM must be signed bya key that's different from the DevID, called an Attestation Key (AK).¶

Given separate Attestation and DevID keys, thebinding between the AK and the same device must also be proven toprevent a person-in-the-middle attack (e.g., the 'Asokan Attack'[RFC6813]).¶

This is accomplished in RIV through use of an AK certificate with the same elements as the DevID(same manufacturer's serial number, signed by the same manufacturer's key), but containingthe device's unique AK public key instead of the DevID public key.This binding between DevID and AK certificates is critical to reliable attestation.¶

The TCG document TPM 2.0 Keys for Device Identity and Attestation[Platform-DevID-TPM-2.0] specifiesOIDs for Attestation Certificates that allow the CA to mark a key as specifically known to be an Attestation key.¶

These two key-pairs and certificates are used together:¶

• The DevID is used to validate a TLS connection terminating on the device with a known serial number.¶
• The AK is used to sign attestation quotes, providing proof that the attestationevidence comes from the same device.¶

5.3.Replay Attacks

Replay attacks, where results of a previous attestation are submitted in response to subsequent requests,are usually prevented by inclusion of a random nonce in the request to the TPMfor a quote. Each request from the Verifier includes a new random number (a nonce). The resultingquote signed by the TPM contains the same nonce, allowing the Verifier to determinefreshness, (i.e., that the resulting quote was generated in response to the Verifier's specific request).Time-Based Uni-directional Attestation[RATS-TUDA] provides an alternate mechanismto verify freshness without requiring a request/response cycle.¶

5.4.Owner-Signed Keys

Although device manufacturers must pre-provision devices with easily verified DevID and AK certificatesif zero-touch provisioning such as described in[RFC8572] is to be supported,use of those credentials is not mandatory. IEEE 802.1AR incorporates the idea of an Initial Device ID(IDevID), provisioned by the manufacturer, and a Local Device ID (LDevID) provisioned by the owner ofthe device. RIV and[Platform-DevID-TPM-2.0] extends that concept by defining an Initial Attestation Key (IAK) and Local AttestationKey (LAK) with the same properties.¶

Device owners can use any method to provision the Local credentials.¶

• TCG document[Platform-DevID-TPM-2.0] shows how the initial Attestationkeys can be used to certify LDevID and LAK keys. Use of the LDevID and LAK allows the device ownerto use a uniform identity structure across device types from multiple manufacturers (in the same waythat an "Asset Tag" is used by many enterprises to identify devices they own). TCG document[Provisioning-TPM-2.0] also contains guidance on provisioning Local identity keys in TPM 2.0.Owners should follow the same practice of binding Local DevID and Local AK as the manufacturer would for IDevID and IAK.SeeSection 2.2.¶
• Device owners, however, can use any other mechanism they want to assure themselves that local identitycertificates are inserted into the intended device, including physical inspection and programmingin a secure location, if they prefer to avoid placing trust in the manufacturer-provided keys.¶

Clearly, local keys can't be used for secure Zero Touch provisioning; installation of the local keyscan only be done by some process that runs before the device is installed for network operation, or using procedures such as those outlined in Bootstrapping Remote Secure Key Infrastructure (BRSKI)[RFC8995].¶

On the other end of the device life cycle, provision should be made to wipe local keys when a deviceis decommissioned, to indicate that the device is no longer owned by the enterprise. The manufacturer'sInitial identity keys must be preserved, as they contain no information that's not already printed onthe device's serial number plate.¶

5.5.Other Factors for Trustworthy Operation

In addition to trustworthy provisioning of keys, RIV depends on a number of other factors for trustworthy operation.¶

• Secure identity depends on mechanisms to prevent per-device secret keys from being compromised. The TPMprovides this capability as a Root of Trust for Storage.¶
• Attestation depends on an unbroken chain of measurements, starting from the very first measurement. SeeSection 9.1 for background on TPM practices.¶
• That first measurement is made by code called the Root of Trust for Measurement, typically done by trustedfirmware stored in boot flash. Mechanisms for maintaining the trustworthiness of the RTM are out ofscope for RIV, but could include immutable firmware, signed updates, or a vendor-specific hardwareverification technique. SeeSection 9.2 for background on roots of trust.¶
• The device ownerSHOULD provide some level of physical defense for the device. If a TPM that has already been programmedwith an authentic DevID is stolen and inserted into a counterfeit device, attestation of that counterfeitdevice may become indistinguishable from an authentic device.¶

RIV also depends on reliable Reference Values, as expressed by the RIM[RIM]. The definition oftrust procedures for RIMs is out of scope for RIV, and the device owner is free to use any policy to validatea set of reference measurements. It should also be noted that, while RIV can provide a reliable indication that a known software package is in use by the device, and that the package has not been tampered, it is the device owner's responsibility to determine that it's the correct package for the application.¶

RIMs may be conveyed out-of-band or in-band, as part of the attestationprocess (seeSection 3.1.3). But for network devices, where software is usually shipped as a self-containedpackage, RIMs signed by the manufacturer and delivered in-band may be more convenient for the device owner.¶

The validity of RIV attestation results is also influenced by procedures used to create Reference Values:¶

• While the RIM itself is signed, supply-chainsSHOULD be carefully scrutinized to ensure that the values are not subject to unexpected manipulation prior to signing. Insider-attacks against code bases and build chainsare particularly hard to spot.¶
• DesignersSHOULD guard against hash collision attacks. Reference Integrity Manifests often give hashes for large objectsof indeterminate size; if one of the measured objects can be replaced with an implant engineered to producethe same hash, RIV will be unable to detect the substitution. TPM1.2 uses SHA-1 hashes only, which have beenshown to be susceptible to collision attack. TPM2.0 will produce quotes with SHA-256, which so far has resistedsuch attacks. Consequently, RIV implementationsSHOULD use TPM2.0.¶

9.1.Using a TPM for Attestation

The Trusted Platform Module and surrounding ecosystem provide three interlocking capabilities to enable secure collection of evidence from a remote device, Platform Configuration Registers (PCRs), a Quote mechanism, and a standardized Event Log.¶

Each TPM has at least eight and at most twenty-four PCRs (depending on the profile and vendor choices), each one large enough to hold one hash value (SHA-1, SHA-256, and other hash algorithms can be used, depending on TPM version). PCRs can't be accessed directly from outside the chip, but the TPM interface provides a way to "extend" a new security measurement hash into any PCR, a process by which the existing value in the PCR is hashed with the new security measurement hash, and the result placed back into the same PCR. The result is a composite fingerprint comprising the hash of all the security measurements extended into each PCR since the system was reset.¶

Every time a PCR is extended, an entry should be added to the corresponding Event Log. Logs contain the security measurement hash plus informative fields offering hints as to which event generated the security measurement. The Event Log itself is protected against accidental manipulation, but it is implicitly tamper-evident - any verification process can read the security measurement hash from the log events, compute the composite value and compare that to what ended up in the PCR. If there's no discrepancy, the logs do provide an accurate view of what was placed into the PCR.¶

Note that the composite hash-of-hashes recorded in PCRs is order-dependent, resulting in different PCR values for different ordering of the same set of events (e.g. Event A followed by Event B yields a different PCR value than B followed by A).For single-threaded code, where both the events and their order are fixed, a Verifier may validate a single PCR value, and use the log only to diagnose a mismatch from Reference Values. However, operating system code is usually non-deterministic, meaning that there may never be a single "known good" PCR value. In this case, the Verifier may haveto verify that the log is correct, and then analyze each item in the log to determine if it represents an authorized event.¶

In a conventional TPM Attestation environment, the first measurement must be made and extended into the TPM by trusted device code (called the Root of Trust for Measurement, RTM). That first measurement should cover the segment of code that is run immediately after the RTM, which then measures the next code segment before running it, and so on, forming an unbroken chain of trust. See[TCGRoT] for more on Mutable vs Immutable roots of trust.¶

The TPM provides another mechanism called a Quote that can read the current value of the PCRs and package them, along with the Verifier's nonce, into a TPM-specific data structure signed by an Attestation private key, known only to the TPM.¶

As noted above inSection 5 Security Considerations, it's important to note that the Quote data structure is signed inside the TPM. The trust model is preserved by retrieving the Quote in a way that does not invalidate the signature, as specified in[RFCYYY1]. The structure of the command and response for a quote, including its signature, as generated by the TPM, can be seen in[TPM1.2] Part 3, Section 16.5, and[TPM2.0] Section 18.4.2.¶

The Verifier uses the Quote and Log together. The Quote contains the composite hash of the complete sequence of security measurement hashes, signed by the TPM's private Attestation Key. The Log contains a record of eachmeasurement extended into the TPM's PCRs. By computing the composite hash of all the measurements, the Verifiercan verify the integrity of the Event Log, even though the Event Log itself is not signed. Each hash in the validated Event Log can then be compared to corresponding expected values in the set of Reference Values to validate overall system integrity.¶

A summary of information exchanged in obtaining quotes from TPM1.2 and TPM2.0 can be found in[TAP], Section 4.Detailed information about PCRs and Quote data structures can be found in[TPM1.2],[TPM2.0]. Recommended log formats include[PC-Client-BIOS-TPM-2.0], and[Canonical-Event-Log].¶

9.2.Root of Trust for Measurement

The measurements needed for attestation require that the device being attestedis equipped with a Root of Trust for Measurement, that is, some trustworthymechanism that can compute the first measurement in the chain of trust requiredto attest that each stage of system startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to record the results, and a Root of Trustfor Reporting to report the results.¶

While there are many complex aspects of Roots of Trust ([TCGRoT],[SP800-155],[SP800-193]), two aspects thatare important in the case of attestation are:¶

• The first measurement computed by the Root of Trust for Measurement, and storedin the TPM's Root of Trust for Storage, must be assumed to be correct.¶
• There must not be a way to reset the Root of Trust for Storage without re-enteringthe Root of Trust for Measurement code.¶

The first measurement must be computed by code that is implicitly trusted; if thatfirst measurement can be subverted, none of the remaining measurements canbe trusted. (See[SP800-155])¶

It's important to note that the trustworthiness of the RTM code cannot be assured by the TPM or TPM supplier - code or procedures external to the TPM must guarantee the security of the RTM.¶

9.3.Layering Model for Network Equipment Attester and Verifier

Retrieval of identity and attestation state uses one protocol stack, whileretrieval of Reference Values uses a different set of protocols. Figure5 shows the components involved.¶

+-----------------------+              +-------------------------+|                       |              |                         ||       Attester        |<-------------|        Verifier         ||       (Device)        |------------->|   (Management Station)  ||                       |      |       |                         |+-----------------------+      |       +-------------------------+                               |           -------------------- --------------------           |                                        |-------------------------------    ---------------------------------|Reference Values             |    |         Attestation           |-------------------------------    ---------------------------------*********************************************************************         IETF Attestation Reference Interaction Diagram           *********************************************************************    .........................          .........................    . Reference Integrity   .          .  TAP (PTS2.0) Info    .    .      Manifest         .          . Model and Canonical   .    .                       .          .     Log Format        .    .........................          .........................    *************************          *************************    * YANG SWID Module      *          * YANG Attestation      *    * RFC9393               *          * Module                *    *                       *          * RFCYYY1               *    *                       *          *                       *    *************************          *************************    *************************          *************************    * XML, JSON, CBOR (etc) *          * XML, JSON, CBOR (etc) *    *************************          *************************    *************************          *************************    *   RESTCONF/NETCONF    *          *   RESTCONF/NETCONF    *    *************************          *************************    *************************          *************************    *       TLS, SSH        *          *       TLS, SSH        *    *************************          *************************

IETF documents are captured in boxes surrounded by asterisks. TCG documentsare shown in boxes surrounded by dots.¶

9.4.Implementation Notes

Table 2 summarizes many of the actions needed to complete an Attestationsystem, with links to relevant documents. While documents are controlledby several standards organizations, the implied actions required forimplementation are all the responsibility of the manufacturer of the device,unless otherwise noted.¶

As noted, SWID tags can be generated many ways, but one possible tool is[SWID-Gen]¶