# RATS @ IETF 111 ## RATS Agenda July 26th Monday Session II Room 8, RATS Session 1 Note takers: Wei Pan (WP) and Michael Richardson (MCR) Time zone: PDT ### Agenda Bash & Logistics (5 min) Nancy Cam-Winget (NCW), Kathleen Moriarty (KM), Ned Smith (NS) ### RATS Architecture and next steps (5 min) Michael Richardson (MCR) [draft-ietf-rats-architecture-12](https://datatracker.ietf.org/doc/draft-ietf-rats-architecture) MCR: No significant changes to the draft; awaiting Shepherd review. NS: Some activities on the mailing list. Has the design team reviewed that and does the team have some opinions? MCR: The remaining issue is about a diagram. Personaly don't want to change diagram. No consensus in the design team yet. Expect for AD review and IESG review, and deal with all the issues together. Laurence Lundblade (LL): Have comments about layered attestation, it's not clearly clarified, but not critical. MCR: Many compromised changes have been made. Not enthusiastic on any further changes, but happy to engage on dialogue. Don't think the requested changes are critical to the general architecture. We don't have to get all the minor bits correct. KM: Want to hear all of the potential issues and see if we can progress this. LL: Hard to understand "layered attestation" given the text. Need a lot of TCG background which some people don't have. MCR: would be interested in additional or suggested text; it's reasonable to let people be directed to appropriate text. KM: as shepherd wants to see how to help move it forward; want to see suggestion of text so that we can conclude on this issue quickly. LL: not asking for detail design, or specifics; for "me" took weeks to read to understand what layered attestation means and get confirmed. KM: will work with you andou andy the authors. Henk Birkholz (HB): A proposal-based approach is to have targeted additional text The chat has others commenting that it should proceed to Area Director (AD) review. NCW: Go to AD review.NN ### EAT (10 min) Laurence Lundblade (LL) [draft-ietf-rats-eat-10](https://datatracker.ietf.org/doc/draft-ietf-rats-eat/) LL: Some Claims are ready for last call. NS: Are Cliams with 4 green bars ready and are the ones with less than 4 bars not ready? LL: Yes. Giri Manyam (GM): believes that there are a number of WGLC blocking issues, and requests that we have a deadline for new issues to be opened. Several other SDOs have normative reference to EAT. https://github.com/ietf-rats-wg/eat where the issues are logged. Dave Thaler (DT): About the claims with different bars, is the editor thinking to split the current draft into things that are ready for last call versus things that are not? Or is the intent to hold the draft until all claims reaching 4 bars. GM: Would like to hold. But it depends on the open issues. DT: Lets think about it and discuss it at the open mic on Thursday. LL: The objective is to define a solid core set of useful claims that are useful for basic attestation. NS: Is it that not enought people are providing feedback on Github? Or are people needed to read the latest draft to comment on it. DT: Some people didn't necessarily know the Github link. LL: Very little activity on GitHub except activities from my side. NS: suggests people read draft/issues on Github to continue discussion on Thursday. ### CHARRA and RIV (10 min) Henk Birkholz, Guy Fedorkow [draft-ietf-rats-yang-tpm-charra-08](https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra), [draft-ietf-rats-tpm-based-network-device-attest-07](https://datatracker.ietf.org/doc/draft-ietf-rats-tpm-based-network-device-attest/) On CHARRA draft: NS: Is it appropriate to go to YANG Doctor and ask what's holding up. HB: Eric did that occasionally, we're wait for responses now. NCW: as shepherd comments that drafts are ready, but need to ping the Yang doctor to confirm that the Yang comments have been addressed to his satisfaction. Once ID-Nits and Yang confirmation are done, it can go to AD review. On RIV draft: A new revision will get posted (for the RIV draft), and that version may be the last one. ### Reference Interaction Models and DAA (10 min) Henk Birkholz (HB) [draft-ietf-rats-reference-interaction-models-03](https://datatracker.ietf.org/doc/draft-ietf-rats-reference-interaction-models/), [draft-birkholz-rats-daa-01](https://datatracker.ietf.org/doc/draft-birkholz-rats-daa-01) **Discussion on Reference Interaction Models:** Issue #12 has been addressed, and now agreed that #43 is out of scope. NS: Asked if we are ready for WGLC? There seems to be support for going that way. WGLC will be issued. DT: suggests that if the chairs and the authors don't know of any open issues, then the document should go to WGLC, and he can agree to such a thing, even if he hasn't read the latest version. **Discussion on DAA draft** HB: Dave Thaler joined the author team. , NCW: I issued an adoption call and only one comment received. HB: I received some comments about the content, maybe before the adoption call. NCW: The adoption call was in late May, and Thomas and Guy gave the feedbacks. Need to find out how many people have read the draft befor adoption. 6 people have reviewed it. Take it to the mailing list, and another WG adoption call will be issued. ### Concise Reference Integrity Manifests (15 min) Henk Birkholz [draft-birkholz-rats-corim-00](https://datatracker.ietf.org/doc/html/draft-birkholz-rats-corim-00) RIM = Reference Integrity Manifests. CoRIM = {CoMID + CoSWID} Ran out of time with ~10 slides to go. ### Attestation Sets (5 min) Kathleen Moriarty [draft-moriarty-attestationsets-03](https://datatracker.ietf.org/doc/draft-moriarty-attestationsets/) KM: Would like to get more comments on the draft. Will iterate the comments received. There was agreement to move the draft to the working group draft. NCW: Nancy says that she will start a request for WG Adoption call for this document in the next week given feedback. ## RATS Agenda July 29th Thursday Session I Room 8, RATS Session 2 Time zone: PDT ### Agenda bash & logistics (5 min) Nancy Cam-Winget (NCW), Kathleen Moriarty (KM), Ned Smith (NS) ### Open Mic (5 min) NS: Attestation Sets draft available for comment -- looking for feedback on adoption from the wg KM: text should be stable - only minor edits needed so far. KM: there may be an implementation lined up. KM: Antonio has provided input to the draft. GF: relationship between this drafts and Eric's? KM: different scope: devices vs systems. Seems like I'd like to keep the draft separated. GF: seems like aiming for similar targets, not sure I understand what the difference is. KM: need compare to EV's more recent draft to look for similarities, but I see differences. Mine is targeted at what attestation sets would look like. EV: perhaps things could be merged, would have to compare the results in each draft. KM: objective for sets draf is small (align to industry recognized standards), don't want to cover too much ground. NCW: need more discussion on the ML to clarify the differences. KM: would like more time this IETF to get to adoption call. NS: we may have some time at the end of the meeting to further discuss this. ### Attestation Results and Trusted Path Routing (25 min) Eric Voit (EV) [draft-voit-rats-attestation-results](https://datatracker.ietf.org/doc/html/draft-voit-rats-attestation-results-01), [draft-voit-rats-trustworthy-path-routing](https://datatracker.ietf.org/doc/draft-voit-rats-trustworthy-path-routing/) Summary of the problem - provide a standard abstraction for complex, device specific attestation results. Express validation for: - Identity - Verifier Appraisals - E.g., is hardware authentic, is the security configuration acceptable - Freshness Presentation goals: - Requesting WG adoption - Consensus on problem being addressed-- there are a lot of attestation environments, and different apps trying to prove their trustworthiness to a relying party. Need to normalize definitions of claims so the relying party can figure out what is being attested without translating between them. - Define broad categories that abstract commonalities in hetereoegneus environments: identity, verifier appraisals, and freshness - HW authenticity, TCB integrity, etc - Once you understand what claims are being made, there are diffent uses for them, different ways they could be attested to by the chip EV: Presented example trustworthiness claim delivery message flow showing Attester, Verifier-A, Relying-Party/Verifier-B. Message flow is described as 'passport model'. Dave Thaler (DT): Message flow should not be constrained to the passport model; suggested it was a hybrid model. EV: Yes, currently written for passport model, could be changed. DT: Suggested a change to the draft to remove references to specific topologies unless they are required. - Normalizing claims is not the same as normalizing relying party policy. the RP policy is orthogonal. DT: Slide 7 is hybrid model, not really pure passport. EV: In fact, this is "based on" the 'passport model'. DT: Maybe simplify the examples: make two pics, one for BG (background) and another for PP (passport). - Augemented evidence-- can add verifier a decisions to the evidence shared with verifier b - this draft aims to define trustworthiness claims, identity, and freshness of the evidence in a shareable way across transports Daniel Migault (DM): slide 5: is there any link between identity and verified identity? EV: yes, on slide 5 normalizing trustworthiness claims (note from Jess-- I think that was the right slide?) Laurence Lundblade (LL): The same philosophy is in EAT (i.e., capture broad semantics). Take a look if there are any claims in the EAT draft that can be reused. NS: show of hands for who has read the draft (7 people have read it). Call for adoption discussion: · How the work fits with EAT work? · Concern that adoption shouldn't be considered until after Lawrence's topic in RATS Session 3. NCW: There are a fair number of reviews, I suggest we defer a call for adoption until after the review of LL's EAT presentation on attestation results (AR) during session 3 today. Will confirm any discussion on the mail list. Roman Danlyn (from chat): Another possibility if we need to pull apart the way ahead for a seemingly related cluster of docs is to reconvene at a topic-specific virtual interim. That way we can have a "side-by-side" conversation. I'm note RATS is already booked with more sessions than anyone else on this week's agenda and it looks like we still have a packed schedule across the three sessions. chat: ^^^(gets some thumbs up) Henk Birkholz (HB) (from Jabber): I am in strong favor of establishing as much consensus with precisely scoped topics on the list as soon as possible. An interim will also be "a room" and discussion results will have to be brought back to the list anyways. Let's use today's time to present the current states as best as we can, so we can create these topics for consensus finding on the list as best as we can Kathleen Moriarty (KM) (from Jabber): Henk - I agree. I think there's enough different with each draft, but some overlap with EAT for the attestation results draft to reconcile. Moving forward soon would be good, Nancy Cam-Winget (from Jabber) The chat is showing some level of consensus.....we need to have a closer review/analysis to these 3 drafts now to ensure we have the right scope and goals between them. Lets plan on initiating the discussions after the presentation today and establish the points that we need to get consensus and plan on an interim to build a path forward. KM (from chat): I'll note there are some clear differences to attestation sets as the purpose is different. The sets draft looks to convey that a set of policies and measurements have or have not been met. It would be complimentary or just used with what is in EAT. **Trusted Path Routing Draft** EV: Trusted Path Routing- based on attestation results augemented evidence, add links to a routing topology to move around untusted devices. Much material from last draft version was extracted into Attestation Results v01. EV: Summarized the problem: - Routing around nodes that can't prove their security postures - This draft results from the original trusted-path-routing draft, which was split in two - Adoption is not requested until after Attestation Results draft. EV: Reviewed updates since last RATS meeting. Not asking for a call for adoption until there is a decision (adoption call) on attestation results draft. ### Attestation Event Stream Subscription (5 min) Henk Birkholz, Eric Voit [draft-birkholz-rats-network-device-subscription](https://datatracker.ietf.org/doc/draft-birkholz-rats-network-device-subscription/) Henk discussed Attestation Event Stream Subscriptions (no slides) - Status report, no request for adoption. HB: Evidence is not the only interesting message, policies, logs, etc are all interesting too. We want to add additional message streams to allow for all conceptual messages. Not asking for adoption yet. ### Trusted Identities (20 min) Meiling Chen (MC) [draft-chen-rats-tee-identification-01](https://datatracker.ietf.org/doc/html/draft-chen-rats-tee-identification-01) MC: Use tee and eap-tls to create a proceedure to autheticate a device's identity. Can be use in link or data layer. MC: TLS is secure but the endpoint may not be MC: needed in mobile networks, where authentication of the device cannot be the same as the authentication of the SIM card EV: what identity types you eventually want to support? Can you support chip type? Can you support Software instance? Can you support chip instance? EV: it would be great to be able to support different types of identities tied to a private key. MC: we do not specify what types of IDs to use (Note from Jess- I think this was about it? Please edit if wrong) MC: Inner middle layer is where key derivation is done. The key must be protected here MC: X509.3 certs are stored in the TEE, key derivation has to occur in TEE MC: specification defines 6 messages exchanges with the Extended Middle Layer (EML) MC: todo- prevent or mitigate attach from REE, and identify if the device enables TEE functions DT: I will observe some of the things you describe overlap with TEEP: take a look at the TETEP aarch to see if there are any sec considerations to be inherited here LL: comment: looks very similar to IDevID, maybe have a look at that. LL: Question: does this cover IMEI, Mac Address, MIMSI? MC: Assumes TEE is trusted and the identity is encrypted. Do you think we need to prove IMEI? LL: A you planning to use these identifiers (IMEI, Mac Address, MIMSI)? MC (Collegue): IMEI can be used (lost transmission) NCW: let's continue discussion on the mail list, authors provie their expectations for this draft on the list as well. ## RATS Agenda July 29th Thursday Session II Room 8, RATS Session 3 Time zone: PDT ### SUEID and EAT relation to DevID (20 min) Laurence Lundblade (LL) LL: semi-permanent UEID = SUEID to id an instance of a piece of hardware. Currently encoded as a binary string, goal is an identifier that is globaly unique that has additional properties: - is created with crypto-quality RNG - or is a IEEE EUI - or is a IMEI Answers need for a device ID change when a device changes ownership, or otherwise needs a new identifier (e.g., from a reset). IEEE uses IDevID/LDevID [802.1AR](https://standards.ieee.org/standard/802_1AR-2018.html) certificate containing a device identifier. An Semi-permanent UEID (SUEID) is similar to a UEID but can identify sub-devices / sub-components, each with their own SUEID. What is the relationship with IDevID? 3 ways, highlighted in following slides: - EAT protocol is used with an IDevID - both are implemented and work together - EAT as a competitor to IDevID - Both can identify the device (competitors) - EAT claims are added into the IDevID - Can put the claims in EAT token which goes into IDevID Interesting question: how do you ensure conflicting Ids are not received by the Relying Party (especially when composite identities are involved.) has to be a signed nonce to prevent replay- this would be handled in EAP, but, DevID doesn't require any particular protocol EAT claims can be put into an x.509 v3 exensionin a DevID cert - option 1: define ASN.1 syntax and an OID for each EAT claim - option 2: define one OID that contains a CBOR/UCCS formated EAT note: this only works for static EAT claims DT: good stuff, couple of comments: 1. dev identifiers, there are many (MAC addresses, etc.) one could do the same exercise for any similar identifier out there. Yours is some kind of template for others to repeat the exercise. others could do this for other kinds of IDs, or for IDs for things besides devices (software identities, user identities, etc.) LL: will bring a side dicussion to the list on UEID v other types of IDs. Good discussion, may even cross working groups Russ: do you think the cert extension for EAT claims should be defined in RATS or somewhere else, and if the latter where? LL: haven't really dug into that, don't have an opinion .Think its encoding a symatics, probably not that hard Russ: That involves ASN.1, and I can help with the ASN.1. EV: would be good to talk about the heirarchy of IDs that might be needed. Have you thought about the relationship between the IDs. The relying party will have to understand the specific IDs in order to evaluate according to Policy on the Relying Party LL: focusing on claims right now, need to think about architectures. hopefully expressible via sub modules in EAT. EV: You need to structure your claims so that the policy language at the RP that digests them gets what they need EV: Claims are only as useful as the Policy language which can consume them. So you need to aim your claims for processing at the consumer. ### Claims to carry Attestation Results (20 min) Laurence Lundblade (LL) Serving the Relying Party (RP) is the goal of attestation - a lot use machine learning, want every bit of data, even if it's of little value LL: EAT is a relevant/viable way of encoding claims. LL: Many claims may pass through the verifier and relying party. LL: slide 15 provides list of claims that are useful to pass through to the relying party LL: Slide 16 includes the things determined by the Verifier. EV: some of the claims on slide 16 are useful to normalize against the Attestation Results for Secure Interactions draft. A first cut could be done before the offsite discussed during the previous hour. Digital Letter of Approval (DLOA) is a digital version of a letter of approval. Currently an XML document. - includes authority who issued it, and loa id and scope, a platform label, issuance date and expiration date - not in any drafts, but available in github DT: Is the DLOA an endorsement, and attestation result? LL: I don't think its an Endorsement. DLOA can be included as a claim to an AR, tell the RP about properties - like passing a common criteria certification, etc. HB: What is a claim and how is the claim collected? LL: Verifier would receive Evidence that includes OEMID, SW & HW info, and Verifier would have a table to lookup DLOA based on the identity. LL: DLOA is retrieved by the Relying Party from an Endorser. There shouldn't be many of these enumerated. DT: DLOA is about a class of devices, not an instance. NS: Noted several messages in chat questioning the RATS Architecture definition of Endorser / Endorsement being specific to an particular instance of an Attester vs. a class of Attesters. Some people in each camp. ### TEEP requirements for EAT (10 min) Dave Thaler (DT) DT: TEEP WG has a draft showing requirements on what is needed to be enumerated in Attestation Results. BM: I don't see a device unique ID from SUIT. SUIT shouldn't have a strong preference here. DT: The goal from TEEP is to show what should be generalized across groups beyond TEEP. Presumably in RATS. DT: [draft-birkholz-rats-suit-claims](https://datatracker.ietf.org/doc/draft-birkholz-rats-suit-claims/) should be generalized for this purpose. Dispatch question: what should happen with this document? Options: {a} goto RATS, even if some claims are SUIT {b} goto SUIT, even if some claims are not SUIT {c} dispatch SUIT claims to SUIT and keep general claims to RATS. DT: my preference is for the last option, with general claims added to EAT spec HB: This should be a RATS document. Even if the claims are SUIT specific. DT: Not all claims need be done in RATS HB: splitting will cause confusion DT: Authors want {a}, David wants {c} In chat: Russ- c LL- c Thomas- c, def not b, can live with a MCR: a, does this change time needed to complete doc? LL: the main thing is that for the claims that are generic, make the work to make them really generic. this is the most important thing, where they are defined is a secondary consideration -- agree with MCR on this. DT: There are early assingment issues with some of the claims which need to be considered, and could block implementation. HB: wild idea: pull Laurence in the authors pool in draft-birkholz to create the right synergy to get the early assignment. Let's figure this out offline. DT: Requested the chairs to take the dispatch decision. LL: we got early assignment already, not sure how many times you can do that. I don't see early assignment as a hard requirement. Ned Smith (NS): let's move this to the list. Get more discussion between option A and C. Option B wasn't popular. DT (from Jabber): this will affect the SUIT recharter discussion tomorrow if people argue for A. The SUIT draft recharter text allows for B or C. NS: need to go for a RATS virtual interim meeting. More details to follow on the list. NS: Session closed. ### Open Mic x(10 min)