RFC 5922

Domain Certificates in the Session Initiation Protocol (SIP)

📅 published June 2010, from ietf

Domain Certificates in the Session Initiation Protocol (SIP) 🎀

Okay bestie, this is RFC 5922 from the Internet Engineering Task Force (IETF) 🫶. The authors are V. Gurbani, S. Lawrence, and A. Jeffrey, all from Bell Laboratories, Alcatel-Lucent 💅.

It's a Standards Track doc, dated June 2010 📅, with ISSN 2070-1721. It updates RFC 3261 [2], and there's no Obsoletes line, so it isn't replacing anything 💖.

Abstract ✨

This doc explains how to build and read certain info in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection 🔐. Specifically, it covers how to encode and pull out the identity of a SIP domain in a cert, and how to use that identity for SIP domain authentication 🦋. So it's relevant to SIP implementors and to certificate issuers, iykyk 💜.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5922.

Copyright (c) 2010 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1. Introduction ....................................................3
2. Terminology .....................................................3
   2.1. Key Words ..................................................3
3. Problem Statement ...............................................3
4. SIP Domain to Host Resolution ...................................5
5. The Need for Mutual Interdomain Authentication ..................6
6. Certificate Usage by a SIP Service Provider .....................7
7. Behavior of SIP Entities ........................................8
   7.1. Finding SIP Identities in a Certificate ....................8
   7.2. Comparing SIP Identities ...................................9
   7.3. Client Behavior ...........................................10
   7.4. Server Behavior ...........................................11
   7.5. Proxy Behavior ............................................12
   7.6. Registrar Behavior ........................................12
   7.7. Redirect Server Behavior ..................................12
   7.8. Virtual SIP Servers and Certificate Content ...............12
8. Security Considerations ........................................13
   8.1. Connection Authentication Using Digest ....................13
9. Acknowledgments ................................................14
10. References ....................................................14
   10.1. Normative References .....................................14
   10.2. Informative References ...................................15
Appendix A.  Editorial Guidance (Non-Normative) ...................16
  A.1.  Additions .................................................16
  A.2.  Changes ...................................................16
    A.2.1.  Changes to Section 26.3.1 .............................16

1. Introduction ✨

Okay so TLS, from RFC 5246 [5], is showing up in more and more Session Initiation Protocol (SIP) implementations of RFC 3261 [2] 💅. To actually use TLS's authentication powers, you need certificates defined by the Internet X.509 Public Key Infrastructure, see RFC 5280 [6] 🔐.

Here's the tea ☕: existing SIP specs don't spell out well enough how to use certificates for domain (as opposed to host) authentication. This doc gives guidance so everyone interoperates, with uniform conventions for building and reading certs that show the holder is authoritative for the domain 🦋.

This is all about X.509 PKIX-compliant certs used for a TLS connection. It does not define using them for any other purpose, like Secure/Multipurpose Internet Mail Extensions (S/MIME) 💜.

2. Terminology 💅

2.1. Key Words 🔑

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 RFC 2119 [1].

Additional definition(s):

SIP domain identity: An identity (e.g., sip:example.com) contained in an X.509 certificate bound to a subject that identifies the subject as an authoritative SIP server for a domain. 🎀

3. Problem Statement 🧩

So TLS uses RFC 5280 [6] X.509 Public Key Infrastructure to bind an identity, or a set of identities, to the subject of an X.509 certificate 🪪. Here's the drama: RFC 3261 gives decent guidance on X.509 certs for S/MIME, but it's basically silent on using them for TLS 🙈. When it comes to TLS certs, RFC 3261 (Section 26.3.1) says:

Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname.

Now, the security properties of TLS and S/MIME in SIP are different 💜. S/MIME certs are usually for end-to-end authentication and encryption, so they tie a user's identity to the cert. RFC 3261 is clear enough that in S/MIME certs, the subjectAltName field will contain the appropriate identity 📬. TLS certs, on the other hand, bind the identities of the per-hop domain sending or receiving the SIP messages 🔁.

But RFC 3261 doesn't say exactly where identities go: in the subjectAltName field, or carried as a Common Name (CN) in the Subject field. That gap created ambiguity 😭. Following the accepted practice of the time, legacy certs could store the identity in the CN field instead of the currently specified subjectAltName extension 🕰️. With no further guidance on how to interpret identities, which one to pick when more than one is present, or what happens when multiple identities with different schemes show up in the same cert, reading certs in a uniform way for TLS got messy 🌀.

This doc shows how certs are used for mutual authentication when both the client and the server have appropriate certs 🤝. It also gives normative behavior for matching the DNS query string against an identity stored in the X.509 cert ✨. A cert can hold multiple identities for the subject in the subjectAltName extension (the "subject" of a certificate identifies the entity associated with the public key stored in the public key field) 🧩. So this doc specifies matching rules that cover the different ways a subject's identity can be represented 💅. And finally, it gives guidelines to service providers for assigning certs to SIP servers 🎀.

Here's the roadmap 🗺️. The next section covers the most basic case: a client using DNS to access a SIP server, and the resulting authentication steps. Section 5 looks at why mutual inter-domain authentication is wanted in SIP, and the lack of normative text and behavior in RFC 3261 for doing it. Section 6 outlines normative guidelines for a service provider assigning certificates to SIP servers. Section 7 provides normative behavior for the SIP entities (user agent clients, user agent servers, registrars, redirect servers, and proxies) that need to perform authentication based on X.509 certificates. Section 8 includes the security considerations.

4. SIP Domain to Host Resolution ✨

okay so routing in SIP works like this: the client runs RFC 3263 [8] procedures on a URI called the "Application Unique String (AUS)" (c.f. Section 8 of RFC 3263 [8]) 💅. Those procedures take a SIP AUS (the SIP URI) as input, pull out the domain portion to use as a lookup key, and ask the Domain Name Service (DNS) for an ordered set of one or more IP addresses. Each address comes with a port number and a transport, and that whole list is the "Expected Output" 🧚. If the transport says TLS, a TLS connection gets opened to the server on a specific IP address and port 🔐. Then the server shows the client an X.509 certificate to verify as part of the initial TLS handshake 🤝.

Next, the client grabs identifiers from the Subject and any subjectAltName extension in that certificate (see Section 7.1) and compares them to the domain part of the original SIP URI (the AUS) 👀. If any identifier matches, the server counts as authenticated and signaling can keep going over the TLS connection 🎀. The matching rules and the normative client behavior live in Section 7.3 💜.

Here's an example, because examples make everything click 🍓. Say a request is headed to sips:alice@example.com. That address needs a secure connection to the SIP domain example.com, since the sips scheme requires one 🔒. DNS does its thing and maps the domain name to a set of host addresses and transports. The entity making the connection picks an address that works with TLS from that set. Once the connection is up, the server presents a certificate asserting the identity sip:example.com. The domain part of the SIP AUS matches the certificate's subject, so the server is authenticated (see Section 7.2 for the normative rules behind that comparison) ✨.

🌸 Session Initiation Protocol Secure (SIPS) borrows this server certificate matching pattern from HTTPS. However, RFC 2818 [7] prefers that the identity be conveyed as a subjectAltName extension of type dNSName, rather than the common practice of conveying the identity in the CN field of the Subject field. Similarly, this document recommends that the SIP domain identity be conveyed as a subjectAltName extension of type uniformResourceIdentifier (c.f. Sections 6 and 7.1) 💖 A domain name in an X.509 certificate is properly interpreted only as a sequence of octets to be compared to the URI used to reach the host. No inference can be made based on the DNS name hierarchy. For example, a valid certificate for example.com does not imply that the owner of that certificate has any relationship at all to subname.example.com 🙈

5. The Need for Mutual Interdomain Authentication

Let's picture the SIP trapezoid shown in Figure 1 🦋.

  Proxy-A.example.com           Proxy-B.example.net
     +-------+                    +-------+
     | Proxy |--------------------| Proxy |
     +----+--+                    +---+---+
          |                           |
          |                           |
          |                           |
          |                         +---+
        0---0                       |   |
         /-\                        |___|
        +---+                      /    /
                                  +----+
   alice@example.com          bob@example.net

            Figure 1: SIP Trapezoid

So alice@example.com invites bob@example.net to a multimedia communication session 🎥. Alice's outbound proxy, Proxy-A.example.com, uses normal RFC 3263 [8] resolution rules to find a proxy in the example.net domain that uses TLS, which is Proxy-B.example.net 🔍. Proxy-A actively sets up an interdomain TLS connection with Proxy-B, and each side presents a certificate to authenticate that connection 🤝.

RFC 3261 [2], Section 26.3.2.2, "Interdomain Requests" says that when a TLS connection is created between two proxies:

Each side of the connection SHOULD verify and inspect the certificate of the other, noting the domain name that appears in the certificate for comparison with the header fields of SIP messages.

But RFC 3261 is silent on whether to use the subjectAltName or the CN of the certificate to get the domain name, and on which one wins when there are multiple names identifying the holder of the certificate 🤷‍♀️.

Proxy-A's authentication problem is pretty straightforward ✨. In the certificate Proxy-A gets from Proxy-B, it looks for an identity that is a SIP URI (sip:example.net) or a DNS name (example.net) asserting that Proxy-B has authority over the example.net domain. The normative behavior for a TLS client like Proxy-A is in Section 7.3 💅.

Proxy-B's problem is a bit more complicated 😤, because it accepts the TLS request passively. That means Proxy-B doesn't have an equivalent AUS it can use as an anchor for matching identities in Proxy-A's certificate 🫠.

💅 RFC 3261 [2], Section 26.3.2.2, only tells Proxy-B to "compare the domain asserted by the certificate with the 'domainname' portion of the From header field in the INVITE request". The problem with that instruction is that the domainname in the From header field is not always the domain the request actually came from 💀

The normative behavior for a TLS server like Proxy-B, one that passively accepts a TLS connection and requires authentication of the sending peer domain, is in Section 7.4 🧚.

6. Certificate Usage by a SIP Service Provider

Service providers are allowed to keep using their existing certificates for SIP, with the identity only in the Subject field 🙆‍♀️. But they should carefully consider these perks of putting the identity in the subjectAltName extension field 👑:

  • The subjectAltName extension can hold multiple values, so the same certificate can identify multiple servers or SIP domains 🌈.
  • There's no fixed syntax for the Subject field, so issuers vary in how they set it. That forces a recipient to use heuristics to pull out the identity, which means more chances for misinterpretation 😵‍💫.

Because of these perks, service providers are strongly encouraged to get certificates that carry the identity or identities in the subjectAltName extension field 💖.

When certificates get assigned to authoritative servers, a SIP service provider MUST ensure that the SIP domain used to reach the server appears as an identity in the subjectAltName field. For compatibility with existing certificates, the Subject field of the certificate works too 🫶. In practice, that means a service provider hands its users SIP URIs whose domain portion matches an identity the provider has been issued a certificate for 🎀.

7. Behavior of SIP Entities

This section is where the rules get locked in 🔒. It normatively specifies how SIP entities behave when they use X.509 certificates to figure out an authenticated SIP domain identity ✨.

The first two subsections apply to every SIP implementation that uses TLS to authenticate the peer. Section 7.1 explains how to pull a set of SIP identities out of the certificate a TLS peer hands over, and Section 7.2 explains how to compare SIP identities 🧠. The remaining subsections give context on how and when these rules get applied by entities in different SIP roles 🦋.

7.1. Finding SIP Identities in a Certificate

Implementations (both clients and servers) MUST determine whether a certificate is valid by following the procedures in RFC 5280 [6] 🔍.

As RFC 5280 [6], Section 4.2.1.12 specifies, implementations MUST check for restrictions on certificate usage declared by any extendedKeyUsage extensions in the certificate 🚦. The SIP Extended Key Usage (EKU) document [12] defines an extendedKeyUsage for SIP 🎀.

Once a certificate passes the checks above, here's how to figure out what SIP domain identity or identities it contains 💅. One certificate can serve more than one purpose. It might contain identities that aren't acceptable as SIP domain identities, and it might also contain one or more identities that are acceptable for use as SIP domain identities 🌸.

  1. Examine each value in the subjectAltName field. The subjectAltName field and the rules for its values are defined in Section 4.2.1.6 of RFC 5280 [6]. The subjectAltName field can be absent or can contain one or more values. Every value has a type, and the only types acceptable for encoding a SIP domain identity SHALL be:
    • URI: If the scheme of the URI is not "sip", then the implementation MUST NOT accept the value as a SIP domain identity. If the scheme of the URI value is "sip" and the URI value contains a userpart (there's an '@'), the implementation MUST NOT accept the value as a SIP domain identity. A value with a userpart identifies an individual user, not a domain 🙅‍♀️. If the scheme of the URI value is "sip" and there's no userinfo component in the URI (no '@'), then the implementation MUST accept the hostpart as a SIP domain identity 💯.
Note: URI scheme tokens are always case insensitive 🫶.
  • DNS: An implementation MUST accept a domain name system identifier as a SIP domain identity if and only if no other identity is found that matches the "sip" URI type described above 🥹.
  1. If and only if the subjectAltName does not appear in the certificate, the implementation MAY examine the CN field of the certificate. If a valid DNS name is found there, the implementation MAY accept this value as a SIP domain identity 🙈. Accepting a DNS name in the CN value is allowed for backward compatibility, but when constructing new certificates, consider the advantages of using the subjectAltName extension field (see Section 6) 🌷.

The procedure above gives back a set containing zero or more identities from the certificate 🧺. A client uses these identities to authenticate a server (see Section 7.3), and a server uses them to authenticate a client (see Section 7.4) 💜✨.

7.2. Comparing SIP Identities 💖

Okay so when an implementation (client or server, both count bestie) compares two values as SIP domain identities, there are some strict rules. Implementations MUST compare only the DNS name component of each SIP domain identifier, and an implementation MUST NOT use any scheme or parameters in the comparison. No drama, just the name 💅

Implementations MUST compare the values as DNS names, which means the comparison is case insensitive, as specified by RFC 4343 [3]. Implementations MUST handle Internationalized Domain Names (IDNs) in accordance with Section 7.2 of RFC 5280 [6] ✨

Implementations MUST match the values in their entirety. Main character energy only, no partial matches 👑

  • Implementations MUST NOT match suffixes. For example, foo.example.com does not match example.com 🙅‍♀️
  • Implementations MUST NOT match any form of wildcard, such as a leading . or *. with any other DNS label or sequence of labels. For example, *.example.com matches only *.example.com but not foo.example.com. Similarly, .example.com matches only .example.com, and does not match foo.example.com 💀
Okay this part is lowkey the tea 🍵 RFC 2818 [7] (HTTP over TLS) allows the dNSName component to contain a wildcard, e.g., DNS:*.example.com. RFC 5280 [6] doesn't explicitly disallow this, but it leaves the interpretation of wildcards up to the individual specification. RFC 3261 [2] doesn't give any guidelines on wildcards in certificates. So, through the rule above, this document prohibits such wildcards in certificates for SIP domains. Not me being strict, just the spec 🫶

7.3. Client Behavior 🦋

So a client takes the domain portion of the SIP AUS and asks a (possibly untrusted) DNS for a result set. That result set is one or more SRV and A records identifying the server for the domain (see Section 4 for an overview) 🌸

The SIP server, when establishing a TLS connection, presents its certificate to the client for authentication. The client MUST determine the SIP domain identities in the server certificate using the procedure in Section 7.1. Then, the client MUST compare the original domain portion of the SIP AUS (the input to the RFC 3263 [8] server location procedures) to the SIP domain identities it got from the certificate 🔍

  • If there were no identities found in the server certificate, the server is not authenticated. 😬
  • If the domain extracted from the AUS matches any SIP domain identity obtained from the certificate when compared as described in Section 7.2, the server is authenticated for the domain. ✨

If the server is not authenticated, the client MUST close the connection immediately. Bye bye, no vibes 👋

7.4. Server Behavior 🎀

When a server accepts a TLS connection, the server presents its own X.509 certificate to the client. Servers that want to authenticate the client will ask the client for a certificate. If the client has one, that certificate gets presented to the server. If the client does not present a certificate, the client MUST NOT be considered authenticated 🙈

Whether or not to close a connection when the client doesn't present a certificate is a matter of local policy, and it depends on what the server needs for that connection. Some currently deployed servers use Digest authentication to authenticate individual requests on the connection, and choose to treat the connection as authenticated by those requests for some purposes (but see Section 8.1) 🧚 If the local server policy requires client authentication for some local purpose, one piece of that policy might be to allow the connection only if the client is authenticated. For example, if the server is an inbound proxy that has peering relationships with the outbound proxies of other specific domains, the server might allow only connections authenticated as coming from those domains 🍓

When authenticating the client, the server MUST obtain the set of SIP domain identities from the client certificate, as described in Section 7.1. The server accepted the TLS connection passively, unlike a client, so it doesn't have an AUS to compare against. That's okay though, because server policies can still use the set of SIP domain identities gathered from the certificate in Section 7.1 to make authorization decisions 💜

For example, a very open policy could be to accept an X.509 certificate and validate it using the procedures in RFC 5280 [6]. If the certificate is valid, the identity set is logged 📝

Alternatively, the server could keep a list of all SIP domains it is allowed to accept connections from. When a client presents its certificate, the server checks each identity in that certificate against the list of acceptable domains to decide whether to accept the connection. Other policies that make finer distinctions are possible too 🌈

Whether the authenticated connection to the client is appropriate for routing new requests to the client domain is a separate question from whether the connection is authenticated at all. The connect-reuse [10] document goes into more detail on this 🦋

7.5. Proxy Behavior 💅

A proxy MUST use the procedures defined for a User Agent Server (UAS) in Section 7.4 when authenticating a connection from a client. ✨

A proxy MUST use the procedures defined for a User Agent Client (UAC) in Section 7.3 when requesting an authenticated connection to a UAS. 🫶

If a proxy adds a Record-Route when forwarding a request, expecting the route to use secure connections, the proxy MUST insert into the Record-Route header a URI that corresponds to an identity for which the proxy has a certificate. If the proxy doesn't insert such a URI, then creating a secure connection using the value from the Record-Route as the AUS will be impossible 😭

7.6. Registrar Behavior 🔐

A SIP registrar, acting as a server, follows the normative behavior of Section 7.4. When the SIP registrar accepts a TLS connection from the client, the SIP registrar presents its certificate. Depending on the registrar policies, the SIP registrar can challenge the client with HTTP Digest 🍵

7.7. Redirect Server Behavior 🦋

A SIP redirect server follows the normative behavior of a UAS as specified in Section 7.4 🌸

7.8. Virtual SIP Servers and Certificate Content 🧚

In "virtual hosting" cases, where multiple domains are managed by a single application, a certificate can contain multiple subjects by having distinct identities in the subjectAltName field, as specified in RFC 4474 [9]. Clients trying to authenticate a server on such a virtual host can still follow the directions in Section 7.3 to find the identity matching the SIP AUS used to query DNS 👑

Alternatively, if the TLS client hello "server_name" extension, as defined in RFC 4366 [4], is supported, the client SHOULD use that extension to request a certificate for the specific domain (from the SIP AUS) it's trying to connect to 💖

8. Security Considerations 🔒

The goals of TLS (when used with X.509 certificates) include the following security guarantees at the transport layer 🛡️

  • Confidentiality: packets tunneled through TLS can be read only by the sender and receiver. 🤫
  • Integrity: packets tunneled through TLS cannot be undetectably modified on the connection between the sender and receiver. 🧱
  • Authentication: each principal is authenticated to the other as possessing a private key for which a certificate has been issued. Moreover, this certificate has not been revoked, and it is verifiable by a certificate chain leading to a (locally configured) trust anchor. 🪪

We expect appropriate processing of domain certificates to provide the following security guarantees at the application level 🌟

  • Confidentiality: SIPS messages from alice@example.com to bob@example.net can be read only by alice@example.com, bob@example.net, and SIP proxies issued with domain certificates for example.com or example.net. 🙊
  • Integrity: SIPS messages from alice@example.com to bob@example.net cannot be undetectably modified on the links between alice@example.com, bob@example.net, and SIP proxies issued with domain certificates for example.com or example.net. 🧷
  • Authentication: alice@example.com and proxy.example.com are mutually authenticated. Moreover, proxy.example.com is authenticated to alice@example.com as an authoritative proxy for domain example.com. Similar mutual authentication guarantees are given between proxy.example.com and proxy.example.net, and between proxy.example.net and bob@example.net. As a result, alice@example.com is transitively mutually authenticated to bob@example.net (assuming trust in the authoritative proxies for example.com and example.net) 🫂

8.1. Connection Authentication Using Digest 🚨

Digest authentication in SIP provides for authentication of the message sender to the challenging UAS. As it's commonly deployed, Digest authentication provides only very limited integrity protection of the authenticated message, and it has no way of binding the authentication to any attribute of the transport. Lots of existing SIP deployments use the Digest authentication of one or more messages on a particular transport connection as a way to authenticate the connection itself. By implication, that also authenticates other (unauthenticated) messages on that connection. Some even authenticate a UDP source address and port based on the Digest authentication of another message received from that address and port. This use of Digest goes beyond the assurances that the Digest Authentication mechanism was designed to provide, so it's giving risky 😬

A SIP implementation SHOULD NOT use the Digest Authentication of one message on a TCP connection, or from a UDP peer, to infer any authentication of any other messages on that connection or from that peer. Authentication of the domain at the other end of a connection SHOULD be accomplished using TLS and the certificate validation rules described by this specification instead 🔐✨

9. Acknowledgments 🫶

The following IETF contributors provided substantive input to this document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, Jonathan Rosenberg, and Russ Housley. Special acknowledgement goes to Stephen Kent for extensively reviewing document versions and suggesting invaluable feedback, edits, and comments 👑

Paul Hoffman, Eric Rescorla, and Robert Sparks provided many valuable WGLC comments 💜

10. References 📚

10.1. Normative References 📚

Okay bestie, these are the core reads you can't skip 💅 Every single one of them is load-bearing ✨

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🌸

[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 💖

[3] Eastlake, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006. 🦋

[4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. 🎀

[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 🔐

[6] 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, May 2008. 👑

10.2. Informative References 🧚

These ones are the extra-credit reading, but honestly they're iconic and you'll want them 💜

[7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 🍓

[8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. 🗺️

[9] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. 🪪

[10] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the Session Initiation Protocol", RFC 5923, June 2010. 🔁

[11] Drage, K., "A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP)", Work in Progress, July 2008. 🚧

[12] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates", RFC 5924, June 2010. ⭐

Appendix A. Editorial Guidance (Non-Normative) 🌈

Okay so this whole document is basically here to update RFC 3261, and it's going to follow the SIP Working Group procedures in [11] (or whatever replaces it) 🫶

This appendix is the little cheat sheet for whoever edits the next big, comprehensive update to RFC 3261 [2]. It explains how to bring in the changes from this doc, and it's giving organized energy 🎀

A.1. Additions

Sections 4 through 7 inclusive can get tucked in as subsections under a section about SIP domain authentication. Very neat 🦋

The contents of Section 8.1 can go into the Security Considerations section of the new document. Protect that section, it's important 🔥

All normative references from this document can be carried forward to its successor. Same squad, new doc 💅

A.2. Changes

The following subsections describe the changes to specific sections of RFC 3261 [2] that the successor document will need in order to line up with this one. In each of them, the token <domain-authentication> points to the section added as described in Appendix A.1. ✨

A.2.1. Changes to Section 26.3.1

Here's what the current text says 👀

   The current text says:

      Proxy servers, redirect servers and registrars SHOULD possess a
      site certificate whose subject corresponds to their canonical
      hostname.

And here's the suggested replacement 💖

   The suggested replacement for the above is:

      Proxy servers, redirect servers, registrars, and any other server
      that is authoritative for some SIP purpose in a given domain
      SHOULD possess a certificate whose subjects include the name of
      that SIP domain.

Authors' Addresses 💜

   Vijay K. Gurbani
   Bell Laboratories, Alcatel-Lucent
   1960 Lucent Lane
   Room 9C-533
   Naperville, IL  60566
   USA

   Phone: +1 630 224-0216
   EMail: vkg@alcatel-lucent.com


   Scott Lawrence

   EMail: scott-ietf@skrb.org


   Alan S.A. Jeffrey
   Bell Laboratories, Alcatel-Lucent
   1960 Lucent Lane
   Room 9C-533
   Naperville, IL  60566
   USA

   EMail: ajeffrey@alcatel-lucent.com

That's the whole RFC, bestie! 🌈🫶✨

📦 where this page comes from