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.