Minutes interim-2019-rats-02: Tue 07:00
minutes-interim-2019-rats-02-201909100700-00

RATS Interim - September 10, 2019
Chairs: Nancy Cam-Winget, Ned Smith, and Kathleen Moriarty
AD: Roman Danyliw
Note-takers: Kathleen Moriarty with some minor help from Rich Salz

MATERIALS: https://datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-chair-slides
https://datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment

WEBEX:
    JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=mefed41895b6dc942bf92a1b4c121d907
Meeting number (access code): 646 390 311
Meeting password: hPrEtxQc
JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)

Notewell noted.

Objective: Alignment on use cases to set requirements for RATS, joint meeting
with TEEP to help accomplish this task.

Presentation: TEEP and RATS Alignment
by: Dave Thaler
https://datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment.pdfA

Began with TEEP background as an introduction.
3 main use cases, one showed (the expected most important one), plus IoT and a
cloud use case. App to be run in a TEE of a device use case covered. TEE trusts
the Trusted App Manager (TAM) Normal app has a dependency on the Trusted app
that runs in the TEE Line 4 is the in-scope of TEEP; sometimes called the Open
Trust Protocol (OTrP) OTRP session terminates inside the TEE - TEEP specified
the OTrP, not the session to the broker. Slide 6 OTrP (from client) has to
reach out to the TAM first, passes through the new rish app pon way back to
client line 5,6 on p 6 are the green line on p4.  line 6 on pg6 was created
before RATS existed, is probably the "integration point" of the two WG's Slide
9 - relationship to RATS Aligning RATS avoids duplication, having RATS handle
the attestation part and TEEP handles the compliance aspect (protocol -
remediation, verification, install data/code to bring it into compliance etc.)
OTrPv1 is pre-RATS, OTrPv2 handles the interdependence - decided at IETF 105
Slide 10 2 ways to use RATS Verifying Relying Party (RP) model, model for
device state (RP in this case is the TAM) Attester is the TEE - in the device
state/background check model, RP is in the middle of the communication., in the
other, the Attester is in the middle. Option 2 & 3 are preferred by TEEP WG
(slide Chained Roles 14 & 15) Hybrid models are possible (slide 16) TEEP will
define the claims that they will expect.

Questions/Discussion:
  Ned Smith:   Were we looking to the use cases to define the set of claims -
  Nancy & Dave: Yes, we think so
  Some claims will be use case independent.  Some will have mandatory and
  optional claims that are use case specific. Vendor specific claims - do they
  need to be in a registry? (Bunch of discussion) Then slide shown - register
  under expert review - Could have some vendor ones not in the registry
  (different options shown) Slide: slides-105-rats-sessa-eat-claims-00.pdf page
  8 JWT needs a specification to be registered, CWT does not (yet) OID gets rid
  of this problem since the owner can delegate on their branch. Avoid different
  answers for different rows is desired (Russ Housley) Avoid unregistered
  entirely - agreed (Laurence & Russ) *Agree to revise registry rules to
  include proposed rules changes How TEEP moves forward with registry rules on
  vandor specific: To provide out specifics for RATS once agreed based on this
  discussion. Ned Smith with Dave Thaler + Henk Birkholz to volunteer for this
  task for RATS proposal for TEEP to use this and follow the right rules.
  Problem is just for the unregistered to avoid collisions (vendor specific for
  example)

Information Model Presentation/Discussion
  Laurence Lundblade
 4 information models presented out of last meeting results
 - detailed on slide
 Dave Thaler - good list, point 3 is orthogonal as it's additive into the others
 Laurence thinks they all are.
 Dave 1& 2 appear disjoint - 1st doesn't require all, 2nd does
 Nancy - concepts you want in the design - 3 could be additive, but could be
 distinct, more complex and nested needs to be accounted for Henk - 3 is
 already covered in 2, allowing for nesting and complexity
Laurence - covered in next slide and thinks all are orthogonal and independent
Would like 1 information model for all of RATS
Henk says the WG would never be finished if we did that, but should just allow
for extensibility instead and Dave Thaler agrees Dave likes concept #2 - can't
have a single document that covers all - does not work. Simon Frost: I was
trying to make the distinction for having a single information model for all
+standard+ claims (with respect to previous conversation, then the model for
how custom claims are expressed Eric Voit - would like to match possibilities
to use cases to look at more complex scenarios.  It would be good to just nail
down the types of information flowing before trying to assert we know all the
combinatorics of objects being sent. Who signs what, was not clear from Dave's
presentation and that should be identified int he information model to
represent those answers Dave Thaler: TEE signs evidence and Eric Voit:
Supervisor signing nested stuff is complex and will not be nailed down soon
Henk - who is creating each signature and why needs to be defined Dave: Teep
uses it when evidence is coming from a cert chain - claims on secure firmware
Laurence: 3& 4 are givens, we need to do these and there was a lot of
discussion in the meetings Thomas Hardjono - 1 information model; multiple
data-models (per use case); multiple claims formats. Simon Frost - Who signs
what is a matter for verification policy rather than information model

Laurence: Thinks there's consensus on 1 and hopes there is for 3&4
Dave: Other WGs that will create claims for their own use cases
1 information model for the core claims, does not include convenience protocols
and can be int he definitions of the claims Giri - agrees with Laurence -
whether an EAT can carry an attesttation, merger of 2 information models and
trying to cover both in one - may not be of benefit

Ned: Is this the right list?  Does wording need to be improved?  #2 - do we
need to remove the word "all" Nancy - some hybrid of the 4 possibly Henk -
types of information, then the specifications then the solutions Laurence
- Claims should all be in one place - Ned: except some WGs may have their own
claims so this doesn't quite work Nancy - claims could be one to many - seems
to have agreement on this

Ned had some good suggestions summarizing - sets of claims and signers that we
don't understand quite well and deserved it's own attention - maybe these 3
things are separable Set of claims, signers, protocols Claims versus assertions
not even discussed yet.

Architecture draft has been updated - reviews requested to see if we can use
this for the architecture model (not yet adopted)

Next interim Oct 8