idnits 2.17.1 draft-ietf-rats-daa-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For DAA, the Attestation Evidence conveyed to the Verifier MUST not uniqely identify the Attester. If the Attestation Evidence is unique to an Attester other cryptographic techniques can be used, for example, property based attestation. (Henk -- reference follows) -- The document date (2 December 2021) is 869 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-13 == Outdated reference: A later version (-09) exists of draft-ietf-rats-reference-interaction-models-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational C. Newton 5 Expires: 5 June 2022 L. Chen 6 University of Surrey 7 D. Thaler 8 Microsoft 9 2 December 2021 11 Direct Anonymous Attestation for the Remote Attestation Procedures 12 Architecture 13 draft-ietf-rats-daa-00 15 Abstract 17 This document maps the concept of Direct Anonymous Attestation (DAA) 18 to the Remote Attestation Procedures (RATS) Architecture. The role 19 DAA Issuer is introduced and its interactions with existing RATS 20 roles is specified. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 5 June 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Direct Anonymous Attestation . . . . . . . . . . . . . . . . 3 58 4. DAA changes to the RATS Architecture . . . . . . . . . . . . 5 59 5. Additions to Remote Attestation principles . . . . . . . . . 6 60 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 8. Implementation Considerations . . . . . . . . . . . . . . . . 7 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 10.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture]) 72 describe interactions between well-defined architectural constituents 73 in support of Relying Parties that require an understanding about the 74 trustworthiness of a remote peer. The identity of an Attester and 75 its corresponding Attesting Environments play a vital role in RATS. 76 A common way to refer to such an identity is the Authentication 77 Secret ID as defined in the Reference Interaction Models for RATS 78 [I-D.ietf-rats-reference-interaction-models]. The fact that every 79 Attesting Environment can be uniquely identified in the context of 80 the RATS architecture is not suitable for every application of remote 81 attestation. Additional issues may arise when Personally 82 identifiable information (PII) -- whether obfuscated or in clear text 83 -- are included in attestation Evidence or even corresponding 84 Attestation Results. This document illustrates how Direct Anonymous 85 Attestation (DAA) can mitigate the issue of uniquely 86 (re-)identifiable Attesting Environments. To accomplish that goal, a 87 new RATS role -- the DAA Issuer -- is introduced and its duties as 88 well as its interactions with other RATS roles are specified. 90 2. Terminology 92 This document uses the following set of terms, roles, and concepts as 93 defined in [I-D.ietf-rats-architecture]: Attester, Verifier, Relying 94 Party, Conceptual Message, Evidence, Attestation Result, Attesting 95 Environment. The role of Endorser, also defined in 96 [I-D.ietf-rats-architecture], needs to be adapted and details are 97 given below. 99 Additionally, this document uses and adapts, as necessary, the 100 following concepts and information elements as defined in 101 [I-D.ietf-rats-reference-interaction-models]: Attester Identity, 102 Authentication Secret, Authentication Secret ID 104 A PKIX Certificate is an X.509v3 format certificate as specified by 105 [RFC5280]. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 3. Direct Anonymous Attestation 115 Figure 1 shows the data flows between the different RATS roles 116 involved in DAA. 118 ************ ************* ************ ***************** 119 * Endorser * * Reference * * Verifier * * Relying Party * 120 ************ * Value * * Owner * * Owner * 121 | * Provider * ************ ***************** 122 | ************* | | 123 | | | | 124 |Endorsements |Reference |Appraisal |Appraisal 125 | |Values |Policy |Policy for 126 | | |for |Attestation 127 | | |Evidence |Results 128 V | | | 129 .-----------------. | | | 130 | DAA Issuer |---------. | | | 131 '-----------------' | | | | 132 ^ | Group| | | | 133 | | Public| | | | 134 |Credential| Key| | | | 135 |Request | v v v | 136 | | .----------------------. | 137 | | .->| Verifier |--. | 138 | | | '----------------------' | | 139 | | | | | 140 | | |Evidence Attestation| | 141 | | | Results| | 142 | | | | | 143 | |Credential| | | 144 | | | | | 145 | v | v v 146 | .-------------. .---------------. 147 '--------| Attester | | Relying Party | 148 '-------------' '---------------' 150 Figure 1: DAA data flows 152 DAA [DAA] is a signature scheme that allows the privacy of users that 153 are associated with an Attester (e.g. its owner) to be maintained. 154 Essentially, DAA can be seen as a group signature scheme with the 155 feature that given a DAA signature no-one can find out who the signer 156 is, i.e., the anonymity is not revocable. To be able to sign 157 anonymously, an Attester has to obtain a credential from a DAA 158 Issuer. The DAA Issuer uses a private/public key pair to generate 159 credentials for a group of Attesters and makes the public key (in the 160 form of a public key certificate) available to the verifier in order 161 to enable them to validate the Evidence received. 163 In order to support these DAA signatures, the DAA Issuer MUST 164 associate a single key pair with a group of Attesters and use the 165 same key pair when creating the credentials for all of the Attesters 166 in this group. The DAA Issuer's group public key certificate 167 replaces the individual Attester Identity documents during 168 authenticity validation as a part of the appraisal of Evidence 169 conducted by a verifier. This is in contrast to intuition that there 170 has to be a unique Attester Identity per device. 172 For DAA, the role of the Endorser is essentially the same, but they 173 now provide Attester endorsement documents to the DAA Issuer rather 174 than directly to the verifier. These Attester endorsement documents 175 enable the Attester to obtain a credential from the DAA Issuer. 177 4. DAA changes to the RATS Architecture 179 In order to enable the use of DAA, a new conceptual message, the 180 Credential Request, is defined and a new role, the DAA Issuer role, 181 is added to the roles defined in the RATS Architecture. 183 Credential Request: An Attester sends a Credential Request to the 184 DAA Issuer to obtain a credential. This request contains 185 information about the DAA key that the Attester will use to create 186 evidence and together with Attester endorsement information that 187 is provided by the Endorser to confirm that the request came from 188 a valid Attester. 190 DAA Issuer: A RATS role that offers zero-knowledge proofs based on 191 public-key certificates used for a group of Attesters (Group 192 Public Keys) [DAA]. How this group of Attesters is defined is not 193 specified here, but the group must be large enough for the 194 necessary anonymity to be assured. 196 Effectively, these certificates share the semantics of Endorsements, 197 with the following exceptions: 199 * Upon receiving a Credential Request from an Attester, the 200 associated group private key is used by the DAA Issuer to provide 201 the Attester with a credential that it can use to convince the 202 Verifier that its Evidence is valid. To keep their anonymity the 203 Attester randomizes this credential each time that it is used. 204 Although the DAA Issuer knows the Attester Identity and can 205 associate this with the credential issued, randomisation ensures 206 that the Attester's identity cannot be revealed to anyone, 207 including the Issuer. 209 * The Verifier can use the DAA Issuer's group public key 210 certificate, together with the randomized credential from the 211 Attester, to confirm that the Evidence comes from a valid Attester 212 without revealing the Attester's identity. 214 * A credential is conveyed from a DAA Issuer to an Attester in 215 combination with the conveyance of the group public key 216 certificate from DAA Issuer to Verifier. 218 5. Additions to Remote Attestation principles 220 In order to ensure an appropriate conveyance of Evidence via 221 interaction models in general, the following prerequisite considering 222 Attester Identity MUST be in place to support the implementation of 223 interaction models. 225 Attestation Evidence Authenticity: Attestation Evidence MUST be 226 correct and authentic. 228 In order to provide proofs of authenticity, Attestation Evidence 229 SHOULD be cryptographically associated with an identity document 230 that is a randomised DAA credential. 232 The following information elements define extensions for 233 corresponding information elements defined in 234 [I-D.ietf-rats-reference-interaction-models] and that are vital to 235 all types of reference interaction models. Varying from solution to 236 solution, generic information elements can be either included in the 237 scope of protocol messages (instantiating Conceptual Messages defined 238 by the RATS architecture) or can be included in additional protocol 239 parameters of protocols that facilitate the conveyance of RATS 240 Conceptual Messages. Ultimately, the following information elements 241 are required by any kind of scalable remote attestation procedure 242 using DAA with one of RATS's reference interaction models. 244 Attester Identity ('attesterIdentity'): _mandatory_ 246 In DAA, the Attester's identity is not revealed to the verifier. 247 The Attester is issued with a credential by the DAA Issuer that is 248 randomised and then used to anonymously confirm the validity of 249 their evidence. The evidence is verified using the DAA Issuer's 250 group public key. 252 Authentication Secret IDs ('authSecID'): _mandatory_ 254 In DAA, Authentication Secret IDs are represented by the DAA 255 Issuer's group public key that MUST be used to create DAA 256 credentials for the corresponding Authentication Secrets used to 257 protect Evidence. 259 In DAA, an Authentication Secret ID does not identify a unique 260 Attesting Environment but is associated with a group of Attesting 261 Environments. This is because an Attesting Environment should not 262 be distinguishable and the DAA credential which represents the 263 Attesting Environment is randomised each time it used. 265 6. Privacy Considerations 267 As outlined about for DAA to provide privacy for the Attester the DAA 268 group must be large enough to stop the Verifier identifying the 269 Attester. 271 Randomization of the DAA credential by the Attester means that 272 collusion between the DAA Issuer and Verifier, will not give them any 273 advantage when trying to identify the Attester. 275 For DAA, the Attestation Evidence conveyed to the Verifier MUST not 276 uniqely identify the Attester. If the Attestation Evidence is unique 277 to an Attester other cryptographic techniques can be used, for 278 example, property based attestation. (Henk -- reference follows) 280 Chen L., Loehr H., Manulis M., Sadeghi AR. (2008) Property-Based 281 Attestation without a Trusted Third Party. Information Security. 282 ISC 2008. Lecture Notes in Computer Science, vol 5222. Springer. 283 https://doi.org/10.1007/978-3-540-85886-7_3 285 7. Security Considerations 287 The anonymity property of DAA makes revocation difficult. Well known 288 solutions include: 1. Rogue attester revocation -- if the an 289 Attester's private key is compromised and known by the Verifier then 290 any DAA signature from that Attester can be revoked. 2. EPID - 291 Intel's Enhanced Privacy ID -- this requires the Attester to prove 292 (as part of their Attestation) that their credential was not used to 293 generate any signature in a signature revocation list. 295 There are no other special security conderations for DAA over and 296 above those specifed in the RATS architecture document 297 [I-D.ietf-rats-architecture]. 299 8. Implementation Considerations 301 The new DAA Issuer role can be implemented in a number of ways, for 302 example: 1. As a stand-alone service like a Certificate Authority, a 303 Privacy CA. 2. As a part of the Attester's manufacture. The 304 Endorser and the DAA Issuer could be the same entity and the 305 manufacturer would then provide a certificate for the group public 306 key to the Verifier. 308 9. IANA Considerations 310 We don't yet. 312 10. References 314 10.1. Normative References 316 [DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct 317 Anonymous Attestation", page 132-145, ACM Proceedings of 318 the 11rd ACM conference on Computer and Communications 319 Security, 2004. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, 324 . 326 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 327 Housley, R., and W. Polk, "Internet X.509 Public Key 328 Infrastructure Certificate and Certificate Revocation List 329 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 330 . 332 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 333 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 334 May 2017, . 336 10.2. Informative References 338 [I-D.ietf-rats-architecture] 339 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 340 W. Pan, "Remote Attestation Procedures Architecture", Work 341 in Progress, Internet-Draft, draft-ietf-rats-architecture- 342 13, 8 November 2021, . 345 [I-D.ietf-rats-reference-interaction-models] 346 Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference 347 Interaction Models for Remote Attestation Procedures", 348 Work in Progress, Internet-Draft, draft-ietf-rats- 349 reference-interaction-models-04, 26 July 2021, 350 . 353 Authors' Addresses 354 Henk Birkholz 355 Fraunhofer SIT 356 Rheinstrasse 75 357 64295 Darmstadt 358 Germany 360 Email: henk.birkholz@sit.fraunhofer.de 362 Christopher Newton 363 University of Surrey 365 Email: cn0016@surrey.ac.uk 367 Liqun Chen 368 University of Surrey 370 Email: liqun.chen@surrey.ac.uk 372 Dave Thaler 373 Microsoft 374 United States of America 376 Email: dthaler@microsoft.com