Session Date/Time: 09 Nov 2022 15:00

TEEP

Summary

The TEEP session covered significant updates to the TEEP Protocol draft (v19), a report from the recent hackathon, and detailed discussions on open issues related to SUIT, EAT tokens, and attestation result delivery. Key technical points included an expanded threat model for compromised TAMs, mandatory cipher suites for authentication, and clarifications on the relationship between TEEP, SUIT, and RATs. Several editorial changes and minor clarifications were also incorporated. The session concluded with an overview of TEEP use cases for computational computing networks.

Key Discussion Points

TEEP Protocol Draft Update (v18 to v19)
- Addressed multiple reviewer comments, including security reviews, terminology (e.g., "trusted application" vs. "trusted component"), device owner roles, and general wording.
- Threat Model Expansion: Section 9.5 on "Compromised TAM" (or "Hostile TAM") was significantly expanded to include potential mitigation strategies for TEEP agents and device owners, such as Access Control Lists (ACLs) for TAM keys, transparent logs, and remote attestation/de-attestation. It was clarified that "hostile TAM" is a special case of "compromised TAM".
- Clarifications:
  - Clarified device administrator privileges and TA installation delegation.
  - Expanded use case examples for Trusted UI (e.g., Point of Sale devices) and IoT.
  - Revised terminology for "danger of attacks" to "risk of attacks."
  - Clarified TAM/TE communication initiation, emphasizing broker-initiated contact due to firewalls.
  - Standardized notation (e.g., TA-1, UA-1).
  - Changed "must" usage to lowercase to align with IETF document conventions.
  - Explicitly stated encryption purpose for data in motion.
  - Adjusted the installation sequence for trusted applications to be more natural.
  - Clarified the TAM's role, removing "abstracts" for clearer language on message relay.
Hackathon Report
- Attestation Payload Processing: TAMs will read the attestation-payload-format before deciding to open or verify the signature of the attestation-payload.
- Passport/Background Check Model: Discussion on combining these models led to using the Update message for sending attestation results to the relying party.
- SUIT Envelope: Decision to not use CBOR Tagged SUIT Envelope.
- Authentication Algorithms: Reaffirmed mandatory support for ES256 and EdDSA for authentication. COSE_Sign will be used in the Query Request to allow multiple signatures, accommodating situations where the TAM doesn't know the device's preferred algorithm.
- CDDL Syntax Validation: Progress on fixing CDDL syntax errors for TEEP messages, with suit message syntax remaining a dependency.
- Trusted Component Deletion: Shift from SUIT Digest to SUIT Component Identifier for targeting specific components for deletion, particularly important for devices with multiple TEEs or instances of the same component.
- Implementations: Noted progress by various implementers on passport model, remote attestation, and other TEEP features.
TEEP Protocol Open Issues & Proposals
- Cipher Suites: The TAM must support both ES256 and EdDSA for the initial Query Request by signing with COSE_Sign. The device chooses one. Subsequent messages use the negotiated cipher suite.
- Unrecognized TEEP Messages: If a TEEP agent receives an invalid message, it should reply with an error. If a TAM receives an invalid message, it may log, take implementation-specific actions, or attempt to update the TEEP agent.
- Relationship to SUIT
  - Uninstalling TAs: The unneeded-manifest-list in SUIT should include unlinked directives for robust uninstallation, allowing local administrators to trigger uninstalls even without the TEEP protocol.
  - SUIT Report Privacy: It was proposed that privacy of SUIT reports (encryption) should be specified in the SUIT Reports document, not TEEP, as SUIT reports can be used outside TEEP. Algorithm specifics (e.g., AES-GCM or AES-CCM) would be left to the encapsulating profile (e.g., EAT profile) or container.
- Relationship to EAT Tokens
  - EAT Profile Encryption: Identified a bug in draft-11's EAT profile regarding encryption cipher suites. Proposed using AEADs like AES-GCM or AES-CCM for encrypting sensitive EAT tokens.
  - Mandatory EAT Claims: Proposed making specific claims mandatory in the EAT profile for TAMs: device unique identifier, OEM/hardware vendor ID, model, version, installed manifests, and a freshness mechanism (nonce or timestamp).
  - Embedding SUIT Manifests: Proposed embedding SUIT manifests in EAT tokens using a SUIT Reference (ID and URL), which would require a new CoAP Content Format value to be registered.
  - Sample EAT token updated in the draft.
  - Attestation Result Delivery (TAM in the middle): Discussed five options for how a verifier delivers attestation results to a TAM (which then forwards to a relying party/tester) when different formats/freshness mechanisms are required. Still an open issue, with a preference expressed for options that don't overly complicate message encapsulation or rely on double messages for constrained devices.
  - TEEP Protocol Version: The TEEP protocol version number can be used to manage changes to the EAT profile default values.
TEEP Use Cases for Computational Computing Network
- Cloud Scenarios: The draft abstract and use case sections were updated to include cloud computing and MEC.
- Terminology: Clarified "computational container" definitions, referring to the Confidential Computing Consortium (CCC) for alignment. (Concern raised by Muhammad about scientific justification for CCC definitions, to be discussed on mailing list).
- Secure Channel: Need to specify or refer to a definition of "secure channel" (e.g., TLS/DTLS).
- Provisioning: Revised provisioning steps to acknowledge that the TAM might not be the verifier, and UA distribution is out of scope.
- Introduction Improvements: Proposed adding explanations using Multi-Party Computation (MPC) and Federated Machine Learning (FML) as examples of TEEP's application.
- Data Owner: Replaced "data owner" with "network user" for clarity.
- UA Tempering: Acknowledged that since the UA is untrusted, the TEEP architecture cannot guarantee its security or prevent DoS attacks. Filtering malicious traffic by a transparent TEEP broker is not reliable.
- Scope Broadening: Document scope should include any computational computing environment configured by a network, not just edge computing.

Decisions and Action Items

The TEEP Protocol draft will be updated with the following:
- Expanded threat model for Compromised TAMs (Section 9.5).
- Standardized ES256 and EdDSA as mandatory-to-implement authentication algorithms, using COSE_Sign for Query Request messages.
- Clarification on handling unrecognized TEEP messages by both TAM and TEEP agent.
- Decision to use SUIT Component Identifier for deletion of trusted components.
- Proposal to use AEADs (like AES-GCM or AES-CCM) for EAT token encryption.
- Specification of mandatory EAT claims for TAM consumption.
- Use of SUIT Reference in EAT (pending new CoAP Content Format registration).
- Updated sample EAT token in the draft.
- Incorporation of cloud scenarios, computational container terminology (with ongoing discussion), and broader scope for TEEP use cases.
Action: Muhammad to post a link and information regarding the scientific justification of CCC definitions to the TEEP mailing list.
Action: Chairs will evaluate the readiness of the TEEP Protocol draft for early directorate reviews (Security, IoT).

Next Steps

Authors to continue addressing open issues, particularly the mechanism for attestation result delivery when the TAM is in the middle and different formats are required by the TAM and other relying parties.
Work on the SUIT Reports document to specify privacy and encryption considerations for SUIT reports.
Proceed with registering the new CoAP Content Format value for SUIT Reference.
Finalize updates for the TEEP Protocol draft to incorporate all agreed-upon changes.
Initiate early reviews for the TEEP Protocol draft to prepare for WGLC.