diff --git a/IETF-OCM-IP.md b/IETF-OCM-IP.md index d84c866..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: @@ -1045,19 +1047,105 @@ one reason the two modes compose. # Security Considerations -## 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.) +## Threat Model + +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 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 +`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. 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 +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. + +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. +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. + +## 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 @@ -1079,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 @@ -1106,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. @@ -1181,6 +1274,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 @@ -1251,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 f0a3915..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 @@ -1670,14 +1669,64 @@ 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 + +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 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 +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. 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 @@ -1693,10 +1742,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 @@ -1736,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 @@ -1765,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 @@ -1819,15 +1866,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 +1909,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 @@ -2002,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 7b97175..17e5ab5 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1970,6 +1970,45 @@ in which case the "providerId" field is REQUIRED, or to a Group. The # Security Considerations +## Threat Model + +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 +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 +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 +2049,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 @@ -2095,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/)",