rfc9683xml2.original.xml   rfc9683.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.26 (Rub
y 2.6.4) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc tocdepth="4"?> -ietf-rats-tpm-based-network-device-attest-14" number="9683" submissionType="IET
<?rfc symrefs="yes"?> F" category="info" consensus="true" obsoletes="" updates="" xml:lang="en" tocInc
<?rfc sortrefs="yes"?> lude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200902" docName="draft-ietf-rats-tpm-based-network-device-attest- 14" category="info">
<front> <front>
<title abbrev="Network Device RIV">TPM-based Network Device Remote Integrity <!-- [rfced] May we update the title as follows?
Verification</title>
Current:
TPM-based Network Device Remote Integrity Verification
Perhaps (expanding TPM per the Style Guide):
Remote Integrity Verification of Network Devices
Containing Trusted Platform Modules
-->
<title abbrev="Network Device RIV">TPM-based Network Device Remote Integrity
Verification</title>
<seriesInfo name="RFC" value="9683"/>
<author initials="G. C." surname="Fedorkow" fullname="Guy Fedorkow" role="ed itor"> <author initials="G. C." surname="Fedorkow" fullname="Guy Fedorkow" role="ed itor">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>10 Technology Park Drive</street> <street>10 Technology Park Drive</street>
<city>Westford</city> <city>Westford</city>
<region>Massachusetts</region> <region>Massachusetts</region>
<code>01886</code> <code>01886</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<phone></phone> <phone/>
<email>gfedorkow@juniper.net</email> <email>gfedorkow@juniper.net</email>
</address> </address>
</author> </author>
<author initials="E." surname="Voit" fullname="Eric Voit"> <author initials="E." surname="Voit" fullname="Eric Voit">
<organization abbrev="Cisco">Cisco Systems</organization> <organization abbrev="Cisco">Cisco Systems</organization>
<address> <address>
<email>evoit@cisco.com</email> <email>evoit@cisco.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Fitzgerald-McKay" fullname="Jessica Fitzgeral d-McKay"> <author initials="J." surname="Fitzgerald-McKay" fullname="Jessica Fitzgeral d-McKay">
skipping to change at line 53 skipping to change at line 57
<postal> <postal>
<street>9800 Savage Road</street> <street>9800 Savage Road</street>
<city>Ft. Meade</city> <city>Ft. Meade</city>
<region>Maryland</region> <region>Maryland</region>
<code>20755</code> <code>20755</code>
<country>US</country> <country>US</country>
</postal> </postal>
<email>jmfitz2@nsa.gov</email> <email>jmfitz2@nsa.gov</email>
</address> </address>
</author> </author>
<date year="2024" month="September"/>
<area>sec</area>
<workgroup>rats</workgroup>
<date year="2022" month="March" day="22"/> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->
<area>Security</area> <keyword>example</keyword>
<workgroup>RATS Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document describes a workflow for remote attestation of the integr
<t>This document describes a workflow for remote attestation of the integrity of ity of firmware and software installed on network devices that contain Trusted P
firmware and software latform Modules (TPMs), as defined by
installed on network devices that contain Trusted Platform Modules <xref target= the Trusted Computing Group (TCG), or equivalent hardware implementations that i
"TPM1.2"/>, <xref target="TPM2.0"/>, as defined by nclude the protected capabilities, as provided by TPMs.</t>
the Trusted Computing Group (TCG)), or equivalent hardware implementations that
include the protected capabilities, as provided by TPMs.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>There are many aspects to consider in fielding a trusted computing devi
<t>There are many aspects to consider in fielding a trusted computing device, ce,
from operating systems to applications. Mechanisms to prove that from operating systems to applications. Mechanisms to prove that
a device installed at a customer’s site is authentic (i.e., not counterfeit) and a device installed at a customer's site is authentic (i.e., not counterfeit) and
has has
been configured with authorized software, all as part of a trusted supply chain, been configured with authorized software, all as part of a trusted supply chain,
are just a few of the many aspects which need to be considered concurrently to are just a few of the many aspects that need to be considered concurrently to h
have confidence that a device is truly trustworthy.</t> ave confidence that a device is truly trustworthy.</t>
<t>A generic architecture for remote attestation has been defined in <xref
<t>A generic architecture for remote attestation has been defined in <xref targe target="RFC9334" format="default"/>. Additionally, use cases for remotely atte
t="I-D.ietf-rats-architecture"/>. Additionally, use cases for remotely attestin sting networking devices are discussed within Section 5 of <xref target="I-D.ric
g networking devices are discussed within Section 6 of <xref target="I-D.richard hardson-rats-usecases" format="default"/>. However, these documents do not prov
son-rats-usecases"/>. However, these documents do not provide sufficient guidan ide sufficient guidance for network equipment vendors and operators to design, b
ce for network equipment vendors and operators to design, build, and deploy inte uild, and deploy interoperable devices.</t>
roperable devices.</t> <t>The intent of this document is to provide such guidance. It does this b
y outlining the Remote Integrity Verification (RIV) problem and then by identify
<t>The intent of this document is to provide such guidance. It does this by outl ing the necessary elements to get the complete, scalable attestation procedure w
ining the Remote Integrity Verification (RIV) problem, and then identifies eleme orking with commercial networking products such as routers, switches, and firewa
nts that are necessary to get the complete, scalable attestation procedure worki lls. An underlying assumption is the availability within the device of a crypt
ng with commercial networking products such as routers, switches and firewalls. oprocessor that is compatible with the Trusted Platform Module specifications <x
An underlying assumption will be the availability within the device of a Trust ref target="TPM-1.2" format="default"/> <xref target="TPM-2.0" format="default"/
ed Platform Module <xref target="TPM1.2"/>, <xref target="TPM2.0"/> compatible c > to enable the trustworthy, remote assessment of the device's software and hard
ryptoprocessor to enable the trustworthy remote assessment of the device’s softw ware.</t>
are and hardware.</t> <section anchor="requirements-notation" numbered="true" toc="default">
<name>Requirements Notation</name>
<section anchor="requirements-notation" title="Requirements notation"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and ",
“OPTIONAL” in this document are to be interpreted as described in "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ey appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
capitals, as shown here.</t> be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
</section> target="RFC8174"/> when, and only when, they appear in all capitals, as
<section anchor="terminology" title="Terminology"> shown here.
</t>
<t>A number of terms are reused from <xref target="I-D.ietf-rats-architecture"/> </section>
. These include: Appraisal Policy for Evidence, Attestation Result, Attester, E <section anchor="terminology" numbered="true" toc="default">
vidence, Reference Value, Relying Party, Verifier, and Verifier Owner.</t> <name>Terminology</name>
<t>A number of terms are reused from <xref target="RFC9334" format="defa
<t>Additionally, this document defines the following term:</t> ult"/>. These include Appraisal Policy for Evidence, Attestation Result, Attest
er, Evidence, Reference Value, Relying Party, Verifier, and Verifier Owner.</t>
<t>Attestation: the process of generating, conveying and appraising <t>Additionally, this document defines the following term:</t>
<dl>
<dt>Attestation:</dt>
<dd>The process of generating, conveying, and appraising
claims, backed by evidence, about device trustworthiness characteristics, includ ing supply chain trust, claims, backed by evidence, about device trustworthiness characteristics, includ ing supply chain trust,
identity, device provenance, software configuration, device identity, device provenance, software configuration, device
composition, compliance to test suites, functional and assurance evaluations, et composition, compliance to test suites, functional and assurance evaluations, et
c.</t> c.</dd>
</dl>
<!-- [rfced] Section 1.2. Does the following update improve readability?
<t>The goal of attestation is simply to assure an administrator or auditor that Original:
the device configuration and software The goal of attestation is simply to assure an administrator or
auditor that the device configuration and software that was launched
when the device was last started is authentic and untampered-with.
Perhaps (rephrasing "untampered-with"):
The goal of attestation is simply to assure an administrator or
auditor that the device's configuration and software
is authentic and has been unaltered since the device started.
-->
<t>The goal of attestation is simply to assure an administrator or audit
or that the device configuration and software
that was launched when the device was last started is authentic and untampered-w ith. that was launched when the device was last started is authentic and untampered-w ith.
The determination of software authenticity is not prescribed in this document, b ut it’s typically taken to mean The determination of software authenticity is not prescribed in this document, b ut it's typically taken to mean
a software image generated by an authority trusted by the administrator, such as the device manufacturer.</t> a software image generated by an authority trusted by the administrator, such as the device manufacturer.</t>
<t>Within the context of the Trusted Computing Group (TCG), the scope of
<t>Within the Trusted Computing Group (TCG) context, the scope of attestation is attestation is typically narrowed to describe the process by
typically narrowed to describe the process by
which an independent Verifier can obtain cryptographic proof as to the identity which an independent Verifier can obtain cryptographic proof as to the identity
of the device in question, and evidence of the integrity of software loaded on of the device in question, evidence of the integrity of the device's software th
that device when it started up, and then verify that what’s there matches the at was loaded upon
startup, and verification that the current configuration matches the
intended configuration. For network equipment, a Verifier capability can intended configuration. For network equipment, a Verifier capability can
be embedded in a Network Management Station (NMS), a posture collection server, be embedded in a Network Management Station, a posture collection server,
or other network analytics tool (such as a software asset management solution, or other network analytics tool (such as a software asset management solution,
or a threat detection and mitigation tool, etc.). While informally referred or a threat detection and mitigation tool, etc.).
to as attestation, this document focuses on a specific subset of attestation tas This document focuses on a specific subset of attestation tasks, defined here as
ks, defined here as Remote Remote
Integrity Verification (RIV). RIV in this document takes a network-equipment-ce Integrity Verification (RIV), and informally referred to as attestation. RIV in
ntric perspective this document takes a network-equipment-centric perspective
that includes a set of protocols and procedures for determining whether a that includes a set of protocols and procedures for determining whether a
particular device was launched with authentic software, starting from Roots particular device was launched with authentic software, starting from Roots
of Trust. While there are many ways to accomplish attestation, RIV sets of Trust. While there are many ways to accomplish attestation, RIV sets
out a specific set of protocols and tools that work in environments commonly out a specific set of protocols and tools that work in environments commonly
found in network equipment. RIV does not cover other device characteristics found in network equipment. RIV does not cover other device characteristics
that could be attested (e.g., geographic location, connectivity; that could be attested (e.g., geographic location or connectivity;
see <xref target="I-D.richardson-rats-usecases"/>), although it does provide evi see <xref target="I-D.richardson-rats-usecases" format="default"/>), although it
dence of a secure infrastructure does provide evidence of a secure infrastructure
to increase the level of trust in other device characteristics attested to increase the level of trust in other device characteristics attested
by other means (e.g., by Entity Attestation Tokens <xref target="I-D.ietf-rats-e by other means (e.g., by Entity Attestation Tokens <xref target="I-D.ietf-rats-e
at"/>).</t> at" format="default"/>).</t>
<t>In line with definitions found in <xref target="RFC9334" format="defa
<t>In line with <xref target="I-D.ietf-rats-architecture"/> definitions, this do ult"/>, this document uses the term Endorser to refer to the
cument uses the term Endorser to refer to the
role that signs identity and attestation certificates used by the Attester, whil e Reference Values are signed role that signs identity and attestation certificates used by the Attester, whil e Reference Values are signed
by a Reference Value Provider. Typically, the manufacturer of a network device would be accepted as 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 ultimatel y up to the Verifier Owner.</t> both the Endorser and Reference Value Provider, although the choice is ultimatel y up to the Verifier Owner.</t>
</section>
</section> <section anchor="document-organization" numbered="true" toc="default">
<section anchor="document-organization" title="Document Organization"> <name>Document Organization</name>
<t>The remainder of this document is organized into several sections:</t
<t>The remainder of this document is organized into several sections:</t> >
<ul spacing="normal">
<t><list style="symbols"> <li>The remainder of this section covers goals and requirements, plus
<t>The remainder of this section covers goals and requirements, plus a top-lev a top-level description of RIV.</li>
el description of RIV.</t> <li>The Solution Overview section (<xref target="solution-overview" fo
<t>The Solution Overview section outlines how Remote Integrity Verification wo rmat="default"/>) outlines how RIV works.</li>
rks.</t> <li>The Standards Components section (<xref target="standards-componen
<t>The Standards Components section links components of RIV to normative stand ts" format="default"/>) links components of RIV to normative standards.</li>
ards.</t> <li>The Privacy and Security Considerations sections (Sections <xref t
<t>Privacy and Security shows how specific features of RIV contribute to the t arget="privacy-considerations" format="counter"/> and <xref target="security-con
rustworthiness of the Attestation Result.</t> s" format="counter"/>) shows how specific features of RIV contribute to the trus
<t>Supporting material is in an appendix at the end.</t> tworthiness of the Attestation Result.</li>
</list></t> <li>Supporting material is in an appendix (<xref target="appendix" for
mat="default"/>).</li>
</section> </ul>
<section anchor="goals" title="Goals"> </section>
<section anchor="goals" numbered="true" toc="default">
<t>Network operators benefit from a trustworthy attestation mechanism that provi <name>Goals</name>
des <t>Network operators benefit from a trustworthy attestation mechanism th
assurance that their network comprises authentic equipment, and has loaded softw at provides
are assurance that their network comprises authentic equipment and has loaded softwa
re
free of known vulnerabilities and unauthorized tampering. In line with the over all goal of assuring integrity, attestation can be used to assist in asset manag ement, vulnerability and compliance free of known vulnerabilities and unauthorized tampering. In line with the over all goal of assuring integrity, attestation can be used to assist in asset manag ement, vulnerability and compliance
assessment, plus configuration management.</t> assessment, plus configuration management.</t>
<t>The RIV attestation workflow outlined in this document is intended to
<t>The RIV attestation workflow outlined in this document is intended to meet th meet the following high-level goals:</t>
e following high-level goals:</t> <ul spacing="normal">
<li>Provable Device Identity - This specification requires that an Att
<t><list style="symbols"> ester (i.e., the attesting device) includes
<t>Provable Device Identity - This specification requires that an Attester (i. a cryptographic identifier unique to each device. Effectively, this means that
e., the attesting device) includes the device's TPM
a cryptographic identifier unique to each device. Effectively this means that t must be provisioned with this during the manufacturing cycle.</li>
he device’s TPM <li>Software Inventory - Key goals are to identify the software releas
must be so provisioned during the manufacturing cycle.</t> e(s) installed
<t>Software Inventory - A key goal is to identify the software release(s) inst on the Attester and to provide evidence that the software stored within hasn't
alled been altered without authorization.</li>
on the Attester, and to provide evidence that the software stored within hasn’t <li>Verifiability - Verification of the device's software and configur
been altered without authorization.</t> ation shows
<t>Verifiability - Verification of software and configuration of the device sh that the software that the administrator authorized for use was actually launche
ows d.</li>
that the software that the administrator authorized for use was actually launche </ul>
d.</t> <t>In addition, RIV is designed to operate either in a centralized envir
</list></t> onment, such as with a central authority that manages and configures a number of
network devices, or "peer-to-peer", where network devices independently verify
<t>In addition, RIV is designed to operate either in a centralized environment, one another to establish a trust relationship. (See <xref target="peer-to-peer"
such as with a central authority that manages and configures a number of network format="default"/>.)</t>
devices, or ‘peer-to-peer’, where network devices independently verify one anot </section>
her to establish a trust relationship. (See <xref target="peer-to-peer"/> below <section anchor="RIV-desc" numbered="true" toc="default">
)</t> <name>Description of Remote Integrity Verification (RIV)</name>
<t>Attestation requires two interlocking mechanisms between the Attester
</section> network device and the Verifier:</t>
<section anchor="RIV-desc" title="Description of Remote Integrity Verification ( <ul spacing="normal">
RIV)"> <li>Device Identity is the mechanism that provides trusted identity, w
hich can reassure network
<t>Attestation requires two interlocking mechanisms between the Attester network
device and the Verifier:</t>
<t><list style="symbols">
<t>Device Identity, the mechanism providing trusted identity, can reassure net
work
managers that the specific devices they ordered from authorized manufacturers fo r managers that the specific devices they ordered from authorized manufacturers fo r
attachment to their network are those that were installed, and that they continu e to attachment to their network are those that were installed and that they continue to
be present in their network. As part of the mechanism for Device Identity, be present in their network. As part of the mechanism for Device Identity,
cryptographic proof of the identity of the manufacturer is also provided.</t> cryptographic proof of the manufacturer's identity is also provided.</li>
<t>Software Measurement is the mechanism that reports the state of mutable sof <li>Software Measurement is the mechanism that reports the state of mu
tware components table software components
on the device, and can assure administrators that they have known, authentic on the device and that can assure administrators that they have known, authentic
software configured to run in their network.</t> software configured to run in their network.</li>
</list></t> </ul>
<t>By using these two interlocking mechanisms, RIV, which is a component
<t>Using these two interlocking mechanisms, RIV is a component in a chain of pro in a chain of procedures, can assure a network operator that the equipment in
cedures that can assure a network operator that the equipment in their network can be reliably identified and that authentic software of
their network can be reliably identified, and that authentic software of
a known version is installed on each device. Equipment in the network includes a known version is installed on each device. Equipment in the network includes
devices that make up the network itself, such as routers, switches and firewalls devices that make up the network itself, such as routers, switches, and firewall
.</t> s.</t>
<!-- [rfced] Section 1.5. In the following passage, it is unclear which componen
t is doing the measuring:
<t>Software used to boot a device can be identified by a chain Original:
of measurements, anchored at the start by a Root of Trust for Measurement (see < Software used to boot a device can be identified by a chain of
xref target="root-of-trust"/>), each measuring the next stage and recording the measurements, anchored at the start by a Root of Trust for
result in tamper-resistant storage, Measurement (see Section 9.2), each measuring the next stage and
recording the result in tamper-resistant storage, normally ending
when the system software is fully loaded.
Perhaps (stating that the Attester measures at each stage):
Software used to boot a device can be identified by a chain of
measurements, anchored at the start by a Root of Trust for
Measurement (RTM) (see Appendix A.2). An Attester measures at each stage and
records the result in tamper-resistant storage. The Attester normally
stops measuring when the system software is fully loaded.
-->
<t>Software used to boot a device can be identified by a chain
of measurements, anchored at the start by a Root of Trust for Measurement (RTM)
(see <xref target="root-of-trust" format="default"/>), each measuring the next s
tage and recording the result in tamper-resistant storage,
normally ending when the system software is fully loaded. normally ending when the system software is fully loaded.
A measurement signifies the identity, integrity and version of each A measurement signifies the identity, integrity, and version of each
software component registered with an Attester’s TPM <xref target="TPM1.2"/>, <x software component registered with an Attester's TPM <xref target="TPM-1.2" form
ref target="TPM2.0"/>, so that a at="default"/> <xref target="TPM-2.0" format="default"/> so that a
subsequent verification stage can determine if the software subsequent verification stage can determine if the software
installed is authentic, up-to-date, and free of tampering.</t> installed is authentic, up-to-date, and free of tampering.</t>
<t>RIV includes several major processes, which are split between the Att
<t>RIV includes several major processes, split between the Attester and Verifier ester and Verifier:</t>
:</t> <ol spacing="normal" type="1"><li>Generation of Evidence is the process
whereby an Attester generates cryptographic
<t><list style="numbers">
<t>Generation of Evidence is the process whereby an Attester generates cryptog
raphic
proof (Evidence) of claims about device properties. In particular, the proof (Evidence) of claims about device properties. In particular, the
device identity and its software configuration are both of critical importance.< device identity and its software configuration are both of critical importance.<
/t> /li>
<t>Device Identification refers to the mechanism assuring the <li>Device Identification refers to the mechanism assuring the
Relying Party (ultimately, a network administrator) of the identity of devices t Relying Party (ultimately, a network administrator) of the identities of devices
hat make up their network, , and the identities of their manufacturers, that make up their network.</li>
and that their manufacturers are known.</t> <li>Conveyance of Evidence
<t>Conveyance of Evidence reliably transports the collected Evidence from the Attester to a Verifier to a
reliably transports the collected Evidence from Attester to a Verifier to allow llow a management station to perform
a management station to perform
a meaningful appraisal in Step 4. The transport a meaningful appraisal in Step 4. The transport
is typically carried out via a management network. is typically carried out via a management network.
While not required for reliable attestation, an encrypted channel may be used t o Although not required for reliable attestation, an encrypted channel may be use d to
provide integrity, authenticity, or confidentiality once attestation is complet e. provide integrity, authenticity, or confidentiality once attestation is complet e.
It should be noted that critical attestation evidence from the TPM is signed by a key known only to TPM, and is not 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.</t> dependent on encryption carried out as part of a reliable transport.</li>
<t>Finally, Appraisal of Evidence occurs. This is the process of verifying th <li>Finally, Appraisal of Evidence occurs. This is the process of ver
e Evidence received by ifying the Evidence received by
a Verifier from the Attester, and using an Appraisal Policy to develop an a Verifier from the Attester and using an Appraisal Policy to develop an
Attestation Result, used to inform decision-making. In practice, this means c Attestation Result, which is used to inform decision-making. In practice, thi
omparing s means comparing
the Attester’s measurements reported as Evidence with the device configuration the Attester's measurements reported as Evidence with the device configuration
expected expected
by the Verifier. Subsequently, the Appraisal Policy for Evidence might by the Verifier. Subsequently, the Appraisal Policy for Evidence might
match Evidence found against Reference Values (aka Golden Measurements), which represent match Evidence found against Reference Values (aka Golden Measurements), which represent
the intended configured state of the connected device.</t> the intended configured state of the connected device.</li>
</list></t> </ol>
<t>All implementations supporting this RIV specification require the sup
<t>All implementations supporting this RIV specification require the support of port of the following three technologies:</t>
the following three technologies:</t> <ol spacing="normal" type="1"><li>Identity: Device identity in RIV is ba
sed on Device Identity (DevID) defined by IEEE Std 802.1AR <xref target="IEEE-80
<t><list style="numbers"> 2-1AR" format="default"/>,
<t>Identity: Device identity in RIV is based on IEEE 802.1AR Device Identity (
DevID) <xref target="IEEE-802-1AR"/>,
coupled with careful supply-chain management by the manufacturer. The coupled with careful supply-chain management by the manufacturer. The
Initial DevID (IDevID) certificate contains a statement by the manufacturer that establishes Initial DevID (IDevID) certificate contains a statement by the manufacturer that establishes
the identity of the device as it left the factory. Some applications with the identity of the device as it left the factory. Some applications with
a more-complex post-manufacture supply chain (e.g., Value Added Resellers), a more complex post-manufacture supply chain (e.g., value added resellers),
or with different privacy concerns, may want to use alternative mechanisms for p latform or with different privacy concerns, may want to use alternative mechanisms for p latform
authentication (for example, TCG Platform Certificates <xref target="Platform-Ce authentication (for example, TCG Platform Certificates <xref target="PLATFORM-CE
rtificates"/>, or RTS" format="default"/> or
post-manufacture installation of Local Device ID (LDevID)).</t> post-manufacture installation of Local DevID (LDevID)).</li>
<t>Platform Attestation provides evidence of configuration of software element <li>Platform Attestation provides evidence of configuration of softwar
s e elements
present in the device. This form of attestation can be implemented present in the device. This form of attestation can be implemented
with TPM Platform Configuration Registers (PCRs), Quote and Log mechanisms, whic h provide cryptographically authenticated evidence with TPM Platform Configuration Registers (PCRs) and Quote and Log mechanisms, which provide cryptographically authenticated evidence
to report what software was started on the device through the boot cycle. Succe ssful attestation requires an to report what software was started on the device through the boot cycle. Succe ssful attestation requires an
unbroken chain from a boot-time root of trust through all layers of software nee ded to bring the device to an unbroken chain from a boot-time Root of Trust through all layers of software nee ded to bring the device to an
operational state, in which each stage computes the hash of components of the ne xt stage, then updates the attestation log and operational state, in which each stage computes the hash of components of the ne xt stage, then updates the attestation log and
the TPM. The TPM can then report the hashes of all the measured hashes as signe d evidence called a the TPM. The TPM can then report the hashes of all the measured hashes as signe d evidence called a
Quote (see <xref target="using-tpm"/> for an overview of TPM operation, or <xref Quote (see <xref target="using-tpm" format="default"/> for an overview of TPM op
target="TPM1.2"/> and <xref target="TPM2.0"/> for many more details).</t> eration or <xref target="TPM-1.2" format="default"/> and <xref target="TPM-2.0"
<t>Signed Reference Values (aka Reference Integrity Measurements) must be conv format="default"/> for many more details).</li>
eyed from the Reference Value Provider (the entity accepted as the software auth <li>Signed Reference Values (aka Reference Integrity Measurements) mus
ority, t be conveyed from the Reference Value Provider (the entity accepted as the soft
often the manufacturer of the network device) to the Verifier.</t> ware authority,
</list></t> often the manufacturer of the network device) to the Verifier.</li>
</ol>
</section> </section>
<section anchor="solution-requirements" title="Solution Requirements"> <section anchor="solution-requirements" numbered="true" toc="default">
<name>Solution Requirements</name>
<t>Remote Integrity Verification must address the “Lying Endpoint” <t>RIV must address the "Lying Endpoint"
problem, in which malicious software on an endpoint may subvert the problem, in which malicious software on an endpoint may subvert the
intended function, and also prevent the endpoint from reporting its compromised intended function and also prevent the endpoint from reporting its compromised
status. (See <xref target="security-cons"/> for further Security Considerations status. (See <xref target="security-cons" format="default"/> for further Securi
.)</t> ty Considerations.)</t>
<t>RIV attestation is designed to be simple
<t>RIV attestation is designed to be simple to deploy at scale. RIV should work "out of the box" as far as possible,
to deploy at scale. RIV should work “out of the box” as far as possible,
that is, with the fewest possible provisioning steps or configuration databases that is, with the fewest possible provisioning steps or configuration databases
needed at the end-user’s site. Network equipment is often required to “self-con figure”, needed at the end user's site. Network equipment is often required to "self-con figure",
to reliably reach out without manual intervention to prove its identity and to reliably reach out without manual intervention to prove its identity and
operating posture, then download its own configuration, a process which preclude operating posture, then download its own configuration, a process which preclude
s pre-installation configuration. See <xref target="RFC8572"/> for an s pre-installation configuration. See <xref target="RFC8572" format="default"/>
example of Secure Zero Touch Provisioning.</t> for an
example of Secure Zero Touch Provisioning (SZTP).</t>
</section> </section>
<section anchor="scope" title="Scope"> <section anchor="scope" numbered="true" toc="default">
<name>Scope</name>
<t>The need for assurance of software integrity, addressed by Remote Attestation <t>The need for assurance of software integrity, addressed by Remote Att
, is a very general problem that could apply to most network-connected computing estation, is a very general problem that could apply to most network-connected c
devices. However, this document includes several assumptions that limit the sc omputing devices. However, this document includes several assumptions that limi
ope to network equipment (e.g., routers, switches and firewalls):</t> t the scope to network equipment (e.g., routers, switches, and firewalls):</t>
<ul spacing="normal">
<t><list style="symbols"> <li>This solution is for use in non-privacy-preserving applications (f
<t>This solution is for use in non-privacy-preserving applications (for exampl or example,
e, networking or industrial Internet of Things (IoT) applications), which avoids th
networking, Industrial IoT), avoiding the need for a Privacy Certificate e need for a Privacy Certification
Authority (also called an Attestation CA) for attestation keys <xref target="AK- Authority (also called an Attestation CA) for Attestation Keys (AKs) <xref targe
Enrollment"/> or TCG Platform t="AIK-ENROLL" format="default"/> or TCG Platform
Certificates <xref target="Platform-Certificates"/>.</t> Certificates <xref target="PLATFORM-CERTS" format="default"/>.</li>
<t>This document assumes network protocols that are common in network equipmen <li>This document assumes network protocols that are common in network
t such as YANG <xref target="RFC7950"/> and NETCONF <xref target="RFC6241"/>, equipment such as YANG <xref target="RFC7950" format="default"/> and Network Co
but not generally used in other applications.</t> nfiguration Protocol (NETCONF) <xref target="RFC6241" format="default"/>,
<t>The approach outlined in this document mandates the use of a TPM <xref targ but not generally used in other applications.</li>
et="TPM1.2"/>, <xref target="TPM2.0"/>, or a compatible cryptoprocessor.</t> <li>The approach outlined in this document mandates the use of a TPM <
</list></t> xref target="TPM-1.2" format="default"/> <xref target="TPM-2.0" format="default"
/> or a compatible cryptoprocessor.</li>
<section anchor="out-of-scope" title="Out of Scope"> </ul>
<section anchor="out-of-scope" numbered="true" toc="default">
<t><list style="symbols"> <name>Out of Scope</name>
<t>Run-Time Attestation: The Linux Integrity Measurement Architecture <xref ta <dl spacing="normal">
rget="IMA"/> attests each process launched <dt>Run-Time Attestation:</dt><dd>The Linux Integrity Measurement Ar
chitecture <xref target="IMA" format="default"/> attests each process launched
after a device is started (and is in scope for RIV in general), but continuous r un-time attestation of Linux or after a device is started (and is in scope for RIV in general), but continuous r un-time attestation of Linux or
other multi-threaded operating system processes after the OS has started conside rably expands the scope of the problem. other multi-threaded operating system processes after the OS has started conside rably expands the scope of the problem.
Many researchers are working on that problem, but this document defers the probl em of continuous, in-memory Many researchers are working on that problem, but this document defers the probl em of continuous, in-memory
run-time attestation.</t> run-time attestation.</dd>
<t>Multi-Vendor Embedded Systems: Additional coordination would be needed for <dt>Multi-Vendor Embedded Systems:</dt><dd> Additional coordination
devices that themselves comprise hardware and software from multiple vendors, would be needed for
devices that themselves comprise hardware and software from multiple vendors and
are
integrated by the end user. Although out of scope for this document, these integrated by the end user. Although out of scope for this document, these
issues are accommodated in <xref target="I-D.ietf-rats-architecture"/>.</t> issues are accommodated in <xref target="RFC9334" format="default"/>.</dd>
<t>Processor Sleep Modes: Network equipment typically does not “sleep”, so <dt>Processor Sleep Modes:</dt><dd>Network equipment typically does
not "sleep", so
sleep and hibernate modes are not considered. Although out of scope sleep and hibernate modes are not considered. Although out of scope
for RIV in this document, Trusted Computing Group specifications do encompass sl for RIV in this document, TCG specifications do encompass sleep and hibernate
eep and hibernate states, which could be incorporated into remote attestation for network equipmen
states, which could be incorporated into remote attestation for network equipmen t in the future, given a compelling need.</dd>
t in the future, given a compelling need.</t> <dt>Virtualization and Containerization:</dt><dd> In a non-virtualiz
<t>Virtualization and Containerization: In a non-virtualized system, the host ed system, the host OS is
OS is responsible for measuring each user-space file or process throughout the operati
responsible for measuring each User Space file or process throughout the operati onal lifetime
onal lifetime
of the system. For virtualized systems, the host OS must verify the hypervisor, of the system. For virtualized systems, the host OS must verify the hypervisor,
but then the hypervisor must manage its own chain of trust through the virtual m achine. Virtualization but then the hypervisor must manage its own chain of trust through the virtual m achine. Virtualization
and containerization technologies are increasingly used in network equipment, bu t and containerization technologies are increasingly used in network equipment, bu t
are not considered in this document.</t> are not considered in this document.</dd>
</list></t> </dl>
</section>
</section> </section>
</section> </section>
</section> <section anchor="solution-overview" numbered="true" toc="default">
<section anchor="solution-overview" title="Solution Overview"> <name>Solution Overview</name>
<section anchor="riv-software-configuration-attestation-using-tpm" numbere
<section anchor="riv-software-configuration-attestation-using-tpm" title="RIV So d="true" toc="default">
ftware Configuration Attestation using TPM"> <name>RIV Software Configuration Attestation Using TPM</name>
<t>RIV Attestation is a process that can be used to determine the identi
<t>RIV Attestation is a process which can be used to determine the identity of s ty of software running
oftware running on a specifically identified device. The Remote Attestation steps of <xref targ
on a specifically-identified device. The Remote Attestation steps of <xref targ et="RIV-desc" format="default"/> are split into two
et="RIV-desc"/> are broken into two phases as shown in <xref target="RIV-Attestation-Model" format="default"/>:</t>
phases, shown in Figure 1:</t> <ul spacing="normal">
<li>During system startup, or Boot Phase, each distinct software objec
<t><list style="symbols"> t is "measured" by the Attester.
<t>During system startup, or boot phase, each distinct software object is “mea The object's identity, hash (i.e., cryptographic digest), and version informatio
sured” by the Attester. n are recorded in a log.
The object’s identity, hash (i.e., cryptographic digest) and version information Hashes are also extended into the TPM (see <xref target="using-tpm" format="defa
are recorded in a log. ult"/> for more on extending hashes) in a way that can be used to validate the l
Hashes are also extended into the TPM (see <xref target="using-tpm"/> for more o og entries. The measurement process generally
n ‘extending hashes’), in a way that can be used to validate the log entries. T
he measurement process generally
follows the layered chain-of-trust model used in Measured Boot, where each stage follows the layered chain-of-trust model used in Measured Boot, where each stage
of the system measures the next one, and extends its measurement into the TPM, of the system measures the next one, and extends its measurement into the TPM,
before launching it. See <xref target="I-D.ietf-rats-architecture"/>, section “ before launching it. See <xref target="RFC9334" sectionFormat="of" section="3.2
Layered Attestation Environments,” for an architectural definition "/>, "Layered Attestation Environments", for an architectural definition
of this model.</t> of this model.</li>
<t>Once the device is running and has operational network connectivity, verifi <li>Once the device is running and has operational network connectivit
cation can take place. A separate y, verification can take place. A separate
Verifier, running in its own trusted environment, will interrogate the network Verifier, running in its own trusted environment, will interrogate the network
device to retrieve the logs and a copy of the digests collected by hashing device to retrieve the logs and a copy of the digests collected by hashing
each software object, signed by an attestation private key secured by, but never released by, each software object, signed by an attestation private key secured by, but never released by,
the TPM. The YANG model described in <xref target="I-D.ietf-rats-yang-tpm-charr the TPM. The YANG model described in <xref target="RFC9684" format="default"/>
a"/> facilitates this operation.</t> facilitates this operation.</li>
</list></t> </ul>
<!-- [rfced] Section 2.1. We're having difficulty parsing the following. Does th
e Verifier validate both the software and the logs, or does it validate the soft
ware with the logs?
<t>The result is that the Verifier can verify the device’s identity by checking Original:
the subject<xref target="RFC5280"/> and signature of the certificate containing The result is that the Verifier can verify the device's identity by
the TPM’s attestation public key, and can checking the subject [RFC5280] and signature of the certificate
containing the TPM's attestation public key, and can validate the
software that was launched by verifying the correctness of the logs
by comparing with the signed digests from the TPM, and comparing
digests in the log with Reference Values.
Perhaps (splitting the passage into two sentences and rephrasing the second sent
ence):
The result is that the Verifier can verify the device's identity by
checking the subject [RFC5280] and signature of the certificate
containing the TPM's attestation public key. The Verifier can also
validate the launched software and verify log correctness by
comparing the log with the signed digests from the TPM and by
comparing the digests in the log with Reference Values.
-->
<t>The result is that the Verifier can verify the device's identity by c
hecking
the subject <xref target="RFC5280" format="default"/> and signature of the certi
ficate containing the TPM's attestation public key, and can
validate the software that was launched by verifying the correctness of the logs by comparing with the validate the software that was launched by verifying the correctness of the logs by comparing with the
signed digests from the TPM, and comparing digests in the log with signed digests from the TPM, and comparing digests in the log with
Reference Values.</t> Reference Values.</t>
<t>It should be noted that attestation and identity are inextricably lin
<t>It should be noted that attestation and identity are inextricably linked; ked;
signed Evidence that a particular version of software was loaded is of little signed Evidence that a particular version of software was loaded is of little
value without cryptographic proof of the identity of the Attester producing value without cryptographic proof of the identity of the Attester producing
the Evidence.</t> the Evidence.</t>
<figure anchor="RIV-Attestation-Model">
<figure title="Layered RIV Attestation Model" anchor="RIV-Attestation-Model"><ar <name>Layered RIV Attestation Model</name>
twork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
+-------------------------------------------------------+ +-------------------------------------------------------+
| +---------+ +--------+ +--------+ +---------+ | | +---------+ +--------+ +--------+ +---------+ |
| |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | | | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
| +---------+ +--------+ +--------+ +---------+ | | +---------+ +--------+ +--------+ +---------+ |
| | | | | | | | | |
| | | | | | | | | |
| +------------+-----------+-+ | | +------------+-----------+-+ |
| Boot Phase | | | Boot Phase | |
| V | | V |
| +--------+ | | +--------+ |
skipping to change at line 361 skipping to change at line 380
| +--------+ | | +--------+ |
| Router | | | Router | |
+--------------------------------|----------------------+ +--------------------------------|----------------------+
| |
| Verification Phase | Verification Phase
| +-----------+ | +-----------+
+--->| Verifier | +--->| Verifier |
+-----------+ +-----------+
Reset---------------flow-of-time-during-boot...---------> Reset---------------flow-of-time-during-boot...--------->
]]></artwork></figure> ]]></artwork>
</figure>
<t>In the Boot phase, measurements are “extended”, or hashed, into the TPM as pr <t>In the Boot Phase, measurements are "extended", or hashed, into the T
ocesses start, PM as processes start,
with the result that the TPM ends up containing hashes of all the measured hashe which result in the TPM containing hashes of all the measured hashes. Later, onc
s. Later, once the system is operational, during the Verification phase, signed e the system is operational, signed
digests are retrieved from the TPM for off-box analysis.</t> digests are retrieved from the TPM during the Verification Phase for off-box ana
lysis.</t>
<section anchor="what-does-riv-attest" title="What Does RIV Attest?"> <section anchor="what-does-riv-attest" numbered="true" toc="default">
<name>What Does RIV Attest?</name>
<t>TPM attestation is focused on Platform Configuration Registers (PCRs), but th <t>TPM attestation is focused on PCRs, but those registers are only ve
ose registers are only vehicles for certifying hicles for certifying
accompanying Evidence, conveyed in log entries. It is the hashes in log entries accompanying Evidence conveyed in log entries. It is the hashes in log entries
that are extended into PCRs, where the final PCR values that are extended into PCRs, where the final PCR values
can be retrieved in the form of a structure called a Quote, signed by an Attesta can be retrieved in the form of a structure called a Quote, which is signed by a
tion key known only to the TPM. The use of multiple PCRs serves only to n AK known only to the TPM. The use of multiple PCRs serves only to
provide some independence between different classes of object, so that one class provide some independence between different classes of object so that one class
of objects can be updated without changing the of objects can be updated without changing the
extended hash for other classes. Although PCRs can be used for any purpose, thi s section outlines the objects within the extended hash for other classes. Although PCRs can be used for any purpose, thi s section outlines the objects within the
scope of this document which may be extended into the TPM.</t> scope of this document that may be extended into the TPM.</t>
<t>In general, assignment of measurements to PCRs is a policy choice m
<t>In general, assignment of measurements to PCRs is a policy choice made by the ade by the device manufacturer, selected to independently attest three classes o
device manufacturer, selected to independently attest three classes of object:< f object:</t>
/t> <dl>
<dt>Code:</dt>
<t><list style="symbols"> <dd>Instructions to be executed by a CPU.</dd>
<t>Code, (i.e., instructions) to be executed by a CPU.</t> <dt>Configuration:</dt>
<t>Configuration - Many devices offer numerous options controlled by non-volat <dd>Many devices offer numerous options controlled by non-volatile c
ile configuration variables which can impact the device’s security posture. The onfiguration variables that can impact the device's security posture. These set
se settings may have vendor defaults, but often can be changed by administrators tings may have vendor defaults, but often can be changed by administrators, who
, who may want to verify via attestation that the operational state of the setti may want to verify via attestation that the operational state of the settings ma
ngs match their intended state.</t> tch their intended state.</dd>
<t>Credentials - Administrators may wish to verify via attestation that public <dt>Credentials:</dt>
keys and credentials outside the Root of Trust have not been subject to unautho <dd>Administrators may wish to verify via attestation that public ke
rized tampering. (By definition, keys protecting the root of trust can’t be ver ys and credentials outside the Root of Trust have not been subject to unauthoriz
ified independently.)</t> ed tampering. (By definition, keys protecting the Root of Trust can't be verifi
</list></t> ed independently.)</dd>
</dl>
<t>The TCG PC Client Platform Firmware Profile Specification <xref target="PC-Cl <t>The "TCG PC Client Specific Platform Firmware Profile Specification
ient-BIOS-TPM-2.0"/> gives considerable detail on what is to be " <xref target="PC-CLIENT-BIOS-TPM-2.0" format="default"/> details what is to be
measured during the boot phase of platform startup using a UEFI BIOS (www.uefi.o measured during the Boot Phase of platform startup using a Unified Extensible Fi
rg), but the goal is simply to measure every bit of rmware Interface (UEFI) BIOS (<eref target="www.uefi.org" brackets="angle"/>), b
ut the goal is simply to measure every bit of
code executed in the process of starting the device, along with any configuratio n information related to security posture, leaving code executed in the process of starting the device, along with any configuratio n information related to security posture, leaving
no gap for unmeasured code to remain undetected, potentially subverting the chai no gap for unmeasured code to remain undetected and potentially subverting the c
n.</t> hain.</t>
<t>For devices using a UEFI BIOS, <xref target="PC-CLIENT-BIOS-TPM-2.0
<t>For devices using a UEFI BIOS, <xref target="PC-Client-BIOS-TPM-2.0"/> and <x " format="default"/> and <xref target="PC-CLIENT-EFI-TPM-1.2" format="default"/>
ref target="PC-Client-EFI-TPM-1.2"/> give detailed normative requirements for PC give detailed normative requirements for PCR usage. For other
R usage. For other platform architectures, where TCG normative requirements currently do not exist,
platform architectures, where TCG normative requirements currently do not exist, <xref target="Attested-Objects" format="default"/> gives non-normative guidance
the table in <xref target="Attested-Objects"/> gives non-normative guidance for for PCR assignment that generalizes the specific
PCR assignment that generalizes the specific details of <xref target="PC-CLIENT-BIOS-TPM-2.0" format="default"/>.</t>
details of <xref target="PC-Client-BIOS-TPM-2.0"/>.</t> <t>By convention, most PCRs are assigned in pairs, with the even-numbe
red PCR used to measure executable code and
<t>By convention, most PCRs are assigned in pairs, which the even-numbered PCR u
sed to measure executable code, and
the odd-numbered PCR used to measure whatever data and configuration are associa ted with that code. It is important the odd-numbered PCR used to measure whatever data and configuration are associa ted with that code. It is important
to note that each PCR may contain results from dozens (or even thousands) of ind ividual measurements.</t> to note that each PCR may contain results from dozens (or even thousands) of ind ividual measurements.</t>
<!-- [rfced] Section 2.1.1. Please review the numbers in Table 2. Should Vendor- Specific Measurements and Measurements made by OS have the same Code and Configu ration number? Is Secure Boot Policy missing a PCR Code?
<figure title="Attested Objects" anchor="Attested-Objects"><artwork align="left" Original:
><![CDATA[
+------------------------------------------------------------------+
| | Assigned PCR # |
| Function | Code | Configuration|
| Firmware Static Root of Trust, (i.e., | 0 | 1 |
| initial boot firmware and drivers) | | |
| Drivers and initialization for optional | 2 | 3 |
| or add-in devices | | |
| OS Loader code and configuration, (i.e., | 4 | 5 |
| the code launched by firmware) to load an | | |
| operating system kernel. These PCRs record | | |
| each boot attempt, and an identifier for | | |
| where the loader was found | | |
| Vendor Specific Measurements during boot | 6 | 6 |
| Secure Boot Policy. This PCR records keys | | 7 |
| and configuration used to validate the OS | | |
| loader | | |
| Measurements made by the OS Loader | 8 | 9 |
| (e.g. GRUB2 for Linux) | | |
| Measurements made by OS (e.g., Linux IMA) | 10 | 10 |
+------------------------------------------------------------------+
]]></artwork></figure>
</section> +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
<section anchor="notes-on-pcr-allocations" title="Notes on PCR Allocations"> | | Assigned PCR # |
| Function | Code | Configuration|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Firmware Static Root of Trust, (i.e., | 0 | 1 |
| initial boot firmware and drivers) | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Drivers and initialization for optional | 2 | 3 |
| or add-in devices | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| OS Loader code and configuration, (i.e., | 4 | 5 |
| the code launched by firmware) to load an | | |
| operating system kernel. These PCRs record | | |
| each boot attempt, and an identifier for | | |
| where the loader was found | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Vendor Specific Measurements during boot | 6 | 6 |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Secure Boot Policy. This PCR records keys | | 7 |
| and configuration used to validate the OS | | |
| loader | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Measurements made by the OS Loader | 8 | 9 |
| (e.g. GRUB2 for Linux) | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Measurements made by OS (e.g., Linux IMA) | 10 | 10 |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
-->
<table anchor="Attested-Objects">
<name>Attested Objects</name>
<thead>
<tr>
<th></th>
<th rowspan="" colspan="2"> Assigned PCR #</th>
</tr>
<tr>
<th>Function</th>
<th>Code</th>
<th>Configuration</th>
</tr>
</thead>
<tbody>
<tr>
<td>Firmware Static Root of Trust (i.e., initial boot firmware
and drivers)</td>
<td>0</td>
<td>1</td>
</tr>
<tr>
<td>Drivers and initialization for optional or add-in devices</
td>
<td>2</td>
<td>3</td>
</tr>
<tr>
<td>OS loader code and configuration (i.e., the code launched b
y firmware) to load an operating system kernel. These PCRs record each boot att
empt, and an identifier for where the loader was found</td>
<td>4</td>
<td>5</td>
</tr>
<tr>
<td>Vendor-specific measurements during boot</td>
<td>6</td>
<td>6</td>
</tr>
<tr>
<td>Secure Boot Policy. This PCR records keys and configuratio
n used to validate the OS loader</td>
<td></td>
<td>7</td>
</tr>
<tr>
<td> Measurements made by the OS loader (e.g., GRUB2 for Linux)
</td>
<td>8</td>
<td>9</td>
</tr>
<tr>
<td>Measurements made by OS (e.g., Linux IMA)</td>
<td>10</td>
<td>10</td>
</tr>
</tbody>
</table>
<t>It is important to recognize that PCR[0] is critical. The first measurement </section>
into PCR[0] is taken by the Root of Trust for <section anchor="notes-on-pcr-allocations" numbered="true" toc="default"
Measurement, code which, by definition, cannot be verified by measurement. This >
measurement <name>Notes on PCR Allocations</name>
<t>It is important to recognize that PCR[0] is critical. The first me
asurement into PCR[0] is taken by the Root of Trust for
Measurement, which is code that, by definition, cannot be verified by measuremen
t. This measurement
establishes the chain of trust for all subsequent measurements. If the PCR[0] m easurement cannot be trusted, the establishes the chain of trust for all subsequent measurements. If the PCR[0] m easurement cannot be trusted, the
validity of the entire chain is put into question.</t> validity of the entire chain is called into question.</t>
<t>Distinctions between PCR[0], PCR[2], PCR[4], and PCR[8] are summari
<t>Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized below:< zed below:</t>
/t> <dl spacing="normal">
<dt>PCR[0]</dt><dd>typically represents a consistent view of rarely
<t><list style="symbols"> changed boot components of the host platform, which allows Attestation policies
<t>PCR[0] typically represents a consistent view of rarely-changed Host Platfo to be defined using the less changeable components of the transitive trust chain
rm boot components, allowing Attestation policies to be defined using the less c . This PCR
hangeable components of the transitive trust chain. This PCR typically provides a consistent view of the platform regardless of user-selected
typically provides a consistent view of the platform regardless of user selected options.</dd>
options.</t> <dt>PCR[2]</dt><dd>is intended to represent a "user-configurable" en
<t>PCR[2] is intended to represent a “user configurable” environment where the vironment where the user has the ability to alter the
user has the ability to alter the
components that are measured into PCR[2]. This is typically done by adding adapt er cards, etc., into user-accessible components that are measured into PCR[2]. This is typically done by adding adapt er cards, etc., into user-accessible
PCI or other slots. In UEFI systems these devices may be configured by Option R Peripheral Component Interconnect (PCI) or other slots. In UEFI systems, these
OMs measured into PCR[2] and devices may be configured by Option ROMs measured into PCR[2] and
executed by the UEFI BIOS.</t> executed by the UEFI BIOS.</dd>
<t>PCR[4] is intended to represent the software that manages the transition be <dt>PCR[4]</dt><dd>is intended to represent the software that manage
tween the platform’s Pre-Operating System s the transition between the platform's pre-OS
start and the state of a system with the Operating System present. This PCR, al start and the state of a system with the OS present. This PCR, along with PCR[5
ong with PCR[5], identifies the initial ], identifies the initial
operating system loader (e.g., GRUB for Linux).</t> OS loader (e.g., GRUB for Linux).</dd>
<t>PCR[8] is used by the OS loader (e.g. GRUB) to record measurements of the v <dt>PCR[8]</dt><dd>is used by the OS loader (e.g., GRUB) to record m
arious components of the operating system.</t> easurements of the various components of the operating system.</dd>
</list></t> </dl>
<t>Although <xref target="PC-CLIENT-BIOS-TPM-2.0" format="default"/> s
<t>Although the TCG PC Client document specifies the use of the first eight PCRs pecifies the use of the first eight PCRs very carefully to ensure interoperabili
very carefully to ensure interoperability ty
among multiple among multiple
UEFI BIOS vendors, it should be noted that embedded software vendors may have co nsiderably more flexibility. Verifiers UEFI BIOS vendors, it should be noted that embedded software vendors may have co nsiderably more flexibility. Verifiers
typically need to know which log entries are consequential and which are not (po ssibly controlled by local policies) but typically need to know which log entries are consequential and which are not (po ssibly controlled by local policies), but
the Verifier may not need to know what each log entry means or why it was assign ed to a particular PCR. Designers must the Verifier may not need to know what each log entry means or why it was assign ed to a particular PCR. Designers must
recognize that some PCRs may cover log entries that a particular Verifier consid ers critical and other log entries that recognize that some PCRs may cover log entries that a particular Verifier consid ers critical and other log entries that
are not considered important, so differing PCR values may not on their own const are not considered important, so differing PCR values may not on their own const
itute a check for authenticity. For example, in a UEFI system, some administrat itute a check for authenticity. For example, in a UEFI system, some administrat
ors may consider booting an image from a removable drive, something recorded in ors may consider booting an image from a removable drive, something recorded in
a PCR, to be a security violation, while others might consider that operation an a PCR, to be a security violation, while others might consider that operation to
authorized recovery procedure.</t> be an authorized recovery procedure.</t>
<t>Designers may allocate particular events to specific PCRs in order
<t>Designers may allocate particular events to specific PCRs in order to achieve to achieve a particular objective with local
a particular objective with local attestation (e.g., allowing a procedure to execute, or releasing a particular de
attestation, (e.g., allowing a procedure to execute, or releasing a particular d cryption key, only if a given PCR is in a given state). It may also be importan
ecryption key, only if a given PCR is in a given state). It may also be importa t
nt to designers to consider whether streaming notification of PCR updates is requir
to designers to consider whether streaming notification of PCR updates is requir ed (see <xref target="I-D.ietf-rats-network-device-subscription" format="default
ed (see <xref target="I-D.birkholz-rats-network-device-subscription"/>). Specif "/>). Specific
ic
log entries can only be validated if the Verifier receives every log entry affec ting the relevant PCR, so (for example) log entries can only be validated if the Verifier receives every log entry affec ting the relevant PCR, so (for example)
a designer might want to separate rare, high-value events such as configuration a designer might want to separate rare, high-value events, such as configuration
changes, from high-volume, routine changes, from high-volume, routine
measurements such as IMA <xref target="IMA"/> logs.</t> measurements such as IMA logs <xref target="IMA" format="default"/>.</t>
</section>
</section> </section>
</section> <section anchor="riv-keying" numbered="true" toc="default">
<section anchor="riv-keying" title="RIV Keying"> <name>RIV Keying</name>
<t>RIV attestation relies on two credentials:</t>
<t>RIV attestation relies on two credentials:</t> <ul spacing="normal">
<li>An identity key pair and matching certificate is required to certi
<t><list style="symbols"> fy the identity of the Attester itself.
<t>An identity key pair and matching certificate is required to certify the id RIV specifies the use of an IEEE 802.1AR DevID <xref target="IEEE-802-1AR" forma
entity of the Attester itself. t="default"/> that is
RIV specifies the use of an IEEE 802.1AR Device Identity (DevID) <xref target="I signed by the device manufacturer and contains the device serial number. This r
EEE-802-1AR"/>, equirement goes slightly
signed by the device manufacturer, containing the device serial number. This re beyond 802.1AR; see <xref target="riv-simplify" format="default"/> for notes.</l
quirement goes slightly i>
beyond 802.1AR; see <xref target="riv-simplify"/> for notes.</t> <li>An Attestation key pair and matching certificate is required to si
<t>An Attestation key pair and matching certificate is required to sign the Qu gn the Quote generated by the TPM to report evidence
ote generated by the TPM to report evidence of software configuration.</li>
of software configuration.</t> </ul>
</list></t> <t>In a TPM application, both the Attestation private key and the DevID
private key <bcp14>MUST</bcp14> be protected by the TPM.
<t>In a TPM application, both the Attestation private key and the DevID private
key MUST be protected by the TPM.
Depending on other TPM configuration procedures, Depending on other TPM configuration procedures,
the two keys are likely to be different; some of the considerations are outlined the two keys are likely to be different; some of the considerations are outlined
in TCG in the
“TPM 2.0 Keys for Device Identity and Attestation” <xref target="Platform-DevID- "TPM 2.0 Keys for Device Identity and Attestation" document <xref target="PLATFO
TPM-2.0"/>.</t> RM-DEVID-TPM-2.0" format="default"/>.</t>
<t>The "TPM 2.0 Keys for Device Identity and Attestation" document <xref
target="PLATFORM-DEVID-TPM-2.0" format="default"/> specifies further convention
s for these keys:</t>
<ul spacing="normal">
<!-- [rfced] Section 2.2. In the following sentence, it is unclear what is exami
ng the certificate. Does the suggestion correctly clarify the actor?
<t>The TCG TPM 2.0 Keys document <xref target="Platform-DevID-TPM-2.0"/> specifi Original:
es further conventions for these keys:</t> This allows a quote from the device, signed by an AK, to be
linked directly to the device that provided it, by examining
the corresponding AK certificate.
<t><list style="symbols"> Perhaps:
<t>When separate Identity and Attestation keys are used, the Attestation By examining the corresponding AK certificate, the Verifier
Key (AK) and its X.509 certificate should parallel the DevID, with the same uniq can directly link a device's quote, which was signed by an
ue AK, to the device that provided it.
-->
<li>When separate Identity and Attestation keys are used, the
AK and its X.509 certificate should parallel the DevID, with the same unique
device identification as the DevID certificate (that is, the same subject and su bjectAltName (if present), even though the key pairs are different). This allow s device identification as the DevID certificate (that is, the same subject and su bjectAltName (if present), even though the key pairs are different). This allow s
a quote from the device, signed by an AK, to be linked directly to the a quote from the device, signed by an AK, to be linked directly to the
device that provided it, by examining the corresponding AK certificate. If the device that provided it, by examining the corresponding AK certificate. If the
subject in the AK certificate doesn’t match the corresponding DevID certificate, subject in the AK certificate doesn't match the corresponding DevID certificate,
or or
they’re signed by differing authorities the Verifier may signal the detection o if they're signed by different authorities, the Verifier may signal the detecti
f an Asokan-style person-in-the-middle attack (see <xref target="pitm"/>).</t> on of an Asokan-style person-in-the-middle attack (see <xref target="pitm" forma
<t>Network devices that are expected to use secure zero touch provisioning as t="default"/>).</li>
specified in <xref target="RFC8572"/> <li>Network devices that are expected to use SZTP as
MUST be shipped by the manufacturer with pre-provisioned keys (Initial DevID and specified in <xref target="RFC8572" format="default"/>
Initial AK, <bcp14>MUST</bcp14> be shipped by the manufacturer with pre-provisioned keys (In
called IDevID and IAK). IDevID and IAK certificates MUST both be signed by the itial DevID and Initial AK,
Endorser called IDevID and IAK, respectively). IDevID and IAK certificates <bcp14>MUST</
bcp14> both be signed by the Endorser
(typically the device manufacturer). Inclusion of an IDevID and IAK by a vendor does not (typically the device manufacturer). Inclusion of an IDevID and IAK by a vendor does not
preclude a mechanism whereby an administrator can define Local Identity and preclude a mechanism whereby an administrator can define LDevID and
Attestation Keys (LDevID and LAK) if desired.</t> Local Attestation Keys (LAK) if desired.</li>
</list></t> </ul>
</section>
</section> <section anchor="RIV-flow" numbered="true" toc="default">
<section anchor="RIV-flow" title="RIV Information Flow"> <name>RIV Information Flow</name>
<t>RIV workflow for network equipment is organized around a simple use c
<t>RIV workflow for network equipment is organized around a simple use case ase
where a network operator wishes to verify the integrity of software installed where a network operator wishes to verify the integrity of software installed
in specific, fielded devices. A normative taxonomy of terms is given in <xref t arget="I-D.ietf-rats-architecture"/>, in specific, fielded devices. A normative taxonomy of terms is given in <xref t arget="RFC9334" format="default"/>,
but as a reminder, this use case implies several roles and objects:</t> but as a reminder, this use case implies several roles and objects:</t>
<dl spacing="normal">
<t><list style="numbers"> <dt>Attester:</dt>
<t>The Attester, the device which the network operator wants to examine.</t> <dd>The device that the network operator wants to examine.</dd>
<t>A Verifier (which might be a network management station) somewhere separate <dt>Verifier:</dt>
<dd>Which might be a Network Management Station and is somewhat separa
te
from the Device that will retrieve the signed evidence and measurement logs, a nd analyze them to pass from the Device that will retrieve the signed evidence and measurement logs, a nd analyze them to pass
judgment on the security posture of the device.</t> judgment on the security posture of the device.</dd>
<t>A Relying Party, which can act on Attestation Results. Interaction between <dt>Relying Party:</dt>
the Relying Party and the <dd>Can act on Attestation Results. Interaction between the Relying P
Verifier is considered out of scope for RIV.</t> arty and the
<t>Signed Reference Integrity Manifests (RIMs), containing Reference Values, c Verifier is considered out of scope for RIV.</dd>
an <dt>Signed Reference Integrity Manifests (RIMs):</dt>
<dd>Contains Reference Values. RIMs can
either be created by the device manufacturer either be created by the device manufacturer
and shipped along with the device as part of its software image, or alternativ ely, and shipped along with the device as part of its software image, or alternativ ely,
could be obtained several other ways (direct to the Verifier from the 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 manufacturer, from a third party, from the owner's concept
thought to be a “known good system”, etc.). Retrieving RIMs from the device of a "known good system", etc.). Retrieving RIMs from the device
itself allows attestation to be done in systems that may not have access 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 to the public Internet, or by other devices that are not management stations
per se (e.g., a peer device; see <xref target="RIM-policy"/>). If Reference V per se (e.g., a peer device; see <xref target="RIM-policy" format="default"/>)
alues are obtained from . If Reference Values are obtained from
multiple sources, the Verifier may need to evaluate the relative level of multiple sources, the Verifier may need to evaluate the relative level of
trust to be placed in each source in case of a discrepancy.</t> trust to be placed in each source in case of a discrepancy.</dd>
</list></t> </dl>
<t>These components are illustrated in <xref target="RIV-Reference-Confi
<t>These components are illustrated in <xref target="RIV-Reference-Configuration guration" format="default"/>.</t>
"/>.</t> <figure anchor="RIV-Reference-Configuration">
<name>RIV Reference Configuration for Network Equipment</name>
<figure title="RIV Reference Configuration for Network Equipment" anchor="RIV-Re <artwork align="left" name="" type="" alt=""><![CDATA[
ference-Configuration"><artwork align="left"><![CDATA[
+----------------+ +-------------+ +---------+--------+ +----------------+ +-------------+ +---------+--------+
|Reference Value | | Attester | Step 1 | Verifier| | |Reference Value | | Attester | Step 1 | Verifier| |
|Provider | | (Device |<-------| (Network| Relying| |Provider | | (Device |<-------| (Network| Relying|
|(Device | | under |------->| Mngmt | Party | |(Device | | under |------->| Mgmt | Party |
|Manufacturer | | attestation)| Step 2 | Station)| | |Manufacturer | | attestation)| Step 2 | Station)| |
|or other | | | | | | |or other | | | | | |
|authority) | | | | | | |authority) | | | | | |
+----------------+ +-------------+ +---------+--------+ +----------------+ +-------------+ +---------+--------+
| /\ | /\
| Step 0 | | Step 0 |
----------------------------------------------- -----------------------------------------------
]]></artwork>
</figure>
<ol spacing="normal" type="Step %d:" start="0" indent="9">
<li>The Reference Value Provider (the device manufacturer or other aut
hority) makes
one or more RIMs, which correspond to the software image expected to be found on
the device and are signed by the Reference Value Provider, available to the Ver
ifier.
(See <xref target="RIM-policy" format="default"/> for "in-band" and "out of band
" ways to make this happen.)</li>
<li>On behalf of a Relying Party, the Verifier (Network Management Sta
tion) requests DevID,
Measurement Values, and possibly RIMs from the Attester.</li>
<li>The
Attester responds to the request by providing a DevID, quotes (measured values t
hat are signed by the Attester),
and optionally RIMs.</li>
</ol>
<t>The use of the following standards components allows for interoperabi
lity:</t>
<ol spacing="normal" type="1"><li>TPM keys <bcp14>MUST</bcp14> be config
ured according to <xref target="PLATFORM-DEVID-TPM-2.0" format="default"/> or <x
ref target="PLATFORM-ID-TPM-1.2" format="default"/>.</li>
<li>For devices using UEFI and Linux, measurements of firmware and boo
table modules <bcp14>MUST</bcp14> be taken according to "TCG EFI Platform Specif
ication" <xref target="PC-CLIENT-EFI-TPM-1.2" format="default"/> or "TCG PC Clie
nt Specific Platform Firmware Profile Specification" <xref target="PC-CLIENT-BIO
S-TPM-2.0" format="default"/>, and Linux IMA <xref target="IMA" format="default"
/>.</li>
<li>DevID <bcp14>MUST</bcp14> be managed as DevID certificates as spec
ified in IEEE Std 802.1AR <xref target="IEEE-802-1AR" format="default"/>, with k
eys protected by TPMs.</li>
<li>Attestation logs from Linux-based systems <bcp14>MUST</bcp14> be f
ormatted according to the "Canonical Event Log Format" <xref target="CEL" format
="default"/>. UEFI-based systems <bcp14>MUST</bcp14> use the TCG UEFI BIOS even
t log <xref target="PC-CLIENT-EFI-TPM-1.2" format="default"/> for TPM 1.2 system
s and the "TCG PC Client Specific Platform Firmware Profile" <xref target="PC-CL
IENT-BIOS-TPM-2.0" format="default"/> for TPM 2.0 systems.</li>
<li>Quotes <bcp14>MUST</bcp14> be retrieved from the TPM according to
the TCG Trusted Attestation Protocol Information Model (TAP IM) <xref target="TA
P" format="default"/> and the Challenge-Response-based Remote Attestation (CHARR
A) YANG model <xref target="RFC9684" format="default"/>. While the TAP IM gives
a protocol-independent description of the data elements involved, it's importan
t to note that quotes from the TPM are signed inside the TPM and <bcp14>MUST</bc
p14> be retrieved in a way that does not invalidate the signature, to preserve t
he trust model. The CHARRA YANG model <xref target="RFC9684" format="default"/>
is used for this purpose. (See <xref target="security-cons" format="default"/>
, Security Considerations).</li>
<!-- [rfced] Section 2.3. Are Reference Values encoded in two ways (SWID and CoS
WID) or three ways (SWID, NIST interoperable SWID tags, and COSWID)?
]]></artwork></figure> Original:
6. Reference Values MUST be encoded as defined in the TCG RIM
<t><list style="symbols"> document [RIM], typically using SWID [SWID], [NIST-IR-8060] or
<t>In Step 0, The Reference Value Provider (the device manufacturer or other a CoSWID tags [I-D.ietf-sacm-coswid].
uthority) 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
(see <xref target="RIM-policy"/> for “in-band” and “out of band” ways to make th
is happen).</t>
<t>In Step 1,
the Verifier (Network Management Station), on behalf of a Relying Party, request
s Identity,
Measurement Values, and possibly RIMs, from the Attester.</t>
<t>In Step 2, the
Attester responds to the request by providing a DevID, quotes (measured values,
signed by the Attester),
and optionally RIMs.</t>
</list></t>
<t>Use of the following standards components allows for interoperability:</t>
<t><list style="numbers">
<t>TPM Keys MUST be configured according to <xref target="Platform-DevID-TPM-2
.0"/>, or <xref target="Platform-ID-TPM-1.2"/>.</t>
<t>For devices using UEFI and Linux, measurements of firmware and bootable mod
ules MUST be taken according to TCG PC Client <xref target="PC-Client-EFI-TPM-1.
2"/> or <xref target="PC-Client-BIOS-TPM-2.0"/>, and Linux IMA <xref target="IMA
"/>.</t>
<t>Device Identity MUST be managed as specified in IEEE 802.1AR Device Identit
y certificates <xref target="IEEE-802-1AR"/>, with keys protected by TPMs.</t>
<t>Attestation logs from Linux-based systems MUST be formatted according to th
e Canonical Event Log format <xref target="Canonical-Event-Log"/>. UEFI-based s
ystems MUST use the TCG UEFI BIOS event log <xref target="PC-Client-EFI-TPM-1.2"
/> for TPM1.2 systems, and TCG PC Client Platform Firmware Profile <xref target=
"PC-Client-BIOS-TPM-2.0"/> for TPM2.0.</t>
<t>Quotes MUST be retrieved from the TPM according to TCG TAP Information Mode
l <xref target="TAP"/> and the CHARRA YANG model <xref target="I-D.ietf-rats-yan
g-tpm-charra"/>. While the TAP IM gives a protocol-independent description of t
he data elements involved, it’s important to note that quotes from the TPM are s
igned inside the TPM, and MUST be retrieved in a way that does not invalidate th
e signature, to preserve the trust model. The <xref target="I-D.ietf-rats-yang-
tpm-charra"/> is used for this purpose. (See <xref target="security-cons"/> Sec
urity Considerations).</t>
<t>Reference Values MUST be encoded as defined in
the TCG RIM document <xref target="RIM"/>, typically using SWID <xref target="
SWID"/>, <xref target="NIST-IR-8060"/> or CoSWID tags <xref target="I-D.ietf-sac
m-coswid"/>.</t>
</list></t>
</section>
<section anchor="riv-simplify" title="RIV Simplifying Assumptions">
<t>This document makes the following simplifying assumptions to reduce complexit Perhaps (encoding is done in one of two ways):
y:</t> 6. Reference Values MUST be encoded as defined in the TCG RIM
document [RIM], typically using SWID tags [SWID] [NIST-IR-8060] or
CoSWID tags [RFC9393].
-->
<t><list style="symbols"> <li>Reference Values <bcp14>MUST</bcp14> be encoded as defined in
<t>The product to be attested MUST be shipped by the equipment vendor with bot the TCG RIM document <xref target="RIM" format="default"/>, typically using So
h an IEEE 802.1AR Device Identity and an Initial ftware Identification (SWID) <xref target="SWID" format="default"/>, <xref targe
Attestation Key (IAK), with certificates in place. The IAK certificate must con t="NIST-IR-8060" format="default"/>, or Concise SWID (CoSWID) tags <xref target=
tain the same identity "RFC9393" format="default"/>.</li>
</ol>
</section>
<section anchor="riv-simplify" numbered="true" toc="default">
<name>RIV Simplifying Assumptions</name>
<t>This document makes the following simplifying assumptions to reduce c
omplexity:</t>
<ul spacing="normal">
<li>The product to be attested <bcp14>MUST</bcp14> be shipped by the e
quipment vendor with both a DevID as specified by IEEE Std 802.1AR and an IAK, w
ith certificates in place. The IAK certificate must contain the same identity
information as the DevID (specifically, the same subject and subjectAltName (if used), signed by the manufacturer). The IAK is a type of key that can be information as the DevID (specifically, the same subject and subjectAltName (if used), signed by the manufacturer). The IAK is a type of key that can be
used to sign a TPM Quote, but not other objects (i.e., it’s marked as a TCG “Res tricted” key; used to sign a TPM Quote, but not other objects (i.e., it's marked as a TCG "Res tricted" key;
this convention is described in this convention is described in
“TPM 2.0 Keys for Device Identity and Attestation” <xref target="Platform-DevID- TPM-2.0"/>). For network equipment, which is generally non-privacy-sensitive, sh ipping "TPM 2.0 Keys for Device Identity and Attestation" <xref target="PLATFORM-DEVID- TPM-2.0" format="default"/>). For network equipment, which is generally not priv acy sensitive, shipping
a device with both an IDevID and an IAK already provisioned substantially a device with both an IDevID and an IAK already provisioned substantially
simplifies initial startup.</t> simplifies initial startup.</li>
<t>IEEE 802.1AR does not require a product serial number as part of the subjec <li>
t, but RIV-compliant <t>IEEE Std 802.1AR does not require a product serial number as part
devices MUST include their serial numbers in the DevID/IAK certificates to simpl of the subject, but RIV-compliant
ify tracking logistics devices <bcp14>MUST</bcp14> include their serial numbers in the DevID/IAK certif
icates to simplify tracking logistics
for network equipment users. All other optional for network equipment users. All other optional
802.1AR fields remain optional in RIV.<vspace /> 802.1AR fields remain optional in RIV.</t>
It should be noted that 802.1AR use of X.509 certificate fields <t>
is not identical to those descsribed in <xref target="RFC6125"/> for representat It should be noted that the use of X.509 certificate fields as specified by IEEE
ion of application service identity.</t> Std 802.1AR
<t>The product MUST be equipped with a Root of Trust for Measurement (RTM), Ro is not identical to that described in <xref target="RFC9525" format="default"/>
ot of Trust for representation of application service identity.</t>
for Storage and Root of Trust for Reporting (as defined in <xref target="SP800-1 </li>
55"/>) which together are <li>The product <bcp14>MUST</bcp14> be equipped with an RTM, a Root of
capable of conforming to TCG Trusted Attestation Protocol Information Model <xre Trust
f target="TAP"/>.</t> for Storage, and a Root of Trust for Reporting (as defined in <xref target="SP80
<t>The authorized software supplier MUST make available Reference Values 0-155" format="default"/>), which together are
in the form of signed SWID or CoSWID tags.</t> capable of conforming to the TCG TAP IM <xref target="TAP" format="default"/>.</
</list></t> li>
<li>The authorized software supplier <bcp14>MUST</bcp14> make availabl
<section anchor="RIM-section" title="Reference Integrity Manifests (RIMs)"> e Reference Values
in the form of signed SWID or CoSWID tags.</li>
<t><xref target="I-D.ietf-rats-yang-tpm-charra"/> focuses on collecting and tran </ul>
smitting evidence in <section anchor="RIM-section" numbered="true" toc="default">
<name>Reference Integrity Manifests (RIMs)</name>
<t><xref target="RFC9684" format="default"/> focuses on collecting and
transmitting evidence in
the form of PCR measurements and attestation logs. But the critical part the form of PCR measurements and attestation logs. But the critical part
of the process is enabling the Verifier to decide whether the measurements of the process is enabling the Verifier to decide whether the measurements
are “the right ones” or not.</t> are "the right ones" or not.</t>
<t>While it must be up to network administrators to decide what they w
<t>While it must be up to network administrators to decide what they want on ant on
their networks, the software supplier should supply the Reference Values, in their networks, the software supplier should supply the Reference Values, in
signed Reference Integrity Manifests, that signed RIMs, that
may be used by a Verifier to determine if evidence shows known good, known may be used by a Verifier to determine if evidence shows known good, known
bad or unknown software configurations.</t> bad, or unknown software configurations.</t>
<t>In general, there are two kinds of reference measurements:</t>
<t>In general, there are two kinds of reference measurements:</t> <ol spacing="normal" type="1"><li>Measurements of early system startup
(e.g., BIOS, boot loader, OS kernel)
<t><list style="numbers"> are essentially single threaded and executed exactly once, in a known sequence,
<t>Measurements of early system startup (e.g., BIOS, boot loader, OS kernel) before any results can be reported. In this case, while the method for
are essentially single-threaded, and executed exactly once, in a known sequence,
before any results could be reported. In this case, while the method for
computing the hash and extending relevant PCRs may be complicated, the net computing the hash and extending relevant PCRs may be complicated, the net
result is that the software (more likely, firmware) vendor will have one result is that the software (more likely, firmware) vendor will have one
known good PCR value that “should” be present in the relevant PCRs after the box has known good PCR value that "should" be present in the relevant PCRs after the box has
booted. In this case, the signed reference measurement could simply list the booted. In this case, the signed reference measurement could simply list the
expected hashes for the given version. However, a RIM that contains the expected hashes for the given version. However, a RIM that contains the
intermediate hashes can be useful in debugging cases where the expected final ha sh intermediate hashes can be useful in debugging cases where the expected final ha sh
is not the one reported.</t> is not the one reported.</li>
<t>Measurements taken later in operation of the system, once an OS has started <li>Measurements taken later in operation of the system, once an OS
(for example, Linux IMA <xref target="IMA"/>), may be more complex, with unpredi has started
ctable “final” (for example, Linux IMA <xref target="IMA" format="default"/>), may be more comp
lex, with unpredictable "final"
PCR values. In this case, the Verifier must have enough information to reconstr uct PCR values. In this case, the Verifier must have enough information to reconstr uct
the expected PCR values from logs and signed reference measurements from the expected PCR values from logs and signed reference measurements from
a trusted authority.</t> a trusted authority.</li>
</list></t> </ol>
<t>In both cases, the expected values can be expressed as signed SWID
<t>In both cases, the expected values can be expressed as signed SWID or CoSWID or CoSWID tags,
tags,
but the SWID structure in the second case is somewhat more complex, as reconstru ction of the extended hash in a PCR may involve thousands of files and other obj ects.</t> but the SWID structure in the second case is somewhat more complex, as reconstru ction of the extended hash in a PCR may involve thousands of files and other obj ects.</t>
<t>TCG has published an information model defining elements of RIMs
<t>TCG has published an information model defining elements of Reference Integri under the title "TCG Reference Integrity Manifest (RIM) Information Model" <xref
ty target="RIM" format="default"/>. This information model outlines how SWID tags
Manifests under the title TCG Reference Integrity Manifest Information Model <xr should be structured to allow attestation, and it defines "bundles" of SWID tag
ef target="RIM"/>. This information model outlines how SWID tags should be stru s that may be needed to describe a complete software release. The RIM contains
ctured to allow attestation, and defines “bundles” of SWID tags that may be need metadata relating to the software release it belongs to, plus hashes for each in
ed to describe a complete software release. The RIM contains metadata relating dividual file or other object that could be attested.</t>
to the software release it belongs to, plus hashes for each individual file or o <t>Many network equipment vendors use a UEFI BIOS to launch their netw
ther object that could be attested.</t> ork operating system. These vendors may want to
also use the "TCG PC Client Reference Integrity Manifest Specification" <xref ta
<t>Many network equipment vendors use a UEFI BIOS to launch their network operat rget="PC-CLIENT-RIM" format="default"/>, which focuses specifically on a SWID-co
ing system. These vendors may want to mpatible format suitable for expressing measurement values expected from a UEFI
also use the TCG PC Client Reference Integrity Measurement specification <xref t BIOS.</t>
arget="PC-Client-RIM"/>, which focuses specifically on a SWID-compatible format </section>
suitable for expressing measurement values expected from a UEFI BIOS.</t> <section anchor="attestation-logs" numbered="true" toc="default">
<name>Attestation Logs</name>
</section> <t>Quotes from a TPM can provide evidence of the state of a device up
<section anchor="attestation-logs" title="Attestation Logs"> to the time
the evidence was recorded. However, to make sense of the quote in cases where se
<t>Quotes from a TPM can provide evidence of the state of a device up to the tim veral events are extended into one PCR, an
e
the evidence was recorded, but to make sense of the quote in cases where several
events are extended into one PCR an
event log that identifies which software modules contributed which values to the quote event log that identifies which software modules contributed which values to the quote
during startup must also be provided. When required, the log MUST contain enoug h information during startup must also be provided. When required, the log <bcp14>MUST</bcp14 > contain enough information
to demonstrate its integrity by allowing exact reconstruction of the digest to demonstrate its integrity by allowing exact reconstruction of the digest
conveyed in the signed quote (that is, calculating the hash of all the hashes in the conveyed in the signed quote (that is, calculating the hash of all the hashes in the
log should produce the same values as contained in the PCRs; if they don’t match log should produce the same values as contained in the PCRs; if they don't match
, the log , the log
may have been tampered with. See <xref target="using-tpm"/>).</t> may have been tampered with. See <xref target="using-tpm" format="default"/>).<
/t>
<t>There are multiple event log formats which may be supported as viable formats <t>There are multiple event log formats that may be supported as viabl
of Evidence between the Attester and Verifier, e formats of Evidence between the Attester and Verifier;
but to simplify interoperability, RIV focuses on just three:</t> however, to simplify interoperability, RIV focuses on just three:</t>
<ol spacing="normal" type="1">
<t><list style="symbols"> <li>TCG UEFI BIOS event log for TPM 2.0 ("TCG PC Client Specific Pla
<t>TCG UEFI BIOS event log for TPM 2.0 (TCG PC Client Platform Firmware Profil tform Firmware Profile Specification") <xref target="PC-CLIENT-BIOS-TPM-2.0" for
e) <xref target="PC-Client-BIOS-TPM-2.0"/></t> mat="default"/></li>
<t>TCG UEFI BIOS event log for TPM 1.2 (TCG EFI Platform Specification for TPM <li>TCG UEFI BIOS event log for TPM 1.2 ("TCG EFI Platform Specifica
Family 1.1 or tion" for TPM Family 1.1 or
1.2, Section 7) <xref target="PC-Client-EFI-TPM-1.2"/></t> 1.2, Section 7) <xref target="PC-CLIENT-EFI-TPM-1.2" format="default"/></li>
<t>TCG Canonical Event Log <xref target="Canonical-Event-Log"/></t> <li>TCG "Canonical Event Log Format" <xref target="CEL" format="defa
</list></t> ult"/></li>
</ol>
</section> </section>
</section> </section>
</section> </section>
<section anchor="standards-components" title="Standards Components"> <section anchor="standards-components" numbered="true" toc="default">
<name>Standards Components</name>
<section anchor="prerequisites-for-riv" title="Prerequisites for RIV"> <section anchor="prerequisites-for-riv" numbered="true" toc="default">
<name>Prerequisites for RIV</name>
<t>The Reference Interaction Model for Challenge-Response-based Remote Attestati <t>The Reference Interaction Model for Challenge-Response-based Remote A
on (<xref target="I-D.birkholz-rats-reference-interaction-model"/>) ttestation (<xref target="I-D.ietf-rats-reference-interaction-models" format="de
is based on the standard roles defined in <xref target="I-D.ietf-rats-architectu fault"/>)
re"/>. However, additional prerequisites have been established to allow for int is based on the standard roles defined in <xref target="RFC9334" format="default
eroperable RIV use case implementations. These prerequisites are intended to pr "/>. However, additional prerequisites have been established to allow for inter
ovide sufficient context information so that the Verifier can acquire and evalua operable implementations of RIV use cases. These prerequisites are intended to
te measurements collected by the Attester.</t> provide sufficient context information so that the Verifier can acquire and eval
uate measurements collected by the Attester.</t>
<section anchor="unique-device-identity" title="Unique Device Identity"> <section anchor="unique-device-identity" numbered="true" toc="default">
<name>Unique Device Identity</name>
<t>A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID certifi <t>A DevID in the form of a DevID certificate as specified by IEEE Std
cate <xref target="IEEE-802-1AR"/> must be provisioned in the Attester’s TPMs.</ 802.1AR <xref target="IEEE-802-1AR" format="default"/> must be provisioned in t
t> he Attester's TPMs.</t>
</section>
</section> <section anchor="keys" numbered="true" toc="default">
<section anchor="keys" title="Keys"> <name>Keys</name>
<t>The AK and certificate must also be provisioned on the Attester acc
<t>The Attestation Key (AK) and certificate must also be provisioned on the Atte ording to <xref target="PLATFORM-DEVID-TPM-2.0" format="default"/> or <xref targ
ster according to <xref target="Platform-DevID-TPM-2.0"/>, or <xref target="Plat et="PLATFORM-ID-TPM-1.2" format="default"/>.</t>
form-ID-TPM-1.2"/>.</t> <t>It <bcp14>MUST</bcp14> be possible for the Verifier to determine th
at the Attester's AKs are resident in the same TPM as its DevID keys (see <xref
<t>It MUST be possible for the Verifier to determine that the Attester’s Attesta target="riv-keying" format="default"/> and <xref target="security-cons" format="
tion keys are resident in the same TPM as its DevID keys (see <xref target="riv- default"/>, Security Considerations).</t>
keying"/> and <xref target="security-cons"/> Security Considerations).</t> </section>
<section anchor="RIM-policy" numbered="true" toc="default">
</section> <name>Appraisal Policy for Evidence</name>
<section anchor="RIM-policy" title="Appraisal Policy for Evidence"> <t>As noted in <xref target="RIV-flow" format="default"/>, the Verifie
r may obtain Reference Values from several sources. In addition, administrators
<t>As noted in <xref target="RIV-flow"/>, the Verifier may obtain Reference Valu may make authorized, site-specific changes (e.g., keys in key databases) that c
es from several sources. In addition, administrators may make authorized, site- ould impact attestation results. As such, there could be conflicts, omissions,
specific changes (e.g. keys in key databases) that could impact attestation resu or ambiguities between some Reference Values and collected Evidence.</t>
lts. As such, there could be conflicts, omissions or ambiguities between some R <t>The Verifier <bcp14>MUST</bcp14> have an Appraisal Policy for Evide
eference Values and collected Evidence.</t> nce to evaluate the significance of any discrepancies between different referenc
e sources, or between Reference Values and evidence from logs and quotes.
<t>The Verifier MUST have an Appraisal Policy for Evidence to evaluate the signi
ficance of any discrepancies between different reference sources, or between ref
erence values and evidence from logs and quotes.
While there must be an Appraisal Policy, this document does not specify the form at or mechanism to convey the intended policy, nor does RIV specify mechanisms b y which the results of applying the policy are communicated to the Relying Party .</t> While there must be an Appraisal Policy, this document does not specify the form at or mechanism to convey the intended policy, nor does RIV specify mechanisms b y which the results of applying the policy are communicated to the Relying Party .</t>
</section>
</section> </section>
</section> <section anchor="reference-model-for-challenge-response" numbered="true" t
<section anchor="reference-model-for-challenge-response" title="Reference Model oc="default">
for Challenge-Response"> <name>Reference Model for Challenge-Response</name>
<t>Once the prerequisites for RIV are met, a Verifier is able to acquire
<t>Once the prerequisites for RIV are met, a Verifier is able to acquire Evidenc Evidence from an Attester. <xref target="IETF-Attestation-Information-Flow" fo
e from an Attester. The following diagram illustrates a RIV information flow be rmat="default"/> illustrates a RIV information flow between a Verifier and an At
tween a Verifier and an Attester, tester,
derived from Section 7.1 of <xref target="I-D.birkholz-rats-reference-interactio derived from Section 7.1 of <xref target="I-D.ietf-rats-reference-interaction-mo
n-model"/>. In this diagram, each event with its dels" format="default"/>. In this diagram, each event with its
input and output parameters is shown as “Event(input-params)=&gt;(outputs)”. input and output parameters is shown as "Event(input-params)=&gt;(outputs)".
Event times shown correspond to the time types described within Appendix A of <x The event times shown correspond to the time types described within <xref target
ref target="I-D.ietf-rats-architecture"/>:</t> ="RFC9334" section="A" sectionFormat="of" format="default"/>:</t>
<figure anchor="IETF-Attestation-Information-Flow">
<figure title="IETF Attestation Information Flow" anchor="IETF-Attestation-Infor <name>IETF Attestation Information Flow</name>
mation-Flow"><artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
.----------. .-----------------------. .----------. .-----------------------.
| Attester | | Relying Party/Verifier | | Attester | | Relying Party/Verifier |
'----------' '------------------------' '----------' '------------------------'
time(VG) | time(VG) |
generateClaims(attestingEnvironment) | generateClaims(attestingEnvironment) |
| => claims, eventLogs | | => claims, eventLogs |
| | | |
| time(NS) | time(NS)
| <-- requestAttestation(handle, authSecIDs, claimSelection) | | <-- requestAttestation(handle, authSecIDs, claimSelection) |
| | | |
skipping to change at line 727 skipping to change at line 792
generateEvidence(handle, authSecIDs, collectedClaims) | generateEvidence(handle, authSecIDs, collectedClaims) |
| => evidence | | => evidence |
| time(RG,RA) | time(RG,RA)
| evidence, eventLogs -------------------------------------> | | evidence, eventLogs -------------------------------------> |
| | | |
| appraiseEvidence(evidence, eventLogs, refValues) | appraiseEvidence(evidence, eventLogs, refValues)
| attestationResult <= | | attestationResult <= |
| | | |
~ ~ ~ ~
| time(RX) | time(RX)
]]></artwork></figure> ]]></artwork>
</figure>
<t><list style="symbols"> <dl spacing="normal">
<t>Step 1 (time(VG)): One or more Attesting Network Device PCRs are extended w <dt>Step 1 (time(VG)):</dt><dd>One or more attesting network device PC
ith measurements. RIV provides no direct link between Rs 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, althoug the time at which the event takes place and the time that it's attested, althoug
h streaming attestation as in <xref target="I-D.birkholz-rats-network-device-sub h streaming attestation as described in <xref target="I-D.ietf-rats-network-devi
scription"/> could.</t> ce-subscription" format="default"/> could.</dd>
<t>Step 2 (time(NS)): The Verifier generates a unique random nonce (“number us <!-- [rfced] Section 3.2. FYI, we will update the title of RFC 9684 when it is f
ed once”), and makes a request for one or more PCRs from an Attester. For inter inalized. -->
operability, this must be accomplished as specified in the YANG Data Model for C <dt>Step 2 (time(NS)):</dt><dd>The Verifier generates a unique random
hallenge-Response-based Remote Attestation Procedures using TPMs <xref target="I nonce ("number used once") and makes a request for one or more PCRs from an Atte
-D.ietf-rats-yang-tpm-charra"/>. TPM1.2 and TPM2.0 both allow nonces as large a ster. For interoperability, this must be accomplished as specified in "A YANG D
s the operative digest size (i.e., 20 or 32 bytes; see <xref target="TPM1.2"></x ata Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Us
ref> Part 2, Section 5.5 and <xref target="TPM2.0"></xref> Part 2, Section 10.4. ing Trusted Platform Modules (TPMs)" <xref target="RFC9684" format="default"/>.
4).</t> Both TPM 1.2 and TPM 2.0 allow nonces as large as the operative digest size (i.
<t>Step 3 (time(EG)): On the Attester, measured values are retrieved from the e., 20 or 32 bytes; see <xref target="TPM-1.2" format="default"/> Part 2, Sectio
Attester’s TPM. This requested PCR evidence, n 5.5, and <xref target="TPM-2.0" format="default"/> Part 2, Section 10.4.4).</d
along with the Verifier’s nonce, called a Quote, is signed by the Attestation Ke d>
y (AK) associated with the DevID. Quotes are retrieved according to CHARRA YANG <dt>Step 3 (time(EG)):</dt><dd>On the Attester, measured values are re
model <xref target="I-D.ietf-rats-yang-tpm-charra"/>. At the same time, the At trieved from the Attester's TPM. This requested PCR evidence
tester collects log evidence showing the values have been extended into that PCR along with the Verifier's nonce is called a Quote and is signed by the AK associ
. <xref target="using-tpm"/> gives more detail on how this works, including ref ated with the DevID. Quotes are retrieved according to the CHARRA YANG model <x
erences to the structure and contents of quotes in TPM documents.</t> ref target="RFC9684" format="default"/>. At the same time, the Attester collect
<t>Step 4: Collected Evidence is passed from the Attester to the Verifier</t> s log evidence showing the values have been extended into that PCR. <xref targe
<t>Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes action as t="using-tpm" format="default"/> gives more detail on how this works and include
needed. As the interaction between Relying Party and Verifier is out of scope s references to the structure and contents of quotes in TPM documents.</dd>
for RIV, this can be described as one step. <list style="symbols"> <dt>Step 4:</dt><dd>The collected Evidence is passed from the Attester
<t>If the signature covering TPM Evidence is not correct, the device SHOUL to the Verifier.</dd>
D NOT be trusted.</t>
<t>If the nonce in the response doesn’t match the Verifier’s nonce, the re
sponse may be a replay, and device SHOULD NOT be trusted.</t>
<t>If the signed PCR values do not match the set of log entries which have
extended a particular PCR, the device SHOULD NOT be trusted.</t>
<t>If the log entries that the Verifier considers important do not match k
nown good values, the device SHOULD NOT be trusted. We note that the process of
collecting and analyzing the log can be omitted if the value in the relevant PC
R is already a known-good value.</t>
<t>If the set of log entries are not seen as acceptable by the Appraisal P
olicy for Evidence, the device SHOULD NOT be trusted.</t>
<t>If time(RG)-time(NS) is greater than the Appraisal Policy for Evidence’
s threshold for assessing freshness, the Evidence is considered stale and SHOULD
NOT be trusted.</t>
</list></t>
</list></t>
<section anchor="transport-and-encoding" title="Transport and Encoding">
<t>Network Management systems may retrieve signed PCR based Evidence using NETCO
NF or RESTCONF with <xref target="I-D.ietf-rats-yang-tpm-charra"/>.
In either case, implementatations must do so using a secure tunnel.</t>
<t>Log Evidence MUST be retrieved via log interfaces specified in <xref target="
I-D.ietf-rats-yang-tpm-charra"/>.</t>
</section>
</section>
<section anchor="peer-to-peer" title="Centralized vs Peer-to-Peer">
<t><xref target="IETF-Attestation-Information-Flow"/> above assumes that the Ver
ifier 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 i
s 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, a
s shown in <xref target="Peer-to-peer-Information-Flow"/>. Peer-to-peer challen
ges, particularly if used to establish a trust relationship between routers, req
uire devices to carry their own signed reference measurements (RIMs). Devices m
ay also have to carry Appraisal Policy for Evidence for each possible peer devic
e so that each device has everything needed for remote attestation, without havi
ng to resort to a central authority.</t>
<figure title="Peer-to-Peer Attestation Information Flow" anchor="Peer-to-peer-I <dt>Step 5 (time(RG,RA)):</dt><dd><t>The Verifier reviews the Eviden
nformation-Flow"><artwork align="left"><![CDATA[ ce and takes action as needed. As the interaction between Relying Party and Ver
ifier is out of scope for RIV, this can be described as one step.</t>
<ul spacing="normal">
<li>If the signature covering TPM Evidence is not correct, the dev
ice <bcp14>SHOULD NOT</bcp14> be trusted.</li>
<li>If the nonce in the response doesn't match the Verifier's nonc
e, the response may be a replay, and the device <bcp14>SHOULD NOT</bcp14> be tru
sted.</li>
<li>If the signed PCR values do not match the set of log entries t
hat have extended a particular PCR, the device <bcp14>SHOULD NOT</bcp14> be trus
ted.</li>
<li>If the log entries that the Verifier considers important do no
t match known good values, the device <bcp14>SHOULD NOT</bcp14> 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.</li>
<li>If the set of log entries are not seen as acceptable by the Ap
praisal Policy for Evidence, the device <bcp14>SHOULD NOT</bcp14> be trusted.</l
i>
<li>If time(RG)-time(NS) is greater than the Appraisal Policy for
Evidence's threshold for assessing freshness, the Evidence is considered stale a
nd <bcp14>SHOULD NOT</bcp14> be trusted.</li>
</ul>
</dd>
</dl>
<section anchor="transport-and-encoding" numbered="true" toc="default">
<name>Transport and Encoding</name>
<t>Network Management systems may retrieve signed PCR-based Evidence u
sing NETCONF or RESTCONF with <xref target="RFC9684" format="default"/>.
In either case, implementations must do so using a secure tunnel.</t>
<t>Log Evidence <bcp14>MUST</bcp14> be retrieved via log interfaces sp
ecified in <xref target="RFC9684" format="default"/>.</t>
</section>
</section>
<section anchor="peer-to-peer" numbered="true" toc="default">
<name>Centralized vs. Peer-to-Peer</name>
<t><xref target="IETF-Attestation-Information-Flow" format="default"/> a
ssumes that the Verifier is trusted, while the Attester is not. In a peer-to-pe
er application such as two routers negotiating a trust relationship, the two pee
rs 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 an
d a Verifier. Each device issues a challenge, and each device responds to the o
ther's challenge, as shown in <xref target="Peer-to-peer-Information-Flow" forma
t="default"/>. Peer-to-peer challenges, particularly if used to establish a tru
st relationship between routers, require devices to carry their own signed refer
ence measurements (RIMs). Devices may also have to carry an Appraisal Policy fo
r Evidence for each possible peer device so that each device has everything need
ed for remote attestation, without having to resort to a central authority.</t>
<figure anchor="Peer-to-peer-Information-Flow">
<name>Peer-to-Peer Attestation Information Flow</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
+---------------+ +---------------+ +---------------+ +---------------+
| RefVal | | RefVal | | RefVal | | RefVal |
| Provider A | | Provider B | | Provider A | | Provider B |
| Firmware | | Firmware | | Firmware | | Firmware |
| Configuration | | Configuration | | Configuration | | Configuration |
| Authority | | Authority | | Authority | | Authority |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
| | | |
| |Step 0B | |Step 0B
skipping to change at line 787 skipping to change at line 854
|- Router A -| Step 3 |- Router B -| | / |- Router A -| Step 3 |- Router B -| | /
| | | | | | | | | |
| | | | | | | | | |
| | Step 1 | | | \ | | Step 1 | | | \
| Verifier |<------>| Attester |<-+ | Router A | Verifier |<------>| Attester |<-+ | Router A
| |<------>| | |- Challenges | |<------>| | |- Challenges
| | Step 2 | | | Router B | | Step 2 | | | Router B
| | | | | | | | | |
| |<-------| | | | |<-------| | |
+------------+ Step 3 +------------+ / +------------+ Step 3 +------------+ /
]]></artwork>
]]></artwork></figure> </figure>
<t>In this application, each device may need to be equipped with signed
<t>In this application, each device may need to be equipped with signed RIMs to RIMs to act as an Attester, and to allow each device to act as a Verifier, each
act as an Attester, and also an Appraisal Policy for Evidence and a selection of may need to be equipped with an Appraisal Policy for Evidence and a selection of
trusted X.509 root certificates, to allow the device to act as a Verifier. An trusted X.509 root certificates also. An existing link layer protocol such as
existing link layer protocol such as 802.1X <xref target="IEEE-802.1X"/> or 802 802.1X <xref target="IEEE-802.1X" format="default"/> or 802.1AE <xref target="I
.1AE <xref target="IEEE-802.1AE"/>, with Evidence being enclosed over a variant EEE-802.1AE" format="default"/>, with Evidence being enclosed over a variant of
of EAP <xref target="RFC3748"/> or LLDP <xref target="LLDP"/> are suitable metho the Extensible Authentication Protocol (EAP) <xref target="RFC3748" format="defa
ds for such an exchange. ult"/> or Link Layer Discovery Protocol (LLDP) <xref target="LLDP" format="defau
lt"/>, are suitable methods for such an exchange.
Details of peer-to-peer operation are out of scope for this document.</t> Details of peer-to-peer operation are out of scope for this document.</t>
</section>
</section> </section>
</section> <section anchor="privacy-considerations" numbered="true" toc="default">
<section anchor="privacy-considerations" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>Network equipment, such as routers, switches, and firewalls, has a key
<t>Network equipment, such as routers, switches and firewalls, has a key role to role to play in guarding the privacy of individuals using the network. Network
play in guarding the privacy of individuals using the network. Network equipme equipment generally adheres to several rules to protect privacy:</t>
nt generally adheres to several rules to protect privacy:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>Packets passing through the device must not be sent to unauthorized
<t>Packets passing through the device must not be sent to unauthorized destina destinations. For example: </t>
tions. For example: <list style="symbols"> <ul spacing="normal">
<t>Routers often act as Policy Enforcement Points, where individual subscr <li>Routers often act as Policy Enforcement Points, where individual
ibers may be checked for subscribers may be checked for
authorization to access a network. Subscriber login information must not be rel authorization to access a network. Subscriber login information must not be rel
eased to unauthorized parties.</t> eased to unauthorized parties.</li>
<t>Network equipment is often called upon to block access to protected res <li>Network equipment is often called upon to block access to protec
ources from unauthorized users.</t> ted resources from unauthorized users.</li>
</list></t> </ul>
<t>Routing information, such as the identity of a router’s peers, must not be </li>
leaked to unauthorized neighbors.</t> <li>Routing information, such as the identity of a router's peers, must
<t>If configured, encryption and decryption of traffic must be carried out rel not be leaked to unauthorized neighbors.</li>
iably, while protecting keys and credentials.</t> <li>If configured, encryption and decryption of traffic must be carried
</list></t> out reliably, while protecting keys and credentials.</li>
</ul>
<t>Functions that protect privacy are implemented as part of each layer of hardw <t>Functions that protect privacy are implemented as part of each layer of
are and software that hardware and software that
makes up the networking device. makes up the networking device.
In light of these requirements for protecting the privacy of users of the networ k, the network equipment In light of these requirements for protecting the privacy of users of the networ k, the network equipment
must identify itself, and its boot configuration and measured device state (for example, PCR values), must identify itself, and its boot configuration and measured device state (for example, PCR values),
to the equipment’s administrator, so there’s no uncertainty as to what function to the equipment's administrator so there's no uncertainty about the device's fu
each device and nction and
configuration is configured to carry out. Attestation is a component that allows configuration. Attestation is a component that allows the administrator to ensur
the administrator to ensure that the network e that the network
provides individual and peer privacy guarantees, even though the device itself m ay not have a provides individual and peer privacy guarantees, even though the device itself m ay not have a
right to keep its identity secret.</t> right to keep its identity secret.</t>
<t>See <xref target="NET-EQ" format="default"/> for more context on privac
y in networking devices.</t>
<t>While attestation information from network devices is not likely to con
tain privacy-sensitive content regarding
network users, administrators may want to keep attestation records confidential
to avoid disclosing versions of
software loaded on the device, which is information that could facilitate attack
s against known vulnerabilities.</t>
</section>
<section anchor="security-cons" numbered="true" toc="default">
<name>Security Considerations</name>
<t>Specifications such as TLS <xref target="RFC8446" format="default"/> an
d YANG <xref target="RFC7950" format="default"/> contain considerable advice on
keeping
network-connected systems secure. This section outlines specific risks and miti
gations related to attestation.</t>
<t>Attestation Evidence obtained by the RIV procedure is subject to a numb
er of attacks:</t>
<ul spacing="normal">
<li>Keys may be compromised.</li>
<li>A counterfeit device may attempt to impersonate (spoof) a known auth
entic device.</li>
<li>Person-in-the-middle attacks may be used by a compromised device to
attempt to deliver
responses that originate in an authentic device.</li>
<li>Replay attacks may be attempted by a compromised device.</li>
</ul>
<section anchor="keys-used-in-riv" numbered="true" toc="default">
<name>Keys Used in RIV</name>
<t>Trustworthiness of RIV attestation depends strongly on the validity o
f keys used for identity
and attestation reports. RIV takes full advantage of TPM capabilities to ensure
that evidence can be trusted.</t>
<t>Two sets of key pairs are relevant to RIV attestation:</t>
<!-- [rfced] Section 5.1. Is the AK used to certify the device identity or is it
the AK key pair?
<t>See <xref target="NetEq"/> for more context on privacy in networking devices. Original:
</t> * A DevID key-pair is used to certify the identity of the device in
which the TPM is installed.
<t>While attestation information from network devices is not likely to contain p * An Attestation Key-pair (AK) key is used to certify attestation
rivacy-sensitive content regarding Evidence (called 'quotes' in TCG documents), used to provide
network users, administrators may want to keep attestation records confidential evidence for integrity of the software on the device
to avoid disclosing versions of
software loaded on the device, information which could facilitate attacks agains
t known vulnerabilities.</t>
</section> Perhaps:
<section anchor="security-cons" title="Security Considerations"> * A DevID key pair is used to certify the identity of the device in
which the TPM is installed.
<t>Specifications such as <xref target="RFC8446"/> (TLS) and <xref target="RFC79 * An AK key pair is used to certify attestation
50"/> (YANG) contain considerable advice on keeping Evidence (i.e., quotes) and to provide
network-connected systems secure. This section outlines specific risks and miti evidence for the integrity of the device software.
gations related to attestation.</t> -->
<ul spacing="normal">
<li>A DevID key pair is used to certify the identity of the device in
which the TPM is installed.</li>
<li>An Attestation Key pair (AK) key is used to certify attestation Ev
idence (called "quotes" in TCG documents),
used to provide evidence for integrity of the software on the device</li>
</ul>
<t>TPM practices usually require that these keys be different to ensure
that a general-purpose
signing key cannot be used to spoof an attestation quote.</t>
<t>In each case, the private half of the key is known only to the TPM an
d cannot be
retrieved externally, even by a trusted party. To ensure that's the case,
specification-compliant private/public key pairs are generated inside the TPM, w
here they are never
exposed and cannot be extracted (see <xref target="PLATFORM-DEVID-TPM-2.0" forma
t="default"/>).</t>
<t>Keeping keys safe is a critical enabler of trustworthiness, but it's
just part of attestation security; knowing which keys are bound
to the device in question is just as important in an environment where private k
eys are never exposed.</t>
<t>While there are many ways to manage keys in a TPM (see <xref target="
PLATFORM-DEVID-TPM-2.0" format="default"/>), RIV includes
support for "zero touch" provisioning (also known as zero touch onboarding) of f
ielded
devices (e.g., SZTP <xref target="RFC8572" format="default"/>), where keys that
have predictable trust properties are
provisioned by the device vendor.</t>
<t>Device identity in RIV is based on DevID defined by IEEE Std 802.1AR.
This specification provides several elements:</t>
<ul spacing="normal">
<li>A DevID requires a unique key pair for each device, accompanied by
an X.509 certificate.</li>
<li>The private portion of the DevID key is to be stored in the device
, in a manner that provides confidentiality (Section 6.2.5 of <xref target="IEEE
-802-1AR" format="default"/>).</li>
</ul>
<t>The X.509 certificate contains several components:</t>
<ul spacing="normal">
<li>The public part of the unique DevID key assigned to that device al
lows a challenge of identity.</li>
<li>An identifying string that's unique to the manufacturer of the dev
ice. This is normally the
serial number of the unit, which might also be printed on a label on the device.
</li>
<li>The certificate must be signed by a key traceable to the manufactu
rer's root key.</li>
</ul>
<t>With these elements, the device's manufacturer and serial number can
be identified by analyzing the
DevID certificate plus the chain of intermediate certificates leading back to th
e manufacturer's root
certificate. As is conventional in TLS or SSH connections, a random nonce must
be signed by the device
in response to a challenge,
proving possession of its DevID private key.</t>
<t>RIV uses the DevID to validate a TLS or SSH connection to the device
as the attestation session begins. Security of
this process derives from TLS or SSH security, with the DevID, which contains a
device serial number, providing proof that the session terminates on
the intended device. See <xref target="RFC8446" format="default"/> <xref target=
"RFC4253" format="default"/>.</t>
<t>Evidence of software integrity is delivered in the form of a quote th
at is signed by the TPM
itself and accompanied by an IAK certificate containing the same identity inform
ation as the DevID. Because the contents of the quote are signed inside the TPM
, any external
modification (including reformatting to a different data format) after measureme
nts have been taken will be detected
as tampering. An unbroken chain of trust is essential for ensuring that blocks
of code that are taking
measurements have been verified before execution (see <xref target="RIV-Attestat
ion-Model" format="default"/>).</t>
<!-- [rfced] Section 5.1. Does splitting the sentence below into two and reorgan
izing the later half of it improve readability?
<t>Attestation Evidence obtained by the RIV procedure is subject to a number of Original:
attacks:</t> Requiring measurements of the operating software to be signed by a
key known only to the TPM also removes the need to trust the device's
operating software (beyond the first measurement in the RTM; see
below); any changes to the quote, generated and signed by the TPM
itself, made by malicious device software, or in the path back to the
Verifier, will invalidate the signature on the quote.
<t><list style="symbols"> Perhaps:
<t>Keys may be compromised.</t> Requiring measurements of the operating software to be signed by a
<t>A counterfeit device may attempt to impersonate (spoof) a known authentic d key known only to the TPM also removes the need to trust the device's
evice.</t> operating software (beyond the first measurement in the RTM; see
<t>Person-in-the-middle attacks may be used by a compromised device to attempt below). If malicious device software makes any changes to a quote
to deliver or in the path back to the Verifier, the signature on the quote will
responses that originate in an authentic device.</t> be invalidated.
<t>Replay attacks may be attempted by a compromised device.</t> -->
</list></t> <t>Requiring measurements of the operating software to be signed by a ke
y known only to the TPM also
removes the need to trust the device's operating software (beyond the first meas
urement in the RTM; see below). Any
changes to the quote, generated and signed by the TPM itself, made by malicious
device software, or in
the path back to the Verifier, will invalidate the signature on the quote.</t>
<!-- [rfced] Section 5.1. Does "compress out" in the following mean to "remove"
or to "reduce"?
<section anchor="keys-used-in-riv" title="Keys Used in RIV"> Original:
<t>Trustworthiness of RIV attestation depends strongly on the validity of keys u While alternate methods of conveying TPM quotes could compress out
sed for identity redundant information,
and attestation reports. RIV takes full advantage of TPM capabilities to ensure -->
that evidence can be trusted.</t> <t>A critical feature of the YANG model described in <xref target="RFC96
84" format="default"/> is the ability to carry TPM data structures in their TCG-
defined format, without requiring any changes to the structures as they were sig
ned and delivered by the TPM. While alternate methods of conveying TPM quotes c
ould compress out redundant information, or add another layer of signing using e
xternal keys, the implementation <bcp14>MUST</bcp14> preserve the TPM signing so
that tampering anywhere in the path between the TPM itself and the Verifier can
be detected.</t>
</section>
<section anchor="pitm" numbered="true" toc="default">
<name>Prevention of Spoofing and Person-in-the-Middle Attacks</name>
<t>Prevention of spoofing attacks against attestation systems is also im
portant. There are several cases to consider:</t>
<ul spacing="normal">
<li>The entire device could be spoofed. If the Verifier goes to apprai
se a specific Attester, it might be redirected to a different Attester.</li>
<li>A compromised device could have a valid DevID, but substitute a qu
ote from a known-good device instead of returning its own, as described in <xref
target="RFC6813" format="default"/>.</li>
<li>A device with a compromised OS could return a fabricated quote pro
viding spoofed attestation Evidence.</li>
</ul>
<t>Use of the 802.1AR DevID in the TPM provides protection against the c
ase of a spoofed device by ensuring that the Verifier's TLS or SSH session is in
fact terminating on the right device.</t>
<t>Protection against spoofed quotes from a device with valid identity i
s a bit more complex.
An identity key must be available to sign any kind of nonce or hash offered by t
he Verifier,
and consequently, could be used to sign a fabricated quote. To block a spoofed
Attestation
Result, the quote generated inside the TPM must be signed by
a key, known as an AK, that's different from the DevID.</t>
<t>Given separate Attestation and DevID keys, the
binding between the AK and the same device must also be proven to
prevent a person-in-the-middle attack (e.g., the "Asokan Attack" <xref target="R
FC6813" format="default"/>).</t>
<t>This is accomplished in RIV through use of an AK certificate with the
same elements as the DevID
(same manufacturer's serial number and signed by the same manufacturer's key), b
ut containing
the device's unique AK public key instead of the DevID public key.
This binding between DevID and AK certificates is critical to reliable attestati
on.</t>
<t>The TCG document "TPM 2.0 Keys for Device Identity and Attestation" <
xref target="PLATFORM-DEVID-TPM-2.0" format="default"/> specifies
OIDs for Attestation Certificates that allow the CA to mark a key as specificall
y known to be
an AK.</t>
<t>These two key pairs and certificates are used together:</t>
<ul spacing="normal">
<li>The DevID is used to validate a TLS connection terminating on the
device with a known serial number.</li>
<li>The AK is used to sign attestation quotes, which provides proof th
at the attestation
evidence comes from the same device.</li>
</ul>
</section>
<section anchor="replay-attacks" numbered="true" toc="default">
<name>Replay Attacks</name>
<t>Replay attacks, where the results of a previous attestation are submi
tted in response to subsequent requests,
are usually prevented by the inclusion of a random nonce in the request to the T
PM
for a quote. Each request from the Verifier includes a new random number (a non
ce). The resulting
quote signed by the TPM contains the same nonce, which allows the Verifier to de
termine
freshness (i.e., that the resulting quote was generated in response to the Verif
ier's specific request).
"Time-Based Uni-Directional Attestation" <xref target="I-D.birkholz-rats-tuda" f
ormat="default"/> provides an alternate mechanism
to verify freshness without requiring a request/response cycle.</t>
</section>
<section anchor="owner-signed-keys" numbered="true" toc="default">
<name>Owner-Signed Keys</name>
<t>Although device manufacturers must pre-provision devices with easily
verified DevID and AK certificates
if SZTP such as described in <xref target="RFC8572" format="default"/> is to be
supported,
use of those credentials is not mandatory. IEEE Std 802.1AR incorporates the id
ea of an
IDevID, which is provisioned by the manufacturer, and a LDevID, which is provisi
oned by the owner of
the device. RIV and <xref target="PLATFORM-DEVID-TPM-2.0" format="default"/> ex
tend that concept by defining an IAK and
LAK with the same properties.</t>
<t>Device owners can use any method to provision the local credentials.<
/t>
<ul spacing="normal">
<li>The TCG document <xref target="PLATFORM-DEVID-TPM-2.0" format="def
ault"/> shows how the IAKs
can be used to certify LDevID and LAK keys. The use of the LDevID and LAK allow
s the device owner
to use a uniform identity structure across device types from multiple manufactur
ers (in the same way
that an "Asset Tag" is used by many enterprises to identify devices they own).
The TCG document
<xref target="PROV-TPM-2.0" format="default"/> also contains guidance on provisi
oning local identity keys in TPM 2.0.
Owners should follow the same practice of binding LDevID and LAK as the manufact
urer would for IDevID and IAK.
See <xref target="riv-keying" format="default"/>.</li>
<li>Device owners, however, can use any other mechanism they want, inc
luding physical inspection and programming in a secure location, to assure thems
elves that local identity
certificates are inserted into the intended device
if they prefer to avoid placing trust in the manufacturer-provided keys.</li>
</ul>
<t>Clearly, local keys can't be used for SZTP; installation of the local
keys
can only be done by some process that runs before the device is installed for ne
twork operation,
or by using procedures such as those outlined in Bootstrapping Remote Secure Key
Infrastructure (BRSKI) <xref target="RFC8995" format="default"/>.</t>
<t>On the other end of the device lifecycle, provision should be made to
wipe local keys when a device
is decommissioned to indicate that the device is no longer owned by the enterpri
se. The manufacturer's
initial identity keys must be preserved, as they contain no information that's n
ot already printed on
the device's serial number plate.</t>
</section>
<section anchor="other-factors-for-trustworthy-operation" numbered="true"
toc="default">
<name>Other Factors for Trustworthy Operation</name>
<t>In addition to the trustworthy provisioning of keys, RIV depends on a
number of other factors for trustworthy operation.</t>
<ul spacing="normal">
<li>Secure identity depends on mechanisms to prevent per-device secret
keys from being compromised. The TPM
provides this capability as a Root of Trust for Storage.</li>
<li>Attestation depends on an unbroken chain of measurements, starting
from the very first
measurement. See <xref target="using-tpm" format="default"/> for background on
TPM practices.</li>
<li>That first measurement is made by code called the RTM, typically d
one by trusted
firmware stored in boot flash. Mechanisms for maintaining the trustworthiness o
f the RTM are out of
scope for RIV, but could include immutable firmware, signed updates, or a vendor
-specific hardware
verification technique. See <xref target="root-of-trust" format="default"/> f
or background on Roots of Trust.</li>
<li>The device owner <bcp14>SHOULD</bcp14> provide some level of physi
cal defense for the device. If a TPM that has already been programmed
with an authentic DevID is stolen and is inserted into a counterfeit device, att
estation of that counterfeit
device may become indistinguishable from an authentic device.</li>
</ul>
<t>RIV also depends on reliable Reference Values, as expressed by the RI
M <xref target="RIM" format="default"/>. The definition of
trust procedures for RIMs is out of scope for RIV, and the device owner is free
to use any policy to validate
a set of reference measurements. It should also be noted that, while RIV can pr
ovide a reliable indication that a known software package is in use by the devic
e and that the package has not been tampered with, it is the device owner's resp
onsibility to determine that it's the correct package for the application.</t>
<t>RIMs may be conveyed either out-of-band or in-band as part of the att
estation
process (see <xref target="RIM-policy" format="default"/>). However, for networ
k devices, where software is usually shipped as a self-contained
package, RIMs signed by the manufacturer and delivered in-band may be more conve
nient for the device owner.</t>
<t>The validity of RIV attestation results is also influenced by procedu
res used to create Reference Values:</t>
<ul spacing="normal">
<li>While the RIM itself is signed, supply chains <bcp14>SHOULD</bcp14
> be carefully scrutinized to ensure that the values are
not subject to unexpected manipulation prior to signing. Insider attacks agains
t code bases and build chains
are particularly hard to spot.</li>
<li>Designers <bcp14>SHOULD</bcp14> guard against hash collision attac
ks. RIMs often give hashes for large objects
of indeterminate size. If one of the measured objects can be replaced with an im
plant engineered to produce
the same hash, RIV will be unable to detect the substitution. TPM 1.2 only uses
SHA-1 hashes, which have been
shown to be susceptible to collision attack. TPM 2.0 will produce quotes with S
HA-256, which so far has resisted
such attacks. Consequently, RIV implementations <bcp14>SHOULD</bcp14> use TPM 2
.0.</li>
</ul>
</section>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="conclusion" numbered="true" toc="default">
<name>Conclusion</name>
<t>TCG technologies can play an important part in the implementation of RI
V.
Standards for many of the components needed for
implementation of RIV already exist:</t>
<ul spacing="normal">
<li>Platform identity can be based on IEEE 802.1AR DevID, coupled with
careful supply-chain management by the manufacturer.</li>
<li>Complex supply chains can be certified using TCG Platform Certificat
es <xref target="PLATFORM-CERTS" format="default"/>.</li>
<li>The TCG TAP mechanism coupled with <xref target="RFC9684" format="de
fault"/> can be used to retrieve attestation evidence.</li>
<li>Reference Values must be conveyed from the software authority (e.g.,
the manufacturer) in RIMs to the system in which verification will take place.
IETF and TCG
SWID and CoSWID work (<xref target="RFC9393" format="default"/> <xref target="RI
M" format="default"/>) forms the basis for this function.</li>
</ul>
</section>
</middle>
<back>
<t>Two sets of key-pairs are relevant to RIV attestation:</t> <displayreference target="I-D.ietf-rats-reference-interaction-models" to="RATS-I
NTERACTION-MODELS"/>
<displayreference target="I-D.richardson-rats-usecases" to="RATS-USECASES"/>
<displayreference target="I-D.birkholz-rats-tuda" to="RATS-TUDA"/>
<displayreference target="I-D.ietf-rats-network-device-subscription" to="RATS-NE
T-DEV-SUB"/>
<displayreference target="I-D.ietf-rats-eat" to="RATS-EAT"/>
<t><list style="symbols"> <references>
<t>A DevID key-pair is used to certify the identity of the device in which the <name>References</name>
TPM is installed.</t> <references>
<t>An Attestation Key-pair (AK) key is used to certify attestation Evidence (c <name>Normative References</name>
alled ‘quotes’ in TCG documents), <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
used to provide evidence for integrity of the software on the device</t> 19.xml"/>
</list></t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
46.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.42
53.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
41.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
80.xml"/>
<t>TPM practices usually require that these keys be different, as a way of ensur <!-- [I-D.ietf-rats-yang-tpm-charra] companion document RFC 9684 -->
ing that a general-purpose
signing key cannot be used to spoof an attestation quote.</t>
<t>In each case, the private half of the key is known only to the TPM, and canno <reference anchor='RFC9684' target='https://www.rfc-editor.org/info/rfc9684'>
t be <front>
retrieved externally, even by a trusted party. To ensure that’s the case, <title>A YANG Data Model for Challenge-Response-Based Remote Attestation (CH
specification-compliant private/public key-pairs are generated inside the TPM, w ARRA) Procedures Using Trusted Platform Modules (TPMs)</title>
here they are never <author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
exposed, and cannot be extracted (See <xref target="Platform-DevID-TPM-2.0"/>).< <organization />
/t> </author>
<author initials='M' surname='Eckel' fullname='Michael Eckel'>
<organization />
</author>
<author initials='S' surname='Bhandari' fullname='Shwetha Bhandari'>
<organization />
</author>
<author initials='E' surname='Voit' fullname='Eric Voit'>
<organization />
</author>
<author initials='B' surname='Sulzen' fullname='Bill Sulzen'>
<organization />
</author>
<author initials='L' surname='Xia' fullname='Liang Xia'>
<organization />
</author>
<author initials='T' surname='Laffey' fullname='Tom Laffey'>
<organization />
</author>
<author initials='G' surname='Fedorkow' fullname='Guy Fedorkow'>
<organization />
</author>
<date year='2024' month='October'/>
</front>
<seriesInfo name="RFC" value="9684"/>
<seriesInfo name="DOI" value="10.17487/RFC9684"/>
</reference>
<t>Keeping keys safe is a critical enabler of trustworthiness, but it’s just par <!-- [rfced] Normative References. FYI, [I-D.ietf-sacm-coswid] has been publishe
t of attestation security; knowing which keys are bound d as RFC 9393. The reference entry and in-text citations have been updated accor
to the device in question is just as important in an environment where private k dingly. -->
eys are never exposed.</t>
<t>While there are many ways to manage keys in a TPM (see <xref target="Platform <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
-DevID-TPM-2.0"/>), RIV includes 93.xml"/>
support for “zero touch” provisioning (also known as zero-touch onboarding) of f
ielded
devices (e.g., Secure ZTP, <xref target="RFC8572"/>), where keys which have pred
ictable trust properties are
provisioned by the device vendor.</t>
<t>Device identity in RIV is based on IEEE 802.1AR Device Identity (DevID). This specification provides several elements:</t> <!-- [rfced] Normative References. FYI [I-D.ietf-rats-architecture] has been pub lished as RFC 9334. The reference entry and in-text citations have been updated accordingly. -->
<t><list style="symbols"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
<t>A DevID requires a unique key pair for each device, accompanied by an X.509 34.xml"/>
certificate,</t>
<t>The private portion of the DevID key is to be stored in the device, in a ma
nner that provides confidentiality (Section 6.2.5 <xref target="IEEE-802-1AR"/>)
</t>
</list></t>
<t>The X.509 certificate contains several components:</t> <reference anchor="IEEE-802-1AR" >
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Secu
re Device Identity</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2018" month="August"/>
</front>
<seriesInfo name="IEEE Std" value="802.1AR-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
</reference>
<t><list style="symbols"> <reference anchor="TAP" target="https://trustedcomputinggroup.org/wp-con
<t>The public part of the unique DevID key assigned to that device allows a ch tent/uploads/TNC_TAP_Information_Model_v1.00_r0.36-FINAL.pdf">
allenge of identity.</t> <front>
<t>An identifying string that’s unique to the manufacturer of the device. Thi <title>TCG Trusted Attestation Protocol (TAP) Information Model for
s is normally the TPM Families 1.2 and 2.0 and DICE Family 1.0</title>
serial number of the unit, which might also be printed on a label on the device. <author>
</t> <organization>Trusted Computing Group</organization>
<t>The certificate must be signed by a key traceable to the manufacturer’s roo </author>
t key.</t> <date year="2018" month="October"/>
</list></t> </front>
<refcontent>Version 1.0, Revision 0.36</refcontent>
</reference>
<t>With these elements, the device’s manufacturer and serial number can be ident <reference anchor="CEL" target="https://trustedcomputinggroup.org/wp-con
ified by analyzing the tent/uploads/TCG_IWG_CEL_v1_r0p41_pub.pdf">
DevID certificate plus the chain of intermediate certificates leading back to th <front>
e manufacturer’s root <title>Canonical Event Log Format</title>
certificate. As is conventional in TLS or SSH connections, a random nonce must <author>
be signed by the device <organization>Trusted Computing Group</organization>
in response to a challenge, </author>
proving possession of its DevID private key.</t> <date year="2022" month="February"/>
</front>
<refcontent>Version 1.0, Revision 0.41</refcontent>
</reference>
<t>RIV uses the DevID to validate a TLS or SSH connection to the device as the a <reference anchor="PC-CLIENT-BIOS-TPM-2.0" target="https://trustedcomput
ttestation session begins. Security of inggroup.org/resource/pc-client-specific-platform-firmware-profile-specification
this process derives from TLS or SSH security, with the DevID, containing a devi /">
ce serial number, providing proof that the session terminates on <front>
the intended device. See <xref target="RFC8446"/>, <xref target="RFC4253"/>.</t> <title>TCG PC Client Specific Platform Firmware Profile Specificatio
n</title>
<author>
<organization>Trusted Computing Group</organization>
</author>
<date year="2021" month="May"/>
</front>
<refcontent>Family "2.0", Level 00, Version 1.05, Revision 23</refconte
nt>
</reference>
<t>Evidence of software integrity is delivered in the form of a quote signed by <reference anchor="PC-CLIENT-EFI-TPM-1.2" target="https://trustedcomputi
the TPM nggroup.org/resource/tcg-efi-platform-specification/">
itself, accompanied by an IAK certificate containing the same identity informati <front>
on as the DevID. Because the contents of the quote are signed inside the TPM, a <title>TCG EFI Platform Specification</title>
ny external <author>
modification (including reformatting to a different data format) after measureme <organization>Trusted Computing Group</organization>
nts have been taken will be detected </author>
as tampering. An unbroken chain of trust is essential to ensuring that blocks o <date year="2014" month="January"/>
f code that are taking </front>
measurements have been verified before execution (see <xref target="RIV-Attestat <refcontent>For TPM Family 1.1 or 1.2, Version 1.22, Revision 15</refco
ion-Model"/>).</t> ntent>
</reference>
<t>Requiring measurements of the operating software to be signed by a key known <reference anchor="RIM" target="https://trustedcomputinggroup.org/resour
only to the TPM also ce/tcg-reference-integrity-manifest-rim-information-model/">
removes the need to trust the device’s operating software (beyond the first meas <front>
urement in the RTM; see below); any <title>TCG Reference Integrity Manifest (RIM) Information Model</tit
changes to the quote, generated and signed by the TPM itself, made by malicious le>
device software, or in <author>
the path back to the Verifier, will invalidate the signature on the quote.</t> <organization>Trusted Computing Group</organization>
</author>
<date year="2020" month="November"/>
</front>
<refcontent>Version 1.01, Revision 0.16</refcontent>
</reference>
<t>A critical feature of the YANG model described in <xref target="I-D.ietf-rats <reference anchor="PC-CLIENT-RIM" target="https://trustedcomputinggroup.
-yang-tpm-charra"/> is the ability to carry TPM data structures in their TCG-def org/resource/tcg-pc-client-reference-integrity-manifest-specification/">
ined format, without requiring any changes to the structures as they were signed <front>
and delivered by the TPM. While alternate methods of conveying TPM quotes coul <title>TCG PC Client Reference Integrity Manifest Specification</tit
d compress out redundant information, or add another layer of signing using exte le>
rnal keys, the implementation MUST preserve the TPM signing, so that tampering a <author>
nywhere in the path between the TPM itself and the Verifier can be detected.</t> <organization>Trusted Computing Group</organization>
</author>
<date year="2020" month="November"/>
</front>
<refcontent>Version 1.04</refcontent>
</reference>
</section> <reference anchor="PLATFORM-DEVID-TPM-2.0" target="https://trustedcomput
<section anchor="pitm" title="Prevention of Spoofing and Person-in-the-Middle At inggroup.org/resource/tpm-2-0-keys-for-device-identity-and-attestation/">
tacks"> <front>
<title>TPM 2.0 Keys for Device Identity and Attestation</title>
<author>
<organization>Trusted Computing Group</organization>
</author>
<date year="2021" month="October"/>
</front>
<refcontent>Version 1.00, Revision 12</refcontent>
</reference>
<t>Prevention of spoofing attacks against attestation systems is also important. <reference anchor="PLATFORM-ID-TPM-1.2" target="https://trustedcomputing
There are several cases to consider:</t> group.org/resource/tpm-keys-for-platform-identity-for-tpm-1-2-2/">
<front>
<title>TCG Infrastructure WG TPM Keys for Platform Identity for TPM
1.2</title>
<author>
<organization>Trusted Computing Group</organization>
</author>
<date year="2015" month="August"/>
</front>
<refcontent>Specification Version 1.0, Revision 3</refcontent>
</reference>
<t><list style="symbols"> <reference anchor="SWID" target="https://www.iso.org/standard/65666.html
<t>The entire device could be spoofed. If the Verifier goes to appraise a spec ">
ific Attester, it might be redirected to a different Attester.</t> <front>
<t>A compromised device could have a valid DevID, but substitute a quote from <title>Information technology - IT asset management - Part 2: Softwa
a knonwn-good device, instead of returning its own, as described in <xref target re identification tag</title>
="RFC6813"/>.</t> <author>
<t>A device with a compromised OS could return a fabricated quote providing sp <organization>ISO/IEC</organization>
oofed attestation Evidence.</t> </author>
</list></t> <date year="2015" month="October"/>
</front>
<seriesInfo name="ISO/IEC" value="19770-2:2015"/>
</reference>
<t>Use of the 802.1AR Device Identity (DevID) in the TPM provides protection aga inst the case of a spoofed device, by ensuring that the Verifier’s TLS or SSH se ssion is in fact terminating on the right device.</t> <!-- [rfced] Normative References. FYI, we have updated the [IMA] reference to m atch our style guide and also link to the most recent dated version. Please let us know if any changes are needed:
<t>Protection against spoofed quotes from a device with valid identity is a bit Original:
more complex. [IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn,
An identity key must be available to sign any kind of nonce or hash offered by t "Integrity Measurement Architecture", June 2019,
he Verifier, <https://sourceforge.net/p/linux-ima/wiki/Home/>.
and consequently, could be used to sign a fabricated quote. To block a spoofed
Attestation
Result, the quote generated inside the TPM must be signed by
a key that’s different from the DevID, called an Attestation Key (AK).</t>
<t>Given separate Attestation and DevID keys, the Current:
binding between the AK and the same device must also be proven to [IMA] "Integrity Measurement Architecture (IMA) Wiki", October
prevent a person-in-the-middle attack (e.g., the ‘Asokan Attack’ <xref target="R 2018, <https://sourceforge.net/p/linux-ima/wiki/
FC6813"/>).</t> Home/?version=31>.
-->
<t>This is accomplished in RIV through use of an AK certificate with the same el <reference anchor="IMA" target="https://sourceforge.net/p/linux-ima/wiki
ements as the DevID /Home/?version=31">
(same manufacturer’s serial number, signed by the same manufacturer’s key), but <front>
containing <title>Integrity Measurement Architecture (IMA) Wiki</title>
the device’s unique AK public key instead of the DevID public key. <author/>
This binding between DevID and AK certificates is critical to reliable attestati <date year="2018" month="October"/>
on.</t> </front>
</reference>
</references>
<references>
<name>Informative References</name>
<t>The TCG document TPM 2.0 Keys for Device Identity and Attestation <xref targe <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.681
t="Platform-DevID-TPM-2.0"/> specifies 3.xml"/>
OIDs for Attestation Certificates that allow the CA to mark a key as specificall <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.374
y known to be 8.xml"/>
an Attestation key.</t>
<t>These two key-pairs and certificates are used together:</t> <!-- [rfced] Informative References. FYI, RFC 6125 has been obsoleted by RFC 952 5. We have replaced RFC 6125 with RFC 9525. Please let us know any objections.
<t><list style="symbols"> Original:
<t>The DevID is used to validate a TLS connection terminating on the device wi It should be noted that 802.1AR use of X.509 certificate fields is
th a known serial number.</t> not identical to those descsribed in [RFC6125] for representation
<t>The AK is used to sign attestation quotes, providing proof that the attesta of application service identity.
tion
evidence comes from the same device.</t>
</list></t>
</section> [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
<section anchor="replay-attacks" title="Replay Attacks"> Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
<t>Replay attacks, where results of a previous attestation are submitted in resp Current:
onse to subsequent requests, It should be noted that the use of X.509 certificate fields as
are usually prevented by inclusion of a random nonce in the request to the TPM specified by IEEE Std 802.1AR is not identical to that described
for a quote. Each request from the Verifier includes a new random number (a non in [RFC9525] for representation of application service identity.
ce). The resulting
quote signed by the TPM contains the same nonce, allowing the Verifier to determ
ine
freshness, (i.e., that the resulting quote was generated in response to the Veri
fier’s specific request).
Time-Based Uni-directional Attestation <xref target="I-D.birkholz-rats-tuda"/> p
rovides an alternate mechanism
to verify freshness without requiring a request/response cycle.</t>
</section> [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
<section anchor="owner-signed-keys" title="Owner-Signed Keys"> RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
-->
<t>Although device manufacturers must pre-provision devices with easily verified <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.952
DevID and AK certificates 5.xml"/>
if zero-touch provisioning such as described in <xref target="RFC8572"/> is to b <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.899
e supported, 5.xml"/>
use of those credentials is not mandatory. IEEE 802.1AR incorporates the idea o <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.795
f an Initial Device ID 0.xml"/>
(IDevID), provisioned by the manufacturer, and a Local Device ID (LDevID) provis <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.857
ioned by the owner of 2.xml"/>
the device. RIV and <xref target="Platform-DevID-TPM-2.0"/> extends that concep
t by defining an Initial Attestation Key (IAK) and Local Attestation
Key (LAK) with the same properties.</t>
<t>Device owners can use any method to provision the Local credentials.</t> <!-- [I-D.birkholz-rats-reference-interaction-model] replaced by [I-D.ietf-rats- reference-interaction-models] IESG state Expired -->
<t><list style="symbols"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
<t>TCG document <xref target="Platform-DevID-TPM-2.0"/> shows how the initial ietf-rats-reference-interaction-models.xml"/>
Attestation
keys can be used to certify LDevID and LAK keys. Use of the LDevID and LAK allo
ws the device owner
to use a uniform identity structure across device types from multiple manufactur
ers (in the same way
that an “Asset Tag” is used by many enterprises to identify devices they own).
TCG document
<xref target="Provisioning-TPM-2.0"/> also contains guidance on provisioning Loc
al identity keys in TPM 2.0.
Owners should follow the same practice of binding Local DevID and Local AK as th
e manufacturer would for IDevID and IAK.
See Section <xref target="riv-keying"/>.</t>
<t>Device owners, however, can use any other mechanism they want to assure the
mselves that local identity
certificates are inserted into the intended device, including physical inspectio
n and programming
in a secure location, if they prefer to avoid placing trust in the manufacturer-
provided keys.</t>
</list></t>
<t>Clearly, local keys can’t be used for secure Zero Touch provisioning; install <!-- [I-D.richardson-rats-usecases] IESG state Expired -->
ation of the local keys
can only be done by some process that runs before the device is installed for ne
twork operation,
or using procedures such as those outlined in Bootstrapping Remote Secure Key In
frastructure (BRSKI) <xref target="RFC8995"/>.</t>
<t>On the other end of the device life cycle, provision should be made to wipe l <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
ocal keys when a device .richardson-rats-usecases.xml"/>
is decommissioned, to indicate that the device is no longer owned by the enterpr
ise. The manufacturer’s
Initial identity keys must be preserved, as they contain no information that’s n
ot already printed on
the device’s serial number plate.</t>
</section> <!-- [I-D.birkholz-rats-tuda] IESG state I-D Exists -->
<section anchor="other-factors-for-trustworthy-operation" title="Other Factors f
or Trustworthy Operation">
<t>In addition to trustworthy provisioning of keys, RIV depends on a number of o ther factors for trustworthy operation.</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .birkholz-rats-tuda.xml"/>
<t><list style="symbols"> <!-- [I-D.birkholz-rats-network-device-subscription] Replaced by [I-D.ietf-rats-
<t>Secure identity depends on mechanisms to prevent per-device secret keys fro network-device-subscription] IESG state I-D Exists -->
m being compromised. The TPM
provides this capability as a Root of Trust for Storage.</t>
<t>Attestation depends on an unbroken chain of measurements, starting from the
very first
measurement. See <xref target="using-tpm"/> for background on TPM practices.</t
>
<t>That first measurement is made by code called the Root of Trust for Measure
ment, typically done by trusted
firmware stored in boot flash. Mechanisms for maintaining the trustworthiness o
f the RTM are out of
scope for RIV, but could include immutable firmware, signed updates, or a vendor
-specific hardware
verification technique. See <xref target="root-of-trust"/> for background on
roots of trust.</t>
<t>The device owner SHOULD provide some level of physical defense for the devi
ce. If a TPM that has already been programmed
with an authentic DevID is stolen and inserted into a counterfeit device, attest
ation of that counterfeit
device may become indistinguishable from an authentic device.</t>
</list></t>
<t>RIV also depends on reliable Reference Values, as expressed by the RIM <xref <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
target="RIM"/>. The definition of .ietf-rats-network-device-subscription.xml"/>
trust procedures for RIMs is out of scope for RIV, and the device owner is free
to use any policy to validate
a set of reference measurements. It should also be noted that, while RIV can pr
ovide a reliable indication that a known software package is in use by the devic
e, and that the package has not been tampered, it is the device owner’s responsi
bility to determine that it’s the correct package for the application.</t>
<t>RIMs may be conveyed out-of-band or in-band, as part of the attestation <!-- [I-D.ietf-rats-eat] IESG state I-D Exists -->
process (see <xref target="RIM-policy"/>). But for network devices, where softw
are is usually shipped as a self-contained
package, RIMs signed by the manufacturer and delivered in-band may be more conve
nient for the device owner.</t>
<t>The validity of RIV attestation results is also influenced by procedures used to create Reference Values:</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-rats-eat.xml"/>
<t><list style="symbols"> <reference anchor="TPM-1.2" target="https://trustedcomputinggroup.org/re
<t>While the RIM itself is signed, supply-chains SHOULD be carefully scrutiniz source/tpm-main-specification/">
ed to ensure that the values are <front>
not subject to unexpected manipulation prior to signing. Insider-attacks agains <title>TPM 1.2 Main Specification</title>
t code bases and build chains <author>
are particularly hard to spot.</t> <organization>Trusted Computing Group</organization>
<t>Designers SHOULD guard against hash collision attacks. Reference Integrity </author>
Manifests often give hashes for large objects <date year="2011" month="March"/>
of indeterminate size; if one of the measured objects can be replaced with an im </front>
plant engineered to produce <refcontent>Level 2, Version 1.2, Revision 116</refcontent>
the same hash, RIV will be unable to detect the substitution. TPM1.2 uses SHA-1 </reference>
hashes only, which have been
shown to be susceptible to collision attack. TPM2.0 will produce quotes with SH
A-256, which so far has resisted
such attacks. Consequently, RIV implementations SHOULD use TPM2.0.</t>
</list></t>
</section> <!-- [rfced] Informative References. [TPM-2.0] has been updated to Revision 1.83
</section> . May we update [TPM-2.0] to use the latest revision number?
<section anchor="IANA" title="IANA Considerations">
<t>This document has no IANA actions.</t> Original:
[TPM2.0] Trusted Computing Group, "Trusted Platform Module
Library", Family "2.0", Level 00, Revision 01.59, November
2019, <https://trustedcomputinggroup.org/resource/tpm-
library-specification/>.
</section> Perhaps:
<section anchor="conclusion" title="Conclusion"> [TPM-2.0] Trusted Computing Group, "Trusted Platform Module
Library", Family "2.0", Level 00, Revision 01.83, March
2024, <https://trustedcomputinggroup.org/resource/tpm-
library-specification/>.
-->
<t>TCG technologies can play an important part in the implementation of Remote <reference anchor="TPM-2.0" target="https://trustedcomputinggroup.org/re
Integrity Verification. Standards for many of the components needed for source/tpm-library-specification/">
implementation of RIV already exist:</t> <front>
<title>Trusted Platform Module Library</title>
<author>
<organization>Trusted Computing Group</organization>
</author>
<date year="2019" month="November"/>
</front>
<refcontent>Family "2.0", Level 00, Revision 01.59</refcontent>
</reference>
<t><list style="symbols"> <reference anchor="PLATFORM-CERTS" target="https://trustedcomputinggroup
<t>Platform identity can be based on IEEE 802.1AR Device Identity, coupled wit .org/resource/tcg-platform-attribute-credential-profile/">
h <front>
careful supply-chain management by the manufacturer.</t> <title>TCG Platform Attribute Credential Profile</title>
<t>Complex supply chains can be certified using TCG Platform Certificates <xre <author>
f target="Platform-Certificates"/>.</t> <organization>Trusted Computing Group</organization>
<t>The TCG TAP mechanism coupled with <xref target="I-D.ietf-rats-yang-tpm-cha </author>
rra"/> can be used to retrieve attestation evidence.</t> <date year="2018" month="January"/>
<t>Reference Values must be conveyed from the software authority (e.g., </front>
the manufacturer) in Reference Integrity Manifests, to the system in which verif <refcontent>Specification Version 1.0, Revision 16</refcontent>
ication will take place. IETF and TCG </reference>
SWID and CoSWID work (<xref target="I-D.ietf-sacm-coswid"/>, <xref target="RIM"/
>) forms the basis for this function.</t>
</list></t>
</section> <reference anchor="PROV-TPM-2.0" target="https://trustedcomputinggroup.o
<section anchor="acknowledgements" title="Acknowledgements"> rg/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf">
<front>
<title>TCG TPM v2.0 Provisioning Guidance</title>
<author>
<organization>Trusted Computing Group</organization>
</author>
<date year="2017" month="March"/>
</front>
<refcontent>Version 1.0, Revision 1.0</refcontent>
</reference>
<t>The authors wish to thank numerous reviewers for generous assistance, includi <reference anchor="IEEE-802.1X">
ng William Bellingrath, Mark Baushke, Ned Smith, <front>
Henk Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas Hardjono, <title>IEEE Standard for Local and Metropolitan Area Networks - Port
Bill Sulzen, Willard (Monty) Wiseman, -Based Network Access Control</title>
Kathleen Moriarty, Nancy Cam-Winget and Shwetha Bhandari</t> <author>
<organization>IEEE</organization>
</author>
<date year="2020" month="February"/>
</front>
<seriesInfo name="IEEE Std" value="802.1X-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9018454"/>
</reference>
</section> <reference anchor="IEEE-802.1AE">
<section anchor="appendix" title="Appendix"> <front>
<title>IEEE Standard for Local and metropolitan area networks - Medi
a Access Control (MAC) Security</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2018"/>
</front>
<seriesInfo name="IEEE Std" value="802.1AE-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421" />
</reference>
<section anchor="using-tpm" title="Using a TPM for Attestation"> <reference anchor="LLDP">
<front>
<title>IEEE Standard for Local and metropolitan area networks - Stat
ion and Media Access Control Connectivity Discovery</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2016" month="March"/>
</front>
<seriesInfo name="IEEE Std" value="802.1AB-2016"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7433915"/>
</reference>
<t>The Trusted Platform Module and surrounding ecosystem provide three interlock <reference anchor="TCG-RT" target="https://trustedcomputinggroup.org/wp-
ing capabilities to enable secure collection content/uploads/TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf">
of evidence from a remote device, Platform Configuration Registers (PCRs), a Quo <front>
te mechanism, and a standardized Event Log.</t> <title>TCG Roots of Trust Specification</title>
<author>
<organization>Trusted Computing Group</organization>
</author>
<date year="2018" month="July"/>
</front>
<refcontent>(Draft), Family "1.0", Level 00, Revision 0.20</refcontent
>
</reference>
<t>Each TPM has at least eight and at most twenty-four PCRs (depending on the pr <reference anchor="SP800-193" target="https://nvlpubs.nist.gov/nistpubs/
ofile and vendor choices), each one large SpecialPublications/NIST.SP.800-193.pdf">
<front>
<title>Platform Firmware Resiliency Guidelines</title>
<author>
<organization>NIST</organization>
</author>
<date year="2018" month="May"/>
</front>
<seriesInfo name="NIST SP" value="800-193"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-193"/>
</reference>
<reference anchor="SP800-155" target="https://csrc.nist.gov/files/pubs/s
p/800/155/ipd/docs/draft-sp800-155_dec2011.pdf">
<front>
<title>BIOS Integrity Measurement Guidelines (Draft)</title>
<author>
<organization>NIST</organization>
</author>
<date year="2011" month="December"/>
</front>
<seriesInfo name="NIST SP" value="800-155 (Draft)"/>
</reference>
<reference anchor="NET-EQ" target="https://trustedcomputinggroup.org/res
ource/tcg-guidance-securing-network-equipment/">
<front>
<title>TCG Guidance for Securing Network Equipment Using TCG Technol
ogy</title>
<author>
<organization>Trusted Computing Group</organization>
</author>
<date year="2018" month="January"/>
</front>
<refcontent>Version 1.0, Revision 29</refcontent>
</reference>
<reference anchor="NIST-IR-8060" target="https://nvlpubs.nist.gov/nistpu
bs/ir/2016/NIST.IR.8060.pdf">
<front>
<title>Guidelines for the Creation of Interoperable Software Identif
ication (SWID) Tags</title>
<author initials="D" surname="Waltermire" fullname="David Waltermire
"></author>
<author initials="B. A." surname="Cheikes" fullname="Brant A. Cheike
s"></author>
<author initials="L" surname="Feldman" fullname="Larry Feldman"></au
thor>
<author initials="G" surname="Witte" fullname="Greg Witte"></author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="NIST NISTIR" value="8060"/>
<seriesInfo name="DOI" value="10.6028/NIST.IR.8060"/>
</reference>
<reference anchor="AIK-ENROLL" target="https://trustedcomputinggroup.org
/resource/tcg-infrastructure-working-group-a-cmc-profile-for-aik-certificate-enr
ollment/">
<front>
<title>TCG Infrastructure Working Group A CMC Profile for AIK Certif
icate Enrollment</title>
<author>
<organization>Trusted Computing Group</organization>
</author>
<date year="2011" month="March"/>
</front>
<refcontent>Version 1.0, Revision 7</refcontent>
</reference>
<reference anchor="SWID-GEN" target="https://github.com/Labs64/swid-mave
n-plugin">
<front>
<title>SoftWare IDentification (SWID) Tags Generator (Maven Plugin)<
/title>
<author>
<organization>Labs64</organization>
</author>
</front>
</reference>
</references>
</references>
<section anchor="appendix" numbered="true" toc="default">
<name>Supporting Materials</name>
<section anchor="using-tpm" numbered="true" toc="default">
<name>Using a TPM for Attestation</name>
<t>The TPM and surrounding ecosystem provide three interlocking capabili
ties to enable secure collection
of evidence from a remote device: PCRs, a Quote mechanism, and a standardized Ev
ent Log.</t>
<t>Each TPM has at least eight and at most twenty-four PCRs (depending o
n the profile and vendor choices), each one large
enough to hold one hash value (SHA-1, SHA-256, and other hash algorithms can 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 outsid be used, depending on TPM version). PCRs can't be accessed directly from outsid
e the chip, but the TPM e the chip, but the TPM
interface provides a way to “extend” a new security measurement hash into any PC interface provides a way to "extend" a new security measurement hash into any PC
R, a process by which the existing value R, a process by which the existing value
in the PCR is hashed with the new security measurement hash, and the result plac ed back into the same PCR. The result in the PCR is hashed with the new security measurement hash, and the result plac ed 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.</t> is a composite fingerprint comprising the hash of all the security measurements extended into each PCR since the system was reset.</t>
<t>Every time a PCR is extended, an entry should be added to the corresp
<t>Every time a PCR is extended, an entry should be added to the corresponding E onding Event Log. Logs contain the security
vent Log. Logs contain the security
measurement hash plus informative fields offering hints as to which event genera ted the security measurement. measurement hash plus informative fields offering hints as to which event genera ted the security measurement.
The Event Log itself is protected against accidental manipulation, but it is imp The Event Log itself is protected against accidental manipulation, but it is imp
licitly tamper-evident – any licitly tamper-evident: Any
verification process can read the security measurement hash from the log events, verification process can read the security measurement hash from the log events,
compute the composite value compute the composite value,
and compare that to what ended up in the PCR. If there’s no discrepancy, the l and compare that to what is in the PCR. If there's no discrepancy, the logs do
ogs do provide an accurate provide an accurate
view of what was placed into the PCR.</t> view of what was placed into the PCR.</t>
<t>Note that the composite hash-of-hashes recorded in PCRs is order-depe
<t>Note that the composite hash-of-hashes recorded in PCRs is order-dependent, r ndent, resulting in different PCR values for different
esulting in different PCR values for different ordering of the same set of events (e.g., Event A followed by Event B yields a d
ordering of the same set of events (e.g. Event A followed by Event B yields a di ifferent PCR value than B followed by A).
fferent PCR value than B followed by A).
For single-threaded code, where both the events and their order are fixed, a Ver ifier may validate a single PCR value, and use the log only to diagnose a mismat ch from Reference Values. However, operating system code is usually For single-threaded code, where both the events and their order are fixed, a Ver ifier may validate a single PCR value, and use the log only to diagnose a mismat ch from Reference Values. However, operating system code is usually
non-deterministic, meaning that there may never be a single “known good” PCR val ue. In this case, the Verifier may have nondeterministic, meaning that there may never be a single "known good" PCR valu e. In this case, the Verifier may have
to verify that the log is correct, and then analyze each item in the log to dete rmine if it represents an authorized event.</t> to verify that the log is correct, and then analyze each item in the log to dete rmine if it represents an authorized event.</t>
<t>In a conventional TPM Attestation environment, the first measurement
<t>In a conventional TPM Attestation environment, the first measurement must be must be made and extended into the TPM by trusted
made and extended into the TPM by trusted device code (called the RTM). That first measurement should cover the segment o
device code (called the Root of Trust for Measurement, RTM). That first measure f
ment should cover the segment of
code that is run immediately after the RTM, which then measures the next code se gment before running it, and so on, code that is run immediately after the RTM, which then measures the next code se gment before running it, and so on,
forming an unbroken chain of trust. See <xref target="TCGRoT"/> for more on Mut forming an unbroken chain of trust. See <xref target="TCG-RT" format="default"/
able vs Immutable roots of trust.</t> > for more on Mutable vs. Immutable Roots of Trust.</t>
<t>The TPM provides another mechanism called a Quote that can read the c
<t>The TPM provides another mechanism called a Quote that can read the current v urrent value of the PCRs and package them,
alue of the PCRs and package them, along with the Verifier's nonce, into a TPM-specific data structure signed by an
along with the Verifier’s nonce, into a TPM-specific data structure signed by an Attestation private key, known
Attestation private key, known
only to the TPM.</t> only to the TPM.</t>
<t>It's important to note that the Quote data structure is signed inside
<t>As noted above in <xref target="security-cons"/> Security Considerations, it’ the TPM (see <xref target="security-cons" format="default"/>, Security Consider
s important to note that the Quote data structure is signed inside the TPM. The ations). The trust model is preserved by retrieving the Quote in a way that doe
trust model is preserved by retrieving the Quote in a way that does not invalid s not invalidate the signature,
ate the signature, as specified in <xref target="RFC9684" format="default"/>. The structure of the
as specified in <xref target="I-D.ietf-rats-yang-tpm-charra"/>. The structure o command and response for a quote, including its signature, as generated by the
f the command and response for a quote, including its signature, as generated by TPM, can be seen in Part 3, Section 16.5, of <xref target="TPM-1.2" format="defa
the TPM, can be seen in <xref target="TPM1.2"></xref> Part 3, Section 16.5, and ult"/> and Section 18.4.2 of <xref target="TPM-2.0" format="default"/>.</t>
<xref target="TPM2.0"></xref> Section 18.4.2.</t> <t>The Verifier uses the Quote and Log together. The Quote contains the
composite hash of the complete sequence
<t>The Verifier uses the Quote and Log together. The Quote contains the composi of security measurement hashes, signed by the TPM's private AK. The Log contain
te hash of the complete sequence s a record of each
of security measurement hashes, signed by the TPM’s private Attestation Key. Th measurement extended into the TPM's PCRs. By computing the composite hash of al
e Log contains a record of each l the measurements, the Verifier
measurement extended into the TPM’s PCRs. By computing the composite hash of al
l the measurements, the Verifier
can verify the integrity of the Event Log, even though the Event Log itself is n ot signed. Each hash in the validated can verify the integrity of the Event Log, even though the Event Log itself is n ot signed. Each hash in the validated
Event Log can then be compared to corresponding expected values in the set of Re ference Values to Event Log can then be compared to corresponding expected values in the set of Re ference Values to
validate overall system integrity.</t> validate overall system integrity.</t>
<t>A summary of information exchanged in obtaining quotes from TPM 1.2 a
<t>A summary of information exchanged in obtaining quotes from TPM1.2 and TPM2.0 nd TPM 2.0 can be found in <xref target="TAP" format="default"/>, Section 4.
can be found in <xref target="TAP"/>, Section 4. Detailed information about PCRs and Quote data structures can be found in <xref
Detailed information about PCRs and Quote data structures can be found in <xref target="TPM-1.2" format="default"/>, <xref target="TPM-2.0" format="default"/>.
target="TPM1.2"/>, <xref target="TPM2.0"/>. Recommended log Recommended log
formats include <xref target="PC-Client-BIOS-TPM-2.0"/>, and <xref target="Canon formats include <xref target="PC-CLIENT-BIOS-TPM-2.0" format="default"/>, and <x
ical-Event-Log"/>.</t> ref target="CEL" format="default"/>.</t>
</section>
</section> <section anchor="root-of-trust" numbered="true" toc="default">
<section anchor="root-of-trust" title="Root of Trust for Measurement"> <name>Root of Trust for Measurement (RTM)</name>
<t>The measurements needed for attestation require that the device being
<t>The measurements needed for attestation require that the device being atteste attested
d is equipped with an RTM, that is, some trustworthy
is equipped with a Root of Trust for Measurement, that is, some trustworthy
mechanism that can compute the first measurement in the chain of trust required mechanism that can compute the first measurement in the chain of trust required
to attest that each stage of system startup is verified, a Root of Trust for Sto rage (i.e., to attest that each stage of system startup is verified, a Root of Trust for Sto rage (i.e.,
the TPM PCRs) to record the results, and a Root of Trust the TPM PCRs) to record the results, and a Root of Trust
for Reporting to report the results.</t> for Reporting to report the results.</t>
<t>While there are many complex aspects of Roots of Trust (<xref target= "TCG-RT" format="default"/> <xref target="SP800-155" format="default"/> <xref ta rget="SP800-193" format="default"/>), two aspects that
<t>While there are many complex aspects of Roots of Trust ( <xref target="TCGRoT "/>, <xref target="SP800-155"/>, <xref target="SP800-193"/>), two aspects that
are important in the case of attestation are:</t> are important in the case of attestation are:</t>
<ul spacing="normal">
<li>The first measurement computed by the RTM and stored
in the TPM's Root of Trust for Storage must be assumed to be correct.</li>
<li>There must not be a way to reset the Root of Trust for Storage wit
hout re-entering
the RTM code.</li>
</ul>
<t>The first measurement must be computed by code that is implicitly tru
sted; if that
first measurement can be subverted, none of the remaining measurements can
be trusted. (See <xref target="SP800-155" format="default"/>.)</t>
<t>It's important to note that the trustworthiness of the RTM code canno
t be assured by
the TPM or TPM supplier -- code or procedures external to the TPM must guarantee
the
security of the RTM.</t>
</section>
<section anchor="layering-model-for-network-equipment-attester-and-verifie
r" numbered="true" toc="default">
<name>Layering Model for Network Equipment Attester and Verifier</name>
<t>Retrieval of identity and attestation state uses one protocol stack,
while
retrieval of Reference Values uses a different set of protocols.
<xref target="RIV-Protocol-Stacks" format="default"/> shows the components invol
ved.</t>
<!-- [rfced] Section A.3. In Figure 5, is the following a label? Should its cont
ents be moved to the figure caption?
<t><list style="symbols"> Original:
<t>The first measurement computed by the Root of Trust for Measurement, and st
ored
in the TPM’s Root of Trust for Storage, must be assumed to be correct.</t>
<t>There must not be a way to reset the Root of Trust for Storage without re-e
ntering
the Root of Trust for Measurement code.</t>
</list></t>
<t>The first measurement must be computed by code that is implicitly trusted; if ********************************************************************
that * IETF Attestation Reference Interaction Diagram *
first measurement can be subverted, none of the remaining measurements can ********************************************************************
be trusted. (See <xref target="SP800-155"/>)</t>
<t>It’s important to note that the trustworthiness of the RTM code cannot be ass -->
ured by <!-- [rfced] Section A.3. In Figure 5, what does "PTS2.0" mean?
the TPM or TPM supplier – code or procedures external to the TPM must guarantee
the
security of the RTM.</t>
</section> Original:
<section anchor="layering-model-for-network-equipment-attester-and-verifier" tit
le="Layering Model for Network Equipment Attester and Verifier">
<t>Retrieval of identity and attestation state uses one protocol stack, while ......................... .........................
retrieval of Reference Values uses a different set of protocols. Figure . Reference Integrity . . TAP (PTS2.0) Info .
5 shows the components involved.</t> . Manifest . . Model and Canonical .
. . . Log Format .
......................... .........................
<figure title="RIV Protocol Stacks" anchor="RIV-Protocol-Stacks"><artwork align= -->
"left"><![CDATA[ <figure anchor="RIV-Protocol-Stacks">
<name>RIV Protocol Stacks</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
+-----------------------+ +-------------------------+ +-----------------------+ +-------------------------+
| | | | | | | |
| Attester |<-------------| Verifier | | Attester |<-------------| Verifier |
| (Device) |------------->| (Management Station) | | (Device) |------------->| (Management Station) |
| | | | | | | | | |
+-----------------------+ | +-------------------------+ +-----------------------+ | +-------------------------+
| |
-------------------- -------------------- -------------------- --------------------
| | | |
------------------------------- --------------------------------- ------------------------------- ---------------------------------
|Reference Values | | Attestation | | Reference Values | | Attestation |
------------------------------- --------------------------------- ------------------------------- ---------------------------------
******************************************************************** ********************************************************************
* IETF Attestation Reference Interaction Diagram * * IETF Attestation Reference Interaction Diagram *
******************************************************************** ********************************************************************
......................... ......................... ......................... .........................
. Reference Integrity . . TAP (PTS2.0) Info . . Reference Integrity . . TAP (PTS2.0) Info .
. Manifest . . Model and Canonical . . Manifest . . Model and Canonical .
. . . Log Format . . . . Log Format .
......................... ......................... ......................... .........................
************************* ************************* ************************* *************************
* YANG SWID Module * * YANG Attestation * * YANG SWID Module * * YANG Attestation *
* I-D.ietf-sacm-coswid * * Module * * RFC9393 * * Module *
* * * I-D.ietf-rats- * * * * RFC9684 *
* * * yang-tpm-charra * * * * *
************************* ************************* ************************* *************************
************************* ************************* ************************* *************************
* XML, JSON, CBOR (etc) * * XML, JSON, CBOR (etc) * * XML, JSON, CBOR, etc. * * XML, JSON, CBOR, etc. *
************************* ************************* ************************* *************************
************************* ************************* ************************* *************************
* RESTCONF/NETCONF * * RESTCONF/NETCONF * * RESTCONF/NETCONF * * RESTCONF/NETCONF *
************************* ************************* ************************* *************************
************************* ************************* ************************* *************************
* TLS, SSH * * TLS, SSH * * TLS, SSH * * TLS, SSH *
************************* ************************* ************************* *************************
]]></artwork>
]]></artwork></figure> </figure>
<t>IETF documents are captured in boxes surrounded by asterisks. TCG doc
<t>IETF documents are captured in boxes surrounded by asterisks. TCG documents uments
are shown in boxes surrounded by dots.</t> are shown in boxes surrounded by dots.</t>
</section>
</section> <section anchor="implementation-notes" numbered="true" toc="default">
<section anchor="implementation-notes" title="Implementation Notes"> <name>Implementation Notes</name>
<t><xref target="Component-Status" format="default"/> summarizes many of
<t><xref target="Component-Status"/> summarizes many of the actions needed to co the actions needed to complete an Attestation
mplete an Attestation
system, with links to relevant documents. While documents are controlled system, with links to relevant documents. While documents are controlled
by several standards organizations, the implied actions required for by several standards organizations, the implied actions required for
implementation are all the responsibility of the manufacturer of the device, implementation are all the responsibility of the manufacturer of the device,
unless otherwise noted.</t> unless otherwise noted.</t>
<t>As noted, SWID tags can be generated many ways, but one possible tool is <xref target="SWID-GEN" format="default"/>.</t>
<t>As noted, SWID tags can be generated many ways, but one possible tool is <xre <!-- [rfced] Appendix A.4, Table 2.
f target="SWID-Gen"></xref></t>
<figure title="Component Status" anchor="Component-Status"><artwork align="left"
><![CDATA[
+------------------------------------------------------------------+
| Component | Controlling |
| | Specification |
| Make a Secure execution environment | TCG RoT |
| o Attestation depends on a secure root of | UEFI.org |
| trust for measurement outside the TPM, as | |
| well as roots for storage and reporting | |
| inside the TPM. | |
| o Refer to TCG Root of Trust for Measurement.| |
| o NIST SP 800-193 also provides guidelines | |
| on Roots of Trust | |
| Provision the TPM as described in |[Platform-DevID-TPM-2.0]|
| TCG documents. | TCG Platform |
| | Certificate |
| Put a DevID or Platform Cert in the TPM | TCG TPM DevID |
| o Install an Initial Attestation Key at the | TCG Platform |
| same time so that Attestation can work out | Certificate |
| of the box |-----------------
| o Equipment suppliers and owners may want to | IEEE 802.1AR |
| implement Local Device ID as well as | |
| Initial Device ID | |
| Connect the TPM to the TLS stack | Vendor TLS |
| o Use the DevID in the TPM to authenticate | stack (This |
| TAP connections, identifying the device | action is |
| | configuring TLS|
| | to use the DevID |
| | as its client |
| | certificate) |
| Make CoSWID tags for BIOS/Loader/Kernel objects | IETF CoSWID |
| o Add reference measurements into SWID tags | ISO/IEC 19770-2|
| o Manufacturer should sign the SWID tags | NIST IR 8060 |
| o The TCG RIM-IM identifies further | |
| procedures to create signed RIM | |
| documents that provide the necessary | |
| reference information | |
| Package the SWID tags with a vendor software | Retrieve tags |
| release | with |
| o A tag-generator plugin such | I-D.ietf-sacm-coswid|
| as [SWID-Gen] can be used |----------------|
| | TCG PC Client |
| | RIM |
| Use PC Client measurement definitions | TCG PC Client |
| to define the use of PCRs | BIOS |
| (although Windows OS is rare on Networking | |
| Equipment, UEFI BIOS is not) | |
| Use TAP to retrieve measurements | |
| o Map to YANG | YANG Module for|
| Use Canonical Log Format | Basic |
| | Attestation |
| | TCG Canonical |
| | Log Format |
| Posture Collection Server (as described in IETF | |
| SACMs ECP) should request the | |
| attestation and analyze the result | |
| The Management application might be broken down | |
| to several more components: | |
| o A Posture Manager Server | |
| which collects reports and stores them in | |
| a database | |
| o One or more Analyzers that can look at the| |
| results and figure out what it means. | |
]]></artwork></figure>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a
uthor>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/><
/author>
<date month='August' year='2018'/>
<abstract><t>This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate over the
Internet in a way that is designed to prevent eavesdropping, tampering, and mess
age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs
5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2
implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>
<reference anchor='RFC4253' target='https://www.rfc-editor.org/info/rfc4253'>
<front>
<title>The Secure Shell (SSH) Transport Layer Protocol</title>
<author fullname='T. Ylonen' initials='T.' surname='Ylonen'><organization/></aut
hor>
<author fullname='C. Lonvick' initials='C.' role='editor' surname='Lonvick'><org
anization/></author>
<date month='January' year='2006'/>
<abstract><t>The Secure Shell (SSH) is a protocol for secure remote login and ot
her secure network services over an insecure network.</t><t>This document descri
bes the SSH transport layer protocol, which typically runs on top of TCP/IP. Th
e protocol can be used as a basis for a number of secure network services. It p
rovides strong encryption, server authentication, and integrity protection. It
may also provide compression.</t><t>Key exchange method, public key algorithm, s
ymmetric encryption algorithm, message authentication algorithm, and hash algori
thm are all negotiated.</t><t>This document also describes the Diffie-Hellman ke
y exchange method and the minimal set of algorithms that are needed to implement
the SSH transport layer protocol. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4253'/>
<seriesInfo name='DOI' value='10.17487/RFC4253'/>
</reference>
<reference anchor='RFC6241' target='https://www.rfc-editor.org/info/rfc6241'>
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname='R. Enns' initials='R.' role='editor' surname='Enns'><organizat
ion/></author>
<author fullname='M. Bjorklund' initials='M.' role='editor' surname='Bjorklund'>
<organization/></author>
<author fullname='J. Schoenwaelder' initials='J.' role='editor' surname='Schoenw
aelder'><organization/></author>
<author fullname='A. Bierman' initials='A.' role='editor' surname='Bierman'><org
anization/></author>
<date month='June' year='2011'/>
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this docume
nt provides mechanisms to install, manipulate, and delete the configuration of n
etwork devices. It uses an Extensible Markup Language (XML)-based data encoding
for the configuration data as well as the protocol messages. The NETCONF proto
col operations are realized as remote procedure calls (RPCs). This document obs
oletes RFC 4741. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6241'/>
<seriesInfo name='DOI' value='10.17487/RFC6241'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='RFC5280' target='https://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revo
cation List (CRL) Profile</title>
<author fullname='D. Cooper' initials='D.' surname='Cooper'><organization/></aut
hor>
<author fullname='S. Santesson' initials='S.' surname='Santesson'><organization/
></author>
<author fullname='S. Farrell' initials='S.' surname='Farrell'><organization/></a
uthor>
<author fullname='S. Boeyen' initials='S.' surname='Boeyen'><organization/></aut
hor>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></a
uthor>
<author fullname='W. Polk' initials='W.' surname='Polk'><organization/></author>
<date month='May' year='2008'/>
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificat
e revocation list (CRL) for use in the Internet. An overview of this approach a
nd model is provided as an introduction. The X.509 v3 certificate format is des
cribed in detail, with additional information regarding the format and semantics
of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with sta
ndard and Internet-specific extensions. An algorithm for X.509 certification pa
th validation is described. An ASN.1 module and examples are provided in the ap
pendices. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>
<reference anchor='I-D.ietf-rats-yang-tpm-charra'>
<front>
<title>A YANG Data Model for Challenge-Response-based Remote Attestation P
rocedures using TPMs</title>
<author fullname='Henk Birkholz'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Michael Eckel'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Shwetha Bhandari'>
<organization>ThoughtSpot</organization>
</author>
<author fullname='Eric Voit'>
<organization>Cisco Systems</organization>
</author>
<author fullname='Bill Sulzen'>
<organization>Cisco Systems</organization>
</author>
<author fullname='Liang Xia (Frank)'>
<organization>Huawei Technologies</organization>
</author>
<author fullname='Tom Laffey'>
<organization>Hewlett Packard Enterprise</organization>
</author>
<author fullname='Guy C. Fedorkow'>
<organization>Juniper Networks</organization>
</author>
<date day='20' month='March' year='2022'/>
<abstract>
<t> This document defines YANG RPCs and a few configuration nodes
required to retrieve attestation evidence about integrity
measurements from a device, following the operational context defined
in TPM-based Network Device Remote Integrity Verification.
Complementary measurement logs are also provided by the YANG RPCs,
originating from one or more roots of trust for measurement (RTMs).
The module defined requires at least one TPM 1.2 or TPM 2.0 as well
as a corresponding TPM Software Stack (TSS), or equivalent hardware
implementations that include the protected capabilities as provided
by TPMs as well as a corresponding software stack, included in the
device components of the composite device the YANG server is running
on.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rats-yang-tpm-charra-18'/
>
<format target='https://www.ietf.org/archive/id/draft-ietf-rats-yang-tpm-char
ra-18.txt' type='TXT'/>
</reference>
<reference anchor='I-D.ietf-sacm-coswid'>
<front>
<title>Concise Software Identification Tags</title>
<author fullname='Henk Birkholz'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Jessica Fitzgerald-McKay'>
<organization>National Security Agency</organization>
</author>
<author fullname='Charles Schmidt'>
<organization>The MITRE Corporation</organization>
</author>
<author fullname='David Waltermire'>
<organization>National Institute of Standards and Technology</organizati
on>
</author>
<date day='7' month='March' year='2022'/>
<abstract>
<t> ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide a
n
extensible XML-based structure to identify and describe individual
software components, patches, and installation bundles. SWID tag
representations can be too large for devices with network and storage
constraints. This document defines a concise representation of SWID
tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of
semantics and features as SWID tags, as well as new semantics that
allow CoSWIDs to describe additional types of information, all in a
more memory efficient format.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-sacm-coswid-21'/>
<format target='https://www.ietf.org/archive/id/draft-ietf-sacm-coswid-21.txt
' type='TXT'/>
</reference>
<reference anchor='I-D.ietf-rats-architecture'>
<front>
<title>Remote Attestation Procedures Architecture</title>
<author fullname='Henk Birkholz'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Dave Thaler'>
<organization>Microsoft</organization>
</author>
<author fullname='Michael Richardson'>
<organization>Sandelman Software Works</organization>
</author>
<author fullname='Ned Smith'>
<organization>Intel Corporation</organization>
</author>
<author fullname='Wei Pan'>
<organization>Huawei Technologies</organization>
</author>
<date day='8' month='February' year='2022'/>
<abstract>
<t> In network protocol exchanges it is often useful for one end of a
communication to know whether the other end is in an intended
operating state. This document provides an architectural overview of
the entities involved that make such tests possible through the
process of generating, conveying, and evaluating evidentiary claims.
An attempt is made to provide for a model that is neutral toward
processor architectures, the content of claims, and protocols.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rats-architecture-15'/>
<format target='https://www.ietf.org/archive/id/draft-ietf-rats-architecture-
15.txt' type='TXT'/>
</reference>
<reference anchor="IEEE-802-1AR" >
<front>
<title>802.1AR-2018 - IEEE Standard for Local and Metropolitan Area Networks
- Secure Device Identity, IEEE Computer Society</title>
<author initials="M." surname="Seaman">
<organization>IEEE Computer Society</organization>
</author>
<date year="2018" month="August"/>
</front>
</reference>
<reference anchor="TAP" target="https://trustedcomputinggroup.org/resource/tcg-t
ap-information-model/">
<front>
<title>TCG Trusted Attestation Protocol (TAP) Information Model for TPM Fami
lies 1.2 and 2.0 and DICE Family 1.0, Version 1.0, Revision 0.36</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2018" month="October"/>
</front>
</reference>
<reference anchor="Canonical-Event-Log" target="https://trustedcomputinggroup.or
g/resource/canonical-event-log-format/">
<front>
<title>Canonical Event Log Format Version 1.0 Revision .41, February 25, 202
2</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2020" month="December"/>
</front>
</reference>
<reference anchor="PC-Client-BIOS-TPM-2.0" target="https://trustedcomputinggroup
.org/resource/pc-client-specific-platform-firmware-profile-specification/">
<front>
<title>PC Client Specific Platform Firmware Profile Specification Family "2.
0", Level 00 Revision 1.05 Revision 23, May 7, 2021</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2021" month="May"/>
</front>
</reference>
<reference anchor="PC-Client-EFI-TPM-1.2" target="https://trustedcomputinggroup.
org/resource/tcg-efi-platform-specification/">
<front>
<title>TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Specificati
on Version 1.22, Revision 15</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2014" month="January"/>
</front>
</reference>
<reference anchor="RIM" target="https://trustedcomputinggroup.org/resource/tcg-r
eference-integrity-manifest-rim-information-model/">
<front>
<title>TCG Reference Integrity Manifest (RIM) Information Model, v1.0, Revis
ion 0.16, Nov 12, 2020</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2019" month="June"/>
</front>
</reference>
<reference anchor="PC-Client-RIM" target="https://trustedcomputinggroup.org/reso
urce/tcg-pc-client-reference-integrity-manifest-specification/">
<front>
<title>TCG PC Client Reference Integrity Manifest Specification, v1.04, Nov
4, 2020</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2019" month="December"/>
</front>
</reference>
<reference anchor="Platform-DevID-TPM-2.0" target="https://trustedcomputinggroup
.org/resource/tpm-2-0-keys-for-device-identity-and-attestation/">
<front>
<title>TPM 2.0 Keys for Device Identity and Attestation, Specification Versi
on 1.0, Revision 2</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2020" month="September"/>
</front>
</reference>
<reference anchor="Platform-ID-TPM-1.2" target="https://trustedcomputinggroup.or
g/resource/tpm-keys-for-platform-identity-for-tpm-1-2-2/">
<front>
<title>TPM Keys for Platform Identity for TPM 1.2, Specification Version 1.0
, Revision 3</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2015" month="August"/>
</front>
</reference>
<reference anchor="SWID" target="https://www.iso.org/standard/65666.html">
<front>
<title>Information Technology Software Asset Management Part 2: Software Ide
ntification Tag, ISO/IEC 19770-2</title>
<author >
<organization>The International Organization for Standardization/Internati
onal Electrotechnical Commission</organization>
</author>
<date year="2015" month="October"/>
</front>
</reference>
<reference anchor="IMA" target="https://sourceforge.net/p/linux-ima/wiki/Home/">
<front>
<title>Integrity Measurement Architecture</title>
<author surname="dsafford">
<organization>dsafford</organization>
</author>
<author surname="kds_etu">
<organization>kds_etu</organization>
</author>
<author surname="mzohar">
<organization>mzohar</organization>
</author>
<author surname="reinersailer">
<organization>reinersailer</organization>
</author>
<author surname="serge_hallyn">
<organization>serge_hallyn</organization>
</author>
<date year="2019" month="June"/>
</front>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC6813' target='https://www.rfc-editor.org/info/rfc6813'>
<front>
<title>The Network Endpoint Assessment (NEA) Asokan Attack Analysis</title>
<author fullname='J. Salowey' initials='J.' surname='Salowey'><organization/></a
uthor>
<author fullname='S. Hanna' initials='S.' surname='Hanna'><organization/></autho
r>
<date month='December' year='2012'/>
<abstract><t>The Network Endpoint Assessment (NEA) protocols are subject to a su
btle forwarding attack that has become known as the NEA Asokan Attack. This docu
ment describes the attack and countermeasures that may be mounted. This documen
t is not an Internet Standards Track specification; it is published for informat
ional purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6813'/>
<seriesInfo name='DOI' value='10.17487/RFC6813'/>
</reference>
<reference anchor='RFC3748' target='https://www.rfc-editor.org/info/rfc3748'>
<front>
<title>Extensible Authentication Protocol (EAP)</title>
<author fullname='B. Aboba' initials='B.' surname='Aboba'><organization/></autho
r>
<author fullname='L. Blunk' initials='L.' surname='Blunk'><organization/></autho
r>
<author fullname='J. Vollbrecht' initials='J.' surname='Vollbrecht'><organizatio
n/></author>
<author fullname='J. Carlson' initials='J.' surname='Carlson'><organization/></a
uthor>
<author fullname='H. Levkowetz' initials='H.' role='editor' surname='Levkowetz'>
<organization/></author>
<date month='June' year='2004'/>
<abstract><t>This document defines the Extensible Authentication Protocol (EAP),
an authentication framework which supports multiple authentication methods. EA
P typically runs directly over data link layers such as Point-to-Point Protocol
(PPP) or IEEE 802, without requiring IP. EAP provides its own support for dupli
cate elimination and retransmission, but is reliant on lower layer ordering guar
antees. Fragmentation is not supported within EAP itself; however, individual E
AP methods may support this. This document obsoletes RFC 2284. A summary of th
e changes between this document and RFC 2284 is available in Appendix A. [STAND
ARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3748'/>
<seriesInfo name='DOI' value='10.17487/RFC3748'/>
</reference>
<reference anchor='RFC6125' target='https://www.rfc-editor.org/info/rfc6125'>
<front>
<title>Representation and Verification of Domain-Based Application Service Ident
ity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in
the Context of Transport Layer Security (TLS)</title>
<author fullname='P. Saint-Andre' initials='P.' surname='Saint-Andre'><organizat
ion/></author>
<author fullname='J. Hodges' initials='J.' surname='Hodges'><organization/></aut
hor>
<date month='March' year='2011'/>
<abstract><t>Many application technologies enable secure communication between t
wo entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) ce
rtificates in the context of Transport Layer Security (TLS). This document speci
fies procedures for representing and verifying the identity of application servi
ces in such interactions. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6125'/>
<seriesInfo name='DOI' value='10.17487/RFC6125'/>
</reference>
<reference anchor='RFC8995' target='https://www.rfc-editor.org/info/rfc8995'>
<front>
<title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
<author fullname='M. Pritikin' initials='M.' surname='Pritikin'><organization/><
/author>
<author fullname='M. Richardson' initials='M.' surname='Richardson'><organizatio
n/></author>
<author fullname='T. Eckert' initials='T.' surname='Eckert'><organization/></aut
hor>
<author fullname='M. Behringer' initials='M.' surname='Behringer'><organization/
></author>
<author fullname='K. Watsen' initials='K.' surname='Watsen'><organization/></aut
hor>
<date month='May' year='2021'/>
<abstract><t>This document specifies automated bootstrapping of an Autonomic Con
trol Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is d
one using manufacturer-installed X.509 certificates, in combination with a manuf
acturer's authorizing service, both online and offline. We call this process th
e Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping
a new device can occur when using a routable address and a cloud service, only
link-local connectivity, or limited/disconnected networks. Support for deploymen
t models with less stringent security requirements is included. Bootstrapping is
complete when the cryptographic identity of the new key infrastructure is succe
ssfully deployed to the device. The established secure connection can be used t
o deploy a locally issued certificate to the device as well.</t></abstract>
</front>
<seriesInfo name='RFC' value='8995'/>
<seriesInfo name='DOI' value='10.17487/RFC8995'/>
</reference>
<reference anchor='RFC7950' target='https://www.rfc-editor.org/info/rfc7950'>
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author fullname='M. Bjorklund' initials='M.' role='editor' surname='Bjorklund'>
<organization/></author>
<date month='August' year='2016'/>
<abstract><t>YANG is a data modeling language used to model configuration data,
state data, Remote Procedure Calls, and notifications for network management pro
tocols. This document describes the syntax and semantics of version 1.1 of the
YANG language. YANG version 1.1 is a maintenance release of the YANG language,
addressing ambiguities and defects in the original specification. There are a s
mall number of backward incompatibilities from YANG version 1. This document al
so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).<
/t></abstract>
</front>
<seriesInfo name='RFC' value='7950'/>
<seriesInfo name='DOI' value='10.17487/RFC7950'/>
</reference>
<reference anchor='RFC8572' target='https://www.rfc-editor.org/info/rfc8572'>
<front>
<title>Secure Zero Touch Provisioning (SZTP)</title>
<author fullname='K. Watsen' initials='K.' surname='Watsen'><organization/></aut
hor>
<author fullname='I. Farrer' initials='I.' surname='Farrer'><organization/></aut
hor>
<author fullname='M. Abrahamsson' initials='M.' surname='Abrahamsson'><organizat
ion/></author>
<date month='April' year='2019'/>
<abstract><t>This document presents a technique to securely provision a networki
ng device when it is booting in a factory-default state. Variations in the solu
tion enable it to be used on both public and private networks. The provisioning
steps are able to update the boot image, commit an initial configuration, and e
xecute arbitrary scripts to address auxiliary needs. The updated device is subs
equently able to establish secure connections with other systems. For instance,
a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connection
s with deployment-specific network management systems.</t></abstract>
</front>
<seriesInfo name='RFC' value='8572'/>
<seriesInfo name='DOI' value='10.17487/RFC8572'/>
</reference>
<reference anchor='I-D.birkholz-rats-reference-interaction-model'>
<front>
<title>Reference Interaction Models for Remote Attestation Procedures</tit
le>
<author fullname='Henk Birkholz'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Michael Eckel'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Christopher Newton'>
<organization>University of Surrey</organization>
</author>
<author fullname='Liqun Chen'>
<organization>University of Surrey</organization>
</author>
<date day='7' month='July' year='2020'/>
<abstract>
<t> This document describes interaction models for remote attestation
procedures (RATS). 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. Privacy preserving conveyance of Evidence via Direct
Anonymous Attestation is elaborated on for each interaction model,
individually.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-birkholz-rats-reference-intera
ction-model-03'/>
<format target='https://www.ietf.org/archive/id/draft-birkholz-rats-reference
-interaction-model-03.txt' type='TXT'/>
</reference>
<reference anchor='I-D.richardson-rats-usecases'>
<front>
<title>Use cases for Remote Attestation common encodings</title>
<author fullname='Michael Richardson'>
<organization>Sandelman Software Works</organization>
</author>
<author fullname='Carl Wallace'>
<organization>Red Hound Software</organization>
</author>
<author fullname='Wei Pan'>
<organization>Huawei Technologies</organization>
</author>
<date day='2' month='November' year='2020'/>
<abstract>
<t> This document details mechanisms created for performing Remote
Attestation that have been used in a number of industries. The
document initially focuses on existing industry verticals, mapping
terminology used in those specifications to the more abstract
terminology used by the IETF RATS Working Group.
The document aspires to describe possible future use cases that would
be enabled by common formats.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-richardson-rats-usecases-08'/>
<format target='https://www.ietf.org/archive/id/draft-richardson-rats-usecase
s-08.txt' type='TXT'/>
</reference>
<reference anchor='I-D.birkholz-rats-tuda'>
<front>
<title>Time-Based Uni-Directional Attestation</title>
<author fullname='Andreas Fuchs'>
<organization>Fraunhofer Institute for Secure Information Technology</or
ganization>
</author>
<author fullname='Henk Birkholz'>
<organization>Fraunhofer Institute for Secure Information Technology</or
ganization>
</author>
<author fullname='Ira E McDonald'>
<organization>High North Inc</organization>
</author>
<author fullname='Carsten Bormann'>
<organization>Universität Bremen TZI</organization>
</author>
<date day='12' month='January' year='2022'/>
<abstract>
<t> This document defines the method and bindings used to convey Evide
nce
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.
</t> a) Please review the format of Table 2, which has been converted to an RFCXML ta
</abstract> ble. In particular, please review the use of rowspan in the second column. Are t
</front> he contents in the second column supposed to align with bullet points in the fir
<seriesInfo name='Internet-Draft' value='draft-birkholz-rats-tuda-06'/> st column?
<format target='https://www.ietf.org/archive/id/draft-birkholz-rats-tuda-06.t
xt' type='TXT'/>
</reference>
<reference anchor='I-D.birkholz-rats-network-device-subscription'> b) We added citation tags to the contents of Table 2. Please review and let us k
<front> now if any changes are necessary.
<title>Attestation Event Stream Subscription</title>
<author fullname='Henk Birkholz'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Eric Voit'>
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname='Wei Pan'>
<organization>Huawei Technologies</organization>
</author>
<date day='17' month='August' year='2021'/>
<abstract>
<t> This memo defines how to subscribe to YANG Event Streams for Remot
e
Attestation Procedures (RATS). In RATS, Conceptional Messages, are
defined. Analogously, the YANG module defined in this memo augments
the YANG module for TPM-based Challenge-Response based Remote
Attestation (CHARRA) to allow for subscription to remote attestation
Evidence. Additionally, this memo provides the methods and means to
define additional Event Streams for other Conceptual Message as
illustrated in the RATS Architecture, e.g. Attestation Results,
Endorsements, or Event Logs.
</t> c) FYI, there is an issue with xml2rfc that is cutting off text in Table 2 in th
</abstract> e txt output. We have asked the Tools Team to fix this issue <https://github.com
</front> /ietf-tools/xml2rfc/issues/1155>
<seriesInfo name='Internet-Draft' value='draft-birkholz-rats-network-device-s -->
ubscription-03'/> <table anchor="Component-Status">
<format target='https://www.ietf.org/archive/id/draft-birkholz-rats-network-d <name>Component Status</name>
evice-subscription-03.txt' type='TXT'/> <thead>
</reference> <tr>
<th>Component</th>
<th>Controlling Specification</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<t>Make a Secure execution environment:</t>
<ul>
<li>Attestation depends on a secure RTM outside the TPM, as well as Ro
ots for Storage and Reporting inside the TPM.</li>
<li>Refer to "TCG Roots of Trust Specification" <xref target="TCG-RT"
format="default"/>.</li>
<li><xref target="SP800-193" format="default"/> also provides guidelin
es on Roots of Trust.</li>
</ul>
</td>
<td>
<t><xref target="TCG-RT" format="default"/></t>
<t><eref target="www.uefi.org" brackets="angle"/></t>
</td>
</tr>
<tr>
<td>Provision the TPM as described in the TCG documents.</td>
<td>
<t><xref target="PLATFORM-DEVID-TPM-2.0" format="default"/></t>
<t><xref target="PLATFORM-CERTS" format="default"/></t>
</td>
</tr>
<tr>
<td rowspan="2" colspan="">
<t>Put a DevID or Platform Certificate in the TPM:</t>
<ul>
<li>Install an IAK at the same time so that Attestation can work out o
f the box.</li>
<li>Equipment suppliers and owners may want to implement LDevID as wel
l as IDevID.</li>
</ul>
</td>
<td>
<t><xref target="PLATFORM-DEVID-TPM-2.0" format="default"/></t>
<t><xref target="PLATFORM-CERTS" format="default"/></t>
</td>
</tr>
<tr>
<td><xref target="IEEE-802-1AR" format="default"/></td>
</tr>
<tr>
<td>
<t>Connect the TPM to the TLS stack:</t>
<ul>
<li>Use the DevID in the TPM to authenticate TAP connections, identify
ing the device</li>
</ul>
</td>
<td>Vendor TLS stack (This action configures TLS to use the DevID as its c
lient certificate)</td>
</tr>
<tr>
<td>
<t>Make CoSWID tags for BIOS/Loader/Kernel objects:</t>
<ul>
<li>Add reference measurements into SWID tags.</li>
<li>Manufacturer should sign the SWID tags.</li>
<li>The TCG RIM-IM <xref target="RIM" format="default"/> identifies fu
rther procedures to create signed RIM documents that provide the necessary refer
ence information.</li>
</ul>
</td>
<td>
<t><xref target="RFC9393" format="default"/></t>
<t><xref target="SWID" format="default"/></t>
<t><xref target="NIST-IR-8060" format="default"/></t>
</td>
</tr>
<tr>
<td rowspan="2">
<t>Package the SWID tags with a vendor software release:</t>
<ul>
<li>A tag-generator plugin such as <xref target="SWID-GEN" format="def
ault"/> can be used.</li>
</ul>
</td>
<td>Retrieve tags with <xref target="RFC9393" format="default"/>.</td>
</tr>
<tr>
<td><xref target="PC-CLIENT-RIM" format="default"/></td>
</tr>
<tr>
<td>Use PC Client measurement definitions to define the use of PCRs (altho
ugh Windows OS is rare on Networking Equipment, UEFI BIOS is not).</td>
<td><xref target="PC-CLIENT-BIOS-TPM-2.0" format="default"/></td>
</tr>
<tr>
<td>
<t>Use TAP to retrieve measurements:</t>
<ul>
<li><t>Map to YANG.</t></li>
</ul>
<t>Use Canonical Log Format.</t>
</td>
<td>
<t><xref target="RFC9684" format="default"/></t>
<t><xref target="CEL" format="default"/></t>
</td>
</tr>
<tr>
<!-- [rfced] Appendix A.4. Table 2. Please provide a reference for the following
and let us know if it should be an informative or normative reference:
<reference anchor='I-D.ietf-rats-eat'> Original:
<front> Posture Collection Server (as described in IETF SACMs ECP)
<title>The Entity Attestation Token (EAT)</title> should request the attestation and analyze the result.
<author fullname='Laurence Lundblade'> -->
<organization>Security Theory LLC</organization> <td>
</author> <t>A Posture Collection Server (as described in IETF SACMs ECP) should r
<author fullname='Giridhar Mandyam'> equest the attestation and analyze the result. The Management application might
<organization>Qualcomm Technologies Inc.</organization> be broken down to several more components:</t>
</author> <ul>
<author fullname='Jeremy O&#39;Donoghue'> <li>A Posture Manager Server that collects reports and stores them in
<organization>Qualcomm Technologies Inc.</organization> a database.</li>
</author> <li>One or more Analyzers that can look at the results and figure out
<date day='24' month='February' year='2022'/> what it means.</li>
<abstract> </ul>
<t> An Entity Attestation Token (EAT) provides an attested claims set </td>
that describes state and characteristics of an entity, a device like <td>
a phone, IoT device, network equipment or such. This claims set is </td>
used by a relying party, server or service to determine how much it </tr>
wishes to trust the entity. </tbody>
</table>
</section>
</section>
An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with <section anchor="acknowledgements" numbered="false" toc="default">
attestation-oriented claims. To a large degree, all this document <name>Acknowledgements</name>
does is extend CWT and JWT. <t>The authors wish to thank numerous reviewers for generous assistance, i
ncluding <contact fullname="William Bellingrath"/>, <contact fullname="Mark Baus
hke"/>, <contact fullname="Ned Smith"/>,
<contact fullname="Henk Birkholz"/>, <contact fullname="Tom Laffey"/>, <contact
fullname="Dave Thaler"/>, <contact fullname="Wei Pan"/>, <contact fullname="Mich
ael Eckel"/>, <contact fullname="Thomas Hardjono"/>, <contact fullname="Bill Sul
zen"/>, <contact fullname="Willard (Monty) Wiseman"/>,
<contact fullname="Kathleen Moriarty"/>, <contact fullname="Nancy Cam-Winget"/>,
and <contact fullname="Shwetha Bhandari"/>.</t>
</section>
</back>
<!-- [rfced] Terminology
</t> a) During AUTH48 for RFC 9393, the authors decided that the phrase "Reference In
</abstract> tegrity Manifests (RIMs)" should be used and not "reference integrity measuremen
</front> ts (RIM)" or "reference measurements (RIMs)". We note one instance of "Reference
<seriesInfo name='Internet-Draft' value='draft-ietf-rats-eat-12'/> Integrity Measurements" and five instances of "reference measurements". Please
<format target='https://www.ietf.org/archive/id/draft-ietf-rats-eat-12.txt' t let us know if we should update these.
ype='TXT'/>
</reference>
<reference anchor="TPM1.2" target="https://trustedcomputinggroup.org/resource/tp b) We have added expansions for the following abbreviations per Section 3.6 of R
m-main-specification/"> FC 7322 ("RFC Style Guide"). Please review each expansion in the document carefu
<front> lly to ensure correctness.
<title>TPM Main Specification Level 2 Version 1.2, Revision 116</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2011" month="March"/>
</front>
</reference>
<reference anchor="TPM2.0" target="https://trustedcomputinggroup.org/resource/tp
m-library-specification/">
<front>
<title>Trusted Platform Module Library Specification, Family "2.0", Level 00
, Revision 01.59</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2019" month="November"/>
</front>
</reference>
<reference anchor="Platform-Certificates" target="https://trustedcomputinggroup.
org/resource/tcg-platform-attribute-credential-profile/">
<front>
<title>TCG Platform Attribute Credential Profile, Specification Version 1.0,
Revision 16</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2018" month="January"/>
</front>
</reference>
<reference anchor="Provisioning-TPM-2.0" target="https://trustedcomputinggroup.o
rg/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf">
<front>
<title>TCG TPM v2.0 Provisioning Guidance, Version 1.0, Revision 1.0</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2015" month="March"/>
</front>
</reference>
<reference anchor="IEEE-802.1X" target="https://standards.ieee.org/standard/802_
1X-2020.html">
<front>
<title>802.1X-2020 - IEEE Standard for Local and Metropolitan Area Networks-
-Port-Based Network Access Control</title>
<author >
<organization>IEEE Computer Society</organization>
</author>
<date year="2020" month="February"/>
</front>
</reference>
<reference anchor="IEEE-802.1AE" target="https://1.ieee802.org/security/802-1ae/
">
<front>
<title>802.1AE MAC Security (MACsec)</title>
<author initials="M." surname="Seaman">
<organization>IEEE Computer Society</organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="LLDP" target="https://standards.ieee.org/standard/802_1AB-201
6.html">
<front>
<title>802.1AB-2016 - IEEE Standard for Local and metropolitan area networks
- Station and Media Access Control Connectivity Discovery</title>
<author >
<organization>IEEE Computer Society</organization>
</author>
<date year="2016" month="March"/>
</front>
</reference>
<reference anchor="TCGRoT" target="https://trustedcomputinggroup.org/wp-content/
uploads/TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf">
<front>
<title>DRAFT: TCG Roots of Trust Specification</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2018" month="October"/>
</front>
</reference>
<reference anchor="SP800-193" target="https://nvlpubs.nist.gov/nistpubs/SpecialP
ublications/NIST.SP.800-193.pdf">
<front>
<title>NIST Special Publication 800-193: Platform Firmware Resiliency Guidel
ines</title>
<author >
<organization>National Institute for Standards and Technology</organizatio
n>
</author>
<date year="2018" month="April"/>
</front>
</reference>
<reference anchor="SP800-155" target="https://csrc.nist.gov/csrc/media/publicati
ons/sp/800-155/draft/documents/draft-sp800-155_dec2011.pdf">
<front>
<title>BIOS Integrity Measurement Guidelines (Draft)</title>
<author >
<organization>National Institute of Standards and Technology</organization
>
</author>
<date year="2011" month="December"/>
</front>
</reference>
<reference anchor="NetEq" target="https://trustedcomputinggroup.org/resource/tcg
-guidance-securing-network-equipment/">
<front>
<title>TCG Guidance for Securing Network Equipment, Version 1.0, Revision 29
</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2018" month="January"/>
</front>
</reference>
<reference anchor="NIST-IR-8060" target="https://nvlpubs.nist.gov/nistpubs/ir/20
16/NIST.IR.8060.pdf">
<front>
<title>Guidelines for the Creation of Interoperable Software Identification
(SWID) Tags</title>
<author >
<organization>National Institute for Standards and Technology</organizatio
n>
</author>
<date year="2016" month="April"/>
</front>
</reference>
<reference anchor="AK-Enrollment" target="https://trustedcomputinggroup.org/reso
urce/tcg-infrastructure-working-group-a-cmc-profile-for-aik-certificate-enrollme
nt/">
<front>
<title>TCG Infrastructure Working Group - A CMC Profile for AIK Certificate
Enrollment Version 1.0, Revision 7</title>
<author >
<organization>Trusted Computing Group</organization>
</author>
<date year="2011" month="March"/>
</front>
</reference>
<reference anchor="SWID-Gen" target="https://github.com/Labs64/swid-maven-plugin
">
<front>
<title>SoftWare IDentification (SWID) Tags Generator (Maven Plugin)</title>
<author >
<organization>Labs64, Munich, Germany</organization>
</author>
<date year="n.d."/>
</front>
</reference>
</references> CHARRA - Challenge-Response-based Remote Attestation
CoSWID - Concise SWID
EAP - Extensible Authentication Protocol
IoT - Internet of Things
LLDP - Link Layer Discovery Protocol
NETCONF - Network Configuration Protocol
PCI - Peripheral Component Interconnect
SWID - Software Identification
SZTP - Secure Zero Touch Provisioning
TAP IM - Trusted Attestation Protocol Information Model
UEFI - Unified Extensible Firmware Interface
</back> c) FYI, we have used abbreviations after the abbreviated forms were introduced f or the following terms per the online portion of the Style Guide <https://www.rf c-editor.org/styleguide/part2/#exp_abbrev>:
<!-- ##markdown-source: Attestation Key / AK
H4sIAAy3OWIAA82963bbVpYu+h9PgaH8kJgQ1CW247i66jQty4k6lq2WlKT2 Device Identity / DevID
rq6RAZGghDIJsABQMhOnR73D/rXH2Ofl6knOvK41FwBK8qXOOR7dFYkiFtZl Initial DevID / Initial Device Identity / IDevID
rnmf30ySJKqbtJj+ks7LInsWN9Uqi/JlRT/VzcHe3rd7B9G0nBTpAv48rdJZ Initial Attestation Key / IAK
k+RZM0uqtKmTZrlILtM6myZF1tyW1dtkmt3kkyxJmyarm2T/UTRJm2dxXszK Local Attestation Key / LAK
aJk/i+K4KSfP4u11Vm/zL9Ns2VzDJ4/w93q9qLJZ7b9Ql1UTfjIpF8t00piv Local Device ID / Local DevID / LDevID
rC79Z0W5HTV5M4e5Xpye8Nzi1zy3+AXNLT7LFmWTxcdFk11VebOOf8qqfJbD Platform Configuration Register / PCR
RPOyiNLLyyq7edZ56PinKK2y9Fl8nk1W+Fh0e/UsPhtfnMc/w/fy4ir+ripX Reference Integrity Manifests / RIMs
y+jt7TMau4ItSV7ghkXpqrkuq2dRElclTi2b5k1ZwdzzAlb23Sg+HMUvsykM Remote Integrity Verification / RIV
U97Cp7zX363W9sOygtf9x6rIl1mlk6uH8KbJCDcBdimDDdjfiy+yyXVRzsur Root of Trust for Measurement / RTM
dXya4gKq/CbDjYM5P4t/hmOZldWUdnIKr9ne23/69AluZJVdwQY8i0/Suk4n Trusted Platform Modules / TPMs
16s6a5qavrcqmgqe/fEcflteE6Fs4xPZIs3nz+KrmUzz3//G8xvB0mGxtLqj
UfxTmTduWUdVPtFPaE2HeT0p4/N13WQLfJ0eAH3uX5LdwDP/PsEPR3DeOvx/
wM7lza9XWZXOp8nJ5Id07V71H1ldw7H2fYHe/JpOPJ27I43HV1kxWZv93P72
6d5efJ7epFdAA2U63XY7uf2yGcUnWTrNtv1mHux98/ix3cztk7Raz+GGbXd2
Uhb2t8UM5nfw70Wdjq7KmwjI/Vn82+9RUVYLmOBNhrfm7OXhwf7+t/Lj00eP
nsiPjw4efy0/Pjl4tK9f2P/mkfz4+ODpHv54nLwY+Yu7Tosrur2T67SqgKrp
U/7FfhkIAb5T1rf5tDtIWk2u8yabNKsqkxHwI/ze0dFR8nTvINkfn+FzcNP5
UsJnI/gsOQCqixP6XnyODCitpjHQZfyqnMCBwAewtU1VLst5Dn+Ox3D1HNXH
CQ0Z87llekWPp1kBr1kPedhDYAoruIbxeTmBOa/pGb2J+LNQ0MkIxkkXaSGD
EmlsHmGaNrAOnH+y9xQ+uRifygrT6gpJ5rpplvWz3V1ioNl0QoMAe7hC7jCC
0XerrC5X1STbbSZwCOkyQfZIh10WyQIIab5r92z74vC7+IJHi8fEWOmr8WlV
AgMt5/EOTGIArMCNEp/gKLShwAZlYS/TRT7PszreHx3QDh+M9ui/L44Pj/iv
a/jb3hAZYo2j0C9nsLv0297oa+IT7V2kDdP5HepyhRu2tmx/Dz45TIuygIs5
T45u4MiSV+VVQCTb7gsxfQGI4ip+SWuzU/MzGz3aHwKvvKxWcNnig8dDeNnB
wfbHHsvEzS+j+QEvTXhrd+NPWf/BXrJ/AJ+cHiaHcBAw8vPjN+cJCio4io+m
ouUkmfBw9TKboCRLlvMUufwimeXV4hbkVrKsylk+z9xXiEwCMjs9jHlW8bl8
Jz6VYYCD8jBIcjiM+wpTm9DOFqxiayjU9gr2bh7vmVOCI3vsfzv4egiSZh1/
Q4e1/0n7up/sPQ729ejlMW0rUPonXc5slvu93Lx1eEHhlX6/wu2Ra+iv2D6s
DW/hMPyi7Jwn8YMDc/32H3/S3XuU7OEmnx2fPOswl7NsllUg+axSdJIW+QxY
TbwDj/Qwl2F802YP+0+G8evyJt4/oDPd++gLiFtf6ZyAO8qckoXMKanyxSam
+bH7822y9ySgIb9TH7cAfy3vXMpmqqKj8bfyzkMK6IiP5hEfxiN7Fh+/Ocy4
9CqAxD1+0WJcOmkgdBQsP2Trmii/JZ1J4hgp1roDG2TPxzNzVHIOkr3kLcwH
ubhaKLnMJ4H5iLlijuDjOfzet3ajZJc+iQ/BAtzkHTNy08dP8Sv7sMqDkCvB
SbhTcKzJnYNypS4fCs5AmJI7ia8/iZAes9J0/vPxi/4Nub29HeV1SVtQi2K4
++TxkydPRtfNYh6QmuVJxuo5L2cNCatxDSYM3hFQ3hd4hcAeauKDZ/4bvBkt
/nuRXoEKef5m9/joMN7/9ptv9pKDzdfnOhNrT42JN9UV3MpfPetX/VY+2w2/
fjQHBRoUOZw/6hwyiRj3cZHXtc7LbCEpUccn4+DiGaaQpTWoxbTisVHRe/eb
iQymeZWh1ba73J3nxepdki/S3dv8bb77fbnI+u4EvEJ8AnU6E4sS/9GubOuH
2+1vv53Wv2TNKviyfNb57uLXEgyS4Kv8UeebVZYXQLNgT2Xh9+0fOk/VGaz6
l+t0Pl8Hyv+2/cN2j5hwoscZZ0+e7qsZ9vU3j57qp/sHj9Ui+/Zb/fGbbx/v
6aePvzlQu+oyr95el/Nf2bYKZUaVTryc0wfAkIa9mNbwOT0CBvskrbO6f8Bm
NU37/9Jy3dSry3pS5Ut8Ydfmy9IGP0TD5/TkU9kaGMDFnQIQ2NMJfKfFnli1
PLCKktWT9j/RSgFt8mte36do5bi+eX5ZgUVy5xJlRo4/g3K1AgX7FT/aFuyB
pu10bKuF7Y8ef/vJwn7fyrDDrBIeybT18RqRjgjitsovwbROJlVGLBhsLbFQ
elQg3ZqxPhYfusfUItkgwuRah8rEpxLIU1al4c08IHztY42422UyKeGCF83u
ajkv02m9C0um0W5guCR4x3erfJoiSzhdXc7z+jqbJjf71f5oOZ21rRG8OThA
MMlYB9hk4cNvnyrdv46M+2e0/+eu9+fPCepJH+38SZLTsgLLOfDsjieTrK5h
cgU8Nu8XdPKiGphZloX6BczrF5mX1zLsJjzYK4QK4EGwA+OjHgfYUXwyPvRu
xx34DZj3oHfi+zRhfI7mLM/sknct7RXNn+bWwgN89erFac+0n6Pf7sk9R7ew
R4cu87hwfjt8hq4nn/E0T1tHh/8tQF3Jb3BfXqC39yar1h93ojLfTzzS/SdC
1XCvzsqLz3PDfzkry6b+pZz9Qhfrl4B5/XKztzzY++X0x+evjg9/OTv66fjo
5/Yl335xNn55wZedxorLGV/SkBF+Fofd+enTvb1k/9uv+xdf3MyXoDSMirxu
0IW9iz/gJ7s0lXRO/IrnU+++Pj6/GJ2fjmTIzsLw77E8GJsnY51Dj1vqLKvR
tVlM1sTjMtBhOTjUu3Tn9z8uangrChSrp9dEnd6g6DD/R35LHj/u35JJXU38
fuBvuwsk992l3Yp6uSuj7FJkbXdaTlaot9f8OygO8vdfptkEVZP2bqEDcYPq
7zci3qEw1OAD9gOI6WHbsc+eAWDER3//JOXgSoUbczgQd6qXZn9f5UtcUsfn
pvKMj0+ec0LhSJ/bJO4Ovv0cagDSa3J8Btz+yQbxv/l+5NUuMhi+E8dnIxyj
fcTmHHGZzTWpP3wl4JjImiyXYCJcol+237KNd9DiHqBpW/9LbsUTvhXjH5Kj
Atj4HLf9k8gBTKwqreHLZLomtxxiTejbSZpMFhPn0kYPSJq/TSZeT00yN4sO
0RwHI4fBW9iLcXx4cuj83LgD4+MfYqMDx36FIkj6qeubTzdCxFOSfJcV/Zt5
lTfXq0uMh+6+Si/rJ492MVIHdtVNVoC6vbrKC7t8pI6fiTpebKKOGN4FtNTA
undOcBjgtjjMRubB7x3GJ6sC7NEhPA+WcbGOkiSJ4U8Nmq5RdHGd17Fyt3ia
oYV5CRSdxniys3l5S1tdcWjeuOOQxJHknecUP9CoBpFkLSQPVjk8M5/DzsJj
wjxiNmprGCNtYhTEaE5uMLrq+Lff2Kr9/fch/wwqNP6cwuSzGdzBaXy5jiOc
0IZTjHeAxgaDIXr4kXHdpHNcMRrqNON8sZwTf2YRwPPKi8l8Nc1ooUvyBeHI
k3SZXoJYa/KspiksUZef8hxgbvUool1e5NPpPIuiL5AXVLAS8hXgnme4RfD/
eCAwAMhU0BOaEvehhoEqeDHsZTaf4vTTWK5m7O6m7N4wmlXlIiYmQx/XHKzH
odLl0smzUQwCaHKdAnvjP+KEM1pilMpYsT8lWHgaT+CV5SKrtuu4zuHogUyQ
yJA8J/FOPspGw7goGw6dZ9Usy5sBHft1WkeXGdAnLGaWX8FVnsa3cB2ERvNf
M08asHvzOe0gOgCBgPxa6xUsYB3DrHMwr3Gz/oY6VBrPslulvWD7bq+BzIG8
4FlY4WXmNpM2rgAZVMHkYUj46zVcIJ7flBz3dNh+J2qcBX4T5wLU2lyv4UjH
8RVeQVi+ja9vuh6wDTFtg9InHOlvv22O0//+O5zSeDrNmdnP18N4VcMk0XFk
3gGz4rfgcctd8gRR00ZNQTtf1bXsO3ppMqK8+AluHE9ik4+KpvF9eZuBdj/E
TYY5OOUHfqIzF3qHM5oBq6IgyJWV+HrHnYIQA7+alhWLKiZX/A1OAjhOfgUH
fLnK59Mh/X2agTq+Jsbi5aesb0S3h/5WNEwGln/ljrp5ekAQOrFRfAz8rSSO
A1+Dm1quGpDeuHlIS3cmH2Gs7acBDgxzWfA08S7EuUhzGDZj9iGcA88B7CWw
oNBZBJMC8UDvwTs8zxog/RoMM1qbJRt4xSSbIl3pydLdgafgLpLmbQ59yUyl
5pUCwQGjg00DpgTSpplcZ7zhwJWzWyAp5APxuIhXBdyK+Zp4S12vFuRRhPfA
VbxkXpfepPmcedxaiQg/lwtCF3WTg6yfVXN6WJPjeifVetmUtNK6Rs2pjLOC
dgLfYS6du1dAzHW9cEeuE0HepHoVsx5m5kAlX3xxhtRXyZkA1aaO+cZvszVu
L6hOWyc/nl9sDfm/8es39PPZ0X/+eHx29AJ/Pv9+/OqV+4G/EcEvb358JX/H
n/yTh29OTo5ev+CH4dO49dHJ+H9sEf1EW29OL47fvB6/2oppdy0d44KYidEt
WFYZ7jQJOxbQyE6i54en8f4j2GRJQoJdpp8xyQh+vgUCZVItC2Ab/Cts3hpl
Q5aSkAGqiECc5cD5WZTV1+UtMK9MNhH0ymqRi2IJHLBYLS5BPOEpwB+Y3VTZ
CnkNiaJ7OdwFcRSRq8/i8XJZpXmNBmUJ4oqDX0c3zJaHQVINmJKreaOfIXfy
3/Mh2J/S+Yo+YPrGwNJ6KHcZn8Ht0N/iN7fAz5GzB2y3aalEM1LxkepmoF6W
t8QxYPXP4EE/v2eqJJDXBDboivU1+PYQRc1NxhcO3p/youHXaDJP8wXs/GU6
ecv6Q+YWlV7CbdYr528FzqZGuYgKHKwERMEERuAtJSXASE5+bhjlLgVLxiMN
oGCfo7tDKrHFp81fjfDmlnXOnxH7yonTA4Hi6uF9cMIwg9mqmIilQqsE1lLR
FzPQtVasiQzjrJnAjtM1vCrhq8hLzCnnqG4sliymaQi82nE6BSrMUWlFBRj+
L11RqiYzW8OagiWEaih99RZofJ7CTK9RPCILNw/zH3FJoM/jjQuUHhwMdJ10
sUSdIkG2OKJ1TLOGbonTiz1T0oeRj+a1CE9zh0NiQzEIQqwBvtaslxh0xH1I
3+Isy3iRpQWoa27wfIG5j0JmTDy4U6xlNWunScHnxNPtFg6dyDDLB3VqNUvp
ruKt+Nnz/Tt1atLes3cNMReQaiCze07VL6hIqwoUjKmIf9qL4PJcriNW5mA5
OciqJSgPeBXdvZ3AH8pLshhYllxV6RKewBHwzaQFkHEiZB8FYgP3/e8r1KFK
YZB66XqNGrfh6CQkI4ZJSYmG9ABPM6ul0Q9ucMprptJb+J9t2nDS/Fk+49si
UmemrKd66gVu+bJPmYLh7VYsVU7DroDiHWfAoadTpi7nnbfBdnX17rw+OR/g
YHC7SZOdAHsTTbHOKlQAI7xsOGE3CxhmvkaOA1uMCY5KRoYuU4ruL/wL63K+
or3G4UDDv0YvCd2aibulC+AvVzwvHJj5xGAU/3yN1r7EdZF6KP4K9y8i/mCp
rM25Z/ADKs/4hlgjfZiVjtNrEWiT1pi0rbo6G2i1KIXRXUrhCFO3fuqKcLy2
uC0dZ1kygf9BKwLYCJkumAVurU3aTJ7iUhJJWY9zuiEbBMp2SEm8zuiY0ggt
qXyymqdVyNWU5aklxjzNG2JEvjgUyXHyXEfquYY18jk0oeV6m67Z1pywWKiv
w/PAjYGVwECrJjiDvtXhsYvyTJQGO5oVN3lVFqzCoQqMikw0A4uTqLtzM+Qs
SMtn2/QmUwJW+RDKzUjcD6v5FLUtnj1s0042ugID9ypzrGVeaqh3YiIhf4ij
Osvutanwms2BL6+urpFV0ATVSrG8Bw+eMqdDLxvSOhAHXJuaOeWc4svIrCiw
AHtx1yLdsiK0euiLKEtqXSV8esSpR1bfuihB7tQdjQ6uLqwHxMNxEaPzkynq
br2P71UuGkB4T+iKkt4PxAzzQDMxI5uAbrpy8ggLNJg60GCsHWtnXcPM23gb
65g0UxGAXnG8JWJuKY2szOLg8AjuVNr+BsdswXZCPVbF2VA9EU508kGGfi4g
aSWxySRbijYfXcJp0PNu3biaTa81RESW5HUp3grQi0EZIOcACGXZsY6Wi+r8
C912mwzF2liFZQ9oGfaa1SV/n8QKvKBG/wBobzWz8Bp04S/j/lHkK3wZa1L6
+MJXxkAbxsv5Chkf2IUJUzerBkvVqeBij/Ql5yJQ4jcw5E2e3bqXsE0PZwlm
zD0mPUU+/ZDOm446TlkQy9FRYci3xID0Dzwf3GlXDBL7qCeOeVrlN+mEqdOF
k9G44qk5VjiD+0QcXYZEXUpyKeQc25q/qChd04jeew7Kf8mMHCmiQo8BHALq
AgXZfcU0fxeLzgy/CF18h6cSRaoteBfNJaiXM2BZJBXSwDi3l26h7kW+osLb
6sgbAaqo516XwA0FFpVZJdtqOexMVLXL6fGzKiNm+bZAU/VmNUcFWP2xoqUb
XyMr7LAhcGsDnoU7UBIZz70pgvPFzXMa4DBkLrCLcImJrbCBkjP/bSs9w2Bi
TAfedoq8R0MoP7Rb/Dji8ELSsPNwznkh+K4twacueiVZD+KA8kbsdX51LZeN
buUzJtzyhnwx7fTgJKZYQZAypXdYnV6FY7LqIibLwzksmRkOnKYTxehpDlR4
51Gr4BhzUNPJPZSClskPwykezWasNqF1hHNiadYyBUHV5hKbBYpIOLRaPIMY
BII9mfJBh9wbP5msJ/OML5ML2hVYb1JWa4pDofuICIbdjTJjFjJOC66yOYrr
nXrgPeswmbJoySJWfbragFuNG7GGCXifLtyMYhsDXeRkBsGQ6R9J2RL6Z0MC
18K8T8kxCXlhYLMWLTsk9LkxE4P3difoPgmtdXMXUW1FrzaqpLjfpNGrbso6
RSq+GNYe81o8xEzEzJdgl3LSYsjCIXU6ndP4RmH0Fi6rvPo9ayDjfPmq1cGy
WXF3rq5WyIpCSNvLLKuSpkzwv9uoUmTk8Q2DW8Z6hYWKMQjUB29jPQxpG4jj
knVnUeeAdNhbcp0vgdx3zknDtC8Eleoyg1s8iKLfnsVfwE4lKC5/JxHfkpv3
+7UDP5a50rclux9B9SV388LHkC5hoVkW0nJb5REj2CkixF46JYF0/5z04GtA
91JcDt5zhbwXVWDyCcm78HrTAVbm/jvh6mOMcGPLimNBLMk8TVrVjQwrZEpN
AxyH7biyJbWY0sta6P02q0zsTE1/nsmaxHleEBOjq0reH+LORTjsKB77KFi4
Jz21Gpj83+f5UPeF8mwfJ/PaKfq05rXjONOQ09lElbxuzYTWVWWoYPCfkGZI
Fi9WDQkN40pUZckzPQla8lVLC+fes9yiNptHUTqS8kOvIURx11/JzKFaFd1t
jaIfa2HzeGKbSdrxm9TPXRgMOVLZXlX7m81GswZHHqo6eXL0UbAcPUeBBsTq
BFx44MzAIZzws4TUtdZhMlGq+o/kOJC4N3H2lsg0c6BJ6QycJA7i8Yv0bUam
hP1mU2fz2fDBsaYockSl6tJlWZowqyzer5k8mLzd6HpYeFLE2ATICJJ/esnR
X8FPoLPCZ9nhdbFUvMMGOtyPJilnCfEVsshph/glqggU2Tty5F1lYqFMgGvo
HyvSsmkDSaVM4IMctf6GRDM8NOTacBRqqGezX4b3myPzxnkLrGZF0o+021E0
tuslM5TDivY+D41jEuenZw9rx8VE3dtH5e611w2sisYK0sbUiroU8ovIZQaa
GMVxjfDgjcJjVFcUTHUW6AQm98P60odAXCjLMKuGKV2Veq+tRxH71cQnphbn
Iv0bHLC4ilEY16BTN/0CyQZ7QPrsjzSJRjZNA0jK6dQBTcKc3eluLPWz1yHj
jZjx7uhQAxyXozphAGdJsWw0UUZohng3HYnASD3T1quRN/WG2AwJIXIe4NuA
HqgmO18gZ6ZgdxQdjEKhYVT2WVY5D7ln7s70wekE8bN4xzsYhobVBYx70Cd8
NjEVzwKHkRWY8HkojnGdxOdgRV+PMAn5Jlun4i3TPY88A4W5FLWXT+LRBupz
R03i350q2nDeU4K/oXEEn1n3tfqIS3TZoiM6wi+AzQE7BJdY43l4AkV83mTL
+NGInApuNlEYAZmkVYX8DsnjJk/D1znJJT5XdGSKTjaVRBBabBb6WlN0lxJp
YhwBzrTI8LKsjbkaOSvDWrcmREWarabFYBEHHSPuWiuYo0kMMMnjBi0CcW7B
XDM5TUeV9tEsOAWKLAEHopjfVaECAM0rlm0Ut4Zthy8xl+AQWhT7mFBJy14v
xTr3+xokFbktcycC9PQIEUok5uvj0JYtlJPJqqopao3iNWQS8EVW6FU+uMdA
bGRgneJyyMB19OVWHZp/q5ojw91oOEXIwM4tlzHVC/TFw1W4cowEvj8hCzeB
6+acHkuqU0Pdy9jLlJGBN56MuczKBSt6ReFjj6Vbo/Og9MZds3dLunao864D
IwDmc+7EiXpP78wCiBf51XVDij6oGeYiUxggvUpRxHSduTvp2zT+rpzDl606
UA+GkikGyxJdXNbficKh00kVXOYm5PhH3wHrVWA4zeedzMHau+BotykK0uc1
YUnJ39Z3mBSDaxSJjeb15ljjhSJMbYBnyt8dwwXuIzoswyvBm6iKQrBdOh6d
HaoWH6Dz3sDCgOzHNNJJuVrOVWuAi5Uhp+PUgoQ1YsOz5JCDADLleuBIx+j5
h7Olt8U7x/JW46fX/E+KfOGObxqUWYuzmMmB1GvxqAlaY7hlns3E9QXDlNUa
abBcZEGKJK0TRwNeDGpmwhzuHcVGEzOFMLtCAijsph9T1BWuZQZCpwJCi6iW
hXdwms+IQNE3yp5hzEnMKgyIIJe+TdnWRO8IOXMK9iobmxsvhVbqRZLzS5xb
THn8e/YuxXkP46A+zxYKwmn3FhCiygcD4MCdNYsS5/QmrilScoIzfcVnOmC9
w9YF2sQ2cgkH8a6On8mpO5pNR/MJbGZv1BBXphe1orlqWejFJEbE54Dyxu9L
8PozUZWBd5weniGj+M8VZZ8Bm0GgG2srMgtRcRpohCThzdlkPr2AqLUUhkr5
AH7B6BLTFILAXkZG4GI+ZEGxgxIZKZVokQrS58CBXcA3rorLCmN5QrPiyceR
EtDqQFyJ+cTOJ30besXn6Rq3w54L5teKMeesJp1nqW+UhGRKBaL7jIaL7BlZ
XWI5cHUXi9XrtGZtNoiyhEbZkJMqVstpqo/ZhQOXpMNSpgBnzVyITh2Jgh6X
7deXcuwFl8v6MImKqf4pdbqJo9uJZEnTe5hExMYkQY6gD7//TrcV01Q0QoX2
KczCbQ3dNm970cRNuiQ+TjF25EZoX6X5vB6wFnzOE+oXeb1oJFb+OX84J6Wp
R6y57kREXeAx3uFoEVsmJoAZuH+dY5UZ36wRc6wdG7VOBQ0ItGKWnHvownw2
lRPMwjs9mrS6dDqtUEfDMbdekYZ2VEyXJYj4rchl8TqaBJMd9N9yZcwtSktB
K54eIhYNZjAcJhGOz9jRpDfW5MSxRuhUGmHjAWiPmfIovMQJDTCVRQ6iGrEe
m1Xtnb1aTYolirWQw2xVkc/YhRMPJcFdkvwHbDG3VHXrPscgCDHFiBRLSrNG
HgQUDfyE9BRW5elstlCNlvO6LN9t4YHP0oo067KuMZV3KIkryBFVIZxlt5gV
qF/xMRfKTQTrqHZWhmO9cJ9T1FnqSPiLD1BiFoUWIYxil89knGq10JozkmBx
W+irSpwitzWMiO+KlVgRE8LlabwEaZTstwYTnwpn71GdBB6WNcwjX3AhqVPC
mKZgtKA/h55AA6aVUJkaDwPLj0y8G/BTEkjZViYYU4UAUzjuEom4p6pAThz5
n1kF9lKJPjpbYS5h3nNMzuOIIhVK0DAuRGv5vLUQ+TKxeSaXL8AJIqcpVgOL
k2SuifKxya5Jl5LUuYAtc1lRXqVu17bUYR1CENls+4R8Fru4Gub5Ihc3IaUj
YqC+QziivN3jxxxIagMaqcqPWO0gXQ3TkMDYEqUuIVUFGD7ac1a7DJQzYI8+
iR+RQqfAsyhSf1xeYKrQTZlPvUtSz8nlFBi1DW1CF8/aIfaj4qkI1K/D8YBH
MZ8heBFQVVAbCLSF8ENGe4RXPEx/HLmN8nnseDCYjCWb7zO+XJEEp3X1pnM5
V/P/GL/+jskfIVpEWL4+ujh88/olf44Qm2y4YAYtukyEFDElpubwOEfcgroo
zf5AD04pPGFDOH2B2R2qdeDJcxHEHQ5UOrPNZQ8k476I3zCTlZv5ZXy2KpIL
VMuC3HKc5CvE/3kAnBDacydj3CUaoWaVSzmPRlvRMzEjJ6kpe1IFdEecLbAL
fIGQdCTNUTZ2wMnKEuBC2VnBzEmhbFUJ8rzZtpDsM/QnJpQHSgm1rfo1792V
KeKWvzmnZBCdoRZ3ET/P3i1hwrW58CK2hA8hEO8JKlN4OzE1TV2LWkhDCjfn
rbBqgEvr1AFwkNGNKgaMLB/ViWQB3JFAEfr2gqjthJb+E5VDxUeaqisgu89M
ARgMTbEHzfdQDxvLRw5TBu5VmNkCpN5NVrvEGl/daBPhWRehM0DZIaVZeHeY
6acmaTwj9xRZ82PNPRO1wBNGK4edQm04Glx+yaqjBNFFOaWh7y+EkzwUKQ86
n2fZkrAN62c98t+7VV3e51aNj2xhDAPDhfQ8ZRPll2RYg05aTmVqnCeqlYKb
1gnDmCvQWvCm7PjA6UPFc6BbIz+Aa9gzKZwqGkvOvHRpqSDwygpUR9k+UmU6
BYf9hXdiM89WrKZc5Vg5zGwpm8+5iFBiwD/lFWZkKEIazu2Q/TKZZpI8I29i
SiLvRr+ObjKiX3bmXaN8h9ua1xFctyVu7aUUbPtgG7GkHzHh8XyZojMPPd0+
rqNWaLliKW4Nynk+y/BqaU4/v1uS5buTqsNZkXngsvLh8/US5XWNJRER33ox
W/xf+CF2d3nVTqPCodmMT8ok4IkJ5uzB1FpbG0mySbC3gasvZh2MUn5hv4wU
6ykHwGlHXVruUCopgd3kSdIMkbJdvDb0i1g1gl3VmFdFtsY4tDXa+m0rW85H
CdsuO581tSpQXY2CnH283IkJExsHUNajkKqRgaWuLjPmdw6ZsSOErhBsY7S8
TjmGSFVvsF8vyVyI9zlXhWlVQ7coebC4AwiC3DD0sISRp5hpDZagMSAv/wb8
DHdlS30KW+1MZC4f4m9u1ybMS84QyaAL8zym+RU8OgjCvwZwVQryMGytFSBA
UKPoe/FmIC9GJTF7J/Yrb4W4SDa4McgFAWNv81OUOkjjbQ+G/I7bdO1TIsyJ
3wDNI9OnN6B7hkofslrOzka8lXKc3haxK5xFLnmiOLAFYlbD+MTG5+5qnKjv
5jkcj6ZkeX9TyDD05bX3MZWFBKN5nTXddTtHu1nD6BLRGTNRqNioR6ecKwfY
JN6GLq9465Usy1LvkSl6GG6pH8kMkc5NPn2kada0FcTH33D6YGb0OrlWLqXW
8lOfjevLGoZhoJ9cZxi9Xc5TunhjWMIyrVhomepKfU9eOD6peVxBah7VGpOx
XZVXSh8+pcs7FKsM6eXGERAbZyi/lt7XT1eiNsHeyzURKIe2mADCazm0Acei
VYANRlbDNcJcjIHfYiZboL2pmZ30cdT2NJKpwmRpa3U7JNHC+ceblk4wN1Ns
jNwc0kgT9Dn/xGS6BRVxRqq5DFjHZC8xZJFR0lPEYSfaCDKesBOBGFW4LZSQ
7mJe3SiNWqaw6O063DvCUMKtc0leUcACwlTRoDDpct0KpwIPA0bW2Jx3IgBc
iUYundcpkvNUWrDx5aFLvuZn9DuiGiFbouBP25+K+agbgtt20WQqOe8QiW3g
HxVsGZomWDqQTf+g8zsK0ntTkwZik3mCoICkv5ObC4ZrmnmGm7rKnPPqAzIB
XeIDQwcoNei0YMn/Df8IRuar5OP+fUVPvzfPfxUM91X7l+Cb7+Xp9z8ibjui
aL2Hz//0Pn6F21DF7+mXH7CJyzzmP6EaiY088KnP8m7/v/Lv/Yafg3+f7+lg
578Kfv7q/qdb/1AWxqeoqmx8+x1P238/ffTT4ZZ/6NPvCfK191uf691n5APc
/P7ejx92S973f/xVdNekWy+5/2txGASh837wo+EqHjizr/haOgn00Km6h/37
6EGMmzetTcIKF1L2wNxLuF4jQdV7NBq57/yJOZamwRtNKuFeKwSx9cdtVbXa
Zgt9aRsYNzukQVpdFX/cwpSBrd+pIAH543Oj7we5Mcikt1SZ3iLbgFTj6TDU
rBkkSpxaZEmAuelCJiLZnVjHJ0gBXS2t0L03WjmKX6WUVVSqCii6bh6ofENb
+xLQjSxRiyBVUrJRwZrYNMzdQvW0nM3gWN5xbXid1+LZ/BmX8wJ9Mn7P/y9Q
ZXA7QruRK7Up7v3g2Dzb6piGX7m/ceCOKi1AEs6lTppVGNIrIq5UTgsOCTqo
DRcKzYuWmXLs0uBl98NveD92aFHhJNUCIf8LJprhp/ENx2ojl/qt26qeGs1n
iD0Unos4U7S5pbyOQ49+K3Uu1E7Fb+18fzhNrvWv3RORg0/CHBlfwQIUpUm2
PpllMqdKNhzUadaSN4xlLvRn/8fa2YdLdgU6DeYa1GGlyMhtJZnBM4dBIC+z
PjpagDU62VxagypaLctaE9465aGNs7tri28UGe+xdf5qmJiyKXttZy5eEuN1
SIWBV4UiFgUsQ6hD/CWc7yalvAtQcdRH0IPJgYajWDiU72dri/hGSdJY51TI
nXEInG6oXgUMNlYMSFcPJDacvQN7R5FE4sPTH0f8mL2ICTvS1fNcIiFgqVRW
YQiglCDchEGD5zwWeQtLDGzO24mCN6CSY2Km9Rjl1DMwtGM0Hq4BV4ckhL3w
gHBqOhwqGGF/NprIKZB5zZyCI8RCKERtssyg9gRvbBmkY4lNRUm6Fi5COXUn
00UVbTMvzFpsKLfZZQ3QV3l3HWA6ojCPw1IYmglWht0zE293SR2bGRRIHv2B
nN8RFErQbqHLkCoIxSCkHLRN5bM7z9fG9TDkFwouoquSCLKJYMe3KdmE/Ql0
aQzZYs4C5ecEDXUe2t3qt9/6G3aBLYt+7toGiTSHBmXMLecsCNVHTogaqegd
fFT4oxMSH6Bm7MbOSIl3sD/KCvYGEVOdeMpcnagHNZLXxRlFzC9z2q0I2xT6
CyjsyKQaO3gOfy0QDqBUGxgvZXi1rFeQKgqZbbRv0jCeZykFrKOijK/SJYe2
C7crNDMOOaDHG8HjGAdzCEM0TGZzlx3jrHd01AHJRNHLsnLsorNvw7sOkVOi
epuHyRHLocIsfR2+hRXgDjsgdVd1epVJjICFSeQO1XrnnNBGitwwpkeSFDjE
7B1cWQ4zcBUc+XvE1J4mb1jOOKpEduiHDoATcapGdNDlFpkCl1ECnFrdGElW
GHu6N+0icJnna1ZwCr61lIBBIkjQelibyLEoJa9c9InCfwhXy4Ww8A3eSC0n
FyomkqVVT0i+UAIescbp9O5H8RqSQw2zf3rKjmV25SR3uoImlEwzp5pp0UsT
RwTH0Ihvhdx++Fpkooovy4q2uIem5a8IcLKDmRk3FPQBEYZxZCplAT6VgxpE
cRwjvjGGgvbGx3pHAsPnXpO7Y6iN9bRwZV/gpzDIS8lBe9AgqAXQf8xWv48+
fTVJgjNRhk0YU5NQ4DjdQ5ezp6va9/ODQXLJFyceHCAKT7FjbgXnE+xJx0L/
bMt5we9jFx/PyvaPYm0HZspTONCZfB0sBxVSuAp54bjg3Uf8r1sOiCnxohFP
79w4c0AwhUc6k8fBctg1O80Cz62eEmmSlAEHmtbG5bzvZny8JYfeSJQ6Yk4c
xbpjELrhXFIKrHaxFMiQtLAYEnhOd83Em2hz3hp0uXJpyf/LpyM5Ia7Hp03a
VdWEVktTeKIzefL5ZyKphOw5JANFk+2R6/C51Kz82T35JtjYLj/vDQoCTd5x
OnImD/n3Lz6d4DSsneYvlZnJU53Jt8FyKOMw/u7sx+cH3JsFM6MGcd+//y+W
g2os50RKqtnJeEBT2N9TRr3nZ/JZJKC67trKknrt9PNYPt/oqPviiy9elw2j
/SGVjucK2FZTGCfQFEibnZRXCGjF2gI88l9/2fsr1TZK4aK4TIC1YaC5HQU2
DzBAp5BDtxY9Mns9ZNZJChbhrllrCmwltsa8sQTfMG/WW2gnE5liKK94ewOM
/CHzeWxquAN1BtQoNlh1QXZwPyOJ4rKSyzE9E1VCblvpq2GCy5XskqJsgtb0
QjIkyD/wXBxJ8tIh/3CgPzz6K7EP+vnpXxmXbbVYpGyREvIJYxXJnH0KmCvq
YxyHAgv0qW5dSjAqGIsL2MgD8D2pwmoIcHGNqz8ZcjEw8t2gkAk5Irn+yHxU
yMiVwkyAPcX4vPAG0YvbFS1UhZqT+i9mMltLjsdGfkWubqp3PWQl6vyr7Cqt
pnOxGDFtzzuMxDMzctt28Nc2QpQviEzjf/7j/9DzjoPDQrZsDN8ITvritVSD
KMAQlVJr7mZktsA5TJ2B6e/TwV9HvtTWpPUVGftquB3CNF02FPIGKcQ4oeJs
x4kkKdVEUcpZdHp4HDuDr56XTO8Fm5+uVwJj3ItuJj4+UwKKjJHLi8/enNT9
02arx/rPcNnOyvW7/uiOXe8GyBWbyNJMWQRYB3r4//zH/wbSqbLkjVOtOKk0
jhgpQ9F4nJcqVd3LhSE6j8rMjPQPfA60osdwaQ0KPgWdRYGPOmqeyHORMigI
jRz0u/SUdsliN4Joss/SowPl49U09LDKvUDfYrlq4/YZr52bFxXyGmTF0B3l
vMBieYc54I2TERnWKbPuSq4dKZplrw9Ymispq5CmBnxPonSB++k88pF3KWli
LoEL92UhOKRfRzXaZsE5Q4M0acrjms2zdzm/fORTd2rLcrSHBkYSxBlgQx6C
RiHiJBe4b0FslizEHSn/WbdcwXOqHFUWOuDUxSCTBaeOI7QmoRa9TmQtRexY
X3u9xi0iTLHaFzsFyRVwKtj84AUXQ+EOAduNWkoABTzo/NhngL6JbqzHDuvz
b2Sfa4N7gMD7xHnaY/TmaqpyQgEUDrAQAIcPGenOlIpxJBVG2hQq5QwfFvkG
1UHcXq40mDL2DAsc8sLTru/ZtaNBySgYBYw6LkWkmIbMaIFkmvNIDSXDhUmI
xDpYYKbeBXmTl3OxPBmSlfar5op//3YOJ6mn3YCcozaA76Hr5tCZUNnw5wzL
SFkXzOzJUYkeyXDnT+OoTMFAYQxrfE25Z8GRc0AFRTfxQCboKIDiEPbmtIfU
dPVAVsBigoLFnEsmX7LIzZTTIyG9IcfmcuTZnMCNVCGonvIJsfUBe8V4zXUp
NdDGPTZ1+2KbDSl4NJx9li4oJ7w0gDHA5Mh9J1W3mE6olXY7Hvz4wa2LET04
9mZuZG8HAbvjWlEJFjNxqphC7rIJvkYtLnTPElIGhnR4TfPsBldOxAfbYYuw
BjF1PuLtEILToI/mNpK2OGSYTM64EqrRuqTQvmWVDxsh4OXgp8o5iA6uMcO8
5yiQUzoM2FmuZgdT3EaM6gc3CvvLw3J+1wztH+jXbp0nVjay7YMIZyb8Q2ry
uPB5YBghRjcvg65jbIogL02Wnz1fpBKOnt+dTcbYYFhmY8AuWrVSnwBG4ePd
GyOjrdxExapkAFx2Q6saY5z58RWmJ9RzPP75mhD61iVsjEzyD7Fgh8FJUAAH
NkJyolEMszY97obgP2iDcXE0Zy4lD/o5aJaFBw0wUAI2UTAsF2UgTU488eVu
w9jBTY83JLyqkshQHfYv1B/n0nZB89MbAb9dSmJ4qXV2VHIf3A8PnzckkY+k
yiFLzKLO32asKaFNpfkFf2DR5PFXTL0zZ3uYej3Q2qItfC22V/4BB+5BTqQl
muVv2XpGWnYQOtHgZDCsUwg3P2rugJZt+xCM6xdZ097yJf0Z604c59k0Xb9h
qB0P24cZwfzinfEPA4cf9ufR471vA/ITVRJfBFrZ3J+3qeGuU9h1ht8Nkcmc
UBBzjwnFDr/jKsLdQBpapgRj/hnU7df4p518plYGIvJpGEb0cL1L2tZMqGKg
N5kkbA2M/O90dVxiksZHwzyZH1QD4ZxcGA/zi12aTOTgNjyANe4h+WlQanju
QqnJWNpEJD/+wW6A86hEumwJ5oZfo2I1jI27/IDWqJ2dZXgW+OJ6GzbDrM0r
i4rAoKw3UKoptXsu+6OtN5gxj+vybVokdbPGen1QD8oiyYsEvppwD0MGRH2r
8n6ZNwtuAgCE+7qFeWsyopYuWWVFqRrkVv4VK9QbqlAPoAFSxHrRayM5867g
HQs4hQMhKu7S858AXYIIGGvpLdAzXZmdEIUISVE/AcJAOFXOsTo2f4d7hKcZ
fBK2F+A5IVe9zFpSyiH6w9g7pptPvwCjF2FZe+1PpfViSsrR5BapdIxihyFA
kHSK5WcADEMsZgZrRI+VgPhYRtMCGCNeJ9A+DIKDjCWfkdpUUdGgS7vETE2n
pRybzIOX8AfWV4J+oj2FirbHQFoxuJfAVbhOiBF7nXrQVm/FA1raMoj+Nj4e
jhvLm0UPHXK/TVddRllmJgOgSd+VRblY+9ZnMGFWve+tZ5XKQuqSA3oHtUeQ
xDRdGGEV5QbSANtdSLtE9nwz+NfFtQWPM8TkY/bdrUnF0mEmJuCQY88ddiS9
jZTgS7u9XRTEAUlkPgZTA+RY7wvDRKnKJ6jgaUPpcFt673BG7VejeOl8TYY5
wkiUMRbNwnv+tppecVadwKq2sllC/C+Gyxm3u8H5VDPMM2tVODKsHjsKYZPT
ScflFmJjisoUeV8KAyQ6y75TLs2dLB714PiY2n64CDPKvd05Oz7BfFej4LYL
VSh0gJVOjIqO7kvssHSnxozl/yiOhZkar555wGAoBlik5ANggAMPVTZnVGr1
U3F/LnROCUWzWkgtg3ZY9HY6lSgVMaq30e61+8R1XpHmgqfoSK7E/ibbwD4u
MZPV2azcbosKtFChaJz7YYszZK/KUmuEt1y7KdhbIlfaZtj4tk6BZe1k64ju
EebisfKK7mrkLM6/nDbOd0NOOXZRR7GuX9L3yDcIN48rTNdBSx/bVbRseu4l
Drckh79zP8SIFC/PqyUDa0o455TN8ONZfxscd3q4fuqhIP5J7gQu2l3otBOH
nXT7y9QGZ/6pHYtw1VwwTZtFBYUk7KVMD0fHXyepQmxgN1swftJismaFvA5C
KkSP8/mKJJzTG0AkuXUlQa4LqfX/3ZvC4ypEvrrvY19UEr1vg2a5kO17bx/T
b4QMux/7mgn/zei9g9oK47/4w47wVPrt3+TF8LEoXu+VIcEo9qutUajpq/4m
g/zpfXxSXC04pYDZGc7lxKpU4SiG3AeyogNamn7kV+QCL9259AS67cd2FAcq
NviEUT7PSfe++L5/u/91x3O0f3vdz3nW8sOHBNThXxTWw2y4BRpfR8XME3D4
FZRVqtw7/PiNAfj4S4ys8YqGUpl/F5pcj0zysTpz6gvqoxchU9VS9IcKTGtO
CattNc+0JsqlQsq2uhWEav0dvbm4Z/I864i1aKfLfGl3t8DIugQxvEWyWPHW
+BPtrUeo2aQrXlP7JuDaaHXpXu8PW/ETZQs9HR8H6EiGdV6n8xnz1pZihG4p
2kPfZ8KCDKm2Qb0INb6Duz3sIhuHszxgkHPHD+VgHAq5vBg32XcASdUtQdY9
HKwLvd7IRMKj0dEHjCmu2XkyR7RW8N+PJmznsHZd765AsrCEx4Nqh+1EGT89
YSNJTVMTNcZCo0opb7OfSFAg3Z/lb5ThzHp6N32aQjdkj2HYdNiJfQYpkxi5
IaJcUHduP1fOWgmmGYY9N2de85Q35BsP/dSsY5tV8bYzTifD+gxBSgYegDs9
xpMQlazlNmZl1lYoMKXARGtWv63WT5XlRMQ084QBlFWF02myWdu0jxdp6TAt
yoLifkcE/oiAsfx1mJr7Y0J/TOCP1AwbT7LvVStp84gH4uPBjCqJ0Y7NR4PE
ymhkHv4Gz+OhBRZ3ZOPL0PALbN/jEbur/d5sqA/sENjF+DRwEHCR5m+/weeS
8k/b+f347Gxs0RTuBVCwTUr5LSeScJ863LnEthNuNRgkno+Z6Ao9DAR4U85v
qJaT4Fls/phPNBfuFK7ad5LMC1d+47AIunsWoqg4ICuYQQCfoOgMQwanJKzB
TNJDHB6KJK7djzihORYOw0uK5jbDkG6AHkVP4JNR15LQdSLsFbpWuIP9TBz2
ip0BRAEM2nrV4Ve8wd5rxozv/OfjF/BX/A9j7b0+Pr9Ijs/g1j/ZY750WNKX
mvQq6FxapxNYd1nf5lNiRS6+5qI6DgNJPiDHroeVRMMjRAN82+kJX5tHA0RK
DN5MV5NM2ia8YwHCyIOMw+CMU0133ODs9O4ycQQSkyMH5H3xNUmNFqdn19UX
76C/U9hmwFqxMERwX3DGLScog2NpgYXz+bvO23EIT2TDBjsW4Onh8QKk2UFb
+LedqTpTqrIEQuKOkVkAUwRz05xkCsJxxExqbBVHkhVSrRXV6knkB4u0essy
KyUi3jrLEMYTBc0WvuoP3FiAvUEKKsuIvB4XBr7yWWNWg9GmpuHs9coNwlKA
XFpnkpI4ZKJj8BwHDhkSmvcJ42+wzekcsRzXQYNFDPoju6T6MIri0v3IiaTY
9S71dKIsWvJ1LFB7JaTuqgRBXeujIgJaSRkynh8aQNp0szF4iXS7BEVWcmmC
QR02DK1zt+P2J4Lhy455edxKDIHbuN2ygAV2fdyYoMjly+oOUyUVHtGVkx+6
1nI7V2PCzR2woi7e2HNFh5CQezf2J2MTOCMLGCIxVFtIjykpE7Ke1Aa3CNFV
9w8eiwbg0hWdn81EmKmU3LakGLXZnJMIuCdLreq6t4XX2cUJ3PjgS7LJ59x5
i/smdwY5c4DbO4HoQSly+nRvL9l/DAsbqPe8vJIu6lVGEaElac7Sp6CsFlaN
EVgry0VPRcvYrN94wFmfwOT7e2JnCTThaJPI7vM2ZVu2El8VAcSAAcIPSf6F
kpBNH/YInCRSC/87YTQ8xJSGR+8HryIEB8pAERguhRujvNVFTtXQ3vHPnfDc
3KlOL8DVaDX1prSYOH4uVbUuyQ6vvuK6abUskHZWYE58gHDBKV3YHYcS8Pmg
SXKY91Jm3hZZpBQMAT5Wb8Wc7gG7yPpl3jgIfe623dsPqw5epy0NKcWobLUB
1Fh5hxDkkkvLkR73A6HOxgoudedhDjn10HaEoohiuDumjZs7K+5a7Z3mQ/45
ukynMZUK85/6c1HqFjBCwwG8StI/cnQCYF6+m7o9DjazT1r2bZZWWG8coDKq
05triimRn/OFh5g6zNVlA2qagoHpuvZly4iumTksYsX/k0Tu7F1KGQIloYSQ
ki6LpeTXCWF5xwIEKADDVGDqwiDaPIkTz1kbIIyVW2erYMZkqZC+Bgcd/0YI
GB6SkBMrfVqbyVdfMBfWpBAgLRytBzPOndMOOdM48WZoSvicaglSiuIVcAtw
LBM2cVmpPOwWE+pWt8Fpa7YezhnxYq4p5E+n1bNBJl7YSx2yx1JYP8/rRkJH
3qsnkC2SbSPhWsFZs/DyKRkgUlssnYhkLPL8LLIp1iDreB5vBFuvUGHn5eqK
8Etw6rWpjXBTYQAYHIBGZelL0avCEAl5fAJ6ZzcNVu9Tu2OfBRuAWQriD8wr
hMnGd4V9gTqOmcFQaYjIQUwUsQNWBRznFFRakkFbtIgtHNSnJfeemw8MOaCJ
rKC0HmsMSPq+IJFo1xa3ZSb1mYxrB/94F1XUGrHSbsqooas3mXkRabETBn4N
Xigvk+OFj6Xtge8B0yNch4oazH/0oD25i1CXBIVYM8I6Rc8xIhjsdlrbrTDn
G2LhaC41HZm4J2JXt87OP5c3YA0XjJyB1oKkQdFGhKiibG5zHIpaOeMos3OD
lLM+yRJ5NYFDS+SFwKgCW/R3yKJe/YhsftdqrzMth9wDwij2Nr5Xg93GT00b
x7BB4lQ0wDreuoQ5z0m2z8xoLlR7aRsdqb0msNnY97DT5l3BiI9PPAcBvp6S
Q4mDoD1BCHk4pv6lGIFHpWEI1vaqtryLQqMGj0DBsu0JK/eS3VBHApw74fV0
bREtFaGGY8bLiAXcVNkdBzpKt2ZGEXhszYlmUEeUfm7dmN75eE+DolarPOuQ
FLcQK+uqcVofAnXtofNMTN8FccPWq5zZGPNDutzcAtq/WziA59qcd2ALuRjb
zKr9r4AvRdF/Gjdg6hpOKZaWbXrWhFVYYmCzKsmXaJGRduweuk21HB7FO/Eb
CQyh1e4G5SxICZ6rFNL0C0ld70KVoQAi3JEi8h5mTuL0ZV28545wNZhAxT35
JelK/BXZQVkKzSiS4nVV1bhDk9QnuC7kMWfAamY0s2acCllD6l/qShEua1gQ
66Ts6qY2eV+Xa1+GQcrcBjbLSHeRxYEz+gdvrM9sBWLDOo1QSzOwfB4qDrUI
XIQm3ZIZnHlXl2wX1xJIyoW8GxWmP0jtAxVBarKo25rIlXkRghMjNYlN7ZCo
DZj3gPMnRP92KR3+1HlT6xDuTBpUshy8yVN/peqgWeq9HZhFUhrfSTusxj3Y
jS35t5VimrHDdEM8REIT5ETbeWCoY3BHrOMh78IQC70Lv+PeEgJU6Xdfposc
uNP+aD8mJR+eHaIvnb70zWBzPEcn0hdd2hBWYox/F888dPFM7gB1WmV0xbCd
Vq3paJznHjJmzXxj+YxfPLzGrMniKkvOuK9DJrGrHgj+nb6iIKewJbl/QULy
HYgzsn1LhUfSIiQXMvDe3Nk+xGr2vp/KMli5vza+gN5oDq2gLzpggDKDbE3T
8tXJwvAd2kdLS30dsOJqNsP6x4LNDYSetwqPAigGijRnK4orFO1BzbIKdN8A
Aj0Ix7PY+pFS+tv+5Sgaa3L2pqqcNjhlN9jQKgNox2Ody8R6iPOQW3BDeoUP
RW84E2YnUqEFDp0wRCBV5CVlmyV9lsj8sfdluk53amf2u1TcmZrl9lZ2gGJC
kje28RQBkUXpxpvNWe2+PkkqxRQ17QMid84zKLkprODc1ZIZCKYWv7NLt6MM
8N978gI5lbAbHCRNSbUTSStkY1Iv7bCvJpX9os59OqTGgIkr4pQiPCkTp03K
uSjL9RgcWF1ZwCbDYjrNAB5zjZ56rZx2jR4u2BR0qmH/xprCfJgNu7jMr1Zc
f6HikAqYujmWhI7Tbk4vBUdu+4jCOGW0pzl40CS7nXiJmgtdDVE6CbTTZVLa
CXowV29QuyxPzESV7/m/3vg1hA3dnYXOMfFR5ALyVeYYQM9S2g3+XPCHj3Xt
eA/WAVemzoGrWG8yn+5PvHYpoxZaKuGrEte2ozIwSZ83r647CWm4PgQC0aq9
6laFNPUVFTdIoZI2i/6475KeUeQ6dSz7pLKgZCCsVZBbrjlmKg6OgjNwiMDa
gttEqKd5elWlC5MvW5Pv66dA/lCRhp66ebWE+3z5QQRsJHcZH06fQS1n1lsV
fKcCYBxJMk/prcO6F/mjgP1FeYHwMuThWDX4IxYhLDICgM5raeUDrHKLlKId
+npC36kHf/zTDj9UD7ZGEetSaG7pYz5n0BpjFD+2cVtBDB4vqerxXTz2C96k
lDyTvEwPXJ6M7kkdHW3I8BxFJrP4nmzU9yF97rrDfB9t+xG37x5ke8NEkm0M
cMMG7fz0XT+K1b3/3kda73o4T/NFvcOMGCZs2uDcOTblyb6P//gnRD3OMd+J
6AWN8gfPIf7QrN7POgLt4OvzAQ/yb0mi6ZBGO9gBljVF/y1KPrhpxy/QDMUF
nxPCD1XmfJaF0GyOPvY8YQQRa3Keeijtud45Bz1QFZA81oes4pP3QclSmWv/
AYQTHAQj6CqciPzgOXzsKugIz74bno2FpjIHdO/vxoOSyf/0r7ocKWsAfnt7
poj5yDPWlwYfMgujy3ExV/xvf/xc6/jvTxnhvz9lDnyofx749P7jo4uXQb8L
41ZPsO5Sk/zxi4Gp0S7Q3JjU/6UWrewomx88i9+YVPyxsmtXKSAWpMMXds5G
EuAt7DlUPRzAWVFKSTYVaDsNJHJiOG1a0MQNhcdqTk9zuaMssslX17gGVRTa
VYwnD3QSNHKqvW/hA9BM2CwYuc06kM0Cjj7gxr1O6CpTQa2Lq+vjCmYNylNB
8budLUlqkm4Yk2xrMBQgibcZl49yojzBz5pzoO3u0f9e9iSvi7bt9PEJB485
JNRKwMb9pCTcFxjI+Dhf0KnDffDtI+sH5fNKJjMlMFPmsWSgkYuGtoxcp/O0
uso0tVDiFDfq0wVL6NdM8/YO9nDHvj4AzR/mx0Vxf+G3/JU0pNg45h6PHtOr
/8Lv7n5hf2/0aPRo4I/+azn6I7kngbk/jFv1C5vaqoTukJEHLeHUUPTVO24Z
tQo3ldS2a96fYad3SF73lk20vSsd3G1JhoNTkUhHOPvAq/Jx2dvjxrs7cBuH
od9GhG3NeD82OUUtNdlW49prdepgoE94VdjjkrPE6R75JgEYZ6R7Ihk6nC7I
CRhixbgwhw/6amNXDZxKcjiik5z6FOfak8yjZ/Fhxw9AGJopxZ47VNGuLnIj
PRbiY8HfZj1VhpCRfEWObPk1c1Bx9qa1xD3Z+aFGdbsKulsBbe3TvoLnoWYI
FIyZqZYU9qIsMurYOsI+UF8qHKlvREjwXsI2gh1iBDVqEhiUwp9//+bHVy/i
128uDHJpODqzW5eiwhysB5Kje52CByRCgmwZRNBaY8x3zYLyN4NVhpkO0lLA
T6HOaDctShYLQc6qUApvo9196I50cO5C77ODt/NFEMFMTW6QFmfd+/44/jkz
dRQ2hY9SLoM0QsYDcBCr5ZXSUom5hR4kjLOSepKPyHMiWcqSxZX4+baIr7vn
Wnldk1OkphruJceTlY/e5Z/7oOPgWzxIVI2gpG2q6CcsvOL+121TB+0MmONc
WiJhPyASvjP8GJtqDkNeEIIWIEIG84dNkyUv8QUmdxIuFX71CMs8CJ+spwZR
C5zwzjhMCEP/rD646bCm8Pro4vDN65cotM+Ozvlnkkf3yxPM9BFABM5LMjEb
AZAiDQjImFIVuOJQwiDNqiiomy4G2tycumU72I0HqYSY5CydZHUbwebeaZIq
j5X6SVMm+F8qRTlEupM+5jd1fCp/x/9SOu59qj/GAS7Lm4wLUXrvNOYEKqqz
T0b0kG7EYMUhH0wgzPgWDDvM5qyoiyKKkKuyyTk8LllYkgMDu36dL6VVCjyB
62WpQJ6+tH7LOhwn53LEzBbtalzf+AoDgDMWWC1XpvRvQ72CkycYagAjcci1
Sa0u8R6TbllbDVq6DeuewWuPqNu3NlauVwzMrNqwpI+a77QrXWlp23XwSO37
j//226khhZ5jhSnYb/hx4D57CcBokVrc4iKcvafhHfx8fENXcuGgJ0rEsq3W
khFE+a93puBx3vgoFmNQUTjhnpHQcuPdHdJwqU8uwGYALVyU1G42prcRJiRD
kEoKF5ctkFkSJIRp87lrbn9E2Yg18jICj53wDQySB/txIzb0ZOV/nS9H6JJF
t4Z+457ep60vw+Oujn78gMfdl5/r4y4R4iFvb305ajWOue/x1pfRca3b+ZC3
t77c6ZdzX9vY8PdPPbgHvLM7iY97imEUnrce/qp38u1P269s9SJ2KCTBp/T7
f3WeNAAmijwS9HzVJ+9+p3+y+873rvmurvar/m87rJGeMRLvj6gVNoO3cNzf
ifnumYxbnWzDbyd3rab9ZOLGjJP36iTwnz7HT+nJ3TvfuXHe/4qnHkAh/mNL
C/6cQ7r5Kn747m6iFfpP3znfsYYutcTBTJ5/1O7Rfx6yhuQhT7Zur1BI303f
NcgudyoJ6vYNdLaPcv/26lhW4Frcp05Vn1YlIYwWhaublnYlSG+oF9yb38CK
WK0BJNfgBF7AZY7Ud9JWaQ59NpexvcxErFqHKL7Uxo8qOdH9PMd+0Q44wOm5
lPH0Z5PeBL9x6TnnQh0FfxofOSQKkydJyajFZF6SlxdR5lNuhMrdYo/Gp1x2
+fU3j57y2K9evcDP8D+o2VONmGQzc/UQJw3wJHElnAaDwLyuRaC1MSyaOqPo
hh6bIB2DywcxdZAqhVsZRN7YM7XGultOpaxhDybXkjQyA+XyFk4GPr+mg8D0
HFLBUeWfU2lDfLVKxZ9IfgF+ddCXrzY9V8RDDyfZmY2pd06nmInC9buKs0h5
zGxqYLBeX8X9ZdLJ26xhXxy/qXLYtHoDUJ2WJjncxaPVP3VK8RGXJ2iQ+J+x
xX8mVhO3qBXilCtwhDd1wgb0aZlTUxpO6zblABKOuFS4e+pwm03eZlpTprNx
VTcMQOdxHjFZ2A1ChcytyhCzSKlZmHYWStYHYWLjqrrHkOsSxSO9Wgpk3ryc
vNUp+YMg60LykNgLGryNS6nxkM5KLpczE/YESAahQS1PhSTBAiPbcxisDVb2
tmdlBXb2uCzlfcczg/MzxIusUP3s/XO/EotKMdXTxVrQ7MkFExIx27Eth1rf
po9uXyNfeLf2eRRrvkWxnG6qTg72rWplPLfOII4Gv13DzXIAQUHHmYjjTFiL
4C8VZQ4JniZIhDlXxpKnrO5pt9rqB2yuLp2ZZtzL4EP7i6eWiHZMChDWgrk4
dKjW0qkp6BbqoUSdD5arLMICOO9rHQwjMcrdazFcaFMOpZs5XDjyAANZoIRJ
4SKuibpKLu2daQNOKxsRULfVkbc2lOOtYCCGEIwor6XUiBK3+bAFjApnGyL6
+t4yzsUjuxm5yKphFoTdlZFk43NBPguCJ8vqLv62+jkY8TLEsIwjLpHGFi0Z
KC1Ud6E3rYZbkKHg4BoEYAZHfxcAAal747RnhZ+fEMvv0Fvtaq5tnDZw8CBj
UOpRf4XEBjykvFaPdLAuNFYjrbO4C7KMRtTam4KqVU607jBzlFsj0inLxSV+
e1PmU0q/BJmPL5EaVLoMkbuBVLHcwZ+zyxXkWspDnaUTDOemjaJzA9VcYeFZ
I974m9W80KAvM2ZUHcPEYKwV6M8MhrOztQy+WwWjcj969AQOdOfi1flAMo7h
02++fYw4PDsY+Bu4XQ+6cKdTIinKd84IZESD6/C1gvm+uorZGas1gbVqfloJ
6HJ+q7x+y/xyASu9kvmantfmjLDVkzkxp5U5wFPF+ePMBOnagq/3/dFTxR5B
gcJbT+oC4beYguwKk4PRWf4lmH9waOQkzvLGas/SuhSHzRcMvU48q16W5Wzg
6s1dPx/HiUE72QzU7qbh6/zNhKwu7F8/BXkEdBlpdEukDMjAq5zmlLvWO+2Z
nFH4q/1uGXvzBCjRn3ftx5od5liMQtAaQBLoxJNgULvfCYN4YZlzVRZXXPgn
0R/XmJCEqMO3cnhEbWQJrr3WZBSOhmLXLqRUuOeILYKQIlTPt3SXqc12XTxa
olI+TnJxi8omR4NhSonvZ+CiUzBWa4HctsVn+tNTDq/rnq4syrULky2D86e6
WoE+H3Ubl/ygr6EEAFTJe96X9t2dHdHotjnavS3NOHy4GyStDtQpiNRKG4fT
HlTIBrwQNhOWsaRoNMMhrqTpI/urVQBKW42gk8iQTT6EWEN9CI+ONRRq6SUm
QiIAaASoIYqYaYLpwKLwbtJdMLtBa+cCc9ICfDG8tlFR2E38TLaXLzd1PBJV
xGHEuddGPtyE0d6qYLQsktV0sdQOJlxs5JYBaW5LW1CcThTU1npoJJ3iriBR
h3TqO9K0sewczgErnwXaVFH2Drdw2loFzh0PDkYRbLnNCFZgbf7AwoHPsU5n
mShFivtCAC/MgZuQXXCIhzK/qHpQVWB7VioD/0AHgO/hm+JKcC4RCFa1Q3+f
tJ0pToYGT21AnPljt0emaaNT+32KZZ+citP4ykws1vD4rxhCdZUsXFosdT8b
t3AoSf2EcFVHUsLJmLO+/8ZW2IBjhzwxIm9q6tORcJ+OsrgsWT0aMMYAdUqI
VN8S7BVpG/0/L06HtnXHQOmElmByFyy0BIellpSm1ki8PbJVXCGSPdecU6O3
AG9KREhsSwkf0nVKkqzC0nOnPrsS6rmDpfHcWZiPSelzHaBcAEtVOU61Swtp
7QvU0oHoGjrALCYawq/ydcpOIlBUs2Tgg7LyyXpea8SGIHD7tH+eW41VTmkL
NJ3tyehg9LhTuDfgmqQulpjDOdDt8dC5Ht2Q+YkFaFu5EkRZiO3ZyOiXYj8J
wL4PcZL7xyGLmb5mjLmI4HvC0rdrfY/c4RBmOugREbuWs9TtQ5q0RCHKnJ+8
Q9Ljdhm+4jAno5sQCObpZTYPZddIdqRTshg0jmFXGDLKzCJJ29lv1+zqhC8i
65DkPBB5Sp021YRQCs3KyeAPFib6iiv1F8I0yTZRt7iTACpIqmiz6QAmJ8DK
m2cp2VWX2D9o83qisIXSuI4D3EQGwANrA72h5+ffx2ItoKaP9VFBGm13X40O
kRc+f4sDvS4SzwwH5ooB56zWVjy+5tJw8hE3tVnVmUW0bEx3+7R/unEoVbRt
ciCd+NWXGSjeNRXyi4VWziLGaZU0Ka6/EveYeZvKt2EreTPoIuKQJwKCGBoA
bviJ6F6Bo2ReXNCacrP1KCi80yvFEt7ZiSIPHh08/ppSXrzVNetJ7mCMTDJG
PF9zlccCxhCeLUi+yPmIOky2jVja6hUY4JVuRCtF9LlskiqmiU3yxN95Vnfi
/q6d/hYtyqmXMztBailDTEtCQmqqMwlKhv88ECCtIOnCAkEgZhThd11qsy8Q
17gagoiAwUcU8VgVl1WJ3201jUcEPcVIc5aOU5fJYSs5elPRusmBmKLrJtow
Kd/TntHSGGON1q/o+D8FKU0ngguAN41kbAuspa+bs/Nlln18tVfbJg4eUSNb
ucoa0JI+JZaZ9rxqR1pGEpFSH2gLKCPUe3Zxwsnm1Lt+8AekhkhLlS1WytBo
2wbqyrSCVDJfpFNKPQSJlU+oz7VLjOGZUfGu4CwuU0RvNRzYYXIwmWzCmVYZ
psZNNPYq+CxLbcclk+wdANw+CIaaWKDvHM9+UcqYRqJ36dUKqQK6FdiXiSJC
8KXwCT2VIxe8dK1tNoPx9QZVO/PXln34ynxMj0tFF9eORz7yxvigN1R/T5OW
pG9205Hbg9wYNLMpGBZsLJhoBSZoTvHd0i9aHfVqhnKcS7kHKdKS6xbgUHCC
YgALjtORUYYeWEK5AO6PhpNiTycGyMVTnCuvCSApDH/RVEbsDShIIwp6jCBb
aDNrMm/ouTphz9WYvUdRFD5YuwdbTs5AZIrHkHJ869IbZVwCLXaVU1QJHsl0
QHb6Kr7WJb75en+aA2YsH7c6EVP7WOTTUs6GIWr1SvooNwKGam81tHkq13PE
8ndTtROJx7DjseMZiQOerqwKdjR6CXBZe4GblpjkRCw039lbCPA2hPBE9E24
EERpqOsAkxwyUntwjREH+On+1wJiOw6AoUPv3ptzmSiPC3+dpZeVlM3zvLyS
IXvb61kaBe067uscnHuSdcaOBqNQmAvdqDeEtQl9ve4K9voMpF2rDCDQslgf
4kbcqM861Ug64VIOOp28c3iediekU/h7gCBmt5dP2qsoaBVd5iGG4Chqt3l2
BV62MQ0DnQNbROhV3AJWmWFJAmI1s4zPQzdJYQvjnjbogHK3o4Wh3j5r9khJ
lNct1jat5SrNodGjNrmcuqp9lDpU9+3a3CbbkJAUXymD6vg8yd0JB/Mdt1HX
Brz2W7h2D7rCrWwuc0ZjDVCvfnBMknRKmyJgkWnw6yUYG1zCmN7dcZV9Kzjm
NrdpFUa5ba8kI3uxFRvU84k/RBMXfC/ulkocdv510I9WAY526G8t261lPIT6
St8DsIUDZldeDY8CJUssd5ihd0dabuXNLf/3ES+/fSoep74N4Y7WpWoylPk7
Z2SzMFTk+j87aJIPxep/UI/o6M3xCx7NPnkYQM67IDCt/3DMvkFEnRYvSoiE
yLou68FR2mlR7jrpSRNudfeGoEq+07TDRneikrfWhAhahq+1eLtcMRQeiqls
m7XLa7iFQ8hi2l73+g6j1Xw58kGacmE7tpjLOhL8FopnOY0kjG+pP9MCxqDW
dUNaeFBRTIlal1qhFHoeUFozN3V9t4YR7zeHNYRB8HXKg+bAob/DVTtxbbC3
bSIq/XFsmGoXXAWxrt4XhIi7mPKCbt0r2E+0k/LLBtyDlteOV3eDOR4AKfMO
SwWdw2MMXm6hsiJToySFu+483YtFUiA0ppUWwRa3ZLcPGPMeANe8yBdZ8pxc
xT8WecK6GfubwkvcLQpvVlO0XpyqgfEgYxsIyBAGEaQjsVtVn6Gic9p185+s
J3OhxzfY4TSRdrGMizbWWvaePnpS2RT0wXbJEXTlwEJFQEJnk2/kk1E+s4GA
IF6gCQFdPZEd/8ZFrRCSFAdkHo6tJkx6kyZtLBDzrykrKvGxnnugzrKCUYQb
kscmVSw639ubeDHIKm5RMhjGPUGEsLcsZ5ZyN2w3gPa9HvQ9Tw1n2RlnvMgU
wqVMiI0Mn6s1hZlP8Dosqeedw1w2a+ltz8O91WiqVoGiv1N37lCO+3iKD5XQ
5LnmiqB/i7UC0Gt0lp1819ohPMxB+zIUh3dJN2obcC0CK+8uK6KAkAdTDwLN
YdtxUrywYZq3BlpfMPlRU7NQvH6McAxaBfkQfY6SL9qeVGXt/CcM9kTs0UGk
hrdrxwLz3abriIVzEW+NaywdvUivtpzUIhcN+v7QQ76scjE9XWqb7+8Lhwhz
puZFZosj2GJz68wGk0rp2OzVCqRvwak1wTXlU7SWgatHp15ub5ggBKGWwcIs
CXG0nRpTinbl7oruPxPkD6ouBiGHWxm2avWzH1FumMaeQgxDorOAXodISAzp
aSmX/SUGD8712EDjupYgeLaos/mNKlHzYD+ijroDm5lVjQcN6Li3LRbA8npd
kw4JTy3VrisI6BcRzBBjJKJQnBSW4svZ56PAvkuqofNZYohlQtKRPbFFZ0cT
hUzmSxFFh3PqiDGUlemt2vY5C5QbLtFZjP5edJj5HzQ1JGgu4AeMcNfJc6od
roGuCdpQYxG0t9WqqNXBa0PnJvMkaI3k0tCHcYStRGrR4BQvxKfxoriQzC+S
M8/LssGkPGpUpagjEoFGdnhczKrUX/Gd52fnPxwPRDx9++1jIjJB6GAqyopp
GBmM5/lMxLARIwZynlywmAOaL+1eoXpYOAs+omgGIgcyUCRBW5eUkjlJbe27
36uijBHVI6NSSy92PAcRYL/QsopUcoRX3eOusltwOnR+T03QK8qwLQPb0iiN
fVsvjW6GploYS1xiwp1oLLSlL2FymDRJOMguTWMdv9Fjp3QZhft0Pnf5VsDF
JKGLExs0/YuCrT5Cy+c4My+1wzlaY/ANJhW3V2ZIAxDJXRbJTIenExcww+xW
3l6SE1zSYVP++IBQBXf6oQBgLNXPTflI3ZZV0tCKnWw9KW/EYHoiNzYyMmSs
dS73FzUfy2IlQGFDNH044TQPjBZcVdoQOUi8ki5WmPjcDXjULjJB0SHxu1AQ
5K4eX7bbo/IXSWyKXENbn+pACeCzeVoj0PmJPzDKMMb8bBPfa7r5hBKTMcUv
UQuuhB0UhBArfeLyxWIlDQRkPs7dsVpOueKIzC1OTvGQtJpuH7G6LVG/BiZN
jg6CgeQzwEB4Us4SmnHvOeA3aheoc+3ErMqjiA0ObRq59ByIeE5VQCqwQOek
3gEKWuz02OOZJBkRZ6ICHeECFMdTyQbnwta7TQl1TgE4qXnGojCUp2lPIuww
MJrVejffi0zC7CXyUq5/oWqtVV5f86kI+lU3QZUi9aQtmUvkPD7dllppbZq/
uHzgk6BJSSZKu0w5cglMKrqYkk7qzYg46isMDi9HlpKRWFElRwBojYslShWi
pL8Af2RbBKrn0fcJ1IoT3BbbpCL1myLiScWB99Fo2HMJZIl5aez8xqkGaRa6
OsV1kW8jNXE+oOlXQAGSvKu7Y2YIG8O5Dw228LRzl9/IQEDuTUrWpnSRCOHE
ZGhLrwc4Hbx0lwQpi24Q+nHY7ixpPUmq9PQ0dh9Imzqr5oiOr44jn/Lgc1i1
0StJBYy3Ja4hRCRrGjI9be572gpeykJa7Z0wo4ag58OLz1suANQ2jbqdeq1e
LxdqK2ZzaoU2le7tHutNLDpCrulcM3Ik+obNeL8k0OgQyobS+S4hIVcrY+M6
Kuy9hfs2qbD8i+q0ekphDNJaRPA9Pot/Vbg2L7CJ+XI117S/nMtqJG5KWCMU
JkzaIUiScIQpzr3WVzkGfGmyEV8SA8iBYkCyhxsxcGiZlVsYlTy6wSkegyhI
rHbKu9HRcGfPRq6xQ0gz20KIIfKkGVTEZZSZS+QhjDzqNUKYgkzvrphKe9+K
pU5YVxMt8sUeUgv4AAgqK66AXLPKJXpjq5PIWZI4G1bfNDNlVWhUimPIbHVq
EDOnHm0CAUh5Vuffj5N9XRUaI0ObToo8JWIgFfU61ehgyeUd7a3kwdGXT/PR
1iwShaPF4QsPHj8ZuvY3oFxSoIww+kk3YQvFnc1hECKjVNSwVYSeNXJM1009
+gIs4tfjVgVO/NsX+Onv7d7TzET5CQZmo5YJ+LT4iLnZF2kYJVZzSlMzdmIX
JmWZ+JvYmK1cAur6hVZV5KnsJ6PAoOLouoyw2lW4/H2fCmpAWKKeN5BgZu2C
yq+57Fa7qTjtXEjvQTm9FJlczoVAqY8rMYuAmUhaNe1nDyel+3nIgVVtvylM
SKYibgOqRKW8D+w6o/MOIjfGRWY/N81gqZ/s+NT4MewKHpBB0/KhOXgty7cz
H1P/stuPwBWoqlD0wREVVg4IR2KS0r49aLwdB40e+ruQShoOt+90RSqBbkwX
ErPYXONxgrAlHNDD7+DF1LINf5VGfCRldzY1fB+q5jagVCFWGICWcm0NiT9I
CSfdpPEEtR04gCtpC0tSkTcAWUN9LcnKxVs0P7MKAz+MsJiJ5UkxCYoH1cgp
0iL0G/0MK8zTRfw8m2OfWjhX4I0nGM57nq7q67fw5ddwCucLIIBh9H0GL3ou
0YdhfAFH8yqdzTKg9RfI+sAWm6Nr7Ocsj0/TAkaCLU1B4T+avM3m8MB1uQCm
8T3c1b+VRTmEsWCDz1fzXzP4Ms4FBc/OCWgc6wH8XmdwqsPoB5jVHDW1Ezh3
LC6BScFC1vFhukh+hmlnjPt2fn2bwWbEz6+JH+Qx7aGA43NWkLcu0Tvwo6Ct
oZXRjnpGMQddpajF3akTajkmPeErMogoKQoOmUlJtVhqF8UJyZhzwF0525Vb
JHjEJaZIg/jyctZqaZEqdJTqtf6SB7W9Zxl2/ybvMGLxImwvA6X6W62hBu1r
RDqL6+c0goVTgA43hayuBnOn4VpmnGhOdWugxWGE7xYeWiezclUx8u8OGzYm
wLrkLlf0mDR0nVyXqIUOBMIDRT2rBZF0VYOdIcBA/AtpHwymuENyd+iloe8u
ye1p51fIF64XzBwj4UTDOJgULkvKXlFFpmnD1//5j/+tKMRsb3EIbr7m7Qfd
3OV/TAg6Trtt4niRw90zYTiq8YKl/PMf/4fjLf/8x/8tIU3Niw48FtJYE21T
EGAEnZk6r2bQIcQBhPC+RL5RG+qspJcYuNw7X+itP+nQKzoV5Wg6xzPpTYxY
64OuceTrw7FfCLaWvSLHIPWTWqCHcFNjur751C2YXCIOXBOMoq3q+IZxG8Ia
C7tjbJ6BiHCEy61boAMNuRCqqdbGW5pOp1rkkZlGGzhVfwli6qboPJPBnKPO
qVEdgnNd3rj+9pTFhANf55rFUso5sjPPR4w37cqI2ZBvt+aNEw9Q4VIRJxNS
VdJ5YEpoKRoZydSfOUfCZrs3YT7TAJ3+L6K80D2kBIg3CvWjjRPlnXDimsGR
2QnIraQzr5ERuQjxckLXYpk6c0nADJgUVkvThxBdVJz6WGVwYQWqXZsJrV1D
QoKvdd4EBDOZrCibKkLRiIRIb0A6Enp3pI5viaLXARqsnzOuEW100f21FyZO
kRgJ+liqKXlokeWQP9FnCuS2yZHtKoztgdwfIhpBfM3u9omfRbpnclcpJoqx
xMrY8OXPnsdrpsC0742kMcB37HPjwShCTJhWH3IyLdVfQMCUxICkhyezDoRi
xCmTdTvL39G9C3tvmZwcfoGfDHMgLWdAstHEeOy+U5QUNF2A2CJ8X6KvttZo
G+2128OybWwcHGB+F4nanMhHJwSIXthEy0oRpbA+8tLMesvjC2/5JdzTelqa
Y5oMDEdZhNlae/Ro2dFCKp8yabkrGqo+EbifciwMQmOY+53X6noUzBg6Ki4H
TsM6JhRcVuExBaO8gq5TXbVz8qz7bvD2/uCo3mUeq8eUTmHn4U74s4sTCkD3
O/eFmRMitzCkK/oDwlj4YhCEq1+hmSkFYYi85Bq/wxuGXqYWOr6WXrwTr4qO
LMFEGE/yk4eCWhNT0BBZvyRObChmcQEOsBzOyguLQoIZ8+LSv6njY+ff7zjZ
L9ppxZqpbyy2AGZfPNiWdwMnJG7AnEBYDHfJwHixuC0xWD2M70f1F186JgO4
OENYK2GrX8L0P1PFNhS3btQqihmZDn+MI0ypPQ9sKjhkt6x3MzRlC+ebN6k1
Yd+ZIEz6Fe2HPexcYUJSWOKZuEKxeFXt+U9thCzKIFWVak+5TbUuuO0fDN/M
U/Nr8P6PBaOWT31CmknGs6YgptybSQT5bD6fbqhGPgGQw9zCthVfm64UT0aP
h2HjCvenp6NHo4OR2liOVboqRt44zum4cjmfskr+Y5DXF0po6/3hLunkCgM2
hHbVRuUFHeOd/EEE6BI6bWVCyWxwgm4uqagEinUVqIq9zBLGx8uHzvq1KEpK
Pd1FqfocxljtzaT8CCdlbDGj7IlTJLsoS306JvmqaU80b1PMFPVqEwFP48g/
PGFg+ELRZ1IFmQpUbefzFh3IKdkNe/xafiF4PnLXpaTymbn33SgaN9DTGKxy
oPlKMPp8NoFiEdKFYpQdl72plaudNi9C6zMKe9JFvBifoiNHKfmRQhvSuKZi
8xJjbY6t9vGZum90mgF7ingKdLfPKG+DiQcVgEj7XmtMeHML6aHkAvb2aJZS
qTDcS4nHd0lnlkOB5WYQrsMYTQiIojEezlPQhkhoR4aInX35CGGMXjugU1DZ
ZFdENgdLRJ81PzZWRrYqT7X9e+RQm2KP8l0rGo8QoDaUh3VoJuvwrpwKTSaO
VGEiTw17TIl7eHu8VmdNMBjlU58RYJBDDCdgDfPgJjwPKdMB/r6kaAreNtUz
eKY7RklBQjw/fbq3l+w/fhz8+u3XBKmBefs6FCH3CfqfxyKh3dU6pzAp3SXx
d49FDs3Hve8mCNLFKCsjik0BFnDXjacw9IVJ1JtAwWNFGVevuHaMFfgY59Yh
B8SGqek5+/zqhJKmMAsvvn85pHmKurdZCbc7FOi81sRnNfwPnOUHp9Oz0SLO
V5c3lB6B3Wp98A2+JIwy7O+dFpHtoCJQOoZSBtia+m7l6458GEnZUcwezqCk
lbo7Iy3tKSiCukOS8FOM/KjBX1eraswT2kAHN0gfR7WHNtBJSA/dV1gEixvg
m44ppuiRwxQN+jT4jkhnrA6mc4sYEreRvxgdknQf3HkP9YvBPMmRUPAlHqoj
Hulha+uLHNWxCPGV8B6jx5IQ3QqPgTZazm+oera3ucAGrPpNX+MGA/3/3t/5
q/2LG8LgeIfQ1i2Aa4MC3h5ih8Nzrjfm+2AEwvneMW1izvlwBn1w/62Z94LN
txZyz3b2Iuu3tnPj6PoO80vfCL0f2oce3BvgfbRxmvKqDVMIX/2+Q8bBS8Ip
WeX7s88k+vIz/ANxof86jS7DWKS2MXshbbD9vy8/z0zoVEeb/vnXbfwKD9Ab
QsXP/QAxBYx3Ti/OQdscEKI7fS4D0D8Nutqn/I/MVimGqipqe4DOv1H7R7Q7
XnJfdv380/eARti4yebQNp4D/ZURKSg8LLFDfsoMwF/pkLgO0BdNbg1gRzaf
R603hX+1P4YOho8YoOWTCAf4pE38XOfw55NXw/g/zt+8HsaHz9+cxTtZMxmE
i9jwlc8xg8+1ith1INvVrmTto9jwlf8fHQX/u3h1PiQEgz562vCVT5+B716B
SD+noiEl55xSJz0rMCFI/xTznzZ3p0Bu7zBGydKapMtm5VLE31EFCecKiCcU
lRlECx6FAKVkPbkmXH1PTktMq41YNz0OE5kwalVjW7ZD1etwVc0KXaTsFcl/
pSZYPkFK8rbUgCc3jTjNQm9txLauIHlhZ4pa6tUZO9a3FFWAmtaOlEVTYYLD
NMKKHUFAqV3mVlldgZj4VR23mgiGDlCdo9rkfTlclBgk3rFWsq6mEW5E3htG
q2JOBgiayrcIn0IeZ+N8HjL/BrvfeW28c9TBZHKclXR47RTWlCV5if+Czyfw
zF/v0a8/4F9bw3anHm/+955SA+kk0Ka5S7u9a5AAkvsBatiD/sFMTjDXKtWi
GA/NZcFMW8uhC3RWXsgHtJxyY8WK5tpUYn/rID8evTweAQ2aQWJxBVGYxhjM
NhWEEdXquEd51kFuM8RwriWYQxVw4h1gp7w6ceK7BukEIu48nd5BSknYxVvL
W3aHB2K0eZDXx+cX8flpLE4gTr52ASms/swYFv2O5eBRtJxOH7Kcz0Rsp0GR
MUGwtYrI5YV/6a8t/isvJ2Dgdx8NLSfI0PzYCxjb3M7PuScrrLHg8hkgiSCT
1AIbhcvBT/gZXU6JuepYaHlXKbn4ge7YE9eD22GG2TGQE3P5Jsy6Z0+U2JjZ
gzS9f2P79oSW43096nFiz76Usdt2DO/DtGAzEye0OmX+QHnKKPwRh1PTQTog
A3fTSWuQz0Qnh4yq4uhB3Wuvztlt1Z3JT5z8h98wyym5lh6flZqtwo7paqj4
RGXsHcpDt3tCVmgAxWoBeU3kAQcR6zuvWxv7Af/euwYqlHP96vzDB3mvpVV+
7R8zCCJ/o0OWYj/00UcMYmrP2T/2eQW6JEeT9oSCBiNUu6+wyUi1+0NWFVgR
KLUd79l3Ik/Elk7G0419Ximg6t8Bg5y/2T0+Ooz3v/3mm73kwA9yYrVASSMh
MB88BT8C7QpJuuMzuMhP9oKZaK48llthuZBiFmP2dkX5GH5r23vtTsc4qX1x
km9VF5zPxkG8jm2xtSWFBfP2MBB63yB+U20Es59SOoN8JjqhFmeSeGLOQaKB
kjjsSgBi6kcrxQV8YLQc6QnWO/fe5dD4nT1BYsNhE9HxMaQwX2EzMqqyMc/3
eWZ0Y1PV+r8DrT8ojeiZSXtLPo4pkRg9jA+FGXzcICHxfcYjRkbvZ2dVal/C
WtuZ9C2Hct9mXHeZKY4cxdk3LAeZTbAcGGQnVdSin3OgrFt4GL6E6WLS6+O1
7wAVb7o7R77NIFoP/CJOmRi0H+gf5HNuLApAW3IT8Md7Z+LZ4xJHIXfk3f/e
85fE7whs473OxLtxu17Znpk8T+t80prJB/3DJwLX6cffHeOB/tiZBGv+fGp5
WVNa16EvETnHpDPEQ2vZLCQ/+4/4fHx4UsdHh6cDFX0Oqu26h2n2DxKE8Cm1
jDNVTQ3BvYOgADWxNlMb7QFqJYlyir6w/pk0vnumAyCVvg+bTqc7iHB73WCe
VaW7++BB4J/2RKMTqrWfk89MoJAr5fHeMUhKSUKXDxBidyznTUFhcNqUMR9P
pWBfIIbmZflWbK87tQKur+ZGqVcrQai45Wp3SpkWa/dfxdmcn7btzlQnrXd4
8ecbPbT0D4akspbo/wGgYHS91FwBAA==
--> -->
<!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in m ore precise language, which is helpful for readers.
</rfc> Note that our script did not flag any words in particular, but this should still
be reviewed as a best practice.
-->
</rfc>
 End of changes. 198 change blocks. 
2805 lines changed or deleted 2106 lines changed or added

This html diff was produced by rfcdiff 1.48.