Re: [EAT] Scope, Goals & Background for RATS

[Henk Birkholz <[e-mail]>]

Hello Laurence,

please find replies and comments in-line:

On 09/20/2018 10:18 PM, Laurence Lundblade wrote:
> It’s a bit buried, but I see you do intend that this include the EAT 
> work. Thus the work would not be TPM/TCG centric. It would include use 
> cases like FIDO and Android Keystore attestation that are often based on 
> TrustZone. It could also include EPID-related use cases. Please confirm.

I am not sure, if I am the authority to confirm this, as kickstarting 
RATS is a group effort. What I can do is to agree with the statement 
that RATS is abstracting from specific hardware solutions that provide, 
for example trust anchors and shielded locations (which keystores are a 
subset of, I think), or restrict secret key access (protection of 
execution, I think) based on system status (or more generic - system 
health).

Conveyance of Attestation Claims is a big part of implicit attestation 
and the comparison of (amongst other information) claims wrt to 
appraisal of Attestation Evidence in explicit attestation. As EAT 
provides a data format to express these claim sets in a state-of-the art 
representation (and, if signed, via a state-of-the-art COSE envelope) 
they are compose a perfect option to address the data model part of 
conveyance.

> 
> My preference would be to choose another name for the group that is 
> neither EAT or RATS to help make this clear. I don’t really think there 
> is a “procedure” with EAT. To be honest, I don’t really like “RATS” as a 
> name. My suggestions are “RA” for Remote Attestation or “CAT” for Common 
> Attestation Technology (and besides cats caused us to invent the 
> Internet so we share pictures of them (securely)).
> 
> I propose a more high-level intro with examples:
> 
>     The purpose of RA/CAT is to allow a Relying Party (e.g. a web
>     service, network management center...) to securely receive Claims
>     from an Entity requesting service (e.g. a phone, router, IoT
>     device...) that allow the Relying Party to determine if and how that
>     entity is trusted.  For example:
> 
>       o An IoT management back-end receives a signed nonce that proves
>         the IoT device is the genuine article manufactured by the
>         expected OEM and is not a Linux box or such emulating such a device.
>       o A network management center receives a set of measurement claims
>         from a router to know that the configuration has not been
>         tampered with.
>       o An online banking service receives many claims about the device
>         including location, SW versions and measurements and determines
>         that it will allow a higher-than-usual value transaction.
>       o A government online document server receives claims indicating
>         manufacture and location of the device, determines they are from
>         the correct country and grants access to classified documents.
> 
>     There are protocols for determining and securing the identity of a
>     server or service (TLS and IPsec). There are many protocols for
>     authenticating end users (SASL, TLS client auth, EAP…). There are no
>     general protocols for managing the characteristics, security and
>     identity of an end client device (an Entity). RA/CAT aims to address
>     that gap.
> 
>     There is no goal here to set criteria for what is trustworthy or not
>     as that is an impossible task as it will vary widely from use case
>     to use case. The goal here is to securely provide information
>     (Claims) to the Relying Party so it can make that determination
>     based on its own criteria and needs.

RATS addresses a vital domain that I feel is missing here: critical 
infrastructure or safety critical systems.

Examples given: voting machines, rail-road object controllers, air plane 
cabin and avionic control systems & corresponding airports, cell-phone 
towers, or domains with high levels of confidentiality, in general.

Of course, there is the high demand to convey information to assess a 
system's trustworthiness in a trusted and resilient way coming from 
network equipment (or network function services) vendors. But managing 
the integrity (and actual composition) of a large number of end-user 
devices is also a requirement with continuously growing importances - 
not only for governments, but also for enterprises.

The scope of numbers of devices expanding due to encompassing 
constrained-node environments will render RATS a very interesting effort 
(that is why "offloading the burden of appraisal" and differentiating 
the roles of Verifier, Relying Party & "measured system (component)" is 
so vital, I think).

> 
> 
> 
> I don’t think the intro should mention public key crypto. I know of 
> attestation solutions that do not use it.
> 

This is a good point, we added proof-of-possession to enable readers to 
better intuitively grasp the context in the IETF. Could you reference 
some of the solutions? I think that would help address that comment.


> I tend to prefer “attestation” when the goal is whether and how a device 
> is to be trusted and “authentication” when the goal is how a human is to 
> be identified. FIDO, OAuth, SASL are all about users and use the word 
> authentication.

Yes - I think we are in agreement here. I am not sure if we can skip the 
term entirely, but the focus is on more than "stronger authentication".

> 
> LL
> 

Viele Grüße,

Henk

> 
>> On Sep 18, 2018, at 1:26 AM, Henk Birkholz 
>> <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi all,
>>
>> we pushed an initial document to the RATS github in order to focus the 
>> discussion about remote attestation procedures a bit.
>>
>>> https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md
>>
>> We included a background section to better highlight the meaning of 
>> the term "attestation" in general. Hence, there is a trade-off between 
>> clarity and conciseness, which is one of the things we would like to 
>> get feedback about.
>>
>> Naturally, we are also very interested in feedback about the 
>> illustrated difference between explicit attestation and implicit 
>> attestation.
>>
>> Viele Grüße,
>>
>> Henk
>>
>>
>>
>>
>>
>> _______________________________________________
>> EAT mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/eat
>