RATS - Remote ATtestation ProcedureS Virtual Interim Meeting 2020-03-31 (14:30 to 16:30 UTC) Jabber: rats@jabber.ietf.org Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-rats-vi-2020-03-31 webex: https://ietf.webex.com/ietf/j.php?MTID=md817829672f3fe426f810053f00221f6 NOT: https://ietf.webex.com/ietf/j.php?MTID=md780f1aa53bfc0bf5eba5c1de9c9c3c7 Notetakers: Thomas Fossati and Michael Richardson Chair slides:https://datatracker.ietf.org/meeting/interim-2020-rats-04/materials/slides-interim-2020-rats-04-sessa-chair-slides Agenda Bash (5min) Architecture – Michael (30min) https://tools.ietf.org/html/draft-ietf-rats-architecture-02 slides: https://datatracker.ietf.org/meeting/interim-2020-rats-04/materials/slides-interim-2020-rats-04-sessa-rats-architecture-final-2 MCR goes through the slide deck: TOC should be in crisp state at this stage closed issues since last meeting: intro done, terminology nearly complete conceptual data flow: added "endorsements" and "appraisal policy", not necessarily in scope with the current charter, but important to have in order to understand the flow types of environement: target and attesting, some times overlapping. the verifier is the ultimate decider in terms of trustworthiness. layered attestation, modelled around the boot chain composite device: a complex device where multiple attesters exist, one of which is the "lead" with direct connection with the verifier topology models: passport and background check already discussed in previous meetings encoding formats: goal is interop between parties. the assumption we are making is the constrained side (typically the attester) is going to use one single format. similarly the RP is going to use one format. (the negotiation of such format is not in scope with the architecture doc. the protocol document will have to provide that information.) the verifier might need to accept multiple formats. Question/Discussion none EAT Claim characteristics and IANA – Laurence (15min) https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ slides: https://datatracker.ietf.org/meeting/interim-2020-rats-04/materials/slides-interim-2020-rats-04-sessa-eat-claims-characteristics Laurence goes through the slide deck slide 1: guidelines for creating claims slide 2: use separate docs, i.e., profiles, for specific use cases. question is where do these claims go? Dave: re: slide 1. another characteristic is: how I design claims that are multi-valued? in TEEP we have TAs that are installed or list of TAs that I need that are not yet installed. Both are lists of TAs. Need guidance around how to format, how to interpret, etc. Roman Danyliw: where do you put this text? irrespective, it needs to be consistent with the policy of the CWT registry; perhaps profile language could describe which collection of claims should be used for a given use case. Henk: need to distinguish between claims for evidence and claims for attestation result. Jim: the guidance in slides 1/2 are not necessarily appropriate for CWT. recommendation: register RATS claims in a RATS subregistry of CWT registry. they are separate namespaces and can be clearly identified as such. Laurence: unsure how to proceed. Henk: we don't want to register the claim in two different registries. Carsten suggested adding a column to the CWT registry that flags a claim as being used for remote attestation. Dave Thaler: in Jim proposal what goes in the RATS claims map is only coming from the RATS subregistry. Any claim reused from CWT proper would go in a separate map. Henk: it's complex Carsten: example: cwt = {iss: "foo", nbf: "4711", rats: { ratsclaim1: "foo", clatsraim2: "bar"}} you have to define the interaction between the claims in any case, independently of how you register them and how the nesting occurs. Laurence: thanks for the comments, I'll think about it and make proposals (11:20:37 AM) mcr: jimsch1, so, in our EAT document, we would need ask for "rats:" as a claim from CWT. (11:20:57 AM) mcr: would we need to create our own registry? (11:21:06 AM) Carsten Bormann: If nested, yes. (11:21:09 AM) Carsten Bormann: (Or a subreg) (11:21:16 AM) Dave Thaler: right that is Jim's proposal (11:21:21 AM) jimsch1: The big win - you get more small values for keys!!!!! (11:18:58 AM) mcr: Thomas Hardjono asks in webex: Can vendors claim their own sub-registry? (own namespace) (11:19:31 AM) jimsch1: @Thomas - THere is a private namespace in CWT so that would be doable (if memory serves) RATS Timing definitions across use cases – Eric Voit (15min) https://github.com/ietf-rats-wg/architecture/pull/75/files slides: https://datatracker.ietf.org/meeting/interim-2020-rats-04/materials/slides-interim-2020-rats-04-sessa-timing-definitions-and-data-flow Eric goes through the slides deck potential claims associated with timing events; helpful to reason about similarities between use cases. the suggested place for this is the architecture document. slide 1: a table with 9 events associated with the attestation flow. any initial question? Dave: clarification: there is a 10th in the PR: "result relayed", which could end up in a claim or not depending on protocol. Henk: there should be informative guidance in the architecture doc about these slide 2: example of precise events in a nonce based background check. applies to draft-fedorkov-rats-network-device-attestation. Dave: time(rx) is not known by the RP unless the parties are time synchronised. The PR (https://github.com/ietf-rats-wg/architecture/pull/75/files), in particular the nonce based bg check part, has more precise description, please look at that. slide 3: another example. this one is about composite evidence and applies to draft-voit-rats-trusted-path-routing. shows there's actual similarity between use cases Henk: another frame of reference: freshness v recentness Dave: (response to Henk) Section 9 of the architecture has some discussion about that slide 4: enhanced table with 4 new event types. if you have other event types now is the time to propose them. EAT timestamps and expiration discussion - Laurence (20min) slides: https://datatracker.ietf.org/meeting/interim-2020-rats-04/materials/slides-interim-2020-rats-04-sessa-timestamps-in-eat Laurence goes through the slides deck: Value generation. how to deal with situations when the claim is collected long before attestation. every claim that can be generated out-of-sync wrt the attestation report could have an "age" / "timestamp" associated to it. Dave: do we think it'll always be the case that when someone defines a claim he/she knows whether it needs a timestamp or not? Laurence: this is a key question. for most of existing claims this is quite clear. Ned: the policy decides whether a freshness indicator is needed or not. how to communicate this policy to the attester should also be discussed. it is not currently discussed. Laurence: still we need a way to convey from attester to RP / verifier the age/timestamp if required. Dave: we have other "claim-about-a-claim" type claims. timestamp is not the only one. we need a generic mechanism for handling this. Timestamp or age? depends on clock availability timestamp is preferred if clock available age only if you can't do better Dave: another possibility is deltas between events. they could be expressed as difference of two age claims, or as a single delta claim, which is obviously more compact. are there enough use cases to motivate the latter? Nonce: no need to record the time of nonce Token / Evidence Creation: use iat from CWT/JWT (as absolute time). a device without clock will just not add this claim. Henk: in TUDA, age doesn't exist as a separate claim: there is a separate synchronisation channel where "age" is conveyed Laurence: in TUDA you always know what time is it, so you'd never use an "age"? RP and verifier want to know when a token has been created as an absolute time. Dave: no objections for an age claim though I think we need a more general solution. Results creation, trouble duplicating the iat key at the same level. possible alternatives: add the whole evidence to the result define a new "results issued at" (riat) claim to differentiate the verifier's iat from the attester's Dave: it should be up to a profile to decide whether the verbatim embedding of evidence in a result is OK, but it should not be mandated by EAT. don't force complexity on the entities if not needed/wanted. Trusted Path Routing – Eric (5 min) https://datatracker.ietf.org/doc/draft-voit-rats-trusted-path-routing/ slides: https://datatracker.ietf.org/meeting/interim-2020-rats-04/materials/slides-interim-2020-rats-04-sessa-rats-trusted-path-routing Eric goes through the slides slide 1: use case is "sensitive" network flows that want to go through trustworthy network paths only slide 2: centralised architecture using background check topological model slide 3: distributed model, network nodes decide about the trustworthiness of their peers slide 4: element 1: event stream based on draft-yang-tpm-charra slide 5: element 2: "levels of trustworthiness" claims slide 6: element 3: "composite evidence" (cfr. passport model as currently defined) Dave: are these (slide 6) composite evidence that needs to be signed as a single blob or independent pieces of evidence? Eric: the latter Laurence: a passport has been signed by a verifier and the holder of the passport doesn't modify it. Eric: another way to look at this is that it's a living document which is updated (stamps are added) when you cross a border Nancy: itshould that be captured in the architecture document Request to the group: review and comment the draft, in particular: composite evidence importance (passport is not applicable here as currently defined -- i.e. not modifiable) level of trustworthiness: are these reusable in other use cases? RATs PubSub – Wei Pan (5 min) https://datatracker.ietf.org/doc/draft-xia-rats-pubsub-model/ slides: https://datatracker.ietf.org/meeting/interim-2020-rats-04/materials/slides-interim-2020-rats-04-sessa-rats-pubsub-model Wei goes through the slides: draft has been updated since last meeting (not a big update though) slide 1: want to use NETCONF pub/sub where a verifier subscribes attestation events from an attester. ideal for cases where attestation is needed on state update. slide 2: support TPM-based network devices. for freshness, reuse analysis done in draft-trusted-path-routing. Dave: in the sequence diagram: how do the verifier knows when an attester is ready for receiving the subscription? Eric: the underlying transport will partly solve this problem. Dave: recollection from past conversation (which is not captured in written text): when the network gear reboots, it will reach out to the verifier if a subscription had been previously established. Next step: update draft Please provide reviews and comments Nancy: next meeting 28th April 7am pacific time.