RATS - IETF 104 WG 
Thursday 28-Mar-2019, 

Chairs    
• Kathleen Moriarty (CM)
• Nancy Cam-Winget (NC)
• Ned Smith (NS)
Area Director 
• Roman Danyliw (RD)

RATS Charter overview/milestones – Chairs
• NS: Charter Overview / Goals / Out-of-scope 
• NS: Program of Work
o Correction to the slide:Standardize bindings to protocols rather than protocols
• NC: Milestones proposal

Use Cases (draft-richardson-rats-usecases) – Michael Richardson (MR)
• Slide 2: not intended to be published as an RFC
• Slide 3: Relevant docs from TCG, FIDO, Android Keystore
o Recent news that Android now supports something TPM-like.
• Dave Thaler (DT): TCG use case - (enterprise) Device Operator has a use case as someone different than the operator of the network
o (Bring your own device use case)
• Frank Xia (FX) - Wants the use case (from TCG) about attesting to the state of network devices / endpoints
• Jessica Fitzgerald-McKay (JF) - Use Case info from TCG proprietary document exists - 
o Action item Jessica to place snippet of use case for network devices document into the RATS WG mail list
• Hannes T. (HT): Change name of document from Use Case to something else (Guidelines?)
o MR: It is the document which needs to be improved so it fills the stated role.  
o MR: Document also should cover the domain specific terminology which allows the use case to be mapped to RATS terms

Architecture (draft-birkholz-rats-architecture) – Henk Birkholz (HB)
• Recap of deltas from IETF 103
• Architecture Principles
• Evolution of Arch slides - Actors, Roles, Composability
• Out-of-scope slides
o Is actually red circles rather than triangle.  The document needs to do this better than currently documented
• Relationship/overlap to other architectures described at a high level
o SACM, SUIT, TEEP, NETCONF, Global Platform, FIDO, TCG
o RATS needs a consensus on a core vocabulary to allow integration with other entities
• Avoid use of the word 'claim', assertions is the proposed alternative
• Giri Mandyam (GM) - 1b. & 2 interface is a B2B interface, there is a desire to discuss the desired operational mechanisms, 
o Action Item: FIDO alliance paper, will be posted to the list
• Stephen Banghart (SB),  from Jabber for Carl Wallace
o What is TAMP?   It is about provisioning the TPM
• DT -  Which lines on scoping slide could be packaged with (CWT?)
o HB: potentially all of them

Reference Interaction Model (draft-birkholz-rats-reference-interaction-model) – Henk Birkholz 
• Intended to stop replication of key interaction models so that they can be referenced elsewhere.
• Roman Danyliw -  why is this protocol the first one to do?
o HB: because there is a YANG model coming up that needs this

YANG model (draft-birkholz-rats-basic-yang-module) – Henk Birkholz
• Encoding remote attestation procedures via YANG is proposed
• Includes the carrying of the Nonce as part of challenge / response

TUDA (draft-birkholz-rats-tuda) – Henk Birkholz
• Nonceless variation to attestation, using trusted external time source (RFC 3161)
• Aligns timestamps between attestor and TSA.
• Works on CBOR array
• Technical content is accurate, but could be made clearer in future iterations.
• Needs to align to whatever new terminology we create for RATS

• NC: what. is a stable &. mature document?
o HB: they have multiple implementations by companies with running code
• Dave Waltermire. (DW):  looks like there is already a lot of work done here, what else needs to be done? / How can we help?
o HB: understand YANG models, understand your use cases, speak up to ensure coverage.
o HB: there might be other uses for TUDA - perhaps pushing data externally.   What capabilities would you like to see?
o HB: Also don't think about too much about TUDA.  Let's focus on the Architecture
• RD:  struggling with sequencing, don't have architecture, but have a lot of pieces that plug in; that doesn't seem to make sense
o HB: We need to define terms before we have a document which uses these terms.   Cross mapping still needs to be done.   
o RD: would be interested to see if WG agrees with multiple items here as a starting point
o NC: need to define arch, info model, data model.  But a lot of work on interfaces it seems
o HB: We are not  in any way ready for WGLC
o SB: where does TUDA fit in within the overall arch.
• HB: communicates between Attester and Verifier directly, but no line is there
• HB: this is a composability feature (apparently which is not on the WG scoping slide)
o RD:  an interim is a fabulous idea
• Action Item: Working Group Interim to be set


Token Bind Attestation (draft-mandyam-tokbind-attest) – Giri Mandyam (GM)
• Keys in user space (including browsers) are at risk.  This can impact the trustworthiness of TLS token binding
• Defines "signing process" - what can the browser delegate to secure elements
o Can you tell if the remote device is using secure elements, and alter your behaviour as necessary?  Suspect Yes.
• Performance considerations are essenital to conisder for networked interactions (i.e., browsers fast enough?)
o Tokbind impact
• Issue without this draft is that relying party doesn't have tokbind private key trustability
• Recommend that RATS adopts tokbind
• HB: following work, in favor of attestation format meta-header which is extensible.  Unsure of overhead impacts.
o GM: Browser vendors wants the ability not to have any attestation at all when the relying party doesn't want it (i.e., don't give me private info)

EAT (draft-mandyam-rats-eat) – Laurence Lundblade (LL)
• Entity Attestation Token (EAT) collects claims which is sent to the relying party
• EAT overall system slide has reasonable alignment with that in Henk's architecure doc
• EAT Format COSE_Sign1
• Many algorithms supported (RSA, ECDSA, ECDAA, HMAC, other)
• Privacy implications varies by use case (i.e., EAT does not drive a specific privacy model)
o Can omit privacy infringing claims
• There is a suggested starting point for initial claims propsed in slide 8
• Robin Wilton (RW) - I get uneasy where privacy is tracable to a device when there are a limited number of instances which can be matched to the identity which is actually exposed 
o LL: didn't mean to imply that
• Brendan Warren (BW)  - Object to the assertion that single use IoT devices have simpler privacy implications


Claims Definition/Information Model – Laurence Lundblade 
• RD: Charter doesn't say that IM & DM don't have to be separate docs,and can define additional DM's
o LL: Lets put it one document, we can always pull it out if necessary
• Anthony - are you considering encyption as part of signing, and JWT style claims
o LL: absolutely, if we get there, we would be using JWT and we will be doing encryption
• LL: Primary objective of these documents is semantic interoperability of Claims 
o List of areas of claim definition, and to which entities where claims should be applicable
• A subset of potential claims listed
o Nonce
o Universal Entity ID (UEID)
• BW - was there anything missing from RFC 4122?  
• LL: No
• Kathleen Moriarty (KM): What are the privacy implications of device identification
• BW: when starting from RFC4122, use something derived from Domain Name in SUIT
o Boot & Debug State

Program of Work
• Ned Smith (NS): this EAT work hits at the heart of the problem for information models
o Mapping information models from other standards groups is an option for this WG.  
o Also viable is a semantic interoperation to allow structures to interoperate.  
• GM: did early evaluations of TPM model for early IM evaluation, decided it was better not to reproduce that
o We should be looking to augment the existing attestation ecosystems/infrastructure
• LL: To Ned's point, there are pre-existing things where it will be easy to reference
o The hard work is an information model worthwhile to the relying party.   
o We need useful claims to accomplish this.
• NC : What you are proposing LL is for the group to create standard set of universal claims,  maybe useful with an IANA registry, widest audience possible to receive claims; vendors are always going to make up/add more
o LL: claims bundled in token, and then transport and security, apis, transport, etc. are orthogonal to the claim semantics
o NC: this means they can be carried through a set of hops and be safely interpreted.
o HB: fine with defining a lot of universal claims; but not sure if SWIDs or manifests can be in the claim, it would be to big;   also, integrity measurement system (IMA) might be to big/complicated to be in claims
• NC: LL had this covered, including via the nesting of claims
• HH If they were nested, perhaps they are not claims
• Fundamental assumption about privacy and security
o BM: Is there a single verifier?   HB: Answer: No
• HT: Can we spend time to define the semantics of claims?  That would be useful.  Perhaps this doesn't need to be in a single document
o NC: we haven't defined document list, this is too early to worry about
• DW: instead of defining a standard set of claims, a method about how to standardize claims; an IANA registry and ability to segment those
• LL: Back to HB question on "What is a claim, what is not a claim".  If it is included in the token, it is a claim.
o There are examples of software claims which are reasonable and minimal
• NS: Manifest is something we should start with as part of RATS.
o Questions exist like should be nest claims?  SUIT already does stuff like this.  Do we also cover?
o NC: Do we build a tight coupling with SUIT?
o NS: Complexity reflected in manifests already exist.  We shouldn't try to minimize this reality..  And it needs to be covered first
• Is rfc 8225 relevant


• Who has read various drafts
o lots (EAT),  lots (token bind), lots, a bit fewer (YANG model), and fewer still.  (TUDA) :)
• Who wants specific drafts adopted (based on people raising their hand)
o EAT - 9 in favor, nobody against
• worth taking to the list for a vote
• FX: does it have the right pre-requisites?   (NC: to be determined on the list)
o Tokkbind - 8 in favor. Nobody objects to bring this to a vote. 8 in favor, taking it to the list 

NC: Interim - look for April as the proposed date for this.


AOB