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

[John Kemp <[e-mail]>]

Since I'm still explicitly mentioned on this thread, and I actually have 
interest in this specific example, I'll comment inline below:

El 01/30/25 a las 15:23, Muhammad Usama Sardar escribió:
> Please see some thoughts inline. I think we are in full agreement on the 
> rest.
> 
> On 30.01.25 18:48, Kathleen Moriarty wrote:
>>
>>>               o 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.
>>
>>     I guess you mean anyone could create a social media account on the
>>     name of a specific person and pretend to be that person as it is
>>     not checked/verified (aka identity proofed), right? If yes, I agree.
>>
>>     I should have scoped the discussion to workloads on Confidential
>>     Computing platform [3], my bad. For authentication of workload, it
>>     still needs some form of identity, right?
>>
>> Yes, and you may still want to consider this in your scoping. There 
>> could be organizations who chose to use raw key pairs that are not 
>> tied to an identity proofing process.
> 
> I think this is the counter example you mentioned in your email.
> 
> I am not sure how such organizations would authenticate to a their 
> customers (or third parties)? For example, I am thinking about a cloud 
> service provider (CSP) claiming confidential computing and raw key pairs 
> for their servers, how would they authenticate their servers to me as a 
> cloud customer?

There is a difference between the "workload" and the "servers" (upon 
which, the workload is running).

Thinking of SPIFFE/SPIRE (a common technology for deploying workloads), 
SPIFFE has the concept of a SPIRE agent supplying a workload with its 
"identity" (which can include a key(pair) blessed by the agent). The 
SPIRE agent is part of a SPIRE "trust domain" and knows about particular 
SPIRE servers in that same trust domain. SPIRE servers can "federate" 
with other SPIRE servers.

In this case, I think attestation relates to the SPIRE infrastructure, 
and your CSP would use this, or a similar trust domain federation 
scheme, to do "attestation".

Although workloads MAY (and in fact in SPIFFE/SPIRE _do_) use keys 
provided by their SPIRE agent (IIRC) they might also (and in my opinion 
_should_) also have keys they only have access to themselves (ie. their 
trusted agent can't also impersonate them) and thus workload 
authentication _might_ be independent of platform (CSP resource) 
attestation.

> A hypothetical example: assuming Google as CSP and 
> assuming Google uses raw keys (without any identity proofing process), 
> how can you as Google's customer be sure that your workload is really 
> running on one of Google's machines, and not on a machine controlled by 
> MITM?

Identity proofing for machines and robots is tricky - that's where I 
think "measurements" attested by something trusted due to some 
pre-sharing of keys, and federation of some sort, are important. But I 
believe that we already had the discussion about attestation vs. 
authentication.

I think workload authentication (and workload keys) might be entirely 
separated from attestation related to the platform that the workloads 
are being run on. However, authentication of a workload is also likely 
to include "agent X gave workload A it's identity, and agent X has a key 
blessed by trust domain Y" or some such. These are "relationships" 
rather than "identity" alone.

Regards, - johnk

-- 
Independent Security Architect
t: +1.413.645.4169
e: [e-mail]

https://www.linkedin.com/in/johnk-am9obmsk/
https://github.com/frumioj