idnits 2.17.1 draft-birkholz-rats-architecture-02.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2019) is 1681 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-richardson-rats-usecases-04 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 H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track M. Wiseman 5 Expires: March 15, 2020 GE Global Research 6 H. Tschofenig 7 ARM Ltd. 8 N. Smith 9 Intel 10 September 12, 2019 12 Remote Attestation Procedures Architecture 13 draft-birkholz-rats-architecture-02 15 Abstract 17 The Remote ATtestation procedureS (RATS) architecture facilitates 18 interoperability of attestation mechanisms by defining a set of 19 participant roles and interactions that reveal information about the 20 trustworthiness attributes of an attester's computing environment. 21 By making trustworthiness attributes explicit, they can be evaluated 22 dynamically and within an operational context where risk mitigation 23 depends on having a more complete understanding of the possible 24 vulnerabilities germane to the attester's environment. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 15, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. RATS in a Nutshell . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 64 3. Conceptual Overview . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Computing Environments . . . . . . . . . . . . . . . . . 5 66 3.2. Trustworthiness . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. RATS Workflow . . . . . . . . . . . . . . . . . . . . . . 6 68 3.4. Interoperability between RATS . . . . . . . . . . . . . . 7 69 4. RATS Architecture . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. Attestation Principles . . . . . . . . . . . . . . . . . 8 72 4.3. RATS Roles and Messages . . . . . . . . . . . . . . . . . 8 73 4.3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.3.2. Role Messages . . . . . . . . . . . . . . . . . . . . 10 75 4.4. RATS Principals . . . . . . . . . . . . . . . . . . . . . 11 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 6.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The long-standing Internet Threat Model [RFC3552] focuses on threats 85 to the communication channel, as pioneered by Dolev and Yao 86 [DOLEV-YAO] in 1983. However, threats to the endpoint [RFC5209] and 87 system components [RFC4949] of transited communication gear (i.e. 88 hosts) are increasingly relevant for assessing the trustworthiness 89 properties of a communication channel. Beyond the collection and 90 conveyance of security posture [RFC5209] about an endpoint (host), 91 remote attestation provides believable trustworthiness claims 92 ("Evidence") about an endpoint (host). In general, this document 93 provides normative guidance how to use, create or adopt network 94 protocols that facilitate RATS. 96 1.1. RATS in a Nutshell 98 The RATS architecture provides a basis to assess the trustworthiness 99 of endpoints by other parties: 101 o In remote attestation workflows, trustworthiness Claims are 102 accompanied by a proof of veracity. Typically, this proof is a 103 cryptographic expression such as a digital signature or message 104 digest. Trustworthiness Claims with proof is what makes 105 attestation Evidence believable. 107 o A corresponding attestation provisioning workflow uses 108 trustworthiness Claims to convey believable Endorsements and 109 Known-Good-Values used by a Verifier to appraise Evidence. 111 In the RATS architecture, specific content items are identified (and 112 described in more detail below): 114 o Evidence is provable Claims about a specific Computing Environment 115 made by an Attester. 117 o Known-Good-Values are reference Claims used to appraise Evidence. 119 o Endorsements are reference Claims about the environment protecting 120 the Attesters capabilities to create believable Evidence (e.g. the 121 type of protection for an attestation key). It answers the 122 question "why Evidence is believable". 124 o Attestation Results are the output from the appraisal of Evidence, 125 Known-Good-Values and Endorsements. 127 Attestation Results are the output of RATS. Assessment of 128 Attestation Results can be multi-faceted, but is out-of-scope for the 129 RATS architecture. If appropriate Endorsements about the Attester 130 are available, Known-Good-Values about the Attester are available, 131 and if the Attester is capable of creating believable Evidence - then 132 the Verifier is able to create Attestation Results that enable 133 Relying Parties to establish a level of confidence in the 134 trustworthiness of the Attester. 136 2. Terminology 138 Conveyance: a mechanism for transferring RATS Evidence, 139 Endorsements, Known-Good-Values or Attestation Results. 141 Entity: a user, organization, device or computing environment. 143 Principal: an Entity that implements RATS Roles and creates provable 144 Claims or Attestation Results (see [ABLP] and [Lampson2007]). 146 Trustworthiness: an expectation about a computing environment that 147 it will behave in a way that is intended and nothing more. 149 Computing Environment: a computing context consisting of system 150 components. 152 Attesting Computing Environment: a Computing Environment capabile of 153 monitoring and attesting a target Computing Environment. 155 Attested Computing Environment: a target Computing Environment that 156 is monitored and attested by an Attesting Computing Environment. 158 2.1. Requirements Notation 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 163 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 3. Conceptual Overview 168 In network protocol exchanges, it is often the case that one entity 169 (a Relying Party) requires an assessment of the trustworthiness of a 170 remote entity (an Attester or specifc system components [RFC4949] 171 thereof). Remote ATtestation procedureS (RATS) enable Relying 172 Parties to establish a level of confidence in the trustworthiness of 173 remote system components through the creation of attestation evidence 174 by remote system components and a processing chain of architectural 175 constituents towards the relying party. 177 The corresponding trustworthiness attributes processed may not be 178 just a finite set of values. Additionally, the system 179 characteristics of remote components themselves have an impact on the 180 veracity of trustworthiness attributes included in Evidence. 181 Attester environments can vary widely ranging from those highly 182 resistant to attacks to those having little or no resistance to 183 attacks. Configuration options, if set poorly, can result in a 184 highly resistant environment being operationally less resistant. 185 Computing Environments are often malleable being constructed from re- 186 programmable hardware, firmware, software and updatable memory. When 187 a trustworthy environment changes, the question has to be asked 188 whether the change transitioned the environment from a trustworthy 189 state to an untrustworthy state. The RATS architecture provides a 190 framework for anticipating when a relevant change with respect to a 191 trustworthiness attribute occurs, what changed and how relevant it 192 is. A remote attestation framework also creates a context for 193 enabling an appropriate response by applications, system software and 194 protocol endpoints when changes to trustworthiness attributes do 195 occur. 197 3.1. Computing Environments 199 In the RATS context, a Claim is a specific trustworthiness attribute 200 that pertains to a particular Computing Environment of an Attester. 201 The set of possible Claims is expected to follow the possible 202 computing environments that support attestation. In other words, 203 identical (i.e. same type, model, versions, components and 204 composition) Attesting Computing Environments can create different 205 Claim values that still compose valid Evidence due to different 206 computing contexts. Exemplary Claims include flight vectors or 207 learned configuration. 209 Likely, there are a set of Claims that is widely applicable across 210 most, if not all environments. Conversely, there are Claims that are 211 unique to specific environments. Consequently, the RATS architecture 212 incorporates extensible mechanisms for representing Claims. 214 Computing Environments can be complex structurally. In general, 215 every Attester consists of multiple components (e.g. memory, CPU, 216 storage, networking, firmware, software). Components are 217 computational elements that can be linked and composed to form 218 computational pipelines, arrays and networks (e.g. a BIOS, a 219 bootloader, or a trusted execution environment). 221 An Attester includes at least one Computing Environment that is able 222 to create attestation Evidence (the Attesting Computing Environment) 223 about other Computing Environments (the Attested Computing 224 Environments). Not every computational element of an Attester is 225 expected to be a Computing Environment capable of remote attestation. 226 Analogously, remote attestation capable Computing Environments may 227 not be capable of attesting to (creating evidence about) every 228 computational element that interacts with the Computing Environment. 229 A Computing Environment with an attestation capability can only be 230 endorsed by an external entity and cannot create believable evidence 231 about itself by its own. 233 A Computing Environment with the capability of remote attestation: 235 o is separate from other Attested Computing Environments (about 236 which attestation evidence is created), and 238 o is enabling the role of an Attester in the RATS architecture. 240 A Computing Environment with the capability of remote attestation and 241 taking on the role of an Attester has the following duties in order 242 to create Evidence: 244 o monitoring trustworthiness attributes of other Computing 245 Environments, 247 o collecting trustworthiness attributes and create Claims about 248 them, 250 o serialize Claims using interoperable representations, 252 o provide integrity protection for the sets of Claims, and 254 o add appropriate attestation provenance attributes about the sets 255 of Claims. 257 3.2. Trustworthiness 259 The trustworthiness of remote attestation capabilities is also a 260 consideration for the RATS architecture. It should be possible to 261 understand the trustworthiness properties of the remote attestation 262 capability for any set of claims of a remote attestation flow via 263 verification operations. The RATS architecture anticipates recursive 264 trustworthiness properties and the need for termination. Ultimately, 265 a portion of a computing environment's trustworthiness is established 266 via non-automated means. For example, design reviews, manufacturing 267 process audits and physical security. For this reason, trustworthy 268 RATS depend on trustworthy manufacturing and supply chain practices. 270 3.3. RATS Workflow 272 The basic function of RATS is creation, conveyance and appraisal of 273 attestation Evidence. An Attester creates attestation Evidence that 274 are conveyed to a Verifier for appraisal. The appraisals compare 275 Evidence with expected Known-Good-Values called obtained from 276 Asserters (e.g. Prinicipals that are Supply Chain Entities). There 277 can be multiple forms of appraisal (e.g., software integrity 278 verification, device composition and configuration verification, 279 device identity and provenance verification). Attestation Results 280 are the output of appraisals. Attestation Results are signed and 281 conveyed to Relying Parties. Attestation Results provide the basis 282 by which the Relying Party may determine a level of confidence to 283 place in the application data or operations that follow. 285 RATS architecture defines attestation Roles (i.e., Attester, 286 Verifier, Asserter and Relying Party), the messages they exchange, 287 their structure and the various legal ways in which Roles may be 288 hosted, combined and divided (see Principals below). RATS messages 289 are defined by an information model that defines Claims, environment 290 and protocol semantics. Information Model representations are 291 realized as data structure and conveyance protocol binding 292 specifications. 294 3.4. Interoperability between RATS 296 The RATS architecture anticipates use of information modeling 297 techniques that describe computing environment structures - their 298 components/computational elements and corresponding capabilities - so 299 that verification operations may rely on the information model as an 300 interoperable way to navigate the structural complexity. 302 4. RATS Architecture 304 4.1. Goals 306 RATS architecture has the following goals: 308 o Enable semantic interoperability of attestation semantics through 309 information models about computing environments and 310 trustworthiness. 312 o Enable data structure interoperability related to claims, endpoint 313 composition / structure, and end-to-end integrity and 314 confidentiality protection mechanisms. 316 o Enable programmatic assessment of trustworthiness. (Note: 317 Mechanisms that manage risk, justify a level of confidence, or 318 determine a consequence of an attestation result are out of 319 scope). 321 o Provide the building blocks, including Roles and Principals that 322 enable the composition of service-chains/hierarchies and workflows 323 that can create and appraise evidence about the trustworthiness of 324 devices and services. 326 o Use-case driven architecture and design (RATS use cases are 327 summarized in [I-D.richardson-rats-usecases]). 329 o Terminology conventions that are consistently applied across RATS 330 specifications. 332 o Reinforce trusted computing principles that include attestation. 334 4.2. Attestation Principles 336 Specifications developed by the RATS working group apply the 337 following principles: 339 o Freshness - replay of previously asserted Claims about an Attested 340 Computing Environment can be detected. 342 o Identity - the Attesting Computing Environment is identifiable 343 (non-anonymous). 345 o Context - the Attested Computing Environment is well-defined 346 (unambiguous). 348 o Provenance - the origin of Claims with respect to the Attested and 349 Attesting Computing Environments are known. 351 o Validity - the expected lifetime of Claims about an Attested 352 Computing Environment is known. 354 o Relevance - the Claims associated with the Attested Computing 355 Environment pertain to trustworthiness metrics. 357 o Veracity - the believability (level of confidence) of Claims is 358 based on verifiable proofs. 360 4.3. RATS Roles and Messages 362 The RATS Roles (roles) are performed by RATS Principals. 364 The RATS Architecture provides the building blocks to compose various 365 RATS roles by leveraging existing and new protocols. It defines 366 architecture for composing RATS roles with principals and models 367 their interactions. 369 Figure Figure 1 provides an overview of the relationships between 370 RATS Roles and the messages they exchange. 372 +----------------+ +-----------------+ 373 | | Known-Good-Values | | 374 | Asserter(s) |-------------------->| Verifier | 375 | | Endorsements /-->| | 376 +----------------+ | +-----------------+ 377 | | 378 | | 379 | | 380 | |Attestation 381 | |Results 382 | | 383 | | 384 | v 385 +----------------+ | +-----------------+ 386 | | Evidence | | | 387 | Attester |-----------------/ | Relying Party | 388 | | | | 389 +----------------+ +-----------------+ 391 Figure 1: RATS Roles 393 4.3.1. Roles 395 RATS roles are implemented by principals that possess cryptographic 396 keys used to protect and authenticate Claims or Results. 398 Attester: An Attestation Function that creates Evidence by 399 collecting, formatting and protecting (e.g., signing) Claims. It 400 presents Evidence to a Verifier using a conveyance mechanism or 401 protocol. 403 Verifier: An Attestation Function that accepts Evidence from an 404 Attester using a conveyance mechanism or protocol. It also 405 accepts Known-Good-Values and Endorsments from an Asserter using a 406 conveyance mechanism or protocol. It verifies the protection 407 mechanisms, parses and appraises Evidence according to good-known 408 valid (or known-invalid) Claims and Endorsments. It produces 409 Attestation Results that are formatted and protected (e.g., 410 signed). It presents Attestation Results to a Relying Party using 411 a conveyance mechanism or protocol. 413 Asserter: An Attestation Function that generates reference Claims 414 about both the Attesting Computing Environment and the Attested 415 Computing Environment. The manufacturing and development 416 processes are presumed to be trustworthy processes. In other 417 words the Asserter is presumed, by a Verifier, to produce valid 418 Claims. The function collects, formats and protects (e.g. signs) 419 valid Claims known as Endorsements and Known-Good-Values. It 420 presents provable Claims to a Verifier using a conveyance 421 mechanism or protocol. 423 Relying Party: An Attestation Function that accepts Attestation 424 Results from a Verifier using a conveyance mechanism or protocol. 425 It assesses Attestation Results protections, parses and assesses 426 Attestation Results according to an assessent context (Note: 427 definition of the assessment context is out-of-scope). 429 4.3.2. Role Messages 431 Claims: Statements about trustworthiness characteristics of an 432 Attested Computing Environment. 434 The veracity of a Claim is determined by the reputation of the 435 entity making the Claim. (Note: Reputation may involve 436 identifying, authenticating and tracking transactions associated 437 with an entity. RATS may be used to establish entity reputation, 438 but not exclusively. Other reputation mechanisms are out-of- 439 scope). 441 Evidence: Claims that are formatted and protected by an Attester. 443 Evidence SHOULD satisfy Verifier expectations for freshness, 444 identity, context, provenance, validity, relevance and veracity. 446 Known-Good-Values: Claims about the Attested Computing Environment. 447 Typically, KGV Claims are message digests of firmware, software or 448 configuration data supplied by various vendors. If an Attesting 449 Computing Environment implements cryptography, they include Claims 450 about key material. 452 Like Claims, Known-Good-Values SHOULD satisfy a Verifier's 453 expectations for freshness, identity, context, provenance, 454 validity, relevance and veracity. Known-Good-Values are reference 455 Claims that are - like Evidence - well formatted and protected 456 (e.g. signed). 458 Endorsements: Claims about immutable and implicit characteristics of 459 the Attesting Computing Environment. Typically, endorsement 460 Claims are created by manufacturing or supply chain entities. 462 Endorsements are intended to increase the level of confidence with 463 respect to Evidence created by an Attester. 465 Attestation Results: Statements about the output of an appraisal of 466 Evidence that are created, formatted and protected by a Verifier. 468 Attestation Results provide the basis for a Relying Party to 469 establsh a level of confidence in the trustworthiness of an 470 Attester. Attestation Results SHOULD satisfy Relying Party 471 expectations for freshness, identity, context, provenance, 472 validity, relevance and veracity. 474 4.4. RATS Principals 476 RATS Principals are entities, users, organizations, devices and 477 computing environments (e.g., devices, platforms, services, 478 peripherals). 480 RATS Principals may implement one or more RATS Roles. Role 481 interactions occurring within the same RATS Principal are out-of- 482 scope. 484 The methods whereby RATS Principals may be identified, discovered, 485 authenticated, connected and trusted, though important, are out-of- 486 scope. 488 Principal operations that apply resiliency, scaling, load balancing 489 or replication are generally believed to be out-of-scope. 491 +------------------+ +------------------+ 492 | Principal 1 | | Principal 2 | 493 | +------------+ | | +------------+ | 494 | | | | | | | | 495 | | Role 1 |<-|---|->| Role 2 | | 496 | | | | | | | | 497 | +------------+ | | +------------+ | 498 | | | | 499 | +-----+------+ | | +-----+------+ | 500 | | | | | | | | 501 | | Role 2 |<-|---|->| Role 3 | | 502 | | | | | | | | 503 | +------------+ | | +------------+ | 504 | | | | 505 +------------------+ +------------------+ 507 Figure 2: RATS Principals-Role Composition 509 RATS Principals have the following properties: 511 o Multiplicity - Multiple instances of RATS Principals that possess 512 the same RATS Roles can exist. 514 o Composition - RATS Principals possessing different RATS Roles can 515 be combined into a singleton RATS Principal possessing the union 516 of RATS Roles. RATS Interactions between combined RATS Principals 517 is uninteresting. 519 o Decomposition - A singleton RATS Principal possessing multiple 520 RATS Roles can be divided into multiple RATS Principals. 522 RATS Interactions may occur between them. 524 5. Security Considerations 526 RATS Evidence, Verifiable Assertions and Results SHOULD use formats 527 that support end-to-end integrity protection and MAY support end-to- 528 end confidentiality protection. Replay attack prevention MAY be 529 supported if a Nonce Claim is included. Nonce Claims often piggy- 530 back other information and can convey attestation semantics that are 531 of essence to RATS, e.g. the last four bytes of a challenge nonce 532 could be replaced by the IPv4 address-value of the Attester in its 533 response. 535 All other attacks involving RATS structures are not explicitly 536 addressed by RATS architecture. Additional security protections MAY 537 be required of conveyance mechanisms. For example, additional means 538 of authentication, confidentiality, integrity, replay, denial of 539 service and privacy protection of RATS payloads and Principals may be 540 needed. 542 6. References 544 6.1. Normative References 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 552 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 553 May 2017, . 555 6.2. Informative References 557 [ABLP] Abadi, M., Burrows, M., Lampson, B., and G. Plotkin, "A 558 Calculus for Access Control in Distributed Systems", 559 Springer Annual International Cryptology Conference, 560 page 1-23, DOI 10.1.1.36.691, 1991. 562 [DOLEV-YAO] 563 Dolev, D. and A. Yao, "On the security of public key 564 protocols", IEEE Transactions on Information Theory Vol. 565 29, pp. 198-208, DOI 10.1109/tit.1983.1056650, March 1983. 567 [I-D.richardson-rats-usecases] 568 Richardson, M., Wallace, C., and W. Pan, "Use cases for 569 Remote Attestation common encodings", draft-richardson- 570 rats-usecases-04 (work in progress), July 2019. 572 [Lampson2007] 573 Lampson, B., "Practical Principles for Computer Security", 574 IOSPress Proceedings of Software System Reliability and 575 Security, page 151-195, DOI 10.1.1.63.5360, 2007. 577 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 578 Text on Security Considerations", BCP 72, RFC 3552, 579 DOI 10.17487/RFC3552, July 2003, 580 . 582 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 583 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 584 . 586 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 587 Tardo, "Network Endpoint Assessment (NEA): Overview and 588 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 589 . 591 Authors' Addresses 593 Henk Birkholz 594 Fraunhofer SIT 595 Rheinstrasse 75 596 Darmstadt 64295 597 Germany 599 Email: henk.birkholz@sit.fraunhofer.de 601 Monty Wiseman 602 GE Global Research 603 USA 605 Email: monty.wiseman@ge.com 606 Hannes Tschofenig 607 ARM Ltd. 608 110 Fulbourn Rd 609 Cambridge CB1 9NJ 610 UK 612 Email: hannes.tschofenig@gmx.net 614 Ned Smith 615 Intel Corporation 616 USA 618 Email: ned.smith@intel.com