Minutes interim-2020-rats-04: Tue 07:30
minutes-interim-2020-rats-04-202003310730-00

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:
<attestation> 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.