idnits 2.17.1
draft-ietf-rats-tpm-based-network-device-attest-04.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 :
----------------------------------------------------------------------------
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 294: '... Device identity MUST be based on IEEE...'
RFC 2119 keyword, line 604: '... Attestation key MUST be protected by ...'
RFC 2119 keyword, line 605: '... and the DevID SHOULD be as well. D...'
RFC 2119 keyword, line 623: '... provisioning as specified in [RFC8572]) MUST be shipped by the...'
RFC 2119 keyword, line 628: '...IAK certificates MUST both be signed b...'
(37 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 18, 2020) is 1315 days in the past. Is
this intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '0' on line 546
-- Looks like a reference, but probably isn't: '2' on line 557
-- Looks like a reference, but probably isn't: '4' on line 559
-- Looks like a reference, but probably isn't: '8' on line 565
-- Looks like a reference, but probably isn't: '5' on line 562
== Outdated reference: A later version (-22) exists of
draft-ietf-rats-yang-tpm-charra-02
== Outdated reference: A later version (-24) exists of
draft-ietf-sacm-coswid-15
== Outdated reference: A later version (-03) exists of
draft-birkholz-rats-network-device-subscription-00
== Outdated reference: A later version (-07) exists of
draft-birkholz-rats-tuda-03
== Outdated reference: A later version (-22) exists of
draft-ietf-rats-architecture-06
== Outdated reference: A later version (-25) exists of
draft-ietf-rats-eat-04
== Outdated reference: A later version (-08) exists of
draft-richardson-rats-usecases-07
Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 RATS Working Group G. Fedorkow, Ed.
3 Internet-Draft Juniper Networks, Inc.
4 Intended status: Informational E. Voit
5 Expires: March 22, 2021 Cisco Systems, Inc.
6 J. Fitzgerald-McKay
7 National Security Agency
8 September 18, 2020
10 TPM-based Network Device Remote Integrity Verification
11 draft-ietf-rats-tpm-based-network-device-attest-04
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].
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at https://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on March 22, 2021.
36 Copyright Notice
38 Copyright (c) 2020 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
55 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4
56 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
57 1.4. Description of Remote Integrity Verification (RIV) . . . 5
58 1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7
59 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
60 1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8
61 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9
62 2.1. RIV Software Configuration Attestation using TPM . . . . 9
63 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 10
64 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 12
65 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 13
66 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 14
67 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 16
68 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 17
69 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 18
70 3. Standards Components . . . . . . . . . . . . . . . . . . . . 19
71 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 19
72 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 19
73 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 19
74 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 19
75 3.2. Reference Model for Challenge-Response . . . . . . . . . 20
76 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 22
77 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 23
78 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
80 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 25
81 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 27
82 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 28
83 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 28
84 5.5. Other Trust Anchors . . . . . . . . . . . . . . . . . . . 29
85 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 30
86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
87 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 30
88 8.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 30
89 8.2. Root of Trust for Measurement . . . . . . . . . . . . . . 32
90 8.3. Layering Model for Network Equipment Attester and
91 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 32
92 8.3.1. Why is OS Attestation Different? . . . . . . . . . . 34
93 8.4. Implementation Notes . . . . . . . . . . . . . . . . . . 34
94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
95 9.1. Normative References . . . . . . . . . . . . . . . . . . 36
96 9.2. Informative References . . . . . . . . . . . . . . . . . 38
97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
99 1. Introduction
101 There are many aspects to consider in fielding a trusted computing
102 device, from operating systems to applications. Mechanisms to prove
103 that a device installed at a customer's site is authentic (i.e., not
104 counterfeit) and has been configured with authorized software, all as
105 part of a trusted supply chain, are just a few of the many aspects
106 which need to be considered concurrently to have confidence that a
107 device is truly trustworthy.
109 A generic architecture for remote attestation has been defined in
110 [I-D.ietf-rats-architecture]. Additionally, the use cases for
111 remotely attesting networking devices are discussed within Section 6
112 of [I-D.richardson-rats-usecases]. However, these documents do not
113 provide sufficient guidance for network equipment vendors and
114 operators to design, build, and deploy interoperable devices.
116 The intent of this document is to provide such guidance. It does
117 this by outlining the Remote Integrity Verification (RIV) problem,
118 and then identifies elements that are necessary to get the complete,
119 scalable attestation procedure working with commercial networking
120 products such as routers, switches and firewalls. An underlying
121 assumption will be the availability within the device of a Trusted
122 Platform Module [TPM1.2], [TPM2.0] compliant cryptoprocessor to
123 enable the trustworthy remote assessment of the device's software and
124 hardware.
126 1.1. Terminology
128 A number of terms are reused from [I-D.ietf-rats-architecture].
129 These include: Appraisal Policy for Attestation Results, Attestation
130 Result, Attester, Evidence, Relying Party, Verifier, and Verifier
131 Owner.
133 Additionally, this document defines the following terms:
135 Remote Attestation: the process of creating, conveying and appraising
136 claims about device trustworthiness characteristics, including supply
137 chain trust, identity, device provenance, software configuration,
138 hardware configuration, device composition, compliance to test
139 suites, functional and assurance evaluations, etc.
141 This document uses the term Endorser to refer to the trusted
142 authority for any signed object relating to the device, such as
143 certificates or reference measurement. Typically, the manufacturer
144 of an embedded device would be accepted as an Endorser.
146 The goal of attestation is simply to assure an administrator that the
147 software that was launched when the device was last started is an
148 authentic and untampered-with copy of the software that the device
149 vendor shipped.
151 Within the Trusted Computing Group context, attestation is the
152 process by which an independent Verifier can obtain cryptographic
153 proof as to the identity of the device in question, and evidence of
154 the integrity of software loaded on that device when it started up,
155 and then verify that what's there is what's supposed to be there.
156 For networking equipment, a Verifier capability can be embedded in a
157 Network Management Station (NMS), a posture collection server, or
158 other network analytics tool (such as a software asset management
159 solution, or a threat detection and mitigation tool, etc.). While
160 informally referred to as attestation, this document focuses on a
161 subset defined here as Remote Integrity Verification (RIV). RIV
162 takes a network equipment centric perspective that includes a set of
163 protocols and procedures for determining whether a particular device
164 was launched with authentic software, starting from Roots of Trust.
165 While there are many ways to accomplish attestation, RIV sets out a
166 specific set of protocols and tools that work in environments
167 commonly found in Networking Equipment. RIV does not cover other
168 device characteristics that could be attested (e.g., geographic
169 location, connectivity; see [I-D.richardson-rats-usecases]), although
170 it does provide evidence of a secure infrastructure to increase the
171 level of trust in other device characteristics attested by other
172 means (e.g., by Entity Attestation Tokens [I-D.ietf-rats-eat]).
174 1.2. Document Organization
176 The remainder of this document is organized into several sections:
178 o The remainder of this section covers goals and requirements, plus
179 a top-level description of RIV.
181 o The Solution Overview section outlines how Remote Integrity
182 Verification works.
184 o The Standards Components section links components of RIV to
185 normative standards.
187 o Privacy and Security shows how specific features of RIV contribute
188 to the trustworthiness of the Attestation Result.
190 o Supporting material is in an appendix at the end.
192 1.3. Goals
194 Network operators benefit from a trustworthy attestation mechanism
195 that provides assurance that their network comprises authentic
196 equipment, and has loaded software free of known vulnerabilities and
197 unauthorized tampering. In line with the overall goal of assuring
198 integrity, attestation can be used to assist in asset management,
199 vulnerability and compliance assessment, plus configuration
200 management.
202 The RIV attestation workflow outlined in this document is intended to
203 meet the following high-level goals:
205 o Provable Device Identity - This specification requires that an
206 attesting device includes a cryptographic identifier unique to
207 each device. Effectively this means that the TPM must be so
208 provisioned during the manufacturing cycle.
210 o Software Inventory - A key goal is to identify the software
211 release(s) installed on the attesting device, and to provide
212 evidence that the software stored within hasn't been altered
213 without authorization.
215 o Verifiability - Verification of software and configuration of the
216 device shows that the software that was authorized for
217 installation by the administrator has actually been launched.
219 In addition, RIV is designed to operate either in a centralized
220 environment, such as with a central authority that manages and
221 configures a number of network devices, or 'peer-to-peer', where
222 network devices independently verify one another to establish a trust
223 relationship. (See Section 3.3 below, and also
224 [I-D.voit-rats-trusted-path-routing])
226 1.4. Description of Remote Integrity Verification (RIV)
228 Attestation requires two interlocking services between the Attester
229 network device and the Verifier:
231 o Device Identity, the mechanism providing trusted identity, can
232 reassure network managers that the specific devices they ordered
233 from authorized manufacturers for attachment to their network are
234 those that were installed, and that they continue to be present in
235 their network. As part of the mechanism for Device Identity,
236 cryptographic proof of the identity of the manufacturer is also
237 provided.
239 o Software Measurement is the mechanism that reports the state of
240 mutable software components on the device, and can assure network
241 managers that they have known, authentic software configured to
242 run in their network.
244 Using these two interlocking services, RIV is a component in a chain
245 of procedures that can assure a network operator that the equipment
246 in their network can be reliably identified, and that authentic
247 software of a known version is installed on each device. Equipment
248 in the network includes devices that make up the network itself, such
249 as routers, switches and firewalls.
251 RIV includes several major processes:
253 1. Creation of Evidence is the process whereby an Attester generates
254 cryptographic proof (Evidence) of claims about device properties.
255 In particular, the device identity and its software configuration
256 are both of critical importance.
258 2. Device Identification refers to the mechanism assuring the
259 Relying Party (ultimately, a network administrator) of the
260 identity of devices that make up their network, and that their
261 manufacturers are known.
263 3. Software used to boot a device can be described as a chain of
264 measurements, anchored at the start by a Root of Trust for
265 Measurement, that normally ends when the system software is
266 loaded. A measurement signifies the identity, integrity and
267 version of each software component registered with an attesting
268 device's TPM [TPM1.2], [TPM2.0], so that the subsequent appraisal
269 stage can determine if the software installed is authentic, up-
270 to-date, and free of tampering.
272 4. Conveyance of Evidence reliably transports at least the minimum
273 amount of Evidence from Attester to a Verifier to allow a
274 management station to perform a meaningful appraisal in Step 5.
275 The transport is typically carried out via a management network.
276 The channel must provide integrity and authenticity, and, in some
277 use cases, may also require confidentiality.
279 5. Finally, Appraisal of Evidence occurs. As the Verifier and
280 Relying Party roles are often combined within RIV, this is the
281 process of verifying the Evidence received by a Verifier from the
282 Attesting device, and using an Appraisal Policy to develop an
283 Attestation Result, used to inform decision making. In practice,
284 this means comparing the device measurements reported as Evidence
285 with the Attester configuration expected by the Verifier.
286 Subsequently the Appraisal Policy for Attestation Results might
287 match what was found against Reference Integrity Measurements
288 (aka Golden Measurements) which represent the intended configured
289 state of the connected device.
291 All implementations supporting this RIV specification require the
292 support of the following three technologies:
294 1. Identity: Device identity MUST be based on IEEE 802.1AR Device
295 Identity (DevID) [IEEE-802-1AR], coupled with careful supply-
296 chain management by the manufacturer. The DevID certificate
297 contains a statement by the manufacturer that establishes the
298 identity of the device as it left the factory. Some applications
299 with a more-complex post-manufacture supply chain (e.g., Value
300 Added Resellers), or with different privacy concerns, may want to
301 use alternative mechanisms for platform authentication (for
302 example, TCG Platform Certificates [Platform-Certificates]).
304 2. Platform Attestation provides evidence of configuration of
305 software elements present in the device. This form of
306 attestation can be implemented with TPM Platform Configuration
307 Registers (PCRs), Quote and Log mechanisms, which provide
308 cryptographically authenticated evidence to report what software
309 was started on the device through the boot cycle. Successful
310 attestation requires an unbroken chain from a boot-time root of
311 trust through all layers of software needed to bring the device
312 to an operational state, in which each stage measures components
313 of the next stage, updates the attestation log, and extends
314 hashes into a PCR. The TPM can then report the hashes of all the
315 measured hashes as signed evidence called a Quote (see
316 Section 8.1 for an overview of TPM operation, or [TPM1.2] and
317 [TPM2.0] for many more details).
319 3. Reference Integrity Measurements must be conveyed from the
320 Endorser (the entity accepted as the software authority, often
321 the manufacturer for embedded systems) to the system in which
322 verification will take place.
324 1.5. Solution Requirements
326 Remote Integrity Verification must address the "Lying Endpoint"
327 problem, in which malicious software on an endpoint may subvert the
328 intended function, and also prevent the endpoint from reporting its
329 compromised status. (See Section 5 for further Security
330 Considerations)
332 RIV attestation is designed to be simple to deploy at scale. RIV
333 should work "out of the box" as far as possible, that is, with the
334 fewest possible provisioning steps or configuration databases needed
335 at the end-user's site, as network equipment is often required to
336 "self-configure", to reliably reach out without manual intervention
337 to prove its identity and operating posture, then download its own
338 configuration. See [RFC8572] for an example of Secure Zero Touch
339 Provisioning.
341 1.6. Scope
343 Remote Attestation is a very general problem that could apply to most
344 network-connected computing devices. However, this document includes
345 several assumptions that limit the scope to Network Equipment (e.g.,
346 routers, switches and firewalls):
348 o This solution is for use in non-privacy-preserving applications
349 (for example, networking, Industrial IoT), avoiding the need for a
350 Privacy Certificate Authority for attestation keys
351 [AIK-Enrollment] or TCG Platform Certificates
352 [Platform-Certificates]
354 o This document assumes network protocols that are common in
355 networking equipment such as YANG [RFC7950] and NETCONF [RFC6241],
356 but not generally used in other applications.
358 o The approach outlined in this document mandates the use of a
359 compliant TPM [TPM1.2], [TPM2.0].
361 1.6.1. Out of Scope
363 o Run-Time Attestation: Run-time attestation of Linux or other
364 multi-threaded operating system processes considerably expands the
365 scope of the problem. Many researchers are working on that
366 problem, but this document defers the run-time attestation
367 problem.
369 o Multi-Vendor Embedded Systems: Additional coordination would be
370 needed for devices that themselves comprise hardware and software
371 from multiple vendors, integrated by the end user.
373 o Processor Sleep Modes: Network equipment typically does not
374 "sleep", so sleep and hibernate modes are not considered.
375 Although out of scope for RIV, Trusted Computing Group
376 specifications do encompass sleep and hibernate states.
378 o Virtualization and Containerization: In a non-virtualized system,
379 the host OS is responsible for measuring each User Space file or
380 process, but that't the end of the boot process. For virtualized
381 systems, the host OS must verify the hypervisor, which then
382 manages its own chain of trust through the virtual machine.
384 Virtualization and containerization technologies are increasingly
385 used in Network equipment, but are not considered in this revision
386 of the document.
388 2. Solution Overview
390 2.1. RIV Software Configuration Attestation using TPM
392 RIV Attestation is a process which can be used to determine the
393 identity of software running on a specifically-identified device.
394 Remote Attestation is broken into two phases, shown in Figure 1:
396 o During system startup, each distinct software object is
397 "measured". Its identity, hash (i.e., cryptographic digest) and
398 version information are recorded in a log. Hashes are also
399 extended, or cryptographically folded, into the TPM, in a way that
400 can be used to validate the log entries. The measurement process
401 generally follows the Chain of Trust model used in Measured Boot,
402 where each stage of the system measures the next one, and extends
403 its measurement into the TPM, before launching it.
405 o Once the device is running and has operational network
406 connectivity, a separate, trusted Verifier will interrogate the
407 network device to retrieve the logs and a copy of the digests
408 collected by hashing each software object, signed by an
409 attestation private key known only to the TPM.
411 The result is that the Verifier can verify the device's identity by
412 checking the Subject Field and signature of certificate containing
413 the TPM's attestation public key, and can validate the software that
414 was launched by verifying the correctness of the logs by comparing
415 with the signed digests from the TPM, and comparing digests in the
416 log with known-good values.
418 It should be noted that attestation and identity are inextricably
419 linked; signed Evidence that a particular version of software was
420 loaded is of little value without cryptographic proof of the identity
421 of the Attester producing the Evidence.
423 +-------------------------------------------------------+
424 | +--------+ +--------+ +--------+ +---------+ |
425 | | BIOS |--->| Loader |-->| Kernel |--->|Userland | |
426 | +--------+ +--------+ +--------+ +---------+ |
427 | | | | |
428 | | | | |
429 | +------------+-----------+-+ |
430 | Step 1 | |
431 | V |
432 | +--------+ |
433 | | TPM | |
434 | +--------+ |
435 | Router | |
436 +--------------------------------|----------------------+
437 |
438 | Step 2
439 | +-----------+
440 +--->| Verifier |
441 +-----------+
443 Reset---------------flow-of-time-during-boot--...------->
445 Figure 1: RIV Attestation Model
447 In Step 1, measurements are "extended", or hashed, into the TPM as
448 processes start, with the result that the PCR ends up containing a
449 hash of all the measured hashes. In Step 2, signed PCR digests are
450 retrieved from the TPM for off-box analysis after the system is
451 operational.
453 2.1.1. What Does RIV Attest?
455 TPM attestation is strongly focused on Platform Configuration
456 Registers (PCRs), but those registers are only vehicles for
457 certifying accompanying Evidence, conveyed in log entries. It is the
458 hashes in log entries that are extended into PCRs, where the final
459 PCR values can be retrieved in the form of a structured called a
460 Quote, signed by an Attestation key known only to the TPM. The use
461 of multiple PCRs serves only to provide some independence between
462 different classes of object, so that one class of objects can be
463 updated without changing the extended hash for other classes.
464 Although PCRs can be used for any purpose, this section outlines the
465 objects within the scope of this document which may be extended into
466 the TPM.
468 In general, assignment of measurements to PCRs is a policy choice
469 made by the device manufacturer, selected to independently attest
470 three classes of object:
472 o Code, (i.e., instructions) to be executed by a CPU.
474 o Configuration - Many devices offer numerous options controlled by
475 non-volatile configuration variables which can impact the device's
476 security posture. These settings may have vendor defaults, but
477 often can be changed by administrators, who may want to verify via
478 attestation that the settings they intend are still in place.
480 o Credentials - Administrators may wish to verify via attestation
481 that keys (and other credentials) outside the Root of Trust have
482 not been subject to unauthorized tampering. (By definition, keys
483 inside the root of trust can't be verified independently).
485 The TCG PC Client Platform Firmware Profile Specification
486 [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be
487 measured during the boot phase of platform startup using a UEFI BOIS
488 (www.uefi.org), but the goal is simply to measure every bit of code
489 executed in the process of starting the device, along with any
490 configuration information related to security posture, leaving no gap
491 for unmeasured code to remain undetected and subvert the chain.
493 For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] gives
494 detailed normative requirements for PCR usage. But for other
495 platform architectures, the table in Figure 2 gives guidance for PCR
496 assignment that generalizes the specific details of
497 [PC-Client-BIOS-TPM-2.0].
499 By convention, most PCRs are assigned in pairs, which the even-
500 numbered PCR used to measure executable code, and the odd-numbered
501 PCR used to measure whatever data and configuration are associated
502 with that code. It is important to note that each PCR may contain
503 results from dozens (or even thousands) of individual measurements.
505 +------------------------------------------------------------------+
506 | | Assigned PCR # |
507 | Function | Code | Configuration|
508 --------------------------------------------------------------------
509 | Firmware Static Root of Trust, (i.e., | 0 | 1 |
510 | initial boot firmware and drivers) | | |
511 --------------------------------------------------------------------
512 | Drivers and initialization for optional | 2 | 3 |
513 | or add-in devices | | |
514 --------------------------------------------------------------------
515 | OS Loader code and configuration, (i.e., | 4 | 5 |
516 | the code launched by firmware) to load an | | |
517 | operating system kernel. These PCRs record | | |
518 | each boot attempt, and an identifier for | | |
519 | where the loader was found | | |
520 --------------------------------------------------------------------
521 | Vendor Specific Measurements during boot | 6 | 6 |
522 --------------------------------------------------------------------
523 | Secure Boot Policy. This PCR records keys | | 7 |
524 | and configuration used to validate the OS | | |
525 | loader | | |
526 --------------------------------------------------------------------
527 | Measurements made by the OS Loader | 8 | 9 |
528 | (e.g GRUB2 for Linux) | | |
529 --------------------------------------------------------------------
530 | Measurements made by OS (e.g., Linux IMA) | 10 | 10 |
531 +------------------------------------------------------------------+
533 Figure 2: Attested Objects
535 2.1.2. Notes on PCR Allocations
537 It is important to recognize that PCR[0] is critical. The first
538 measurement into PCR[0] taken by the Root of Trust for Measurement,
539 is critical to establishing the chain of trust for all subsequent
540 measurements. If the PCR[0] measurement cannot be trusted, the
541 validity of the entire chain is put into question.
543 Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized
544 below:
546 o PCR[0] typically represents a consistent view of the Host Platform
547 between boot cycles, allowing Attestation and Sealed Storage
548 policies to be defined using the less changeable components of the
549 transitive trust chain. This PCR typically provides a consistent
550 view of the platform regardless of user selected options.
552 o PCR[2] is intended to represent a "user configurable" environment
553 where the user has the ability to alter the components that are
554 measured into PCR[2]. This is typically done by adding adapter
555 cards, etc., into user-accessible PCI or other slots. In UEFI
556 systems these devices may be configured by Option ROMs measured
557 into PCR[2] and executed by the BIOS.
559 o PCR[4] is intended to represent the software that manages the
560 transition between the platform's Pre-Operating System Start and
561 the state of a system with the Operating System present. This
562 PCR, along with PCR[5], identifies the initial operating system
563 loader (e.g., GRUB for Linux).
565 o PCR[8] is used by the OS loader to record measurements of the
566 various components of the operating system.
568 Although the TCG PC Client document specifies the use of the first
569 eight PCRs very carefully to ensure interoperability among multiple
570 UEFI BIOS vendors, it should be noted that embedded software vendors
571 may have considerably more flexibility. Verifiers typically need to
572 know which log entries are consequential and which are not (possibly
573 controlled by local policies) but the Verifier may not need to know
574 what each log entry means or why it was assigned to a particular PCR.
575 Designers must recognize that some PCRs may cover log entries that a
576 particular Verifier considers critical and other log entries that are
577 not considered important, so differing PCR values may not on their
578 own constitute a check for authenticity.
580 Designers may allocate particular events to specific PCRs in order to
581 achieve a particular objective with Local Attestation, (e.g.,
582 allowing a procedure to execute only if a given PCR is in a given
583 state). It may also be important to designers to consider whether
584 streaming notification of PCR updates is required (see
585 [I-D.birkholz-rats-network-device-subscription]). Specific log
586 entries can only be validated if the Verifier receives every log
587 entry affecting the relevant PCR, so (for example) a designer might
588 want to separate rare, high-value events such as configuration
589 changes, from high-volume, routine measurements such as IMA [IMA]
590 logs.
592 2.2. RIV Keying
594 RIV attestation relies on two keys:
596 o An identity key is required to certify the identity of the
597 Attester itself. RIV specifies the use of an IEEE 802.1AR Device
598 Identity (DevID) [IEEE-802-1AR], signed by the device
599 manufacturer, containing the device serial number.
601 o An Attestation Key is required to sign the Quote generated by the
602 TPM to report evidence of software configuration.
604 In TPM application, the Attestation key MUST be protected by the TPM,
605 and the DevID SHOULD be as well. Depending on other TPM
606 configuration procedures, the two keys are likely be different; some
607 of the considerations are outlined in TCG Guidance for Securing
608 Network Equipment [NetEq].
610 TCG Guidance for Securing Network Equipment specifies further
611 conventions for these keys:
613 o When separate Identity and Attestation keys are used, the
614 Attestation Key (AK) and its X.509 certificate should parallel the
615 DevID, with the same device ID information as the DevID
616 certificate (i.e., the same Subject Name and Subject Alt Name,
617 even though the key pairs are different). This allows a quote
618 from the device, signed by an AK, to be linked directly to the
619 device that provided it, by examining the corresponding AK
620 certificate.
622 o Network devices that are expected to use secure zero touch
623 provisioning as specified in [RFC8572]) MUST be shipped by the
624 manufacturer with pre-provisioned keys (Initial DevID and AK,
625 called IDevID and IAK). Inclusion of an IDevID and IAK by a
626 vendor does not preclude a mechanism whereby an Administrator can
627 define Local Identity and Attestation Keys (LDevID and LAK) if
628 desired. IDevID and IAK certificates MUST both be signed by the
629 Endorser (typically the device manufacturer).
631 2.3. RIV Information Flow
633 RIV workflow for networking equipment is organized around a simple
634 use case where a network operator wishes to verify the integrity of
635 software installed in specific, fielded devices. This use case
636 implies several components:
638 1. The Attesting Device, which the network operator wants to
639 examine.
641 2. A Verifier (which might be a network management station)
642 somewhere separate from the Device that will retrieve the
643 information and analyze it to pass judgment on the security
644 posture of the device.
646 3. A Relying Party, which can act on Attestation Results.
647 Interaction between the Relying Party and the Verifier is
648 considered out of scope for RIV.
650 4. Signed Reference Integrity Manifests (RIMs), containing Reference
651 Integrity Measurements, can either be created by the device
652 manufacturer and shipped along with the device as part of its
653 software image, or alternatively, could be obtained several other
654 ways (direct to the Verifier from the manufacturer, from a third
655 party, from the owner's observation of what's thought to be a
656 "known good system", etc.). Retrieving RIMs from the device
657 itself allows attestation to be done in systems that may not have
658 access to the public internet, or by other devices that are not
659 management stations per se (e.g., a peer device; see
660 Section 3.1.3). If Reference Integrity Measurements are obtained
661 from multiple sources, the Verifier may need to evaluate the
662 relative level of trust to be placed in each source in case of a
663 discrepancy.
665 These components are illustrated in Figure 3.
667 A more-detailed taxonomy of terms is given in
668 [I-D.ietf-rats-architecture]
670 +---------------+ +-------------+ +---------+--------+
671 | | | Attester | Step 1 | Verifier| |
672 | Endorser | | (Device |<-------| (Network| Relying|
673 | (Device | | under |------->| Mngmt | Party |
674 | Manufacturer | | attestation)| Step 2 | Station)| |
675 | or other | | | | | |
676 | authority) | | | | | |
677 +---------------+ +-------------+ +---------+--------+
678 | /\
679 | Step 0 |
680 -----------------------------------------------
682 Figure 3: RIV Reference Configuration for Network Equipment
684 In Step 0, The Endorser (the device manufacturer or other authority)
685 provides a software image to the Attester (the device under
686 attestation), and makes one or more Reference Integrity Manifests
687 (RIMs) signed by the Endorser, available to the Verifier (see
688 Section 3.1.3 for "in-band" and "out of band" ways to make this
689 happen). In Step 1, the Verifier (Network Management Station), on
690 behalf of a Relying Party, requests Identity, Measurement Values, and
691 possibly RIMs, from the Attester. In Step 2, the Attester responds
692 to the request by providing a DevID, quotes (measured values, signed
693 by the Attester), and optionally RIMs.
695 To achieve interoperability, the following standards components
696 SHOULD be used:
698 1. TPM Keys MUST be configured according to
699 [Platform-DevID-TPM-2.0], [PC-Client-BIOS-TPM-1.2], or
700 [Platform-ID-TPM-1.2].
702 2. For devices using UEFI and Linux, measurements of firmware and
703 bootable modules SHOULD be taken according to TCG PC Client
704 [PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA]
706 3. Device Identity MUST be managed as specified in IEEE 802.1AR
707 Device Identity certificates [IEEE-802-1AR], with keys protected
708 by TPMs.
710 4. Attestation logs SHOULD be formatted according to the Canonical
711 Event Log format [Canonical-Event-Log], although other
712 specialized formats may be used. UEFI-based systems MAY use the
713 TCG UEFI BIOS event log [EFI-TPM]).
715 5. Quotes are retrieved from the TPM according to the TCG TAP
716 Information Model [TAP]. While the TAP IM gives a protocol-
717 independent description of the data elements involved, it's
718 important to note that quotes from the TPM are signed inside the
719 TPM, so MUST be retrieved in a way that does not invalidate the
720 signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to
721 preserve the trust model. (See Section 5 Security
722 Considerations).
724 6. Reference Integrity Measurements SHOULD be encoded as CoSWID
725 tags, as defined in the TCG RIM document [RIM], compatible with
726 NIST IR 8060 [NIST-IR-8060] and the IETF CoSWID draft
727 [I-D.ietf-sacm-coswid]. See Section 2.4.1.
729 2.4. RIV Simplifying Assumptions
731 This document makes the following simplifying assumptions to reduce
732 complexity:
734 o The product to be attested MUST be shipped with an IEEE 802.1AR
735 Device Identity and an Initial Attestation Key (IAK) with
736 certificate. The IAK cert contains the same identity information
737 as the DevID (specifically, the same Subject Name and Subject Alt
738 Name, signed by the manufacturer), but it's a type of key that can
739 be used to sign a TPM Quote. This convention is described in TCG
740 Guidance for Securing Network Equipment [NetEq]. For network
741 equipment, which is generally non-privacy-sensitive, shipping a
742 device with both an IDevID and an IAK already provisioned
743 substantially simplifies initial startup. Privacy-sensitive
744 applications may use the TCG Platform Certificate and additional
745 procedures to install identity credentials into the device after
746 manufacture.
748 o The product MUST be equipped with a Root of Trust for Measurement,
749 Root of Trust for Storage and Root of Trust for Reporting (as
750 defined in [SP800-155]) that are capable of conforming to the TCG
751 Trusted Attestation Protocol (TAP) Information Model [TAP].
753 o The authorized software supplier MUST make available Reference
754 Integrity Measurements (i.e., known-good measurements) in the form
755 of signed CoSWID tags [I-D.ietf-sacm-coswid], [SWID], as described
756 in TCG Reference Integrity Measurement Manifest Information Model
757 [RIM].
759 2.4.1. Reference Integrity Manifests (RIMs)
761 [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and
762 transmitting evidence in the form of PCR measurements and attestation
763 logs. But the critical part of the process is enabling the Verifier
764 to decide whether the measurements are "the right ones" or not.
766 While it must be up to network administrators to decide what they
767 want on their networks, the software supplier should supply the
768 Reference Integrity Measurements that may be used by a Verifier to
769 determine if evidence shows known good, known bad or unknown software
770 configurations.
772 In general, there are two kinds of reference measurements:
774 1. Measurements of early system startup (e.g., BIOS, boot loader, OS
775 kernel) are essentially single-threaded, and executed exactly
776 once, in a known sequence, before any results could be reported.
777 In this case, while the method for computing the hash and
778 extending relevant PCRs may be complicated, the net result is
779 that the software (more likely, firmware) vendor will have one
780 known good PCR value that "should" be present in the relevant
781 PCRs after the box has booted. In this case, the signed
782 reference measurement could simply list the expected hashes for
783 the given version. However, a RIM that contains the intermediate
784 hashes can be useful in debugging cases where the expected final
785 hash is not the one reported.
787 2. Measurements taken later in operation of the system, once an OS
788 has started (for example, Linux IMA[IMA]), may be more complex,
789 with unpredictable "final" PCR values. In this case, the
790 Verifier must have enough information to reconstruct the expected
791 PCR values from logs and signed reference measurements from a
792 trusted authority.
794 In both cases, the expected values can be expressed as signed SWID or
795 CoSWID tags, but the SWID structure in the second case is somewhat
796 more complex, as reconstruction of the extended hash in a PCR may
797 involve thousands of files and other objects.
799 The TCG has published an information model defining elements of
800 reference integrity manifests under the title TCG Reference Integrity
801 Manifest Information Model [RIM]. This information model outlines
802 how SWID tags should be structured to allow attestation, and defines
803 "bundles" of SWID tags that may be needed to describe a complete
804 software release. The RIM contains metadata relating to the software
805 release it belongs to, plus hashes for each individual file or other
806 object that could be attested.
808 TCG has also published the PC Client Reference Integrity Measurement
809 specification [PC-Client-RIM], which focuses on a SWID-compatible
810 format suitable for expressing expected measurement values in the
811 specific case of a UEFI-compatible BIOS, where the SWID focus on
812 files and file systems is not a direct fit. While the PC Client RIM
813 is not directly applicable to network equipment, many vendors do use
814 a conventional UEFI BIOS to launch their network OS.
816 2.4.2. Attestation Logs
818 Quotes from a TPM can provide evidence of the state of a device up to
819 the time the evidence was recorded, but to make sense of the quote in
820 most cases an event log that identifies which software modules
821 contributed which values to the quote during startup MUST also be
822 provided. The log MUST contain enough information to demonstrate its
823 integrity by allowing exact reconstruction of the digest conveyed in
824 the signed quote (i.e., PCR values).
826 There are multiple event log formats which may be supported as viable
827 formats of Evidence between the Attester and Verifier:
829 o Event log exports from [I-D.ietf-rats-yang-tpm-charra]
831 o IMA Event log file exports [IMA]
833 o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM
834 Family 1.1 or 1.2, Section 7) [EFI-TPM])
836 o TCG Canonical Event Log [Canonical-Event-Log]
838 Devices which use UEFI BIOS and Linux SHOULD use TCG Canonical Event
839 Log [Canonical-Event-Log] and TCG UEFI BIOS event log [EFI-TPM])
841 3. Standards Components
843 3.1. Prerequisites for RIV
845 The Reference Interaction Model for Challenge-Response-based Remote
846 Attestation is based on the standard roles defined in
847 [I-D.ietf-rats-architecture]. However additional prerequisites have
848 been established to allow for interoperable RIV use case
849 implementations. These prerequisites are intended to provide
850 sufficient context information so that the Verifier can acquire and
851 evaluate Attester measurements.
853 3.1.1. Unique Device Identity
855 A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID
856 certificate [IEEE-802-1AR] MUST be provisioned in the Attester's
857 TPMs.
859 3.1.2. Keys
861 The Attestation Identity Key (AIK) and certificate MUST also be
862 provisioned on the Attester according to [Platform-DevID-TPM-2.0],
863 [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2].
865 The Attester's TPM Keys MUST be associated with the DevID on the
866 Verifier (see [Platform-DevID-TPM-2.0] and Section 5 Security
867 Considerations, below).
869 3.1.3. Appraisal Policy for Evidence
871 The Verifier MUST obtain trustworthy Endorsements in the form of
872 reference measurements (e.g., Known Good Values, encoded as CoSWID
873 tags [I-D.birkholz-yang-swid]). These reference measurements will
874 eventually be compared to signed PCR Evidence acquired from an
875 Attester's TPM using Attestation Policies chosen by the administrator
876 or owner of the device.
878 This document does not specify the format or contents for the
879 Appraisal Policy for Evidence, but Endorsements may be acquired in
880 one of two ways:
882 1. a Verifier may obtain reference measurements directly from an
883 Endorser chosen by the Verifier administrator (e.g., through a
884 web site).
886 2. Signed reference measurements may be distributed by the Endorser
887 to the Attester, as part of a software update. From there, the
888 reference measurement may be acquired by the Verifier.
890 In either case, the Verifier Owner MUST select the source of trusted
891 endorsements through the Appraisal Policy for Evidence.
893 ************* .-------------. .-----------.
894 * Endorser * | Attester | | Verifier/ |
895 * * | | | Relying |
896 *(Device *----2--->| (Network |----2--->| Party |
897 * config * | Device) | |(Ntwk Mgmt |
898 * Authority)* | | | Station) |
899 ************* '-------------' '-----------'
900 | ^
901 | |
902 '----------------1--------------------------'
904 Figure 4: Appraisal Policy for Evidence Prerequisites
906 In either case the Endorsements must be generated, acquired and
907 delivered in a secure way, including reference measurements of
908 firmware and bootable modules taken according to TCG PC Client
909 [PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA]. Endorsementa MUST be
910 encoded as SWID or CoSWID tags, signed by the device manufacturer, as
911 defined in the TCG RIM document [RIM], compatible with NIST IR 8060
912 [NIST-IR-8060] or the IETF CoSWID draft [I-D.ietf-sacm-coswid].
914 3.2. Reference Model for Challenge-Response
916 Once the prerequisites for RIV are met, a Verifier is able to acquire
917 Evidence from an Attester. The following diagram illustrates a RIV
918 information flow between a Verifier and an Attester, derived from
919 Section 8.1 of [I-D.birkholz-rats-reference-interaction-model].
920 Event times shown correspond to the time types described within
921 Appendix A of [I-D.ietf-rats-architecture]:
923 .----------. .--------------------------.
924 | Attester | | Relying Party / Verifier |
925 '----------' '--------------------------'
926 time(VG) |
927 valueGeneration(targetEnvironment) |
928 | => claims |
929 | |
930 | <--------------requestEvidence(nonce, PcrSelection)-----time(NS)
931 | |
932 time(EG) |
933 evidenceGeneration(nonce, PcrSelection, collectedClaims) |
934 | => SignedPcrEvidence(nonce, PcrSelection) |
935 | => LogEvidence(collectedClaims) |
936 | |
937 | returnSignedPcrEvidence----------------------------------> |
938 | returnLogEvidence----------------------------------------> |
939 | |
940 | time(RG,RA)
941 | evidenceAppraisal(SignedPcrEvidence, eventLog, refClaims)
942 | attestationResult <= |
943 ~ ~
944 | time(RX)
946 Figure 5: IETF Attestation Information Flow
948 o Step 1 (time(VG)): One or more Attesting Network Device PCRs are
949 extended with measurements. RIV provides no direct link between
950 the time at which the event takes place and the time that it's
951 attested, although streaming attestation as in
952 [I-D.birkholz-rats-network-device-subscription] could.
954 o Step 2 (time(NS)): The Verifier generates a unique nonce ("number
955 used once"), and makes a request attestation data for one or more
956 PCRs from an Attester. For interoperability, this MUST be
957 accomplished via a YANG [RFC7950] interface that implements the
958 TCG TAP model (e.g., YANG Module for Basic Challenge-Response-
959 based Remote Attestation Procedures
960 [I-D.ietf-rats-yang-tpm-charra]).
962 o Step 3 (time(EG)): On the Attester, measured values are retrieved
963 from the Attester's TPM. This requested PCR evidence is signed by
964 the Attestation Identity Key (AIK) associated with the DevID.
965 Quotes are retrieved according to TCG TAP Information Model [TAP].
966 While the TAP IM gives a protocol-independent description of the
967 data elements involved, it's important to note that quotes from
968 the TPM are signed inside the TPM, so must be retrieved in a way
969 that does not invalidate the signature, as specified in
970 [I-D.ietf-rats-yang-tpm-charra], to preserve the trust model.
972 (See Section 5 Security Considerations). At the same time, the
973 Attester collects log evidence showing what values have been
974 extended into that PCR.
976 o Step 4: Collected Evidence is passed from the Attester to the
977 Verifier
979 o Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes
980 action as needed. As the interaction between Relying Party and
981 Verifier is out of scope for RIV, this can happen in one step.
983 * If the signed PCR values do not match the set of log entries
984 which have extended a particular PCR, the device SHOULD NOT be
985 trusted.
987 * If the log entries that the Verifier considers important do not
988 match known good values, the device SHOULD NOT be trusted. We
989 note that the process of collecting and analyzing the log can
990 be omitted if the value in the relevant PCR is already a known-
991 good value.
993 * If the set of log entries are not seen as acceptable by the
994 Appraisal Policy for Evidence, the device SHOULD NOT be
995 trusted.
997 * If the AIK signature is not correct, or freshness such as that
998 provided by the nonce is not included in the response, the
999 device SHOULD NOT be trusted.
1001 * If time(RG)-time(NS) is greater than the threshold in the
1002 Appraisal Policy for Evidence, the Evidence is considered stale
1003 and SHOULD NOT be trusted.
1005 3.2.1. Transport and Encoding
1007 Network Management systems may retrieve signed PCR based Evidence as
1008 shown in Figure 5, and can be accomplished via NETCONF or RESTCONF,
1009 with XML, JSON, or CBOR encoded Evidence.
1011 Implementations that use NETCONF MUST do so over a TLS or SSH secure
1012 tunnel. Implementations that use RESTCONF transport MAY do so over a
1013 TLS or SSH secure tunnel.
1015 Retrieval of Log Evidence SHOULD be via log interfaces on the network
1016 device. (For example, see [I-D.ietf-rats-yang-tpm-charra]).
1018 3.3. Centralized vs Peer-to-Peer
1020 Figure 5 above assumes that the Verifier is implicitly trusted, while
1021 the Attesting device is not. In a Peer-to-Peer application such as
1022 two routers negotiating a trust relationship
1023 [I-D.voit-rats-trusted-path-routing], the two peers can each ask the
1024 other to prove software integrity. In this application, the
1025 information flow is the same, but each side plays a role both as an
1026 Attester and a Verifier. Each device issues a challenge, and each
1027 device responds to the other's challenge, as shown in Figure 6.
1028 Peer-to-peer challenges, particularly if used to establish a trust
1029 relationship between routers, require devices to carry their own
1030 signed reference measurements (RIMs). Devices may also have to carry
1031 Appraisal Policy for Evidence for each possible peer device so that
1032 each device has everything needed for attestation, without having to
1033 resort to a central authority.
1035 +---------------+ +---------------+
1036 | | | |
1037 | Endorser A | | Endorser B |
1038 | Firmware | | Firmware |
1039 | Configuration | | Configuration |
1040 | Authority | | Authority |
1041 | | | |
1042 +---------------+ +---------------+
1043 | |
1044 | +-------------+ +------------+ |
1045 | | | Step 1 | | | \
1046 | | Attester |<------>| Verifier | | |
1047 | | |<------>| | | | Router B
1048 +------>| | Step 2 | | | |- Challenges
1049 Step 0A| | | | | | Router A
1050 | |------->| | | |
1051 |- Router A --| Step 3 |- Router B -| | /
1052 | | | | |
1053 | | | | |
1054 | | Step 1 | | | \
1055 | Verifier |<------>| Attester |<-+ | Router A
1056 | |<------>| | |- Challenges
1057 | | Step 2 | | | Router B
1058 | | | | |
1059 | |<-------| | |
1060 +-------------+ Step 3 +------------+ /
1062 Figure 6: Peer-to-Peer Attestation Information Flow
1064 In this application, each device may need to be equipped with signed
1065 RIMs to act as an Attester, and also an Appraisal Policy for Evidence
1066 and a selection of trusted X.509 root certificates, to allow the
1067 device to act as a Verifier. An existing link layer protocol such as
1068 802.1x [IEEE-802.1x] or 802.1AE [IEEE-802.1ae], with Evidence being
1069 enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable
1070 methods for such an exchange.
1072 4. Privacy Considerations
1074 Networking Equipment, such as routers, switches and firewalls, has a
1075 key role to play in guarding the privacy of individuals using the
1076 network:
1078 o Packets passing through the device must not be sent to
1079 unauthorized destinations. For example:
1081 * Routers often act as Policy Enforcement Points, where
1082 individual subscribers may be checked for authorization to
1083 access a network. Subscriber login information must not be
1084 released to unauthorized parties.
1086 * Networking Equipment is often called upon to block access to
1087 protected resources from unauthorized users.
1089 o Routing information, such as the identity of a router's peers,
1090 must not be leaked to unauthorized neighbors.
1092 o If configured, encryption and decryption of traffic must be
1093 carried out reliably, while protecting keys and credentials.
1095 Functions that protect privacy are implemented as part of each layer
1096 of hardware and software that makes up the networking device. In
1097 light of these requirements for protecting the privacy of users of
1098 the network, the Network Equipment must identify itself, and its boot
1099 configuration and measured device state (for example, PCR values), to
1100 the Equipment's Administrator, so there's no uncertainty as to what
1101 function each device and configuration is configured to carry out.
1102 This allows the administrator to ensure that the network provides
1103 individual and peer privacy guarantees.
1105 RIV specifically addresses the collection of information from
1106 enterprise network devices by authorized agents of the enterprise.
1107 As such, privacy is a fundamental concern for those deploying this
1108 solution, given EU GDPR, California CCPA, and many other privacy
1109 regulations. The enterprise SHOULD implement and enforce their duty
1110 of care.
1112 See [NetEq] for more context on privacy in networking devices.
1114 5. Security Considerations
1116 Attestation Results from the RIV procedure are subject to a number of
1117 attacks:
1119 o Keys may be compromised.
1121 o A counterfeit device may attempt to impersonate (spoof) a known
1122 authentic device.
1124 o Man-in-the-middle attacks may be used by a counterfeit device to
1125 attempt to deliver responses that originate in an actual authentic
1126 device.
1128 o Replay attacks may be attempted by a compromised device.
1130 5.1. Keys Used in RIV
1132 Trustworthiness of RIV attestation depends strongly on the validity
1133 of keys used for identity and attestation reports. RIV takes full
1134 advantage of TPM capabilities to ensure that results can be trusted.
1136 Two sets of keys are relevant to RIV attestation:
1138 o A DevID key is used to certify the identity of the device in which
1139 the TPM is installed.
1141 o An Attestation Key (AK) key signs attestation reports (called
1142 'quotes' in TCG documents), used to provide evidence for integrity
1143 of the software on the device.
1145 TPM practices usually require that these keys be different, as a way
1146 of ensuring that a general-purpose signing key cannot be used to
1147 spoof an attestation quote.
1149 In each case, the private half of the key is known only to the TPM,
1150 and cannot be retrieved externally, even by a trusted party. To
1151 ensure that's the case, specification-compliant private/public key-
1152 pairs are generated inside the TPM, where they're never exposed, and
1153 cannot be extracted (See [Platform-DevID-TPM-2.0]).
1155 Keeping keys safe is just part of attestation security; knowing which
1156 keys are bound to the device in question is just as important.
1158 While there are many ways to manage keys in a TPM (see
1159 [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch"
1160 provisioning (also known as zero-touch onboarding) of fielded devices
1161 (e.g., Secure ZTP, [RFC8572]), where keys which have predictable
1162 trust properties are provisioned by the device vendor.
1164 Device identity in RIV is based on IEEE 802.1AR Device Identity
1165 (DevID). This specification provides several elements:
1167 o A DevID requires a unique key pair for each device, accompanied by
1168 an X.509 certificate,
1170 o The private portion of the DevID key is to be stored in the
1171 device, in a manner that provides confidentiality (Section 6.2.5
1172 [IEEE-802-1AR])
1174 The X.509 certificate contains several components:
1176 o The public part of the unique DevID key assigned to that device
1177 allows a challenge of identity.
1179 o An identifying string that's unique to the manufacturer of the
1180 device. This is normally the serial number of the unit, which
1181 might also be printed on a label on the device.
1183 o The certificate must be signed by a key traceable to the
1184 manufacturer's root key.
1186 With these elements, the device's manufacturer and serial number can
1187 be identified by analyzing the DevID certificate plus the chain of
1188 intermediate certificates leading back to the manufacturer's root
1189 certificate. As is conventional in TLS or SSH connections, a nonce
1190 must be signed by the device in response to a challenge, proving
1191 possession of its DevID private key.
1193 RIV uses the DevID to validate a TLS or SSH connection to the device
1194 as the attestation session begins. Security of this process derives
1195 from TLS or SSH security, with the DevID providing proof that the
1196 session terminates on the intended device. See [RFC8446], [RFC4253].
1198 Evidence of software integrity is delivered in the form of a quote
1199 signed by the TPM itself. Because the contents of the quote are
1200 signed inside the TPM, any external modification (including
1201 reformatting to a different data format) after measurements have been
1202 taken will be detected as tampering. An unbroken chain of trust is
1203 essential to ensuring that blocks of code that are taking
1204 measurements have been verified before execution (see Figure 1.
1206 Requiring results of attestation of the operating software to be
1207 signed by a key known only to the TPM also removes the need to trust
1208 the device's operating software (beyond the first measurement; see
1209 below); any changes to the quote, generated and signed by the TPM
1210 itself, made by malicious device software, or in the path back to the
1211 Verifier, will invalidate the signature on the quote.
1213 A critical feature of the YANG model described in
1214 [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data
1215 structures in their native format, without requiring any changes to
1216 the structures as they were signed and delivered by the TPM. While
1217 alternate methods of conveying TPM quotes could compress out
1218 redundant information, or add an additional layer of signing using
1219 external keys, the implementation MUST preserve the TPM signing, so
1220 that tampering anywhere in the path between the TPM itself and the
1221 Verifier can be detected.
1223 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks
1225 Prevention of spoofing attacks against attestation systems is also
1226 important. There are two cases to consider:
1228 o The entire device could be spoofed, that is, when the Verifier
1229 goes to verify a specific device, it might be redirected to a
1230 different device. Use of the 802.1AR Device Identity (DevID) in
1231 the TPM ensures that the Verifier's TLS or SSH session is in fact
1232 terminating on the right device.
1234 o A compromised device could respond with a spoofed Attestation
1235 Result, that is, a compromised OS could return a fabricated quote.
1237 Protection against spoofed quotes from a device with valid identity
1238 is a bit more complex. An identity key must be available to sign any
1239 kind of nonce or hash offered by the Verifier, and consequently,
1240 could be used to sign a fabricated quote. To block a spoofed
1241 Attestation Result, the quote generated inside the TPM must be signed
1242 by a key that's different from the DevID, called an Attestation Key
1243 (AK).
1245 Given separate Attestation and DevID keys, the binding between the AK
1246 and the same device must also be proven to prevent a man-in-the-
1247 middle attack (e.g., the 'Asokan Attack' [RFC6813]).
1249 This is accomplished in RIV through use of an AK certificate with the
1250 same elements as the DevID (i.e., same manufacturer's serial number,
1251 signed by the same manufacturer's key), but containing the device's
1252 unique AK public key instead of the DevID public key.
1254 [Editor's Note: does this require an OID that says the key is known
1255 by the CA to be an Attestation key?]
1256 These two keys and certificates are used together:
1258 o The DevID is used to validate a TLS connection terminating on the
1259 device with a known serial number.
1261 o The AK is used to sign attestation quotes, providing proof that
1262 the attestation evidence comes from the same device.
1264 5.3. Replay Attacks
1266 Replay attacks, where results of a previous attestation are submitted
1267 in response to subsequent requests, are usually prevented by
1268 inclusion of a nonce in the request to the TPM for a quote. Each
1269 request from the Verifier includes a new random number (a nonce).
1270 The resulting quote signed by the TPM contains the same nonce,
1271 allowing the Verifier to determine freshness, (i.e., that the
1272 resulting quote was generated in response to the Verifier's specific
1273 request). Time-Based Uni-directional Attestation
1274 [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify
1275 freshness without requiring a request/response cycle.
1277 5.4. Owner-Signed Keys
1279 Although device manufacturers MUST pre-provision devices with easily
1280 verified DevID and AK certificates, use of those credentials is not
1281 mandatory. IEEE 802.1AR incorporates the idea of an Initial Device
1282 ID (IDevID), provisioned by the manufacturer, and a Local Device ID
1283 (LDevID) provisioned by the owner of the device. RIV and
1284 [Platform-DevID-TPM-2.0] extends that concept by defining an Initial
1285 Attestation Key (IAK) and Local Attestation Key (LAK) with the same
1286 properties.
1288 Device owners can use any method to provision the Local credentials.
1290 o The TCG document [Platform-DevID-TPM-2.0] shows how the initial
1291 Attestation keys can be used to certify LDevID and LAK keys. Use
1292 of the LDevID and LAK allows the device owner to use a uniform
1293 identity structure across device types from multiple manufacturers
1294 (in the same way that an "Asset Tag" is used by many enterprises
1295 to identify devices they own). The TCG document
1296 [Provisioning-TPM-2.0] also contains guidance on provisioning
1297 identity keys in TPM 2.0.
1299 o Device owners, however, can use any other mechanism they want to
1300 assure themselves that Local identity certificates are inserted
1301 into the intended device, including physical inspection and
1302 programming in a secure location, if they prefer to avoid placing
1303 trust in the manufacturer-provided keys.
1305 Clearly, Local keys can't be used for secure Zero Touch provisioning;
1306 installation of the Local keys can only be done by some process that
1307 runs before the device is installed for network operation.
1309 On the other end of the device life cycle, provision should be made
1310 to wipe Local keys when a device is decommissioned, to indicate that
1311 the device is no longer owned by the enterprise. The manufacturer's
1312 Initial identity keys must be preserved, as they contain no
1313 information that's not already printed on the device's serial number
1314 plate.
1316 5.5. Other Trust Anchors
1318 In addition to trustworthy provisioning of keys, RIV depends on other
1319 trust anchors. (See [SP800-155] for definitions of Roots of Trust.)
1321 o Secure identity depends on mechanisms to prevent per-device secret
1322 keys from being compromised. The TPM provides this capability as
1323 a Root of Trust for Storage.
1325 o Attestation depends on an unbroken chain of measurements, starting
1326 from the very first measurement. That first measurement is made
1327 by code called the Root of Trust for Measurement, typically done
1328 by trusted firmware stored in boot flash. Mechanisms for
1329 maintaining the trustworthiness of the RTM are out of scope for
1330 RIV, but could include immutable firmware, signed updates, or a
1331 vendor-specific hardware verification technique. See Section 8.1
1332 for background on TPM practices.
1334 o The device owner SHOULD provide some level of physical defense for
1335 the device. If a TPM that has already been programmed with an
1336 authentic DevID is stolen and inserted into a counterfeit device,
1337 attestation of that counterfeit device may become
1338 indistinguishable from an authentic device.
1340 RIV also depends on reliable reference measurements, as expressed by
1341 the RIM [RIM]. The definition of trust procedures for RIMs is out of
1342 scope for RIV, and the device owner is free to use any policy to
1343 validate a set of reference measurements. RIMs may be conveyed out-
1344 of-band or in-band, as part of the attestation process (see
1345 Section 3.1.3). But for embedded devices, where software is usually
1346 shipped as a self-contained package, RIMs signed by the manufacturer
1347 and delivered in-band may be more convenient for the device owner.
1349 The validity of RIV attestation results is also influenced by
1350 procedures used to create reference measurements:
1352 o While the RIM itself is signed, supply-chains SHOULD be carefully
1353 scrutinized to ensure that the values are not subject to
1354 unexpected manipulation prior to signing. Insider-attacks against
1355 code bases and build chains are particularly hard to spot.
1357 o Designers SHOULD guard against hash collision attacks. Reference
1358 Integrity Measurements often give hashes for large objects of
1359 indeterminate size; if one of the measured objects can be replaced
1360 with an implant engineered to produce the same hash, RIV will be
1361 unable to detect the substitution. TPM1.2 uses SHA-1 hashes only,
1362 which have been shown to be susceptible to collision attack.
1363 TPM2.0 will produce quotes with SHA-256, which so far has resisted
1364 such attacks. Consequently RIV implementations SHOULD use TPM2.0.
1366 6. Conclusion
1368 TCG technologies can play an important part in the implementation of
1369 Remote Integrity Verification. Standards for many of the components
1370 needed for implementation of RIV already exist:
1372 o Platform identity can be based on IEEE 802.1AR Device Identity,
1373 coupled with careful supply-chain management by the manufacturer.
1375 o Complex supply chains can be certified using TCG Platform
1376 Certificates [Platform-Certificates].
1378 o The TCG TAP mechanism can be used to retrieve attestation
1379 evidence. Work is needed on a YANG model for this protocol.
1381 o Reference Integrity Measurements must be conveyed from the
1382 software authority (e.g., the manufacturer) to the system in which
1383 verification will take place. IETF CoSWID work forms the basis
1384 for this, but new work is needed to create an information model
1385 and YANG implementation.
1387 7. IANA Considerations
1389 This memo includes no request to IANA.
1391 8. Appendix
1393 8.1. Using a TPM for Attestation
1395 The Trusted Platform Module and surrounding ecosystem provide three
1396 interlocking capabilities to enable secure collection of evidence
1397 from a remote device, Platform Configuration Registers (PCRs), a
1398 Quote mechanism, and a standardized Event Log.
1400 Each TPM has at least between eight and twenty-four PCRs (depending
1401 on the profile and vendor choices), each one large enough to hold one
1402 hash value (SHA-1, SHA-256, and other hash algorithms can be used,
1403 depending on TPM version). PCRs can't be accessed directly from
1404 outside the chip, but the TPM interface provides a way to "extend" a
1405 new security measurement hash into any PCR, a process by which the
1406 existing value in the PCR is hashed with the new security measurement
1407 hash, and the result placed back into the same PCR. The result is a
1408 composite fingerprint of all the security measurements extended into
1409 each PCR since the system was reset.
1411 Every time a PCR is extended, an entry should be added to the
1412 corresponding Event Log. Logs contain the security measurement hash
1413 plus informative fields offering hints as to what event it was that
1414 generated the security measurement.
1415 The Event Log itself is protected against accidental manipulation,
1416 but it is implicitly tamper-evident - any verification process can
1417 read the security measurement hash from the log events, compute the
1418 composite value and compare that to what ended up in the PCR. If
1419 there's a discrepancy, the logs do not provide an accurate view of
1420 what was placed into the PCR.
1422 In a conventional TPM Attestation environment, the first measurement
1423 must be made and extended into the TPM by trusted device code (called
1424 the Root of Trust for Measurement, RTM). That first measurement
1425 should cover the segment of code that is run immediately after the
1426 RTM, which then measures the next code segment before running it, and
1427 so on, forming an unbroken chain of trust. See [TCGRoT] for more on
1428 Mutable vs Immutable roots of trust.
1430 The TPM provides another mechanism called a Quote that can read the
1431 current value of the PCRs and package them into a data structure
1432 signed by an Attestation Key (which is private key that is known only
1433 to the TPM).
1435 The Verifier uses the Quote and Log together. The Quote, containing
1436 the composite hash of the complete sequence of security measurement
1437 hashes, is used to verify the integrity of the Event Log. Each hash
1438 in the validated Quote can then be compared to corresponding expected
1439 values in the set of Reference Integrity Measurements to validate
1440 overall system integrity.
1442 A summary of information exchanged in obtaining quotes from TPM1.2
1443 and TPM2.0 can be found in [TAP], Section 4. Detailed information
1444 about PCRs and Quote data structures can be found in [TPM1.2],
1445 [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0]
1446 and [Canonical-Event-Log].
1448 8.2. Root of Trust for Measurement
1450 The measurements needed for attestation require that the device being
1451 attested is equipped with a Root of Trust for Measurement, that is,
1452 some trustworthy mechanism that can compute the first measurement in
1453 the chain of trust required to attest that each stage of system
1454 startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs)
1455 to record the results, and a Root of Trust for Reporting to report
1456 the results [TCGRoT], [SP800-155].
1458 While there are many complex aspects of a Root of Trust, two aspects
1459 that are important in the case of attestation are:
1461 o The first measurement computed by the Root of Trust for
1462 Measurement, and stored in the TPM's Root of Trust for Storage, is
1463 presumed to be correct.
1465 o There must not be a way to reset the Root of Trust for Storage
1466 without re-entering the Root of Trust for Measurement code.
1468 The first measurement must be computed by code that is implicitly
1469 trusted; if that first measurement can be subverted, none of the
1470 remaining measurements can be trusted. (See [NIST-SP-800-155])
1472 8.3. Layering Model for Network Equipment Attester and Verifier
1474 Retrieval of identity and attestation state uses one protocol stack,
1475 while retrieval of Reference Measurements uses a different set of
1476 protocols. Figure 5 shows the components involved.
1478 +-----------------------+ +-------------------------+
1479 | | | |
1480 | Attester |<-------------| Verifier |
1481 | (Device) |------------->| (Management Station) |
1482 | | | | |
1483 +-----------------------+ | +-------------------------+
1484 |
1485 -------------------- --------------------
1486 | |
1487 ---------------------------------- ---------------------------------
1488 |Reference Integrity Measurements| | Attestation |
1489 ---------------------------------- ---------------------------------
1491 ********************************************************************
1492 * IETF Attestation Reference Interaction Diagram *
1493 ********************************************************************
1495 ....................... .......................
1496 . Reference Integrity . . TAP (PTS2.0) Info .
1497 . Manifest . . Model and Canonical .
1498 . . . Log Format .
1499 ....................... .......................
1501 ************************* .............. **********************
1502 * YANG SWID Module * . TCG . * YANG Attestation *
1503 * I-D.birkholz-yang-swid* . Attestation. * Module *
1504 * * . MIB . * I-D.ietf-rats- *
1505 * * . . * yang-tpm-charra *
1506 ************************* .............. **********************
1508 ************************* ************ ************************
1509 * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)*
1510 ************************* ************ ************************
1512 ************************* ************************
1513 * RESTCONF/NETCONF * * RESTCONF/NETCONF *
1514 ************************ *************************
1516 ************************* ************************
1517 * TLS, SSH * * TLS, SSH *
1518 ************************* ************************
1520 Figure 7: RIV Protocol Stacks
1522 IETF documents are captured in boxes surrounded by asterisks. TCG
1523 documents are shown in boxes surrounded by dots.
1525 8.3.1. Why is OS Attestation Different?
1527 Even in embedded systems, adding Attestation at the OS level (e.g.,
1528 Linux IMA, Integrity Measurement Architecture [IMA]) increases the
1529 number of objects to be attested by one or two orders of magnitude,
1530 involves software that's updated and changed frequently, and
1531 introduces processes that begin in an unpredictable order.
1533 TCG and others (including the Linux community) are working on methods
1534 and procedures for attesting the operating system and application
1535 software, but standardization is still in process.
1537 8.4. Implementation Notes
1539 Figure 8 summarizes many of the actions needed to complete an
1540 Attestation system, with links to relevant documents. While
1541 documents are controlled by several standards organizations, the
1542 implied actions required for implementation are all the
1543 responsibility of the manufacturer of the device, unless otherwise
1544 noted. It should be noted that, while the YANG model is RECOMMENDED
1545 for attestation, this table identifies an optional SNMP MIB as well,
1546 [Attest-MIB].
1548 +------------------------------------------------------------------+
1549 | Component | Controlling |
1550 | | Specification |
1551 --------------------------------------------------------------------
1552 | Make a Secure execution environment | TCG RoT |
1553 | o Attestation depends on a secure root of | UEFI.org |
1554 | trust for measurement outside the TPM, as | |
1555 | well as roots for storage and reporting | |
1556 | inside the TPM. | |
1557 | o Refer to TCG Root of Trust for Measurement.| |
1558 | o NIST SP 800-193 also provides guidelines | |
1559 | on Roots of Trust | |
1560 --------------------------------------------------------------------
1561 | Provision the TPM as described in | TCG TPM DevID |
1562 | TCG documents. | TCG Platform |
1563 | | Certificate |
1564 --------------------------------------------------------------------
1565 | Put a DevID or Platform Cert in the TPM | TCG TPM DevID |
1566 | o Install an Initial Attestation Key at the | TCG Platform |
1567 | same time so that Attestation can work out | Certificate |
1568 | of the box |-----------------
1569 | o Equipment suppliers and owners may want to | IEEE 802.1AR |
1570 | implement Local Device ID as well as | |
1571 | Initial Device ID | |
1572 --------------------------------------------------------------------
1573 | Connect the TPM to the TLS stack | Vendor TLS |
1574 | o Use the DevID in the TPM to authenticate | stack (This |
1575 | TAP connections, identifying the device | action is |
1576 | | simply |
1577 | | configuring TLS|
1578 | | to use the |
1579 | | DevID as its |
1580 | | trust anchor.) |
1581 --------------------------------------------------------------------
1582 | Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID |
1583 | o Add reference measurements into SWID tags | ISO/IEC 19770-2|
1584 | o Manufacturer should sign the SWID tags | NIST IR 8060 |
1585 | o The TCG RIM-IM identifies further | |
1586 | procedures to create signed RIM | |
1587 | documents that provide the necessary | |
1588 | reference information | |
1589 --------------------------------------------------------------------
1590 | Package the SWID tags with a vendor software | Retrieve tags |
1591 | release | with |
1592 | o A tag-generator plugin such | draft-birkholz-yang-swid|
1593 | as [SWID-Gen] can be used |----------------|
1594 | | TCG PC Client |
1595 | | RIM |
1596 --------------------------------------------------------------------
1597 | Use PC Client measurement definitions | TCG PC Client |
1598 | to define the use of PCRs | BIOS |
1599 | (although Windows OS is rare on Networking | |
1600 | Equipment, UEFI BIOS is not) | |
1601 --------------------------------------------------------------------
1602 | Use TAP to retrieve measurements | |
1603 | o Map TAP to SNMP | TCG SNMP MIB |
1604 | o Map to YANG | YANG Module for|
1605 | Use Canonical Log Format | Basic |
1606 | | Attestation |
1607 | | TCG Canonical |
1608 | | Log Format |
1609 --------------------------------------------------------------------
1610 | Posture Collection Server (as described in IETF | |
1611 | SACMs ECP) should request the | |
1612 | attestation and analyze the result | |
1613 | The Management application might be broken down | |
1614 | to several more components: | |
1615 | o A Posture Manager Server | |
1616 | which collects reports and stores them in | |
1617 | a database | |
1618 | o One or more Analyzers that can look at the| |
1619 | results and figure out what it means. | |
1620 --------------------------------------------------------------------
1621 Figure 8: Component Status
1623 9. References
1625 9.1. Normative References
1627 [Canonical-Event-Log]
1628 Trusted Computing Group, "DRAFT Canonical Event Log Format
1629 Version: 1.0, Revision: .12", October 2018.
1631 [I-D.birkholz-yang-swid]
1632 Birkholz, H., "Software Inventory YANG module based on
1633 Software Identifiers", draft-birkholz-yang-swid-02 (work
1634 in progress), October 2018.
1636 [I-D.ietf-rats-yang-tpm-charra]
1637 Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit,
1638 E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data
1639 Model for Challenge-Response-based Remote Attestation
1640 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-02
1641 (work in progress), June 2020.
1643 [I-D.ietf-sacm-coswid]
1644 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
1645 Waltermire, "Concise Software Identification Tags", draft-
1646 ietf-sacm-coswid-15 (work in progress), May 2020.
1648 [IEEE-802-1AR]
1649 Seaman, M., "802.1AR-2018 - IEEE Standard for Local and
1650 Metropolitan Area Networks - Secure Device Identity, IEEE
1651 Computer Society", August 2018.
1653 [PC-Client-BIOS-TPM-1.2]
1654 Trusted Computing Group, "TCG PC Client Specific
1655 Implementation Specification for Conventional BIOS,
1656 Specification Version 1.21 Errata, Revision 1.00",
1657 February 2012,
1658 .
1662 [PC-Client-BIOS-TPM-2.0]
1663 Trusted Computing Group, "PC Client Specific Platform
1664 Firmware Profile Specification Family "2.0", Level 00
1665 Revision 1.04", June 2019,
1666 .
1669 [PC-Client-RIM]
1670 Trusted Computing Group, "DRAFT: TCG PC Client Reference
1671 Integrity Manifest Specification, v.09", December 2019,
1672 .
1675 [Platform-DevID-TPM-2.0]
1676 Trusted Computing Group, "DRAFT: TPM Keys for Platform
1677 DevID for TPM2, Specification Version 0.7, Revision 0",
1678 October 2018.
1680 [Platform-ID-TPM-1.2]
1681 Trusted Computing Group, "TPM Keys for Platform Identity
1682 for TPM 1.2, Specification Version 1.0, Revision 3",
1683 August 2015, .
1686 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
1687 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
1688 January 2006, .
1690 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1691 and A. Bierman, Ed., "Network Configuration Protocol
1692 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1693 .
1695 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1696 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1697 .
1699 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1700 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1701 .
1703 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
1704 Touch Provisioning (SZTP)", RFC 8572,
1705 DOI 10.17487/RFC8572, April 2019,
1706 .
1708 [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity
1709 Manifest Information Model", June 2019,
1710 .
1713 [SWID] The International Organization for Standardization/
1714 International Electrotechnical Commission, "Information
1715 Technology Software Asset Management Part 2: Software
1716 Identification Tag, ISO/IEC 19770-2", October 2015,
1717 .
1719 [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol
1720 (TAP) Information Model for TPM Families 1.2 and 2.0 and
1721 DICE Family 1.0, Version 1.0, Revision 0.36", October
1722 2018, .
1725 9.2. Informative References
1727 [AIK-Enrollment]
1728 Trusted Computing Group, "TCG Infrastructure Working Group
1729 - A CMC Profile for AIK Certificate Enrollment Version
1730 1.0, Revision 7", March 2011,
1731 .
1735 [Attest-MIB]
1736 Trusted Computing Group, "SNMP MIB for TPM-Based
1737 Attestation, Version 0.8Revision 0.02", May 2018,
1738 .
1742 [EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification
1743 for TPM Family 1.1 or 1.2, Specification Version 1.22,
1744 Revision 15", January 2014,
1745 .
1748 [I-D.birkholz-rats-network-device-subscription]
1749 Birkholz, H., Voit, E., and W. Pan, "Attestation Event
1750 Stream Subscription", draft-birkholz-rats-network-device-
1751 subscription-00 (work in progress), June 2020.
1753 [I-D.birkholz-rats-reference-interaction-model]
1754 Birkholz, H., Eckel, M., Newton, C., and L. Chen,
1755 "Reference Interaction Models for Remote Attestation
1756 Procedures", draft-birkholz-rats-reference-interaction-
1757 model-03 (work in progress), July 2020.
1759 [I-D.birkholz-rats-tuda]
1760 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
1761 "Time-Based Uni-Directional Attestation", draft-birkholz-
1762 rats-tuda-03 (work in progress), July 2020.
1764 [I-D.ietf-rats-architecture]
1765 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
1766 W. Pan, "Remote Attestation Procedures Architecture",
1767 draft-ietf-rats-architecture-06 (work in progress),
1768 September 2020.
1770 [I-D.ietf-rats-eat]
1771 Mandyam, G., Lundblade, L., Ballesteros, M., and J.
1772 O'Donoghue, "The Entity Attestation Token (EAT)", draft-
1773 ietf-rats-eat-04 (work in progress), August 2020.
1775 [I-D.richardson-rats-usecases]
1776 Richardson, M., Wallace, C., and W. Pan, "Use cases for
1777 Remote Attestation common encodings", draft-richardson-
1778 rats-usecases-07 (work in progress), March 2020.
1780 [I-D.voit-rats-trusted-path-routing]
1781 Voit, E., "Trusted Path Routing", draft-voit-rats-trusted-
1782 path-routing-02 (work in progress), June 2020.
1784 [IEEE-802.1ae]
1785 Seaman, M., "802.1AE MAC Security (MACsec)", 2018,
1786 .
1788 [IEEE-802.1x]
1789 IEEE Computer Society, "802.1X-2020 - IEEE Standard for
1790 Local and Metropolitan Area Networks--Port-Based Network
1791 Access Control", February 2020,
1792 .
1794 [IMA] and , "Integrity Measurement Architecture", June 2019,
1795 .
1797 [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for
1798 Local and metropolitan area networks - Station and Media
1799 Access Control Connectivity Discovery", March 2016,
1800 .
1802 [NetEq] Trusted Computing Group, "TCG Guidance for Securing
1803 Network Equipment, Version 1.0, Revision 29", January
1804 2018, .
1807 [NIST-IR-8060]
1808 National Institute for Standards and Technology,
1809 "Guidelines for the Creation of Interoperable Software
1810 Identification (SWID) Tags", April 2016,
1811 .
1814 [NIST-SP-800-155]
1815 National Institute for Standards and Technology, "BIOS
1816 Integrity Measurement Guidelines (Draft)", December 2011,
1817 .
1820 [Platform-Certificates]
1821 Trusted Computing Group, "TCG Platform Attribute
1822 Credential Profile, Specification Version 1.0, Revision
1823 16", January 2018,
1824 .
1827 [Provisioning-TPM-2.0]
1828 Trusted Computing Group, "TCG TPM v2.0 Provisioning
1829 Guidance, Version 1.0, Revision 1.0", March 2015,
1830 .
1833 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
1834 Levkowetz, Ed., "Extensible Authentication Protocol
1835 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
1836 .
1838 [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment
1839 (NEA) Asokan Attack Analysis", RFC 6813,
1840 DOI 10.17487/RFC6813, December 2012,
1841 .
1843 [SP800-155]
1844 National Institute of Standards and Technology, "BIOS
1845 Integrity Measurement Guidelines (Draft)", December 2011,
1846 .
1849 [SWID-Gen]
1850 Labs64, Munich, Germany, "SoftWare IDentification (SWID)
1851 Tags Generator (Maven Plugin)", n.d.,
1852 .
1854 [TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust
1855 Specification", October 2018,
1856 .
1859 [TPM1.2] Trusted Computing Group, "TPM Main Specification Level 2
1860 Version 1.2, Revision 116", March 2011,
1861 .
1864 [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library
1865 Specification, Family "2.0", Level 00, Revision 01.59",
1866 November 2019,
1867 .
1870 Authors' Addresses
1872 Guy Fedorkow (editor)
1873 Juniper Networks, Inc.
1874 US
1876 Email: gfedorkow@juniper.net
1878 Eric Voit
1879 Cisco Systems, Inc.
1880 US
1882 Email: evoit@cisco.com
1884 Jessica Fitzgerald-McKay
1885 National Security Agency
1886 US
1888 Email: jmfitz2@nsa.gov