# RATS Meeting Notes Tuesday March 22nd Room: Park Suite 3 Time zone: UTC+1, 2 hrs ## Agenda - Session I Notes Takers: Giri Mandyam (GM), Tero Kivinen **10:00 - 10:05 Agenda Bash & Logistics** (5 min) WG Chairs - Nancy Cam-Winget, Kathleen Moriarty, Ned Smith [Chairs began meeting and Note Well. **10:05 - 10:10 CHARRA Summary** (5 min) Eric Voit - (draft-ietf-rats-yang-tpm-charra) [EV] Review of ver. -18 changes. One IESG review pass is completed. References adjusted and XPATH description will be provided. Number of interdependencies in drafts and some with IESG now. [Chairs] Request to resolve "Discuss" comments from AD [EV] They should have been resolved already, needs to just clear them. **10:10 - 10:13 AR4SI Summary** (3 min) Eric Voit - (draft-ietf-rats-ar4si) [EV] interactions between an attester and verifier solidified background check & verifier model - raisin open source project in confidential compute environments (TEE). Comparisons to EAT - seclevels and swresults claims - have been included. Also more detail on trustworthiness claims. AR design principles for trustworthiness claims has been further clarified in latest draft. Overall desire to maintain commonality between EAT trustworthiness claims and ar4si. **10:13 - 10:16 Device Subscription Summary** (3 min) Eric Voit - (draft-ietf-rats-network-device-subscription) [EV] Provides a method for accessing a steam of information from a TPM as PCR map changes. Will update with sec. cons. and go to WGLC after CHARRA. **10:16 - 10:21 Architecture Summary** (5 min) Michael Richardson, Henk Birkholz - (draft-ietf-rats-architecture) [HB] No remaining GH issues. One outstanding PR. Has been submitted to IESG for review/publication. Pending AD action. [Roman] Will review during next week, and start IETF LC after that. **10:21 - 10:26 DAA Summary** (5 min) Henk O - (draft-ietf-rats-daa) [HB] Next steps for document described - incl. rel. of DAA issuer to RATS endorser, privacy CA, TCG DICE, and privacy via CHARRA interaction models. [Laurence Lundblade] DAA could apply to EAT. [HB response] May require separate document. Requesting help. [Thomas Hardjono] DAA is for TPM. Privacy CA for DICE requires furhter investigation - may not make sense. [Laurence Lundblade response] DAA is a general concept and is not associated with TPM's, e.g. FIDO specification of ECDAA. [Diego Lopez] Are the use cases for DAA focused on protecting privacy of individuals (like in the case of mobile terminals) or rather oriented to simplify the processing of "swarms of similar devices" (Henk dixit) where specific identities are not relevant? [HB] Both use cases can be served **10:26 - 10:31 Interaction Models Summary** (5 min) Henk Birkholz - (draft-ietf-rats-reference-interaction-models) [HB] Added models and sample sequences for challenge/response. Emerging requirements of C2PA, Coalition of Content Provenance and Authenticity, may affect draft. Can go to WGLC. **10:31 - 10:36 UCCS Summary** (5 min) Henk Birkholz, Carsten Bormann - (draft-ietf-rats-uccs) [HB] Latest changes included feature tag, which can allow for JSON or CBOR description of UCCS. Addition is informative, hence no change to document title ("UJCS"). **10:36 - 10:41 EAT Summary** (5 min) Laurence Lundblade - (draft-ietf-rats-eat) [LL] Changes in latest (-12) draft: normative language cleanup, HW version claim improvement, entity def.'n, HW version, boot odometer claim among other things. Future draft can group claims into categories: entity claims, token claims, nonce/freshness, public key attestations - all covered by open PR. Upcoming draft will complete CDDL and bug fixes as well. [LL] Topics requiring WG consensus: relationship to UCCS, security-level claim, role of EAT in attestation results' [Roman] Early allocations have been approved, waiting for iana **10:41 - 10:44 RIV Summary** (5 min) Guy Fedorkow [GF] Document describes standard operating model for TPM-based remote attestation in routers. IESG review DISCUSS comments have been resolved. Ready for RFC Editor. Document has been synchronized with CHARRA. [Chairs] This is the first document form the RATS WG. **10:44 - 11:04 RATS Charter** (20 min) WG Chairs [Chairs] As per IETF 112, WG agreed to expand charter. Poll on who has read the proposed charter text. 24 participants had not read text - only 8 had read. [Chairs] Primary change was to expand scope to include endorsements and reference values. [HB] Charter text can cover protocols for endorsements/reference values. [Chairs response] Covered by separate charter statement on protocols. [Kathleen Moriarty] What is the criteria for extensions (e.g. IANA registries)? [Chairs response] Covered in item 6 of Program of Work. [Dave Thaler] Charter should clarify 5 in Program of Work (interoperable protocols). Existing protocols should be used whenever possible. New protocols should be justified. [Chairs response] Will propose edit. [Hannes Tschofenig] Recommend not getting delayed by language on existing protocols. [Chairs response] Previous charter got bogged down in Program of Work. There should be another pass at the charter. [Laurence Lundblade] Charter should not exclude EAT for attestation results. Charter looks to be OK. [Chairs] Will confirm charter edits on mail list. **11:04 - 11:14 RATS Milestones** (10 min) WG Chairs [Chairs] Milestones need to be updated. Group has fallen behind. [Roman] AD review of milestones is ongoing. Caution WG to pipeline work correctly. **11:14 - 11:44 EAT Attestation Evidence / Results Taxonomy** (30 min) Laurence Lundblade [LL] Attestation results (AR) is for a full range of security assurances (TPM, downloadable SW, etc.). AR should cover range of system architectures. [HB] AR are intrinsically tied to evidence. AR becoming stale implies a determination that evidence has become stale. attesting environments cannot be 'signing fools'. [LL response] Comment on full range of system architectures was not meant to address detection of 'signing fools'. Verifier policy would be out of scope. [EV] RP has a verifier in most cases. Evidence can be sent as well, not just AR. [Hannes] Previous comments were not related to content on slides. There is sometimes a assumption on the minimum security assurance of attesters, There should be a more general model for RATS, where policies can account for different implementations. Will AR document such differences? Would recommend against it, and leave it to sec. certification schemes. [LL response] We cannot narrow down to one security level in RATS. RATS should be universal. [Nancy Cam-Winget] As a systems architect, this goal is laudable but difficult to meet in practice. Hard to cover gamut of security assurances. CHARRA is an exmaple which is TPM specific. [HB] Someone needs to decide whether security assurance is adequate. This is the verifier, and is defined for AR. [Hannes] Implementors will decide on the target security assurance level. We need to support a wider spectrum. Organizations will decide what they want to use, not just TPM. [Nancy Cam-Winget] Are you commenting on a specific draft? [LL response] I have written on the mailing list on AR4SI. [HB] Miracle occurs. Someone defines an appraisal policy and the results are conveyed. This is consistent with the architecture. [LL response] Verifier does not determine whether a transaction is good. Application-specific interactions are handled outside of verifier by RP. RP makes final decision. [Brendan Moran] 3 entities can be involved: trustworthiness verifier, FW version verifier and RP. RP must detect which verifier to trust. [EV] Verifier is embedded in the physical RP device. Almost all physical devices will have a dual role. And just because Evidence is sent to the physical RP device doesn't make it AR. [Diego Lopez] Level-of-assurance for the verification, beyond the LoA in claims, could be considered in the process. A draft could be written on this topic. [LL response] EAT has a DLOA claim. [Hannes] Multistage verification: is it documented in the RATS architecture? [LL response] Arch. does not discuss compound verifier. [HB response] Compound verifier is a co-located verifier (with RP). [Chairs] Has this been articulated well in the Arch. document? [LL response] Verifier policy is what is not defined. [Hannes response] Agree that this is disconnect. [LL] (continuing with presentation) Verifier and RP is a B2B communication. B2B data encoding and security is solved and should not be a focus of RATS. Device/attester ID was originally defined in EAT document, as was meant to be conveyed directly to RP. [Hannes response] Device ID should be extensible. [LL response] EAT ueid is extensible. [HB] Identifer versus identity: need to understand attesting environment and how identity is determined by verifier. Regarding kultiple verifier: architecture can be augmented with statement on this topic. [LL response] Not a critical need to change arch. document. [LL response] If someone cannot use ueid for your use case, then please provide feedback to EAT editors. [LL] Allow passthrough claims. [LL] Base standard could cover simple pass/fail and/or error code. Device ID could also be incldued. But other verifiers (e.g. ML engines) require every detail from the attestation evidence. AR can cover a large range of protocol requirements. [Giri Mandyam] EAT should not be overly prescirptive on how passthrough claims are determined. This is because of the range of verification architectures (e.g. multistage verifiers) make it difficult to determine a general approach for how/when verifiers would determine how attestation evidence can be passed through. [EV] Arch. document covers RP as a role, not a physical item (e.g. device with its own security assurance). [Dave Thaler] Is passthrough defined in any document? [LL response] Pending PR in EAT document doesn't use term 'pass through' [DT follow up] Will update TEEP terminology accordingly. **11:44 - 12:00 Open Mic** (16 min) # RATS Meeting Notes Wednesday March 23rd Room: Grand Park Hall 3 Time zone: UTC+1, 1 hr ## Agenda - Session II Notes Takers: Thomas F, Kathleen M **13:00 - 13:05 Agenda Bash & Logistics** (5 min) RATS chairs no agenda bashing **13:05 - 13:15 UCCS / UJCS and EAT** (10 min) Giri Mandyam [GM] EAT and UCCS are both standards track and both scoped to attestation. We need to establish a clear relationship between the two documents. Assumption: UCCS scoped to attestation, does not require mutually authenticate d secure transport -- leaves it as a matter of security considerations. EAT makes no normative requirement on transport layer. Assumption: EAT can be a UCCS, therefore UCCS is a normative ref for EAT. [DT] Question: is there a use case for UCCS to be used in attestation results? If so, there may be some word-smithing to be done in the UCCS draft Dave Thaler suggested just using evidence as an example (in meeting chat, he also mentioned some might want to use EAT as a format for Endorsements too, not just AR). Question triggered by introduction of the document itself which only says "the conveyance of Evidence from an Attester to a Verifier". [GM] Proposal: EAT editors recommend to incorporate the meat (i.e., the normative parts) of UCCS into EAT and only focus the UCCS draft on the security considerations. UCCS can then become an informational document and therefore solve the normative reference dependency troubles UCCS can focus more on transport considerations then. [RD] would the security consideration section in UCCS be reference informatively or normatively? [GM] it'd be informative, since we don't fully grasp all of the use cases for UCCS. [KM] I'd be against the EAT editor proposal. Trying to understand this in the context of the timeline for the publication of the EAT document. [GM] the impact is already there. The WG needs to figure out timeline impacts and the path forward in terms of dependenciesBig . [CB] practical problem: there is weird stuff in section 8 of EAT that we'll need some time to clean up. Fundamental problem: CWT is general purpose. Can we get a clean separation between the EAT extensions on top of CWT? That'd make me much happier. [HB] UCCS has nothing to do with EAT intrinsically. [GM] should we bring it to a different WG then? [HB] the "presecription note" we are writing is for RATS, we do it where the Sec Con experts are. **13:15 - 13:25 Attestation for Cloud-Synchronizable Keys** (10 min) Giri Mandyam [GM] use case: moving credentials from one device to another. FIDO defins AROE (authenticator restricted operating environment) which may include an Attester. Relevance with the RATS architecture: "must not be able to modify or extract keys" (of what?) [GM] question for the WG: should evidence address whether private key material is extractable? possible way forwards: 1) define claims in EAT, 2) leave it to the specific EAT profiles, 3) no-op let the RP figure out. [HB] If this comes with an endorsement ok, but if not that would become a self-assertion and this is not good. Pretty dangerous. [DT] I'll pick the second option (leave it to the EAT profile) [LL] FIDO auth keys are different from attestation keys. The latter is of concern for this group, the former is not. **13:25 - 13:40 Concise Reference Integrity Manifest** (15 min) Henk Birkholz, Thomas Fossati - (draft-birkholz-rats-corim) [Tony] leave FIDO to work out the details [TF] CoRIM is an attempt to provide a network effect to improve the supply of descriptionss of the attester to the verifier. Transport agnostic. [TF] CoRIM is an extensible container consisting of groups of triples (sub, verb, obj). [TF] Info model is in DICE. Data model is this ID. Running code in Go. [TF] Cannot adopt; require charter update. Can we adopt once charter is in place? [DT] Yes, this is work that we should adopt. Primary value is in specifying reference values. Depends on charter update going through. [DT] CoRIM should not be used to carry evidence. Avoid endorsements, should focus on reference values. [TF] How do we express interaction with a certification body [DT] If we cannot express appraisal policy in EAT semantics, then express as a reference value. [DT] It would be appropriate to continue to discuss in the working group. [HB] There could be a CoRIM that contains only endorsements. [HB] The identity part of the endorser has to go in the reference values. [HB] Reference values need pointers to endorsers. [HB] Reference values and endorsements can be combined by the verifier [HB] CoRIM already has PSA endorsement token [LL] Reference values have to correlate to measurements in evidence. Eat allows plugin formats for measurements, e.g. SWID. Chairs: Reminder: cannot adopt without charter udpate [NCW] Wants to know who read the draft and want have enough to provide feedback [DT] from chat: I personally am thinking of using EAT for Endorsements and CoRIM for ref values.08:44:00 since endorsements are just another claim set of singleton values (unless someone can convince me otherwise :) **13:40 - 14:00 Open Mic** (20 min) [GM] Clarity desired on UCCS and EAT circular dependencies. [NS] Several gating items discussed last year, what are the gating items? [HB] Can get consensus of editors after the meeting. Can just do EAT and can give guidance on how to do UCCS with EAT, it's a decoupled problem, it's not holding anything up. No recursive thing. [GM] If there's WG consensus, that is one way forward [DT] Way forward to remove normative content about UCCS in EAT and make it informative. This is doable and fastest path to get EAT to RFC. EAT RFC would just informatively reference UCCS as "Work in progress". [LL] Problem is CDDL. Need CDDL to make EAT complete, that's why he proposed bringing UCCS into EAT or they have to progress together. [HB] Doesn't understand what is meant by the CDDL comment, can keep CDDL in EAT spec. Discussion in room clarified, but not audible remote. [NCW] Echoed what Dave and Henk said - not clear remote. Poll to make UCCS content informative - 16 to 3 in favor.