**Session Date/Time:** 24 May 2023 13:00

# [T2TRG](../wg/t2trg.html)

## Summary

The T2TRG work meeting focused on the progress of three active research group drafts related to security and discussed a potential new area of work on discovery security. Updates were provided on the "Amplification Attacks in CoAP" draft, the "Survey of Initial Security Setup Techniques for IoT Devices" draft, and the "Taxonomy for Manufacturer-Installed Keys and Trust Anchors" draft. A new topic, "Discovery Security," was introduced to gauge interest in addressing poorly defined terms and security challenges in IoT discovery mechanisms. The group discussed scope and potential next steps for each area.

## Key Discussion Points

*   **Amplification Attacks in CoAP (Presented by John)**
    *   **Draft Updates**: Three versions released since last presentation, adopted by the research group. Changes include:
        *   Text about gateways added to multicast figures.
        *   Separate figure for observers based on a comment from Achim.
        *   Clarification that the draft does not suggest CoAP is inherently more vulnerable than other protocols.
        *   Noted that POST/PUT with conditional attributes are only possible if supported.
        *   Removed a section on actual amplification attacks due to poor quality of descriptions.
        *   Figures clarified with "client" changed to "victim" and "server" to "servers," addition of gateways for clearer attack illustration.
    *   **Discussion on Next Steps**:
        *   The draft is in a good state, with detailed comments addressed. Two minor comments from Achim remain.
        *   **Proposal**: Add recommended/enthusiastic mitigations for the described attacks, then prepare for publication.
        *   **Carsten's Comment**: Emphasized that the research group's role is to document the state of the art and identify gaps for future IETF work, not to write BCPs or recommend strict limits. Agreed that RFC 2116 language would not be used.
        *   **Michael's Comment**: Inquired about amplification attacks involving CoAP block mode transfers (not currently known). Suggested more unique terminology for attack types.
        *   **Mohit's Comment**: Asked about special considerations for Resource Directory (RD) lookups or observations, as responses might be much larger and potentially allow amplification.
    *   **Consensus**: Focus on adding mitigation information, identify existing mitigations, and describe new ones where needed, without acting as a BCP. Investigate potential new attack vectors (block mode, RD amplification).

*   **A Survey of Initial Security Setup Techniques for IoT Devices (Presented by Mohit)**
    *   **Draft Updates**: Title changed to "A Survey of Initial Security Setup Techniques for IoT Devices" to match content. Off-list feedback from Jaime regarding OMA needs to be addressed.
    *   **Draft Purpose**: Capture different terminologies, processes, and initial assumptions used in protocols for IoT device initial security setup, using illustrative examples from IETF and non-IETF protocols.
    *   **Challenges in Structuring**:
        *   **Terminology**: Current approach is a "dumb grep" of standards. Questioned whether to list all terms or focus on terms with specific meaning for setup.
        *   **Processes**: Should focus on user/network administrator expectations rather than detailed protocol explanations.
        *   **Players**: Current list includes every player mentioned. Questioned whether to distinguish based on manufacturer/service provider/user involvement, rather than listing every client/device/server.
    *   **Discussion**:
        *   **Carsten's Comment**: Suggested that for terminology, the document should define its own terms or a reference framework to explain the *meaning* and *context* of terms like "provisioning," "initialization," and "configuration" within each standard. This would make the document more useful as a dictionary of terms.
        *   **Carsten's Comment**: Emphasized the "triangle" of Players, Processes, and Beliefs, where a "party" (group of players) has security objectives. The document should explore who controls what, the collective knowledge, and how players work to realize party objectives.
        *   **Mohit's Suggestion**: To take OMA as a complex example to refine the definitions of players, processes, and beliefs, and then apply this refined approach to other protocols.
    *   **Consensus**: Revise the document to provide context and meaning for terminology, focus processes on user/administrator expectations, and refine player definitions. Call for reviews and community contributions.

*   **Taxonomy for Manufacturer-Installed Keys and Trust Anchors (Presented by Michael)**
    *   **Draft Purpose**: Provide terminology for discussing keys and trust anchors in IoT devices, allowing expression of desired security levels without establishing new evaluation criteria.
    *   **Draft Updates**: Influenced by CAB Forum requirements for code signing keys (e.g., requiring HSM, remote attestation). Expanding terminology to include key generation providence and extractability from devices/HSMs (e.g., non-extractable, encrypted extractable, extractable to similar HSM).
    *   **Discussion**:
        *   **Mohit's Comment**: Clarified the relationship between the CA forum's concerns (private key management for code signing) and device-specific keys/trust anchors. The document aims for common terminology between these areas. Discussed different methods of key storage (fuses, puff, device-generated) and the distinction between device-generated keys and factory-burned public trust anchors for software updates.
    *   **Timeline**: Aim for research group last call in September, with publication by year-end.
    *   **Consensus**: Continue refining terminology, incorporating insights from related work on key management and attestation.

*   **Discovery Security (Presented by Carsten)**
    *   **Problem Statement**: Many poorly defined terms (Discovery Access Control, Secure Discovery, Privacy Preserving Discovery). Discovery is critical for IoT automation but presents security challenges.
    *   **Types of Discovery**: Network discovery, Resource discovery.
    *   **Security Objectives (CIA triad)**:
        *   **Confidentiality**: Privacy (e.g., finding medical devices, expensive gadgets), preventing disclosure of attack surface (e.g., software versions). Stable identifiers create linkability issues.
        *   **Integrity**: Preventing injection of spoofed information, confusing players.
        *   **Availability**: Preventing disruption of discovery, abusing discovery for DoS.
    *   **Core Challenge**: Discovery security is an authorization problem. How do authentication and authorization work in the early discovery phase when there's only partial information? The "Christmas problem" (devices connecting to wrong networks).
    *   **Proposed Solution**: Secret handshakes – mutual authentication procedures that complete before information is disclosed to non-authorized parties.
    *   **Discussion**:
        *   **John's Comment**: Questioned how this relates to CoRE Resource Discovery RFCs. Carsten clarified that CoRE RD assumes network authentication, operating in an "advanced phase," whereas "early discovery" (benefiting from secret handshakes) cannot make such assumptions.
        *   **Michael's Comment**: Acknowledged the problem's interest but questioned the body of work. Referenced Christian Redema's past work on "secret handshakes" (DNSSEC) which didn't gain traction, possibly due to lack of broad IoT interoperability at the time. Argued that while important, the world might not be ready for it yet. Carsten stressed the research group's role in thinking ahead.
        *   **Milan's Comment**: Agreed on the problem's interest. Suggested identifying the scope: who can discover, subject to which constraints, and how much information is disclosed. Inquired about differences from Bluetooth discovery/pairing, noting Bluetooth often requires manual initial security steps, which is a key differentiator from desired IoT automation.
        *   **Marco's Comment**: Agreed on the interest, particularly for early discovery issues. Suggested defining a taxonomy of trust models for the early discovery phase as a starting point.
    *   **Interest**: There was strong interest from participants in exploring this topic.

## Decisions and Action Items

*   **Amplification Attacks Draft**:
    *   **ACTION**: John to add recommended mitigations to the draft.
    *   **ACTION**: Mohit to open an issue describing potential amplification attacks related to Resource Directory lookup/observe scenarios for investigation.
*   **Initial Security Setup Draft**:
    *   **ACTION**: Mohit (and co-authors) to undertake a major revision focusing on defining the meaning and context of terminology within each standard, explaining processes from a user/administrator perspective, and refining the definition of "players" and "parties" (using OMA as a key example).
    *   **ACTION**: Call for community reviews and contributions, especially for identifying players, processes, parties, and beliefs for the protocols covered.
*   **Taxonomy for Manufacturer-Installed Keys and Trust Anchors Draft**:
    *   **ACTION**: Michael to update the terminology in the draft based on recent CAB Forum discussions regarding key generation providence and extractability.
*   **Discovery Security**:
    *   **ACTION**: Initial discussions will continue on the mailing list to refine the scope, potentially starting with a taxonomy of trust models for early discovery.
    *   **ACTION**: The chairs will allocate time for a follow-up meeting of interested people to delve deeper into this topic.

## Next Steps

*   The T2TRG plans to hold further focused work meetings in the coming months, possibly at a cadence of approximately one per month.
*   Attendees interested in presenting or allocating time for specific topics are encouraged to contact the chairs.
*   All participants are encouraged to contribute to the drafts via mailing list comments or pull requests.