Re: [Teep] [Rats] Potential attestation attack

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