idnits 2.17.1
draft-thaler-rats-architecture-01.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 abstract seems to contain references ([RFC4949]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (November 04, 2019) is 1635 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-19) exists of
draft-ietf-teep-architecture-03
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group D. Thaler
3 Internet-Draft Microsoft
4 Intended status: Informational November 04, 2019
5 Expires: May 7, 2020
7 Remote Attestation Architecture
8 draft-thaler-rats-architecture-01
10 Abstract
12 In network protocol exchanges, it is often the case that one entity
13 (a relying party) requires evidence about the remote peer (and system
14 components [RFC4949] thereof), in order to assess the trustworthiness
15 of the peer. This document describes an architecture for such remote
16 attestation procedures (RATS), which enable relying parties to decide
17 whether to consider a remote system component trustworthy or not.
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 http://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 May 7, 2020.
36 Copyright Notice
38 Copyright (c) 2019 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
56 3.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 4
57 3.2. Confidential Machine Learning (ML) Model Protection . . . 5
58 3.3. Confidential Data Retrieval . . . . . . . . . . . . . . . 5
59 3.4. Critical Infrastructure Control . . . . . . . . . . . . . 5
60 3.5. Trusted Execution Environment (TEE) Provisioning . . . . 6
61 3.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 6
62 4. Serialization Formats . . . . . . . . . . . . . . . . . . . . 7
63 5. Architectural Models . . . . . . . . . . . . . . . . . . . . 8
64 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 8
65 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 9
66 5.2.1. Variation: Verifying Relying Party . . . . . . . . . 10
67 5.2.2. Variation: Out-of-Band Evidence Conveyance . . . . . 10
68 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 11
69 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 12
70 7. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 12
71 7.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 12
72 7.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 13
73 7.3. Attestation Results . . . . . . . . . . . . . . . . . . . 13
74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
77 11. Informative References . . . . . . . . . . . . . . . . . . . 14
78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
80 1. Introduction
82 In network protocol exchanges, it is often the case that one entity
83 (a relying party) requires evidence about the remote peer (and system
84 components [RFC4949] thereof), in order to assess the trustworthiness
85 of the peer. Remote attestation procedures (RATS) enable relying
86 parties to establish a level of confidence in the trustworthiness of
87 remote system components through the creation of attestation evidence
88 by remote system components and a processing chain towards the
89 relying party. A relying party can then decide whether to consider a
90 remote system component trustworthy or not.
92 To improve the confidence in a system component's trustworthiness, a
93 relying party may require evidence about:
95 - system component identity,
96 - composition of system components, including nested components,
98 - roots of trust,
100 - assertion/claim origination or provenance,
102 - manufacturing origin,
104 - system component integrity,
106 - system component configuration,
108 - operational state and measurements of steps which led to the
109 operational state, or
111 - other factors that could influence trust decisions.
113 This document discusses an architecture for describing solutions for
114 this problem.
116 2. Terminology
118 This document uses the following terms:
120 - Attestation: A process by which one entity (the "Attester")
121 provides evidence about its identity and health to another entity,
122 which then assesses its trustworthiness.
124 - Attestation Result: The evaluation results generated by a
125 Verifier, typically including information about an Attester, where
126 the Verifier vouches for the validity of the results.
128 - Attester: An entity whose attributes must be evaluated in order to
129 determine whether the entity is considered healthy or authorized
130 to access a resource.
132 - Endorsement: A secure statement that some entity (typically a
133 manufacturer) vouches for the integrity of an Attester's signing
134 capability. (Note: in some discussions the entity providing an
135 Endorsement has been called an Asserter, but some believe that
136 term is confusing and the term Endorser would be more correct.
137 For now, this document avoids using a specific term until
138 consensus is reached.)
140 - Evidence: A set of information about an Attester that is to be
141 evaluated by a Verifier.
143 - Relying Party: An entity that depends on the validity of
144 information about another entity, typically for purposes of
145 authorization. Compare /relying party/ in [RFC4949].
147 - Security policy: A set of rules that direct how a system evaluates
148 the validity of information about another entity. For example,
149 the security policy might involve an equality comparison against
150 known-good values (called Reference Integrity Measurements in some
151 contexts), or might involve more complex logic. Compare /security
152 policy/ in [RFC4949].
154 - Verifier: An entity that evaluates the validity of information
155 about an Attester.
157 3. Use Cases
159 This section covers a number of representative use cases for
160 attestation, independent of solution. The purpose is to provide
161 motivation for various aspects of the architecture presented in this
162 draft. Many other use cases exist, and this document does not intend
163 to have a complete list, only to have a set of use cases that
164 collectively cover all the functionality required in the
165 architecture. The use cases are covered prior to discussion of
166 architectural models in Section 5, since each use case might be
167 addressed via different solutions that have different architectural
168 models.
170 Each use case includes a description, and a summary of what an
171 Attester and a Relying Party refer to in the use case. (Since
172 solutions to a use case may greatly vary in architectural model, the
173 role of a Verifier is considered part of a specific solution, not a
174 solution-independent property of a use case, and so is not covered in
175 this section.)
177 3.1. Network Endpoint Assessment
179 Network operators want a trustworthy report of identity and version
180 of information of the hardware and software on the machines attached
181 to their network, for purposes such as inventory, auditing, and/or
182 logging. The network operator may also want a policy by which full
183 access is only granted to devices that meet some definition of
184 health, and so wants to get claims about such information and verify
185 their validity. Attestation is desired to prevent vulnerable or
186 compromised devices from getting access to the network and
187 potentially harming others.
189 Typically, solutions start with some component (called a "Root of
190 Trust") that provides device identity and protected storage for
191 measurements. They then perform a series of measurements, and
192 express this with Evidence as to the hardware and firmware/software
193 that is running.
195 - Attester: A device desiring access to a network
197 - Relying Party: A network infrastructure device such as a router,
198 switch, or access point.
200 3.2. Confidential Machine Learning (ML) Model Protection
202 A device manufacturer wants to protect its intellectual property in
203 terms of the ML model it developed and that runs in the devices that
204 its customers purchased, and it wants to prevent attackers,
205 potentially including the customer themselves, from seeing the
206 details of the model.
208 This typically works by having some protected environment in the
209 device attest to some manufacturer service. If attestation succeeds.
210 then the manufacturer service releases either the model, or a key to
211 decrypt a model the Attester already has in encrypted form, to the
212 requester.
214 - Attester: A device desiring to run an ML model to do inferencing
216 - Relying Party: A server or service holding ML models it desires to
217 protect
219 3.3. Confidential Data Retrieval
221 This is a generalization of the ML model use case above, where the
222 data can be any highly confidential data, such as health data about
223 customers, payroll data about employees, future business plans, etc.
224 Attestation is desired to prevent leaking data to compromised
225 devices.
227 - Attester: An entity desiring to retrieve confidential data
229 - Relying Party: An entity that holds confidential data for
230 retrieval by other entities
232 3.4. Critical Infrastructure Control
234 In this use case, potentially dangerous physical equipment (e.g.,
235 power grid, traffic control, hazardous chemical processing, etc.) is
236 connected to a network. The organization managing such
237 infrastructure needs to ensure that only authorized code and users
238 can control such processes, and they are protected from malware or
239 other adversaries. When a protocol operation can affect some
240 critical system, the device attached to the critical equipment thus
241 wants some assurance that the requester has not been compromised. As
242 such, attestation can be used to only accept commands from requesters
243 that are within policy.
245 - Attester: A device or application wishing to control physical
246 equipment.
248 - Relying Party: A device or application connected to potentially
249 dangerous physical equipment (hazardous chemical processing,
250 traffic control, power grid, etc.
252 3.5. Trusted Execution Environment (TEE) Provisioning
254 A "Trusted Application Manager (TAM)" server is responsible for
255 managing the applications running in the TEE of a client device. To
256 do this, the TAM wants to verify the state of a TEE, or of
257 applications in the TEE, of a client device. The TEE attests to the
258 TAM, which can then decide whether the TEE is already in compliance
259 with the TAM's latest policy, or if the TAM needs to uninstall,
260 update, or install approved applications in the TEE to bring it back
261 into compliance with the TAM's policy.
263 - Attester: A device with a trusted execution environment capable of
264 running trusted applications that can be updated.
266 - Relying Party: A Trusted Application Manager.
268 3.6. Hardware Watchdog
270 One significant problem is malware that holds a device hostage and
271 does not allow it to reboot to prevent updates to be applied. This
272 is a significant problem, because it allows a fleet of devices to be
273 held hostage for ransom.
275 A hardware watchdog can be implemented by forcing a reboot unless
276 attestation to a remote server succeeds within a periodic interval,
277 and having the reboot do remediation by bringing a device into
278 compliance, including installation of patches as needed.
280 - Attester: The device that is desired to keep from being held
281 hostage for a long period of time.
283 - Relying Party: A remote server that will securely grant the
284 Attester permission to continue operating (i.e., not reboot) for a
285 period of time.
287 4. Serialization Formats
289 The following diagram illustrates a relationship to which attestation
290 is desired to be added:
292 +-------------+ +-------------+
293 | |-------------->| |
294 | Attester | Access some | Relying | Evaluate request
295 | | resource | Party | against security policy
296 +-------------+ +-------------+
298 Figure 1: Typical Resource Access
300 In this diagram, the protocol between Attester and a Relying Party
301 can be any new or existing protocol (e.g., HTTP(S), COAP(S), 802.1x,
302 OPC UA, etc.), depending on the use case. Such protocols typically
303 already have mechanisms for passing security information for purposes
304 of authentication and authorization. Common formats include JWTs
305 [RFC7519], CWTs [RFC8392], and X.509 certificates.
307 In many cases, it is desirable to add attestation to existing
308 protocols, enabling a higher level of assurance against malware for
309 example. To enable such integration, it is important that
310 information needed for evaluating the Attester be usable with
311 existing protocols that have constraints around what formats they can
312 transport. For example, OPC UA [OPCUA] (probably the most common
313 protocol in industrial IoT environments) is defined to carry X.509
314 certificates and so security information must be embedded into an
315 X.509 certificate to be passed in the protocol. Thus, attestation-
316 related information could be natively encoded in X.509 certificate
317 extensions, or could be natively encoded in some other format (e.g.,
318 a CWT) which in turn is then encoded in an X.509 certificate
319 extension.
321 Especially for constrained nodes, however, there is a desire to
322 minimize the amount of parsing code needed in a Relying Party, in
323 order to both minimize footprint and to minimize the attack surface
324 area. So while it would be possible to embed a CWT inside a JWT, or
325 a JWT inside an X.509 extension, etc., there is a desire to encode
326 the information natively in the format that is natural for the
327 Relying Party.
329 This motivates having a common "information model" that describes the
330 set of attestation related information in an encoding-agnostic way,
331 and allowing multiple serialization formats (CWT, JWT, X.509, etc.)
332 that encode the same information into the format needed by the
333 Relying Party.
335 5. Architectural Models
337 There are multiple possible models for communication between an
338 Attester, a Verifier, and a Relying Party.
340 5.1. Passport Model
342 In this model, an Attester sends Evidence to a Verifier, which
343 compares the Evidence against its security policy. The Verifier then
344 gives back an Attestation Result. If the Attestation Result was a
345 successful one, the Attester can then present the Attestation Result
346 to a Relying Party, which then compares the Attestation Result
347 against its own security policy.
349 Since the resource access protocol between the Attester and Relying
350 Party includes an Attestation Result, in this model the details of
351 that protocol constrain the serialization format of the Attestation
352 Result. The format of the Evidence on the other hand is only
353 constrained by the Attester-Verifier attestation protocol.
355 +-------------+
356 | | Compare Evidence
357 | Verifier | against security policy
358 | |
359 +-------------+
360 ^ |
361 Evidence| |Attestation
362 | | Result
363 | v
364 +-------------+ +-------------+
365 | |-------------->| | Compare Attestation
366 | Attester | Attestation | Relying | Result against
367 | | Result | Party | security policy
368 +-------------+ +-------------+
370 Figure 2: Passport Model
372 The passport model is so named because it resembles the process
373 typically used for passports and drivers licenses, where a person
374 applies and gets a passport or license that is issued by a government
375 and shows information such as the person's name and birthdate. The
376 passport or license can then be supplied to other entities to gain
377 entrance to an airport boarding area, or age-restricted section of a
378 bar, where the passport or license is considered sufficient because
379 it vouches for that piece of information and is issued by a trusted
380 authority. Thus, in this analogy, the passport issuing agency is a
381 Verifier, the passport is an Attestation Result, and the airport
382 security is a Relying Party.
384 5.2. Background-Check Model
386 In this model, an Attester sends Evidence to a Relying Party, which
387 simply passes it on to a Verifier. The Verifier then compares the
388 Evidence against its security policy, and returns an Attestation
389 Result to the Relying Party. The Relying Party then compares the
390 Attestation Result against its own security policy.
392 The resource access protocol between the Attester and Relying Party
393 includes Evidence rather than an Attestation Result, but that
394 Evidence is not processed by the Relying Party. Since the Evidence
395 is merely forwarded on to a trusted Verifier, any serialization
396 format can be used for Evidence because the Relying Party does not
397 need a parser for it. The only requirement is that the Evidence can
398 be _encapsulated in_ the format required by the resource access
399 protocol between the Attester and Relying Party.
401 However, like in the Passport model, an Attestation Result is still
402 consumed by the Relying Party and so the serialization format of the
403 Attestation Result is still important. If the Relying Party is a
404 constrained node whose purpose is to serve a given type resource
405 using a standard resource access protocol, it already needs the
406 parser(s) required by that existing protocol. Hence, the ability to
407 let the Relying Party obtain an Attestation Result in the same
408 serialization format allows minimizing the code footprint and attack
409 surface area of the Relying Party, especially if the Relying Party is
410 a constrained node.
412 +-------------+
413 | | Compare Evidence
414 | Verifier | against security policy
415 | |
416 +-------------+
417 ^ |
418 Evidence| |Attestation
419 | | Result
420 | v
421 +-------------+ +-------------+
422 | |-------------->| | Compare Attestation
423 | Attester | Evidence | Relying | Result against
424 | | | Party | security policy
425 +-------------+ +-------------+
427 Figure 3: Background-Check Model
429 The background-check model is so named because it resembles the
430 process typically used for job and loan applications, where a person
431 fills out an application to get a job or a loan from a company, and
432 the company then does a background check with some other agency that
433 checks credit history, arrest records, etc. and gives back a report
434 on the application that is then used to help determine whether to
435 actually offer the job or loan. Thus, in this analogy, a person
436 asking for a loan is an Attester, the bank is the Relying Party, and
437 a credit report agency is a Verifier.
439 5.2.1. Variation: Verifying Relying Party
441 One variation of the background-check model is a "Verifying Relying
442 party", where the Relying Party and the Verifier on the same machine,
443 and so there is no need for a protocol between the two.
445 5.2.2. Variation: Out-of-Band Evidence Conveyance
447 Another variation of the background-check model is shown in Figure 4,
448 where the Verifier is still chosen by (and trusted by) the Relying
449 Party, but the Evidence must be passed out-of-band. For example, in
450 step 1, the Attester communicates with the Relying Party, which
451 refers the matter to a Verifier chosen by the Relying Party in step
452 2. Evidence is then passed to that Verifier in step 3, e.g., either
453 by the Relying Party providing the Attester with information about
454 the Verifier to send Evidence to, or by the Verifier querying the
455 Attester directly, although the latter has the problem that it only
456 works if devices allow unsolicited inbound queries, which may be a
457 security problem in some contexts.
459 +-------------+
460 | | Compare Evidence
461 +----->| Verifier | against security policy
462 | | |
463 Evidence| +-------------+
464 | ^ |
465 | | |Attestation
466 |3 2| | Result
467 | | v
468 +-------------+ | +-------------+
469 | |--------+ | | Compare Attestation
470 | Attester |-------------->| Relying | Result against
471 | | 1 | Party | security policy
472 +-------------+ +-------------+
474 Figure 4: Out-of-Band Evidence Conveyance
476 5.3. Combinations
478 The choice of model is generally up to the Relying Party, and the
479 same device may need to attest to different relying parties for
480 different use cases (e.g., a network infrastructure device to gain
481 access to the network, and then a server holding confidential data to
482 get access to that data). As such, both models may simultaneously be
483 in use by the same device.
485 Figure 5 shows an example of a combination where Relying Party 1 uses
486 the passport model, whereas Relying Party 2 uses an extension of the
487 background-check model. Specifically, in addition to the basic
488 functionality shown in Figure 3, Relying Party 2 actually provides
489 the Attestation Result back to the Attester, allowing the Attester to
490 use it with other Relying Parties. This is the model that the
491 Trusted Application Manager plans to support in the TEEP architecture
492 [I-D.ietf-teep-architecture].
494 +-------------+
495 | | Compare Evidence
496 | Verifier | against security policy
497 | |
498 +-------------+
499 ^ |
500 Evidence| |Attestation
501 | | Result
502 | v
503 +-------------+
504 | | Compare
505 | Relying | Attestation Result
506 | Party 2 | against security policy
507 +-------------+
508 ^ |
509 Evidence| |Attestation
510 | | Result
511 | v
512 +-------------+ +-------------+
513 | |-------------->| | Compare Attestation
514 | Attester | Attestation | Relying | Result against
515 | | Result | Party 1 | security policy
516 +-------------+ +-------------+
518 Figure 5: Example Combination
520 6. Trust Model
522 The scope of this document is scenarios for which a Relying Party
523 trusts a Verifier that can evaluate the trustworthiness of
524 information about an Attester. Such trust might come by the Relying
525 Party trusting the Verifier (or its public key) directly, or might
526 come by trusting an entity (e.g., a Certificate Authority) that the
527 Verifier has a certificate that chains up to. The Relying Party
528 might implicitly trust a Verifier (such as in the Verifying Relying
529 Party combination). Or, for a stronger level of security, the
530 Relying Party might require that the Verifier itself provide
531 information about itself that the Relying Party can use to evaluate
532 the health of the Verifier before accepting its Attestation Results.
534 In solutions following the background-check model, the Attester is
535 assumed to trust the Verifier (again, whether directly or indirectly
536 via a Certificate Authority that it trusts), since the Attester
537 relies on an Attestation Result it obtains from the Verifier, in
538 order to access resources.
540 The Verifier trusts (or more specifically, the Verifier's security
541 policy is written in a way that configures the Verifier to trust) a
542 manufacturer, or the manufacturer's hardware, so as to be able to
543 evaluate the health of that manufacturer's devices. In solutions
544 with weaker security, a Verifier might be configured to implicitly
545 trust firmware or even software (e.g., a hypervisor). That is, it
546 might evaluate the health of an application component, or operating
547 system component or service, under the assumption that information
548 provided about it by the lower-layer hypervisor or firmware is true.
549 A stronger level of security comes when information can be vouched
550 for by hardware or by ROM code, especially if such hardware is
551 physically resistant to hardware tampering. The component that is
552 implicitly trusted is often referred to as a Root of Trust.
554 7. Conceptual Messages
556 7.1. Evidence
558 Today, Evidence tends to be highly device-specific, since the
559 information in the evidence often includes vendor-specific
560 information that is necessary to fully describe the manufacturer and
561 model of the device including its security properties, the health of
562 the device, and the level of confidence in the correctness of the
563 information. Evidence is typically signed by the device (whether by
564 hardware, firmware, or software on the device), and evaluating it in
565 isolation would require security policy to be based on device-
566 specific details (e.g., a device public key).
568 7.2. Endorsements
570 An Endorsement is a secure statement that some entity (typically a
571 manufacturer) vouches for the integrity of the device's signing
572 capability. For example, if the signing capability is in hardware,
573 then an Endorsement might be a manufacturer certificate that signs a
574 public key whose corresponding private key is only known inside the
575 device's hardware. Thus, when Evidence and such an Endorsement are
576 used together, evaluating them can be done against security policy
577 that may not be specific to the device instance, but merely specific
578 to the manufacturer providing the Endorsement. For example, a
579 security policy might simply check that devices from a given
580 manufacturer have information matching a set of known-good reference
581 values, or a security policy might have a set of more complex logic
582 on how to evaluate the validity of information.
584 However, while a security policy that treats all devices from a given
585 manufacturer the same may be appropriate for some use cases, it would
586 be inappropriate to use such a security policy as the sole means of
587 authorization for use cases that wish to constrain _which_ compliant
588 devices are considered authorized for some purpose. For example, an
589 enterprise using attestation for Network Endpoint Assessment may not
590 wish to let every healthy laptop from the same manufacturer onto the
591 network, but instead only want to let devices that it legally owns
592 onto the network. Thus, an Endorsement may be helpful information in
593 authenticating information about a device, but is not necessarily
594 sufficient to authorize access to resources which may need device-
595 specific information such as a public key for the device or component
596 or user on the device.
598 7.3. Attestation Results
600 Attestation Results may indicate compliance or non-compliance with a
601 Verifier's security policy. A result that indicates non-compliance
602 can be used by an Attester (in the passport model) or a Relying Party
603 (in the background-check model) to indicate that the Attester should
604 not be treated as authorized and may be in need of remediation. In
605 some cases, it may even indicate that the Evidence itself cannot be
606 authenticated as being correct.
608 An Attestation Result that indicates compliance can be used by a
609 Relying Party to make authorization decisions based on the Relying
610 Party's security policy. The simplest such policy might be to simply
611 authorize any party supplying a compliant Attestation Result signed
612 by a trusted Verifier. A more complex policy might also entail
613 comparing information provided in the result against known-good
614 reference values, or applying more complex logic using such
615 information.
617 Thus, Attestation Results often need to include detailed information
618 about the Attester, for use by Relying Parties, much like physical
619 passports and drivers licenses include personal information such as
620 name and date of birth. Unlike Evidence, which is often very device-
621 and vendor-specific, Attestation Results can be vendor-neutral if the
622 Verifier has a way to generate vendor-agnostic information based on
623 evaluating vendor-specific information in Evidence. This allows a
624 Relying Party's security policy to be simpler, potentially based on
625 standard ways of expressing the information, while still allowing
626 interoperability with heterogeneous devices.
628 Finally, whereas Evidence is signed by the device (or indirectly by a
629 manufacturer, if Endorsements are used), Attestation Results are
630 signed by a Verifier, allowing a Relying Party to only need a trust
631 relationship with one entity, rather than a larger set of entities,
632 for purposes of its security policy.
634 8. Security Considerations
636 To evaluate the security provided by a particular security policy, it
637 is important to understand the strength of the Root of Trust, e.g.,
638 whether it is mutable software, or firmware that is read-only after
639 boot, or immutable hardware/ROM.
641 It is also important that the security policy was itself obtained
642 securely. As such, if security policy in a Relying Party or Verifier
643 can be configured via a network protocol, the ability to attest to
644 the health of the client providing the security policy needs to be
645 considered.
647 9. IANA Considerations
649 This document does not require any actions by IANA.
651 10. Acknowledgements
653 Some content in this document came from drafts by Michael Richardson,
654 Henk Birkholz, and Ned Smith, and from the IETF RATS Working Group
655 Charter.
657 11. Informative References
659 [I-D.ietf-teep-architecture]
660 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.
661 Liu, "Trusted Execution Environment Provisioning (TEEP)
662 Architecture", draft-ietf-teep-architecture-03 (work in
663 progress), July 2019.
665 [OPCUA] OPC Foundation, "OPC Unified Architecture Specification,
666 Part 2: Security Model, Release 1.03", Global
667 Platform GPD_SPE_009, November 2015,
668 .
671 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
672 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
673 .
675 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
676 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
677 .
679 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
680 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
681 May 2018, .
683 Author's Address
685 Dave Thaler
686 Microsoft
688 EMail: dthaler@microsoft.com