- From: Orie Steele <orie@transmute.industries>
- Date: Sun, 12 Mar 2023 21:05:18 -0500
- To: W3C VC Working Group <public-vc-wg@w3.org>
- Message-ID: <CAN8C-_LKPaH7i3NNVencS38VDfCDrnKHwusnG+kf4TqLGURdRg@mail.gmail.com>
cnf identified as a solution for "holder binding". I am eager to add some similar examples to vc-jwt. I feel there is a lot of overlap with RATs that is worth citing more directly, in our work. ---------- Forwarded message --------- From: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org> Date: Sun, Mar 12, 2023, 8:37 PM Subject: Re: [Rats] Potential attestation attack To: Giridhar Mandyam <mandyam@qti.qualcomm.com>, rats@ietf.org < rats@ietf.org> Cc: TEEP@ietf.org <teep@ietf.org> I agree, the cnf claim in RFC8747 looks like what we want in EAT. I will reference it in the EAT profile for TEEP, though I still think it might be helpful to mention in Security Considerations of EAT. Thanks Giri! Dave *From:* Giridhar Mandyam <mandyam@qti.qualcomm.com> *Sent:* Sunday, March 12, 2023 5:27 PM *To:* Dave Thaler <dthaler@microsoft.com>; rats@ietf.org *Cc:* TEEP@ietf.org *Subject:* RE: Potential attestation attack Hi Dave, The cnf claim seems to fit the purpose for what you are proposing: see https://www.rfc-editor.org/rfc/rfc7800.html#section-3.1 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7800.html%23section-3.1&data=05%7C01%7Cdthaler%40microsoft.com%7Cafd73bd8b5bb4265c68d08db2359b96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638142640528548890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dPguH1LU9EsYSZVc3AtQbPwVYw8UYHC2oVU2zTF6730%3D&reserved=0>, CBOR equivalent in https://www.rfc-editor.org/rfc/rfc8747.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8747.html&data=05%7C01%7Cdthaler%40microsoft.com%7Cafd73bd8b5bb4265c68d08db2359b96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638142640528548890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gajBIdJo5tMkOedmFtuNPOCrrKWZYZoDmpzVUraxjok%3D&reserved=0>. For the latter (CWT), there is a suggestion to send the hash of the PK in the cnf field as a kid (sec. 3.4). If this is not suitable, then I would like to know why. -Giri *From:* RATS <rats-bounces@ietf.org> *On Behalf Of *Dave Thaler *Sent:* Sunday, March 12, 2023 4:24 PM *To:* rats@ietf.org *Cc:* TEEP@ietf.org *Subject:* [Rats] Potential attestation attack In a TEEP github issue ( https://github.com/ietf-teep/teep-protocol/issues/310 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F310&data=05%7C01%7Cdthaler%40microsoft.com%7Cafd73bd8b5bb4265c68d08db2359b96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638142640528548890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YSutbHQa9ftrnKHwkeql4HPE19u41oUF1MENO9TWZzc%3D&reserved=0> ) Kohei Isobe poised an impersonation attack scenario that I will summarize as follows, which is not specific to TEEP: Consider an attestation solution using the Passport model. The victim does remote attestation normally, and presents the Attestation Results (e.g., in EAT format) to various Relying Parties. The attacker gets a copy of said Attestation Results, e.g., from one of said Relying Parties (and it may even be one of them). The attacker then presents the Attestation Results to other Relying Parties as if the Attestation Results were its own, when doing its own remote attestation, in order to trick Relying Parties into believing it is trustworthy. To prevent such an impersonation attack, I believe that what is needed is a way to cryptographically bind the Attestation Results to a key only the attester knows and not some attacker trying to impersonate it. So in the above attack, if (say) the Attestation Results contained a hash of a public key of the victim, and the protocol between the attacker and another Relying Party required a message to be signed with the corresponding private key, then that Relying Party would know the Attestation Results didn’t match and could reject the request. I believe the same attack could be mounted in a Background Check model, using Evidence instead of Attestation Results. I could not, however, find any claims in draft-ietf-rats-eat or draft-ietf-rats-ar4si that could be used to provide such a cryptographic binding to an EAT, nor could I find any mention of this threat in the Security Considerations section of either document. Since this class of attack would seem to be generic, possibly applying to all EAT profiles and protocols using RATS, one could argue that a discussion (at least of the Security Consideration) would be appropriate in the EAT document even if a solution is left to a separate document. Anyone else already have a solution or do we need to quickly write up a draft that adds another claim for EAT profiles (including TEEP) to use? Dave _______________________________________________ RATS mailing list RATS@ietf.org https://www.ietf.org/mailman/listinfo/rats
Received on Monday, 13 March 2023 02:05:43 UTC