--- 1/draft-ietf-rats-reference-interaction-models-04.txt 2022-01-26 12:13:43.820317523 -0800 +++ 2/draft-ietf-rats-reference-interaction-models-05.txt 2022-01-26 12:13:43.876318925 -0800 @@ -1,22 +1,22 @@ RATS Working Group H. Birkholz Internet-Draft M. Eckel Intended status: Informational Fraunhofer SIT -Expires: 27 January 2022 W. Pan +Expires: 30 July 2022 W. Pan Huawei Technologies E. Voit Cisco - 26 July 2021 + 26 January 2022 Reference Interaction Models for Remote Attestation Procedures - draft-ietf-rats-reference-interaction-models-04 + draft-ietf-rats-reference-interaction-models-05 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. @@ -28,71 +28,73 @@ 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 27 January 2022. + This Internet-Draft will expire on 30 July 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License text - as described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Simplified BSD License. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Disambiguation . . . . . . . . . . . . . . . . . . . . . 4 3. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4 4. Essential Requirements . . . . . . . . . . . . . . . . . . . 5 4.1. Endorsement of Attesting Environments . . . . . . . . . . 5 5. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6 6. Generic Information Elements . . . . . . . . . . . . . . . . 7 7. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9 7.1. Challenge/Response Remote Attestation . . . . . . . . . . 9 - 7.2. Uni-Directional Remote Attestation . . . . . . . . . . . 11 - 7.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13 - 8. Additional Application-Specific Requirements . . . . . . . . 15 - 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15 - 8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15 - 8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15 - 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 - 9.1. Implementer . . . . . . . . . . . . . . . . . . . . . . . 16 - 9.2. Implementation Name . . . . . . . . . . . . . . . . . . . 16 - 9.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16 - 9.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9.5. Coverage and Version Compatibility . . . . . . . . . . . 16 - 9.6. License . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 9.7. Implementation Dependencies . . . . . . . . . . . . . . . 17 - 9.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10. Security and Privacy Considerations . . . . . . . . . . . . . 17 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 12.2. Informative References . . . . . . . . . . . . . . . . . 18 + 7.1.1. Models and example sequences of Challenge/Response + Remote Attestation . . . . . . . . . . . . . . . . . 11 + 7.2. Uni-Directional Remote Attestation . . . . . . . . . . . 13 + 7.3. Streaming Remote Attestation . . . . . . . . . . . . . . 15 + 8. Additional Application-Specific Requirements . . . . . . . . 17 + 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 17 + 8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 17 + 8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 17 + 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 + 9.1. Implementer . . . . . . . . . . . . . . . . . . . . . . . 18 + 9.2. Implementation Name . . . . . . . . . . . . . . . . . . . 18 + 9.3. Implementation URL . . . . . . . . . . . . . . . . . . . 18 + 9.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9.5. Coverage and Version Compatibility . . . . . . . . . . . 18 + 9.6. License . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9.7. Implementation Dependencies . . . . . . . . . . . . . . . 19 + 9.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10. Security and Privacy Considerations . . . . . . . . . . . . . 19 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 12.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. CDDL Specification for a simple CoAP Challenge/ - Response Interaction . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + 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 -- generated by an @@ -468,20 +470,108 @@ appraises the Evidence. For this purpose, it validates the signature, the Attester Identity, and the Handle, and then appraises the Claims. Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference Values, such as Reference Integrity Measurements. The final output of the Verifier are Attestation Results. Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an Attester's trustworthiness. +7.1.1. Models and example sequences of Challenge/Response Remote + Attestation + + According to the RATS Architecture, two reference models for + Challenge/Response Attestation have been proposed. This section + highlights the information flows bewteen the Attester, Verifier and + Relying Party undergoing Remote Attestation Procedure, using these + models. + + 1. Passport Model + The passport model is so named because of its resemblance to how + nations issue passports to their citizens. In this model, the + attestation sequence is a two step procedure. In the first step, an + Attester conveys Evidence to a Verifier which compares the Evidence + against its appraisal policy. The Verifier then gives back an + Attestation Result to the Attester, which simply caches it. In the + second step, the Attester presents the Attestation Result (and + possibly additional Claims/evidence) to a Relying Party, which then + compares this information against its own appraisal policy to + establish the trustworthiness of the Attester. + +.----------. .----------. .----------. +| Attester | | Verifier | | R. P. | +'----------' '----------' '----------' + | | | + generateClaims(attestingEnvironment) | | + | => claims, eventLogs | | + | | | + | <-- requestAttestation(handle, authSecIDs, claimSelection) | | + | | | + collectClaims(claims, claimSelection) | | + | => collectedClaims | | + | | | + generateEvidence(handle, authSecIDs, collectedClaims) | | + | => evidence | | + | | | + | evidence, eventLogs -------------------------------------> | | + | | | + | appraiseEvidence(evidence, eventLogs, refValues) | + | | | + | attestationResults <----------------------------------- | | + | | | + | attestationResults(evidence, results) ----------------------------------------------------------> | | | | + | | | | | | appraiseResult() + | | | + + 1. BackGround Check Model + + The background-check model is so named because of the resemblance of + how employers and volunteer organizations perform background checks. + In this model, the attestation sequence is initiated by a Relying + Party. The Attester conveys Evidence to the Relying Party, which + does not process its payload, but realys the message and optionally + check its signature against a policed trust anchor store. Upon + receiving the evidence the Relying Party initiates a session with the + Verifier. Once session is established, it forwards the received + Evidence to the Verfier. The Verifier, appraises the received + Evidence according to its appraisal policy for Evidence and returns a + corresponding Attestation Result to the Relying Party. The Relying + Party then checks the Attestation Result against its own appraisal + policy to conclude attestation. + +.----------. .----------. .----------. +| Attester | | R. P. | | Verifier | +'----------' '----------' '----------' + | | | + generateClaims(attestingEnvironment) | | + | => claims, eventLogs | | + | | | + | <-- requestAttestation(handle, authSecIDs, claimSelection) | | + | | | + collectClaims(claims, claimSelection) | | + | => collectedClaims | | + | | | + generateEvidence(handle, authSecIDs, collectedClaims) | | + | => evidence | | + | | | + | evidence, eventLogs -------------------------------------> | | + | | | + | | handle, evidence, eventLogs -------> | + | | |appraiseEvidenc() + | | | + | | attestationResults <--------------- | + | | (evidence, results) | + | | | + | appraiseResults(evidence, results) | | + | | | + 7.2. Uni-Directional Remote Attestation .----------. .--------------------. .----------. | Attester | | Handle Distributor | | Verifier | '----------' '--------------------' '----------' | | | | generateHandle() | | | => handle | | | | | <----------------------------- handle | handle ----------> | | | | @@ -787,38 +877,38 @@ 12.2. Informative References [DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct Anonymous Attestation", page 132-145, ACM Proceedings of the 11th ACM conference on Computer and Communications Security, 2004. [I-D.birkholz-rats-tuda] Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, "Time-Based Uni-Directional Attestation", Work in - Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12 - July 2021, . + Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12 + January 2022, . [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture- - 12, 23 April 2021, . + 14, 9 December 2021, . [I-D.ietf-rats-tpm-based-network-device-attest] Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- based Network Device Remote Integrity Verification", Work in Progress, Internet-Draft, draft-ietf-rats-tpm-based- - network-device-attest-07, 10 June 2021, + network-device-attest-10, 30 December 2021, . + based-network-device-attest-10.txt>. [turtles] Rudnicki, R., "Turtles All the Way Down: Foundation, Edifice, and Ruin in Faulkner and McCarthy", DOI 10.1353/fau.2010.0002, The Faulkner Journal 25.2, 2010, . Appendix A. CDDL Specification for a simple CoAP Challenge/Response Interaction The following CDDL specification is an exemplary proof-of-concept to