Minutes IETF105: rats
minutes-105-rats-00

Remote ATtestation ProcedureS (RATS) WG
IET 105, Wednesday, July 24, 2019
15:50 – 16:50, Van Horne
Chairs: Kathleen Moriarty, Nancy Cam-Winget, Ned Smith

Notetakers:
Robin Wilton
Chris Inacio
Michael Richardson
Carsten Bormann

Milestones and admin: Chairs will update the milestones for missed deadlines.

Use Cases (draft-richardson-rats-usecases) – Michael Richardson
draft-richardson-rats-usecases-04
NOTE: Not intended for publication as an RFC, (because it's a use case
document); up to others to publish as an appendix of some other doc if they see
fit.

MCR: Are the examples too detailed?
Roman Danyliw: Those entities (Trusted Computing GRoup, FIDO, Android
Keystore) expressed interest to use this, by that does it mean use case
document or protocol MCR: They provided use cases, they're interested in the
protocols;  but they really want standardized ways of using the claims MCR: Was
surprised that the charter wants a protocol, thought we were only going to do a
claims format only.

Roman (as AD): if one of the potential implementers says the use cases would be
important, that might change the view of how/whether to publish them. Nancy
(chair): at Virtual Interim (VI) the group decided to table conversation about
publishing the use cases Frank (Liang) Xia: Can include network virtualization
(something) as part of this? MCR: post to the list, not sure if it would be
worth including here MCR: Wallace's additions were just sucked into the
document, but may not stay, lots more detail than needed

Frank (Liang) Xia: Raising this because virtualized network use case gives rise
to specific requirements in this area and merits further discussion MCR: wants
to ensure its also being discussed on the mail list to ensure that everyone is
aligned

Not a lot of people in the room have read the document. (A scant handful?4-5)

Eric Voit: network-based attestations don't seem to appear in the use-case
document - will they be incorporated along with other stated requirements? MCR:
yes, they're coming in recently; side meeting on Thursday, 8:30am Coller Room
to talk about them, want to get the right text out of the submissions into the
use case document

Robin Wilton: Are you open to the idea that there might be multiple attesting
parties and relying parties in a single use case? MCR: yes, might be multiple
on either side MCR: might be a peer-to-peer type use case and could be the
relying party is a 3rd party

EAT (draft-ietf-rats-eat-01) – Laurence Lundblade
draft-ietf-rats-eat-01 https://github.com/ietf-rats-wg/eat/issues

Mike Jones: Think we're already aligned; wanted to make sure any claims
included were justified by a known use case - with the option of a registry for
claims people wanted to add later. Henk Birkholz: So we're doing it right? Mike
Jones: I think so

Issue #23 - claims optionality;
Henk Birkholz: Should profiles be able to override?
LL: Yes, that's what the propsoed text allows for
Mike Jones: You're doing it right.
MCR: Suggested: "profiles MUST override this" - because the whole point of the
profile is to specify which claims are in valid use and which aren't. Otherwise
it isn't a profile. LL: delete all the current text and let the inherited text
for CWT/JWT govern ==> Otherwise, no objections apparent

Issue #21 and #12 - Random UEIDs
"Is the 128-bit minimum UEID length sufficient to mitigate the riskof
collisions? Stuart Cheshire: don't know whether 128 bits is or isn't enough,
but this is probably vulnerable to the birthday problem. (Carsten returns to
seat ;^)  ) Bob Moskowitz: can give formula and population size spreadsheet
that will tell you the actual probability of a collision LL: so I'm clearly not
doing it right Stephen Banghart: Is this UEID different than a UUID? LL: Yes, I
didn't like the UUID complexity; so I did this because its simpler SB: you will
probably find that using UUID's have solved this and done the math to make this
work

Dave Waltermire: think the reference here is to type 4 EUIDs, which include
e,g. system clock input as seeds to randomness Chair: This is a WG document, so
the WG can decide.  RFC4122 is the reference for UUID generation.

Giri Mandyam: have use-cases where we'd like to see an attestation generated
*in a deterministic way*, so this isn't just about randomness, as a design
point. GM: Issue is already in GitHub Chair: put the use case in GitHub

Issues #19 and #24:
Henk Birkholz: strengthening key protection requriements makes sense, because
trustworthiness of the resulting attestations is highly important LL: in the
EAT draft, we're not going to talk about it HB: In my opinion you should
discuss the key signing material security LL: Doesn't seem like it needs to go
into the EAT draft HB: Ah, so a draft that *uses* EAT would specify this and
then use EAT for the rest...? Might need profiling. LL: Sounds good that it
would be in profiles

GM: ephermeral keys shouldn't be used for signing unless they're attested
Top level of tokens should have some level of assurance about the keys used.

Dave Thaler: Disagree with Giri and agree it should be moved to profile
documentation - reqt is for key material that is trusted by the receiver of the
EAT - which is not necessarily the manufacturer. PRofiling would make the
specification more generally applicable. Adam Whitacker: Agree with current
text here; should be in the profile documents.  But that seems like we're
punting on this, and then its turtles the whole way down.

GM: Could we mention this in Security Considerations and move it into profiles?
DT: issue arises from trying to constrain the document to "key material
provided by the manufacturer"... because the key material can legitimately come
from elsewhere. LL: will take a shot at putting those concerns in the security
considerations

Issue #18 - Verification Procedures
Suggestion is that verification procedures be added to the EAT document; LL
view is that EAT inherist from JWT and CWT, so shouldn't also be needed in the
EAT document.

Henk Birkholz: for the RATS end-to-end verification, is that the evidence
attestation LL: Yes, there is a verifier in the model, so that its about that

GM: I filed this issue; the slide doesn't quite reflect the proposal, which was
that although there's a lot of inheritance, it's easier for a reader to
understand if the verification procedures are described in the same doc. LL:
CWT/JWT don't say anything about validating the claims themselves, only the
envelope.  And EAT shouldn't change from that. GM: rough agreement with that

Tony Nadalin: "Presenter" (as opposed to Issuer) is not explicitly called out
in this description; they aren't necessarily the same. Mike Jones: e.g.
Security Event Token specification [RFC 8417] does make such a distinction.

https://tools.ietf.org/html/rfc8417 --- Security Event Token.

Issue #16 - Definition of "entity"
LL: intended to be open and somewhat ambiguous so as to not limit use. But
profiles can get very specific and limited. Robin Wilton:
Roger Clarke (Xamax) - defines "entity" as part of the taxonomy of identity,
naming, nymity etc.; won't necessarily change your definition, but worth
looking at for ideas/holstics: http://rogerclarke.com/ID/#EI

Dave Thaler: you're doing it right, RFC4133 (now RFC 6933), "Entity MIB" might
be handy to compare language in Tony Nadalin: ISO21995 is another reference
(mirror of RFC4133) but with a slightly different twist on entity

GM: Don't need to add any text about the registries for the CWT/JWT.

[not too many hands raised on number of people who've read document]
chairs: need to see more people have read the document

Chairs: tomorrow's session will give updates on a number of the milestone
drafts. ==>Any objections to dropping the Tokbind draft from the work items? No
objections in the room...

==>Any objection to droping *discussion of* TUDA from tomorrow's session?
Henk B: TUDA isn't ready yet, so OK to drop it from tomorrow's discussion

by request GitHub:
    https://github.com/ietf-rats-wg/eat

Remote ATtestation ProcedureS (RATS) WG
IETF 105, Thursday, July 25, 2019
15:50 – 17:20, Stainte-Catherine
Second Session
Chairs: Kathleen Moriarty, Nancy Cam-Winget, Ned Smith
Note takers: Shwetha Bhandari, Ryo Kajiwara, Michael Richardson, David M.
Wheeler

15:50 - 15:55 Agenda bash (5min)
No change in the agenda
MCR: side meeting on rats usecases - notes will be posted to the list
structural changes to the use case document, no recording

15:55 - 16:05 Architecture (draft-birkholz-rats-architecture) – Henk Birkholz
(10min) Henk
presenting https://datatracker.ietf.org/meeting/105/materials/slides-105-rats-sessb-rats-architecture-interaction-model-challange-response-yang-module-information-module-00
Architecture and terminology recap of last session actors • defined by
architecture document • device • resource manager • remote attestation service
• supply chain entity is out of scope roles • attester: prove its
trustworthiness by evidence • RP, verifier how TEEP as the first customer of
concepts defined in rats, sees rats roles • TA: attester • TAM: relying party
question: is this a good starting point to build a coherent architecture ->
call for adoption? Many in the room have read the draft Chairs: Can this draft
be adopted? Any objection for adopting it as workgroup draft.. •
Lawrence Lundblade: 3 concerns, against adoption • 1.there needs to be a root
of trust •   (the above #1 means) Attestations in the draft document require a
RoT (root of trust), and not all applications or sources of attestations will
have a ROT or be associated with a root of trust. This is a problem. •
3. document is unclear, hard to read
   4. we do not understand all the use cases and how they fit together
Tony Nadalin : against adoption, use case are in flux, the draft has to be
improved before adoption Henk: RoT is not mandatory in all use cases Katherine:
People opposing the adoption call please write detailed response to the mailing
list. With concerns, proposal to improve Nancy: Recommends to not serialize
perfection of usecases before adopting architecture draft. Continue to work on
solutions Lawrence: I want an architecture document, and this document is going
in the right direction Dave Thaler: mixed opinions • roles part is in a good
state, but other parts I didn't understand if they belong in the document or
not • Subset of the document seem to be clear and adoptable Nancy: Pose the
question on the mail list (Done with Architecture)

16:05 - 16:10 Reference Interaction Model
(draft-birkholz-rats-reference-interaction-model) – Henk Birkholz (5 min) (same
deck as above)

published as a separate document as above

state of document
• PoC available (empty repository as of now, will be filled in later)
No time for question, moving on to next topic

16:10 - 16:15 YANG model (draft-birkholz-rats-basic-yang-module) – Henk
Birkholz (5 min) (also same deck) Yang agents already exist - good to reuse
that More work is needed to add English text as well as security considerations
This is mostly complete and would like it to be adopted Requests for adoption
Nancy: Do you have feedback on the model? Henk: Yes Only one person has
reviewed it in the room. -> encourages people to read the document Get 3 people
to review and provide feedback in maillist - Thomas Hardjono, Wei Pan, Jessica
Fitzgerald-Mckay Feedback is needed before the interim meeting to determine
call for adoption

16:15 - 16:25 Information model (draft-birkholz-rats-information-model) – Henk
Birkholz (10 min) •
https://datatracker.ietf.org/doc/draft-birkholz-rats-information-model/

Need for information model is clear: different data models should interoperate
in concert An information model is needed to accomodate an interoperable format
becuase there will be different data models

SUITs has a suitable process to create information model, same can be done here
Process could follow using use cases to derive requirements and not just
collect a shopping list Dave Thaler: mostly agree. add on: it is more general
than suit. we do not have a one single use case. every use case can have their
own information model. document that describes how to come up with an
information model can be important Not convinced a common information model for
all use cases. Eric Voit:Likes the information model at a high level. If we go
down the path of information model for every use case we are probably heading
down a wrong creek. Kathleen M:Find a middle ground? start with profiles?
Henk: When do we have a minimal viable set that we can close the document with?

16:25 - 16:30 EAT and Information Model considerations – Laurence Lundblade
(5min)
https://datatracker.ietf.org/meeting/105/materials/slides-105-rats-sessb-eat-claims-00

draft update: describe each claim in text and CDDL(normative)
section 3: information model of each claim
• both information and data model
section 4: serialization
It is useful to separate the information model from the interaction model
yang document goes into an exchange

3 Boat Analogy
boat 1 - EATS claims
boat 2 - TPM - all a hash, yang based protocol to move attestation around
boat 3 - only X.509 similar to eats claims
Recommend: split Info Model around claims, and discuss how to serialize them
        separate Info Model for the interaction model (Yang)

16:30 - 16:55 Information Model discussion – all (25min)

Ned/Chairs - scope of the discussion - Information model discussion goals
(1) contents of the information model?
(2) what drafts to document them?
the charter says that we will standardize information model and a data model.
definition: RFC3444 https://tools.ietf.org/html/rfc3444 not here to do general
information model. discussion should be in the context of RATS

David M Wheeler: has been looking at different way to do attestation. Prefers
information model/CDDL on lines of Suits manifest. Data model should map to the
information model thus defined. Goal: want manufacturers to be able to extend
by themselves (without IANA registering) Henk Birkholz: As the author of the
draft-birkholz-rats-information-model is concerned about losing taxonomy,
categories and protocol parameters defined in it. Ned Smith (chair): Charter
specifies that IM/DM are derived from use cases Nancy (chair) Needs to have
some level of structure and guidance Jessica Fitzgerald: go back to usecases,
consider all of them to build an information model Nancy (chair): See if there
is a way to parallelize the efforts - we cannot wait till all the use cases are
done

Dave Thaler (*as an individual implementer): Requirement/usecase based
identification of minimal set of modelling elements needed think it is useful
to have a list of patterns of how to define an information model Mapping like
to JSON or CBOR or map between them so we don't have to define that elsewhere
(multiple times) Nancy (as TEEP Co-Chair): The IANA structure is important and
should not become a bottleneck for future extensions Lawrence
Lundblade: Focused on definition of claims & assertions. Eats drafts does that.
Does not understand the information model that takes the claims from eats draft
e.g. location. It would be a disaster...... definition of claims cannot be
docked (split between) into 2 drafts. Its importand to have definition of
claims in *one* draft David Wheeler: We can't split claims between two
documents. (Ready to fight back to back with Lawrence). Information model with
clear data types. Claims draft will use the elements  and structure defined in
the information model. Nancy (chair): IM defines the structure, but IM doesn't
necessarily instantiate the actual claim (eg. geolocation claims ...) Chairs
:Requesting everyone to review and comment on the list Nancy (chair):
clarification - IMs can have semantics Henk: common place to define elements
and reuse instead of spreading it in multiple documents Ming Pei:claims are
relative to a specific domain. separate document for claims following
terminology in information model draft.

Ned(chair): Will publish the comments on the list. continue to the discussion
on the list

16:55 - 17:15 Network device attestation
(draft-fedorkow-rats-network-device-attestation) – Jessica Fitzgerald-McKay &
Guy Fedorkow (20min)
https://datatracker.ietf.org/meeting/105/materials/slides-105-rats-remote-integrity-validation-workflow-01

worked previously in TCG

What we see as attestation in TCG
problem statement: whoever put the software wants to know if the software is
not hacked when running. uses TPM to do so (note: the end user/network admin
might want to know that their devices are running good software) The format has
been done for a long time, but no the interaction or exchange of the
attestation - that is what we work on here Explains measured boot with PCR
extension into TPM asks for RATS model to not break the existing TCG model
Reference measurements : from the manufacturer to be conveyed to the verified
to compare the measured values against. Man in the middle attack may cause the 
data to be provided to the verifier come from a bad actor and not from
expected  device being attested Golden/Reference measurements signed and
provided by the vendor producing the software Collection of RIV (Reference
integrity verifcation) should be coordinated b/n TCG and IETF

Anything TPM related belongs to TCG
Communication protocols and models belong at RATS
Henk's yang model lines up with TPM information model defined at TCG. TCG
defined MIB, but the yang model seems like a better approach and should be
continued at RATS.

Next Steps • We’d appreciate help in clarifying the workflow • We’ll add a
Security Considerations section to outline mechanisms used to defend against
attack • We want to ensure that the RATS Use Cases cover RIV • Interoperability
with existing TPM practice is critical

How to handle the reference measurements may be out of scope for RATS
Some documents are published publicly, some are still TCG member-only. TCG's
process publishes document for public review afterinternal work has been
complete

Dave Thaler: attestor, verifier in the diagrams but not relying party.
Jessica/Guy: Relying party is not part of TCG diagrams. TCG does not have an
opinion on the interaction with the relying party. Lawrence Lundblade: how well
is it aligned with yang? Guy: Perfectly aligned. Yang draft adoption will make
TCG happy.

Ned(chair): What is expected as interaction between TCG and RATS? Liason needed?
Guy: Yang model looks solid, working / mapping it to the TCG information model
will lead to a strong coordination b/n the groups. Jessica: Keynote at TCG. AD:
ready to setup liason if needed Chairs: Is a liason needed? Jessica: Yes Chairs
and AD to huddle on the liason decision.

17:15 - 17:20 Draft adoption discussion

Nancy:
1. TEEP dependency on RATs - Value in joint interim? 1 hr - no objection.
Chairs will facilitate the logistics 2. 2 virtual interims on RATs topics
separate from (1) ? No objections in the room. Chairs will facilitate the
logistics.