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