[Rats] Re: Security considerations of remote attestation (RFC9334)

[Kathleen Moriarty <[e-mail]>]

Usama.

Thank you for outlining your goals for the workshop. I'll insert some
questions and comments that I believe should be helpful.

On Thu, Jan 30, 2025 at 6:43 AM Muhammad Usama Sardar <
[e-mail]> wrote:

> Thank you Ned for sharing your perspective. My point is simply that we
> should not make such hand-wavey statements that we know are wrong. As
> Kathleen rightly pointed out, such statements are often more problematic
> than helpful. Regarding the statements falling apart, I thought I have
> already demonstrated that via three keys to which at least Laurence agreed
> [1] and there was no disagreement yet on the list. Do you disagree? If so,
> please explain why?
>
> A useful result of the discussion so far has been:
>
>    - We need to disambiguate Attestation and Authentication. One does not
>    necessarily imply the other and we can have one without the other (even if
>    people believe they have designed a protocol to achieve both). One needs to
>    specify which of the three keys [2] are used by a specific attested TLS
>    solution.
>    - Authentication has something to do with *long-term identity.*
>
> Ah, this is not true. Identity may or may not be tied to authentication.
If you read through NIST SP 800-63, there is a clear delineation for levels
of authentication. The basic level is only that the same credentials are
used and that can be verified. There are numerous use cases, such as social
media accounts, where there is no identity proofing required. This could be
narrowed to an authentication level or the levels where identity proofing
is tied to the issuance of credentials.


>
>    - Attestation has something to do with *measurements*. The use of
>       Attestation without qualifying it with what *exactly* is measured
>       does not make any sense to me, e.g., I mentioned about MITM when Kernel, OS
>       and App are not measured.
>
> I'd say it's more the capture and assurance that evidence was captured and
signed through a process where you know that evidence was happening on that
system. You are working to guarantee that there was no MITM when taking
those measurements to have an assurance, hence the use of immutable
hardware and the TEE.


>
>
> Apart from above, there are open questions (in no particular order and in
> the context of Confidential Computing threat model [3]) that we plan to
> discuss in Brussels tomorrow and we will bring back the results to the WG:
>
>    - What is the "long-term identity" of VM-based TEE? Who provisions
>    (and signs) this "long-term identity"? If it is still the CSP, it trivially
>    breaks the claimed Confidential Computing threat model. If it is some other
>    entity, how is that entity trusted?
>       - Somewhat related: Who is the "owner" of VM-based TEE? How that
>       "ownership" is determined?
>
> Isn't this key derived from the immutable one on the hardware RoT (e.g.
TPM)?  Because of this, you can regenerate keys as needed without taxing
the TPM above its capacity.

>
>    -
>    - What does "freshness" mean for long-lived workloads?
>    - In what ways is the distinction between "freshness" and "recentness"
>    helpful for protocol analysis?
>    - How to provide both Attestation and Authentication in TLS?
>
> Let's keep these separate, please. In the case of a CDN, we may be
authenticating the business and use of the customer's domain through X.509
certificates and trusted key pairs. The identity proofing process varies
for different levels of certificates and minimally looks at things like the
tax identification number and sometimes has strict re-authentication of the
roles who handle the updates for certificates and associated key pairs.
For attestation, we are relying on hardware certificates and keys that were
burned in at a factory to a root of the hardware vendor. These are distinct
trust chains that are in no way related.
If we provide both, they each need to be associated with a validation of
their individual trust chains to assure at the level the system and process
was developed.


>    - What security does Attester-generated nonce in one-way (vs. mutual)
>    Attestation for single-layered Attester provide? (referring back to the EAT
>    discussion)
>
> Maybe Laurence could chime in here? I assume you are referring to each
entity attesting their environment to each other, is that correct?


>    - I believe keys for Authentication and Attestation should be
>    separate, and using same keys for both does not add anything to security
>    [4]. I would like to see a practical counter-example.
>
> I think this would tie into the lowest level of authentication where you
don't have identity proofing as required. See the above statements on the
chain of trust.

>
>    -
>    - Should we include key protection level in the formal analysis of
>    attested TLS?
>
> YES! This will help with the level of trustworthiness and will vary based
on the properties of the key protection for attestation (hardware and
immutable, virtual with protection and refresh processes, etc.).

>
>    - Is there something important missing in the security goals? [5]
>
> For all, please feel free to provide insights -- if you have any -- to any
> of those.
>
Thank you for this very nice and helpful outline. I'd love to see focus on
this to help you with the workshop and research goals.

Best regards,
Kathleen

>
> Thanks,
>
> Usama
>
> [1]
> https://mailarchive.ietf.org/arch/msg/rats/tyX4nkJqk4fYWBUfmRqfELI3nFw/
>
> [2]
> https://mailarchive.ietf.org/arch/msg/rats/6K2kZVCh6TPZHSz_VGxwseh6Dec/
>
> [3]
> https://www.ietf.org/archive/id/draft-fossati-tls-attestation-08.html#section-9.1
>
> [4]
> https://muhammad-usama-sardar.github.io/rats-unprotected-evidence/draft-usama-rats-unprotected-evidence.html
>
> [5]
> https://mailarchive.ietf.org/arch/msg/rats/qm5CYRM4bNZ_HbrHLAebKZxWGII/
>
>
> On 29.01.25 22:14, Smith, Ned wrote:
>
> > I am pretty sure that nobody intended to start an axiomatic proof
>
> I think this is true.
>
>
>
> I think Usama is trying to map the various hand-wavey statements (that
> weren’t trying to be expressed in a way that makes sense for formal
> methods) into something that is meaningful to formal methods. But maybe
> Usama / others who are familiar with formal methods could show their work
> so to speak and explain where the various statements fall apart, but more
> importantly, what would a statement look like that is useful?
>
>
>
> -Ned
>
>
>
>

-- 

Best regards,
Kathleen