Minutes IETF103: rats
minutes-103-rats-00

Remote ATtestation ProcedureS (RATS) BoF Minutes
IETF 103

Tuesday, November 6, 2018, 13:50-15:50
Afternoon session I, Chitlada 2

Video of session: https://www.youtube.com/watch?v=SrJCVq7zx6M

1) Introduction, Logistics and Agenda Bash
==========================================
presenters: Nancy Cam-Winget and Roman Danyliw
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-chairs-summary-04
candidate charter:
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-draft-charter-00

The chairs presented the ground-rules for the BoF agenda -- required scoping
questions; and the two open mic discussion times per agenda item #4 and 6.

2) Problem Statement
====================
presenters: Henk Birkholz and Ned Smith
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-rats-problem-statement-02

Birkholz and Smith, as the proponents, present the motivating problem statement
for the RATS BoF based on a bar-Bof at IETF 102 and mailing list discussion.

Clarifying questions:
None

3) Relevant Work
================
3.1) Compromise Trustworthy Visibility in Working Systems
---------------------------------------------------------
presenter: Eric Voit
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-compromise-trustworthy-visibility-in-working-systems-00

Eric Voit presented on remote attestation on routers and switches.

Clarifying questions:

Per slide #4:
Frank Xia: Are your proposed transporting all of this configuration information
or just a hash of it?  Are you proposing tacking this information? (defer till
open mic)

Q: Eric : Is there any gray areas, which means you may have sort of different
severity for your router or switch? A: Eric Voit: yes, there might be a change,
and there is a a need to determine if this is ok.

Q: Alissa Cooper: can you clarify your need for interoperability requirements
for the router and switch? A: Eric Voit: Deployed boxes want to manage
routers/switches.  Therefore, knowing how to attest it is interesting.  I do
see that there are different kinds of information that are useful for the
management applications to check the system's health. So the list of possible
information errs on the side of a longer list for future use. A: Henk Birkholz:
 If you start with remote attestation and then the evidence tells you things
have changed, then the concern is higher (the device was healthy before but is
not healthy later in the timeline) A: Shwetha: To response to Alissa's question
about the interoperability requirement, yes we do need this interoperability
solution since the attester and the verifier can come from different companies.

3.2) Oauth and IoT
------------------
presenter: Hannes Tschofenig
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-oauth-and-iot-01

Tschofenig presented two use cases: Oauth with delegated authorization for
high-value transactions; and in IoT.

Clarifying questions:
None

4) Problem Statement Discussion
===============================
Live Summary:
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-live-summary-of-feedback-from-the-mic-during-discussion-1-00

With the problem statement described by the proponents, the BoF had its first
open mic session.  Below are all of the individual comments made on the problem
statement at the mic.  The chairs captured and organized this feedback during
the meeting and presented it back to the BoF after this open mic time
concluded.  See the "Live Summary" materials referenced above.

Frank Xia: Two concerns; (1) - a lot of use cases (IoT, network device, NFV),
can we produce a single protocol for them? I hope so! (2) Need backward
compatibility is very important for vendors and operators.

Dave Thaler: I had difficulty understanding the presented attestation model. 
My understanding is that we have at least 3 entities in remote attestation:
device whose health you want to determine; relying party that wants to know
that health; and attestation server that supplies something to the device that
can be given to the relying party.  More complicated instances might exist
where there are multiple instances of these or they are chained together. This
suggests there are at least two protocols: how does a device get what it needs
to supply to the relying party; and the communication between the device and
relying party.  Alyssa was asking about whether we need interop between the
device and manufacturer (protocol 1).  I think we need both.  I'd like
protocols that exchange a variety of token types (e.g., X.509 certificates,
JWTs).

In summary, we need to standardize a protocol for the communication between a
device and an attestation server; and the format for a token (probably in
multiple formats).

Eliot Lear: I see two questions: state change (from a known state to another),
state itself (what does it consist of). We may not solve both problems in a
single approach. Is it one question or two?  Concur with Dave that this
information will be transported in different ways.  This problem has some
similarity with IoT on-boarding problem. We can consider them all from a more
broad way,

Tony: I care about privacy issues and the possibility of correlation of these
attestations. Likewise, it is important to separate the protocols from the
formats.  Ensuring crypto-agility is also important.

Eric Nordmark: There are several problems.  Root of Trust (ROT) does not have
to be the manufacturer.  There are multiple approaches for implementing the
ROT.  We may need to address this early on -- don't limit to a specific
approach for ROT too early. ROT could be the manufacturer or owner.  We should
not assume a hardware root of trust.  With ROT, there are various degrees of
'tamper-proof-ness'. Privacy is another important problem.  The idea that a
device would disclosure all assertions to everyone with whom it talks is not
good practice.  What would be the policies for such an approach?

Massimiliano Pala: I agree that privacy is important, and we need some control
mechanism for who can access what assertions. This might require additional
thinking on authorization.  Trust anchors is another problem we should
consider. There are a lot of work remote attestation can do and existing
related work.  In particular, there is prior work in local attestation.  We
need to be specific on what we are trying to attest.  I suggest we start from a
simple and basic one, and then extend it.

Bret Jordan: I'm excited about this work.  I see it being used in many spaces.
For examples, it's useful for Course of Action playbooks and in Google's
beyondcorp solution.

Henk Birkholz: The assertion semantics will always have privacy considerations
which may vary across domains.  Yes, there are a lot of existing protocol work.
 We can't solve everything at once.  To Elliot's point of state vs. chance in
state and how to check evidence, this will be in the charter.

Leif Johansson: there is a similar work in IETF -- secevent. The architecture
is the same -- except subjects are devices.  Other working groups have
discussed what gets put into a claim/assertion.  They have agreed on timestamp.
 What would be most valuable is to write down the best practices for
attestation.  The problem is that if you are cover too broad scope and too many
use cases, you will hardly get valuable output. I suggest to start with very
specific use cases and solutions and then extend on it.

Ben Kaduk (Security AD): I am glad to hear people mentioning the privacy and
authorization issues for remote attestation.  Per Max's comment, holistic
attestation is going to be hard to do.  To the question of where there are
interoperability requirements, consider an example an IDS or network health
monitoring system needs to check the security/integrity state of network
entities from different vendors.

Tony Medline: There is work in the W3C about verifiable claim with focus on the
various data models, but not transport.

Dave Thaler: I liked Lief's comments about privacy.  The issue is what you send
to the relying party, not attestation server.

In reaction to the chair's summary of the feedback:

Aaron Falk: I have different opinion about one of today's outcome: we don't
have consensus on whether there is a unique or important problem to be solved. 
We need to get agreement on the interoperability problem.  A useful outcome of
this BoF, would be to agree on why we need to standardize something if there
isn't an interop problem.

Eliot Lear: Do we want to have a means to gather attestation information?  Do
we provide that in aggregate or granular form?  Per the architecture, what does
the root of trust look like, how is that anchored?  One approach might not be
possible

Michael Richardson: In ANIMA, 6Tisch and other prior work, there was a
realization that there are audit requirements on the attestations being
exchanged.  Since devices across verticals will need to interact there are
interoperability requirements for remote attestation.  Also, there are
manufacturers that are large enough that they could benefit from a standard
format to keep even internal business units aligned.

Massimiliano Pala: The real world requirement I see is secure network access
across devices from different vendors and to provide varying levels of trust. 
This work is useful.

Dave Thaler: To Pala, is your requirements from the device to the attestation
server or relying party? Massimiliano Pala: You're assuming there is an
attestation server.  Yes.

Ben Kaduk: To Thaler, what is the architecture you are proposing?  Is the
attestation service closer to the manufacturer or the verifying? Dave Thaler:
Yes.

5) An Attestation Format
========================
presenter: Laurence Lundblade
draft: draft-mandyam-eat-00
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-entity-attestation-token-00

Lundblade presented EAT, a token format for describing attestation information.

Questions:
None

6) Next Steps
=============
Alternative Reference Diagram: slide 9 of
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-chairs-summary-04

-- Discussion (open mic) (10 min)
-- Consensus Call for Scoping Questions (10+ min)
-- More discussion or charter discussion (as time allows)

With the problem statement and candidate starting points presented, the BoF had
its second open mic session to continue discussions on scoping and next steps. 
To help focus the comments at the mic on where interop might be needed (but not
propose an architecture), the chairs added slide #9 to the chairs update
presentation during the meeting.

https://www.youtube.com/watch?v=SrJCVq7zx6M
1:30

Carsten Borman: The slides presented as of yet were trying to present the most
simple of pictures.  In general, we have to expect that any serious attestation
systems is going to need several systems to work together, that's why the
interoperability is required.

Dave Thaler: In the last presentation, there was a line between a relying party
and the attestation server.  Is there work we want to do on the connection
between the relying party and the attestation server? What is the trust model
between them?  The presenter said no.  Per the diagram, this is line #2.

Leif Johansson: Line #2 (relying party to attestation server) needs interop. 
Line #1 is where vendors exist now.  Back to privacy, it seemed like in prior
presentation that it was suggested that privacy issues can be sovled by asking
the user to get consent.  We need to be careful when we think about how to
describe the privacy considerations.

Henk Birkholz: The new drawn picture may be too simple and misses things such
as the CA, the root of trust and the trust chains.

Lawrence Lundblade: Interop on line #2 would be do, but it is very difficult. 
My intention is to solve the line #1.  Per privacy, it will vary by use case. 
For example, on Android, such a device would talk to multiple relying parties.

Massimiliano Pala: All three lines are useful for interop depending on your
architecture.  However, line #1 and #3 are most useful for
interop/implementations.

Dave Thaler: There might be different opinions on what is line #2.  One
possible use case for line #2 is related to privacy.  While I may give
everything to the attestation server, but not to the relying party.  I've heard
a lot of feedback on the important of interop for line #1, but fuzziness on
line #2. Roman Danyliw (as chair): Concur.  The use cases for each line appear
to be varied from the comments on the floor.

Ben Kaduk: Trying to abstract the architecture, it appears there is a device. 
It has an owner.  This owner talks to the vendor/manufacturer for provisioning
of the device.  The owner also has an attestation server and it controls/sets
the policy of who is allowed to received what information/claims from the
device.  We appear to have agreement on Line #1 so we may just need to go with
that.

Carsten Borman: This picture is wrong.  What does these lines mean -- is it
communication?  knowledge of? trust relations? Roman Danyliw: The chart is an
attempt to define the the entities in question and to identify where interop is
required. Carsten Borman: All of these things sign things, or that's delegated.
 These entities are in different security domains and there are multiple
instances.  More boxes are required.  Don't try to categorize roles in this
picture.

Kathleen Moriarty: Claims work starting from EAT, which has implementation
experience, could be the starting point.  Further work can expand from there. 
EAT is a well-defined starting point.

Eric: Agreed with Moriarty. We need start with concrete use cases and this
would clarifying the interface interactions and flows required.

Eliot Lear: Agreed with Eric.  Per Thaler's comment on line #3, the use case
for interop is the an attestation server that is evaluating claims.  This
server would be in an enterprise element trying to determine whether to let a
device onto the network.  Both device and server as in the same domain.  The
lack of interop would mean that, for each device type, there has to be separate
attestation server.

Laurence Lundblade: Consider another use case.  The device is a chip; the
attestation server is a service offered by a chip manufacturer; relying party
is a bank that wants to know if this transaction originated from a secure part
of the chip.  The chip manufacturer is operating an open attestation service
for many relying party.  For example, the attestation server is Google/Android;
line #3 is keys given to phone vendors; relying parties are banks; and line #2
is banks asking Google/Android 'what do you think of this device?'?

Per Kaduk's comment about owner, this is really about software and device
manufacturers.

Henk Birkholz: Discrepancy between Lear and Lundblade's use case shows the need
for what Borman suggests.  We need use cases.  Per Kathleen's comment, there
are existing protocols to choose from too.  Not just a data model.

Ben Kaduk: We've seen two diagrams.  The simple one drawn with numbered lines
and more complicated ones seen earlier.  To relate one to the other, it looks
like in the more complicated diagrams the attestation server is collapsed into
the device.

7) Chair Wrap-Up
================
candidate charter:
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-draft-charter-00

In closing the chairs reviewed the following BoF scoping questions:

- Is the problem sufficiently understood? No.  Ambiguity remains
- Is this problem tractable? Can't answer with the scope
- Who is willing to author/review drafts? There was interest expressed to do
work

More discussion is required to proceed.  Draft charter language is available
for review.  Bring your thoughts to the mailing list.