Remote Attestation Procedures (RATS) IETF 106 - Singapore (2 sessions) Chairs: Nancy Cam-Windget, Kathleen Moriarty and Ned Smith Note: Kathleen and Ned will be remote, so please ensure they receive slides to upload and other administrative tasks that can be easily accomplished from afar. FRIDAY NOTES BELOW. Chair: Nancy Cam-winget Note Takers: Peter Yee, Michael Richardson, Liang Xia, Wei Pan Jabber Scribe: Jaime 15:20-16:50        Tuesday Afternoon session II (90 minutes) Room: VIP A EAT Claims Discussion, Laurence Lundblade (30 minutes)  o Software Inventory claims  o Measurement and integrity claims  o Public key claims   15:23 Laurence presenting. Support for CoSWID was expressed at the MIC. Henk: some questions and then a hum. Hannes: public key claim.  I believe that this already exists.  Was specified in CWT and JWT. LL: proof of possession is not there and the Android claims are not there (yet). Henk: there is a format for RPK for DTLS (https://tools.ietf.org/html/rfc7250#section-3) this is a MUST for the RPK format.  Q: Does the group believe we should work to define Claims for Attestation Results. Yes Hum: some people. No Hum: complete silence. Q: Should we work on public key claim like proof of possession (PoP) and GIRI: FIDO has a concept of Credential ID. LL: we should refine this proposal and work on it another time. Hannes: ACE has some PoP work. Q: Does the group want to work on claims about software inventory Yes Hum: moderate + some in jabber.  No Hum: nobody Don't care: a few Q: Does the group want to work on measurement/integrity claims Yes Hum: silence, but 4 in jabber   [not sure the minutes need to identify the people, as we don't identify hummers]  No Hum: silence Don't care: some people EAT Open Issues for discussion, Laurence Lundblade (50 minutes)  o Detailed overview and discussion on submods and nesting.   o OEMID Clarifications  o UEID size  o cti, jti and nonce   o Claim optionality  o Claim characteristics PR. Relates too above.   o Boot state / debug as levels, not Booleans  Chair: Is there an issue on Github related to the OEMID PR? LL: May not. Text before was incomplete, so I create a PR. Henk: Question about encoding. Using CBOR for compactnees is fine. Dashes and HEX values in Jason with base64 or base64 URL isn't fine. LL: It's common to express MAC addresses in this form. We can discuss more on the mailing list. Henk: The debug states isn't independent, it's platform specific. There should be an indication about what platform this is for. LL: Try to make it general and not platform specific. Henk: What does 'debug' mean? LL: It means whether some debug facilities are truned on or not. Henk: So 'some' has to be defined as platform specific. This is still platform-specific. LL: Read the context in the draft. Ned: 1) Is the secure-boot moved out of the draft? 2) It deponds on the uses cases as how useful the debug status are. LL: Vendors can always have prefered proprietary claims. DaveThaler: Change 'boot' to 'start', then it'wll be applicable to more scenarios, such as SGX Enclaves Giri: the states need to be split across Chip OEM (e.g. Qualcomm) vs Device OEM (e.g. Phone). Can add a lable into the claim to indicate which OEM owns these debug status? LL: OK. Chris (not sure): It's better to add an 'unknown' state. Stephen: Agree with Chris. LL: Will discuss more on the mailing list. Dave: The submodules match my needs. Can all the 3 submodules be claims? LL: The submods contain the claims. The name of the submod isn't a claim. Henk: They may be covered by the attestation provenance concept in the architecture. Signed submods are more complicated. Ned: It's unclear to me that what is the attesting environment and what is the attested environment. Chair: Do you mean to augment to diagram about who's doing the attesting? Ned: The attesting environment has some special ability to observer the attested environment, so it can make these claims legitimate. I don't get the use case for the linkage for things that sign other things. Dave: This picture didn't show the attesting vs. the attested environment. I agree with Henk that this should be discussed in the architecture document. # Security Considerations Henk: It's an assumption that the attester knows which parties are there will be able to appraise the evidence and it isn't always true. Giri: I think it's reasonable, but the nonce needs to have some providence. Henk: This can be remediated by the attester giving a hint, and the verifier will assess the hint. Ned: Is it a case that the Verifier of submod A would provide its nonce to the top-level Verifier who would forward it to the attester. Giri: Not necessarily. Dave: The bottom case is complex. It may be suitable for the use case draft to consider. Frank Xia: Agree with Dave. It's an use case. Giri: There's transport security issues to be considered. Frank Xia: It's not a typical remote attestation security consideration. Dave: For the simple case that has EAT and EAT, are you assuming that nonce on the left is the same as the nonce on the right? Giri: The nonces can be different. Dave: Then the attester only talks to the top-level Verifier because that's the only nonce that it needs to include. Henk: There could be multiple remote attestation servers, and the attester needs to know this, then the nonce create is viable. Otherwise there has to be a distribution system. New Drafts: Explanation to contrast this proposal with EAT, Giri Mandyam (5 minutes)     https://tools.ietf.org/id/draft-mandyam-rats-qwestoken-00.txt Henk: For the PKHash, I assume the evidence comes with the hash of the public key, and then you need to go back to the Asserter to resolve the hash and validate the religion provenance of the evidence. Right? Giri: Yes. If the private keys of a device got lost, I need to provision a new public key to this device, then I can query the PKHash to know which device is using the old public key. Henk: Why isn't the hash also been destroyed? Giri: If the device updateds its public key store. Henk: The Asserter retains a secret key derivation function to reconstruct everything, and then this would be possible. Giri: It's usually a standard hash, like SHA-256. Henk: For every device, hash index is maintained by the asserter. LL: This public key has nothing to do with verifying attestations, this key is only used to verify the software that you're going to run. The software producer has the private key and the device running this software has the public key, so the device can verify the software. Henk: It's implicit attestation by origination. LL: It's not even attestation. Sometimes it's a stand-in for an OEM ID because the OEM has to have the private key otherwise they can't sign the software. Chair: Is your intent to bring your draft as a potential profile? Giri: Yes. I want to resolve these questions whether some of these claims belong to EAT draft or profile draft. Chair: Make this clarification when you pose it. Giri: File an issue or put it on the mailing list? Chair: Issus is more formal. Henk: About the 'Context', might that be related to the audience tag and CWT? Giri: It could be related to the audience tech. The entity usage of the token would be implict in the audience tag. Chair: Discuss more on the mailing list. ========== 10:00-12:00        Friday Morning session I (120 minutes) Room: Orchard Friday Nov 22, 2019 Chairs: Nancy Cam-Winget Kathleen Moriarty (Remote) Ned Smith (Remote) Note Takers: Liang Xia, Peter Yee (offline), Wei Pan #Security Considerations for RIV draft, Guy/Jess (20 minutes - remote) 2 minutes comments and then discussing the intention of the draft for RATS Michael: IDevID and LDevID issues, maybe need a specific terminology for RATS instead of just using IDevID and LDevID. Certificate chain relation needs more clarifications. Guy: explain the process of manufacturing routers with TPM of Juniper. Laurence: all is talking about integrity check of the booting stage, not running time, and other evidence that can be attested? Guy: yes, this document is not intended for those parts, which is a gray area. Chairs: Ask the authors about the intention of this draft? adopted as a WG item? Guy: Can be an informational draft to describe the process of RA for routers. Chairs: your draft may be the use cases or part of the architecture. Considering to merge into use cases or architecture draft? AD: clarify the role of use cases draft. Michael: can be a specific RATS profile with some specific claims and mechanisms. It depends on architecture progress. Dave: I don't have enough information to choose from yet. If no normative things contained then it suits for use cases draft. Architecture draft is generic and this is specific. Kathleen: Double-check the statement of use cases draft role. We can consider to incorporate this draft into the use cases draft, and adopt them in the future. Agree with Dave that this isn't fit for the architecture draft. Henk: Agree with Kathleen and Michael. This can be a profile of the architecture. Chair: encourage to clarify the intent of this draft and have more discussion with architecture Design Team, and make the decision later #RATS Architecture (45 minutes) Discussion from the Editorial Team Chair: explain the goal of the architecture design team, and members: Dave, Henk, Michael, Ned Eliot: ask the way to reach consensus in Github, some confusions for him Dave: explain the text: chairs close Github issues Michael: discuss at Github first, then bring the result to the mailing list Dave and Chair: agree with Michael on this point Laurence: ask about the pace of publishing drafts and what are the decision points. Dave: no answer now. Henk: talking about the terminology and use cases, we need it and have several options to include in current drafts Dave: ok and welcome more discussion Thomas from Jabber: agree with the current way of deal with trust establish part in arch draft Elliot: in-band interaction vs out-of-band interaction clarification question Dave: current diagrams are out-of-band, in-band ways are already in architecture draft (the passport mode and background check mode) Thomas from Jabber: Can Attester don't sign evidence at local which is to be pulled later by Verifier? Dave: Yes. Michael: we may need to consider cooperative and uncooperative methods for arch design, for protecting privacy and confidentiality. Dave: I don't know yet whether it belongs to the architecture so far. Need more thinking about it. Henk: jabber says we need recharter for phase 2  Laurence: how many details should be in the arch? for example, signing methods, ... Chair: we need to consider this point. Thomas from Jabber: also need to allow Verifier to ask for only the substance of the claims. Dave: will discuss this after this meeting. Chair: ask the timeline of arch draft Michael: we will have a new one in December # YANG Module, Henk Birkholz (20 minutes) Michael: Is there any relation between the EAT part yang model and the rest yang model? Henk: Not yet. For now, the EAT part can only include what defined in the EAT draft. Laurence: ok with defining the EAT part yang model, one suggestion: input is lack of the identity info to tell the device which EAT the verifier needs Henk: You can file an issue about this. Dave: How does the verifier know whether it should call the yang function or eat function? How does the Verifier know the Attester is TPM-based or EAT-based? Shwetha from Jabber: One way is to use other YANG models to figure out whether the device supports TPM or EAT. The other way is to separate the TPM-based attestation and the EAT-based attestation into two YANG models. Henk: Can use the 'feature' function provided by YANG. Dave: How to know the address of the device to query? This is related to the whole workflow, maybe the RIV people should consider this. Dave: what's your consideration to include other formats (e.g., eat) in your current yang model? Henk: we think we can deal with it. Chair: ask the WG hum for adopting this draft.     Many hums both in the meeting room and Jabber Chair: ask the WG hum for not adopting this draft.     Silence from WG: the WG agrees with adopting this draft based on hum. Chair: will still bring it to the mailing list for the formal process # New Drafts: RATS pub/sub model, Liang Xia (10 minutes)      https://tools.ietf.org/id/draft-xia-rats-pubsub-model-01.txt Dave: don't understand the counter for freshness check, timestamp can work. Is it possible to be part of the current yang model draft? Henk: you are right, they are similar and have the same basis. Dave: Consider whether to pull this into the yang model draft. The freshness issue should be considered by using TUDA or timestamp or other RPCs. Henk: Creating a YANG model for TUDA is easy. TUDA work can be started again. Michael: We agree that we need to solve the nonce problem for RATS pub/sub solution. Chair: please provide your feedback about how to process this draft together with the current yang model draft to the mailing list. Milestones, Summary of Calls for Adoption (5 minutes)   - YANG Module draft   - RIV draft Open Mic (10 minutes)  Two virtual interim: TEEP TEEP was planning to have interim during the hackathon in Feb. Jabber: xmpp:rats@jabber.ietf.org?join MeetEcho: https://www.meetecho.com/ietf106/rats Etherpad: https://etherpad.ietf.org/p/notes-ietf-106-rats