Minutes IETF104: rats
minutes-104-rats-00

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