idnits 2.17.1
draft-ietf-rats-tpm-based-network-device-attest-13.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (1 March 2022) is 780 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '0' on line 590
-- Looks like a reference, but probably isn't: '2' on line 601
-- Looks like a reference, but probably isn't: '4' on line 603
-- Looks like a reference, but probably isn't: '8' on line 609
-- Looks like a reference, but probably isn't: '5' on line 606
== Outdated reference: A later version (-22) exists of
draft-ietf-rats-architecture-15
== Outdated reference: A later version (-22) exists of
draft-ietf-rats-yang-tpm-charra-15
== Outdated reference: A later version (-24) exists of
draft-ietf-sacm-coswid-20
== Outdated reference: A later version (-07) exists of
draft-birkholz-rats-tuda-06
== Outdated reference: A later version (-25) exists of
draft-ietf-rats-eat-12
-- Obsolete informational reference (is this intentional?): RFC 6125
(Obsoleted by RFC 9525)
Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 RATS Working Group G. C. Fedorkow, Ed.
3 Internet-Draft Juniper Networks, Inc.
4 Intended status: Informational E. Voit
5 Expires: 2 September 2022 Cisco
6 J. Fitzgerald-McKay
7 National Security Agency
8 1 March 2022
10 TPM-based Network Device Remote Integrity Verification
11 draft-ietf-rats-tpm-based-network-device-attest-13
13 Abstract
15 This document describes a workflow for remote attestation of the
16 integrity of firmware and software installed on network devices that
17 contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by
18 the Trusted Computing Group (TCG)), or equivalent hardware
19 implementations that include the protected capabilities, as provided
20 by TPMs.
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at https://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on 2 September 2022.
39 Copyright Notice
41 Copyright (c) 2022 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents (https://trustee.ietf.org/
46 license-info) in effect on the date of publication of this document.
47 Please review these documents carefully, as they describe your rights
48 and restrictions with respect to this document. Code Components
49 extracted from this document must include Revised BSD License text as
50 described in Section 4.e of the Trust Legal Provisions and are
51 provided without warranty as described in the Revised BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
56 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
58 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
59 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
60 1.5. Description of Remote Integrity Verification (RIV) . . . 6
61 1.6. Solution Requirements . . . . . . . . . . . . . . . . . . 8
62 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
63 1.7.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 9
64 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9
65 2.1. RIV Software Configuration Attestation using TPM . . . . 9
66 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 11
67 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 13
68 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 15
69 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 16
70 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 18
71 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18
72 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 20
73 3. Standards Components . . . . . . . . . . . . . . . . . . . . 20
74 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 20
75 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20
76 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 21
77 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 21
78 3.2. Reference Model for Challenge-Response . . . . . . . . . 21
79 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23
80 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24
81 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
83 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26
84 5.2. Prevention of Spoofing and Person-in-the-Middle
85 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 28
86 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29
87 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 30
88 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30
89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
90 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 32
91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
92 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32
93 9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32
94 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 34
95 9.3. Layering Model for Network Equipment Attester and
96 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 35
98 9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 37
99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
100 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
101 10.2. Informative References . . . . . . . . . . . . . . . . . 41
102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
104 1. Introduction
106 There are many aspects to consider in fielding a trusted computing
107 device, from operating systems to applications. Mechanisms to prove
108 that a device installed at a customer's site is authentic (i.e., not
109 counterfeit) and has been configured with authorized software, all as
110 part of a trusted supply chain, are just a few of the many aspects
111 which need to be considered concurrently to have confidence that a
112 device is truly trustworthy.
114 A generic architecture for remote attestation has been defined in
115 [I-D.ietf-rats-architecture]. Additionally, use cases for remotely
116 attesting networking devices are discussed within Section 6 of
117 [I-D.richardson-rats-usecases]. However, these documents do not
118 provide sufficient guidance for network equipment vendors and
119 operators to design, build, and deploy interoperable devices.
121 The intent of this document is to provide such guidance. It does
122 this by outlining the Remote Integrity Verification (RIV) problem,
123 and then identifies elements that are necessary to get the complete,
124 scalable attestation procedure working with commercial networking
125 products such as routers, switches and firewalls. An underlying
126 assumption will be the availability within the device of a Trusted
127 Platform Module [TPM1.2], [TPM2.0] compatible cryptoprocessor to
128 enable the trustworthy remote assessment of the device's software and
129 hardware.
131 1.1. Requirements notation
133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
135 "OPTIONAL" in this document are to be interpreted as described in BCP
136 14 [RFC2119] [RFC8174] when, and only when, they appear in all
137 capitals, as shown here.
139 1.2. Terminology
141 A number of terms are reused from [I-D.ietf-rats-architecture].
142 These include: Appraisal Policy for Evidence, Attestation Result,
143 Attester, Evidence, Reference Value, Relying Party, Verifier, and
144 Verifier Owner.
146 Additionally, this document defines the following term:
148 Attestation: the process of generating, conveying and appraising
149 claims, backed by evidence, about device trustworthiness
150 characteristics, including supply chain trust, identity, device
151 provenance, software configuration, device composition, compliance to
152 test suites, functional and assurance evaluations, etc.
154 The goal of attestation is simply to assure an administrator or
155 auditor that the device configuration and software that was launched
156 when the device was last started is authentic and untampered-with.
157 The determination of software authenticity is not prescribed in this
158 document, but it's typically taken to mean a software image generated
159 by an authority trusted by the administrator, such as the device
160 manufacturer.
162 Within the Trusted Computing Group (TCG) context, the scope of
163 attestation is typically narrowed to describe the process by which an
164 independent Verifier can obtain cryptographic proof as to the
165 identity of the device in question, and evidence of the integrity of
166 software loaded on that device when it started up, and then verify
167 that what's there matches the intended configuration. For network
168 equipment, a Verifier capability can be embedded in a Network
169 Management Station (NMS), a posture collection server, or other
170 network analytics tool (such as a software asset management solution,
171 or a threat detection and mitigation tool, etc.). While informally
172 referred to as attestation, this document focuses on a specific
173 subset of attestation tasks, defined here as Remote Integrity
174 Verification (RIV). RIV in this document takes a network-equipment-
175 centric perspective that includes a set of protocols and procedures
176 for determining whether a particular device was launched with
177 authentic software, starting from Roots of Trust. While there are
178 many ways to accomplish attestation, RIV sets out a specific set of
179 protocols and tools that work in environments commonly found in
180 network equipment. RIV does not cover other device characteristics
181 that could be attested (e.g., geographic location, connectivity; see
182 [I-D.richardson-rats-usecases]), although it does provide evidence of
183 a secure infrastructure to increase the level of trust in other
184 device characteristics attested by other means (e.g., by Entity
185 Attestation Tokens [I-D.ietf-rats-eat]).
187 In line with [I-D.ietf-rats-architecture] definitions, this document
188 uses the term Endorser to refer to the role that signs identity and
189 attestation certificates used by the Attester, while Reference Values
190 are signed by a Reference Value Provider. Typically, the
191 manufacturer of a network device would be accepted as both the
192 Endorser and Reference Value Provider, although the choice is
193 ultimately up to the Verifier Owner.
195 1.3. Document Organization
197 The remainder of this document is organized into several sections:
199 * The remainder of this section covers goals and requirements, plus
200 a top-level description of RIV.
202 * The Solution Overview section outlines how Remote Integrity
203 Verification works.
205 * The Standards Components section links components of RIV to
206 normative standards.
208 * Privacy and Security shows how specific features of RIV contribute
209 to the trustworthiness of the Attestation Result.
211 * Supporting material is in an appendix at the end.
213 1.4. Goals
215 Network operators benefit from a trustworthy attestation mechanism
216 that provides assurance that their network comprises authentic
217 equipment, and has loaded software free of known vulnerabilities and
218 unauthorized tampering. In line with the overall goal of assuring
219 integrity, attestation can be used to assist in asset management,
220 vulnerability and compliance assessment, plus configuration
221 management.
223 The RIV attestation workflow outlined in this document is intended to
224 meet the following high-level goals:
226 * Provable Device Identity - This specification requires that an
227 Attester (i.e., the attesting device) includes a cryptographic
228 identifier unique to each device. Effectively this means that the
229 device's TPM must be so provisioned during the manufacturing
230 cycle.
232 * Software Inventory - A key goal is to identify the software
233 release(s) installed on the Attester, and to provide evidence that
234 the software stored within hasn't been altered without
235 authorization.
237 * Verifiability - Verification of software and configuration of the
238 device shows that the software that the administrator authorized
239 for use was actually launched.
241 In addition, RIV is designed to operate either in a centralized
242 environment, such as with a central authority that manages and
243 configures a number of network devices, or 'peer-to-peer', where
244 network devices independently verify one another to establish a trust
245 relationship. (See Section 3.3 below)
247 1.5. Description of Remote Integrity Verification (RIV)
249 Attestation requires two interlocking mechanisms between the Attester
250 network device and the Verifier:
252 * Device Identity, the mechanism providing trusted identity, can
253 reassure network managers that the specific devices they ordered
254 from authorized manufacturers for attachment to their network are
255 those that were installed, and that they continue to be present in
256 their network. As part of the mechanism for Device Identity,
257 cryptographic proof of the identity of the manufacturer is also
258 provided.
260 * Software Measurement is the mechanism that reports the state of
261 mutable software components on the device, and can assure
262 administrators that they have known, authentic software configured
263 to run in their network.
265 Using these two interlocking mechanisms, RIV is a component in a
266 chain of procedures that can assure a network operator that the
267 equipment in their network can be reliably identified, and that
268 authentic software of a known version is installed on each device.
269 Equipment in the network includes devices that make up the network
270 itself, such as routers, switches and firewalls.
272 Software used to boot a device can be identified by a chain of
273 measurements, anchored at the start by a Root of Trust for
274 Measurement (see Section 9.2), each measuring the next stage and
275 recording the result in tamper-resistant storage, normally ending
276 when the system software is fully loaded. A measurement signifies
277 the identity, integrity and version of each software component
278 registered with an Attester's TPM [TPM1.2], [TPM2.0], so that a
279 subsequent verification stage can determine if the software installed
280 is authentic, up-to-date, and free of tampering.
282 RIV includes several major processes, split between the Attester and
283 Verifier:
285 1. Generation of Evidence is the process whereby an Attester
286 generates cryptographic proof (Evidence) of claims about device
287 properties. In particular, the device identity and its software
288 configuration are both of critical importance.
290 2. Device Identification refers to the mechanism assuring the
291 Relying Party (ultimately, a network administrator) of the
292 identity of devices that make up their network, and that their
293 manufacturers are known.
295 3. Conveyance of Evidence reliably transports the collected Evidence
296 from Attester to a Verifier to allow a management station to
297 perform a meaningful appraisal in Step 4. The transport is
298 typically carried out via a management network. The channel must
299 provide integrity and authenticity, and, in some use cases, may
300 also require confidentiality. It should be noted that critical
301 attestation evidence from the TPM is signed by a key known only
302 to TPM, and is not dependent on encyption carried out as part of
303 a reliable transport.
305 4. Finally, Appraisal of Evidence occurs. This is the process of
306 verifying the Evidence received by a Verifier from the Attester,
307 and using an Appraisal Policy to develop an Attestation Result,
308 used to inform decision making. In practice, this means
309 comparing the Attester's measurements reported as Evidence with
310 the device configuration expected by the Verifier. Subsequently
311 the Appraisal Policy for Evidence might match Evidence found
312 against Reference Values (aka Golden Measurements), which
313 represent the intended configured state of the connected device.
315 All implementations supporting this RIV specification require the
316 support of the following three technologies:
318 1. Identity: Device identity in RIV is based on IEEE 802.1AR Device
319 Identity (DevID) [IEEE-802-1AR], coupled with careful supply-
320 chain management by the manufacturer. The Initial DevID (IDevID)
321 certificate contains a statement by the manufacturer that
322 establishes the identity of the device as it left the factory.
323 Some applications with a more-complex post-manufacture supply
324 chain (e.g., Value Added Resellers), or with different privacy
325 concerns, may want to use alternative mechanisms for platform
326 authentication (for example, TCG Platform Certificates
327 [Platform-Certificates], or post-manufacture installation of
328 Local Device ID (LDevID)).
330 2. Platform Attestation provides evidence of configuration of
331 software elements present in the device. This form of
332 attestation can be implemented with TPM Platform Configuration
333 Registers (PCRs), Quote and Log mechanisms, which provide
334 cryptographically authenticated evidence to report what software
335 was started on the device through the boot cycle. Successful
336 attestation requires an unbroken chain from a boot-time root of
337 trust through all layers of software needed to bring the device
338 to an operational state, in which each stage computes the hash of
339 components of the next stage, then updates the attestation log
340 and the TPM. The TPM can then report the hashes of all the
341 measured hashes as signed evidence called a Quote (see
342 Section 9.1 for an overview of TPM operation, or [TPM1.2] and
343 [TPM2.0] for many more details).
345 3. Signed Reference Values (aka Reference Integrity Measurements)
346 must be conveyed from the Reference Value Provider (the entity
347 accepted as the software authority, often the manufacturer of the
348 network device) to the Verifier.
350 1.6. Solution Requirements
352 Remote Integrity Verification must address the "Lying Endpoint"
353 problem, in which malicious software on an endpoint may subvert the
354 intended function, and also prevent the endpoint from reporting its
355 compromised status. (See Section 5 for further Security
356 Considerations.)
358 RIV attestation is designed to be simple to deploy at scale. RIV
359 should work "out of the box" as far as possible, that is, with the
360 fewest possible provisioning steps or configuration databases needed
361 at the end-user's site. Network equipment is often required to
362 "self-configure", to reliably reach out without manual intervention
363 to prove its identity and operating posture, then download its own
364 configuration, a process which precludes pre-installation
365 configuration. See [RFC8572] for an example of Secure Zero Touch
366 Provisioning.
368 1.7. Scope
370 The need for assurance of software integrity, addressed by Remote
371 Attestation, is a very general problem that could apply to most
372 network-connected computing devices. However, this document includes
373 several assumptions that limit the scope to network equipment (e.g.,
374 routers, switches and firewalls):
376 * This solution is for use in non-privacy-preserving applications
377 (for example, networking, Industrial IoT), avoiding the need for a
378 Privacy Certificate Authority (also called an Attestation CA) for
379 attestation keys [AK-Enrollment] or TCG Platform Certificates
380 [Platform-Certificates].
382 * This document assumes network protocols that are common in network
383 equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not
384 generally used in other applications.
386 * The approach outlined in this document mandates the use of a TPM
387 [TPM1.2], [TPM2.0], or a compatible cryptoprocessor.
389 1.7.1. Out of Scope
391 * Run-Time Attestation: The Linux Integrity Measurement Architecture
392 [IMA] attests each process launched after a device is started (and
393 is in scope for RIV in general), but continuous run-time
394 attestation of Linux or other multi-threaded operating system
395 processes after the OS has started considerably expands the scope
396 of the problem. Many researchers are working on that problem, but
397 this document defers the problem of continuous, in-memory run-time
398 attestation.
400 * Multi-Vendor Embedded Systems: Additional coordination would be
401 needed for devices that themselves comprise hardware and software
402 from multiple vendors, integrated by the end user. Although out
403 of scope for this document, these issues are accommodated in
404 [I-D.ietf-rats-architecture].
406 * Processor Sleep Modes: Network equipment typically does not
407 "sleep", so sleep and hibernate modes are not considered.
408 Although out of scope for RIV in this document, Trusted Computing
409 Group specifications do encompass sleep and hibernate states,
410 which could be incorporated into remote attestation for network
411 equipment in the future, given a compelling need.
413 * Virtualization and Containerization: In a non-virtualized system,
414 the host OS is responsible for measuring each User Space file or
415 process throughout the operational lifetime of the system. For
416 virtualized systems, the host OS must verify the hypervisor, but
417 then the hypervisor must manage its own chain of trust through the
418 virtual machine. Virtualization and containerization technologies
419 are increasingly used in network equipment, but are not considered
420 in this document.
422 2. Solution Overview
424 2.1. RIV Software Configuration Attestation using TPM
426 RIV Attestation is a process which can be used to determine the
427 identity of software running on a specifically-identified device.
428 The Remote Attestation steps of Section 1.5 are broken into two
429 phases, shown in Figure 1:
431 * During system startup, or boot phase, each distinct software
432 object is "measured" by the Attester. The object's identity, hash
433 (i.e., cryptographic digest) and version information are recorded
434 in a log. Hashes are also extended into the TPM (see Section 9.1
435 for more on 'extending hashes'), in a way that can be used to
436 validate the log entries. The measurement process generally
437 follows the layered chain-of-trust model used in Measured Boot,
438 where each stage of the system measures the next one, and extends
439 its measurement into the TPM, before launching it. See
440 [I-D.ietf-rats-architecture], section "Layered Attestation
441 Environments," for an architectural definition of this model.
443 * Once the device is running and has operational network
444 connectivity, verification can take place. A separate Verifier,
445 running in its own trusted environment, will interrogate the
446 network device to retrieve the logs and a copy of the digests
447 collected by hashing each software object, signed by an
448 attestation private key secured by, but never released by, the
449 TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra]
450 facilitates this operation.
452 The result is that the Verifier can verify the device's identity by
453 checking the subject[RFC5280] and signature of the certificate
454 containing the TPM's attestation public key, and can validate the
455 software that was launched by verifying the correctness of the logs
456 by comparing with the signed digests from the TPM, and comparing
457 digests in the log with Reference Values.
459 It should be noted that attestation and identity are inextricably
460 linked; signed Evidence that a particular version of software was
461 loaded is of little value without cryptographic proof of the identity
462 of the Attester producing the Evidence.
464 +-------------------------------------------------------+
465 | +---------+ +--------+ +--------+ +---------+ |
466 | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
467 | +---------+ +--------+ +--------+ +---------+ |
468 | | | | |
469 | | | | |
470 | +------------+-----------+-+ |
471 | Boot Phase | |
472 | V |
473 | +--------+ |
474 | | TPM | |
475 | +--------+ |
476 | Router | |
477 +--------------------------------|----------------------+
478 |
479 | Verification Phase
480 | +-----------+
481 +--->| Verifier |
482 +-----------+
484 Reset---------------flow-of-time-during-boot...--------->
486 Figure 1: Layered RIV Attestation Model
488 In the Boot phase, measurements are "extended", or hashed, into the
489 TPM as processes start, with the result that the TPM ends up
490 containing hashes of all the measured hashes. Later, once the system
491 is operational, during the Verification phase, signed digests are
492 retrieved from the TPM for off-box analysis.
494 2.1.1. What Does RIV Attest?
496 TPM attestation is focused on Platform Configuration Registers
497 (PCRs), but those registers are only vehicles for certifying
498 accompanying Evidence, conveyed in log entries. It is the hashes in
499 log entries that are extended into PCRs, where the final PCR values
500 can be retrieved in the form of a structure called a Quote, signed by
501 an Attestation key known only to the TPM. The use of multiple PCRs
502 serves only to provide some independence between different classes of
503 object, so that one class of objects can be updated without changing
504 the extended hash for other classes. Although PCRs can be used for
505 any purpose, this section outlines the objects within the scope of
506 this document which may be extended into the TPM.
508 In general, assignment of measurements to PCRs is a policy choice
509 made by the device manufacturer, selected to independently attest
510 three classes of object:
512 * Code, (i.e., instructions) to be executed by a CPU.
514 * Configuration - Many devices offer numerous options controlled by
515 non-volatile configuration variables which can impact the device's
516 security posture. These settings may have vendor defaults, but
517 often can be changed by administrators, who may want to verify via
518 attestation that the operational state of the settings match their
519 intended state.
521 * Credentials - Administrators may wish to verify via attestation
522 that public keys and credentials outside the Root of Trust have
523 not been subject to unauthorized tampering. (By definition, keys
524 protecting the root of trust can't be verified independently.)
526 The TCG PC Client Platform Firmware Profile Specification
527 [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be
528 measured during the boot phase of platform startup using a UEFI BIOS
529 (www.uefi.org), but the goal is simply to measure every bit of code
530 executed in the process of starting the device, along with any
531 configuration information related to security posture, leaving no gap
532 for unmeasured code to remain undetected, potentially subverting the
533 chain.
535 For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] and
536 [PC-Client-EFI-TPM-1.2] give detailed normative requirements for PCR
537 usage. For other platform architectures, where TCG normative
538 requirements currently do not exist, the table in Figure 2 gives non-
539 normative guidance for PCR assignment that generalizes the specific
540 details of [PC-Client-BIOS-TPM-2.0].
542 By convention, most PCRs are assigned in pairs, which the even-
543 numbered PCR used to measure executable code, and the odd-numbered
544 PCR used to measure whatever data and configuration are associated
545 with that code. It is important to note that each PCR may contain
546 results from dozens (or even thousands) of individual measurements.
548 +------------------------------------------------------------------+
549 | | Assigned PCR # |
550 | Function | Code | Configuration|
551 --------------------------------------------------------------------
552 | Firmware Static Root of Trust, (i.e., | 0 | 1 |
553 | initial boot firmware and drivers) | | |
554 --------------------------------------------------------------------
555 | Drivers and initialization for optional | 2 | 3 |
556 | or add-in devices | | |
557 --------------------------------------------------------------------
558 | OS Loader code and configuration, (i.e., | 4 | 5 |
559 | the code launched by firmware) to load an | | |
560 | operating system kernel. These PCRs record | | |
561 | each boot attempt, and an identifier for | | |
562 | where the loader was found | | |
563 --------------------------------------------------------------------
564 | Vendor Specific Measurements during boot | 6 | 6 |
565 --------------------------------------------------------------------
566 | Secure Boot Policy. This PCR records keys | | 7 |
567 | and configuration used to validate the OS | | |
568 | loader | | |
569 --------------------------------------------------------------------
570 | Measurements made by the OS Loader | 8 | 9 |
571 | (e.g GRUB2 for Linux) | | |
572 --------------------------------------------------------------------
573 | Measurements made by OS (e.g., Linux IMA) | 10 | 10 |
574 +------------------------------------------------------------------+
576 Figure 2: Attested Objects
578 2.1.2. Notes on PCR Allocations
580 It is important to recognize that PCR[0] is critical. The first
581 measurement into PCR[0] is taken by the Root of Trust for
582 Measurement, code which, by definition, cannot be verified by
583 measurement. This measurement establishes the chain of trust for all
584 subsequent measurements. If the PCR[0] measurement cannot be
585 trusted, the validity of the entire chain is put into question.
587 Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized
588 below:
590 * PCR[0] typically represents a consistent view of rarely-changed
591 Host Platform boot components, allowing Attestation policies to be
592 defined using the less changeable components of the transitive
593 trust chain. This PCR typically provides a consistent view of the
594 platform regardless of user selected options.
596 * PCR[2] is intended to represent a "user configurable" environment
597 where the user has the ability to alter the components that are
598 measured into PCR[2]. This is typically done by adding adapter
599 cards, etc., into user-accessible PCI or other slots. In UEFI
600 systems these devices may be configured by Option ROMs measured
601 into PCR[2] and executed by the UEFI BIOS.
603 * PCR[4] is intended to represent the software that manages the
604 transition between the platform's Pre-Operating System start and
605 the state of a system with the Operating System present. This
606 PCR, along with PCR[5], identifies the initial operating system
607 loader (e.g., GRUB for Linux).
609 * PCR[8] is used by the OS loader (e.g. GRUB) to record
610 measurements of the various components of the operating system.
612 Although the TCG PC Client document specifies the use of the first
613 eight PCRs very carefully to ensure interoperability among multiple
614 UEFI BIOS vendors, it should be noted that embedded software vendors
615 may have considerably more flexibility. Verifiers typically need to
616 know which log entries are consequential and which are not (possibly
617 controlled by local policies) but the Verifier may not need to know
618 what each log entry means or why it was assigned to a particular PCR.
619 Designers must recognize that some PCRs may cover log entries that a
620 particular Verifier considers critical and other log entries that are
621 not considered important, so differing PCR values may not on their
622 own constitute a check for authenticity. For example, in a UEFI
623 system, some administrators may consider booting an image from a
624 removable drive, something recorded in a PCR, to be a security
625 violation, while others might consider that operation an authorized
626 recovery procedure.
628 Designers may allocate particular events to specific PCRs in order to
629 achieve a particular objective with local attestation, (e.g.,
630 allowing a procedure to execute, or releasing a particular decryption
631 key, only if a given PCR is in a given state). It may also be
632 important to designers to consider whether streaming notification of
633 PCR updates is required (see
634 [I-D.birkholz-rats-network-device-subscription]). Specific log
635 entries can only be validated if the Verifier receives every log
636 entry affecting the relevant PCR, so (for example) a designer might
637 want to separate rare, high-value events such as configuration
638 changes, from high-volume, routine measurements such as IMA [IMA]
639 logs.
641 2.2. RIV Keying
643 RIV attestation relies on two credentials:
645 * An identity key pair and matching certificate is required to
646 certify the identity of the Attester itself. RIV specifies the
647 use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR],
648 signed by the device manufacturer, containing the device serial
649 number. This requirement goes slightly beyond 802.1AR; see
650 Section 2.4 for notes.
652 * An Attestation key pair and matching certificate is required to
653 sign the Quote generated by the TPM to report evidence of software
654 configuration.
656 In a TPM application, both the Attestation private key and the DevID
657 private key MUST be protected by the TPM. Depending on other TPM
658 configuration procedures, the two keys are likely to be different;
659 some of the considerations are outlined in TCG "TPM 2.0 Keys for
660 Device Identity and Attestation" [Platform-DevID-TPM-2.0].
662 The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies
663 further conventions for these keys:
665 * When separate Identity and Attestation keys are used, the
666 Attestation Key (AK) and its X.509 certificate should parallel the
667 DevID, with the same unique device identification as the DevID
668 certificate (that is, the same subject and subjectAltName (if
669 present), even though the key pairs are different). This allows a
670 quote from the device, signed by an AK, to be linked directly to
671 the device that provided it, by examining the corresponding AK
672 certificate. If the subject in the AK certificate doesn't match
673 the corresponding DevID certificate, or they're signed by
674 differing authorities the Verifier may signal the detection of an
675 Asokan-style person-in-the-middle attack (see Section 5.2).
677 * Network devices that are expected to use secure zero touch
678 provisioning as specified in [RFC8572] MUST be shipped by the
679 manufacturer with pre-provisioned keys (Initial DevID and Initial
680 AK, called IDevID and IAK). IDevID and IAK certificates MUST both
681 be signed by the Endorser (typically the device manufacturer).
682 Inclusion of an IDevID and IAK by a vendor does not preclude a
683 mechanism whereby an administrator can define Local Identity and
684 Attestation Keys (LDevID and LAK) if desired.
686 2.3. RIV Information Flow
688 RIV workflow for network equipment is organized around a simple use
689 case where a network operator wishes to verify the integrity of
690 software installed in specific, fielded devices. A normative
691 taxonomy of terms is given in [I-D.ietf-rats-architecture], but as a
692 reminder, this use case implies several roles and objects:
694 1. The Attester, the device which the network operator wants to
695 examine.
697 2. A Verifier (which might be a network management station)
698 somewhere separate from the Device that will retrieve the signed
699 evidence and measurement logs, and analyze them to pass judgment
700 on the security posture of the device.
702 3. A Relying Party, which can act on Attestation Results.
703 Interaction between the Relying Party and the Verifier is
704 considered out of scope for RIV.
706 4. Signed Reference Integrity Manifests (RIMs), containing Reference
707 Values, can either be created by the device manufacturer and
708 shipped along with the device as part of its software image, or
709 alternatively, could be obtained several other ways (direct to
710 the Verifier from the manufacturer, from a third party, from the
711 owner's observation of what's thought to be a "known good
712 system", etc.). Retrieving RIMs from the device itself allows
713 attestation to be done in systems that may not have access to the
714 public internet, or by other devices that are not management
715 stations per se (e.g., a peer device; see Section 3.1.3). If
716 Reference Values are obtained from multiple sources, the Verifier
717 may need to evaluate the relative level of trust to be placed in
718 each source in case of a discrepancy.
720 These components are illustrated in Figure 3.
722 +----------------+ +-------------+ +---------+--------+
723 |Reference Value | | Attester | Step 1 | Verifier| |
724 |Provider | | (Device |<-------| (Network| Relying|
725 |(Device | | under |------->| Mngmt | Party |
726 |Manufacturer | | attestation)| Step 2 | Station)| |
727 |or other | | | | | |
728 |authority) | | | | | |
729 +----------------+ +-------------+ +---------+--------+
730 | /\
731 | Step 0 |
732 -----------------------------------------------
734 Figure 3: RIV Reference Configuration for Network Equipment
736 * In Step 0, The Reference Value Provider (the device manufacturer
737 or other authority) makes one or more Reference Integrity
738 Manifests (RIMs), corresponding to the software image expected to
739 be found on the device, signed by the Reference Value Provider,
740 available to the Verifier (see Section 3.1.3 for "in-band" and
741 "out of band" ways to make this happen).
743 * In Step 1, the Verifier (Network Management Station), on behalf of
744 a Relying Party, requests Identity, Measurement Values, and
745 possibly RIMs, from the Attester.
747 * In Step 2, the Attester responds to the request by providing a
748 DevID, quotes (measured values, signed by the Attester), and
749 optionally RIMs.
751 Use of the following standards components allows for
752 interoperability:
754 1. TPM Keys MUST be configured according to
755 [Platform-DevID-TPM-2.0], or [Platform-ID-TPM-1.2].
757 2. For devices using UEFI and Linux, measurements of firmware and
758 bootable modules MUST be taken according to TCG PC Client
759 [PC-Client-EFI-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux
760 IMA [IMA].
762 3. Device Identity MUST be managed as specified in IEEE 802.1AR
763 Device Identity certificates [IEEE-802-1AR], with keys protected
764 by TPMs.
766 4. Attestation logs from Linux-based systems MUST be formatted
767 according to the Canonical Event Log format
768 [Canonical-Event-Log]. UEFI-based systems MUST use the TCG UEFI
769 BIOS event log [PC-Client-EFI-TPM-1.2] for TPM1.2 systems, and
770 TCG PC Client Platform Firmware Profile [PC-Client-BIOS-TPM-2.0]
771 for TPM2.0.
773 5. Quotes MUST be retrieved from the TPM according to TCG TAP
774 Information Model [TAP] and the CHARRA YANG model
775 [I-D.ietf-rats-yang-tpm-charra]. While the TAP IM gives a
776 protocol-independent description of the data elements involved,
777 it's important to note that quotes from the TPM are signed inside
778 the TPM, and MUST be retrieved in a way that does not invalidate
779 the signature, to preserve the trust model. The
780 [I-D.ietf-rats-yang-tpm-charra] is used for this purpose. (See
781 Section 5 Security Considerations).
783 6. Reference Values MUST be encoded as defined in the TCG RIM
784 document [RIM], typically using SWID [SWID], [NIST-IR-8060] or
785 CoSWID tags [I-D.ietf-sacm-coswid].
787 2.4. RIV Simplifying Assumptions
789 This document makes the following simplifying assumptions to reduce
790 complexity:
792 * The product to be attested MUST be shipped by the equipment vendor
793 with both an IEEE 802.1AR Device Identity and an Initial
794 Attestation Key (IAK), with certificates in place. The IAK
795 certificate must contain the same identity information as the
796 DevID (specifically, the same subject and subjectAltName (if
797 used), signed by the manufacturer). The IAK is a type of key that
798 can be used to sign a TPM Quote, but not other objects (i.e., it's
799 marked as a TCG "Restricted" key; this convention is described in
800 "TPM 2.0 Keys for Device Identity and Attestation"
801 [Platform-DevID-TPM-2.0]). For network equipment, which is
802 generally non-privacy-sensitive, shipping a device with both an
803 IDevID and an IAK already provisioned substantially simplifies
804 initial startup.
806 * IEEE 802.1AR does not require a product serial number as part of
807 the subject, but RIV-compliant devices MUST include their serial
808 numbers in the DevID/IAK certificates to simplify tracking
809 logistics for network equipment users. All other optional 802.1AR
810 fields remain optional in RIV.
812 It should be noted that 802.1AR use of X.509 certificate fields is
813 not identical to those descsribed in [RFC6125] for representation
814 of application service identity.
816 * The product MUST be equipped with a Root of Trust for Measurement
817 (RTM), Root of Trust for Storage and Root of Trust for Reporting
818 (as defined in [SP800-155]) which together are capable of
819 conforming to TCG Trusted Attestation Protocol Information Model
820 [TAP].
822 * The authorized software supplier MUST make available Reference
823 Values in the form of signed SWID or CoSWID tags.
825 2.4.1. Reference Integrity Manifests (RIMs)
827 [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and
828 transmitting evidence in the form of PCR measurements and attestation
829 logs. But the critical part of the process is enabling the Verifier
830 to decide whether the measurements are "the right ones" or not.
832 While it must be up to network administrators to decide what they
833 want on their networks, the software supplier should supply the
834 Reference Values, in signed Reference Integrity Manifests, that may
835 be used by a Verifier to determine if evidence shows known good,
836 known bad or unknown software configurations.
838 In general, there are two kinds of reference measurements:
840 1. Measurements of early system startup (e.g., BIOS, boot loader, OS
841 kernel) are essentially single-threaded, and executed exactly
842 once, in a known sequence, before any results could be reported.
843 In this case, while the method for computing the hash and
844 extending relevant PCRs may be complicated, the net result is
845 that the software (more likely, firmware) vendor will have one
846 known good PCR value that "should" be present in the relevant
847 PCRs after the box has booted. In this case, the signed
848 reference measurement could simply list the expected hashes for
849 the given version. However, a RIM that contains the intermediate
850 hashes can be useful in debugging cases where the expected final
851 hash is not the one reported.
853 2. Measurements taken later in operation of the system, once an OS
854 has started (for example, Linux IMA [IMA]), may be more complex,
855 with unpredictable "final" PCR values. In this case, the
856 Verifier must have enough information to reconstruct the expected
857 PCR values from logs and signed reference measurements from a
858 trusted authority.
860 In both cases, the expected values can be expressed as signed SWID or
861 CoSWID tags, but the SWID structure in the second case is somewhat
862 more complex, as reconstruction of the extended hash in a PCR may
863 involve thousands of files and other objects.
865 TCG has published an information model defining elements of Reference
866 Integrity Manifests under the title TCG Reference Integrity Manifest
867 Information Model [RIM]. This information model outlines how SWID
868 tags should be structured to allow attestation, and defines "bundles"
869 of SWID tags that may be needed to describe a complete software
870 release. The RIM contains metadata relating to the software release
871 it belongs to, plus hashes for each individual file or other object
872 that could be attested.
874 Many network equipment vendors use a UEFI BIOS to launch their
875 network operating system. These vendors may want to also use the TCG
876 PC Client Reference Integrity Measurement specification
877 [PC-Client-RIM], which focuses specifically on a SWID-compatible
878 format suitable for expressing measurement values expected from a
879 UEFI BIOS.
881 2.4.2. Attestation Logs
883 Quotes from a TPM can provide evidence of the state of a device up to
884 the time the evidence was recorded, but to make sense of the quote in
885 cases where several events are extended into one PCR an event log
886 that identifies which software modules contributed which values to
887 the quote during startup must also be provided. When required, the
888 log MUST contain enough information to demonstrate its integrity by
889 allowing exact reconstruction of the digest conveyed in the signed
890 quote (that is, calculating the hash of all the hashes in the log
891 should produce the same values as contained in the PCRs; if they
892 don't match, the log may have been tampered with. See Section 9.1).
894 There are multiple event log formats which may be supported as viable
895 formats of Evidence between the Attester and Verifier, but to
896 simplify interoperability, RIV focuses on just three:
898 * TCG UEFI BIOS event log for TPM 2.0 (TCG PC Client Platform
899 Firmware Profile) [PC-Client-BIOS-TPM-2.0]
901 * TCG UEFI BIOS event log for TPM 1.2 (TCG EFI Platform
902 Specification for TPM Family 1.1 or 1.2, Section 7)
903 [PC-Client-EFI-TPM-1.2]
905 * TCG Canonical Event Log [Canonical-Event-Log]
907 3. Standards Components
909 3.1. Prerequisites for RIV
911 The Reference Interaction Model for Challenge-Response-based Remote
912 Attestation ([I-D.birkholz-rats-reference-interaction-model]) is
913 based on the standard roles defined in [I-D.ietf-rats-architecture].
914 However additional prerequisites have been established to allow for
915 interoperable RIV use case implementations. These prerequisites are
916 intended to provide sufficient context information so that the
917 Verifier can acquire and evaluate measurements collected by the
918 Attester.
920 3.1.1. Unique Device Identity
922 A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID
923 certificate [IEEE-802-1AR] must be provisioned in the Attester's
924 TPMs.
926 3.1.2. Keys
928 The Attestation Key (AK) and certificate must also be provisioned on
929 the Attester according to [Platform-DevID-TPM-2.0], or
930 [Platform-ID-TPM-1.2].
932 It MUST be possible for the Verifier to determine that the Attester's
933 Attestation keys are resident in the same TPM as its DevID keys (see
934 Section 2.2 and Section 5 Security Considerations).
936 3.1.3. Appraisal Policy for Evidence
938 As noted in Section 2.3, the Verifier may obtain Reference Values
939 from several sources. In addition, administrators may make
940 authorized, site-specific changes (e.g. keys in key databases) that
941 could impact attestation results. As such, there could be conflicts,
942 omissions or ambiguities between some Reference Values and collected
943 Evidence.
945 The Verifier MUST have an Appraisal Policy for Evidence to evaluate
946 the significance of any discrepancies between different reference
947 sources, or between reference values and evidence from logs and
948 quotes. While there must be an Appraisal Policy, this document does
949 not specify the format or mechanism to convey the intended policy,
950 nor does RIV specify mechanisms by which the results of applying the
951 policy are communicated to the Relying Party.
953 3.2. Reference Model for Challenge-Response
955 Once the prerequisites for RIV are met, a Verifier is able to acquire
956 Evidence from an Attester. The following diagram illustrates a RIV
957 information flow between a Verifier and an Attester, derived from
958 Section 7.1 of [I-D.birkholz-rats-reference-interaction-model]. In
959 this diagram, each event with its input and output parameters is
960 shown as "Event(input-params)=>(outputs)". Event times shown
961 correspond to the time types described within Appendix A of
962 [I-D.ietf-rats-architecture]:
964 .----------. .-----------------------.
965 | Attester | | Relying Party/Verifier |
966 '----------' '------------------------'
967 time(VG) |
968 generateClaims(attestingEnvironment) |
969 | => claims, eventLogs |
970 | |
971 | time(NS)
972 | <-- requestAttestation(handle, authSecIDs, claimSelection) |
973 | |
974 time(EG) |
975 collectClaims(claims, claimSelection) |
976 | => collectedClaims |
977 | |
978 generateEvidence(handle, authSecIDs, collectedClaims) |
979 | => evidence |
980 | time(RG,RA)
981 | evidence, eventLogs -------------------------------------> |
982 | |
983 | appraiseEvidence(evidence, eventLogs, refValues)
984 | attestationResult <= |
985 | |
986 ~ ~
987 | time(RX)
989 Figure 4: IETF Attestation Information Flow
991 * Step 1 (time(VG)): One or more Attesting Network Device PCRs are
992 extended with measurements. RIV provides no direct link between
993 the time at which the event takes place and the time that it's
994 attested, although streaming attestation as in
995 [I-D.birkholz-rats-network-device-subscription] could.
997 * Step 2 (time(NS)): The Verifier generates a unique random nonce
998 ("number used once"), and makes a request for one or more PCRs
999 from an Attester. For interoperability, this must be accomplished
1000 as specified in the YANG Data Model for Challenge-Response-based
1001 Remote Attestation Procedures using TPMs
1002 [I-D.ietf-rats-yang-tpm-charra]. TPM1.2 and TPM2.0 both allow
1003 nonces as large as the operative digest size (i.e., 20 or 32
1004 bytes; see [TPM1.2] Part 2, Section 5.5 and [TPM2.0] Part 2,
1005 Section 10.4.4).
1007 * Step 3 (time(EG)): On the Attester, measured values are retrieved
1008 from the Attester's TPM. This requested PCR evidence, along with
1009 the Verifier's nonce, called a Quote, is signed by the Attestation
1010 Key (AK) associated with the DevID. Quotes are retrieved
1011 according to CHARRA YANG model [I-D.ietf-rats-yang-tpm-charra].
1013 At the same time, the Attester collects log evidence showing the
1014 values have been extended into that PCR. Section 9.1 gives more
1015 detail on how this works, including references to the structure
1016 and contents of quotes in TPM documents.
1018 * Step 4: Collected Evidence is passed from the Attester to the
1019 Verifier
1021 * Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes
1022 action as needed. As the interaction between Relying Party and
1023 Verifier is out of scope for RIV, this can be described as one
1024 step.
1026 - If the signature covering TPM Evidence is not correct, the
1027 device SHOULD NOT be trusted.
1029 - If the nonce in the response doesn't match the Verifier's
1030 nonce, the response may be a replay, and device SHOULD NOT be
1031 trusted.
1033 - If the signed PCR values do not match the set of log entries
1034 which have extended a particular PCR, the device SHOULD NOT be
1035 trusted.
1037 - If the log entries that the Verifier considers important do not
1038 match known good values, the device SHOULD NOT be trusted. We
1039 note that the process of collecting and analyzing the log can
1040 be omitted if the value in the relevant PCR is already a known-
1041 good value.
1043 - If the set of log entries are not seen as acceptable by the
1044 Appraisal Policy for Evidence, the device SHOULD NOT be
1045 trusted.
1047 - If time(RG)-time(NS) is greater than the Appraisal Policy for
1048 Evidence's threshold for assessing freshness, the Evidence is
1049 considered stale and SHOULD NOT be trusted.
1051 3.2.1. Transport and Encoding
1053 Network Management systems may retrieve signed PCR based Evidence
1054 using NETCONF or RESTCONF with [I-D.ietf-rats-yang-tpm-charra]. In
1055 either case, implementatations must do so using a secure tunnel.
1057 Log Evidence MUST be retrieved via log interfaces specified in
1058 [I-D.ietf-rats-yang-tpm-charra].
1060 3.3. Centralized vs Peer-to-Peer
1062 Figure 4 above assumes that the Verifier is trusted, while the
1063 Attester is not. In a Peer-to-Peer application such as two routers
1064 negotiating a trust relationship, the two peers can each ask the
1065 other to prove software integrity. In this application, the
1066 information flow is the same, but each side plays a role both as an
1067 Attester and a Verifier. Each device issues a challenge, and each
1068 device responds to the other's challenge, as shown in Figure 5.
1069 Peer-to-peer challenges, particularly if used to establish a trust
1070 relationship between routers, require devices to carry their own
1071 signed reference measurements (RIMs). Devices may also have to carry
1072 Appraisal Policy for Evidence for each possible peer device so that
1073 each device has everything needed for remote attestation, without
1074 having to resort to a central authority. Details of peer-to-peer
1075 operation are out of scope for this document.
1077 +---------------+ +---------------+
1078 | RefVal | | RefVal |
1079 | Provider A | | Provider B |
1080 | Firmware | | Firmware |
1081 | Configuration | | Configuration |
1082 | Authority | | Authority |
1083 | | | |
1084 +---------------+ +---------------+
1085 | |
1086 | |Step 0B
1087 | +------------+ +------------+ |
1088 | | | Step 1 | | | \
1089 | | Attester |<------>| Verifier | | |
1090 | | |<------>| | | | Router B
1091 +------>| | Step 2 | | | |- Challenges
1092 Step 0A| | | | | | Router A
1093 | |------->| | | |
1094 |- Router A -| Step 3 |- Router B -| | /
1095 | | | | |
1096 | | | | |
1097 | | Step 1 | | | \
1098 | Verifier |<------>| Attester |<-+ | Router A
1099 | |<------>| | |- Challenges
1100 | | Step 2 | | | Router B
1101 | | | | |
1102 | |<-------| | |
1103 +------------+ Step 3 +------------+ /
1105 Figure 5: Peer-to-Peer Attestation Information Flow
1107 In this application, each device may need to be equipped with signed
1108 RIMs to act as an Attester, and also an Appraisal Policy for Evidence
1109 and a selection of trusted X.509 root certificates, to allow the
1110 device to act as a Verifier. An existing link layer protocol such as
1111 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being
1112 enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable
1113 methods for such an exchange.
1115 4. Privacy Considerations
1117 Network equipment, such as routers, switches and firewalls, has a key
1118 role to play in guarding the privacy of individuals using the
1119 network. Network equipment generally adheres to several rules to
1120 protect privacy:
1122 * Packets passing through the device must not be sent to
1123 unauthorized destinations. For example:
1125 - Routers often act as Policy Enforcement Points, where
1126 individual subscribers may be checked for authorization to
1127 access a network. Subscriber login information must not be
1128 released to unauthorized parties.
1130 - Network equipment is often called upon to block access to
1131 protected resources from unauthorized users.
1133 * Routing information, such as the identity of a router's peers,
1134 must not be leaked to unauthorized neighbors.
1136 * If configured, encryption and decryption of traffic must be
1137 carried out reliably, while protecting keys and credentials.
1139 Functions that protect privacy are implemented as part of each layer
1140 of hardware and software that makes up the networking device. In
1141 light of these requirements for protecting the privacy of users of
1142 the network, the network equipment must identify itself, and its boot
1143 configuration and measured device state (for example, PCR values), to
1144 the equipment's administrator, so there's no uncertainty as to what
1145 function each device and configuration is configured to carry out.
1146 Attestation is a component that allows the administrator to ensure
1147 that the network provides individual and peer privacy guarantees,
1148 even though the device itself may not have a right to keep its
1149 identity secret.
1151 See [NetEq] for more context on privacy in networking devices.
1153 While attestation information from network devices is not likely to
1154 contain privacy-sensitive content regarding network users,
1155 administrators may want to keep attestation records confidential to
1156 avoid disclosing versions of software loaded on the device,
1157 information which could facilitate attacks against known
1158 vulnerabilities.
1160 5. Security Considerations
1162 Specifications such as [RFC8446] (TLS) and [RFC7950] (YANG) contain
1163 considerable advice on keeping network-connected systems secure.
1164 This section outlines specific risks and mitigations related to
1165 attestation.
1167 Attestation Evidence obtained by the RIV procedure is subject to a
1168 number of attacks:
1170 * Keys may be compromised.
1172 * A counterfeit device may attempt to impersonate (spoof) a known
1173 authentic device.
1175 * Person-in-the-middle attacks may be used by a compromised device
1176 to attempt to deliver responses that originate in an authentic
1177 device.
1179 * Replay attacks may be attempted by a compromised device.
1181 5.1. Keys Used in RIV
1183 Trustworthiness of RIV attestation depends strongly on the validity
1184 of keys used for identity and attestation reports. RIV takes full
1185 advantage of TPM capabilities to ensure that evidence can be trusted.
1187 Two sets of key-pairs are relevant to RIV attestation:
1189 * A DevID key-pair is used to certify the identity of the device in
1190 which the TPM is installed.
1192 * An Attestation Key-pair (AK) key is used to certify attestation
1193 Evidence (called 'quotes' in TCG documents), used to provide
1194 evidence for integrity of the software on the device
1196 TPM practices usually require that these keys be different, as a way
1197 of ensuring that a general-purpose signing key cannot be used to
1198 spoof an attestation quote.
1200 In each case, the private half of the key is known only to the TPM,
1201 and cannot be retrieved externally, even by a trusted party. To
1202 ensure that's the case, specification-compliant private/public key-
1203 pairs are generated inside the TPM, where they are never exposed, and
1204 cannot be extracted (See [Platform-DevID-TPM-2.0]).
1206 Keeping keys safe is a critical enabler of trustworthiness, but it's
1207 just part of attestation security; knowing which keys are bound to
1208 the device in question is just as important in an environment where
1209 private keys are never exposed.
1211 While there are many ways to manage keys in a TPM (see
1212 [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch"
1213 provisioning (also known as zero-touch onboarding) of fielded devices
1214 (e.g., Secure ZTP, [RFC8572]), where keys which have predictable
1215 trust properties are provisioned by the device vendor.
1217 Device identity in RIV is based on IEEE 802.1AR Device Identity
1218 (DevID). This specification provides several elements:
1220 * A DevID requires a unique key pair for each device, accompanied by
1221 an X.509 certificate,
1223 * The private portion of the DevID key is to be stored in the
1224 device, in a manner that provides confidentiality (Section 6.2.5
1225 [IEEE-802-1AR])
1227 The X.509 certificate contains several components:
1229 * The public part of the unique DevID key assigned to that device
1230 allows a challenge of identity.
1232 * An identifying string that's unique to the manufacturer of the
1233 device. This is normally the serial number of the unit, which
1234 might also be printed on a label on the device.
1236 * The certificate must be signed by a key traceable to the
1237 manufacturer's root key.
1239 With these elements, the device's manufacturer and serial number can
1240 be identified by analyzing the DevID certificate plus the chain of
1241 intermediate certificates leading back to the manufacturer's root
1242 certificate. As is conventional in TLS or SSH connections, a random
1243 nonce must be signed by the device in response to a challenge,
1244 proving possession of its DevID private key.
1246 RIV uses the DevID to validate a TLS or SSH connection to the device
1247 as the attestation session begins. Security of this process derives
1248 from TLS or SSH security, with the DevID, containing a device serial
1249 number, providing proof that the session terminates on the intended
1250 device. See [RFC8446], [RFC4253].
1252 Evidence of software integrity is delivered in the form of a quote
1253 signed by the TPM itself, accompanied by an IAK certificate
1254 containing the same identity information as the DevID. Because the
1255 contents of the quote are signed inside the TPM, any external
1256 modification (including reformatting to a different data format)
1257 after measurements have been taken will be detected as tampering. An
1258 unbroken chain of trust is essential to ensuring that blocks of code
1259 that are taking measurements have been verified before execution (see
1260 Figure 1).
1262 Requiring measurements of the operating software to be signed by a
1263 key known only to the TPM also removes the need to trust the device's
1264 operating software (beyond the first measurement in the RTM; see
1265 below); any changes to the quote, generated and signed by the TPM
1266 itself, made by malicious device software, or in the path back to the
1267 Verifier, will invalidate the signature on the quote.
1269 A critical feature of the YANG model described in
1270 [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data
1271 structures in their native format, without requiring any changes to
1272 the structures as they were signed and delivered by the TPM. While
1273 alternate methods of conveying TPM quotes could compress out
1274 redundant information, or add an additional layer of signing using
1275 external keys, the implementation MUST preserve the TPM signing, so
1276 that tampering anywhere in the path between the TPM itself and the
1277 Verifier can be detected.
1279 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks
1281 Prevention of spoofing attacks against attestation systems is also
1282 important. There are several cases to consider:
1284 * The entire device could be spoofed. If the Verifier goes to
1285 appraise a specific Attester, it might be redirected to a
1286 different Attester.
1288 * A compromised device could have a valid DevID, but substitute a
1289 quote from a knonwn-good device, instead of returning its own, as
1290 described in [RFC6813].
1292 * A device with a compromised OS could return a fabricated quote
1293 providing spoofed attestation Evidence.
1295 Use of the 802.1AR Device Identity (DevID) in the TPM provides
1296 protection against the case of a spoofed device, by ensuring that the
1297 Verifier's TLS or SSH session is in fact terminating on the right
1298 device.
1300 Protection against spoofed quotes from a device with valid identity
1301 is a bit more complex. An identity key must be available to sign any
1302 kind of nonce or hash offered by the Verifier, and consequently,
1303 could be used to sign a fabricated quote. To block a spoofed
1304 Attestation Result, the quote generated inside the TPM must be signed
1305 by a key that's different from the DevID, called an Attestation Key
1306 (AK).
1308 Given separate Attestation and DevID keys, the binding between the AK
1309 and the same device must also be proven to prevent a person-in-the-
1310 middle attack (e.g., the 'Asokan Attack' [RFC6813]).
1312 This is accomplished in RIV through use of an AK certificate with the
1313 same elements as the DevID (same manufacturer's serial number, signed
1314 by the same manufacturer's key), but containing the device's unique
1315 AK public key instead of the DevID public key. This binding between
1316 DevID and AK certificates is critical to reliable attestation.
1318 The TCG document TPM 2.0 Keys for Device Identity and Attestation
1319 [Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates
1320 that allow the CA to mark a key as specifically known to be an
1321 Attestation key.
1323 These two key-pairs and certificates are used together:
1325 * The DevID is used to validate a TLS connection terminating on the
1326 device with a known serial number.
1328 * The AK is used to sign attestation quotes, providing proof that
1329 the attestation evidence comes from the same device.
1331 5.3. Replay Attacks
1333 Replay attacks, where results of a previous attestation are submitted
1334 in response to subsequent requests, are usually prevented by
1335 inclusion of a random nonce in the request to the TPM for a quote.
1336 Each request from the Verifier includes a new random number (a
1337 nonce). The resulting quote signed by the TPM contains the same
1338 nonce, allowing the Verifier to determine freshness, (i.e., that the
1339 resulting quote was generated in response to the Verifier's specific
1340 request). Time-Based Uni-directional Attestation
1341 [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify
1342 freshness without requiring a request/response cycle.
1344 5.4. Owner-Signed Keys
1346 Although device manufacturers must pre-provision devices with easily
1347 verified DevID and AK certificates if zero-touch provisioning such as
1348 described in [RFC8572] is to be supported, use of those credentials
1349 is not mandatory. IEEE 802.1AR incorporates the idea of an Initial
1350 Device ID (IDevID), provisioned by the manufacturer, and a Local
1351 Device ID (LDevID) provisioned by the owner of the device. RIV and
1352 [Platform-DevID-TPM-2.0] extends that concept by defining an Initial
1353 Attestation Key (IAK) and Local Attestation Key (LAK) with the same
1354 properties.
1356 Device owners can use any method to provision the Local credentials.
1358 * TCG document [Platform-DevID-TPM-2.0] shows how the initial
1359 Attestation keys can be used to certify LDevID and LAK keys. Use
1360 of the LDevID and LAK allows the device owner to use a uniform
1361 identity structure across device types from multiple manufacturers
1362 (in the same way that an "Asset Tag" is used by many enterprises
1363 to identify devices they own). TCG document
1364 [Provisioning-TPM-2.0] also contains guidance on provisioning
1365 Local identity keys in TPM 2.0. Owners should follow the same
1366 practice of binding Local DevID and Local AK as the manufacturer
1367 would for IDevID and IAK. See Section Section 2.2.
1369 * Device owners, however, can use any other mechanism they want to
1370 assure themselves that local identity certificates are inserted
1371 into the intended device, including physical inspection and
1372 programming in a secure location, if they prefer to avoid placing
1373 trust in the manufacturer-provided keys.
1375 Clearly, local keys can't be used for secure Zero Touch provisioning;
1376 installation of the local keys can only be done by some process that
1377 runs before the device is installed for network operation, or using
1378 procedures such as those outlined in Bootstrapping Remote Secure Key
1379 Infrastructure (BRSKI) [RFC8995].
1381 On the other end of the device life cycle, provision should be made
1382 to wipe local keys when a device is decommissioned, to indicate that
1383 the device is no longer owned by the enterprise. The manufacturer's
1384 Initial identity keys must be preserved, as they contain no
1385 information that's not already printed on the device's serial number
1386 plate.
1388 5.5. Other Factors for Trustworthy Operation
1390 In addition to trustworthy provisioning of keys, RIV depends on a
1391 number of other factors for trustworthy operation.
1393 * Secure identity depends on mechanisms to prevent per-device secret
1394 keys from being compromised. The TPM provides this capability as
1395 a Root of Trust for Storage.
1397 * Attestation depends on an unbroken chain of measurements, starting
1398 from the very first measurement. See Section 9.1 for background
1399 on TPM practices.
1401 * That first measurement is made by code called the Root of Trust
1402 for Measurement, typically done by trusted firmware stored in boot
1403 flash. Mechanisms for maintaining the trustworthiness of the RTM
1404 are out of scope for RIV, but could include immutable firmware,
1405 signed updates, or a vendor-specific hardware verification
1406 technique. See Section 9.2 for background on roots of trust.
1408 * The device owner SHOULD provide some level of physical defense for
1409 the device. If a TPM that has already been programmed with an
1410 authentic DevID is stolen and inserted into a counterfeit device,
1411 attestation of that counterfeit device may become
1412 indistinguishable from an authentic device.
1414 RIV also depends on reliable Reference Values, as expressed by the
1415 RIM [RIM]. The definition of trust procedures for RIMs is out of
1416 scope for RIV, and the device owner is free to use any policy to
1417 validate a set of reference measurements. It should also be noted
1418 that, while RIV can provide a reliable indication that a known
1419 software package is in use by the device, and that the package has
1420 not been tampered, it is the device owner's responsibility to
1421 determine that it's the correct package for the application.
1423 RIMs may be conveyed out-of-band or in-band, as part of the
1424 attestation process (see Section 3.1.3). But for network devices,
1425 where software is usually shipped as a self-contained package, RIMs
1426 signed by the manufacturer and delivered in-band may be more
1427 convenient for the device owner.
1429 The validity of RIV attestation results is also influenced by
1430 procedures used to create Reference Values:
1432 * While the RIM itself is signed, supply-chains SHOULD be carefully
1433 scrutinized to ensure that the values are not subject to
1434 unexpected manipulation prior to signing. Insider-attacks against
1435 code bases and build chains are particularly hard to spot.
1437 * Designers SHOULD guard against hash collision attacks. Reference
1438 Integrity Manifests often give hashes for large objects of
1439 indeterminate size; if one of the measured objects can be replaced
1440 with an implant engineered to produce the same hash, RIV will be
1441 unable to detect the substitution. TPM1.2 uses SHA-1 hashes only,
1442 which have been shown to be susceptible to collision attack.
1443 TPM2.0 will produce quotes with SHA-256, which so far has resisted
1444 such attacks. Consequently, RIV implementations SHOULD use
1445 TPM2.0.
1447 6. IANA Considerations
1449 This document has no IANA actions.
1451 7. Conclusion
1453 TCG technologies can play an important part in the implementation of
1454 Remote Integrity Verification. Standards for many of the components
1455 needed for implementation of RIV already exist:
1457 * Platform identity can be based on IEEE 802.1AR Device Identity,
1458 coupled with careful supply-chain management by the manufacturer.
1460 * Complex supply chains can be certified using TCG Platform
1461 Certificates [Platform-Certificates].
1463 * The TCG TAP mechanism coupled with [I-D.ietf-rats-yang-tpm-charra]
1464 can be used to retrieve attestation evidence.
1466 * Reference Values must be conveyed from the software authority
1467 (e.g., the manufacturer) in Reference Integrity Manifests, to the
1468 system in which verification will take place. IETF and TCG SWID
1469 and CoSWID work ([I-D.ietf-sacm-coswid], [RIM]) forms the basis
1470 for this function.
1472 8. Acknowledgements
1474 The authors wish to thank numerous reviewers for generous assistance,
1475 including William Bellingrath, Mark Baushke, Ned Smith, Henk
1476 Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas
1477 Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty,
1478 Nancy Cam-Winget and Shwetha Bhandari
1480 9. Appendix
1482 9.1. Using a TPM for Attestation
1484 The Trusted Platform Module and surrounding ecosystem provide three
1485 interlocking capabilities to enable secure collection of evidence
1486 from a remote device, Platform Configuration Registers (PCRs), a
1487 Quote mechanism, and a standardized Event Log.
1489 Each TPM has at least eight and at most twenty-four PCRs (depending
1490 on the profile and vendor choices), each one large enough to hold one
1491 hash value (SHA-1, SHA-256, and other hash algorithms can be used,
1492 depending on TPM version). PCRs can't be accessed directly from
1493 outside the chip, but the TPM interface provides a way to "extend" a
1494 new security measurement hash into any PCR, a process by which the
1495 existing value in the PCR is hashed with the new security measurement
1496 hash, and the result placed back into the same PCR. The result is a
1497 composite fingerprint comprising the hash of all the security
1498 measurements extended into each PCR since the system was reset.
1500 Every time a PCR is extended, an entry should be added to the
1501 corresponding Event Log. Logs contain the security measurement hash
1502 plus informative fields offering hints as to which event generated
1503 the security measurement. The Event Log itself is protected against
1504 accidental manipulation, but it is implicitly tamper-evident - any
1505 verification process can read the security measurement hash from the
1506 log events, compute the composite value and compare that to what
1507 ended up in the PCR. If there's no discrepancy, the logs do provide
1508 an accurate view of what was placed into the PCR.
1510 Note that the composite hash-of-hashes recorded in PCRs is order-
1511 dependent, resulting in different PCR values for different ordering
1512 of the same set of events (e.g. Event A followed by Event B yields a
1513 different PCR value than B followed by A). For single-threaded code,
1514 where both the events and their order are fixed, a Verifier may
1515 validate a single PCR value, and use the log only to diagnose a
1516 mismatch from Reference Values. However, operating system code is
1517 usually non-deterministic, meaning that there may never be a single
1518 "known good" PCR value. In this case, the Verifier may have to
1519 verify that the log is correct, and then analyze each item in the log
1520 to determine if it represents an authorized event.
1522 In a conventional TPM Attestation environment, the first measurement
1523 must be made and extended into the TPM by trusted device code (called
1524 the Root of Trust for Measurement, RTM). That first measurement
1525 should cover the segment of code that is run immediately after the
1526 RTM, which then measures the next code segment before running it, and
1527 so on, forming an unbroken chain of trust. See [TCGRoT] for more on
1528 Mutable vs Immutable roots of trust.
1530 The TPM provides another mechanism called a Quote that can read the
1531 current value of the PCRs and package them, along with the Verifier's
1532 nonce, into a TPM-specific data structure signed by an Attestation
1533 private key, known only to the TPM.
1535 As noted above in Section 5 Security Considerations, it's important
1536 to note that the Quote data structure is signed inside the TPM. The
1537 trust model is preserved by retrieving the Quote in a way that does
1538 not invalidate the signature, as specified in
1539 [I-D.ietf-rats-yang-tpm-charra]. The structure of the command and
1540 response for a quote, including its signature, as generated by the
1541 TPM, can be seen in [TPM1.2] Part 3, Section 16.5, and [TPM2.0]
1542 Section 18.4.2.
1544 The Verifier uses the Quote and Log together. The Quote contains the
1545 composite hash of the complete sequence of security measurement
1546 hashes, signed by the TPM's private Attestation Key. The Log
1547 contains a record of each measurement extended into the TPM's PCRs.
1548 By computing the composite hash of all the measurements, the Verifier
1549 can verify the integrity of the Event Log, even though the Event Log
1550 itself is not signed. Each hash in the validated Event Log can then
1551 be compared to corresponding expected values in the set of Reference
1552 Values to validate overall system integrity.
1554 A summary of information exchanged in obtaining quotes from TPM1.2
1555 and TPM2.0 can be found in [TAP], Section 4. Detailed information
1556 about PCRs and Quote data structures can be found in [TPM1.2],
1557 [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0],
1558 and [Canonical-Event-Log].
1560 9.2. Root of Trust for Measurement
1562 The measurements needed for attestation require that the device being
1563 attested is equipped with a Root of Trust for Measurement, that is,
1564 some trustworthy mechanism that can compute the first measurement in
1565 the chain of trust required to attest that each stage of system
1566 startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs)
1567 to record the results, and a Root of Trust for Reporting to report
1568 the results.
1570 While there are many complex aspects of Roots of Trust ( [TCGRoT],
1571 [SP800-155], [SP800-193]), two aspects that are important in the case
1572 of attestation are:
1574 * The first measurement computed by the Root of Trust for
1575 Measurement, and stored in the TPM's Root of Trust for Storage,
1576 must be assumed to be correct.
1578 * There must not be a way to reset the Root of Trust for Storage
1579 without re-entering the Root of Trust for Measurement code.
1581 The first measurement must be computed by code that is implicitly
1582 trusted; if that first measurement can be subverted, none of the
1583 remaining measurements can be trusted. (See [SP800-155])
1585 It's important to note that the trustworthiness of the RTM code
1586 cannot be assured by the TPM or TPM supplier - code or procedures
1587 external to the TPM must guarantee the security of the RTM.
1589 9.3. Layering Model for Network Equipment Attester and Verifier
1591 Retrieval of identity and attestation state uses one protocol stack,
1592 while retrieval of Reference Values uses a different set of
1593 protocols. Figure 5 shows the components involved.
1595 +-----------------------+ +-------------------------+
1596 | | | |
1597 | Attester |<-------------| Verifier |
1598 | (Device) |------------->| (Management Station) |
1599 | | | | |
1600 +-----------------------+ | +-------------------------+
1601 |
1602 -------------------- --------------------
1603 | |
1604 ------------------------------- ---------------------------------
1605 |Reference Values | | Attestation |
1606 ------------------------------- ---------------------------------
1608 ********************************************************************
1609 * IETF Attestation Reference Interaction Diagram *
1610 ********************************************************************
1612 ......................... .........................
1613 . Reference Integrity . . TAP (PTS2.0) Info .
1614 . Manifest . . Model and Canonical .
1615 . . . Log Format .
1616 ......................... .........................
1618 ************************* *************************
1619 * YANG SWID Module * * YANG Attestation *
1620 * I-D.ietf-sacm-coswid * * Module *
1621 * * * I-D.ietf-rats- *
1622 * * * yang-tpm-charra *
1623 ************************* *************************
1625 ************************* *************************
1626 * XML, JSON, CBOR (etc) * * XML, JSON, CBOR (etc) *
1627 ************************* *************************
1629 ************************* *************************
1630 * RESTCONF/NETCONF * * RESTCONF/NETCONF *
1631 ************************* *************************
1633 ************************* *************************
1634 * TLS, SSH * * TLS, SSH *
1635 ************************* *************************
1637 Figure 6: RIV Protocol Stacks
1639 IETF documents are captured in boxes surrounded by asterisks. TCG
1640 documents are shown in boxes surrounded by dots.
1642 9.4. Implementation Notes
1644 Figure 7 summarizes many of the actions needed to complete an
1645 Attestation system, with links to relevant documents. While
1646 documents are controlled by several standards organizations, the
1647 implied actions required for implementation are all the
1648 responsibility of the manufacturer of the device, unless otherwise
1649 noted.
1651 As noted, SWID tags can be generated many ways, but one possible tool
1652 is [SWID-Gen]
1654 +------------------------------------------------------------------+
1655 | Component | Controlling |
1656 | | Specification |
1657 --------------------------------------------------------------------
1658 | Make a Secure execution environment | TCG RoT |
1659 | o Attestation depends on a secure root of | UEFI.org |
1660 | trust for measurement outside the TPM, as | |
1661 | well as roots for storage and reporting | |
1662 | inside the TPM. | |
1663 | o Refer to TCG Root of Trust for Measurement.| |
1664 | o NIST SP 800-193 also provides guidelines | |
1665 | on Roots of Trust | |
1666 --------------------------------------------------------------------
1667 | Provision the TPM as described in |[Platform-DevID-TPM-2.0]|
1668 | TCG documents. | TCG Platform |
1669 | | Certificate |
1670 --------------------------------------------------------------------
1671 | Put a DevID or Platform Cert in the TPM | TCG TPM DevID |
1672 | o Install an Initial Attestation Key at the | TCG Platform |
1673 | same time so that Attestation can work out | Certificate |
1674 | of the box |-----------------
1675 | o Equipment suppliers and owners may want to | IEEE 802.1AR |
1676 | implement Local Device ID as well as | |
1677 | Initial Device ID | |
1678 --------------------------------------------------------------------
1679 | Connect the TPM to the TLS stack | Vendor TLS |
1680 | o Use the DevID in the TPM to authenticate | stack (This |
1681 | TAP connections, identifying the device | action is |
1682 | | configuring TLS|
1683 | | to use the DevID |
1684 | | as its client |
1685 | | certificate) |
1686 --------------------------------------------------------------------
1687 | Make CoSWID tags for BIOS/Loader/Kernel objects | IETF CoSWID |
1688 | o Add reference measurements into SWID tags | ISO/IEC 19770-2|
1689 | o Manufacturer should sign the SWID tags | NIST IR 8060 |
1690 | o The TCG RIM-IM identifies further | |
1691 | procedures to create signed RIM | |
1692 | documents that provide the necessary | |
1693 | reference information | |
1694 --------------------------------------------------------------------
1695 | Package the SWID tags with a vendor software | Retrieve tags |
1696 | release | with |
1697 | o A tag-generator plugin such | I-D.ietf-sacm-coswid|
1698 | as [SWID-Gen] can be used |----------------|
1699 | | TCG PC Client |
1700 | | RIM |
1701 --------------------------------------------------------------------
1702 | Use PC Client measurement definitions | TCG PC Client |
1703 | to define the use of PCRs | BIOS |
1704 | (although Windows OS is rare on Networking | |
1705 | Equipment, UEFI BIOS is not) | |
1706 --------------------------------------------------------------------
1707 | Use TAP to retrieve measurements | |
1708 | o Map to YANG | YANG Module for|
1709 | Use Canonical Log Format | Basic |
1710 | | Attestation |
1711 | | TCG Canonical |
1712 | | Log Format |
1713 --------------------------------------------------------------------
1714 | Posture Collection Server (as described in IETF | |
1715 | SACMs ECP) should request the | |
1716 | attestation and analyze the result | |
1717 | The Management application might be broken down | |
1718 | to several more components: | |
1719 | o A Posture Manager Server | |
1720 | which collects reports and stores them in | |
1721 | a database | |
1722 | o One or more Analyzers that can look at the| |
1723 | results and figure out what it means. | |
1724 --------------------------------------------------------------------
1726 Figure 7: Component Status
1728 10. References
1730 10.1. Normative References
1732 [Canonical-Event-Log]
1733 Trusted Computing Group, "Canonical Event Log Format
1734 Version 1.0 Revision .41, February 25, 2022", December
1735 2020, .
1738 [I-D.ietf-rats-architecture]
1739 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
1740 W. Pan, "Remote Attestation Procedures Architecture", Work
1741 in Progress, Internet-Draft, draft-ietf-rats-architecture-
1742 15, 8 February 2022, .
1745 [I-D.ietf-rats-yang-tpm-charra]
1746 Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,
1747 B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A
1748 YANG Data Model for Challenge-Response-based Remote
1749 Attestation Procedures using TPMs", Work in Progress,
1750 Internet-Draft, draft-ietf-rats-yang-tpm-charra-15, 28
1751 February 2022, .
1754 [I-D.ietf-sacm-coswid]
1755 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
1756 Waltermire, "Concise Software Identification Tags", Work
1757 in Progress, Internet-Draft, draft-ietf-sacm-coswid-20, 26
1758 January 2022, .
1761 [IEEE-802-1AR]
1762 Seaman, M., "802.1AR-2018 - IEEE Standard for Local and
1763 Metropolitan Area Networks - Secure Device Identity, IEEE
1764 Computer Society", August 2018.
1766 [IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn,
1767 "Integrity Measurement Architecture", June 2019,
1768 .
1770 [PC-Client-BIOS-TPM-2.0]
1771 Trusted Computing Group, "PC Client Specific Platform
1772 Firmware Profile Specification Family "2.0", Level 00
1773 Revision 1.05 Revision 23, May 7, 2021", May 2021,
1774 .
1777 [PC-Client-EFI-TPM-1.2]
1778 Trusted Computing Group, "TCG EFI Platform Specification
1779 for TPM Family 1.1 or 1.2, Specification Version 1.22,
1780 Revision 15", January 2014,
1781 .
1784 [PC-Client-RIM]
1785 Trusted Computing Group, "TCG PC Client Reference
1786 Integrity Manifest Specification, v1.04, Nov 4, 2020",
1787 December 2019,
1788 .
1791 [Platform-DevID-TPM-2.0]
1792 Trusted Computing Group, "TPM 2.0 Keys for Device Identity
1793 and Attestation, Specification Version 1.0, Revision 2",
1794 September 2020,
1795 .
1798 [Platform-ID-TPM-1.2]
1799 Trusted Computing Group, "TPM Keys for Platform Identity
1800 for TPM 1.2, Specification Version 1.0, Revision 3",
1801 August 2015, .
1804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1805 Requirement Levels", BCP 14, RFC 2119,
1806 DOI 10.17487/RFC2119, March 1997,
1807 .
1809 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
1810 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
1811 January 2006, .
1813 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1814 Housley, R., and W. Polk, "Internet X.509 Public Key
1815 Infrastructure Certificate and Certificate Revocation List
1816 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1817 .
1819 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1820 and A. Bierman, Ed., "Network Configuration Protocol
1821 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1822 .
1824 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1825 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1826 May 2017, .
1828 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1829 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1830 .
1832 [RIM] Trusted Computing Group, "TCG Reference Integrity Manifest
1833 (RIM) Information Model, v1.0, Revision 0.16, Nov 12,
1834 2020", June 2019,
1835 .
1838 [SWID] The International Organization for Standardization/
1839 International Electrotechnical Commission, "Information
1840 Technology Software Asset Management Part 2: Software
1841 Identification Tag, ISO/IEC 19770-2", October 2015,
1842 .
1844 [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol
1845 (TAP) Information Model for TPM Families 1.2 and 2.0 and
1846 DICE Family 1.0, Version 1.0, Revision 0.36", October
1847 2018, .
1850 10.2. Informative References
1852 [AK-Enrollment]
1853 Trusted Computing Group, "TCG Infrastructure Working Group
1854 - A CMC Profile for AIK Certificate Enrollment Version
1855 1.0, Revision 7", March 2011,
1856 .
1860 [I-D.birkholz-rats-network-device-subscription]
1861 Birkholz, H., Voit, E., and W. Pan, "Attestation Event
1862 Stream Subscription", Work in Progress, Internet-Draft,
1863 draft-birkholz-rats-network-device-subscription-03, 17
1864 August 2021, .
1867 [I-D.birkholz-rats-reference-interaction-model]
1868 Birkholz, H., Eckel, M., Newton, C., and L. Chen,
1869 "Reference Interaction Models for Remote Attestation
1870 Procedures", Work in Progress, Internet-Draft, draft-
1871 birkholz-rats-reference-interaction-model-03, 7 July 2020,
1872 .
1875 [I-D.birkholz-rats-tuda]
1876 Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
1877 "Time-Based Uni-Directional Attestation", Work in
1878 Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12
1879 January 2022, .
1882 [I-D.ietf-rats-eat]
1883 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
1884 Attestation Token (EAT)", Work in Progress, Internet-
1885 Draft, draft-ietf-rats-eat-12, 24 February 2022,
1886 .
1889 [I-D.richardson-rats-usecases]
1890 Richardson, M., Wallace, C., and W. Pan, "Use cases for
1891 Remote Attestation common encodings", Work in Progress,
1892 Internet-Draft, draft-richardson-rats-usecases-08, 2
1893 November 2020, .
1896 [IEEE-802.1AE]
1897 Seaman, M., "802.1AE MAC Security (MACsec)", 2018,
1898 .
1900 [IEEE-802.1X]
1901 IEEE Computer Society, "802.1X-2020 - IEEE Standard for
1902 Local and Metropolitan Area Networks--Port-Based Network
1903 Access Control", February 2020,
1904 .
1906 [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for
1907 Local and metropolitan area networks - Station and Media
1908 Access Control Connectivity Discovery", March 2016,
1909 .
1911 [NetEq] Trusted Computing Group, "TCG Guidance for Securing
1912 Network Equipment, Version 1.0, Revision 29", January
1913 2018, .
1916 [NIST-IR-8060]
1917 National Institute for Standards and Technology,
1918 "Guidelines for the Creation of Interoperable Software
1919 Identification (SWID) Tags", April 2016,
1920 .
1923 [Platform-Certificates]
1924 Trusted Computing Group, "TCG Platform Attribute
1925 Credential Profile, Specification Version 1.0, Revision
1926 16", January 2018,
1927 .
1930 [Provisioning-TPM-2.0]
1931 Trusted Computing Group, "TCG TPM v2.0 Provisioning
1932 Guidance, Version 1.0, Revision 1.0", March 2015,
1933 .
1936 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
1937 Levkowetz, Ed., "Extensible Authentication Protocol
1938 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
1939 .
1941 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1942 Verification of Domain-Based Application Service Identity
1943 within Internet Public Key Infrastructure Using X.509
1944 (PKIX) Certificates in the Context of Transport Layer
1945 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
1946 2011, .
1948 [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment
1949 (NEA) Asokan Attack Analysis", RFC 6813,
1950 DOI 10.17487/RFC6813, December 2012,
1951 .
1953 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1954 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1955 .
1957 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
1958 Touch Provisioning (SZTP)", RFC 8572,
1959 DOI 10.17487/RFC8572, April 2019,
1960 .
1962 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
1963 and K. Watsen, "Bootstrapping Remote Secure Key
1964 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
1965 May 2021, .
1967 [SP800-155]
1968 National Institute of Standards and Technology, "BIOS
1969 Integrity Measurement Guidelines (Draft)", December 2011,
1970 .
1973 [SP800-193]
1974 National Institute for Standards and Technology, "NIST
1975 Special Publication 800-193: Platform Firmware Resiliency
1976 Guidelines", April 2018,
1977 .
1980 [SWID-Gen] Labs64, Munich, Germany, "SoftWare IDentification (SWID)
1981 Tags Generator (Maven Plugin)", n.d.,
1982 .
1984 [TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust
1985 Specification", October 2018,
1986 .
1989 [TPM1.2] Trusted Computing Group, "TPM Main Specification Level 2
1990 Version 1.2, Revision 116", March 2011,
1991 .
1994 [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library
1995 Specification, Family "2.0", Level 00, Revision 01.59",
1996 November 2019,
1997 .
2000 Authors' Addresses
2002 Guy Fedorkow (editor)
2003 Juniper Networks, Inc.
2004 10 Technology Park Drive
2005 Westford, Massachusetts 01886
2006 United States of America
2007 Email: gfedorkow@juniper.net
2009 Eric Voit
2010 Cisco Systems
2011 Email: evoit@cisco.com
2012 Jessica Fitzgerald-McKay
2013 National Security Agency
2014 9800 Savage Road
2015 Ft. Meade, Maryland 20755
2016 United States of America
2017 Email: jmfitz2@nsa.gov