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.