From 9e6a65630d5bfe1d534151a74a6c0c89224a7a92 Mon Sep 17 00:00:00 2001 From: Micke Nordin Date: Tue, 11 Aug 2026 01:16:58 +0200 Subject: [PATCH 1/2] Security: Add threat model for OCM During discussion at IETF126 it became clear that being explicit about the threat model for OCM would be useful for implementers and reviewers alike. This patch introduces a threat model secion in each of the OCM documents, as well as a new paragraph that calls out to the security section of load bearing RFCs that OCM leans on. --- IETF-OCM-IP.md | 85 ++++++++++++++++++++++++++++++++++++ IETF-OCM-MLS.md | 111 +++++++++++++++++++++++++++++++++++++++--------- IETF-OCM.md | 65 ++++++++++++++++++++++++++++ 3 files changed, 240 insertions(+), 21 deletions(-) diff --git a/IETF-OCM-IP.md b/IETF-OCM-IP.md index d84c866..7212b59 100644 --- a/IETF-OCM-IP.md +++ b/IETF-OCM-IP.md @@ -1045,6 +1045,75 @@ one reason the two modes compose. # Security Considerations +## Threat Model + +This specification inherits the threat model and trust assumptions of +[OCM]. It additionally assumes that attackers may operate an unpaired +Protocol Server, compromise a paired OCM Server or Protocol Server, +steal bearer credentials, submit malformed back-channel or +front-channel requests, or attempt to exhaust storage, computation, or +network capacity. + +Pairing creates an explicit administrative trust relationship. A +paired OCM Server is trusted to provision only authorized Shares, issue +tokens only for valid grants, provide truthful Share information, and +stay within agreed resource limits. A compromised OCM Server can +impersonate its users, provision arbitrary Shares, mint valid access +tokens, direct the Protocol Server to expose Resources, and consume +resources allocated to the pairing. + +The Protocol Server is part of the Sending Server's trusted computing +base for every protocol it serves. Its administrators, users with +equivalent access such as root access to its host, and operators of its +underlying storage are trusted. A compromised Protocol Server can +ignore permissions and identity bindings, disclose or alter Resources, +inject arbitrary content, misuse bearer tokens that reach it, record +Share metadata, or deny service. OCM-IP does not protect users from +such behavior. Avoiding persistent replication of OCM `sharedSecret` +values limits credential exposure, but does not make the Protocol Server +an untrusted content-serving component. + +Provisioned and Introspected Integration disclose the full Share +Creation Notification payload to the Protocol Server with every +`sharedSecret` removed. Depending on the Share, this can include the +sender, owner, Receiving Party, display names, Resource name and +description, Resource and Share types, protocol endpoints, permissions, +expiration, and extension metadata. Provisioned Integration transfers +this information over the signed back channel before Resource access +and normally stores it as a Share Record. Introspected Integration +transfers it through the additional introspection exchange and permits +the resulting response to be cached until its stated expiration. + +Self-Contained Integration discloses slightly less information. The +JWT presented to the Protocol Server contains the `ocm_ip` claim with +the protocol details, `providerId`, Resource type, and selected optional +Share metadata, while the enclosing JWT claims identify the issuer, +owner, and Receiving Party. The same JWT form is used by Introspected +Integration, but Self-Contained Integration performs no additional +introspection request. The `ocm_ip` contents are visible to the +Protocol Server and to every other holder of the JWT, including a +Receiving Party's user agent for applicable protocols. + +A delegated Token Server is trusted with token-signing authority and +with the Share and identity information needed to issue credentials. A +compromise of that server permits valid tokens to be minted within the +scope of its published signing keys. + +TLS, HTTP Message Signatures, JWT signatures, and authenticated +introspection establish which paired component made an assertion and +protect exchanges in transit. They do not establish that a trusted +endpoint is benign or that Resource content is safe. Bearer tokens +grant access to their holder until they expire or cease to be accepted +and therefore need to remain confidential. + +The three modes make different availability and revocation trade-offs. +Provisioned Integration depends on delivery of lifecycle requests. +Self-Contained Integration cannot revoke an issued token before expiry. +Introspected Integration depends on availability of the introspection +endpoint and permits revocation only after cached positive responses +expire. No mode prevents a required OCM Server or Protocol Server from +selectively or completely denying service. + ## No Secret Replication A central design goal of OCM-IP is that delegating protocol work does @@ -1181,6 +1250,22 @@ apply negative caching with a short lifetime so that a flood of invalid credentials does not translate into a flood of introspection traffic towards the OCM Server. +## Underlying Security Specifications + +This specification relies on the base Open Cloud Mesh protocol [OCM], +HTTP Message Signatures [RFC9421], JSON Web Keys and JWK Sets [RFC7517], +Digest Fields [RFC9530], JSON Web Tokens [RFC7519], OAuth 2.0 Token +Introspection [RFC7662], and the JWT Profile for OAuth 2.0 Access Tokens +[RFC9068]. All security considerations in those specifications apply +to implementations of OCM-IP. + +These specifications need to be considered together. A signature or +token is only as trustworthy as the provenance and protection of its +key, a signed `Content-Digest` provides content integrity only when both +the signature and digest are validated, and an active introspection +response grants authority only within the authenticated pairing and +until its stated expiration. + # IANA Considerations ## JSON Web Token Claims Registry diff --git a/IETF-OCM-MLS.md b/IETF-OCM-MLS.md index f0a3915..d4970a5 100644 --- a/IETF-OCM-MLS.md +++ b/IETF-OCM-MLS.md @@ -1670,14 +1670,62 @@ operations occur on the user's device. # Security Considerations {#security-considerations} -**Trust model.** In web-client deployments, the OCM Server holds the -Group Key and can decrypt any resource shared with the group on behalf -of its users. This is consistent with the standard OCM Server trust -model, where users trust their server with their data, and with OCM's -existing approach of abstracting security to the server level. Native -client deployments provide stronger isolation, as the server does not -hold key material. Implementations SHOULD move toward native client -deployments over time. +## Threat Model + +This specification inherits the threat model and trust assumptions of +[OCM], except where this document explicitly provides stronger +cryptographic protection. Attackers may control remote OCM Servers, +group members, Delivery Service functions, network paths, or previously +valid members that have since been removed. They may send malformed +messages, withhold or reorder messages, retain previously obtained key +material, and attempt to cause inconsistent group state or resource +exhaustion. + +In web-client deployments, an OCM Server acts as an MLS client and holds +the MLS state, Group Keys, FKs, and plaintext available to its users. +The server's administrators, users with equivalent access such as root +access to its host, and operators of storage containing that material +are therefore trusted. Such an operator can impersonate users hosted +by that server, decrypt or alter Resources available to them, manipulate +local group state, and suppress protocol operations. + +Native-client deployments place MLS state, FKs, and plaintext on the +user's device instead. For encrypted Resources, the OCM Server and its +storage are then outside the confidentiality boundary and cannot create +a valid modification without the relevant key material. They can still +delete or withhold ciphertext, replay previously valid ciphertext unless +the application provides freshness protection, observe metadata, and +deny service. The user's home server also remains the Authentication +Service for its own users and can impersonate those users by +substituting their credentials or KeyPackages. The native client device +and anyone with administrative access to it are trusted with that user's +key material and plaintext. + +Every current group member is an authorized recipient of the group's +cryptographic material. MLS cannot prevent a member from retaining or +disclosing plaintext, Group Keys, or FKs that it legitimately receives. +A member with write access and the applicable FK can also create a +cryptographically valid arbitrary payload for a shared Resource. MLS +authenticates the member that performed a protocol operation; it does +not establish that the member or the supplied content is benign. + +The distributed Delivery Service is not trusted for confidentiality or +integrity of MLS-protected data. A compromised Delivery Service cannot +derive group secrets or forge valid MLS messages, but it can delay, +drop, selectively deliver, or partition messages and can observe the +metadata deliberately exposed by this protocol. The Group Owner Server +is additionally trusted for Commit arbitration and availability, but +not for accepting otherwise invalid Commits or for content +confidentiality. + +This protocol deliberately accepts several deployment-dependent +trade-offs described below. Encryption is optional. Key-reuse mode +trades cryptographic revocation for operational efficiency and trust in +former Member Servers. Temporary retention of previous or forked epoch +state weakens forward secrecy for a bounded period. Public handshake +messages and distribution of the ratchet tree expose group membership +and membership changes to participating servers. None of these modes +provides protection from complete or selective denial of service. **Virtual Clients.** All Emulator Clients of a Virtual Client hold the secret state needed to act as that Virtual Client. Compromise of one @@ -1693,10 +1741,10 @@ SHOULD also be performed periodically or when key compromise is suspected. In key-reuse mode the FK is unchanged and the ciphertext is not re-encrypted, so revocation is not cryptographic: it relies on trusting servers to discard all key material they are no longer entitled -to - superseded Group Keys, old wrapped FKs, and any cached unwrapped -FKs - after a Remove Commit. Key-reuse mode SHOULD only be used within -formal federations with governance agreements that enforce this -behaviour. +to after a Remove Commit. This includes superseded Group Keys, old +wrapped FKs, and any cached unwrapped FKs. Key-reuse mode SHOULD only +be used within formal federations with governance agreements that +enforce this behaviour. **Two access-control layers.** For an encrypted federation share, access is controlled at two independent layers: the per-server transport @@ -1819,15 +1867,20 @@ transport protection (TLS and HTTP Signatures [RFC9421]) prevents exposure to outside observers. Application Messages, which carry key material, are always encrypted as PrivateMessage. -**Group membership privacy.** The ratchet tree contains every member's -OCM Address and is held by every Member Server, so the full membership -of a group is visible to all servers that have a member in it. This is -inherent to the design - servers route shares and notifications using -exactly this information - but it sets the privacy baseline: federated -groups are not anonymous, and membership of a group is as visible to the -participating servers as membership of a shared folder. The tree is not -exposed to servers outside the group, and transport protection prevents -exposure to third parties. +**Group membership and admin enumeration.** The ratchet tree contains +the OCM Address of every group member, and the GroupContext contains the +group's admin set. This information forms part of the MLS group state +and its changes are conveyed in public handshake messages. Every group +member and every Member Server can therefore enumerate all members and +admins of the group and observe membership and admin-set changes over +time. This is an accepted privacy trade-off inherent to this design: +servers need the membership information to route shares and +notifications, resolve federation shares to local users, and enforce +admin policy. Federated groups do not provide anonymous membership or +hidden administrator roles. The information is not exposed by the +protocol to servers outside the group, although an authorized member or +Member Server can disclose it, and transport protection prevents +exposure to outside observers in transit. **Admin set integrity.** The admin set and the group's OCM Address are carried in the GroupContext ({{admin-set}}), so they are covered by the @@ -1857,6 +1910,22 @@ signed using HTTP Message Signatures [RFC9421] and SHOULD implement rate limiting and other access control methods on the `/mls-key-packages` endpoint to avoid user enumeration. +## Underlying Security Specifications + +This specification relies on the base Open Cloud Mesh protocol [OCM], +the Messaging Layer Security protocol [RFC9420], HTTP Message Signatures +[RFC9421], and JSON Web Keys and JWK Sets [RFC7517]. All security +considerations in those specifications apply to implementations of this +protocol. The security and privacy considerations of the MLS +architecture [RFC9750] also apply. + +Implementations using Virtual Clients additionally need to follow all +security considerations of [ietf-mls-virtual-clients], as required +above. Where this specification uses AEAD algorithms defined for HPKE, +the applicable algorithm and nonce-management considerations of +[RFC9180] apply, although this specification does not otherwise use the +HPKE construction. + # IANA Considerations The MLS Exporter label `"ocm-group-key"` used in the Group Key diff --git a/IETF-OCM.md b/IETF-OCM.md index 7b97175..a1a54ba 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1970,6 +1970,60 @@ in which case the "providerId" field is REQUIRED, or to a Group. The # Security Considerations +## Threat Model + +OCM protects protocol exchanges between independently operated servers. +It assumes that an attacker may control a remote user, send malformed or +deceptive protocol messages, observe or modify traffic where transport +security is not used, steal bearer credentials, or operate a malicious +OCM Server. Implementations are expected to authenticate peers where +required, enforce local authorization policy, validate protocol inputs, +and protect credentials. + +OCM does not protect a user from the administrators of the user's OCM +Server or from administrators of the infrastructure on which that +server depends. Administrative users of an OCM Server, users with +equivalent access such as root access to its host, and operators able to +obtain its private keys or bearer credentials are considered trusted. +Such an operator can impersonate users hosted by that server, create or +alter Shares and notifications attributed to those users, access +Resources available to the server, and suppress or modify protocol +operations. Preventing such actions is outside the scope of this +specification. + +Storage used by an OCM Server is also considered trusted. An operator +with administrative access to underlying storage can read, replace, +delete, roll back, or inject Resources and metadata. For example, such +an operator can inject an arbitrary file or payload into a shared +folder. OCM does not provide end-to-end encryption or object-level +integrity protection against the Sending Server, the Receiving Server, +or their storage operators. Deployments requiring those properties +need an additional end-to-end protection mechanism. + +Trust in one OCM Server does not imply trust in every OCM Server. A +server is authoritative only for the users and Resources in the +administrative domain for which it is trusted. A Receiving Server also +acts on behalf of its Receiving Parties and receives credentials that +permit access to their Remote Resources. Consequently, a compromised +or malicious Receiving Server can use or disclose access granted to +those parties. Operators need to consider this delegation when deciding +whether to trust or allowlist a peer. + +TLS and HTTP Message Signatures protect messages in transit and permit +attribution to the server controlling the relevant credentials. They +do not establish that assertions made by that server are truthful, that +its administrator is benign, or that supplied content is safe. +Resource names, descriptions, URIs, metadata, and Resource contents +received from another server therefore remain untrusted input and need +to be handled according to local security policy. + +A malicious or unavailable peer can refuse to deliver notifications or +Resources and can attempt to exhaust network, processing, or storage +capacity. The protocol cannot guarantee availability when a necessary +peer refuses service. Implementations should nevertheless apply +appropriate timeouts, request and response size limits, rate limits, +quotas, and concurrency limits to contain such failures. + ## Trust There are several areas that are not covered by this specification. @@ -2010,6 +2064,17 @@ setups. Bearer tokens MUST be treated as confidential and never logged, persisted beyond their lifetime, or transmitted over unsecured channels. +## Underlying Security Specifications + +This specification relies on HTTP Message Signatures [RFC9421], JSON +Web Keys and JWK Sets [RFC7517], and Digest Fields [RFC9530]. All +security considerations in those specifications apply to +implementations of OCM. Implementers need to consider those +specifications together: a message signature is only as trustworthy as +the provenance and protection of its verification key, and signing a +`Content-Digest` field provides content integrity only when both the +signature and digest are correctly validated. + # Copying conditions The author(s) agree to grant third parties the irrevocable right to From 163885849c8a22dc0f16b0b673dbb70e21c465d2 Mon Sep 17 00:00:00 2001 From: Micke Nordin Date: Tue, 11 Aug 2026 22:42:28 +0200 Subject: [PATCH 2/2] Reference RFC3552 Make it explicit that the Sending and Recieving OCM server as well abortsprotocol servers are part of the trusted comput environment and that the threat model assumes that the OCM server is not compromised. The network, is untrusted as is other OCM servers on the network --- IETF-OCM-IP.md | 159 ++++++++++++++++++++++++++++-------------------- IETF-OCM-MLS.md | 142 +++++++++++++++++++++--------------------- IETF-OCM.md | 74 ++++++++++------------ 3 files changed, 199 insertions(+), 176 deletions(-) diff --git a/IETF-OCM-IP.md b/IETF-OCM-IP.md index 7212b59..649e7b8 100644 --- a/IETF-OCM-IP.md +++ b/IETF-OCM-IP.md @@ -98,8 +98,8 @@ Creation Notifications. The Protocol Server serves the actual Resource access protocol, authorizing requests by independently verifying the access tokens issued by the OCM Server. -Two properties of [OCM] make this delegation possible without sharing -secrets between the OCM Server and the Protocol Server: +Two properties of [OCM] make this delegation possible without +provisioning the Share's `sharedSecret` to the Protocol Server: 1. The OCM Server publishes its public keys as a JWK Set [RFC7517] at the URL advertised in the `jwksUri` field of its OCM API Discovery @@ -390,12 +390,12 @@ Shares whose protocols are served by a Protocol Server MUST use the Code Flow of [OCM] unless the Share uses Introspected Integration: the OCM Server MUST include `must-exchange-token` in the requirements of every protocol entry that a Protocol Server serves in Provisioned or -Self-Contained Integration. Legacy shared-secret access cannot be -verified by a Protocol Server on its own, because the long-lived secret -is deliberately never replicated to it; Introspected Integration exists -precisely to close this gap for Receiving Servers that cannot perform -the token exchange, at the cost of a per-request callback (see Token -Introspection and Security Considerations). +Self-Contained Integration. A Protocol Server cannot validate a legacy +`sharedSecret` on its own. Introspected Integration allows the Protocol +Server to receive that credential on the front channel and validate it +through a per-request callback to the OCM Server. After successful +introspection, the Protocol Server may also use the credential as +described in Security Considerations. ### Note: Delegating the Token Endpoint @@ -570,8 +570,10 @@ Receiving Server (see Lifecycle below), The request body is the Share Creation Notification object of [OCM] that the OCM Server intends to send to the Receiving Server, with one transformation applied: every `sharedSecret` field, in every protocol -entry, MUST be removed. The Protocol Server never receives, stores, or -needs any OCM secret. +entry, MUST be removed. The Integration API therefore never transfers a +`sharedSecret` to the Protocol Server. Introspected Integration is +different: a `sharedSecret` may reach the Protocol Server as a +front-channel credential, independently of provisioning. The fields used by the Protocol Server are thus: @@ -1047,31 +1049,38 @@ one reason the two modes compose. ## Threat Model -This specification inherits the threat model and trust assumptions of -[OCM]. It additionally assumes that attackers may operate an unpaired -Protocol Server, compromise a paired OCM Server or Protocol Server, -steal bearer credentials, submit malformed back-channel or -front-channel requests, or attempt to exhaust storage, computation, or -network capacity. +The threat model follows the Internet threat model described in +[RFC3552] and inherits the trust assumptions of [OCM]. It assumes that +the Sending and Receiving OCM Servers, paired Protocol Servers, and any +delegated Token Server have not been compromised and correctly enforce +the protocol and their local authorization policies. Their +administrative interfaces, host operating systems, private keys, +credentials, and underlying storage are part of the trusted endpoints. +Compromise of an endpoint or its trusted infrastructure is outside the +scope of this specification. + +An attacker is assumed to have extensive control of the communication +channel and may observe, block, replay, insert, modify, delay, or +reorder traffic. TLS, HTTP Message Signatures, JWT signatures, and +authenticated introspection provide the protections described in this +specification against such an attacker. + +An attacker may operate an OCM Server or Protocol Server of its own, +control a remote user, steal a bearer credential, or submit malformed +back-channel or front-channel requests. An unpaired server can make +assertions under its own identity, but must not thereby gain access to a +pairing, a Share Record, or a Resource. Implementations are expected to +verify pairing, authentication, identity binding, permissions, and +Resource scope independently. Pairing creates an explicit administrative trust relationship. A -paired OCM Server is trusted to provision only authorized Shares, issue -tokens only for valid grants, provide truthful Share information, and -stay within agreed resource limits. A compromised OCM Server can -impersonate its users, provision arbitrary Shares, mint valid access -tokens, direct the Protocol Server to expose Resources, and consume -resources allocated to the pairing. - -The Protocol Server is part of the Sending Server's trusted computing -base for every protocol it serves. Its administrators, users with -equivalent access such as root access to its host, and operators of its -underlying storage are trusted. A compromised Protocol Server can -ignore permissions and identity bindings, disclose or alter Resources, -inject arbitrary content, misuse bearer tokens that reach it, record -Share metadata, or deny service. OCM-IP does not protect users from -such behavior. Avoiding persistent replication of OCM `sharedSecret` -values limits credential exposure, but does not make the Protocol Server -an untrusted content-serving component. +paired OCM Server is trusted to provision authorized Shares, issue +tokens for valid grants, and provide truthful Share information. A +Protocol Server is part of the Sending Server's trusted computing base +for every protocol it serves and is trusted to enforce identity +bindings, permissions, and protocol restrictions. A delegated Token +Server is trusted with token-signing authority and with the Share and +identity information needed to issue credentials. Provisioned and Introspected Integration disclose the full Share Creation Notification payload to the Protocol Server with every @@ -1082,7 +1091,10 @@ expiration, and extension metadata. Provisioned Integration transfers this information over the signed back channel before Resource access and normally stores it as a Share Record. Introspected Integration transfers it through the additional introspection exchange and permits -the resulting response to be cached until its stated expiration. +the resulting response to be cached until its stated expiration. In +addition to the Share information returned by introspection, the +Protocol Server receives the presented `sharedSecret` itself and may use +or retain it as permitted under Secret Handling. Self-Contained Integration discloses slightly less information. The JWT presented to the Protocol Server contains the `ocm_ip` claim with @@ -1094,17 +1106,10 @@ introspection request. The `ocm_ip` contents are visible to the Protocol Server and to every other holder of the JWT, including a Receiving Party's user agent for applicable protocols. -A delegated Token Server is trusted with token-signing authority and -with the Share and identity information needed to issue credentials. A -compromise of that server permits valid tokens to be minted within the -scope of its published signing keys. - -TLS, HTTP Message Signatures, JWT signatures, and authenticated -introspection establish which paired component made an assertion and -protect exchanges in transit. They do not establish that a trusted -endpoint is benign or that Resource content is safe. Bearer tokens -grant access to their holder until they expire or cease to be accepted -and therefore need to remain confidential. +Bearer tokens grant access to their holder until they expire or cease +to be accepted and therefore need to remain confidential. The +cryptographic mechanisms authenticate assertions and protect exchanges +in transit; they do not establish that Resource content is safe. The three modes make different availability and revocation trade-offs. Provisioned Integration depends on delivery of lifecycle requests. @@ -1114,19 +1119,33 @@ endpoint and permits revocation only after cached positive responses expire. No mode prevents a required OCM Server or Protocol Server from selectively or completely denying service. -## No Secret Replication - -A central design goal of OCM-IP is that delegating protocol work does -not multiply the places where secrets live: - -* The `sharedSecret` of a Share is never stored on the Protocol Server: -it is stripped from the provisioning payload and absent from the -`ocm_ip` claim. A compromise of the Protocol Server therefore does not -leak credentials that could be exchanged for tokens at the OCM Server's -`tokenEndPoint`. (In Introspected Integration the Receiving Server does -present the legacy secret on the front channel; the Protocol Server -forwards it for introspection but MUST NOT retain it beyond the -request.) +## Secret Handling + +Provisioned and Self-Contained Integration avoid transferring the +Share's `sharedSecret` to the Protocol Server. Introspected Integration +necessarily exposes the presented credential to the Protocol Server and +therefore has different secret-handling requirements: + +* The Integration API strips every `sharedSecret` from the provisioning +payload, and the `ocm_ip` claim does not contain one. A Protocol Server +therefore receives no `sharedSecret` through either of those mechanisms. +* In Introspected Integration, the Receiving Server may present a legacy +`sharedSecret` on the front channel. The Protocol Server MUST +successfully introspect the credential before relying on it. +* After successful introspection, the Protocol Server MAY use the +presented `sharedSecret` to access another protocol entry of the same +Share when this is necessary to serve the requested protocol. For +example, a web application Protocol Server may use it to access a WebDAV +entry in the same multi-protocol Share, whether that entry is served by +another Protocol Server or by the OCM Server. +* Such use MUST remain within the Resource, protocols, permissions, and +parties identified by the successful introspection response. The +credential MUST NOT be used for another Share or retained beyond the +period during which the introspection response may be relied upon. +Continued use after that period requires a new successful introspection. +* A Protocol Server that retains a `sharedSecret` for this purpose MUST +protect it as a bearer credential. It MUST NOT place it in URLs or logs +and MUST delete it when it is no longer needed. * No pairing secret exists; the back channel is authenticated by HTTP Message Signatures against published keys, the front channel by JWT signatures against the same keys, and introspection requests by HTTP @@ -1148,11 +1167,15 @@ consistent with the Code Flow considerations of [OCM]. Without the Code Flow, the only credential is the long-lived `sharedSecret` itself, which the Receiving Server presents directly on -the front channel. The Protocol Server cannot verify it on its own: the -secret is deliberately never replicated to it. A Protocol Server MUST -NOT accept any front-channel credential other than a verifiable access -token or a credential validated through Token Introspection (or, for -SSH, the public-key mechanism of [OCM]). +the front channel. The Protocol Server cannot validate it on its own. +A Protocol Server MUST NOT accept a front-channel credential other than +a verifiable access token or a credential validated through Token +Introspection, except for the SSH public-key mechanism of [OCM]. + +Successful introspection authorizes the Protocol Server to rely on the +credential until the `exp` horizon of the introspection response. This +includes using the credential for another protocol entry of the same +Share as described under Secret Handling. Introspected Integration therefore reintroduces, deliberately and only for compatibility, the per-request coupling to the OCM Server that the @@ -1175,8 +1198,9 @@ content to third parties. The allowlist is therefore REQUIRED, and an empty allowlist means the Integration API rejects all requests. The Protocol Server SHOULD apply resource limits per paired OCM Server -(number of Share Records, concurrent sessions, storage) so that a -misbehaving or compromised OCM Server cannot exhaust it. +(number of Share Records, concurrent sessions, storage) so that requests +from one pairing, including excessive requests caused by malfunction or +an unexpectedly large workload, cannot exhaust it. Conversely, the OCM Server places trust in the Protocol Server to enforce the permissions and identity bindings of this document. @@ -1336,6 +1360,11 @@ https://datatracker.ietf.org/doc/html/rfc9530)", February 2024. ## Informative References +[RFC3552] Rescorla, E. and Korver, B. "[Guidelines for Writing RFC Text +on Security +Considerations](https://datatracker.ietf.org/doc/html/rfc3552)", BCP 72, +July 2003. + [RFC4918] Dusseault, L. M. "[HTTP Extensions for Web Distributed Authoring and Versioning]( https://datatracker.ietf.org/html/rfc4918/)", June 2007. diff --git a/IETF-OCM-MLS.md b/IETF-OCM-MLS.md index d4970a5..65f30ef 100644 --- a/IETF-OCM-MLS.md +++ b/IETF-OCM-MLS.md @@ -1658,11 +1658,10 @@ groups. In this transitive model, each home server is trusted to attest only its own users, and each admin client is trusted to have performed the -attestation check at introduction time. A malicious home server can -impersonate its own users - it is their Authentication Service - but it -cannot impersonate users of other servers, since it cannot produce an -authenticated KeyPackage delivery for an OCM Address whose host part it -does not serve. +attestation check at introduction time. The protocol does not +independently verify assertions made by a user's home server, because +that server is the Authentication Service for its users. Compromise of +that trusted server is outside the threat model. Users who require protection of their key material from their own server should choose a native client implementation where cryptographic @@ -1672,51 +1671,53 @@ operations occur on the user's device. ## Threat Model -This specification inherits the threat model and trust assumptions of -[OCM], except where this document explicitly provides stronger -cryptographic protection. Attackers may control remote OCM Servers, -group members, Delivery Service functions, network paths, or previously -valid members that have since been removed. They may send malformed -messages, withhold or reorder messages, retain previously obtained key -material, and attempt to cause inconsistent group state or resource -exhaustion. - -In web-client deployments, an OCM Server acts as an MLS client and holds -the MLS state, Group Keys, FKs, and plaintext available to its users. -The server's administrators, users with equivalent access such as root -access to its host, and operators of storage containing that material -are therefore trusted. Such an operator can impersonate users hosted -by that server, decrypt or alter Resources available to them, manipulate -local group state, and suppress protocol operations. - -Native-client deployments place MLS state, FKs, and plaintext on the -user's device instead. For encrypted Resources, the OCM Server and its -storage are then outside the confidentiality boundary and cannot create -a valid modification without the relevant key material. They can still -delete or withhold ciphertext, replay previously valid ciphertext unless -the application provides freshness protection, observe metadata, and -deny service. The user's home server also remains the Authentication -Service for its own users and can impersonate those users by -substituting their credentials or KeyPackages. The native client device -and anyone with administrative access to it are trusted with that user's -key material and plaintext. +The threat model follows the Internet threat model described in +[RFC3552] and inherits the trust assumptions of [OCM]. It assumes that +the OCM Servers participating in a group, including Member Servers, +Admin Servers, and the Group Owner Server, have not been compromised and +correctly enforce the protocol and their local authorization policies. +Their administrative interfaces, host operating systems, private keys, +credentials, and underlying storage are part of the trusted endpoints. +Compromise of an OCM Server or its trusted infrastructure is outside the +scope of this specification. + +An attacker is assumed to have extensive control of the communication +channel and may observe, block, replay, insert, modify, delay, or +reorder traffic. TLS, HTTP Message Signatures, and MLS provide the +protections described in this specification against such an attacker. + +An attacker may control a remote user, a current or former group member, +or an OCM Server of its own. It may send malformed messages, retain key +material it legitimately obtained while it was a member, disclose +plaintext or keys available to it, and attempt to cause inconsistent +group state or resource exhaustion. An attacker-controlled server can +make assertions under its own identity, but must not thereby gain +authority for users outside its administrative domain or admission to a +group without the required authorization. + +The distributed Delivery Service is not trusted to provide availability +or consistent delivery. It can delay, drop, reorder, selectively +deliver, or partition messages and can observe metadata deliberately +exposed by this protocol. It cannot derive group secrets or forge valid +MLS messages. The Group Owner Server is trusted to arbitrate Commits, +but its unavailability can stall epoch transitions until failover +completes. + +In web-client deployments, the trusted OCM Server acts as the MLS client +and holds MLS state, Group Keys, FKs, and plaintext on behalf of its +users. Native-client deployments move that cryptographic endpoint to +the user's device. Exposure of member key material and subsequent +recovery are considered according to the forward-secrecy and +post-compromise-security properties of [RFC9420]; full compromise of an +OCM Server remains outside scope. Every current group member is an authorized recipient of the group's cryptographic material. MLS cannot prevent a member from retaining or disclosing plaintext, Group Keys, or FKs that it legitimately receives. A member with write access and the applicable FK can also create a cryptographically valid arbitrary payload for a shared Resource. MLS -authenticates the member that performed a protocol operation; it does -not establish that the member or the supplied content is benign. - -The distributed Delivery Service is not trusted for confidentiality or -integrity of MLS-protected data. A compromised Delivery Service cannot -derive group secrets or forge valid MLS messages, but it can delay, -drop, selectively deliver, or partition messages and can observe the -metadata deliberately exposed by this protocol. The Group Owner Server -is additionally trusted for Commit arbitration and availability, but -not for accepting otherwise invalid Commits or for content -confidentiality. +authenticates the member performing a protocol operation; it does not +establish that the member or supplied content is benign. This protocol deliberately accepts several deployment-dependent trade-offs described below. Encryption is optional. Key-reuse mode @@ -1724,8 +1725,8 @@ trades cryptographic revocation for operational efficiency and trust in former Member Servers. Temporary retention of previous or forked epoch state weakens forward secrecy for a bounded period. Public handshake messages and distribution of the ratchet tree expose group membership -and membership changes to participating servers. None of these modes -provides protection from complete or selective denial of service. +and membership changes to participating servers. The protocol does not +provide protection from complete or selective denial of service. **Virtual Clients.** All Emulator Clients of a Virtual Client hold the secret state needed to act as that Virtual Client. Compromise of one @@ -1784,25 +1785,24 @@ unwrapping once the re-wrapped FKs have arrived. **Group Key retention window.** Between processing a Commit and receiving the re-wrapped FKs for the new epoch ({{fk-rewrap}}), a Member Server may retain the previous epoch's Group Key in order to keep -serving access requests. This retention slightly weakens forward -secrecy for the duration of the window: a server compromised during the -window exposes the previous epoch's Group Key in addition to the current -one. The window is bounded by the arrival of the re-wrapped FKs, and -Member Servers MUST delete the previous Group Key as soon as it is no -longer needed, or after a bounded time, whichever comes first. +serving access requests. This retention extends the lifetime of the +previous epoch's Group Key and therefore weakens forward secrecy for the +duration of the window. The window is bounded by the arrival of the +re-wrapped FKs, and Member Servers MUST delete the previous Group Key as +soon as it is no longer needed, or after a bounded time, whichever comes +first. **Commit ordering.** The Group Owner Server is the sole arbiter of Commits, eliminating conflicting Commits for the same epoch during -normal operation. A compromised or unavailable Group Owner Server can -stall epoch transitions, but it cannot decrypt resource content, and it -cannot cause the group to accept a Commit constructed by a non-admin -client, because every Member Server independently verifies the committer -against the admin set before processing a Commit ({{admins}}). The role -passes automatically to the next admin's server when the first admin -leaves the group ({{admin-set}}), and an unavailable arbiter is -eventually replaced through failover ({{failover}}), during which -conflicting Commits can briefly exist and are resolved -deterministically. +normal operation. An unavailable Group Owner Server can stall epoch +transitions, but the Delivery Service and network attackers cannot cause +the group to accept a Commit constructed by a non-admin client, because +every Member Server independently verifies the committer against the +admin set before processing a Commit ({{admins}}). The role passes +automatically to the next admin's server when the first admin leaves the +group ({{admin-set}}), and an unavailable arbiter is eventually replaced +through failover ({{failover}}), during which conflicting Commits can +briefly exist and are resolved deterministically. **Forked-state retention.** During a detected failover window, Member Servers retain the previous epoch's group state so that they can revert @@ -1813,13 +1813,12 @@ limited to servers that have observed the failover trigger. **Rejoin.** The rejoin procedure ({{rejoin}}) lets a home server replace its own users' leaves with fresh KeyPackages on the strength of its HTTP -Signature alone, without per-request admin approval. This grants no new -capability: the home server is already the trust anchor for its own -users' KeyPackages and could substitute their keys at any time through -the ordinary KeyPackage endpoint. Because admin clients verify that a -rejoin only replaces leaves whose OCM Addresses name the requesting -server and that are already present in the ratchet tree, a rejoin can -never admit a new party. +Signature alone, without per-request admin approval. The procedure +relies on the home server's existing role as the Authentication Service +for its own users and therefore introduces no additional trust +assumption. Because admin clients verify that a rejoin only replaces +leaves whose OCM Addresses name the requesting server and that are +already present in the ratchet tree, a rejoin cannot admit a new party. **Admin liveness and removal latency.** A Remove proposal takes cryptographic effect only when an admin client commits it. Removing @@ -2071,6 +2070,11 @@ Signatures](https://datatracker.ietf.org/doc/html/rfc9421)", February ## Informative References +[RFC3552] Rescorla, E. and Korver, B. "[Guidelines for Writing RFC Text +on Security +Considerations](https://datatracker.ietf.org/doc/html/rfc3552)", BCP 72, +July 2003. + [RFC4918] Dusseault, L. M. "[HTTP Extensions for Web Distributed Authoring and Versioning](https://datatracker.ietf.org/doc/html/rfc4918)", June 2007. diff --git a/IETF-OCM.md b/IETF-OCM.md index a1a54ba..17e5ab5 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1972,50 +1972,35 @@ in which case the "providerId" field is REQUIRED, or to a Group. The ## Threat Model -OCM protects protocol exchanges between independently operated servers. -It assumes that an attacker may control a remote user, send malformed or -deceptive protocol messages, observe or modify traffic where transport -security is not used, steal bearer credentials, or operate a malicious -OCM Server. Implementations are expected to authenticate peers where -required, enforce local authorization policy, validate protocol inputs, -and protect credentials. - -OCM does not protect a user from the administrators of the user's OCM -Server or from administrators of the infrastructure on which that -server depends. Administrative users of an OCM Server, users with -equivalent access such as root access to its host, and operators able to -obtain its private keys or bearer credentials are considered trusted. -Such an operator can impersonate users hosted by that server, create or -alter Shares and notifications attributed to those users, access -Resources available to the server, and suppress or modify protocol -operations. Preventing such actions is outside the scope of this -specification. - -Storage used by an OCM Server is also considered trusted. An operator -with administrative access to underlying storage can read, replace, -delete, roll back, or inject Resources and metadata. For example, such -an operator can inject an arbitrary file or payload into a shared -folder. OCM does not provide end-to-end encryption or object-level -integrity protection against the Sending Server, the Receiving Server, -or their storage operators. Deployments requiring those properties -need an additional end-to-end protection mechanism. +The threat model follows the Internet threat model described in +[RFC3552]. It assumes that the Sending Server and Receiving Server +participating in an OCM exchange have not been compromised. Their +administrative interfaces, host operating systems, private keys, +credentials, and underlying storage are part of the trusted endpoints. +Compromise of either endpoint or its trusted infrastructure is outside +the scope of this specification. + +An attacker is assumed to have extensive control of the communication +channel and may observe, block, replay, insert, or modify traffic. TLS +and, where used, HTTP Message Signatures provide the protections +described in this specification against such a network attacker. + +An attacker may operate an OCM Server of its own, control a remote user, +send malformed or deceptive protocol messages, or steal bearer +credentials. An attacker-controlled server can make arbitrary +assertions under its own identity, but must not thereby gain authority +for users or Resources outside its administrative domain. +Implementations are expected to authenticate peers where required, +enforce local authorization policy, validate protocol inputs, and +protect credentials. Trust in one OCM Server does not imply trust in every OCM Server. A -server is authoritative only for the users and Resources in the -administrative domain for which it is trusted. A Receiving Server also -acts on behalf of its Receiving Parties and receives credentials that -permit access to their Remote Resources. Consequently, a compromised -or malicious Receiving Server can use or disclose access granted to -those parties. Operators need to consider this delegation when deciding -whether to trust or allowlist a peer. - -TLS and HTTP Message Signatures protect messages in transit and permit -attribution to the server controlling the relevant credentials. They -do not establish that assertions made by that server are truthful, that -its administrator is benign, or that supplied content is safe. -Resource names, descriptions, URIs, metadata, and Resource contents -received from another server therefore remain untrusted input and need -to be handled according to local security policy. +TLS and HTTP Message Signatures permit attribution to the server +controlling the relevant credentials, but do not establish that its +assertions are truthful or that supplied content is safe. Resource +names, descriptions, URIs, metadata, and Resource contents received from +another server remain untrusted input and need to be handled according +to local security policy. A malicious or unavailable peer can refuse to deliver notifications or Resources and can attempt to exhaust network, processing, or storage @@ -2160,6 +2145,11 @@ October 2025. ## Informative References +[RFC3552] Rescorla, E. and Korver, B. "[Guidelines for Writing RFC Text +on Security +Considerations](https://datatracker.ietf.org/doc/html/rfc3552)", BCP 72, +July 2003. + [OCM-IP] Nordin, M., Lo Presti, G., and Baghbani, M. "[Open Cloud Mesh Integration Protocol](https://datatracker.ietf.org/doc/draft-nordin-ocm-integration-protocol/)",