Minutes interim-2020-rats-05: Tue 11:00
minutes-interim-2020-rats-05-202004281100-00

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.