idnits 2.17.1 draft-birkholz-rats-daa-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 : ---------------------------------------------------------------------------- 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 (12 July 2021) is 1018 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-12 == Outdated reference: A later version (-09) exists of draft-ietf-rats-reference-interaction-models-02 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: 13 January 2022 L. Chen 6 University of Surrey 7 12 July 2021 9 Direct Anonymous Attestation for the Remote Attestation Procedures 10 Architecture 11 draft-birkholz-rats-daa-01 13 Abstract 15 This document maps the concept of Direct Anonymous Attestation (DAA) 16 to the Remote Attestation Procedures (RATS) Architecture. The role 17 DAA Issuer is introduced and its interactions with existing RATS 18 roles is specified. 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 13 January 2022. 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 (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Direct Anonymous Attestation . . . . . . . . . . . . . . . . 3 56 4. DAA changes to the RATS Architecture . . . . . . . . . . . . 5 57 5. Additions to Remote Attestation principles . . . . . . . . . 6 58 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 8. Implementation Considerations . . . . . . . . . . . . . . . . 7 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 10.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture]) 70 describe interactions between well-defined architectural constituents 71 in support of Relying Parties that require an understanding about the 72 trustworthiness of a remote peer. The identity of an Attester and 73 its corresponding Attesting Environments play a vital role in RATS. 74 A common way to refer to such an identity is the Authentication 75 Secret ID as defined in the Reference Interaction Models for RATS 76 [I-D.ietf-rats-reference-interaction-models]. The fact that every 77 Attesting Environment can be uniquely identified in the context of 78 the RATS architecture is not suitable for every application of remote 79 attestation. Additional issues may arise when Personally 80 identifiable information (PII) -- whether obfuscated or in clear text 81 -- are included in attestation Evidence or even corresponding 82 Attestation Results. This document illustrates how Direct Anonymous 83 Attestation (DAA) can mitigate the issue of uniquely 84 (re-)identifiable Attesting Environments. To accomplish that goal, a 85 new RATS role -- the DAA Issuer -- is introduced and its duties as 86 well as its interactions with other RATS roles are specified. 88 2. Terminology 90 This document uses the following set of terms, roles, and concepts as 91 defined in [I-D.ietf-rats-architecture]: Attester, Verifier, Relying 92 Party, Conceptual Message, Evidence, Attestation Result, Attesting 93 Environment. The role of Endorser, also defined in 94 [I-D.ietf-rats-architecture], needs to be adapted and details are 95 given below. 97 Additionally, this document uses and adapts, as necessary, the 98 following concepts and information elements as defined in 99 [I-D.ietf-rats-reference-interaction-models]: Attester Identity, 100 Authentication Secret, Authentication Secret ID 102 A PKIX Certificate is an X.509v3 format certificate as specified by 103 [RFC5280]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. Direct Anonymous Attestation 113 Figure 1 shows the data flows between the different RATS roles 114 involved in DAA. 116 ************ ************* ************ ***************** 117 * Endorser * * Reference * * Verifier * * Relying Party * 118 ************ * Value * * Owner * * Owner * 119 | * Provider * ************ ***************** 120 | ************* | | 121 | | | | 122 |Endorsements |Reference |Appraisal |Appraisal 123 | |Values |Policy |Policy for 124 | | |for |Attestation 125 | | |Evidence |Results 126 V | | | 127 .-----------------. | | | 128 | DAA Issuer |---------. | | | 129 '-----------------' | | | | 130 ^ | Group| | | | 131 | | Public| | | | 132 |Credential| Key| | | | 133 |Request | v v v | 134 | | .----------------------. | 135 | | .->| Verifier |--. | 136 | | | '----------------------' | | 137 | | | | | 138 | | |Evidence Attestation| | 139 | | | Results| | 140 | | | | | 141 | |Credential| | | 142 | | | | | 143 | v | v v 144 | .-------------. .---------------. 145 '--------| Attester | | Relying Party | 146 '-------------' '---------------' 148 Figure 1: DAA data flows 150 DAA [DAA] is a signature scheme that allows the privacy of users that 151 are associated with an Attester (e.g. its owner) to be maintained. 152 Essentially, DAA can be seen as a group signature scheme with the 153 feature that given a DAA signature no-one can find out who the signer 154 is, i.e., the anonymity is not revocable. To be able to sign 155 anonymously, an Attester has to obtain a credential from a DAA 156 Issuer. The DAA Issuer uses a private/public key pair to generate 157 credentials for a group of Attesters and makes the public key (in the 158 form of a public key certificate) available to the verifier in order 159 to enable them to validate the Evidence received. 161 In order to support these DAA signatures, the DAA Issuer MUST 162 associate a single key pair with a group of Attesters and use the 163 same key pair when creating the credentials for all of the Attesters 164 in this group. The DAA Issuer's group public key certificate 165 replaces the individual Attester Identity documents during 166 authenticity validation as a part of the appraisal of Evidence 167 conducted by a verifier. This is in contrast to intuition that there 168 has to be a unique Attester Identity per device. 170 For DAA, the role of the Endorser is essentially the same, but they 171 now provide Attester endorsement documents to the DAA Issuer rather 172 than directly to the verifier. These Attester endorsement documents 173 enable the Attester to obtain a credential from the DAA Issuer. 175 4. DAA changes to the RATS Architecture 177 In order to enable the use of DAA, a new conceptual message, the 178 Credential Request, is defined and a new role, the DAA Issuer role, 179 is added to the roles defined in the RATS Architecture. 181 Credential Request: An Attester sends a Credential Request to the 182 DAA Issuer to obtain a credential. This request contains 183 information about the DAA key that the Attester will use to create 184 evidence and together with Attester endorsement information that 185 is provided by the Endorser to confirm that the request came from 186 a valid Attester. 188 DAA Issuer: A RATS role that offers zero-knowledge proofs based on 189 public-key certificates used for a group of Attesters (Group 190 Public Keys) [DAA]. How this group of Attesters is defined is not 191 specified here, but the group must be large enough for the 192 necessary anonymity to be assured. 194 Effectively, these certificates share the semantics of Endorsements, 195 with the following exceptions: 197 * Upon receiving a Credential Request from an Attester, the 198 associated group private key is used by the DAA Issuer to provide 199 the Attester with a credential that it can use to convince the 200 Verifier that its Evidence is valid. To keep their anonymity the 201 Attester randomizes this credential each time that it is used. 202 Although the DAA Issuer knows the Attester Identity and can 203 associate this with the credential issued, randomisation ensures 204 that the Attester's identity cannot be revealed to anyone, 205 including the Issuer. 207 * The Verifier can use the DAA Issuer's group public key 208 certificate, together with the randomized credential from the 209 Attester, to confirm that the Evidence comes from a valid Attester 210 without revealing the Attester's identity. 212 * A credential is conveyed from a DAA Issuer to an Attester in 213 combination with the conveyance of the group public key 214 certificate from DAA Issuer to Verifier. 216 5. Additions to Remote Attestation principles 218 In order to ensure an appropriate conveyance of Evidence via 219 interaction models in general, the following prerequisite considering 220 Attester Identity MUST be in place to support the implementation of 221 interaction models. 223 Attestation Evidence Authenticity: Attestation Evidence MUST be 224 correct and authentic. 226 In order to provide proofs of authenticity, Attestation Evidence 227 SHOULD be cryptographically associated with an identity document 228 that is a randomised DAA credential. 230 The following information elements define extensions for 231 corresponding information elements defined in 232 [I-D.ietf-rats-reference-interaction-models] and that are vital to 233 all types of reference interaction models. Varying from solution to 234 solution, generic information elements can be either included in the 235 scope of protocol messages (instantiating Conceptual Messages defined 236 by the RATS architecture) or can be included in additional protocol 237 parameters of protocols that facilitate the conveyance of RATS 238 Conceptual Messages. Ultimately, the following information elements 239 are required by any kind of scalable remote attestation procedure 240 using DAA with one of RATS's reference interaction models. 242 Attester Identity ('attesterIdentity'): _mandatory_ 244 In DAA, the Attester's identity is not revealed to the verifier. 245 The Attester is issued with a credential by the DAA Issuer that is 246 randomised and then used to anonymously confirm the validity of 247 their evidence. The evidence is verified using the DAA Issuer's 248 group public key. 250 Authentication Secret IDs ('authSecID'): _mandatory_ 252 In DAA, Authentication Secret IDs are represented by the DAA 253 Issuer's group public key that MUST be used to create DAA 254 credentials for the corresponding Authentication Secrets used to 255 protect Evidence. 257 In DAA, an Authentication Secret ID does not identify a unique 258 Attesting Environment but is associated with a group of Attesting 259 Environments. This is because an Attesting Environment should not 260 be distinguishable and the DAA credential which represents the 261 Attesting Environment is randomised each time it used. 263 6. Privacy Considerations 265 As outlined about for DAA to provide privacy for the Attester the DAA 266 group must be large enough to stop the Verifier identifying the 267 Attester. 269 Randomization of the DAA credential by the Attester means that 270 collusion between the DAA Issuer and Verifier, will not give them any 271 advantage when trying to identify the Attester. 273 For DAA, the Attestation Evidence conveyed to the Verifier MUST not 274 uniqely identify the Attester. If the Attestation Evidence is unique 275 to an Attester other cryptographic techniques can be used, for 276 example, property based attestation. (Henk -- reference follows) 278 Chen L., Loehr H., Manulis M., Sadeghi AR. (2008) Property-Based 279 Attestation without a Trusted Third Party. Information Security. 280 ISC 2008. Lecture Notes in Computer Science, vol 5222. Springer. 281 https://doi.org/10.1007/978-3-540-85886-7_3 283 7. Security Considerations 285 The anonymity property of DAA makes revocation difficult. Well known 286 solutions include: 1. Rogue attester revocation -- if the an 287 Attester's private key is compromised and known by the Verifier then 288 any DAA signature from that Attester can be revoked. 2. EPID - 289 Intel's Enhanced Privacy ID -- this requires the Attester to prove 290 (as part of their Attestation) that their credential was not used to 291 generate any signature in a signature revocation list. 293 There are no other special security conderations for DAA over and 294 above those specifed in the RATS architecture document 295 [I-D.ietf-rats-architecture]. 297 8. Implementation Considerations 299 The new DAA Issuer role can be implemented in a number of ways, for 300 example: 1. As a stand-alone service like a Certificate Authority, a 301 Privacy CA. 2. As a part of the Attester's manufacture. The 302 Endorser and the DAA Issuer could be the same entity and the 303 manufacturer would then provide a certificate for the group public 304 key to the Verifier. 306 9. IANA Considerations 308 We don't yet. 310 10. References 312 10.1. Normative References 314 [DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct 315 Anonymous Attestation", page 132-145, ACM Proceedings of 316 the 11rd ACM conference on Computer and Communications 317 Security, 2004. 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 325 Housley, R., and W. Polk, "Internet X.509 Public Key 326 Infrastructure Certificate and Certificate Revocation List 327 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 328 . 330 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 331 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 332 May 2017, . 334 10.2. Informative References 336 [I-D.ietf-rats-architecture] 337 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 338 W. Pan, "Remote Attestation Procedures Architecture", Work 339 in Progress, Internet-Draft, draft-ietf-rats-architecture- 340 12, 23 April 2021, . 343 [I-D.ietf-rats-reference-interaction-models] 344 Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference 345 Interaction Models for Remote Attestation Procedures", 346 Work in Progress, Internet-Draft, draft-ietf-rats- 347 reference-interaction-models-02, 25 April 2021, 348 . 351 Authors' Addresses 352 Henk Birkholz 353 Fraunhofer SIT 354 Rheinstrasse 75 355 64295 Darmstadt 356 Germany 358 Email: henk.birkholz@sit.fraunhofer.de 360 Christopher Newton 361 University of Surrey 363 Email: cn0016@surrey.ac.uk 365 Liqun Chen 366 University of Surrey 368 Email: liqun.chen@surrey.ac.uk