Re: [EAT] [Rats] Rats and EAT

[Hannes Tschofenig <[e-mail]>]

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]]
Sent: 11 July 2018 08:01
To: Diego Lopez
Cc: Hannes Tschofenig; Yaron Sheffer; [e-mail]; [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

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]]
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]] 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-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<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
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
_______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
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.