Internet Engineering Task Force J. van de Meent Internet-Draft R. AI Intended status: Informational Humotica Expires: 23 December 2026 21 June 2026 Identity-Anchored Bearer Handover for Real-Time Media Sessions draft-vandemeent-bearer-handover-00 Abstract This document describes identity-anchored bearer handover: a method for keeping a live, authenticated real-time media session (such as a voice call) running uninterrupted while the underlying network bearer changes - for example a device moving from Wi-Fi to cellular. The session is bound to a cryptographic identity and a media-encryption key, never to an IP address. When the bearer changes, the endpoint detects the new local address and emits an authenticated re-anchor over a stable control channel; the media path is re-established to the same cryptographic context, so the far end can relearn the new transport source without exposing the session to source-substitution (latching) attacks. No central media relay is required: a default- routed media anchor plus an authenticated re-anchor is sufficient. Each handover MAY emit a signed transport-rebind event for an auditable trail. This protocol is transport-agnostic and complements JIS [JIS], the MUX Status Frame [MUX], the Semantic Surface Manifest [SSM], and TIBET provenance [TIBET]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 December 2026. van de Meent & AI Expires 23 December 2026 [Page 1] Internet-Draft Bearer Handover June 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Handover Procedure . . . . . . . . . . . . . . . . . . . . . 4 5. Cryptographic Anchoring of Media . . . . . . . . . . . . . . 5 6. Signed Transport-Rebind Event . . . . . . . . . . . . . . . . 5 7. Deliberate Re-Anchor (Moving Target) . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Real-time media sessions break when the network bearer underneath them changes. A device that places a call on Wi-Fi and then leaves the coverage area moves to cellular; its IP address changes; the media stream, addressed to the old transport, stops. The signalling dialog may survive (if it rides a stable, address-independent control channel), yet audio is dead in one or both directions, and an in- dialog teardown sent over the now-defunct transport never arrives. The common mitigation is a central media relay (for example TURN [RFC8656]): both endpoints send media to a fixed rendezvous, so a change of local address is absorbed by the relay. This works, but it reintroduces a central dependency in the media path - a single operator-run waypoint that sees, and can interrupt, every call. For a decentralized, identity-first system that is precisely the property to avoid. van de Meent & AI Expires 23 December 2026 [Page 2] Internet-Draft Bearer Handover June 2026 This document takes a different anchor. The session is bound to a cryptographic identity and to the media-encryption key, not to the transport address. The transport is free to change; the key is the constant. On a bearer change the endpoint re-anchors the existing session onto the fresh transport over a stable control channel, and the encrypted media context continues. The maxim is: _identity anchors, transport hops_. 1.1. Problem Statement A correct handover mechanism must achieve all of the following at once: * Continuity: a live session survives a change of local transport address with at most a brief, bounded interruption. * No central media relay as a precondition: continuity MUST NOT require a third party in the media path. * No source-substitution attack: permitting the far end to relearn a media source MUST NOT let an off-path or on-path attacker hijack the stream by injecting from a new address. * Accountable transition: a handover SHOULD be expressible as an authenticated, auditable event rather than an unauthenticated "trust this new address". 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Identity anchor The hardware-bound cryptographic identity (e.g. a JIS [JIS] .aint with an Ed25519 key) to which a session is bound, independent of any transport address. Bearer The underlying network access path (Wi-Fi, cellular, Ethernet, tethered, etc.) over which transport packets travel. Transport endpoint The address/port currently used to carry signalling or media. An implementation detail, expected to change. Control channel A stable, address-independent, authenticated channel van de Meent & AI Expires 23 December 2026 [Page 3] Internet-Draft Bearer Handover June 2026 over which signalling and re-anchor requests travel; it survives a bearer change (for example an overlay that is reachable by name rather than by IP). Media anchor The default-routed party (typically the calling system's own media engine) that the moving endpoint re-points its media to; it is not a neutral third-party relay. Re-anchor The authenticated act of re-establishing an existing session's media path onto a fresh transport after a bearer change. 3. Model An identity-anchored session is described by three independent planes: * Identity plane: who the parties are. Proven per the identity system; the constant across the session. * Control plane: signalling and re-anchor requests, carried on the stable control channel; authenticated, address-independent. * Media plane: the real-time encrypted stream; its transport address is expendable and expected to change. Continuity is the property that the identity and control planes persist across a media-plane transport change. The session key is shared in the identity/control plane and is not renegotiated on a mere transport change; only the transport binding is refreshed. 4. Handover Procedure When an endpoint in an active session detects that its default bearer or local transport address has changed, it performs the following: 1. Detect: the endpoint observes a new default network / local address (for example via an OS connectivity callback). Transient flaps SHOULD be debounced so a single switch yields a single re- anchor. 2. Re-anchor request: over the stable control channel, the endpoint sends an authenticated request to refresh the transport of the existing session (equivalent to a re-offer / ICE restart). The request is bound to the identity anchor, not to either transport address. van de Meent & AI Expires 23 December 2026 [Page 4] Internet-Draft Bearer Handover June 2026 3. Transport refresh: the media anchor accepts the refreshed transport for the existing session and prepares to relearn the media source. 4. Resume: encrypted media flows over the new transport using the existing key context. The interruption SHOULD be bounded (an implementation target on the order of a few hundred milliseconds). Because the dialog's transport is refreshed (not just a parallel re- registration), an in-dialog teardown after the change travels over the live transport and reaches the far end, avoiding stuck sessions. 5. Cryptographic Anchoring of Media Permitting the far end to relearn the media source from a new address (symmetric source latching) is unsafe over unauthenticated media: an attacker who can send packets from a new address could capture the stream. This document REQUIRES that media be encrypted and authenticated (for example SRTP [RFC3711] or an equivalent AEAD media profile) for source relearning to be enabled. With authenticated media, source relearning is safe: a substituted or injected stream fails the media authentication and is discarded, while the legitimate endpoint - which holds the session key - continues to verify. The key, not the address, is therefore the anchor. The session key-exchange material travels in the control plane (carried inside the authenticated, address-independent control channel), so a bearer change does not require a new key exchange. 6. Signed Transport-Rebind Event A handover MAY be recorded as a signed control event so that the set of transport transitions for a session is auditable: who moved, between which bearer classes, at what point in the media sequence, signed by the moving device's identity key. Such events are an instance of a semantic surface manifest [SSM] and MAY be sealed into a provenance trail [TIBET]. A non-normative shape: { "type": "transport.rebind", "session_id": "...", "reason": "wifi_to_cellular", "old_path": { "bearer": "wifi" }, "new_path": { "bearer": "cellular" }, "media_window": { "last_seq": 19420, "resume_seq": 19421 }, "auth": { "device": "jis:device:...", "signed_at": "..." } } van de Meent & AI Expires 23 December 2026 [Page 5] Internet-Draft Bearer Handover June 2026 The signed event is a proof-plane artifact; it MUST NOT be required to carry media and MUST NOT gate the media handover itself. A failure to record the event MUST NOT interrupt the live session. 7. Deliberate Re-Anchor (Moving Target) The same authenticated re-anchor MAY be invoked deliberately rather than only in response to a bearer change. Because the key is the anchor, rotating the media transport mid-session presents a moving target: an observer has no fixed transport binding to lock onto. Each deliberate re-anchor incurs the same brief media interruption as a bearer-driven one; this is a defensive option, not a default behaviour, and its cadence is an implementation and policy choice. 8. Security Considerations Source-substitution (latching): as stated in [RFC3711]-protected operation above, source relearning MUST be enabled only for authenticated media. Without media authentication, an endpoint MUST NOT relearn the media source from a new address mid-session. Re-anchor authentication: a re-anchor request MUST be authenticated to the session's identity anchor over the control channel; an unauthenticated "move my media to address X" is an obvious hijack primitive and MUST be rejected. A failed authentication SHOULD be treated as an offence, not as a retriable transient, so the mechanism cannot be abused as a denial of service. Privacy of transition metadata: a signed transport-rebind event reveals coarse bearer-class transitions (for example Wi-Fi to cellular). Such events SHOULD carry only bearer-class hints in any outward-visible surface and keep finer detail in the sealed manifest, consistent with [SSM]. Relay avoidance: by not mandating a central media relay, this method removes a single interception/interruption point from the media path. When a relay is unavoidable (for example endpoints behind symmetric NAT with no reachable anchor), it is a last-resort fallback and SHOULD be authenticated to the same identity anchor. 9. IANA Considerations This document has no IANA actions. 10. References van de Meent & AI Expires 23 December 2026 [Page 6] Internet-Draft Bearer Handover June 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004, . [RFC8656] Reddy, T., Johnston, A., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN)", RFC 8656, February 2020, . [JIS] van de Meent, J., "JIS: JTel Identity System", Work in Progress, Internet-Draft, draft-vandemeent-jis-identity, 2026, . [MUX] van de Meent, J., "MUX Status Frame: Two-Way Reachability Signalling without an Enumeration Oracle", Work in Progress, Internet-Draft, draft-vandemeent-mux-status- frame, 2026, . [SSM] van de Meent, J., "TIBET Semantic Surface Manifest", Work in Progress, Internet-Draft, draft-vandemeent-tibet- semantic-surface-manifest, 2026, . [TIBET] van de Meent, J., "TIBET Provenance", Work in Progress, Internet-Draft, draft-vandemeent-tibet-provenance, 2026, . Authors' Addresses Jasper van de Meent Humotica Netherlands Email: jasper@humotica.com URI: https://humotica.com van de Meent & AI Expires 23 December 2026 [Page 7] Internet-Draft Bearer Handover June 2026 Root AI Humotica Email: root_ai@humotica.nl URI: https://humotica.com van de Meent & AI Expires 23 December 2026 [Page 8]