--- 1/draft-ietf-rats-reference-interaction-models-00.txt 2020-10-23 07:14:15.196066163 -0700 +++ 2/draft-ietf-rats-reference-interaction-models-01.txt 2020-10-23 07:14:15.416071758 -0700 @@ -1,49 +1,49 @@ RATS Working Group H. Birkholz Internet-Draft M. Eckel Intended status: Informational Fraunhofer SIT -Expires: March 13, 2021 C. Newton +Expires: April 26, 2021 C. Newton L. Chen University of Surrey - September 09, 2020 + October 23, 2020 Reference Interaction Models for Remote Attestation Procedures - draft-ietf-rats-reference-interaction-models-00 + draft-ietf-rats-reference-interaction-models-01 Abstract This document describes interaction models for remote attestation procedures (RATS). Three conveying mechanisms - Challenge/Response, Uni-Directional, and Streaming Remote Attestation - are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. Privacy preserving conveyance of Evidence via Direct - Anonymous Attestation is elaborated on for each interaction model, - individually. + Anonymous Attestation is elaborated on in the context of the + Attester, Endorser, and Verifier role. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 13, 2021. + This Internet-Draft will expire on April 26, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,21 +59,21 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 4 4. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4 5. Direct Anonymous Attestation . . . . . . . . . . . . . . . . 5 5.1. Endorsers . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Endorsers for Direct Anonymous Attestation . . . . . . . 6 6. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6 7. Generic Information Elements . . . . . . . . . . . . . . . . 7 8. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9 8.1. Challenge/Response Remote Attestation . . . . . . . . . . 10 - 8.2. Uni-Directional Remote Attestation . . . . . . . . . . . 11 + 8.2. Uni-Directional Remote Attestation . . . . . . . . . . . 12 8.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13 9. Additional Application-Specific Requirements . . . . . . . . 15 9.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15 9.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15 9.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 10.1. Implementer . . . . . . . . . . . . . . . . . . . . . . 16 10.2. Implementation Name . . . . . . . . . . . . . . . . . . 16 10.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16 10.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16 @@ -81,62 +81,63 @@ 10.6. License . . . . . . . . . . . . . . . . . . . . . . . . 16 10.7. Implementation Dependencies . . . . . . . . . . . . . . 16 10.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Security and Privacy Considerations . . . . . . . . . . . . . 17 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. CDDL Specification for a simple CoAP - Challenge/Response Interaction . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + Challenge/Response Interaction . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture]) are workflows composed of roles and interactions, in which Verifiers create Attestation Results about the trustworthiness of an Attester's system component characteristics. The Verifier's assessment in the form of Attestation Results is created based on Attestation Policies and Evidence - trustable and tamper-evident Claims Sets about an - Attester's system component characteristics - created by an Attester. - The roles _Attester_ and _Verifier_, as well as the Conceptual - Messages _Evidence_ and _Attestation Results_ are terms defined by - the RATS Architecture [I-D.ietf-rats-architecture]. This documents - captures interaction models that can be used in specific RATS-related - solution documents. The primary focus of this document is the - conveyance of attestation Evidence. Specific goals of this document - are to: + Attester's system component characteristics - generated by an + Attester. The roles _Attester_ and _Verifier_, as well as the + Conceptual Messages _Evidence_ and _Attestation Results_ are concepts + defined by the RATS Architecture [I-D.ietf-rats-architecture]. This + document defines interaction models that can be used in specific + RATS-related solution documents. The primary focus of this document + is the conveyance of attestation Evidence. The reference models + defined can also be applied to the conveyance of other Conceptual + Messages in RATS. Specific goals of this document are to: - o prevent inconsistencies in descriptions of these interaction - models in other documents (due to text cloning over time), + o prevent inconsistencies in descriptions of interaction models in + other documents (due to text cloning and evolution over time), o enable to highlight an exact delta/divergence between the core set of characteristics captured here in this document and variants of these interaction models used in other specifications or solutions, and to o illustrate the application of Direct Anonymous Attestation (DAA) - for each of the interaction models described. + for the defined set of reference models. In summary, this document enables the specification and design of trustworthy and privacy preserving conveyance methods for attestation Evidence from an Attester to a Verifier. While the conveyance of other Conceptual Messages is out-of-scope the methods described can - also be applied to the conveyance of Endorsements or Attestation - Results. + also be applied to the conveyance of, for example, Endorsements or + Attestation Results. 2. Terminology - This document uses the terms, roles, and concepts defined in - [I-D.ietf-rats-architecture]: + This document uses the following set of terms, roles, and concepts as + defined in [I-D.ietf-rats-architecture]: Attester, Verifier, Relying Party, Conceptual Message, Evidence, Endorsement, Attestation Result, Appraisal Policy, Attesting Environment, Target Environment A PKIX Certificate is an X.509v3 format certificate as specified by [RFC5280]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and @@ -145,28 +146,32 @@ capitals, as shown here. 3. Disambiguation The term "Remote Attestation" is a common expression and often associated or connoted with certain properties. The term "Remote" in this context does not necessarily refer to a remote entity in the scope of network topologies or the Internet. It rather refers to a decoupled system or entities that exchange the payload of the Conceptual Message type called Evidence [I-D.ietf-rats-architecture]. - This conveyance can also be "local", if the Verifier is part of the - same entity as the Attester, e.g., separate system components of a - Composite Device (a single RATS Entity). Examples of these types of - co-located environments include: a Trusted Execution Environment - (TEE), Baseboard Management Controllers (BMCs), as well as other - physical or logical protected/isolated/shielded Computing - Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform - Modules (TPM)). + This conveyance can also be "Local", if the Verifier role is part of + the same entity as the Attester role, e.g., separate system + components of the same Composite Device (a single RATS entity). + Examples of these types of co-located environments include: a Trusted + Execution Environment (TEE), Baseboard Management Controllers (BMCs), + as well as other physical or logical protected/isolated/shielded + Computing Environments (e.g. embedded Secure Elements (eSE) or + Trusted Platform Modules (TPM)). Readers of this document should be + familiar with the concept of Layered Attestation as described in + Section 4.3 Two Types of Environments of an Attester in + [I-D.ietf-rats-architecture] and the definition of Attestation as + described in [I-D.ietf-rats-tpm-based-network-device-attest]. 4. Scope and Intent This document focuses on generic interaction models between Attesters and Verifiers in order to convey Evidence. Complementary procedures, functions, or services that are required for a complete semantic binding of the concepts defined in [I-D.ietf-rats-architecture] are out-of-scope of this document. Examples include: identity establishment, key distribution and enrollment, time synchronization, as well as certificate revocation. @@ -190,89 +195,91 @@ 5. Direct Anonymous Attestation DAA [DAA] is a signature scheme used in RATS that allows preservation of the privacy of users that are associated with an Attester (e.g. its owner). Essentially, DAA can be seen as a group signature scheme with the feature that given a DAA signature no-one can find out who the signer is, i.e., the anonymity is not revocable. To be able to sign anonymously an Attester has to obtain a credential from a DAA Issuer. The DAA Issuer uses a private/public key pair to generate a credential for an Attester and makes the public key (in the form of a - public key certificate) available to the verifier to enable them to - validate the DAA signature obtained as part of the Evidence. + public key certificate) available to the verifier in order to enable + them to validate the DAA signature obtained as part of the Evidence. In order to support these DAA signatures, the DAA Issuer MUST associate a single key pair with each group of Attesters and use the same key pair when creating the credentials for all of the Attesters - in this group. The DAA Issuer's public key certificate for the group - replaces the Attester Identity documents in the verification of the - Evidence (instead of unique Attester Identity documents). This is in - contrast to intuition that there has to be a unique Attester Identity - per device. + in this group. The DAA Issuer's public key certificate used by a + group of Attesters replaces the individual Attester Identity + documents during authenticity validation as a part of the appraisal + of Evidence conducted by a Verifier. This is in contrast to + intuition that there has to be a unique Attester Identity per device. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections. 5.1. Endorsers - Via its Attesting Environments, an Attester can only create Evidence + Via its Attesting Environments, an Attester only generates Evidence about its Target Environments. After being appraised to be trustworthy, a Target Environment may become a new Attesting - Environment in charge of creating Evidence for further Target + Environment in charge of generating Evidence for further Target Environments. [I-D.ietf-rats-architecture] explains this as Layered Attestation. Layered Attestation has to start with an initial - Attesting Environment (i.e., there cannot be turtles all the way down - [turtles]). At this rock bottom of Layered Attestation, the - Attesting Environments are called Roots of Trust (RoT). An Attester - cannot create Evidence about its own RoTs by design. As a + Attesting Environment. In essence, there cannot be turtles all the + way down [turtles]. At this rock bottom of Layered Attestation, the + Attesting Environments are always called Roots of Trust (RoT). An + Attester cannot generate Evidence about its own RoTs by design. As a consequence, a Verifier requires trustable statements about this subset of Attesting Environments from a different source than the Attester itself. The corresponding trustable statements are called Endorsements and originate from external, trustable entities that take on the role of an Endorser (e.g., supply chain entities). 5.2. Endorsers for Direct Anonymous Attestation - In order to enable DAA to be used, an Endorser role takes on the + In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these - certificates share the semantics of Endorsements. The differences - are: + certificates share the semantics of Endorsements, with the following + exceptions: o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the - Attester randomises this credential each time that it is used. + Attester randomizes this credential each time that it is used. o The Verifier can use the DAA Issuer's public key certificate, - together with the randomised credential from the Attester, to + together with the randomized credential from the Attester, to confirm that the Evidence comes from a valid Attester. - o A credential is conveyed from an Endorser to an Attester together - with the transfer of the public key certificates from Endorser to - Verifier. + o A credential is conveyed from an Endorser to an Attester in + combination with the conveyance of the public key certificates + from Endorser to Verifier. The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a - trustable third entity - like an Endorser. Due to that vast semantic - overlap (XXX-mcr:explain), an Endorser in this document can convey - trustable third party statements both to a Verifier and an Attester. + trustable third entity - like an Endorser. Due to that semantic + overlap, the Endorser role is augmented via the definition of DAA + duties as defined below. This augmentation enables the Endorser to + convey trustable third party statements both to Verifier roles and + Attester roles. 6. Normative Prerequisites - In order to ensure an appropriate conveyance of Evidence, the - following set of prerequisites MUST be in place to support the - implementation of interaction models: + In order to ensure an appropriate conveyance of Evidence via + interaction models in general, the following set of prerequisites + MUST be in place to support the implementation of interaction models: Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. An Attester Identity MAY be a unique identity, it MAY be included in a zero-knowledge proof (ZKP), or it MAY be part of a group signature, or it MAY be a randomised DAA credential. Attestation Evidence Authenticity: Attestation Evidence MUST be @@ -286,94 +293,100 @@ Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Evidence Freshness: Evidence MUST include an indicator about its - Freshness that can be understood by a Verifier. Analogously, + freshness that can be understood by a Verifier. Analogously, interaction models MUST support the conveyance of proofs of freshness in a way that is useful to Verifiers and their appraisal procedures. Evidence Protection: Evidence MUST be a set of well-formatted and well-protected Claims that an Attester can create and convey to a Verifier in a tamper-evident manner. 7. Generic Information Elements This section defines the information elements that are vital to all kinds interaction models. Varying from solution to solution, generic information elements can be either included in the scope of protocol - messages or can be included in their payload. Ultimately, the - following information elements are required by any kind of scalable - remote attestation procedure using one or more of the interaction - models provided. + messages (instantiating Conceptual Messages) or can be included in + additional protocol parameters or payload. Ultimately, the following + information elements are required by any kind of scalable remote + attestation procedure using one or more of the interaction models + provided. Attester Identity ('attesterIdentity'): _mandatory_ A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. - In DAA the Attester's identity is not revealed to the verifier. + In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Authentication Secret IDs ('authSecID'): _mandatory_ A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to - protect Evidence. In DAA, Authentication Secret IDs are - represented by the Endorser (DAA issuer)'s public key that MUST be - used to create DAA credentials for the corresponding - Authentication Secrets used to protect Evidence. + protect Evidence. + + In DAA, Authentication Secret IDs are represented by the Endorser + (DAA issuer)'s public key that MUST be used to create DAA + credentials for the corresponding Authentication Secrets used to + protect Evidence. Each Authentication Secret is uniquely associated with a distinguishable Attesting Environment. Consequently, an Authentication Secret ID also identifies an Attesting Environment. - In DAA an Authentication Secret ID does not identify a unique + + In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments. This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Handle ('handle'): _mandatory_ A statement that is intended to uniquely distinguish received - Evidence and/or determine the Freshness of Evidence. + Evidence and/or determine the freshness of Evidence. A Verifier can also use a Handle as an indicator for authenticity or attestation provenance, as only Attesters and Verifiers that are intended to exchange Evidence should have knowledge of the corresponding Handles. Examples include Nonces or signed timestamps. Claims ('claims'): _mandatory_ Claims are assertions that represent characteristics of an Attester's Target Environment. Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers. The other information elements in this section can be expressed as Claims in any type of Conceptional Messages. Reference Claims ('refClaims') _mandatory_ - - Reference Claims are a specific subset of Appraisal Policies as - defined in [I-D.ietf-rats-architecture]. + Reference Claims are components of Reference Values as defined in + [I-D.ietf-rats-architecture]. [Editor's Note: Definition might + become obsolete, if replaced by Reference Values. Is there a + difference between Claims and Values here? Analogously, why is + not named Reference Claims in the RATS arch?] Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. For example, Reference Claims MAY be Reference Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see Endorsements in [I-D.ietf-rats-architecture]). Reference Claims typically represent (trusted) Claim sets about an Attester's intended platform operational state. @@ -386,52 +399,51 @@ of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. Evidence ('signedAttestationEvidence'): _mandatory_ A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a Handle. Attestation Evidence MUST cryptographically bind all of - these information elements. The Evidence MUST be protected via - the Authentication Secret. The Authentication Secret MUST be - trusted by the Verifier as authoritative. + these information elements. Evidence MUST be protected via an + Authentication Secret. The Authentication Secret MUST be trusted + by the Verifier as authoritative. Attestation Result ('attestationResult'): _mandatory_ An Attestation Result is produced by the Verifier as the output of the appraisal of Evidence. Attestation Results include condensed assertions about integrity or other characteristics of the - corresponding Attester. + corresponding Attester that are digestable by Relying Parties. 8. Interaction Models The following subsections introduce and illustrate the interaction models: 1. Challenge/Response Remote Attestation - 2. Uni-Directional Remote Attestation 3. Streaming Remote Attestation Each section starts with a sequence diagram illustrating the - interactions between Attester and Verifier. The other roles RATS - roles - mainly Relying Parties and Endorsers - are not relevant for - this interaction model. While the interaction models presented focus - on the conveyance of Evidence, future work could apply this to the - conveyance of other Conceptual Messages, namely Attestation Results, - Endorsements, or Appraisal Policies. + interactions between Attester and Verifier. While the interaction + models presented focus on the conveyance of Evidence, the intention + of this document is in support of future work that applies the + presented models to the conveyance of other Conceptual Messages, + namely Attestation Results, Endorsements, Reference Values, or + Appraisal Policies. - All interaction model have a strong focus on the use of a handle to - incorporate a proof of freshness. The ways these handles are + All interaction models have a strong focus on the use of a handle to + incorporate a type of proof of freshness. The ways these handles are processed is the most prominent difference between the three interaction models. 8.1. Challenge/Response Remote Attestation .----------. .----------. | Attester | | Verifier | '----------' '----------' | | | | @@ -516,35 +529,33 @@ | | | handle----------> | | '--------------------' | | | evidenceGeneration(handle, authSecIDs, collectedClaims) | | => evidence | | | | pushEventLog---------------------------------------------> | | pushEvidence---------------------------------------------> | | | | appraiseEvidence(evidence, eventLog, refClaims) - | evidenceAppraisal(evidence, refClaims) | attestationResult <= | ~ ~ | | valueGeneration(targetEnvironment) | | => claimsDelta | | | evidenceGeneration(handle, authSecIDs, collectedClaims) | | => evidence | | | | pushEventLogDelta----------------------------------------> | | pushEvidence---------------------------------------------> | | | | appraiseEvidence(evidence, eventLogDelta, refClaims) - | evidenceAppraisal(evidence, refClaims) | attestationResult <= | | | Uni-Directional Remote Attestation procedures can be initiated both by the Attester and by the Verifier. Initiation by the Attester can result in unsolicited pushes of Evidence to the Verifier. Initiation by the Verifier always results in solicited pushes to the Verifier. The Uni-Directional model uses the same information elements as the Challenge/Response model. In the sequence diagram above, the Attester initiates the conveyance of Evidence (comparable with a @@ -693,23 +704,23 @@ The open-source implementation project resource can be located via: https://github.com/Fraunhofer-SIT/charra 10.4. Maturity The code's level of maturity is considered to be "prototype". 10.5. Coverage and Version Compatibility - The current version (commit '847bcde') is aligned with the exemplary - specification of the CoAP FETCH bodies defined in section Appendix A - of this document. + The current version ('1bcb469') implements a challenge/response + interaction model and is aligned with the exemplary specification of + the CoAP FETCH bodies defined in Section Appendix A of this document. 10.6. License The CHARRA project and all corresponding code and data maintained on github are provided under the BSD 3-Clause "New" or "Revised" license. 10.7. Implementation Dependencies The implementation requires the use of the official Trusted Computing @@ -881,22 +892,28 @@ page 132-145, 2004. [I-D.birkholz-rats-tuda] Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, "Time-Based Uni-Directional Attestation", draft-birkholz- rats-tuda-03 (work in progress), July 2020. [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", - draft-ietf-rats-architecture-06 (work in progress), - September 2020. + draft-ietf-rats-architecture-07 (work in progress), + October 2020. + + [I-D.ietf-rats-tpm-based-network-device-attest] + Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- + based Network Device Remote Integrity Verification", + draft-ietf-rats-tpm-based-network-device-attest-04 (work + in progress), September 2020. [turtles] Rudnicki, R., "Turtles All the Way Down: Foundation, Edifice, and Ruin in Faulkner and McCarthy", The Faulkner Journal 25.2, DOI 10.1353/fau.2010.0002, 2010. Appendix A. CDDL Specification for a simple CoAP Challenge/Response Interaction The following CDDL specification is an exemplary proof-of-concept to illustrate a potential implementation of the Challenge/Response