idnits 2.17.1 draft-moriarty-attestationsets-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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 22 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 2, 2021) is 1118 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) == Unused Reference: 'RFC2119' is defined on line 249, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF K. Moriarty 3 Internet-Draft Center for Internet Security (CIS) 4 Intended status: Standards Track April 2, 2021 5 Expires: October 4, 2021 7 Scalable Remote Attestation for Systems, Containers, and Applications 8 draft-moriarty-attestationsets-01 10 Abstract 12 This document establishes an architectural pattern whereby a remote 13 attestation could be issued for a complete set of benchmarks or 14 controls that are defined and grouped by an external entity, 15 preventing the need to send over individual attestations for each 16 item within a benchmark or control framework. This document 17 establishes a pattern to list sets of benchmarks and controls within 18 CWT and JWT formats for use as an Entity Attestation Token (EAT). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 4, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Policy and Measurement Set Definitions . . . . . . . . . . . 4 56 3. Supportability and Re-Attestation . . . . . . . . . . . . . . 4 57 4. Configuration Sets . . . . . . . . . . . . . . . . . . . . . 5 58 5. Remediation . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 9.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 66 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Attestation from a root of trust (hardware or software), may be 72 accomplished via a number of formats. Some use cases are well 73 defined, including the Root of Trust (RoT) (e.g. Trusted Platfrom 74 Module, OpenTitan) and attestation format as well as the specific 75 policy and measurement expectations at boot. Device identity and 76 measurements can be attestated at runtime. The attestations on 77 evidence (e.g. hash of boot element) and verification of attestations 78 are typically contained within a system and are limited to the 79 control plane for management. The policy and measurement sets for 80 comparison are protected to assure the result in the attestation 81 verification process for boot element. Event logs and PCR values may 82 be exposed to provide transparency into the verified attestations. 83 Remote attestation on systems is intended to provide an assessment of 84 posture for all managed systems and across various layers in each of 85 these systems in an environment. This document describes a method to 86 use existing attestation formats and protocols while allowing for 87 profiles of policies and measurements at defined assurance levels 88 that scale to provide transparency to posture assessment results with 89 remote attestation. 91 There is a balance of exposure and evidence needed to assess posture 92 when providing assurance of controls and system state. Currently, 93 logs and TPM PCR values may be passed to provide assurance of 94 verification of attestation evidence meeting set requirements. 95 Providing the assurance can be accomplished with a remote attestation 96 format such as the Entity Attestation Token (EAT) [I-D.ietf-rats-eat] 97 and a RESTful interface such as ROLIE or RedFish. Policy definition 98 blocks may be scoped to control measurement sets, where the EAT 99 asserts compliance to the policy or measurement block specified and 100 may include claims with the log and PCR value evidence. Measurement 101 and Policy sets may be published and maintained by separate entities. 102 The policy and measurement sets should be maintained separately even 103 if associated with the same benchmark or control set. This avoids 104 the need to transition the verifying entity to a remote system for 105 individual policy and measurements which are performed locally for 106 more immediate remediation as well as other functions. 108 Posture assessment has long been desired, but has been difficult to 109 achieve due to complexities of customization requirements at each 110 organization. By using policy and measurement sets that may be 111 offered at various assurance levels, automating posture assessment 112 through attestation becomes achievable for organizations of all 113 sizes. The measurement and policy groupings may be provided by the 114 vendor or by a neutral third party. This provides simpler options to 115 enable posture assessment at selected levels by organizations without 116 the need to have in-house expertise. The measurement and policy sets 117 may also be customized, but not necessary to achieve posture 118 assessment to predefined options. 120 Examples of measurement and policy sets include, but are not limited 121 to: 123 o Hardware attribute certificates 125 o Hardware Attribute Certificate Comparison Results 127 o Reference Integrity Measurements for firmware 129 o Operating system benchmarks at Specified Assurance Levels 131 o Application hardening Benchmarks at Specified Assurance Levels 133 o Container security benchmarks at Specified Assurance Levels 135 Scale, ease of use, full automation, and consistency for customer 136 consumption of a remote attestation function or service are essential 137 toward the goal of consistently securing systems against known 138 threats and vulnerabilities. Mitigations may be baked into policy. 139 Measurement verification sets and the attestation that the sets meet 140 expected policies and measurements are conveyed in an Entity 141 Attestation Token made available to a RESTful interface in aggregate 142 for the systems managed. 144 2. Policy and Measurement Set Definitions 146 This document defines EAT claims in the JWT [RFC7519] and CWT 147 [RFC8392] registries to provide attestation to a set of verified 148 claims within a defined grouping. The trustworthiness will be 149 conveyed on original verified evidence as well as the attestation on 150 the grouping. 152 { 153 +------------------------------------+---------------------------------+---------------+ 154 | Claim | Long Name | Description | Format | 155 +-------+----------------------------+---------------------------------+---------------+ 156 | MPS | Measurement or Policy Set | Name for the MPS | | 157 | LEM | Log Evidence of MPS | Log File or URI | | 158 | PCR | TPM PCR Values | | | 159 | FMA | Format of MPS Attestations | Format of included attestations | | 160 | HSH | Hash Value/Message Digest | Hash va,ue of configuration set | | 161 +-------+----------------------------+---------------------------------+---------------+ 162 } 164 3. Supportability and Re-Attestation 166 The remote attestation framework shall include provisions within the 167 system and attestation authority to allow for Product modification. 169 Over its lifecycle, the Product may experience modification due to: 170 maintenance, failures, upgrades, expansion, moves, etc.. 172 The customer can chose to: 174 o Run remote attestation after product modification, or 176 o Not take action and remain un-protected 178 In the case of Re-Attestation: 180 o framework needs to invalidate previous TPM PCR values and tokens, 182 o framework needs to collect new measurements, 184 o framework needs to maintain history or allow for history to be 185 logged to enable change traceability attestation, and 187 o framework needs to notify that the previous attestation has been 188 invalidated 190 4. Configuration Sets 192 In some cases, it may be difficult to attest to configuration 193 settings for the initial or subsequent attestation and verification 194 processes. The use of an expected hash value for configuration 195 settings can be used to compare the attested configuration set. In 196 this case, the creator of the attestation verification measurements 197 would define a set of values for which a message digest would be 198 created and then signed by the attestor. The expected measurements 199 would include the expected hash value for comparison. The 200 configuration set could be the full attestation set to a Benchmark or 201 a defined subset. 203 5. Remediation 205 If policy and configration settings or measurements attestated do not 206 meet expected values, remediation is desireable. Automated 207 remediation performed with alignment to zero trust architecture 208 principles would require that the remeidation be performed prior to 209 any relying component executing. The relying component would verifiy 210 before continuing in a zero trust architecture. 212 Ideally, remediation would occur on system as part of the process to 213 attest to a set of attestations, similar to how attestation is 214 performed for firmware in the boot process. If automated remediation 215 is not possible, an alert should be generated to allow for 216 notification of the variance from expected values. 218 6. Security Considerations 220 This document establishes a pattern to list sets of benchmarks and 221 controls within CWT and JWT formats. The contents of the benchmarks 222 and controls are out of scope for this document. This establishes an 223 architectural pattern whereby a remote attestation could be issued 224 for a complete set of benchmarks or controls as defined and grouped 225 by external entities, preventing the need to send over individual 226 attestations for each item within a benchmark or control framework. 227 This document does not add security consideration over what has been 228 described in the EAT, JWT, or CWT specifications. 230 7. IANA Considerations 232 This memo includes no request to IANA, yet. This will list the 233 initial registration sets to the JWT and CWT registries if adopted. 235 8. Contributors 237 Thank you to reviewers and contributors who helped to improve this 238 document. Thank you to Nick Grobelney, Dell Technologies, for your 239 review and contribution to separate out the policy and measurement 240 sets. Thank you, Samant Kakarla and Huijun Xie from Dell 241 Technologies, for your detailed review and corrections on boot 242 process details. Section 3 has been contributed by Rudy Bauer from 243 Dell as well and an author will be added on the next reveision. 245 9. References 247 9.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 255 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 256 . 258 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 259 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 260 May 2018, . 262 9.2. Informative References 264 [I-D.ietf-rats-eat] 265 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 266 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 267 ietf-rats-eat-06 (work in progress), December 2020. 269 Appendix A. Change Log 271 Note to RFC Editor: if this document does not obsolete an existing 272 RFC, please remove this appendix before publication as an RFC. 274 Appendix B. Open Issues 276 Note to RFC Editor: please remove this appendix before publication as 277 an RFC. 279 Author's Address 281 Kathleen M. Moriarty 282 Center for Internet Security (CIS) 283 31 Tech Valley Drive 284 East Greenbush, NY 285 US 287 EMail: Kathleen.Moriarty.ietf@gmail.com