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)
           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