Subject: Re: [Rats] [EAT] Rats and EAT

From: Diego Lopez <[email-masked]>
Date: Sun, 08 Jul 2018 19:46:58 +0000 (GMT)

Hi Hannes,

I was not deeply involved in the work, but NEA seemed to be focused on a particular use case (that of user devices attaching to a network) and not to the more general problem of mutual attestation in more P2P relationships, that I think are the most relevant right now. And it seems to me that at the moment NEA produced its work, user devices were not that much able of performing the procedures defined by the WG...

Anyway, I think there are several of these procedures that are applicable to P2P environments, once adequately adapted.

Be goode,

--
Eih bennek eih blavek!

Dr Diego R. Lopez
[email-masked]
https://es.linkedin.com/in/dr2lopez

On Jul 08, 2018, at 06:54 PM, Hannes Tschofenig <[email-masked]> wrote:

Hi Diego,
 
what do you think are the lessons we can learn from NEA?
It clearly wasn’t as successful as hoped. I am sure there are reasons for that.
 
Ciao
Hannes

From: Diego Lopez [mailto:[email-masked]] 
Sent: 09 July 2018 01:45
To: Hannes Tschofenig
Cc: Yaron Sheffer; Laurence Lundblade; [email-masked]; [email-masked]
Subject: Re: [EAT] [Rats] Rats and EAT
 
And the use of NEA results is mentioned at least in one of the drafts on remote attestation referred in a previous message. Using NEA’s findings is certainly in our aim.
 
Be goode,

--
Likely to be brief and not very
elaborate as sent from my mobile
Diego R. Lopez

On 8 Jul 2018, at 15:39, Hannes Tschofenig <[email-masked]> wrote:

Hi Yaron,
 
Eliot mentioned NEA on the mailing list. It would be interesting to hear what lessons can be learned from NEA.
 
Ciao
Hannes
 
From: EAT [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: 08 July 2018 06:51
To: Laurence Lundblade; [email-masked]; [email-masked]
Subject: Re: [EAT] [Rats] Rats and EAT
 
I'm a bit surprised that nobody's mentioning the work done by the IETF NEA working group. Yes, it's been some time ago, but the people involved were (to the best of my knowledge) involved with the TCG community.
NEA was about desktop machines and NAC rather than mobile devices, but hey, by now we should be looking for solutions that encompass both technologies!
See this diagram on how the complex NEA/TNC architecture fits together, including the TPM.
Thanks,
    Yaron
 
On 06/07/18 22:20, Laurence Lundblade wrote:
Hey EAT and Rats folks, just became aware of IETF attestation work running in parallel. Seems like EAT is focused more on an independent signed, self-secured data structure with a lot of clams. Rats, seems more TPM and full protocol centric, but I’m still reading.
 
Here’s a list of attestation work that Diego and Henk made:
https://datatracker.ietf.org/doc/draft-pastor-i2nsf-nsf-remote-attestation/
https://datatracker.ietf.org/doc/draft-birkholz-i2nsf-tuda/
https://datatracker.ietf.org/doc/draft-mandyam-eat/
https://datatracker.ietf.org/doc/draft-mandyam-tokbind-attest/
https://datatracker.ietf.org/doc/draft-birkholz-reference-ra-interaction-model/
https://datatracker.ietf.org/doc/draft-birkholz-yang-basic-remote-attestation/
https://datatracker.ietf.org/doc/draft-birkholz-attestation-terminology/
 
A couple of other interesting non-TPM “attestation" technologies:
- FIDO does attestation of FIDO authenticators
- Android KeyStore uses the term to mean proving the provenance of a stored key
- IEEE 802.1AR is kind of an attestation too
 
FYI, the IETF attestation events I know of so far are:
 - I’ll present EAT at HotRFC Sunday around 18:00
 - Secdispatch discussion of EAT (and Rats?) Monday at 15:30 (At least I hope; no confirmation yet)
 - EAT BarBof Monday at 18:00
 - Rats BarBof Thursday after dinner
 
I will attend them all :-)
 
LL
 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
EAT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eat
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
EAT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eat

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 10 Jul 2018 16:01:05 -0700

Here’s a little compare-contrast between EAT and NEA. Please correct and forgive incorrect characterizations I might have made about NEA.

EAT uses CBOR and wants to accommodate translation to JSON and compatibility with web infrastructure, NEA used TLV. 

EAT signs and possibly encrypts the claims with COSE so they form a self-secured token that can be transported by any other protocol. NEA defines a back-and-forth protocol and is more of an end-end solution.

EAT orients around key material provisioned to the entity by the manufacturer that is to be used for signing the token. This signing of a nonce by an entity serves to prove the device is not a fake.

EAT wishes to accommodate different signing schemes including privacy-preserving schemes like ECDAA. NEA seems to assume some secured transport (e.g., TLS) will be available.

NEA is oriented around network management, trying to track the security posture of devices in an enterprise's network. EAT is broadly targeted at establishing trust between entities, often consumer devices (phones, refrigerators, cars...) and servers/services (online banking, IoT services, enterprise authentication…).

LL

> On Jul 8, 2018, at 12:46 PM, Diego Lopez <dr2lopez=[email-masked]> wrote:
> 
> Hi Hannes,
> 
>> Cc: Yaron Sheffer; Laurence Lundblade; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> On 8 Jul 2018, at 15:39, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Yaron,
>>  
>> From: EAT [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Yaron Sheffer
>> Sent: 08 July 2018 06:51
>> To: Laurence Lundblade; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> I'm a bit surprised that nobody's mentioning the work done by the IETF NEA working group <https://datatracker.ietf.org/wg/nea/about/>. Yes, it's been some time ago, but the people involved were (to the best of my knowledge) involved with the TCG community.
>> 
>> See this diagram <https://wiki.strongswan.org/projects/1/wiki/trustednetworkconnect> on how the complex NEA/TNC architecture fits together, including the TPM.
>> 
>> Thanks,
>> 
>>     Yaron
>> 
>>  
>> https://datatracker.ietf.org/doc/draft-pastor-i2nsf-nsf-remote-attestation/ <https://datatracker.ietf.org/doc/draft-pastor-i2nsf-nsf-remote-attestation/>
>> https://datatracker.ietf.org/doc/draft-birkholz-i2nsf-tuda/ <https://datatracker.ietf.org/doc/draft-birkholz-i2nsf-tuda/>
>> https://datatracker.ietf.org/doc/draft-mandyam-eat/ <https://datatracker.ietf.org/doc/draft-mandyam-eat/>
>> https://datatracker.ietf.org/doc/draft-mandyam-tokbind-attest/ <https://datatracker.ietf.org/doc/draft-mandyam-tokbind-attest/>
>> https://datatracker.ietf.org/doc/draft-birkholz-reference-ra-interaction-model/ <https://datatracker.ietf.org/doc/draft-birkholz-reference-ra-interaction-model/>
>> https://datatracker.ietf.org/doc/draft-birkholz-yang-basic-remote-attestation/ <https://datatracker.ietf.org/doc/draft-birkholz-yang-basic-remote-attestation/>
>> https://datatracker.ietf.org/doc/draft-birkholz-attestation-terminology/ <https://datatracker.ietf.org/doc/draft-birkholz-attestation-terminology/>
>>  
>> - FIDO <https://www.w3.org/Submission/2015/SUBM-fido-key-attestation-20151120/> does attestation of FIDO authenticators
>> - Android KeyStore <https://developer.android..com/training/articles/security-key-attestation> uses the term to mean proving the provenance of a stored key
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you..
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2018 05:15:53 +0000

Here is what I believe we should / could learn from NEA.

NEA (via the TCG) came up with the idea that devices would communicate their posture to the network when performing network access authentication. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy.

I believe NEA was unsuccessful to accomplish its goal because it was too difficult for enterprise network operators to keep track of software installed on devices and to make a reasonable policy decision.

As such, I think it would be better to communicate information about the device with less granularity.

Ciao
Hannes

From: Laurence Lundblade [mailto:[email-masked]]
Sent: 11 July 2018 08:01
To: Diego Lopez
Cc: Hannes Tschofenig; Yaron Sheffer; [email-masked]; [email-masked]
Subject: Re: [EAT] [Rats] Rats and EAT

LL

On Jul 8, 2018, at 12:46 PM, Diego Lopez <dr2lopez=[email-masked]<mailto:dr2lopez=[email-masked]>> wrote:

Hi Hannes,

Be goode,

--
Eih bennek eih blavek!

Dr Diego R. Lopez
[email-masked]<mailto:[email-masked]>
https://es.linkedin.com/in/dr2lopez

On Jul 08, 2018, at 06:54 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Diego,

Ciao
Hannes

From: Diego Lopez [mailto:[email-masked]]
Sent: 09 July 2018 01:45
To: Hannes Tschofenig
Cc: Yaron Sheffer; Laurence Lundblade; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [EAT] [Rats] Rats and EAT

Be goode,

On 8 Jul 2018, at 15:39, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yaron,

Ciao
Hannes

From: EAT [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: 08 July 2018 06:51
To: Laurence Lundblade; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [EAT] [Rats] Rats and EAT

I'm a bit surprised that nobody's mentioning the work done by the IETF NEA working group<https://datatracker.ietf.org/wg/nea/about/>. Yes, it's been some time ago, but the people involved were (to the best of my knowledge) involved with the TCG community.
NEA was about desktop machines and NAC rather than mobile devices, but hey, by now we should be looking for solutions that encompass both technologies!
See this diagram<https://wiki.strongswan.org/projects/1/wiki/trustednetworkconnect> on how the complex NEA/TNC architecture fits together, including the TPM.
Thanks,
    Yaron

A couple of other interesting non-TPM “attestation" technologies:
- FIDO<https://www.w3.org/Submission/2015/SUBM-fido-key-attestation-20151120/> does attestation of FIDO authenticators
- Android KeyStore<https://developer.android..com/training/articles/security-key-attestation> uses the term to mean proving the provenance of a stored key
- IEEE 802.1AR is kind of an attestation too

LL

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
EAT mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eat
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you..
_______________________________________________
EAT mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eat
_______________________________________________
EAT mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eat

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 11 Jul 2018 09:42:19 -0700

Would it be correct to say that NEA was mostly about enterprises (businesses, colleges…) that manage the endpoint devices and SW on those devices on their network?  It is entirely impractical for ISPs and wireless operators to manage SW on endpoint devices, so it seems it would have to be only enterprises.

LL

> On Jul 10, 2018, at 10:15 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> From: Laurence Lundblade [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: 11 July 2018 08:01
> To: Diego Lopez
> Cc: Hannes Tschofenig; Yaron Sheffer; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Jul 8, 2018, at 12:46 PM, Diego Lopez <dr2lopez=[email-masked] <mailto:dr2lopez=[email-masked]>> wrote:
>  
> Hi Hannes,
>  
> [email-masked] <mailto:[email-masked]>
> https://es.linkedin.com/in/dr2lopez <https://es.linkedin.com/in/dr2lopez>
> 
> On Jul 08, 2018, at 06:54 PM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Diego,
>  
> From: Diego Lopez [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: 09 July 2018 01:45
> To: Hannes Tschofenig

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 11 Jul 2018 18:34:25 +0000

I’d say this is an accurate analysis.

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 11/07/2018, 18:42, "EAT on behalf of Laurence Lundblade" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

LL

On Jul 10, 2018, at 10:15 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Ciao
Hannes

From: Laurence Lundblade [mailto:[email-masked]]
Sent: 11 July 2018 08:01
To: Diego Lopez
Cc: Hannes Tschofenig; Yaron Sheffer; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [EAT] [Rats] Rats and EAT

LL

Hi Hannes,

Be goode,

--
Eih bennek eih blavek!

Dr Diego R. Lopez

Ciao
Hannes

Be goode,

Ciao
Hannes

LL

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Jul 2018 20:46:13 -0400

Laurence Lundblade <[email-masked]> wrote:
    > NEA is oriented around network management, trying to track the security
    > posture of devices in an enterprise's network. EAT is broadly targeted
    > at establishing trust between entities, often consumer devices (phones,
    > refrigerators, cars...) and servers/services (online banking, IoT
    > services, enterprise authentication…).

That's a surprising claim that EAT is going to broker trust between my phone
and my refrigerator.    Will it do this via third parties, or directly?

Please tell me more about this aspect.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Jul 2018 20:50:28 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > I believe NEA was unsuccessful to accomplish its goal because it was
    > too difficult for enterprise network operators to keep track of
    > software installed on devices and to make a reasonable policy decision.

    > the device with less granularity.

Are you saying that NEA failed because it communicated too many details, and
operator couldn't tell if the detail mattered?

I think that there were other significant issues, such as lack of reliable
support for the (wired) 1x process that NEA depends upon in bargain basement
switching infrastructure,  and that the backend systems were immature, and
too expensive for the target customers.   I.e, the backend systems needed to
be field trialed in medium sized enterprises before large enterprises would
trust them, but medium sized enterprises couldn't afford to do this.

And then BYOD and Linux and MacOS desktops wouldn't speak the right protocols
out of the box.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 12 Jul 2018 09:20:32 -0700

> and my refrigerator.    Will it do this via third parties, or directly?

This is not any direct goal of EAT. Let me say it better:

EAT is broadly targeted at providing some basis for establishing trust in scenarios like this:
 - An online banking website trusting the phone and app used to show account balance
 - A Fortune 500 corp trusting the phone and web browser to allow access to corp data
 - An IoT backend trusting some refrigerators that it is to provide service to (e.g. shopping, milk expiration…)

Maybe someday EAT will be part of a phone-fridge trust solution, but one step at a time.

LL

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 15 Jul 2018 15:50:20 +0300

> Maybe someday EAT will be part of a phone-fridge trust solution, but one step at a time.
I don't see how in this day and age we can consider a solution that 
covers IOT and phones but not other devices that run an operating 
system, such as laptops and servers.

So maybe NEA was too complex or ambitious, and we should scale these 
ambitions down. But desktops and servers, both physical and virtual, 
should be in scope.

Thanks,
     Yaron

---

From: Henk Birkholz <[email-masked]>
Date: Sun, 15 Jul 2018 17:13:51 -0400

Hi all,

sometimes - and this might be a purely subjective perception - the fact 
that "concise" or IoT target solutions "seem" to violate a very curious 
requirement poses - please mind - a somehow surprising strong "impact":

The encoding data in motion is not (directly) human readable.

Wrt to Yaron's comment: this assumption should not be a valid reason for 
not to apply concise & scalable technologies in other scopes (aka bigger 
things) than constrained-nodes environments.

Maybe there are very valid reasons not to apply IoT solutions to "bigger 
things" domains - and that would be very important to understand better 
- but taking into account the t2t philosophy, I am hopeful that there is 
no actual reason not to aspire to that.

Viele Grüße,

Henk

On 07/15/2018 08:50 AM, Yaron Sheffer wrote:
>>   - An IoT backend trusting some refrigerators that it is to provide 
>> service to (e.g. shopping, milk expiration…)
>>