Re: [Rats] IETF 102 Remote Attestation Procedures (RATS) Bar BoF Invite

[Hannes Tschofenig <[e-mail]>]

Hi Henk,

I fear you missed that Lawrence and I already reserved a room for a meeting about the attestation work we proposed. Here is the mail:
https://www.ietf.org/mail-archive/web/eat/current/msg00005.html

Ciao
Hannes


-----Original Message-----
From: Henk Birkholz [mailto:[e-mail]]
Sent: 05 July 2018 23:52
To: DIEGO LOPEZ GARCIA; Xialiang (Frank); Hannes Tschofenig; Jessica Fitzgerald-McKay; Dave Waltermire; Banghart, Stephen A. (Fed); Shwetha Bhandari (shwethab); Bill Sulzen (bsulzen); Eric Voit (evoit); Giridhar Mandyam; Laurence Lundblade; ANTONIO AGUSTIN PASTOR PERALES; Mr. Ned Smith
Cc: Laffey, Tom (HPE Networking ATG); Guy Fedorkow; 'Wiseman, Monty (GE Global Research, US)'; Nancy Cam-Winget (ncamwing); Michael Eckel; [e-mail]
Subject: IETF 102 Remote Attestation Procedures (RATS) Bar BoF Invite

Hi *,

Diego and I are planning to find (or create) an appropriate place for
remote attestation related work in the IETF with a Bar BoF as a first step.


Some context:

In essence, remote attestation procedures are a tool-set that is
intended to increase the confidence that an entity other entities
interact with is a trusted system.

Remote attestation typically is tied to a type of trust anchor or
shielded secret, which is - in a sense - a tad bit exotic in the scope
of protocols developed in the IETF as those exist and operate "inside
the box". In contrast, most IETF solutions operate "between boxes".
While remote attestation procedures require both parts in order to
provide a value, appropriate network protocols to convey corresponding
information between boxes are still very much work in progress.


The Plan:

To create appropriate protocols and architectures, unfortunately, is not
a trivial task. In order to find out how this "non-trivial" thing can be
talked about and how to do that constructively in the IETF, we would
like to invite you to a Bar BoF.

The minimum goal is to talk about what remote attestation means
(semantic), what parts of it would belong in the IETF (scope), how to
align existing work and how to provide a basis for future work
(solution). Even better, if we would be able to agree in some of these
areas and flock together.

As a first proposal, we are planning the Bar BoF for:

*Thursday July 17th, in the evening*
(exact time TBD, but we think at or after dinner)

There is a fine Bar at the Venue. So, the current plan is to meet there,
in order to make it easier to attend. But we will also scout for an
appropriate bar when we are on-site. Also, we would like to encourage
you to "bring a +1" in case you know other individuals, who would be
interested in this topic.


Some references of the work in this space that is scattered all over the
IETF:

> 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/

There also is the [e-mail] list (as you can see in the email
header) and a place at github (https://github.com/ietf-rats).


All that said, we would welcome you to drop by and are looking forward
to a lively discussion.


Best regards,

Diego & Henk
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.