Minutes interim-2020-rats-06: Fri 07:30
Remote ATtestation ProcedureS
||Minutes interim-2020-rats-06: Fri 07:30
RATS October 23, 2020 Virtual Interim
Chairs: Nancy Cam-Winget, Kathleen Moriarty, Ned Smith
Notetakers: Ned Smith, Jessica Fitzgerald-McKay
1. Agenda Bash (5min)
2. Architecture – Michael (15min)
3. EAT – Laurence (20min)
4. Network Device Attestation - Guy (15 min)
5. Interaction Model – Henk (10min) •
6. CHARRA Update – Eric (10min) •
1. Nancy Cam-Winget, Cisco
2. Ned Smith, Intel
3. Dave Thaler, Microsoft
4. Eric Voit, Cisco
5. Guy Fedorkow, Juniper
6. Ira McDonald, High North Inc
7. Jessica Fitzgerald-McKay, NSA
8. Kathleen Moriarty, Dell
9. Laurence Lundblade, Security Theory LLC
10. Michael Richardson, Sandelman Software Works Inc
11. Peter Yee, AKAYLA
12. Thomas Hardjono, MIT
13. Wei Pan, Huawei
14. Henk Birkholz, Fraunhofer SIT
15. Giri Mandyam, Qualcomm
16. Thomas Fossati, ARM
17. Sarah Helble, The Johns Hopkins University Applied Physics Laboratory
18. Andrew Guinn
1. Agenda Bash
- met 8 or 9 times since last IETF meeting
- 100 or so pull requests closed
- think they are done
- Added section called 'reference values' and two new definitions
(reference value provider, reference values) - Changed the high level
diagram to add RVP entity as a 'stared' box which isn't normative at this
time. - Lots of new text about the Verifier role that describes the duties
a verifier needs to perform.
- It includes explanations for keys and the expectation they will be
- Freshness and other edits were added
- The main addition was to add handles in addition to timestamps and
- for those who have not read anything since IETF108:
- The design team believes architecture draft is ready for last call.
- Nancy: Observed there were others who have read the draft and therefore
will issue the last call in 2 or 3 weeks due to holidays etc.
- Presented slides describing Verifier - trust establishment in the Attester
- Asks the question "what goes into EAT to identify the key?"
- There should be interoperation between different attesters and verifiers
from different vendors (towards a generalized verifier) - Introduces a
verification key ID (VKID)
- Taxonomy of VKID presented in detail (looking for discussion and
1. COSE KeyID as VKID - example: COSE KID header parameter
2. URI as VKID - could leverage HTTP to identify where to obtain
the key (see draft-ietf-cose-x509) 3. Base the VKID on the Claims -
standardize a claim; similar to ARM PSA?
- Challenges: Need to decode the payload verify things then go
back to the rest of the payload
4. VKID is in Evidence - Attach X.509 cert to EAT - can use COSE
X.509 to wrap EAT (I think?) - similar conceptually to other
- Dave Thaler - Q: No strong preference, but should support 2nd and 4th
rows. Important to support certificate _chains_ not just
keys/certificates and those rows do. Nothing in the table is really
RATS specific but really applies to any use of COSE, so ideally just
reference the cose draft as much as possible. - Laurence - The goal
isn't to standardize it but to explain how to do it in the draft. -
Dave Thaler - #3 requires mixing instance values with class values
which means there will be many more EAT tokens generated than would
otherwise be required. _[Dave: I don't recall saying this, have to
check the recording as either it wasn't me or wasn't my point or I have
a bad memory now :]_ - Henk Birkholz - Is this really only
informational - how do we proceed toward consensus? For example what
about hash of a public key as a keyid?
- Dave T. - Row 1 is an example of hash of a key. #2 tells you
where to get the key, which #1 doesn't tell you where to get the
key. - Henk - How to enable interoperability then? - Laurence - No
silver bullet - it may take a while
- Endorsement - no formal definition?
- A set of assumptions were presented
- For simplicity including 'reference values' under Endorsements
- Do we have an identifier for an endorsement in EAT
- Add Endorsement ID (EID?) or URI/URL to EAT?
- EAT origination claim would be replaced by Endorsement URL
- Dave Thaler in chat pointed out that this definition isn't
consistent with the definition in the architecture draft -
Endorsements may have information that wouldn't expect to find in
X.509 certificate (such as implicit claims). - Comments:
- Dave Thaler: Proposes a wording modification - All of the
above are technically out of scope for the WG. Hence, can't
include normative language in a draft. Propose adding a ref
value provider URL. - Dave: Implicit claims can be included in
a certificate or an endorsement structure.
- The case the previous table didn't cover (but was in
Michael's diagram) was the endorser might differ from the
reference value provider. If there is a URI available to
find the appropriate entity makes sense.
- Henk: The MUD draft
be a good way to add pointers to things/entities. Endorsement
ID is on the fringe because it mixes evidence with endorsement.
Some assumptions don't apply relative to the content in the
architecture draft. - Giri: Need to finalize EAT draft to
support implementers. See issue 65
- Need approach to unsigned tokens - the UCCS draft didn't
make progress. What is the status for unsigned tokens?
- Nancy (as individual): There were comments and
intention to move it forward. - Henk: Need to allocate
time to work on it.
- Nancy (as chair): Restates RATS interest in moving the draft
7. Network Device Attestation
- Guy Fedorkow update to RIV draft
- Last call ended Oct 12th (thanks to everyone who commented)
- 700 lines comment material provided; most had to do with wording
- One more change required
- Endorser / Reference Value Provider definitions changed in
- Sections that pertain to reference values will change to RVP
where Endorser is currently being used. - Many synonyms to
'reference values' that need to be updated to use the standardized
terminology. - Nancy: Reach out to commenters once v05 has been
- Next steps
- Finish editing tasks
- Anything else?
- Nancy: Once the updated draft is available then a request for
finalization can be made.
9. Interaction Model
- Henk presenting interaction model draft
- Three models identified
- Direct Anonymous Attestation (DAA) is described as a way to address
privacy using group signing - Current status: Adopted as a WG draft
- Recently updated
- Better alignment to terminology in architecture draft
- Referenced by 4 other drafts
- Next Steps
- Section 6. contains normative prerequsites for Attesters.
- Ask: Is the scope of normative language appropriate?
- Dave Thaler: Why is there normative language in a document
that is informational? - Nancy: Asks who has read the document
- Dave: Not the version that is 3 hrs old - Nancy: Looking for
the update to go out on the reflector - looking forward to IETF
109 - Henk: Looking for feedback on the list
- Section 7. contains generic information elements
11. CHARRA Update
- Eric Voit presenting
- Many devices use YANG interfaces
- This draft defines access to/from TPM 1.2 / 2.0 RPCs
- IETF "YANG Doctors" review is complete / near complete
- Reviewed relationship to other RATS drafts
- Issues addressed
1. Overall document added text to describe the purpose and context
2. Added ietf-tcg-algs yang, and created error checks
3. Added support for netequip_boot logs
4. Refined models
- Open Issues
- Need help with XPATH expressions
- YANG Doctor comments need to be addressed
- Maximize commonality between TPM 1.2 and 2.0 RPCs - Can't track
down the original author of the 1.2 RPCs - Include tpm-name and
node-id in RPCs?
- Node-id is used to identify a line card when there are
multiple line cards
- More discussion on node-id
- certificate-name is assumed unique on a multi-linecard attester
- PRO: multiple line cards are disambiguated
- Queries won't change when using node-id
- CON: redundancy in message contents
- exposes linecard structures in routers
- larger code and error conditions to check
- Eric recommendation is option 1 (use certificate name not
node-id) - Wei Pan: Node-id is also used in option 1, why is
this still needed?
- Eric: plan on removing node-id in future revisions
- Wei: Both have pros/cons. Option 1 may be more readable, but
option 2 may be better for machines to process - but not
passionate one way of the other.
- Option 1 could have more processing requirements when
there is a lead Attester - Eric: Even if nod-id wasn't
used, they would still need to be processed and line card
mfg'rs would need to assign names. - Nancy: Try to resolve
the issue on the list.
- Working last call anticipated after these issues are addressed
- Henk: Are options mutually exclusive?
- Eric: The question is how much redundancy needed? Reduancy will
result in more errors.
- Next Steps:
- Nancy: Any more comments?
Meeting adjourned 8:54 PDT