RATs Virtual Interim April 28, 2020 1.Agenda Bash (5min) 2.Network Device Attestation - Guy Fedorkow and Eric Voit (20min) •https://datatracker.ietf.org/doc/draft-fedorkow-rats-network-device-attestation/ The goal is to standardize operational model for TPM-based routers and switches.  Today proprietary techniques are used.  This approach enables appraisal by non-proprietary controllers and verifiers. LL: Example for higher-level claim? EV: GPS coordinates; infrastructure is intact; if that is being used to further makes claims what is going on in the network, [that is the basis] Ian Oliver: ARM devices follow a different flow; will this draft include ARMs flow and semantics - followup: should IETF at least document the various cases for the semantics of PCRs in TPM (or similar measurement/claim mechanisms, cf: TCG x86 boot specification) Way forward? • Option 1: Separate use case context + profile draft • Option 2: Integrate into draft-ietf-rats-yang-tpm-charra G Fedorkow: EAT is candidate to go into the document Dave Thaler: Term RIV specific to TPMs? Can it apply to other network devices? GF: We could go through specific requirements.  In this document, it's TPM, as document is not completely generalized. GF: In the long term, the term "RIV" should not require TPM, other trusted attesters should be accomodated too, but this document is TPM-specific. IO: What makes this router specific? GF: YANG EV: Some router vendors include a key preprovisioned that uniquely identify the device; can make some simplifying assumptions based on that IO: Provisiong process might go deeply into supply chain. GF: Easier to do zero-touch provisioning if the device ships with identity programmed into it. LL: Provisioning the key == there was touch  (BY THE MANUFACTURER/OEM) GF: trying to avoid everybody except manufacturer to touch. GF: In PC-Land, there has to be a provisioning step (a touch by the IT department of the buyer) after manufacturing and before using. Chair Q: Is the content useful in RATS?  (No one objected.) Chair Q: Should the WG adopt this TPM-specific draft?  (No one objected.) Daniel Migault is not objecting and would like to contribute to a version that supports different TEEs. 3.Interaction Model – Henk Birkholz (10min) •https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/ Implementation: https://github.com/Fraunhofer-SIT/charra to show that interaction models work There are at least three interaction models: CHARRA, TUDA (Time-based Uni-Directional Attestation), and Pub/Sub.  Do we put them all in one informational document? Dave Thaler: Right question, break it into two:     (1) where do interaction model go, is it normative/informative?     (2) where should general information go? vs. specific stuff -- option 4      LL: How would this cover interaction with android attestation, EAT based attestation or FIDO; RATS interaction model needs to cover all of these things. HB: Intent is, agnostic, not specific to solution. MCR: 1 is dumb, 2 or 3 not sure which is better, 4 if someone comes with an interaction model we hadn't thought about. Could be that option 4 is what we should do, until we have more than 1 solution that have similar models they can be refactored into a single document. Ned: architecture tries to define a set of roles and deployments can differ but canonical relationship persist. Does same logic apply to interaction models? Are there exemplary type expressions that go thru a layer of adaptation to apply them to a realworld deployment?     HB: Good point. Today’s model focuses on conveyance of evidence. 4.CHARRA Update – Henk Birkholz (10min) •https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/ No discussion 5.RATs with MUD – Henk Birkholz (10min) •https://datatracker.ietf.org/doc/draft-birkholz-rats-mud/ Discovering the resources that a rats role is depending on. RFC 8520 MUD file can have useful things in it; endorsing roots of trust -- find source;  NS: (1) Service -- who hosts the MUD file? (2) discovery -- point to endorsement services HB: Can be local ones or ones provided by the vendor.  It needs to be tied to the LDevID or IDevID. DT: Replace RIM with reference values. Question: seccons largely vacant; how to ensure correct MUD file with correct content -- please put into next version. HB: Right! LL in Webex Chat: MUD just provides a list of candidate verifiers. Relying Party must decide based on out of band data. I doubt we want MUD to be used to establish trust in Verifiers. HB: (Acknowleged) 6.COSWID for RATs – Henk Birkholz (10min) •https://datatracker.ietf.org/doc/draft-birkholz-rats-coswid-rim/ HB: s/RIM/Reference Values/, want to do this with COSWID being finished in SACM Asked for review and comment. 7.EAT Endorsement – Henk Birkholz (10min) •https://datatracker.ietf.org/doc/draft-birkholz-rats-endorsement-eat/ Ned: is there a bright line between endorsement and attester claims, or are they all claims that just need to fulfill specific requirements to be useful for either HB: Encoding is EAT specific; it is not evidence, so it is an endorsement LL: Debug state seems to be both evidence and endorsement -- no bright line between them Asked for review and comment. 8.RATs Unprotected CWT Tokens – Henk Birkholz (10min) •https://datatracker.ietf.org/doc/draft-birkholz-rats-uccs/ Some usage scenarios (some of which are currently specified by Global Platform) there exists a high level of assurance regarding the trustworthiness of a communication channel (called a "Secure Channel") between two RATS roles. NS: ... HB: scope is intended to cover all use cases, even local buses NS: Is this specific to UCCS, or can it be unsigned COSWID or whatever HB: Unsigned COSWIDs are already allowed.  So UCCS is not about that. LL: Discussion should be on RATS and ACE mailing lists. HB: -00 is EAT-agnostic LL: Right thing to do. HB: Can we keep this up with nested EATs, ...? HB: So far, discussion has just been the authors.  Will bring to the appropriate IETF mail list(s) in a few weeks (ACE, RATS, ...?). NS: Need clarity on the sematics of a signature Carsten: Docment has three parts: (1) defines UCCS and (2) the security considerations with RATS; probably needs to say (3) any other use of UCCS needs similar security considerations to be written up Roman Danyliw:      Needs strong language about applicability Closing remarks by AD to ensure that documents not adopted yet are within scope; if not, we need to discuss for consideration on scope and charter.