Secure Telephone Identity Revisited C. Wendt Internet-Draft Somos, Inc. Intended status: Informational 1 November 2026 Expires: 5 May 2027 Securing SIP and RTP with STIR Certificates draft-wendt-stir-secure-sip-rtp-00 Abstract Certificates issued within the Secure Telephone Identity Revisited (STIR) framework establish, through a governed issuance process, that a party holds authority over telephone numbers or a service provider code, and where a domain identifier is bound to that authority, that the same party controls a domain. This document defines a certificate profile for TLS built on the TNAuthList extension and on the binding of telephone number authority to a domain identifier, so that the provider operating an interface is identified by a service provider code and by a validated domain rather than by prior arrangement between the parties, and it specifies the use of TLS, mutual TLS, and media protection across that interface. It applies to the network to network interface between providers. It brings the use of TLS with SIP up to date with TLS 1.3 and current certificate identity practice, and places the issuance of the credentials on which interconnection depends within a defined governance and issuance framework. 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 5 May 2027. Wendt Expires 5 May 2027 [Page 1] Internet-Draft Securing SIP and RTP with STIR November 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Existing Specification Landscape . . . . . . . . . . . . 6 3.1. Core SIP Documents . . . . . . . . . . . . . . . . . . . 6 3.2. Certificate Identity and Connection Management . . . . . 6 3.3. TLS and Service Identity . . . . . . . . . . . . . . . . 7 3.4. Telephone Number Authority in Certificates . . . . . . . 7 3.5. Media Protection . . . . . . . . . . . . . . . . . . . . 8 4. Certificates for SIP over TLS . . . . . . . . . . . . . . . . 8 4.1. Domain Identity . . . . . . . . . . . . . . . . . . . . . 8 4.2. Names in the Certificate . . . . . . . . . . . . . . . . 9 4.3. Binding Domain Identity to Telephone Number Authority . . 10 4.4. Certificate Contents . . . . . . . . . . . . . . . . . . 11 5. Algorithms and TLS 1.3 . . . . . . . . . . . . . . . . . . . 12 5.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 12 5.2. Key Agreement . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Signature Algorithms and Certificates . . . . . . . . . . 13 5.4. Interoperability Considerations . . . . . . . . . . . . . 14 5.5. The Post-Quantum Transition . . . . . . . . . . . . . . . 14 6. Securing the Media . . . . . . . . . . . . . . . . . . . . . 15 6.1. Media Security Baseline . . . . . . . . . . . . . . . . . 15 6.2. Properties of the Two Mechanisms . . . . . . . . . . . . 17 6.2.1. Protection Across the Interface . . . . . . . . . . . 18 6.2.2. Propagation of Keying Material Beyond the Interface . . . . . . . . . . . . . . . . . . . . . . 18 6.2.3. Operational Cost . . . . . . . . . . . . . . . . . . 19 6.2.4. Selecting a Mechanism . . . . . . . . . . . . . . . . 19 6.3. Requirements for Signaling Anchored Keying . . . . . . . 20 6.4. Relationship to the Existing Best Practice . . . . . . . 20 6.5. Key Agreement for Media . . . . . . . . . . . . . . . . . 21 6.6. Termination of Media Security Associations . . . . . . . 21 Wendt Expires 5 May 2027 [Page 2] Internet-Draft Securing SIP and RTP with STIR November 2026 6.7. Keying Mechanisms and Deployed Equipment . . . . . . . . 22 7. Media Resilience . . . . . . . . . . . . . . . . . . . . . . 23 8. Identified Protocol Gaps . . . . . . . . . . . . . . . . . . 23 9. Mutual TLS and Peer Authorization . . . . . . . . . . . . . . 25 9.1. Authentication . . . . . . . . . . . . . . . . . . . . . 25 9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 25 9.3. Interconnection Without Prior Arrangement . . . . . . . . 26 9.4. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 27 9.5. Limiting Issuance for an Interface Domain . . . . . . . . 27 10. Connection Management . . . . . . . . . . . . . . . . . . . . 27 10.1. Connection Reuse . . . . . . . . . . . . . . . . . . . . 28 10.2. Client Authentication and the Handshake . . . . . . . . 28 10.3. Long Lived Connections . . . . . . . . . . . . . . . . . 28 10.4. Server Name Indication . . . . . . . . . . . . . . . . . 28 11. Operational Considerations . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 15.1. Normative References . . . . . . . . . . . . . . . . . . 30 15.2. Informative References . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction Interconnection between telephone service providers is moving onto the public internet, and increasingly onto arrangements in which any provider may exchange traffic with any other without a bilateral agreement having been established in advance. A provider operating such an interface needs to determine, at the moment a connection is presented to it, which provider is at the other end and whether it is prepared to exchange traffic with that provider. Where no agreement precedes the connection, the receiving provider holds no configuration describing the peer, and both determinations have to be made from what the peer presents. A certificate carrying the TNAuthList extension [RFC8226] asserts authority over telephone numbers or a service provider code, and is issued only after an authority responsible for those numbers has validated that assertion. Where the certificate additionally carries a domain identifier bound to that authority [I-D.wendt-stir-tn-domain-binding], the issuer has validated control of the domain in the same act, so the certificate identifies a provider by a service provider code and by a domain that a relying party can verify. The governance and issuance policy under which such certificates are granted is what determines who may obtain one, and therefore who may participate. Participation is established by holding a credential rather than by agreement between the parties. Wendt Expires 5 May 2027 [Page 3] Internet-Draft Securing SIP and RTP with STIR November 2026 What has been missing is a specification of how that credential is used at the interface itself: what a certificate presented for TLS contains, how a peer authenticates it, what a peer is entitled to conclude from it, and how the signaling and media it protects are secured. This document supplies that. The specifications defining the use of TLS with SIP are a further obstacle. SIP [RFC3261] has supported TLS since publication, and the documents describing how that support works were largely complete by 2010. TLS 1.3 [RFC9846] has since replaced the handshake, removed renegotiation, and encrypted the certificate exchange; guidance for representing and verifying service identity in certificates was revised and republished as [RFC9525], narrowing the identifier types in scope and removing practices the SIP documents still permit; recommendations for the secure use of TLS were consolidated in [RFC9325]; earlier TLS versions were deprecated [RFC8996]; and post- quantum key agreement has been introduced. None of these changes were made with SIP in mind, and none of the SIP documents have been revisited in light of them. Implementations have diverged accordingly. Deployments make locally reasonable choices about which certificate identifier to populate and which to check, whether and how to require a client certificate, and how to decide that a presented certificate belongs to a peer whose traffic they will carry. Interconnection is then arranged bilaterally, and commonly falls back to address based access control, with TLS providing confidentiality but not a usable peer identity. A further reason for this document is the transition to post-quantum cryptography. [NIST.IR.8547] deprecates the elliptic curve and RSA algorithms in current use for both key establishment and signatures after 2030 and disallows them after 2035. The SIP and STIR specifications predate that timeline, and interconnection equipment deployed now will be in service through it. This document identifies where the transition touches SIP over TLS, SRTP, and STIR, and what each step depends on, so that the pieces can be taken up in the forums that own them. This document therefore does three things. It sets out the specifications that define the use of TLS and of media protection with SIP, and where each has been overtaken. It defines a profile of current practice for the interface between providers, including the certificate profile described above and the protection of both signaling and media across that interface. And it identifies the points at which existing specifications require change rather than profiling, which it does not undertake here. Wendt Expires 5 May 2027 [Page 4] Internet-Draft Securing SIP and RTP with STIR November 2026 1.1. Scope This document is about the certificates used for TLS between providers and what a peer concludes from them: what a certificate contains, how its subject is validated, how a peer authenticates and authorizes the party presenting it, and how the signaling and media it protects are keyed. The use of TLS as a SIP transport, including the TLS version, cipher suites, and how a certificate identifier is matched against a SIP domain, is specified by [I-D.wendt-sipcore-tls-updates]; this document narrows those rules for the interface it covers and does not restate them. It does not define new TLS mechanisms, new certificate extensions, or new cryptographic algorithms. Where this document recommends a behavior that differs from an existing specification, it identifies that specification and the nature of the difference; it does not formally update those documents. This document applies to the network to network interface, that is, to the signaling and media exchanged between the border elements of two interconnected providers. It covers the protection of both signaling and media across that interface, since the trust in each derives from the same credential and the protection of one bounds what the other achieves. The user to network interface, between a provider and its own subscribers, is out of scope. So is the treatment of signaling and media within a provider's network. This scoping is deliberate and distinguishes this profile from work that sought protection between user agents: at the network to network interface the two border elements are the endpoints of the segment being protected, and no intermediary lies between them to terminate a security association. Protection described here applies to a single interface between two adjacent providers. Where a communication traverses more than one such interface, each is protected independently. This document does not provide, and does not claim, confidentiality between the calling and called parties. This document does not define SRTP transforms or RTP payload formats, which are specified elsewhere and referenced here. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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. Wendt Expires 5 May 2027 [Page 5] Internet-Draft Securing SIP and RTP with STIR November 2026 3. The Existing Specification Landscape This section surveys the documents that together define the use of TLS with SIP, and notes for each what it establishes and what has changed since. 3.1. Core SIP Documents [RFC3261] defines TLS as a SIP transport and the "sips" URI scheme that requests its use. Section 26 sets out the security architecture, including the expectation that peers inspect each other certificates on interdomain connections. Its transport requirements were written against TLS 1.0 [RFC5246] and its mandatory cipher suite, TLS_RSA_WITH_AES_128_CBC_SHA, uses static RSA key exchange, which does not exist in TLS 1.3. The base specification therefore states a mandatory floor that a conforming modern implementation cannot meet. [RFC3263] defines how a SIP URI is resolved to a transport, address, and port using NAPTR and SRV records, and is the mechanism by which a TLS connection target is selected. Because the name used to reach a host can differ from the name in the URI that was resolved, the resolution procedure and the certificate matching procedure interact, and that interaction is a recurring source of implementation disagreement. [RFC5630] clarifies the semantics of the "sips" URI scheme, which [RFC3261] left open to more than one reading. It establishes that "sips" requests TLS on each hop toward the target domain rather than end to end. 3.2. Certificate Identity and Connection Management [RFC5922] is the central document for certificate identity in SIP. It specifies which identifiers in a certificate may represent a SIP domain and how they are compared against the domain being reached. It establishes that a SIP domain identity SHOULD be conveyed as a subjectAltName of type uniformResourceIdentifier containing a "sip" URI with no user part, that a dNSName entry is accepted only if no matching "sip" URI entry is present, and that the Subject common name may be examined only if no subjectAltName appears at all. It also specifies the behavior of a peer that accepts a connection and authenticates the sending domain, which is the basis for mutual authentication in SIP as it exists today. Two of those rules are now in conflict with [RFC9525], which obsoletes the general service identity guidance that [RFC5922] was written against. [RFC9525] establishes that service identity can be Wendt Expires 5 May 2027 [Page 6] Internet-Draft Securing SIP and RTP with STIR November 2026 expressed only in the subjectAltName extension and that the common name is no longer valid for this purpose, and it scopes itself to identifiers expressed as domain names, IP addresses, and SRV service names. A "sip" URI entry is outside that scope. The result is that the identifier type [RFC5922] prefers is not covered by current service identity guidance, while the identifier type it treats as a fallback, dNSName, is the one that general purpose TLS implementations actually verify. [RFC5923] defines connection reuse, allowing a TLS connection established in one direction to carry requests in the other. It requires that both peers be authenticated for such reuse, and is therefore the principal reason mutual TLS is used in SIP. It was written against a TLS version in which a server could request a client certificate through renegotiation, an option TLS 1.3 does not provide. [RFC5924], an Experimental specification, defines an extended key usage, id-kp-sipDomain, marking a certificate as issued for SIP domain use and restricting the names in that certificate to use by a SIP service. Its deployment is limited, and the consequences of its presence or absence in a certificate used for SIP are not treated consistently. 3.3. TLS and Service Identity [RFC9846] defines TLS 1.3, which changes several properties the SIP documents assume: the handshake is restructured, renegotiation is removed in favor of post-handshake authentication, the certificate is encrypted, and session resumption and early data are redefined. [RFC9325] provides current recommendations for the secure use of TLS, and [RFC8996] deprecates TLS 1.0 and 1.1. [RFC6066] defines the server name indication extension, which is relevant wherever a single host serves more than one SIP domain, a case [RFC5922] anticipates through multiple certificate identities rather than through a negotiated server name. 3.4. Telephone Number Authority in Certificates [RFC8226] defines the TNAuthList certificate extension, which conveys the telephone numbers, number ranges, or service provider codes for which a certificate holder is authorized. Although developed for signing PASSporTs, the extension is non critical and carries no restriction on the protocols in which the certificate may be used. [RFC9060] defines delegation of that authority to a subordinate certificate. Wendt Expires 5 May 2027 [Page 7] Internet-Draft Securing SIP and RTP with STIR November 2026 [I-D.wendt-stir-tn-domain-binding] defines a binding between telephone number authority and a domain identifier, established by an issuing certification authority that validates control of the domain and a telephone number authority token within a single issuance, so that the resulting certificate attests that the same entity holds both. 3.5. Media Protection The protection of media is defined separately from the protection of signaling, and the relationship between them determines what protecting the signaling achieves. [RFC3711] defines SRTP. Where keys for SRTP are carried in the session description [RFC4568], the confidentiality of the media depends entirely on the protection of the signaling that carries them. Where DTLS-SRTP [RFC5763] is used, the signaling carries only a certificate fingerprint [RFC8122] and the media keys are established in the media plane. A substantial amount of interconnected traffic uses neither, and carries media with no protection at all. [RFC8643] defines an opportunistic approach for negotiating SRTP where support is not known in advance, intended as a transitional mechanism for deployments moving toward encrypted media. [RFC8862] is the current best practice for securing media signaled with SIP. It requires DTLS-SRTP, and defines a profile of STIR in which a verification service confirms that the fingerprints carried in the session description match the keys exchanged in the DTLS-SRTP handshake, using the PASSporT mky claim to protect those fingerprints and an msec PASSporT type to signal compliance. It was written for an endpoint to endpoint model in which user agents implement both STIR roles, and it predates DTLS 1.3 [RFC9147] and the introduction of post-quantum key agreement. It also observes that media relays and back to back user agents frequently terminate media security associations, so that only hop by hop confidentiality is achievable in many deployments [RFC7879]. 4. Certificates for SIP over TLS 4.1. Domain Identity A certificate used under this profile carries the domain of the interface in a subjectAltName dNSName entry, and a peer verifying the certificate verifies that entry, following the representation and matching rules of [I-D.wendt-sipcore-tls-updates]. The subjectAltName entry of type uniformResourceIdentifier containing a "sip" URI, which [RFC5922] prefers, is not used at this interface. Wendt Expires 5 May 2027 [Page 8] Internet-Draft Securing SIP and RTP with STIR November 2026 The identities carried in signaling across this interface are telephone numbers, expressed as a "tel" URI or as a "sip" URI with the user=phone parameter, in which the host portion identifies the domain to which the request is routed rather than forming part of the identity. A telephone number carries no domain of its own, and no association between a telephone number and a domain can be derived from the number itself. That association is established at issuance by the binding described in [I-D.wendt-stir-tn-domain-binding], which is why a separate binding is required here and is not required for an identity of the form user@domain, where the domain is part of the identity. The identity a peer verifies at this interface is therefore a domain name, and it is the same identifier the binding associates with telephone number authority. The domain that authenticates the transport peer and the domain that corroborates the entity holding the telephone numbers are the same value in the same certificate, verified by the same path validation. 4.2. Names in the Certificate A certificate used under this profile can carry two kinds of name: a domain, and telephone number authority. Both appear in the certificate and both are examined by a peer, and this section says what each establishes. The domain is the identifier a peer verifies. A provider publishes a domain at which its interface is reached, and a connecting peer verifies that domain against the presented certificate. Separately, a provider holds a certificate binding a domain to the telephone numbers or service provider code it is authorized for. A provider that operates its interface under a domain it also has bound presents one certificate that serves both, and a peer that validates it learns both which party it is connected to and what that party is authorized for. Where the two domains differ, a peer learns less. If the interface is operated under a domain that carries no bound telephone number authority, validating the certificate establishes which party operates the interface and nothing about its authority over telephone numbers. A provider whose interface is operated on its behalf by another party, under that party's domain, is in this position, as is a provider that has bound one domain to its numbers and publishes its interface under another. An element accepting a connection under this profile MUST therefore determine which of these cases applies rather than assume the first. Where the certificate presented for the connection is a bound Wendt Expires 5 May 2027 [Page 9] Internet-Draft Securing SIP and RTP with STIR November 2026 certificate and the domain matched for the connection is the bound domain, the authorization determination of Section 9 applies to the party at the other end of the connection. Where it is not, the authenticated identity is that of the party operating the interface only, and any determination about telephone number authority is made from the credential presented with each communication rather than from the transport connection. Deployments SHOULD operate an interface under a domain bound to the telephone number authority of the provider on whose behalf traffic is carried, so that the transport connection and the traffic carried over it are attributable to the same party. Where an interface is operated by one party on behalf of another, that arrangement is visible to a peer as the difference described here, and this profile does not treat it as an error. Telephone number authority is carried in the TNAuthList extension [RFC8226], conveying the telephone numbers, number ranges, or service provider codes for which the subject is authorized. TNAuthList is a non critical extension, so a TLS implementation that does not recognize it ignores it and path validation is unaffected. [RFC8226] places no restriction on the protocols in which such a certificate may be used, and anticipates its use by protocols other than the ones for which it was defined. In an interconnect context the useful content is typically a service provider code identifying the provider operating the SIP endpoint. Where a certificate is scoped to specific telephone numbers, it is issued as a delegate certificate [RFC9060] whose scope is encompassed by that of its parent. Of the identifiers a certificate can carry, this profile uses one for peer verification: the subjectAltName dNSName entry. The subjectAltName uniformResourceIdentifier entry carrying a "sip" URI, which [RFC5922] prefers, and the Subject common name are not used. Telephone number authority is read from the TNAuthList extension and is never used as a name to match. 4.3. Binding Domain Identity to Telephone Number Authority A certificate carrying both a domain identifier and telephone number authority asserts more than either alone only if the two were validated together. [I-D.wendt-stir-tn-domain-binding] defines that binding: the issuing certification authority validates control of the domain and validates an authority token covering the telephone numbers or service provider codes, and treats the two as a single condition for issuance. The resulting certificate attests that the same entity holds both. Wendt Expires 5 May 2027 [Page 10] Internet-Draft Securing SIP and RTP with STIR November 2026 This is the property that makes mutual TLS useful between interconnected networks. Verifying a peer certificate establishes which domain the peer is, and [RFC5922] already specifies how to match it. What it does not establish is whether that domain is entitled to originate traffic for a given provider or set of numbers, which is why interconnect arrangements are made bilaterally and enforced by address. A bound certificate carries that authorization in the credential itself, validated by an issuer against the numbering authority. 4.4. Certificate Contents A certificate used under this profile carries the following: * A subjectAltName dNSName entry containing the SIP domain, as described above. * Where telephone number authority is asserted, a TNAuthList extension [RFC8226], bound to the domain identifier as described in [I-D.wendt-stir-tn-domain-binding]. * An extended key usage extension [RFC5280] containing id-kp- serverAuth where the certificate is presented when accepting a connection, id-kp-clientAuth where it is presented when initiating one, or both where one certificate is used for both roles. * A key usage extension containing digitalSignature. [RFC5924] defines id-kp-sipDomain to mark a certificate as issued for SIP domain use. Where it is present, it is present in addition to id-kp-serverAuth and id-kp-clientAuth rather than instead of them, since a TLS implementation that finds an extended key usage extension without the key purpose it requires will reject the certificate. A peer that both accepts and initiates connections, as is normal where connection reuse is in use, MAY present one certificate carrying both key purposes or MAY hold two certificates, one for each role, with the same domain and the same telephone number authority in each. Both arrangements conform to this profile. The CA/Browser Forum has moved against issuing publicly trusted certificates carrying both id-kp-serverAuth and id-kp-clientAuth, and a certification authority that follows those requirements can issue for this profile only as two certificates. A certification authority issuing under [RFC8226] is not bound by those requirements, but permitting both arrangements lets either kind of issuer support the profile. Wendt Expires 5 May 2027 [Page 11] Internet-Draft Securing SIP and RTP with STIR November 2026 Separate certificates, with separate keying material, MUST be used for TLS session establishment and for PASSporT signing. Both certificates may be issued by the same certification authority, on the basis of the same validated domain control and telephone number authority, so the separation adds an issuance rather than a validation. The two keys are held in different places and their compromise has different consequences, as discussed in Section 12. The two certificates also differ in profile. A certificate used for TLS carries the extended key usage values described above, and a certificate used to sign PASSporTs carries the claim constraints and validity period appropriate to that use. A single certificate satisfying both sets of requirements would be constrained by neither. 5. Algorithms and TLS 1.3 5.1. Protocol Versions [I-D.wendt-sipcore-tls-updates] requires TLS 1.3 [RFC9846] for SIP and permits TLS 1.2 for interoperability. This profile narrows that for the interface it covers: TLS 1.3 MUST be used, and earlier versions MUST NOT be, including TLS 1.2, and including TLS 1.0 and 1.1 which are deprecated in any case [RFC8996]. Cipher suite selection is determined by TLS 1.3 itself; the recommendations of [RFC9325] apply where they concern configuration outside the cipher suite. This profile describes an interface that is newly deployed rather than an existing one being retrofitted, and requiring a single version removes the negotiation and downgrade considerations that supporting more than one entails. Two of the properties this profile depends on are available only in TLS 1.3. Ephemeral key agreement is unconditional, so the forward secrecy that Section 6.2 relies on is a property of the protocol rather than of the cipher suite selected. And the hybrid post-quantum key agreement groups referenced in Section 5.2 are defined for TLS 1.3, so a deployment negotiating an earlier version cannot meet the key agreement requirements of this profile. Existing interconnection interfaces commonly specify TLS 1.2, and equipment deployed for them may require updating before it can participate in an interface conforming to this profile. The version and cipher suite requirements of [RFC3261] predate TLS 1.3 and cannot be satisfied by a conforming TLS 1.3 implementation, as described in Section 3. Updating them is outside the scope of this profile and is specified in [I-D.wendt-sipcore-tls-updates]. Wendt Expires 5 May 2027 [Page 12] Internet-Draft Securing SIP and RTP with STIR November 2026 5.2. Key Agreement Key agreement determines whether traffic recorded today can be decrypted later. An adversary that records a TLS session and its handshake, and that later acquires the ability to solve the underlying problem the key agreement rests on, recovers the traffic keys. Ephemeral key exchange does not prevent this, because the property it provides is protection against later compromise of a long term key, not against the key agreement itself being broken. This matters more for SIP than for many applications, because the confidentiality lifetime of the traffic is long. Call detail, calling and called numbers, and call patterns retain sensitivity for many years, and where the media keys are carried in the session description [RFC4568] the confidentiality of the conversation itself depends entirely on the protection of the signaling that carried them. Implementations SHOULD therefore support a post-quantum key agreement group and SHOULD negotiate one where both peers support it. Either a hybrid group, which combines a post-quantum key encapsulation mechanism with an elliptic curve exchange so that the resulting secret is no weaker than the classical exchange alone, such as those defined in [I-D.ietf-tls-ecdhe-mlkem], or a group using a post- quantum mechanism alone, such as those defined in [I-D.ietf-tls-mlkem], satisfies this requirement. Which to prefer is a deployment choice; TLS 1.3 negotiates the group, so peers that prefer differently still agree on one both support. General guidance on adopting post-quantum cryptography in TLS based applications is given in [I-D.ietf-uta-pqc-app]. Where DTLS-SRTP [RFC5763] is used, the media keys are established in the media plane and the signaling carries only a fingerprint [RFC8122], from which nothing is recoverable. In that case post- quantum key agreement on the SIP connection protects signaling but not media, and equivalent protection of the media requires the same consideration in the media plane. 5.3. Signature Algorithms and Certificates Certificates under this profile continue to use classical signature algorithms. Forging a signature at some future point permits impersonation from that point forward; it does not permit decryption of traffic recorded earlier. The retroactive risk lies in key agreement, not in authentication, and the two can therefore be addressed on different timescales. This also avoids the substantially larger certificates and handshakes that post-quantum signature algorithms currently entail. Wendt Expires 5 May 2027 [Page 13] Internet-Draft Securing SIP and RTP with STIR November 2026 Different timescales do not mean authentication can be left as it is. A signature verified today on a certificate or a PASSporT is relied on later, in records of which party connected and which party signed a communication, and an adversary that can later forge the signature can later dispute or fabricate those records. Section 5.5 sets out the order in which the transition applies to this interface and what the signature step depends on. 5.4. Interoperability Considerations Post-quantum and hybrid key agreement produce larger key shares than elliptic curve groups, which increases the size of the ClientHello and can cause it to be split across more than one packet. Implementations and intermediaries that assume a ClientHello arrives in a single record or a single datagram may fail in ways that are difficult to diagnose. SIP interconnection commonly traverses session border controllers and firewalls, so this population warrants testing rather than assumption. An implementation that encounters a key agreement group it does not recognize is expected to select one it does support rather than to fail the handshake. Implementations that reject unknown groups outright prevent peers from offering new ones and should be identified during interoperability testing. Early data, or 0-RTT, MUST NOT be used for SIP. Early data is replayable by design, and SIP requests are not safe to replay. 5.5. The Post-Quantum Transition [NIST.IR.8547] sets a timeline for moving off the quantum-vulnerable algorithms in current use: ECDSA, EdDSA, and RSA for signatures, and ECDH, finite field DH, and RSA for key establishment are deprecated after 2030 and disallowed after 2035. The equipment deployed under this profile will be in service across those dates. Neither the SIPCORE nor the STIR working group is the forum for selecting post-quantum algorithms or their parameters. That work belongs to the TLS, LAMPS, and JOSE working groups, to NIST, and to the CA/Browser Forum for the Web PKI, and it is still settling. This document therefore does not name post-quantum algorithms beyond the key agreement groups already referenced in Section 5.2, which are the part of the picture that has settled enough to deploy. What it does is state where the transition touches this interface, in what order, and what each step depends on, so that SIP and STIR follow the Web PKI as it settles rather than diverging from it. Wendt Expires 5 May 2027 [Page 14] Internet-Draft Securing SIP and RTP with STIR November 2026 Key agreement comes first, because it is the retroactive risk. Signaling and media recorded today can be decrypted later by an adversary that later obtains the ability to break the key agreement, and the confidentiality lifetime of call records is long. Section 5.2 and Section 6.3 already require post-quantum key agreement where both peers support it. That requirement depends on nothing outside TLS 1.3 and DTLS 1.3 and can be met now. Signatures come second. Forging a signature at some future point permits impersonation and the fabrication of records from that point forward; it does not permit decryption of traffic already recorded. The transition can therefore follow the Web PKI's, and it has more dependencies: a post-quantum signature algorithm registered for X.509 by LAMPS, a certificate profile for STI certificates that permits it, a JOSE algorithm registration so that PASSporTs can be signed with it, and TLS signature scheme registrations for the handshake. The larger certificates and signatures that post-quantum algorithms entail also bear on SIP in a way they do not bear on the web: a PASSporT travels in a SIP header field, and the certificate chain in a TLS handshake traverses session border controllers with their own size limits. Those effects need measurement before a requirement is written. Certificate transparency is part of the signature transition. STI certificate transparency [I-D.ietf-stir-certificate-transparency] is built on [RFC6962], whose log signatures and Merkle tree hashes are classical. The IETF's work on post-quantum transparency logs, in the PLANTS working group, is where that transition is being worked out, and STI certificate transparency is expected to follow it rather than define its own. Implementations under this profile SHOULD be built so that the signature algorithm, the key agreement group, and the certificate chain size they accept are configurable rather than fixed, and SHOULD support the negotiation mechanisms that let a peer offer a new algorithm without failing the handshake with a peer that lacks it, as described in Section 5.4. That is the property that lets the transition proceed by configuration when the dependencies above are met. 6. Securing the Media 6.1. Media Security Baseline Media across the interface MUST be protected using SRTP [RFC3711]. Two mechanisms for establishing the SRTP keys are in use, and both are supported by this profile. Wendt Expires 5 May 2027 [Page 15] Internet-Draft Securing SIP and RTP with STIR November 2026 Signaling anchored keying, using security descriptions carried in the session description [RFC4568], places the SRTP master keys in the SIP signaling. It is the mechanism in general use at interconnection interfaces today. Where it is used, every element on the signaling path holds the media keys, and the confidentiality of the media is therefore no stronger than the protection of the signaling on every hop that carries it. Media anchored keying, using DTLS-SRTP [RFC5763] [RFC5764], establishes the SRTP keys through a handshake on the media path. The signaling carries only a fingerprint of the endpoint credential [RFC8122], from which the keys cannot be derived. Either mechanism MAY be used. Both provide equivalent protection of the media against an attacker on the interface itself when the requirements of this profile are met. They differ in how far the keying material propagates beyond that interface, and in operational cost. Section 6.2 sets out both so that a deployment can select on the basis of what it is exposed to. Where signaling anchored keying is used, the requirements of Section 6.3 apply. Where a peer is not known to support media protection at all, [RFC8643] MAY be used to negotiate it opportunistically. This is a transitional measure for moving deployments away from unprotected media, not a durable configuration, and it provides no protection against an attacker able to modify the signaling. This document does not define SRTP transforms. A transform is the pair of algorithms SRTP applies to each packet, one to encrypt the payload and one to authenticate the packet, and the transforms available are defined separately from the keying mechanisms that establish the master key. [RFC3711] defines AES in counter mode with HMAC-SHA1 authentication, [RFC6188] adds AES with 192 and 256 bit keys in counter mode, and [RFC7714] defines AES-GCM, in which encryption and authentication are performed as a single authenticated encryption operation. Further transforms are under development in the IETF. A transform is not negotiated directly. It is selected through a named set that also fixes the key length, the salt length, and the length of the authentication tag: a crypto suite where security descriptions are used [RFC4568], or a protection profile where DTLS- SRTP is used [RFC5764]. Both are registered with IANA. The transform in most common use at interconnection interfaces today, AES_CM_128_HMAC_SHA1_80, authenticates packets with HMAC-SHA1. SHA-1 has been withdrawn by NIST and is no longer considered secure. Implementations MUST support an AES-GCM transform [RFC7714] and Wendt Expires 5 May 2027 [Page 16] Internet-Draft Securing SIP and RTP with STIR November 2026 SHOULD negotiate it where both peers support it. Where an HMAC-SHA1 transform is negotiated for interoperability with a peer that supports nothing else, the deployment accepts that packet authentication rests on a withdrawn algorithm. A transform that does not rest on SHA-1 for either function is expected from the IETF, and this profile will reference it when it is available. 6.2. Properties of the Two Mechanisms The two mechanisms are equivalent in most respects and differ in one that is a security property and two that are operational. A deployment selects between them on the basis of what it is exposed to, and both are permitted by this profile. The difference is smaller at this interface than the design of media anchored keying suggests. Media anchored keying was specified for use with SIP, but its mandatory use and its deployment at scale followed from browser based communications, in which the signaling is carried by a party that is not a party to the media [RFC8827]. In that arrangement, keys placed in the signaling are disclosed to the signaling party by construction, and withholding them from the signaling is the property the mechanism exists to provide. At the interface described here the two parties to the signaling are the two parties to the media, and no third party is present in the signaling path from which keys need to be withheld. That property is therefore already provided by the topology, and the differences that remain are the ones described below. Arrangements in which media is exchanged among more than two elements are a further reason media anchored keying is preferred in SIP deployments generally. Conference mixing, announcement and interactive response functions, recording, and transcoding introduce media paths that differ from the signaling path and involve elements that are not parties to the signaling. Those functions are performed within a provider's network, on legs other than the interconnection leg. The media association for a communication crossing the interface described here is between two elements. Where an intermediary is present at the interface itself, as in an arrangement where one provider receives traffic on behalf of another, that element terminates the association and re-originates it, which produces a sequence of two party legs rather than a media path shared among several elements. Wendt Expires 5 May 2027 [Page 17] Internet-Draft Securing SIP and RTP with STIR November 2026 6.2.1. Protection Across the Interface Where the signaling is protected as required by this profile, with TLS 1.3, mutual authentication, and ephemeral key agreement on every hop, the two mechanisms protect the media across the interface equally. In both cases the keys are held by the two border elements, which are the endpoints of the interface and hold the media in the clear regardless, so neither protects a provider against its peer. In both cases the channel that establishes or carries the keys provides forward secrecy, so an adversary that later obtains a long term private key recovers neither. In both cases the residual exposure is to a break of the key agreement itself, which is addressed for both by the requirements of Section 5. Neither mechanism therefore offers better protection than the other against an attacker observing the interface. 6.2.2. Propagation of Keying Material Beyond the Interface At this interface the signaling and the media are exchanged between the same two border elements, and commonly over the same path. An attacker positioned on that path observes both under either mechanism, and what it observes of the signaling is protected by TLS in both cases. The mechanisms therefore do not differ in what they expose to an attacker on the path. They differ in where the keying material exists after the exchange. Under media anchored keying the signaling carries only a fingerprint of the endpoint credential, from which no key can be derived, and the keys exist only in the elements that terminate the media. Under signaling anchored keying the keys are carried in the session description, and are therefore present wherever that signaling is present. Signaling is captured for tracing, retained for operational and regulatory purposes, and exported to monitoring, analytics, and accounting systems as a matter of ordinary operation. The keys consequently exist in data whose lifetime is unrelated to the duration of the communication and in systems that have no role in handling media. Wendt Expires 5 May 2027 [Page 18] Internet-Draft Securing SIP and RTP with STIR November 2026 The exposure this creates is compound rather than positional. An attacker that captures media from the path, and that at any later time obtains the corresponding signaling from a system that retained or received it, recovers the media. Capture from the path alone is not sufficient, and access to the retained signaling alone is not sufficient. Under media anchored keying the second does not assist the first, and media captured from the path remains unrecoverable regardless of what signaling is subsequently obtained. Signaling anchored keying also couples the two planes. Any failure to protect the signaling on any hop that carries the keys is a failure of media confidentiality, whereas under media anchored keying a compromise of the signaling discloses the fact and the parties of a communication but not its content. The requirements of Section 6.3 apply to the interface, but the handling of signaling within each provider's own network is outside the scope of this profile, and signaling is commonly carried there without protection. The condition on which signaling anchored keying depends is therefore one a deployment can satisfy at the interface and cannot verify beyond it. Media anchored keying does not depend on that condition. 6.2.3. Operational Cost Media anchored keying requires a handshake on the media path before media can flow. This adds to the delay before a communication is established and must be performed for every communication, which at interconnection volumes is a material load on the border element. Signaling anchored keying adds nothing beyond the signaling already exchanged. Authenticated encryption transforms bound the amount of data that may be protected under a single key, and long lived communications may approach that bound. Media anchored keying can rekey within the media plane. Signaling anchored keying requires a new offer and answer, which deployments are correspondingly less likely to perform. 6.2.4. Selecting a Mechanism A deployment whose interface traverses the public internet, or whose signaling is retained, exported, or handled beyond the interface in ways it cannot constrain, is exposed to the propagation described above and should weigh it accordingly. A deployment for which call setup delay or handshake load at the border is the dominant constraint, or which interconnects with peers that do not support DTLS-SRTP, has a corresponding reason to use signaling anchored keying. Wendt Expires 5 May 2027 [Page 19] Internet-Draft Securing SIP and RTP with STIR November 2026 Both mechanisms are in use and both are permitted here. What this profile requires in either case is that the protection on which the chosen mechanism depends is actually present: for signaling anchored keying, that every hop carrying the keys is protected as required by Section 6.3, and for both, that the key agreement protecting the communication meets the requirements of Section 5. 6.3. Requirements for Signaling Anchored Keying Where security descriptions [RFC4568] are used to establish SRTP keys, every signaling hop that carries the keys MUST be protected as described in Section 5. A deployment MUST NOT carry security descriptions over an unprotected signaling hop, and MUST NOT accept them on one. Because the media keys are present in the signaling, they are available to every element on the signaling path. A deployment using signaling anchored keying accepts that the confidentiality of the media extends only to parties outside that set of elements. 6.4. Relationship to the Existing Best Practice [RFC8862] defines the current best practice for securing media signaled with SIP, and this profile does not replace it. Where its conditions can be met, the binding it defines, in which a PASSporT carrying the mky claim protects the fingerprints in the session description, remains the strongest available assurance that the keys exchanged in the media plane are those the authenticated originator intended. Two of its assumptions do not hold in telephone network interconnection. It places the authentication and verification service roles in the user agents, whereas in interconnection those roles are commonly performed by provider infrastructure. And it observes that few certification authorities issue certificates for telephone numbers, which is no longer the case: the credential described in Section 4 is issued for exactly that purpose and is chained to an authority for the numbers concerned. The consequence is that the fingerprint binding of [RFC8862] can be performed using the same credential that authenticates the signaling peer and that carries telephone number authority. Where the media security association is not terminated between the signing entity and the verifying entity, this yields an assurance about the media that is anchored in the same certificate as the assurance about the identity. Wendt Expires 5 May 2027 [Page 20] Internet-Draft Securing SIP and RTP with STIR November 2026 6.5. Key Agreement for Media The DTLS handshake that establishes SRTP keys is subject to the same consideration described in Section 5.2 for signaling. An adversary that records the handshake and the media, and that later acquires the ability to break the key agreement, recovers the media keys and therefore the conversation. Implementations SHOULD support DTLS 1.3 [RFC9147] for DTLS-SRTP, and SHOULD negotiate a hybrid post-quantum key agreement group where both peers support it. Which key agreement protects the conversation depends on the keying mechanism. Under media anchored keying it is the one in the media handshake, and protecting the signaling alone does not protect the media. Under signaling anchored keying it is the one on every signaling hop that carries the keys, and a recorded communication is recovered in full if that key agreement is broken, since the media keys were carried within it. This is a difference in the number of operations an adversary performs rather than in the capability it requires: an adversary able to break the key agreement protecting the signaling is able to break the one protecting the media handshake, and where both are recorded from the same path, media anchored keying requires it to break the second as well rather than presenting a different obstacle. The requirement in this section applies to both handshakes for that reason. 6.6. Termination of Media Security Associations An assurance about media that is anchored at an originating endpoint is lost wherever an element terminates the media security association and re-originates the media, as described in [RFC7879]. This is the principal reason that end to end media security has not been achieved in telephone networks, and it is why [RFC8862] observes that only hop by hop confidentiality is available in many deployments. Within the scope of this profile the difficulty does not arise. The two border elements are the endpoints of the interface being protected, and no element lies between them to terminate the association. The assurance this profile provides is an assurance about one interface, established between the two providers that operate its endpoints. An assurance that survives termination by an intermediary, and therefore extends across more than one interface or into a provider's own network, is a different problem. It is identified in Section 8 and is not addressed here. Wendt Expires 5 May 2027 [Page 21] Internet-Draft Securing SIP and RTP with STIR November 2026 6.7. Keying Mechanisms and Deployed Equipment The two keying mechanisms are affected differently by the move to TLS 1.3 and by the post-quantum transition, and the difference reverses the usual ordering of their strength for the time being. Under signaling anchored keying, the media keys travel in the signaling, so whatever protects the SIP connection protects them. A border element that negotiates TLS 1.3 with a post-quantum key agreement group on its SIP connection has, by that act alone, protected the SRTP keys against later recovery. Nothing changes on the media path: the SRTP transform, the packet format, and the media gateway behind the border element are untouched. The exposure that remains is the one Section 6.3 describes, that every element on the signaling path holds the keys. Under media anchored keying, the media keys come from the DTLS handshake on the media path, and the protection of the SIP connection does not reach them. Until that handshake runs DTLS 1.3 with a post- quantum key agreement group, the media is protected by DTLS 1.2 key agreement, which is exactly the recorded-now-recovered-later exposure that Section 5.2 addresses for signaling. For the present, therefore, signaling anchored keying over a TLS 1.3 connection with post-quantum key agreement gives stronger protection against that attack than DTLS-SRTP as deployed, while DTLS-SRTP retains its advantage of keeping the keys off the signaling path. A deployment choosing between them should weigh which of the two it is more exposed to. What has to change in deployed equipment follows from this. For signaling anchored keying, the border element's TLS stack is the only thing that changes: TLS 1.3, the post-quantum key agreement groups, and the larger ClientHello they produce (Section 5.4). Media gateways and session border controllers that terminate SRTP need, at most, support for an authenticated encryption transform in place of HMAC-SHA1 (Section 6.1), which is a transform change rather than a keying change. For media anchored keying, the DTLS-SRTP implementation in the media path, which in telephone networks is a session border controller or media gateway rather than an endpoint, has to move to DTLS 1.3 and carry the same post-quantum groups, and the specification gap identified in Section 8 has to be closed first so that implementers converge on one behavior. That is a larger change, to equipment with longer replacement cycles than the border element's TLS stack, and it is why this profile treats post-quantum key agreement on the media handshake as a SHOULD that follows the signaling rather than a requirement that can be met now. Wendt Expires 5 May 2027 [Page 22] Internet-Draft Securing SIP and RTP with STIR November 2026 7. Media Resilience Telephone network interconnection increasingly traverses paths that are not engineered for loss, while the RTP profile in common use for interconnection predates the mechanisms developed for such paths. [RFC8834] profiles the use of RTP for browser based communications, and requires feedback and resilience mechanisms that interconnection deployments generally do not negotiate. The following are applicable to interconnected voice and are not precluded by anything in this profile: * Codec level redundancy, where the codec provides it. The in band forward error correction of Opus [RFC6716] recovers isolated losses at low cost, and is effective for speech where the codec is available. * Redundant encoding [RFC2198], which carries earlier payloads alongside current ones and is generally more efficient for speech than generic forward error correction. * Generic forward error correction [RFC8627], which is applicable but carries higher overhead for the packet sizes typical of voice. * RTCP feedback [RFC4585], and the corresponding profile for use with SRTP [RFC5124], without which a sender has no timely indication of loss and no basis for adaptation. Two constraints govern whether these are useful in practice. The first is codec availability: interconnection continues to carry a large volume of traffic using codecs that provide no in band redundancy, and the resilience available to such traffic is limited to mechanisms applied above the codec. The second is intermediary behavior: elements that transcode, that do not pass unrecognized payload types, or that do not forward RTCP feedback will defeat these mechanisms regardless of what the endpoints negotiate. Negotiation is where these mechanisms most often fail in practice rather than in their operation. This is the same pattern described for certificate identity in Section 3, and it is identified in Section 8 accordingly. 8. Identified Protocol Gaps The preceding sections describe what can be adopted as it stands and what this profile constrains. This section identifies where existing specifications require change, which this document does not undertake. Wendt Expires 5 May 2027 [Page 23] Internet-Draft Securing SIP and RTP with STIR November 2026 The TLS version and cipher suite requirements of [RFC3261], and the certificate identity rules of [RFC5922], cannot be reconciled with current TLS practice by profiling alone. Updates to both are specified in [I-D.wendt-sipcore-tls-updates]. The authorization of an authenticated peer, as distinct from its authentication, has no specification for SIP. [RFC5922] defines how a peer domain is matched but not how a receiving network determines that the domain is entitled to originate for a given provider or set of telephone numbers. This profile addresses that through the credential described in Section 4; whether a corresponding SIP level mechanism is required is left open. An identity assurance about media that survives termination of the media security association by an intermediary is not available. Whether one can be defined, and at what layer, is a question this profile identifies rather than answers. The use of DTLS-SRTP with DTLS 1.3 is not specified. [RFC5764] and the fingerprint handling of [RFC8842] were written against DTLS 1.2 [RFC6347], and the SRTP protection profiles and the use_srtp extension have not been restated for DTLS 1.3 [RFC9147], whose record layer and key schedule differ. The key exporter that [RFC5764] relies on survives in DTLS 1.3, so the mechanism is expected to carry over, but an implementer following the published specifications arrives at DTLS 1.2, and that is what deployed implementations run. The consequence for this profile is stated in Section 6.7. Several choices in this profile are about TLS and DTLS rather than about SIP, and are best judged by the working group responsible for those protocols. The TLS working group's review is sought on: requiring TLS 1.3 alone at a newly deployed interface; the treatment of post-quantum key agreement in Section 5.2, Section 5.5, and Section 6.7, including whether hybrid and pure groups should both be permitted; the client authentication and connection management choices of Section 10, which follow from the removal of renegotiation; the prohibition of early data; and the DTLS 1.3 gap above. Review by the working groups responsible for SRTP and for the DTLS-SRTP specifications is sought on the transform and keying questions of Section 6.1 and Section 6.7. The STIR working group is where the certificate and algorithm dependencies identified in Section 5.5 are coordinated, since the certificates are STIR certificates; the SIP transport changes that this profile narrows are the subject of [I-D.wendt-sipcore-tls-updates] in SIPCORE. Wendt Expires 5 May 2027 [Page 24] Internet-Draft Securing SIP and RTP with STIR November 2026 The negotiation of media resilience mechanisms for interconnection, and the behavior of intermediaries with respect to them, may require a profile or protocol work in the working group responsible for RTP. This document identifies the requirement and does not specify it. 9. Mutual TLS and Peer Authorization At the interface described by this profile both peers are providers, and each has the same interest in knowing which provider it is exchanging traffic with. Connections between border elements MUST therefore be mutually authenticated. The element initiating the connection MUST present a certificate conforming to Section 4, and the element accepting the connection MUST request one and MUST verify it. 9.1. Authentication A peer verifying a presented certificate MUST validate the certification path to a trust anchor it accepts, and MUST verify that the domain of the peer it expected to reach matches a dNSName entry in the certificate, applying the rules referenced in Section 4.1. Both steps are required. Validating the path alone establishes only that a certification authority the verifier trusts issued the certificate to some party, and for a widely trusted authority that is a large set of parties. A deployment that requests a client certificate but does not verify the name within it will accept any peer holding a certificate from any accepted authority. This configuration is known to occur. An accepting element MAY use the certificate authorities extension of the TLS CertificateRequest message [RFC9846] to indicate the trust anchors it accepts, which allows an initiating element that holds more than one certificate to present the appropriate one. 9.2. Authorization Authentication corroborates the domain of the peer. It does not establish that the peer is entitled to send the traffic it is sending. That is a separate determination, and one for which SIP provides no mechanism. Wendt Expires 5 May 2027 [Page 25] Internet-Draft Securing SIP and RTP with STIR November 2026 Where the presented certificate carries a TNAuthList extension [RFC8226] bound to the domain identifier as described in [I-D.wendt-stir-tn-domain-binding], the service provider code it contains identifies the provider operating the peer, as validated by the issuer rather than as asserted by the peer. An accepting element MAY use that value to determine whether the peer is one with which it has an interconnection relationship, and to apply the policy associated with that relationship. This is a determination about the provider operating the interface. It is not a determination about the telephone numbers of any individual communication, which remains the function of the STIR credential presented with that communication. An accepting element that applies both MAY require consistency between them, treating a communication whose signing credential is unrelated to the authenticated peer as a matter for local policy. 9.3. Interconnection Without Prior Arrangement This profile supports interconnection in which two providers exchange traffic without a bilateral arrangement established in advance. Where interconnection is bilateral, a provider authorizes a peer from local configuration: an address range, a pinned certificate, or a trust anchor provisioned for that peer. A provider receiving a connection from a participant with which it has not previously exchanged traffic has no such configuration to consult. Authorization therefore derives from the credential. A provider presenting a certificate that conforms to Section 4 and validates to a trust anchor the receiving provider accepts has demonstrated to its issuer control of the domain it presents and authority over the telephone numbers or service provider code the certificate asserts [I-D.wendt-stir-tn-domain-binding]. The set of trust anchors the participants accept in common determines the set of providers able to interconnect. The criteria under which certificates are issued and revoked are determined by the authority operating the certification hierarchy and are outside the scope of this document. Two consequences follow for an element implementing this profile. A participant is excluded by revocation of its certificate, or by the issuer declining to reissue it where short lived certificates are used, rather than by a configuration change at every peer. And validating a presented certificate does not oblige a provider to carry the traffic; local policy continues to apply, and a provider may decline traffic from an authenticated participant on any grounds. Wendt Expires 5 May 2027 [Page 26] Internet-Draft Securing SIP and RTP with STIR November 2026 9.4. Trust Anchors Certificates presented at this interface MUST be issued by a certification authority operating under [RFC8226], and an element MUST NOT accept a certificate for this interface on the basis of a trust anchor from a certification hierarchy that does not issue under [RFC8226]. A certificate used here carries telephone number authority in a TNAuthList extension, co-validated with a domain identifier [I-D.wendt-stir-tn-domain-binding]. A certification authority that validates only control of a domain does not validate authority over telephone numbers and cannot issue a certificate carrying that assertion. Accepting a trust anchor from such a hierarchy would admit any party that has demonstrated control of any domain. An element SHOULD be able to add a trust anchor in advance of its use, rather than in response to a handshake failure. 9.5. Limiting Issuance for an Interface Domain A provider that operates its interface under a domain can limit which certification authorities may issue certificates for that domain, and through which ACME account, by publishing a CAA record [RFC8659]. [I-D.wendt-stir-tn-domain-binding] defines the issuesti Property Tag for bound certificates, with the accounturi and validationmethods parameters of [RFC8657], and a certification authority issuing a bound certificate for use under this profile processes it as that document specifies. The issue and issuewild Properties of [RFC8659] do not govern these certificates, following the approach of issuemail [RFC9495], so a provider's existing CAA records for its Web PKI certificates neither block nor authorize them. Where domain control is validated with a standing record, as with the dns-persist-01 challenge [I-D.ietf-acme-dns-persist] that [I-D.wendt-stir-tn-domain-binding] lists, the CAA record and the validation record together name the certification authority and account the provider has authorized, in two records at the provider's domain. 10. Connection Management The items in this section are consequences of using the certificate for mutual authentication rather than properties of SIP over TLS generally. Connection reuse requires both peers to be authenticated, which requires the client certificate, which TLS 1.3 requires in the initial handshake. Wendt Expires 5 May 2027 [Page 27] Internet-Draft Securing SIP and RTP with STIR November 2026 10.1. Connection Reuse Connection reuse [RFC5923] allows a connection established in one direction to carry requests in the other, and requires that both peers be authenticated. That condition is met by Section 9, so reuse is applicable across this interface and SHOULD be used, since establishing a connection per direction doubles the handshake load and the number of connections to be maintained without adding any property. An element that reuses a connection applies the authorization determination of Section 9 to requests received on it in either direction. The authenticated identity of the peer does not change with the direction of a request. 10.2. Client Authentication and the Handshake In TLS 1.3 a server cannot obtain a client certificate by renegotiating an established connection, as renegotiation does not exist. An accepting element that requires client authentication MUST therefore request the certificate in the initial handshake. Post- handshake authentication is defined by [RFC9846] but is not widely implemented, and this profile does not rely on it. Early data MUST NOT be used, as stated in Section 5.4. 10.3. Long Lived Connections Connections between border elements are typically long lived, while the certificates used to establish them are not, particularly where the practices described in Section 11 are followed. Expiry of a certificate does not invalidate a connection already established under it, and an element SHOULD NOT tear down an established connection solely because the certificate that authenticated it has expired. The renewed certificate is presented at the next handshake. An element SHOULD perform a TLS key update on a long lived connection in accordance with the limits applicable to the negotiated cipher suite. 10.4. Server Name Indication Where a border element serves more than one domain on a single address, an initiating element SHOULD include the server name indication extension [RFC6066] carrying the domain it intends to reach, so that the accepting element can present the corresponding certificate. An accepting element that serves a single domain does not depend on it, and MUST NOT reject a connection solely because it Wendt Expires 5 May 2027 [Page 28] Internet-Draft Securing SIP and RTP with STIR November 2026 is absent. 11. Operational Considerations Certificates used for TLS under this profile are expected to be short-lived, as described in [I-D.ietf-stir-certificates-shortlived], and a border element renews its TLS certificate on the same cadence as its signing certificate. Renewal does not interrupt established connections (Section 10). Further operational considerations will be added as the profile is reviewed. 12. Security Considerations This profile relies on the security properties of TLS 1.3 [RFC9846], SRTP [RFC3711], DTLS-SRTP [RFC5763], and STIR certificates [RFC8226], and on the binding of domain identity to telephone number authority [I-D.wendt-stir-tn-domain-binding]. The considerations of those documents, and of [RFC9325] and [RFC9525], apply. Separate keys for TLS and for PASSporT signing are required because the two are held in different places and their compromise has different consequences. A TLS key is present on every border element, the most exposed and widely distributed part of a deployment, and its compromise permits impersonation at the transport layer until the certificate expires. A signing key asserts authority over telephone numbers, and its compromise permits an attacker to originate signed communications from any number within the certificate's scope. Using one key for both places the second consequence on every element that terminates TLS. The transform in common use for SRTP at interconnection interfaces authenticates packets with HMAC-SHA1, which NIST has withdrawn. Section 6.1 requires support for an authenticated encryption transform for that reason, and a replacement for the HMAC-SHA1 transforms is needed from the IETF. Further security considerations will be added as the profile is reviewed. 13. IANA Considerations This document has no IANA actions. Wendt Expires 5 May 2027 [Page 29] Internet-Draft Securing SIP and RTP with STIR November 2026 14. Acknowledgments Thanks to Russ Housley for his review of this document. 15. References 15.1. Normative References [I-D.wendt-sipcore-tls-updates] Wendt, C., "TLS 1.3 and Certificate Identity for the Session Initiation Protocol", Work in Progress, Internet- Draft, draft-wendt-sipcore-tls-updates-00, 1 November 2026, . [I-D.wendt-stir-tn-domain-binding] Wendt, C., "Binding a Domain Identifier to Telephone Number Authorization in STIR Certificates", Work in Progress, Internet-Draft, draft-wendt-stir-tn-domain- binding-02, 1 November 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, July 2002, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, DOI 10.17487/RFC5922, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Wendt Expires 5 May 2027 [Page 30] Internet-Draft Securing SIP and RTP with STIR November 2026 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, September 2021, . [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . 15.2. Informative References [I-D.ietf-acme-dns-persist] Heurich, S., Birge-Lee, H., and M. Slaughter, "Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation", Work in Progress, Internet-Draft, draft-ietf-acme-dns-persist-02, 20 September 2026, . [I-D.ietf-stir-certificate-transparency] Wendt, C., Śliwa, R., Fenichel, A., and V. A. Gaikwad, "STI Certificate Transparency", Work in Progress, Internet-Draft, draft-ietf-stir-certificate-transparency- 05, 21 October 2026, . [I-D.ietf-stir-certificates-shortlived] Peterson, J., "Short-Lived Certificates for Secure Telephone Identity", Work in Progress, Internet-Draft, draft-ietf-stir-certificates-shortlived-06, 6 July 2026, . Wendt Expires 5 May 2027 [Page 31] Internet-Draft Securing SIP and RTP with STIR November 2026 [I-D.ietf-tls-ecdhe-mlkem] Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D. Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3", Work in Progress, Internet-Draft, draft- ietf-tls-ecdhe-mlkem-05, 26 May 2026, . [I-D.ietf-tls-mlkem] Connolly, D., "ML-KEM Post-Quantum Key Agreement for TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- mlkem-11, 16 September 2026, . [I-D.ietf-uta-pqc-app] Reddy.K, T. and H. Tschofenig, "Post-Quantum Cryptography Recommendations for TLS-based Applications", Work in Progress, Internet-Draft, draft-ietf-uta-pqc-app-03, 4 July 2026, . [NIST.IR.8547] National Institute of Standards and Technology, "Transition to Post-Quantum Cryptography Standards", NIST IR 8547, October 2026, . [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, . [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, July 2002, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . Wendt Expires 5 May 2027 [Page 32] Internet-Draft Securing SIP and RTP with STIR November 2026 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, DOI 10.17487/RFC5630, October 2009, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC5923] Gurbani, V., Ed., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, DOI 10.17487/RFC5923, June 2010, . [RFC5924] Lawrence, S. and V. Gurbani, "Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates", RFC 5924, DOI 10.17487/RFC5924, June 2010, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . Wendt Expires 5 May 2027 [Page 33] Internet-Draft Securing SIP and RTP with STIR November 2026 [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, DOI 10.17487/RFC6188, March 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)", RFC 7714, DOI 10.17487/RFC7714, December 2015, . [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . [RFC8627] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019, . [RFC8643] Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T. Stach, "An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)", RFC 8643, DOI 10.17487/RFC8643, August 2019, . [RFC8657] Landau, H., "Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding", RFC 8657, DOI 10.17487/RFC8657, November 2019, . Wendt Expires 5 May 2027 [Page 34] Internet-Draft Securing SIP and RTP with STIR November 2026 [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, . [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, . [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, January 2021, . [RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", RFC 8842, DOI 10.17487/RFC8842, January 2021, . [RFC8862] Peterson, J., Barnes, R., and R. Housley, "Best Practices for Securing RTP Media Signaled with SIP", BCP 228, RFC 8862, DOI 10.17487/RFC8862, January 2021, . [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, . [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . [RFC9495] Bonnell, C., "Certification Authority Authorization (CAA) Processing for Email Addresses", RFC 9495, DOI 10.17487/RFC9495, October 2023, . Author's Address Chris Wendt Somos, Inc. United States of America Email: chris@appliedbits.com Wendt Expires 5 May 2027 [Page 35]