**Session Date/Time:** 11 Nov 2021 12:00

# gnap

## Summary

The gnap session focused on the latest updates to the GNAP Core Protocol (draft-ietf-gnap-core-protocol-08), including significant additions to trust, security, and privacy considerations. Discussions also covered a formal security analysis that identified potential attacks and proposed mitigations. The editors outlined their roadmap for addressing open issues, including key rotation, mandatory-to-implement features, extensions, and the future of JOSE key-proofing mechanisms. The session concluded with a presentation by Denis Pinkas, who raised several concerns with the current draft, particularly regarding Attribute-Based Access Control, trust relationships, and client instance key protection, proposing a modified model.

## Key Discussion Points

*   **Logistics:** The session experienced initial technical difficulties with slide sharing but eventually proceeded. The IETF Note Well and Code of Conduct were presented. Kathleen M. took minutes on Hedgedoc.
*   **Core Protocol Updates (draft-ietf-gnap-core-protocol-08):**
    *   **Editors:** Justin Richer, Fabian Hirschmann, Aaron Parecki.
    *   **Revisions:** Draft-ietf-gnap-core-protocol-08 represents two full revisions since IETF 111. The Resource Server (RS) draft has not had a new revision published as changes have been minor.
    *   **Pull Requests/Issues:** 32 PRs merged on core, 3 on RS. 55 core issues and 5 RS issues closed.
    *   **Editorial Changes:** Numerous text consistency improvements, typo fixes, and formatting changes were applied, with significant contributions from Andreas and Florian. `editorconfig` was adopted to minimize spurious whitespace changes.
    *   **Functional Changes:**
        *   **Trust Relationships (Section 1.4):** A new section detailing expectations between parties, using "promise theory" as an alternative trust model. Trust is defined as an agent's expectation that a promise will be kept, allowing for probabilistic assessment, linking to relevant security and privacy sections to avoid repetition.
        *   **Security Considerations (Section 12, 25+ subsections):** Expansive coverage, though needing better organization. Key points include:
            *   Requirement for both TLS (confidentiality) and signatures (identification).
            *   Protection of private keys.
            *   Risks of bearer tokens (no signatures).
            *   Weaknesses in crypto/random number generator algorithms.
            *   Inherent susceptibilities of front-channel redirects (phishing, session capture), combated by GNAP when used properly.
            *   Mitigation for AS mix-up attacks: `interaction_hash` in the front channel.
            *   Pre-registering keys shifts, but doesn't eliminate, trust concerns.
            *   Limitations of mutual TLS (mTLS) in solving all problems.
            *   Vulnerabilities when processing complex identity assertions (e.g., XML DSig, SAML, JOSE).
        *   **OAUTH Security Workshop:** Announced as a free, online event in late November. Justin will present GNAP core structure, Fabian on formal security analysis. Opportunity for in-depth discussion on protocol tweaks before finalization.
        *   **Privacy Considerations (RFC 6973 based):** Addressed surveillance by clients/AS, data storage (opaque identifiers, shared references), and correlation risks from client key reuse across multiple AS/RS (recommended mitigation: use different keys).
        *   **Relationship to RS Draft:** Security and privacy considerations are currently in the core draft. The RS draft will inherit many, but will have unique considerations (e.g., introspection's privacy trade-offs, structured tokens, PII in tokens) that still need to be elaborated.
        *   **Symmetric Cryptography:** Allowed but restricted. GNAP's mechanisms for key *distribution* (by value) are limited to public/private keys only. Symmetric keys are only allowed to be passed by identifier. Security considerations outline safe practices (key derivation functions, key escrow services). HPKE was mentioned as a potential key derivation mechanism.
        *   **Subject Identifier / User Handle:** The "user handle" concept was removed. Opaque identifiers from the Security Events WG subject identifier format are now used, simplifying the protocol without losing functionality for client-to-AS user identification.
        *   **Client Instance Identifier:** The term "handle" was removed. This identifier's potential for dynamic client registration and key rotation over time will be further explored.
*   **Formal Security Analysis (by Florian Hemmerschmidt et al.):**
    *   **Cuckoo Token Attack:**
        *   **Preconditions:** Client uses the same keys with multiple AS. An attacker-controlled AS tricks the client into using a stolen, key-bound access token from the legitimate AS against a legitimate RS.
        *   **Proposed Mitigations:**
            1.  Client sends AS identifier to RS (protocol change, more data, RS check consistency).
            2.  **Client uses different keys for each AS:** Breaks the attack. Recommended as a security best practice or normative text.
            3.  **Client maintains strong binding between RS and AS:** Largely a security consideration, aided by discovery mechanisms.
        *   **Editor's Leaning:** Towards implementing mitigations #2 and #3 via security considerations or normative text. Florian Hemmerschmidt confirmed the explanation.
    *   **HTTP 307 Redirect Mechanical Attack:** Known in OAuth2. POST data (potentially including credentials) can be re-posted during a 307 redirect, leading to credential leakage.
        *   **Mitigation:** Stricter rules for HTTP redirects and associated security considerations. Florian has submitted text for review.
*   **Next Steps / Editor Proposals:**
    *   **Issue Backlog:** Continue to process remaining open issues, making decisions and proposing text.
    *   **API Management:** Define stricter semantics for what can be sent at each step of grant requests and continuation requests (e.g., client object, interaction references) to avoid unexpected corner cases.
    *   **Key Rotation:** Develop mechanisms tied to key presentation types (e.g., HTTP sig, JOSE, mTLS). Investigate leveraging existing tools like ACME for mTLS certificate rotation (suggestion from Kathleen).
    *   **Mandatory to Implement (MTI):** Define a baseline set of mandatory features for GNAP implementations. Debate on whether to use GNAP interoperability profiles (skepticism expressed due to potential for esoteric profiles and adoption challenges, drawing parallels to Sticks vs. MISP).
    *   **Extensions:** Provide guidance and requirements for extending the protocol (e.g., adding new fields, defining different data types for existing fields, handling unknown extensions).
    *   **JOSE Key Proofing Mechanisms:** Re-evaluate whether the two JOSE-based key proofing mechanisms (detached/attached JWS headers) should remain in the core draft or be moved to a separate specification. (Kathleen argued for keeping them in core for object-level security and as a differentiator from OAuth).
    *   **Resource Server Draft:** Acknowledge significant work remains, particularly on defining a token model.
    *   **Implementation Status:** Status is growing, and the core protocol is stabilizing, indicating a good time for further implementation and testing.
*   **Denis Pinkas's Concerns and Proposals (from draft-pinkas-gnap-abac):**
    *   **Attribute-Based Access Control (ABAC):** Argued that GNAP currently supports Capability-Based Access Control (CBAC) but lacks explicit ABAC support. Proposed defining two fields in access tokens to distinguish rights from attributes, defining attribute types (like OpenID Connect claims), and allowing RS to request specific attribute types.
    *   **Resource Owner (RO) vs. End User:** Noted an inconsistency in the draft's assumption that RO and end user are always the same entity, especially for automated processes.
    *   **Trust Relationships:** Criticized the use of promise theory for trust in Section 1.4, arguing for a binary trust model and highlighting incomplete/incorrect trust relationships.
    *   **Client Instance and End User Authentication:** Stated that the link between client instance authentication and end user authentication is undefined, as is how the AS can be confident of the legitimate user. Cited PSD2 multi-factor authentication requirements as unaddressed.
    *   **Insecure Model (Client Instance Key Protection):** Argued that Section 12.3 is insufficient, and collaborative client attacks are possible if keys are shared. Proposed a "binding user identifier" (BYD) mechanism within access tokens to prevent voluntary token sharing, outlining five types with varying privacy properties for long-term and short-term accounts.
    *   **EU Legislation:** Emphasized that GDPR, PSD2, and upcoming EU proposals for electronic attribute attestation are not adequately considered.
    *   **Proposed Model:** A modified model supporting both attributes and capabilities, mandatory end-user authentication to the AS, clear trust relationships, BYD for collaborative attack resistance, and mTLS with ephemeral client key pairs for impersonation protection.
    *   **Editor Response:** Fabian Hirschmann stated that most of Denis's comments have been discussed extensively on GitHub, with rationales for rejection provided, indicating they are unlikely to be included without broader working group consensus.

## Decisions and Action Items

*   **Cuckoo Token Attack Mitigations:** Editors are leaning towards adding security considerations or normative text to recommend clients use different keys for each Authorization Server (AS) and maintain strong bindings between Resource Servers (RS) and AS.
*   **HTTP 307 Redirect Attack:** Editors to review Florian's submitted text and add normative discussion to address this known vulnerability.
*   **Key Rotation:** Editors will propose text defining key rotation mechanisms tied to key presentation types (e.g., HTTP signatures, JOSE, mTLS) and investigate the use of ACME for mTLS certificates.
*   **Issue Backlog:** Editors will continue processing open issues, proposing text to resolve them and initiating working group discussion.
*   **JOSE Key Proofing:** Discussion will be brought to the mailing list to determine whether the JOSE-based key proofing mechanisms should remain in the core draft or be separated.
*   **Denis Pinkas's Proposals:** Editors have previously provided rationale for rejecting many of the proposed changes, but the discussion remains open for broader working group consensus on the mailing list.

## Next Steps

*   The editors will continue to address the extensive issue backlog, proposing specific text and fostering discussion within the working group.
*   Prioritize further defining API management specifics, key rotation mechanisms, Mandatory to Implement (MTI) features, and extension points.
*   Shift focus to the Resource Server (RS) draft, particularly the token model, as the core protocol stabilizes.
*   Encourage continued implementation and testing of the core protocol to identify further use cases and refine the specification.
*   Engage with discussions at the upcoming OAUTH Security Workshop.
*   Further discussions on key decisions (e.g., JOSE key proofing, MTI profiles) will be moved to the mailing list.