Re: [Teep] [Rats] Potential attestation attack

Agreed that this is a general problem — “the attestation binding problem”?

Pretty sure there is not *one* general solution.

Seems like nonce can work in some use cases and cnf can work in others. I think there are other solutions too.

One solution I haven’t seen mentioned is binding the attestation to whatever the task at hand is — a financial transaction, a SW update, admission to a network…  Some of these will have idempotency built in, and others will have other cryptographic material similar to cnf built in.

One way to bind to the task at hand is to put data for the task at hand in the attestation itself. For example, you could put the bank account, amount to transfer and a transaction ID in some proprietary EAT claims (or a hash of the data). Another way of binding might have the EAT and the data bound together via a TLS session or a COSE_Sign. FIDO does a variant of this.

I think the solution is highly dependent on the task-at-hand and its system architecture. Some might have the key material (equivalent to cnf) already, some might add cnf and some might choose a different solution. For some there might already be a transaction nonce. Others will bind in application specific ways. Some will have a spot in their protocol where attestation evidence/result can drop right in, others might have to redesign in a big way.

If there’s anything to do here, it is probably to write up a general security consideration. This probably belongs in a RATS Architecture follow-on or such because it is not specific to EAT.

LL

> On Mar 13, 2023, at 9:15 AM, Thomas Fossati <tho.ietf@gmail.com> wrote:
> 
> Hi Dave, all,
> 
> There seems to be two dimensions here:
> 1. RATS as a collection of primitives,
> 2. how to use RATS primitives in other protocols.
> 
> For case 1. I am not sure there's anything special to say. If so, we
> should have done it in the architecture.
> 
> For case 2. we could have a new applicability document to explain the
> caveats of using RATS primitives in application protocols.   In
> particular, documenting the basic binding problem that pops up
> everywhere the attestation and the authentication channel need to be
> composed.  We have discussed this thoroughly in the CCC attestation
> SIG last year when surveying a number of attested secure channel
> protocols, and we could draw from that experience.
> 
> And if we see the solutions are similar enough we could come up with a
> generic mechanism / claim.
> BTW, we are doing that in our attested TLS prototype: and we came up
> with a "binder" claim that we think could easily scale out to other
> channels (e.g., SSH, IPsec, ...).
> 
> Glad to participate in drafting if there's interest.
> 
> cheers, t
> 
> On Mon, Mar 13, 2023 at 1:36 AM Dave Thaler
> <dthaler=40microsoft.com@dmarc.ietf.org> wrote:
>> 
>> 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, CBOR equivalent in https://www.rfc-editor.org/rfc/rfc8747.html.  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)
>> 
>> 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
> 
> 
> 
> -- 
> Thomas
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats