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

[John Kemp <[e-mail]>]

Hi Henk,

El 01/31/25 a las 11:10, Henk Birkholz escribió:
> Hi Kathleen,
> Hi John,
> 
> I am not entirely sure how the previous messages relate to "the Thaler 
> Conjecture" exactly,

I said directly in my initial response:

>>>> I guess, in specific response to this discussion that:
>>>>
>>>> i) I don't know if it matters whether every attestation use-case is 
>>>> an authentication use-case.
>>>> ...

BUT:

>>>> ii) However, it _does_ matter how we define these terms, and the 
>>>> relationships between them, as regards the RATS entities/roles

(whether we take or adapt NIST definitions, or define them specifically 
for RATS entities)

We do still need a better answer for Usama's original questions around 
the distinctions as they apply to RATS, I think.

More inline below...

> but please find some comments below, inline.
> 
> 
> Viele Grüße,
> 
> Henk
> 
> On 30.01.25 23:12, Kathleen Moriarty wrote:
>>
>> Sent from my mobile device
>>
>>> On Jan 30, 2025, at 4:52 PM, John Kemp <[e-mail]> 
>>> wrote:
>>>
>>> El 01/30/25 a las 16:03, Dave Thaler escribió:
>>>> The logic behind the conjecture is the belief that
>>>> authentication without attestation is weak (i.e., how do you know 
>>>> it's not an adversary,
>>>> like malware on the same device, claiming to be the identity being 
>>>> authenticated?)
>>>> compared to authentication with attestation which provides a 
>>>> stronger level of assurance
>>>> of actual identity.
>>>
>>> At the lowest level, authentication is _only_ the ability for an 
>>> entity to prove that it possesses something _assumed_ to be 
>>> "secret" ("three can keep a secret if two of them are dead").
>>>
>>> It is assumed to be secret because (for example):
>>>
>>> a) it is derived from a cryptographically-secure random number and 
>>> thus cannot be guessed,
>>> b) it is not shared with anything other than the entity claiming 
>>> possession
>>> c) it is used in a cryptographic protocol in such a way as to not 
>>> reveal the secret
>>>
>>> These assumptions, rather more often than we would like, do not hold.
>>>
>>> "identity" is a set of attributes regarding an entity that may be 
>>> claimed by the entity.
> 
> That would be a self-asserted identity, right?

Yes.

> 
>>>
>>> "attestation" is a set of relationships of the form "is-known-by".
> 
> I assume that could be one of the definitions of attestation out there. 
> Do you imply that's the RATS WG use of the bare word "attestation"?

I'm not implying that, no. It's more by way of teasing out the actual 
differences between attestation and authentication.

> The closest that NIST defines "attestation" as used in the RATS comes from 
> NIST SP 1800-19B: "The process of providing a digital signature for a 
> set of measurements securely stored in hardware, and then having the 
> requester validate the signature and the set of measurements." where the 
> securely stored in hardware sometimes leads to discussions, I think.

The "measurements" are signed with a key, and without any other context 
would be equivalent to a self-signed claim of some attributes related to 
the claimant. However, because they're signed with a key that has been 
blessed by (for example) the provider of the hardware (via AK/EK or 
similar), we are saying with the attestation:

1. The measurements represent my best knowledge of the state that I am 
running in.
2. I (my key) is "known by" ("vouched for"?) this other entity.
3. The measurements can be trusted by the entity vouching for me because 
they know "how I've been securely built and are willing to take a risk 
on me" (roughly-speaking ;)

1. is authenticating the device making the measurement claims
2. is providing "trusted", relational context around that authentication 
(I vouch for the key that signed these measurements) and also the 
measurements themselves will provide additional context (e.g. hash of 
firmware) that can theoretically (depending on some variables) make me 
more trustworthy to the recipient.

> 
>>>
>>> So one might imagine an entity claiming a set of identity attributes, 
>>> authenticating itself by holder-of-key signature of something, and 
>>> "attesting" these attributes by signing _those_ possibly 
>>> authenticating and attesting (itself) at the same time.
>>>
>>> Attestation is often used to _avoid_ doing actual entity 
>>> authentication (since key management is hard at scale).
>>>
>>> I guess, in specific response to this discussion that:
>>>
>>> i) I don't know if it matters whether every attestation use-case is 
>>> an authentication use-case.
>>> ii) However, it _does_ matter how we define these terms, and the 
>>> relationships between them, as regards the RATS entities/roles
>>
>> I’m in agreement with John. I used higher level terminology to the 
>> same point and NIST SP 800-63 series is the key source for reference.
> 
> NIST SP 800-63-3 is one of many NIST documents that include a glossary 
> definition of "authentication", I think.
> 
> There are others: https://csrc.nist.gov/glossary/term/authentication
> 
> NIST SP 800-63-3's definition is: "Verifying the identity of a user, 
> process, or device, often as a prerequisite to allowing access to a
> system’s resources."
> 
> I am absolutely okay with that definition of authentication. I'd just 
> like to point out that NIST alone provides more than 20 additional 
> definitions.

Yes, this is a problem I've seen with relying on NIST (or other) 
definitions before. So clearly, we always need definition n+1 and one 
can never have enough standards, right? ;)

- johnk

> And for comparison, RFC4949 has: "The process of verifying 
> a claim that a system entity or system resource has a certain attribute 
> value."
> 
> The special publication series 800-63 does not cover topics related to 
> "attestation", I think.
> 
>>
>> Thank you, John.
>>
>> Kathleen
>>
>>>
>>> Regards,
>>>
>>> - johnk
>>>
>>> -- 
>>> John Kemp
>>> Independent Security Architect
>>> t: +1.413.645.4169
>>> e: [e-mail]
>>>
>>> https://www.linkedin.com/in/johnk-am9obmsk/
>>> https://github.com/frumioj
>>>
>>
>> _______________________________________________
>> RATS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]

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

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