IETF 115 Session III November 9 2022
TEEP
Chairs: Tiru Reddy, Nancy Cam-Winget
Note takers: Pieter Kasselman, Chris Inacio
Agenda bashing, Logistics -- Chairs (5 mins)
- Only 90 minutes available today
- No time for new items today
Architecture – Mingliang Pei (20 mins)
• Draft: draft-ietf-teep-architecture
• Issues: https://github.com/ietf-teep/architecture/issues
Hackathon Report – Akira Tsukamoto (15 min)
- PResnetation here:
https://datatracker.ietf.org/meeting/115/materials/slides-115-teep-teep-hackathon-02.pdf
- 7 Participants
-
Evidence of Attestation Result in EAT Profile
- TAM does not process the attestation-payload in order to verify
it, it can just process the payload-format field
-
Muhammad Sardar(MS): What exactly do you mean by payload? It is
an undefined term in TEEP.
-
MS: What exactly would it mean for SGX?
-
Dave Thaler: The word "payload" - it's the name of the field in
the message.
- payload - byte string in the message
- payload-format - the type of byte string in "payload"
- For SGX - (way too fast to write that down); the payload
would be an SGX specific type (not described in the draft,
SGX specific) that would be processed in/by the SGX
implementation
-
Hannes: will send a link to the list on this topic (about using
newer CBOR features for ? payload feature)
- Thaler: that's not adopted yet
-
Use CBOR tag or not on SUIT nvelope
- Decided not to use SUIT envelope
-
Support for ES 256 and EdDSA
- Will proceed to support it
-
Fixing CDDL Syntax errors
-
SUIT digest unneeded-manifest-list
- Conclusion to use SUIT_Component_Identifier
-
Impact of hackathon/Progress
- 8 PRs
- 4 new issues (see slide 12)
TEEP Protocol and transport drafts – Dave Thaler (40 min)
• Draft: https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/
• Issues: https://github.com/ietf-teep/teep-protocol/issues
- Deck here:
https://datatracker.ietf.org/meeting/115/materials/slides-115-teep-teep-protocol-00.pdf
- #234, 251: Which TEEP messages are protected with which cipher
suites
-
Unrecognised TEEP messages
-
Use of SUIT
- Mike - tCOSE does support EdDSA
- Thaler - could not use it for signatures - couldn't use it with
queryt reqest messages.
-
Uninstalling trusted components
- References SUIT meeting before the TEEP meeting
-
SUIT_Evelope vs SUIT Envelope Tagged
- May want to use something that is not CBORbased
- What people need is in the base document, everything else in
extension doc
-
SUIT digest in unneeded-manifest-list
- SUIT Component identifer
- Not in the draft yet
- Added component ID for root manifest
-
SUIT reports can contain sensitive information
- Add privacy considerations
- Russ Housley: heard something different. Lots of places they
want this in plaintext.
- Thaler: if sneaker netting, who's responsbility is it to encrypt
that
- Bredan: You want a statement in security requirements of
suit-report that says if there is anything senstive you need to
encrypt that
- Brendan: MTI document, is only for constrained device update
only its covered in there.
- Thaler: Then should this be covered in the TEEP protocol?
- Brendan: Yes
- Thaler: Any objections to having it in TEEP not in SUIT-report?
- [none heard]
-
Use of EAT
- Which ciphersuite to use (sign and then encrypt)?
- A good ciphersuite is the one already implemented
- Destination if SUIT report and EAT are different - one goes
to verifier, other goes to verifier
- Thaler: Recommends they should be the same, but still need
to pick something
- Encryption algorithms havbe not ebeen discussed
- Brendan: Should we use different ones from the MTI doc in
SUIT? Some implementor already has hard requirement for RSA.
Would be inclinde to ask what they require as they are not
in the draft.
- Brendan - this is not about key exchange just bulk
encryption. You don't need to deal with out of order arrival
of data. This should not be an issues - use the AEADs. If
you can afford e.g CCM that is the way to go.
- Russ, Hannes: +1 on that recommendation
-
EAT Profile - all claims are optional
- Thaler: Propose 5 mandatory claims, one optional (the nonce)
-
EAT Manifest Claims in TEEP Profile
- Thaler: Propose use of SUIT_Refernece (nods)
-
Sample EAT Token
-
Relationship between TEEP EAT profile and AR4SI (slide 18)
- Discussed 5 options, None ideal
- Thaler - prefernece is for option 4 or 5.
- Call for feedback.
-
Penglin: TAM can be verifier (collapse roll) - this will
simplify
- Thaler - dont want to force it, but allow yes.
-
Akira Tsukamoto: prefer option 4 between 4 and 5; easier to
update draft than too. How implement on SGX, not
clear/informative enough in the draft.
- Hannes: Do we need to cover passport and background check.
Nobody forcing to cover full architecture from RATS
- Thaler: TAM is a specific Relying Party (background checks).
Things more complex when using passport checks. Need to
accomodate both. TAM could send two queries to the verifier,
but will need different nonces (timestamp may help avoid it)
-
How does omitting the EAT profile work with bis documents?
- Resolution proposed, no discussion
TEEP Use Case for Confidential Computing in Network – Penglin Yang (10 min)
•https://datatracker.ietf.org/doc/draft-ietf-teep-usecase-for-cc-in-network/
As we are over time, question on the Protocol draft readiness:
-
Nancy: Are we ready to do early review - take it up on the list
- Thaler: based on those in the comments room answer is possible
yes.
-
Ira: (in Zulip/Jabber) NIST definition of secure channel: From NIST
Glossary: secure channel is "A path for transferring data between
two entities or components that ensures confidentiality, integrity
and replay protection, as well as mutual authentication between the
entities or components. The secure channel may be provided using
approved cryptographic, physical or procedural methods, or a
combination thereof. Sometimes called a trusted channel." from
SP800-90A-Rev1