Re: [EAT] [Rats] Rats and EAT

[Laurence Lundblade <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:[e-mail] <mailto:[e-mail]>] 
> Sent: 11 July 2018 08:01
> To: Diego Lopez
> Cc: Hannes Tschofenig; Yaron Sheffer; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [EAT] [Rats] Rats and EAT
>  
> 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=[e-mail] <mailto:dr2lopez=[e-mail]>> wrote:
>  
> 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
> [e-mail] <mailto:[e-mail]>
> https://es.linkedin.com/in/dr2lopez <https://es.linkedin.com/in/dr2lopez>
> 
> On Jul 08, 2018, at 06:54 PM, Hannes Tschofenig <[e-mail] <mailto:[e-mail]>> 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:[e-mail] <mailto:[e-mail]>] 
> Sent: 09 July 2018 01:45
> To: Hannes Tschofenig
> Cc: Yaron Sheffer; Laurence Lundblade; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 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 <[e-mail] <mailto:[e-mail]>> 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:[e-mail] <mailto:[e-mail]>] On Behalf Of Yaron Sheffer
> Sent: 08 July 2018 06:51
> To: Laurence Lundblade; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 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
>  
> 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-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/>
>  
> 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
>  
> 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
> [e-mail] <mailto:[e-mail]>
> 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..
> _______________________________________________
> EAT mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>
> _______________________________________________
> EAT mailing list
> [e-mail] <mailto:[e-mail]>
> 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.