Fwd: [Rats] Potential attestation attack

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