Re: [Rats] Potential attestation attack

IMO, we could map `cnf` to `confirmationMethod` once we have that feature.

On Mon, Mar 13, 2023 at 3:06 AM Orie Steele <orie@transmute.industries>
wrote:

> 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
>