RFC 4474

Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)

📅 published August 2006, from ietf

Part 1 of 11 🎀

Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) 💖

Okay bestie, here's the title block first 👑 This one came out of the Network Working Group and it's RFC 4474. The facts:

Number: RFC 4474
Authors: J. Peterson (NeuStar) and C. Jennings (Cisco Systems)
Category: Standards Track
Date: August 2006
Obsoletes and updates: the header doesn't list anything it obsoletes or updates 🙈

Status of This Memo 🌸

Okay so this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the distribution of this memo is unlimited, so share away 💅

Copyright Notice 🦋

Abstract ✨

The security mechanisms already in the Session Initiation Protocol (SIP) are not enough to cryptographically prove who the end users sending SIP requests really are, especially across domains 😭 This doc fixes that by defining a way to securely identify who sent a SIP message. It does this with two brand-new SIP header fields: Identity, which carries a signature used to validate the identity, and Identity-Info, which carries a reference to the signer's certificate 🔥

Table of Contents 🧚

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Background ......................................................3
   4. Overview of Operations ..........................................6
   5. Authentication Service Behavior .................................7
      5.1. Identity within a Dialog and Retargeting ..................10
   6. Verifier Behavior ..............................................11
   7. Considerations for User Agent ..................................12
   8. Considerations for Proxy Servers ...............................13
   9. Header Syntax ..................................................13
   10. Compliance Tests and Examples .................................16
      10.1. Identity-Info with a Singlepart MIME body ................17
      10.2. Identity for a Request with No MIME Body or Contact ......20
   11. Identity and the TEL URI Scheme ...............................22
   12. Privacy Considerations ........................................23
   13. Security Considerations .......................................24
      13.1. Handling of digest-string Elements .......................24
      13.2. Display-Names and Identity ...............................27
      13.3. Securing the Connection to the Authentication Service ....28
      13.4. Domain Names and Subordination ...........................29
      13.5. Authorization and Transitional Strategies ................30
   14. IANA Considerations ...........................................31
      14.1. Header Field Names .......................................31
      14.2. 428 'Use Identity Header' Response Code ..................32
      14.3. 436 'Bad Identity-Info' Response Code ....................32
      14.4. 437 'Unsupported Certificate' Response Code ..............32
      14.5. 438 'Invalid Identity Header' Response Code ..............33
      14.6. Identity-Info Parameters .................................33
      14.7. Identity-Info Algorithm Parameter Values .................33
   Appendix A. Acknowledgements ......................................34
   Appendix B. Bit-Exact Archive of Examples of Messages .............34
      B.1. Encoded Reference Files ...................................35
   Appendix C. Original Requirements .................................38
   References ........................................................39
      Normative References ...........................................39
      Informative References .........................................39

1. Introduction ✨

This doc upgrades the existing ways of doing authenticated identity management in the Session Initiation Protocol (SIP, RFC 3261 [1]) 💖 For this doc, an identity is a SIP URI, usually a canonical address-of-record (AoR) that's used to reach a user, like sip:alice@atlanta.example.com 🎀

RFC 3261 has a few spots in a SIP request where a user can state who they are, most notably the user-populated From header field 👀 The problem is that the recipient of a SIP request has no way to check that the From header field was filled in properly, unless there's some kind of cryptographic authentication mechanism in place 😭

RFC 3261 covers several security mechanisms that SIP user agents (UAs) can use, including Digest, Transport Layer Security (TLS), and S/MIME (implementations may support other security schemes too) 💅 The catch is that very few SIP user agents today have the end-user certificates they need to authenticate themselves (S/MIME, for example), and Digest is limited because the originator and the destination have to share a secret that was set up ahead of time 🙈 It would be so much better if SIP user agents could send requests to destinations they have no prior relationship with. Think about the telephone network today: you can get a call from someone you've never met and still feel pretty sure the Caller-ID on your screen is accurate 📞 A cryptographic approach like the one in this doc can probably give a much stronger, harder-to-spoof sense of identity than the telephone network does today 🔐

2. Terminology 💅

In this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], and they show the requirement levels for compliant SIP implementations 🧠

3. Background ✨

okay so the whole point of SIP apps is that a bunch of them make decisions based on who is calling 👀 and that's governed by authorization policies 💅. Some of those policies run automatically, and some get applied by actual humans. A human example is an internet phone app that shows you the Caller-ID of whoever's calling so you can look at it before you pick up 📱. An automated example is a presence service that checks the identity of people who want to subscribe against a whitelist before deciding to accept or reject them 🧚. In both cases, attackers might try to dodge these policies by impersonating someone else 😭. The big problem is that the From header field, which is the main identifier of who sent a SIP request, can be filled in with whatever the person controlling the user agent wants 🙈. So impersonation is honestly super easy right now. This mechanism is aiming to be a strong identity system for SIP, one where authorization policies can't be dodged by impersonating someone 🔥.

All RFC 3261-compliant user agents support Digest authentication 💖. It uses a shared secret, and the user agent uses it to prove who it is to a SIP registrar 🔑. Registration is how a user agent says "hey, I'm the right entity to send requests to for this particular SIP AoR URI" (for example, 'sip:alice@atlanta.example.com') 🌸.

By the definition of identity used in this document, registration counts as proof of the user's identity to a registrar ✅. BUT the credentials a user agent uses to prove itself to a registrar can't be checked by just any user agent or proxy server. They're only shared between the user agent and its domain administrator 🥺. So that shared secret doesn't immediately help a user authenticate to a wide range of recipients 💀. Recipients need a way to figure out whether the 'return address' identity of a non-REGISTER request (aka the From header field value) has actually been legitimately asserted 🕵️‍♀️.

Here's the lowkey clever part 🧠. The AoR URI used for registration is usually also the URI a user agent puts in the From header field to give recipients a 'return address' identity 💅. From an authorization standpoint, if you can prove you're allowed to register in a domain under a particular AoR, you can also prove you're legitimately allowed to receive requests for that AoR 🎀. So when you put that AoR in the From header field of a non-registration SIP request (like an INVITE), you're basically saying "this is a 'return address' where I can legitimately be reached" 📞. If you're authorized to receive requests at that 'return address', it logically follows that you're also authorized to assert that 'return address' in your From header field ✨. Just so you know, this is only one way a domain might decide how a user is allowed to fill in the From header field 🫶. Also, as a little aside, for other kinds of URIs in From (like anonymous URIs), other authorization policies would apply 🦋.

So ideally, SIP user agents should have some way to prove to recipients that their local domain authenticated them and authorized them to fill in the From header field 👑. This document proposes a mediated authentication architecture for SIP 🌈. Requests get sent to a server in the user's local domain, and that server authenticates them using the same practices the domain would use for REGISTER requests 🔒. Once a message is authenticated, the local domain still needs a way to tell other SIP entities that the sending user was authenticated and that their use of the From header field was authorized 📣. This document covers how that stamp of authentication can be shared 💜.

RFC 3261 already describes a pretty similar setup in Section 26.3.2.2 🧐. A user agent authenticates itself to a local proxy server, and that proxy then authenticates itself to a remote proxy server using mutual TLS. That creates a two-link chain of transitive authentication between the originator and the remote domain 🔗. It works well in some architectures, but there are a few ways it's impractical 😩. For one, transitive trust is inherently weaker than an assertion that can be validated end-to-end 📉. Also, SIP requests can cross multiple intermediaries in separate administrative domains, and in that case transitive trust becomes even less convincing 🙃.

One fix for this is to use 'trusted' SIP intermediaries that assert a user's identity in a privileged SIP header 🎟️. A mechanism for doing that (with the P-Asserted-Identity header) is given in [12]. BUT this solution only allows hop-by-hop trust between intermediaries, not end-to-end cryptographic authentication 😤. It also assumes a managed network of nodes with strict mutual trust relationships, which is incompatible with widespread Internet deployment 🌍.

So this document specifies a way to share a cryptographic assurance of end-user SIP identity, in either an interdomain or intradomain context 💖. It's based on the concept of an 'authentication service' and a new SIP header, the Identity header ✨. Just so you know, this document's scope is limited to giving this identity assurance for SIP requests. Solving the same problem for SIP responses is more complicated and is a subject for future work 🧩.

This specification lets either a user agent or a proxy server provide identity services and verify identities 🫶. For maximum end-to-end security, it's obviously better for end-users to get their own certificates and corresponding private keys 🔐. If they do, they can act as an authentication service themselves 👑. BUT end-user certificates might be neither practical nor affordable 💸. That's because setting up a Public Key Infrastructure (PKI) that reaches end-users is hard, and a single user might have a huge number of SIP user agents (phones, PCs, laptops, PDAs, gaming devices) 📱💻🎮. In environments like that, synchronizing keying material across multiple devices can get very complex and needs quite a bit of extra endpoint behavior 😵. Managing several certificates for the various devices is also a huge hassle and unpopular with users 🙄. So for the initial use of this mechanism, intermediaries will most likely be the ones that take on the authentication service role 🌸.

4. Overview of Operations 🧚

This section gives an informative (non-normative) high-level overview of the mechanisms described in this document 📖.

Picture this 🎬: Alice has the home proxy of example.com and the address-of-record sip:alice@example.com, and she wants to talk to sip:bob@example.org 💌.

Alice generates an INVITE and puts her identity in the From header field of the request 💅. Then she sends that INVITE over TLS to an authentication service proxy for her domain 🔒.

The authentication service authenticates Alice (possibly by sending a Digest authentication challenge) and checks that she's authorized to assert the identity in the From header field 🕵️‍♀️. That value might be Alice's AoR, or it might be some other value the proxy's policy lets her use 🎀. Then it computes a hash over some particular headers, including the From header field and the bodies in the message 🧮. This hash gets signed with the certificate for the domain (example.com, in Alice's case) and inserted into a new header field in the SIP message, the Identity header 🔏.

The proxy, as the holder of its domain's private key, is asserting that the originator of this request has been authenticated and that she's authorized to claim the identity (the SIP address-of-record) that appears in the From header field 👑. The proxy also inserts a companion header field, Identity-Info, which tells Bob how to acquire its certificate if he doesn't already have it 🦋.

When Bob's domain receives the request, it verifies the signature in the Identity header 🥰. That means it can validate that the domain indicated by the host portion of the AoR in the From header field authenticated the user, and permitted the user to assert that From header field value 💯. The same validation operation may also be performed by Bob's user agent server (UAS) 💖.

5. Authentication Service Behavior ✨

okay so this section is where the authentication service role gets defined, bestie 🎀 It's a brand new role for SIP entities, and it can be played by a proxy server or a user agent. Whoever plays it MUST possess the private key of a domain certificate 🔑 Intermediaries playing it MUST be capable of authenticating one or more SIP users that can register in that domain. Usually a proxy server takes this role, because proxies are more likely to have a static hostname, hold a matching certificate, and have registrar capabilities that let them authenticate users in their domain 💅 A redirect server could also play it, but that's left as a topic for future work 🦋

SIP entities acting as an authentication service MUST add a Date header field to SIP requests if one isn't already there (see Section 9 for how the Date header helps verifiers 🌸). Same deal with Content-Length: authentication services MUST add that header field too if it's missing. It can help verifiers double-check that they're hashing exactly as many bytes of message-body as the authentication service did when they verify the message 🧚

Here's the in-order checklist for generating an Identity header on a SIP request 📝

Step 1:

The authentication service MUST extract the identity of the sender from the request. It takes this value from the From header field, and this AoR is what we'll call the 'identity field' 👀 If the identity field contains a SIP or SIP Secure (SIPS) URI, the authentication service MUST extract the hostname portion of the identity field and compare it to the domain(s) it's responsible for. It uses the procedures in RFC 3261, Section 16.4, which is how a proxy server figures out its domain(s). If the identity field uses the TEL URI scheme, the authentication service's policy decides whether it's responsible for that identity (see Section 11 for more) 📞 If the authentication service is not responsible for the identity in question, it SHOULD process and forward the request normally, but it MUST NOT add an Identity header. See below for more on how an authentication service handles an existing Identity header 🙈

Step 2:

The authentication service MUST determine whether or not the sender of the request is authorized to claim the identity given in the identity field. To do that, it MUST authenticate the sender of the message 🔐 Some possible ways this authentication might happen:

If the authentication service is instantiated by a SIP intermediary (proxy server), it may challenge the request with a 407 response code using the Digest authentication scheme. Or it may view a Proxy-Authentication header sent in the request, which was sent in anticipation of a challenge using cached credentials, as described in RFC 3261, Section 22.3. Note that if that proxy server is maintaining a TLS connection with the client, and the client had previously authenticated itself over that connection using Digest authentication, the identity value from that previous authentication step can be reused without an additional Digest challenge ✨
If the authentication service is instantiated by a SIP user agent, a user agent can be said to authenticate its user on the grounds that the user can provision the user agent with the private key of the domain, or preferably by providing a password that unlocks said private key 🗝️

Authorizing a particular username in the From header field is a matter of local policy for the authentication service, and it depends a lot on how authentication is done 🧐 For example, one policy might be this: the username given in the 'username' parameter of the Proxy-Authorization header MUST correspond exactly to the username in the From header field of the SIP message. But lots of cases make that too limiting or inappropriate. A realm might use 'username' parameters in Proxy-Authorization that don't match the user-portion of SIP From headers, or a user might manage multiple accounts in the same administrative domain. In that second case, a domain might keep a mapping between the values in the 'username' parameter of Proxy-Authorization and a set of one or more SIP URIs that might legitimately be asserted for that 'username' 🗺️ For example, the username can correspond to the 'private identity' defined in the Third Generation Partnership Project (3GPP). In that case, the From header field can contain any one of the public identities associated with that private identity. Here's another policy for that situation: the URI in the From header field MUST correspond exactly to one of the mapped URIs associated with the 'username' given in the Proxy-Authorization header. There are also exceptions to these policies for cases like anonymity. If the AoR asserted in the From header field uses a form like sip:anonymous@example.com, then the example.com proxy should authenticate that the user is a valid user in the domain and insert the signature over the From header field as usual 🎭

This check is done on the addr-spec in the From header field (like the URI of the sender, sip:alice@atlanta.example.com). It does NOT convert the display-name portion (like 'Alice Atlanta') 💁 Authentication services MAY check and validate the display-name as well, and compare it to a list of acceptable display-names the sender may use. If the display-name doesn't meet policy constraints, the authentication service MUST return a 403 response code. The reason phrase should say what went wrong, for example "Inappropriate Display Name" 🙅 The display-name isn't always there, though, and in lots of environments the operational procedures needed for display-name validation may not exist. For more information, see Section 13.2 📚

Step 3:

The authentication service SHOULD ensure that any preexisting Date header in the request is accurate ⏰ Local policy can dictate exactly how accurate the Date must be. A RECOMMENDED maximum discrepancy of ten minutes will make sure the request is unlikely to upset any verifiers 🍓 If the Date header has a time that's off by more than ten minutes from the current time noted by the authentication service, the authentication service SHOULD reject the request. This behavior is not mandatory, because a user agent client (UAC) could only exploit the Date header to make a request fail verification. The Identity header isn't meant to be a source of non-repudiation or a perfect record of when messages get processed 🕰️ Finally, the authentication service MUST verify that the Date header falls within the validity period of its certificate. For more on the security properties of the Date header field value, see Section 9 🔒

Step 4:

The authentication service MUST form the identity signature and add an Identity header to the request containing this signature. Once the Identity header is on the request, the authentication service MUST also add an Identity-Info header. The Identity-Info header contains a URI where its certificate can be acquired 🎀 Details on generating both of these headers are in Section 9.

Finally, the authentication service MUST forward the message normally 🚀

5.1. Identity within a Dialog and Retargeting

Retargeting is broadly defined as the alteration of the Request-URI by intermediaries 🎯 More specifically, retargeting swaps the original target URI for one that belongs to a different user, a user who isn't authorized to register under the original target URI. By that definition, retargeting does not include translating the Request-URI into a contact address for an endpoint that registered under the original target URI, for example 💫

When a dialog-forming request gets retargeted, it can cause a few wrinkles for the Identity mechanism when it's applied to requests sent in the backwards direction within a dialog 🌀 This section gives some non-normative considerations for that case 💭

When a request is retargeted, it may reach a SIP endpoint whose user isn't identified by the URI in the To header field value. The To header field value of a dialog-forming request is used as the From header field of requests sent in the backwards direction during the dialog. That makes it the header an authentication service would sign for those backwards requests 🔁 In retargeting cases, if the URI in the From header doesn't identify the sender of the backwards request, then it would clearly be inappropriate to provide an Identity signature over that From header 🙅‍♀️ As specified above, if the authentication service is not responsible for the domain in the From header field of the request, it MUST NOT add an Identity header to the request, and it should process/forward the request normally 💌

Anticipating retargeting and so on is outside the scope of this document 🚫 That likely has equal applicability to response identity as it does to backwards requests within a dialog. So no special guidance is given here for implementers about the 'connected party' problem. Authentication service behavior stays the same if retargeting has happened for a dialog-forming request 🧠 In the end, the authentication service provides an Identity header for requests in the backwards dialog when the user is authorized to assert the identity given in the From header field. If they aren't, no Identity header is provided 🫶

For more on the problems of response identity and the potential solution spaces, see [15] 🦋

6. Verifier Behavior 🔍✨

Okay bestie, so this doc introduces a brand new logical role for SIP entities called a server 💅. When a verifier gets a SIP message with an Identity header, it may inspect the signature to check who actually sent the message 🦋. Usually the results get fed into an authorization process, but that process is totally outside this doc's scope 🙈. If there's no Identity header on a request and local policy says there should be one (like a per-sending-domain or per-sending-user policy), then a 428 'Use Identity Header' response MUST be sent 🚨.

To verify who sent a message, an entity acting as a verifier MUST go through the following steps, in this exact order 📋.

Step 1:

The verifier MUST acquire the certificate for the signing domain 🔐. SIP entities that support this spec SHOULD have some way of holding on to domain certificates (following normal practices for certificate lifetimes and revocation) so they don't keep re-downloading the same cert every time a request from the same domain shows up 🙄. Cached certs should be indexed by the URI given in the Identity-Info header field value 🗂️.

If the domain certificate used to sign the message isn't already known to the verifier, SIP entities SHOULD discover it by dereferencing the Identity-Info header, unless they have a more efficient, implementation-specific way of getting certs for that domain ✨. If the URI scheme in the Identity-Info header can't be dereferenced, then a 436 'Bad Identity-Info' response MUST be returned 💀. The verifier processes the cert in the usual ways, which includes checking that it hasn't expired, that the chain is valid back to a trusted certification authority (CA), and that it isn't on any revocation lists 🧐. Once the cert is acquired, it MUST be validated following the procedures in RFC 3280 [9] 🪪. If the cert can't be validated (it's self-signed and untrusted, or signed by an untrusted or unknown certificate authority, expired, or revoked), the verifier MUST send a 437 'Unsupported Certificate' response 😤.

Step 2:

The verifier MUST follow the process described in Section 13.4 to figure out if the signer is authoritative for the URI in the From header field 👑.

Step 3:

The verifier MUST verify the signature in the Identity header field, following the procedures for generating the hashed digest-string described in Section 9 🔥. If a verifier decides the signature on the message doesn't match the reconstructed digest-string, then a 438 'Invalid Identity Header' response MUST be returned 🚫.

Step 4:

The verifier MUST validate the Date, Contact, and Call-ID headers in the manner described in Section 13.1, and recipients that want to verify Identity signatures MUST support all of the operations described there 🫶. It must furthermore ensure that the value of the Date header falls within the validity period of the certificate whose matching private key was used to sign the Identity header 🗓️.

7. Considerations for User Agent 📱💖

This mechanism can be applied opportunistically to existing SIP deployments, so it needs no change to SIP user agent behavior in order to work 🦋. However, because this mechanism doesn't provide integrity protection between the UAC and the authentication service, a UAC SHOULD implement some means of providing that integrity 👀. TLS would be one such mechanism, and it's attractive because it MUST be supported by SIP proxy servers, but it's potentially problematic because it's a hop-by-hop mechanism 🤔. See Section 13.3 for more about securing the channel between the UAC and the authentication service 🔒.

When a UAC sends a request, it MUST accurately populate the From header field with a value that matches an identity it believes it's authorized to claim 💅. In a request, it MUST set the URI portion of its From header to match a SIP, SIPS, or TEL URI AoR that it's authorized to use in the domain (this includes anonymous URIs, as described in RFC 3323 [3]) 🎀. In general, UACs SHOULD NOT use the TEL URI form in the From header field (see Section 11) 🙅‍♀️.

Note that this document defines a bunch of new 4xx response codes. If user agents support these response codes, they'll be able to respond intelligently to Identity-based error conditions 🧠✨.

The UAC MUST also be capable of sending requests, including mid-call requests, through an 'outbound' proxy (the authentication service) 🚀. The best way to do this is with pre-loaded Route headers and loose routing 🛣️. For a given domain, if an entity that can instantiate the authentication service role isn't in the path of dialog-forming requests, identity for mid-dialog requests in the backwards direction can't be provided 😭.

As a recipient of a request, a user agent that can verify signed identities should also support an appropriate user interface to show the validity of that identity to a user 👑. User agent implementations SHOULD tell apart signed From header field values from unsigned ones when they show the end-user who sent a request 💜.

8. Considerations for Proxy Servers 🌸🛡️

Domain policy may require proxy servers to inspect and verify the identity provided in SIP requests 🔍. A proxy server might want to figure out who really sent the message, so it can do spam prevention or call control services 📞. Even if a proxy server isn't acting as an authentication service, it MAY validate the Identity header before it makes a forwarding decision for a request 🧚. Proxy servers MUST NOT remove or modify an existing Identity or Identity-Info header in a request 🙅‍♀️💅.

9. Header Syntax ✨

Okay bestie, this is where we meet the two new SIP headers, Identity and Identity-Info 🎀. Each one can show up only once in a SIP message, so no doubling up 💅. Their grammar follows the ABNF in [6] inside RFC 3261 [1], so it matches the rest of SIP:

Identity = "Identity" HCOLON signed-identity-digest
signed-identity-digest = LDQUOT 32LHEX RDQUOT

Identity-Info = "Identity-Info" HCOLON ident-info
                 *( SEMI ident-info-params )
ident-info = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-info-extension
ident-info-alg = "alg" EQUAL token
ident-info-extension = generic-param

The signed-identity-digest is a signed hash of a canonical string built from certain parts of a SIP request 🔐. To make it, the following elements of a SIP message MUST be placed in a bit-exact string, in the order listed here, separated by a vertical line ("|", or %x7C) character:

The AoR of the UA sending the message, or addr-spec of the From header field (referred to occasionally here as the 'identity field').
The addr-spec component of the To header field, which is the AoR to which the request is being sent.
The callid from Call-Id header field.
The digit (1*DIGIT) and method (method) portions from CSeq header field, separated by a single space (ABNF SP, or %x20). Note that the CSeq header field allows linear whitespace (LWS) rather than SP to separate the digit and method portions, and thus the CSeq header field may need to be transformed in order to be canonicalized. The authentication service MUST strip leading zeros from the 'digit' portion of the Cseq before generating the digest-string.
The Date header field, with exactly one space each for each SP and the weekday and month items case set as shown in BNF in RFC 3261. RFC 3261 specifies that the BNF for weekday and month is a choice amongst a set of tokens. The RFC 2234 rules for the BNF specify that tokens are case sensitive. However, when used to construct the canonical string defined here, the first letter of each week and month MUST be capitalized, and the remaining two letters must be lowercase. This matches the capitalization provided in the definition of each token. All requests that use the Identity mechanism MUST contain a Date header.
The addr-spec component of the Contact header field value. If the request does not contain a Contact header, this field MUST be empty (i.e., there will be no whitespace between the fourth and fifth "|" characters in the canonical string).
The body content of the message with the bits exactly as they are in the Message (in the ABNF for SIP, the message-body). This includes all components of multipart message bodies. Note that the message-body does not include the CRLF separating the SIP headers from the message-body, but does include everything that follows that CRLF. If the message has no body, then message-body will be empty, and the final "|" will not be followed by any additional characters.

For more information on the security properties of these headers, and why their inclusion mitigates replay attacks, see Section 13 and [5]. The precise formulation of this digest-string is, therefore (following the ABNF [6] in RFC 3261 [1]):

digest-string = addr-spec "|" addr-spec "|" callid "|"
                1*DIGIT SP Method "|" SIP-date "|" [ addr-spec ] "|"
                message-body

Note again that the first addr-spec MUST be taken from the From header field value, the second addr-spec MUST be taken from the To header field value, and the third addr-spec MUST be taken from the Contact header field value, provided the Contact header is present in the request.

After the digest-string is formed, it MUST be hashed and signed with the certificate for the domain 🪪. The hashing and signing algorithm is specified by the 'alg' parameter of the Identity-Info header (see below for more information on Identity-Info header parameters). This document defines only one value for the 'alg' parameter: 'rsa-sha1'; further values MUST be defined in a Standards Track RFC, see Section 14.7 for more information. All implementations of this specification MUST support 'rsa-sha1'. When the 'rsa-sha1' algorithm is specified in the 'alg' parameter of Identity-Info, the hash and signature MUST be generated as follows: compute the results of signing this string with sha1WithRSAEncryption as described in RFC 3370 [7] and base64 encode the results as specified in RFC 3548 [8]. A 1024-bit or longer RSA key MUST be used. The result is placed in the Identity header field. For detailed examples of the usage of this algorithm, see Section 10.

The 'absoluteURI' portion of the Identity-Info header MUST contain a URI which dereferences to a resource containing the certificate of the authentication service. All implementations of this specification MUST support the use of HTTP and HTTPS URIs in the Identity-Info header. Such HTTP and HTTPS URIs MUST follow the conventions of RFC 2585 [10], and for those URIs the indicated resource MUST be of the form 'application/pkix-cert' described in that specification. Note that this introduces key lifecycle management concerns: were a domain to change the key available at the Identity-Info URI before a verifier evaluates a request signed by an authentication service, this would cause obvious verifier failures. When a rollover occurs, authentication services SHOULD thus provide new Identity-Info URIs for each new certificate, and SHOULD continue to make older key acquisition URIs available for a duration longer than the plausible lifetime of a SIP message (an hour would most likely suffice). 🔑

The Identity-Info header field MUST contain an 'alg' parameter. No other parameters are defined for the Identity-Info header in this document. Future Standards Track RFCs may define additional Identity-Info header parameters.

This document adds the following entries to Table 2 of RFC 3261 [1]:

   Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
   ------------         -----   -----   ---  ---  ---  ---  ---  ---
   Identity               R       a      o    o    -    o    o    o

                                       SUB  NOT  REF  INF  UPD  PRA
                                       ---  ---  ---  ---  ---  ---
                                        o    o    o    o    o    o


   Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
   ------------         -----   -----   ---  ---  ---  ---  ---  ---
   Identity-Info          R       a      o    o    -    o    o    o

                                       SUB  NOT  REF  INF  UPD  PRA
                                       ---  ---  ---  ---  ---  ---
                                        o    o    o    o    o    o

Note, in the table above, that this mechanism does not protect the CANCEL method. The CANCEL method cannot be challenged, because it is hop-by-hop, and accordingly authentication service behavior for CANCEL would be significantly limited. Note as well that the REGISTER method uses Contact header fields in very unusual ways that complicate its applicability to this mechanism, and the use of Identity with REGISTER is consequently a subject for future study, although it is left as optional here for forward-compatibility reasons. The Identity and Identity-Info header MUST NOT appear in CANCEL. 🚫

10. Compliance Tests and Examples 💅

The examples in this section illustrate the use of the Identity header in the context of a SIP transaction. Implementers are advised to verify their compliance with the specification against the following criteria:

Implementations of the authentication service role MUST generate identical base64 identity strings to the ones shown in the Identity headers in these examples when presented with the source message and utilizing the appropriate supplied private key for the domain in question.
Implementations of the verifier role MUST correctly validate the given messages containing the Identity header when utilizing the supplied certificates (with the caveat about self-signed certificates below).

Note that the following examples use self-signed certificates, rather than certificates issued by a recognized certificate authority. The use of self-signed certificates for this mechanism is NOT RECOMMENDED, and it appears here only for illustrative purposes. Therefore, in compliance testing, implementations of verifiers SHOULD generate appropriate warnings about the use of self-signed certificates. Also, the example certificates in this section have placed their domain name subject in the subjectAltName field; in practice, certificate authorities may place domain names in other locations in the certificate (see Section 13.4 for more information).

Note that all examples in this section use the 'rsa-sha1' algorithm.

Bit-exact reference files for these messages and their various transformations are supplied in Appendix B. 📎

10.1. Identity-Info with a Singlepart MIME body ✨

Okay so picture this: 'atlanta.example.com' has its own private key and certificate pair 🔐 (shown in OpenSSL format, so it's very official).

So Alice, a user of atlanta.example.com, wants to send an INVITE to bob@biloxi.example.org 💌. She makes the following INVITE request and forwards it to the atlanta.example.org proxy server, which is running the authentication service role 🦋:

INVITE sip:bob@biloxi.example.org SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.example.org>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 147

v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

When the auth service gets the INVITE, it challenges Alice with a 407 response 🙅‍♀️. Alice then adds an Authorization header to her request and resends it to the atlanta.example.com authentication service. Once the service is sure it's really Alice, it works out an Identity header for the request 🧠. Here's the canonical string the signature gets generated over (heads up: the first line wraps because of RFC editorial conventions, so don't panic 💅):

sip:alice@atlanta.example.com|sip:bob@biloxi.example.org|
a84b4c76e66710|314159 INVITE|Thu, 21 Feb 2002 13:02:03 GMT|
sip:alice@pc33.atlanta.example.com|v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

The resulting signature (sha1WithRsaEncryption), made with the private RSA key from above and base64 encoded, looks like this 🔥:

ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=

So the atlanta.example.com authentication service creates an Identity header holding that base64 signature string, which is 175 bytes 📏. It also adds an HTTPS URL where its certificate can be found 🔗. With both headers in place, the message looks like this:

INVITE sip:bob@biloxi.example.org SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.example.org>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.example.com>
Identity:
  "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
   ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
   FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U="
Identity-Info: <https://atlanta.example.com/atlanta.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 147

v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Then atlanta.example.com forwards the request as usual 🚀. When Bob gets it, if he doesn't already have atlanta.example.com's certificate, he follows the URL in the Identity-Info header to grab it 🕵️‍♀️. He then builds the same canonical string from the same SIP request headers. Using that canonical string, the signed digest in the Identity header, and the certificate he fetched from the Identity-Info header, Bob can check that the headers and the message body haven't been changed 🫶.

10.2. Identity for a Request with No MIME Body or Contact 🌸

Next up, this one uses the private key and certificate pair assigned to "biloxi.example.org" 🔑.

Bob (bob@biloxi.example.org) now wants to send a BYE to Alice at the end of the dialog we set up in the last example 👋. He makes the following BYE request and forwards it to the 'biloxi.example.org' proxy server, which is running the authentication service role 💅:

BYE sip:alice@pc33.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf
To: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0

When the auth service gets the BYE, it challenges Bob with a 407 response. Bob adds an Authorization header to his request and resends it to the biloxi.example.org authentication service. Now that the service is sure it's Bob, it gets ready to work out an Identity header for the request 🧁. Notice this request doesn't have a Date header field, so biloxi.example.org adds a Date header to the request before it calculates the identity signature ⏰. If the Content-Length header weren't there, the authentication service would add that too. So the baseline message is:

BYE sip:alice@pc33.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf
To: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Date: Thu, 21 Feb 2002 14:19:51 GMT
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0

Also, this request has no Contact header field. That means biloxi.example.org puts no value in the canonical string for the addr-spec of the Contact address 🙈. There's also no message body, so the signature string ends with two vertical bars. The canonical string the identity signature gets generated over is (heads up again: the first line wraps because of RFC editorial conventions 💖):

sip:bob@biloxi.example.org|sip:alice@atlanta.example.com|
a84b4c76e66710|231 BYE|Thu, 21 Feb 2002 14:19:51 GMT||

The resulting signature (sha1WithRsaEncryption), made with the private RSA key for biloxi.example.org from above and base64 encoded, is:

sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=

So the biloxi.example.org authentication service creates an Identity header with that base64 signature string 🎀. It also adds an HTTPS URL where its certificate is available. With both headers added, the message looks like this:

BYE sip:alice@pc33.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf
To: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Date: Thu, 21 Feb 2002 14:19:51 GMT
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Identity:
  "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
   eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
   pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="
Identity-Info: <https://biloxi.example.org/biloxi.cer>;alg=rsa-sha1
Content-Length: 0

And then biloxi.example.org forwards the request normally 🌈.

11. Identity and the TEL URI Scheme ✨

okay so SIP apps are basically VoIP apps 📞, which means phone numbers show up as identities all the time 💅 and honestly? For most cases the identity mechanism in this doc is totally fine with that 🫶 Phone numbers usually live in the username part of a SIP URI, like sip:+17005551008@chicago.example.com;user=phone. That username follows the TEL URI syntax (RFC 3966 [13]) 🌸 and for this kind of address-of-record, chicago.example.com is the right signatory 👑

Now, a TEL URI can also show up in the To or From header without a SIP or SIPS URI around it, like tel:+17005551008. 🙈 That's where it gets kinda fuzzy, bestie, because it's much less clear who should sign for it. The good news is this bare form is way more common in To and Request-URI than in From 🦋 Why? Because when the remote domain is unknown, the UAC literally has no choice but to use a TEL URI by itself. The local domain, though, is usually known, so the UAC can build a proper From header with a SIP URI whose username is in TEL URI form ✨

So here's the vibe: any implementation that plans to send its requests through an authentication service SHOULD put telephone numbers in the From header inside SIP or SIPS URIs whenever it's possible 💖

If the UAC doesn't know its local domain, it most likely can't find an authentication service either 😭 so the whole identity question is kinda moot in that situation. Still, an authentication service MAY sign a request that has a TEL URI in the From header. This is allowed in this spec strictly for forward compatibility 🧚 Long-term, ENUM [14] might be able to tell us which administrative domain is responsible for a telephone number, and that could help with signing and verifying SIP identities that include phone numbers. Future-work era, periodt 🔮

12. Privacy Considerations 🎀

Good news: the identity mechanism here plays nicely with the standard SIP privacy practices in RFC 3323 [3] 🌈 A SIP proxy server can be a privacy service and an authentication service at the same time, iconic behavior 👑

Since a user agent can put in any From header value the authentication service is willing to authorize, there's zero reason private SIP URIs with legit domains (like sip:anonymous@example.com) can't get signed by an authentication service 💅 Building the Identity header works exactly the same for private URIs as for any other URI. No special treatment, no drama ✨

BUT, and this is a big but 🚨, an authentication service has to hold a certificate for the host portion of the addr-spec in the From header of any request it signs. So using domains like anonymous.invalid just won't work for privacy services that are also acting as authentication services 💀 The assurance you get from anonymous URIs with a valid domain is basically: "this is a known user in my domain that I have authenticated, but I am keeping its identity private" 🫶 The domain anonymous.invalid means no corresponding authority can exist for it, and so authentication service functions are meaningless with it 🙅‍♀️

Next, the "header" level of privacy in RFC 3323 [3] asks a privacy service to change the value of the Contact header. Here's the tea ☕: the Contact header is protected by the signature in the Identity header. So privacy services can't run after authentication services without causing an integrity violation 😭 Main character problem, honestly.

Now RFC 3325 [12] defines the id priv-value token, which only applies to the P-Asserted-Identity header 🦋 P-Asserted-Identity is a totally different vibe from the Identity header in this doc. It carries extra info about the sender that can go beyond the From header. It holds a definitive identity for the sender that a closed network of intermediaries knows about, and that network presumably uses it for billing or security 🔐 The worry is that this network-specific info could leak out of the closed network, and that's exactly why the id priv-value token exists. The id token has no implications for the Identity header at all, but privacy services MUST NOT remove the Identity header when a priv-value of id shows up in a Privacy header 🛑

Last but not least, unlike RFC 3325 [12], the mechanism in this spec adds no information to SIP requests that has privacy implications 🌸 Clean, safe, and slay 💖

13. Security Considerations 🔥

13.1. Handling of digest-string Elements ✨

Okay bestie, this section explains WHY the signature covers the fields it covers 🔐 This doc makes a signature over the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP requests 💅 A signature over just From would be enough to lock down a URI on its own, but the extra headers add replay protection and reference integrity, so the Identity header can't get cut-and-pasted around 🫶 The security stuff for these headers is basically the same as what RFC 3261 says about putting headers in tunneled 'message/sip' MIME bodies (see Section 23 especially) 📚 Each field gets its own breakdown below, and together they give us what we need to stop impersonation 🦋

The From header field tells you who sent the message, and the SIP address-of-record URI in the From header field is the identity of a SIP user, for the purposes of this document 👑 The To header field gives the identity of the SIP user that this request targets 🎯 Covering To in the Identity signature does two jobs. First, it stops cut-and-paste attacks where an Identity header from a legit request for one user gets pasted into a request for a different user 🙅‍♀️ Second, it keeps the starting URI scheme of the request, which helps prevent downgrade attacks against the use of SIPS 🔒

The Date and Contact headers give us reference integrity and replay protection, as described in RFC 3261, Section 23.4.2 ⏰ Implementations of this specification MUST NOT deem valid a request with an outdated Date header field (the RECOMMENDED interval is that the Date header must indicate a time within 3600 seconds of the receipt of a message) 🕰️ Implementations MUST also record Call-IDs received in valid requests containing an Identity header, and MUST remember those Call-IDs for at least the duration of a single Date interval (i.e., commonly 3600 seconds) 📝 Because a SIP-compliant UA never generates the same Call-ID twice, verifiers can use the Call-ID to spot cut-and-paste attacks, so the Call-ID acts as a nonce 🧠 The result: if an Identity header gets replayed within the Date interval, verifiers will recognize it as invalid because of a Call-ID duplication 🚫 If it gets replayed after the Date interval, verifiers will recognize it as invalid because the Date is stale 🥀 The CSeq header field holds a numbered identifier for the transaction plus the name of the method of the request 🔢 Without that info, an INVITE request could be cut-and-pasted by an attacker and turned into a BYE request without changing any fields covered by the Identity header 😱 Requests within a certain transaction could also be replayed in potentially confusing or malicious ways 💀

The Contact header field ties the Identity header to the particular user agent instance that generated the request 📱 Say an active attacker intercepts a request with an Identity header and cut-and-pastes that header into its own request (reusing the From, To, Contact, Date, and Call-ID fields from the original message) 🕵️‍♀️ That attacker still wouldn't be eligible to receive SIP requests from the called user agent, since those requests get routed to the URI in the Contact header field 🙅‍♀️ However, the Contact header is only included in dialog-forming requests, so it doesn't provide this protection in all cases 🥺

It might seem attractive to sign some of the info in the Via header field value(s) 🤔 For example, without a signature over the sent-by field of the topmost Via header, an attacker could remove that Via header and insert its own in a cut-and-paste attack, which would route all responses to the request to a host of the attacker's choosing 😈 But signing the topmost Via header doesn't stop this, because the attacker could leave the topmost Via intact and just insert a new Via header field directly after it 🪤 That would route responses to the attacker's host "on their way" to the valid host, which has exactly the same end result 🙃 It's possible an intermediary-based authentication service could guarantee that no Via hops get inserted between the sending user agent and the authentication service, but it couldn't stop an attacker from adding a Via hop after the authentication service and preempting responses 🫠 SIP needs subsequent intermediaries to be able to insert such Via header fields, so it can't be prevented 🚧 So even though it's desirable, securing Via isn't possible through the sort of identity mechanism described in this document, and the best known practice for securing Via is the use of SIPS 🔐

This mechanism also signs the bodies of SIP requests 🎶 The biggest reason is to protect Session Description Protocol (SDP) bodies carried in SIP requests 🎧 There's little point in establishing who originated a SIP request if that assurance isn't paired with a comparable assurance over the media descriptors 📻 Heads up though, this is not perfect end-to-end security 🙈 The authentication service itself, when run at an intermediary, could conceivably change the SDP (and SIP headers, for that matter) before providing a signature 😬 So while this mechanism reduces the chance that a replayer or man-in-the-middle will modify SDP, it doesn't eliminate it entirely 💔 Since it's a foundational assumption of this mechanism that users trust their local domain to vouch for their security, they must also trust the service not to violate the integrity of their message without good reason 🤝 Note that RFC 3261, Section 16.6, states that SIP proxy servers "MUST NOT add to, modify, or remove the message body." 📜

Real talk: the Identity and Identity-Info headers can't protect themselves 🚨 Any attacker could remove these headers from a SIP request and modify the request arbitrarily afterwards 😭 But this mechanism isn't meant to protect requests from men-in-the-middle who interfere with SIP messages. It's only meant to give SIP users a way to prove definitively that they are who they claim to be 💅 At best, by stripping identity info from a request, a man-in-the-middle could make it impossible to tell the illegitimate messages they want to send apart from messages sent by an authorized user 🥷 But that takes a LOT more effort than a trivial impersonation by just copying someone else's From header field 💪 This mechanism gives an authorized user a definitive assurance of their identity that an unauthorized user, an impersonator, can't fake 🦋

One more way the Identity-Info header can't protect itself is the 'alg' parameter 🫣 The 'alg' parameter isn't included in the digest-string, so a man-in-the-middle might try to modify it 🧐 But preventing men-in-the-middle isn't the main goal of this mechanism 🎯 Changing 'alg' would at worst cause some sort of bid-down attack, and at best cause a failure in the verifier 🙃 Only one valid 'alg' parameter is defined in this document, so there's currently no weaker algorithm for the mechanism to be bid down to 🥳 'alg' is in there for forward-compatibility reasons, in case the current algorithm shows weaknesses and needs swift replacement in the future 🔄

13.2. Display-Names and Identity 🎀

Okay so, as an interface design thing, SIP user agents might show the display-name portion of a caller's From header field as the caller's identity 🪪 Email UIs have been doing this forever, so it kinda seems like not signing the display-name is a big omission 😬

BUT there are several important reasons a signature over the display-name doesn't stop impersonation 🙅‍♀️ First off, a particular display-name, like "Jon Peterson", isn't unique in the world, and lots of users in different administrative domains might legitimately claim that name 🌍 Also, enrollment practices for SIP-based services might have a hard time figuring out the legit display-name for a user, so it's safe to assume impersonators will be able to create SIP accounts with arbitrary display-names 🤡 Email has the exact same situation today 📧 And an impersonator who tried to replay a message with an Identity header, changing only the display-name in the From header field, would get caught by the other replay protection mechanisms described in Section 13.1 🚨

Of course, an authentication service can enforce policies about the display-name even when it isn't signed ✅ How to actually create and run those policies is outside the scope of this document 📋 The point of such a policy wouldn't be to stop impersonation of a unique identifier like a SIP URI (display-names aren't unique identifiers anyway), but to let a domain manage the claims its users make 🏛️ If these policies are enforced, users wouldn't be free to claim any display-name they want 🙅‍♀️ Without a signature, man-in-the-middle attackers could conceivably alter display-names in a request with impunity 😈 Still, the scope of this spec is impersonation attacks, and a man-in-the-middle might also strip the Identity and Identity-Info headers from a message 💔

There are plenty of environments where display-name policies aren't feasible 🫤 Handing bit-exact, internationalizable display-names to end-users as part of enrollment or registration would need mechanisms this document doesn't explore 🌏 Without policy enforcement around domain names, an adversary could conceivably attack SIP systems that lean too heavily on the display-name in their user interface 🎭 But that argues for smart interface design, not changes to the mechanisms 🧠 Relying on a non-unique identifier for identity would ultimately result in a weak mechanism 🥀

13.3. Securing the Connection to the Authentication Service 🔐

okay so the assurance from this mechanism is strongest when a user agent makes a direct connection to an intermediary-based authentication service, preferably one secured by TLS 🔒. There are two reasons for that, bestie:

If a user does not receive a certificate from the authentication service over this TLS connection that corresponds to the expected domain (especially when the user receives a challenge via a mechanism such as Digest), then it is possible that a rogue server is attempting to pose as an authentication service for a domain that it does not control, possibly in an attempt to collect shared secrets for that domain. 👀
Without TLS, the various header field values and the body of the request will not have integrity protection when the request arrives at an authentication service. Accordingly, a prior legitimate or illegitimate intermediary could modify the message arbitrarily. 😬

Of these two concerns, the first is most material to the intended scope of this mechanism. This mechanism is intended to prevent impersonation attacks, not man-in-the-middle attacks. Integrity over the header and bodies is provided by this mechanism only to prevent replay attacks. However, it is possible that applications relying on the presence of the Identity header could leverage this integrity protection, especially body integrity, for services other than replay protection ✨.

Accordingly, direct TLS connections SHOULD be used between the UAC and the authentication service whenever possible. The opportunistic nature of this mechanism, however, makes it very difficult to constrain UAC behavior. Moreover, there will be some deployment architectures where a direct connection is simply infeasible and the UAC cannot act as an authentication service itself. So when a direct connection and TLS are not possible, a UAC should use the SIPS mechanism, Digest auth-int for body integrity, or both when it can 🧚. The ultimate decision to add an Identity header to a request lies with the authentication service, of course. Domain policy must identify those cases where the UAC's security association with the authentication service is too weak 💅.

13.4. Domain Names and Subordination 🌸

When a verifier processes a request containing an Identity-Info header, it MUST compare the domain portion of the URI in the From header field of the request with the domain name that is the subject of the certificate acquired from the Identity-Info header. Lowkey it seems like this should be super straightforward, but it gets complicated by two deployment realities 🙈. In the first place, certificates describe their subjects in varying ways, and may indeed have multiple subjects, especially in 'virtual hosting' cases where multiple domains are managed by a single application. Secondly, some SIP services may delegate SIP functions to a subordinate domain and use the procedures in RFC 3263 [4], which allow requests for, say, 'example.com' to be routed to 'sip.example.com'. As a result, a user with the AoR sip:jon@example.com may process its requests through a host like sip.example.com, and it may be that latter host that acts as an authentication service.

To meet the second of these problems, a domain that deploys an authentication service on a subordinate host MUST be willing to supply that host with the private keying material associated with a certificate whose subject is a domain name that corresponds to the domain portion of the AoRs that the domain distributes to users. This corresponds to the comparable case of routing inbound SIP requests to a domain. When the NAPTR and SRV procedures of RFC 3263 are used to direct requests to a domain name other than the domain in the original Request-URI (for example, for sip:jon@example.com, the corresponding SRV records point to the service sip1.example.org), the client expects that the certificate passed back in any TLS exchange with that host will correspond exactly with the domain of the original Request-URI, not the domain name of the host. Consequently, in order to make inbound routing to such SIP services work, a domain administrator must similarly be willing to share the domain's private key with the service. This design decision was made to compensate for the insecurity of the DNS. It makes certain potential approaches to DNS-based 'virtual hosting' unsecurable for SIP in environments where domain administrators are unwilling to share keys with hosting services 😤.

A verifier MUST evaluate the correspondence between the user's identity and the signing certificate by following the procedures defined in RFC 2818 [11], Section 3.1. While RFC 2818 deals with the use of HTTP in TLS, the procedures described are applicable to verifying identity if one substitutes the "hostname of the server" in HTTP for the domain portion of the user's identity in the From header field of a SIP request with an Identity header 🦋.

Because the domain certificates that can be used by authentication services need to assert only the hostname of the authentication service, existing certificate authorities can provide adequate certificates for this mechanism. However, not all proxy servers and user agents will be able to support the root certificates of all certificate authorities, and there are some significant differences in the policies by which certificate authorities issue their certificates. This document makes no recommendations for the usage of particular certificate authorities, nor does it describe any particular policies that certificate authorities should follow. It is anticipated that operational experience will create de facto standards for authentication services. Some federations of service providers, for example, might only trust certificates that have been provided by a certificate authority operated by the federation. It is strongly RECOMMENDED that self-signed domain certificates should not be trusted by verifiers, unless some previous key exchange has justified such trust 🚫.

For further information on certificate security and practices, see RFC 3280 [9]. The Security Considerations of RFC 3280 are applicable to this document 🔐.

13.5. Authorization and Transitional Strategies 💜

Ultimately, the worth of an assurance provided by an Identity header is limited by the security practices of the domain that issues the assurance. Relying on an Identity header generated by a remote administrative domain assumes that the issuing domain used its administrative practices to authenticate its users. However, some domains may implement policies that effectively make users unaccountable (for example, ones that accept unauthenticated registrations from arbitrary users). The value of an Identity header from such domains is questionable 🫠. While there is no magic way for a verifier to distinguish "good" from "bad" domains by inspecting a SIP request, it is expected that further work in authorization practices could be built on top of this identity solution. Without such an identity solution, many promising approaches to authorization policy are impossible. That said, it is RECOMMENDED that authentication services based on proxy servers employ strong authentication practices such as token-based identifiers 👑.

One cannot expect the Identity and Identity-Info headers to be supported by every SIP entity overnight. This leaves the verifier in a compromising position. When it receives a request from a given SIP user, how can it know whether or not the sender's domain supports Identity? In the absence of ubiquitous support for identity, some transitional strategies are necessary 🤔.

A verifier could remember when it receives a request from a domain that uses Identity, and in the future, view messages received from that domain without Identity headers with skepticism.
A verifier could query the domain through some sort of callback system to determine whether or not it is running an authentication service. There are a number of potential ways in which this could be implemented. Use of the SIP OPTIONS method is one possibility. This is left as a subject for future work.

In the long term, some sort of identity mechanism, either the one documented in this specification or a successor, must become mandatory-to-use for the SIP protocol. That is the only way to guarantee that this protection can always be expected by verifiers 🌈.

Finally, it is worth noting that the presence or absence of the Identity headers cannot be the sole factor in making an authorization decision. Permissions might be granted to a message on the basis of the specific verified Identity, or really on any other aspect of a SIP request. Authorization policies are outside the scope of this specification, but this specification advises any future authorization work not to assume that messages with valid Identity headers are always good 💖.

14. IANA Considerations 🧾

This document requests changes to the header and response-code sub-registries of the SIP parameters IANA registry, and requests the creation of two new registries for parameters for the Identity-Info header ✨.

14.1. Header Field Names 🎀

This document specifies two new SIP headers: Identity and Identity-Info. Their syntax is given in Section 9. These headers are defined by the following information, which has been added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.

      Header Name: Identity
      Compact Form: y
      Header Name: Identity-Info
      Compact Form: n

14.2. 428 'Use Identity Header' Response Code 🦋

This document registers a new SIP response code, which is described in Section 6. It is sent when a verifier receives a SIP request that lacks an Identity header, in order to indicate that the request should be re-sent with an Identity header. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.

      Response Code Number: 428
      Default Reason Phrase: Use Identity Header

14.3. 436 'Bad Identity-Info' Response Code 🌷

This document registers a new SIP response code, which is described in Section 6. It is used when the Identity-Info header contains a URI that cannot be dereferenced by the verifier (either the URI scheme is unsupported by the verifier, or the resource designated by the URI is otherwise unavailable). This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.

      Response Code Number: 436
      Default Reason Phrase: Bad Identity-Info

14.4. 437 'Unsupported Certificate' Response Code ✨

okay bestie, so this one registers a brand new SIP response code 🎀, and it's described in Section 6. 💅 The verifier uses it when it can't validate the certificate that the URI in the Identity-Info header points to. Like, maybe the cert is self-signed 🙈, or it's signed by a root certificate authority the verifier has no root certificate for. Totally valid reason to say "nope" 💀. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters. 🦋

Response Code Number: 437
Default Reason Phrase: Unsupported Certificate

14.5. 438 'Invalid Identity Header' Response Code 🌸

this is another new SIP response code, also described in Section 6 💖. It gets used when the verifier gets a message whose Identity signature doesn't match the digest-string the verifier calculated itself. 😭 So the signature and the digest just don't agree, and the verifier is like "wait, what?" 🙃 This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters. ⭐

Response Code Number: 438
Default Reason Phrase: Invalid Identity Header

14.6. Identity-Info Parameters 🌈

the IANA has created a brand new registry for Identity-Info headers 🧚. It's prepopulated with exactly one entry, a parameter called alg, which describes the algorithm used to create the signature that shows up in the Identity header 🔥. Every registry entry has to include the name of the parameter and the specification where that parameter is defined. 📚 And new parameters for the Identity-Info header may be defined only in Standards Track RFCs 👑. So the gatekeeping is strict, periodt 💅.

14.7. Identity-Info Algorithm Parameter Values 💜

same energy here: the IANA has created a new registry for Identity-Info alg parameter values 🍓. It comes prepopulated with a single entry for a value called rsa-sha1, which describes the algorithm used to create the signature in the Identity header ✨. Registry entries must contain the name of the alg parameter value and the specification in which that value is described. 🫶 New values for the alg parameter may be defined only in Standards Track RFCs, same as before, no cap 🔒.

Appendix A. Acknowledgements 🫶

the authors wanna give a huge shoutout to Eric Rescorla, Rohan Mahy, Robert Sparks, Jonathan Rosenberg, Mark Watson, Henry Sinnreich, Alan Johnston, Patrik Faltstrom, Paul Kyzviat, Adam Roach, John Elwell, Aki Niemi, and Jim Schaad for their comments 👑💖. Jonathan Rosenberg gave detailed fixes to innumerable sections of the document, which is literally iconic 😭🔥. The bit-archive in Appendix B follows the pioneering example of RFC 4475 [16] 🦋. And thanks to Hans Persson and Tao Wan for thorough nit reviews 🙈✨.

Appendix B. Bit-Exact Archive of Examples of Messages 🎀

okay this appendix is giving archive energy 📦. The following text block is an encoded, gzip-compressed TAR archive of files that represent the transformations performed on the examples of messages discussed in Section 10 🌸. For each example, it includes:

(foo).message: the original message
(foo).canonical: the canonical string constructed from that message
(foo).sha1: the SHA1 hash of the canonical string (hexadecimal)
(foo).signed: the RSA-signed SHA1 hash of the canonical string (binary)
(foo).signed.enc: the base64 encoding of the RSA-signed SHA1 hash of the canonical string as it would appear in the request
(foo).identity: the original message with the Identity and Identity-Info headers added

The archive also includes two public key/certificate pairs, for atlanta.example.com and biloxi.example.org, respectively 🧚, including:

(foo).cer: the certificate of the domain
(foo).privkey: the private key of the domain
(foo).pubkey: the public key of the domain, extracted from the cert file for convenience

to recover the compressed archive file intact, you can pass the text of this document as input to the following Perl script 🪄. The output should be redirected to a file or piped to "tar -xzvf -".

#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>) {
 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
     if ( m/^\s*[^\s]+\s*$/) {
         $bdata = $bdata . $_;
     }
  }
}
print decode_base64($bdata);

Alternatively, the base-64 encoded block can be edited by hand to remove document structure lines and fed as input to any base-64 decoding utility 🛠️.

B.1. Encoded Reference Files 📦

-- BEGIN MESSAGE ARCHIVE --
H4sICFfaz0QCA25ld2lkZW50LnRhcgDsW0us5NhZ7gUSwqiF2CAhFikiIQhFt992
+U46it+u8qPK5Uc9WPlVfj/KdpXtomEDCxaAhFggISE2WSHCIoIFioQQC8gqAhRA
QQTY8JJAbMgGIYTv7b7T09PT0xNl+mqS3F8qVd3jY/uc85//+87/nXOLoIv9oGjB
B2/PIAiDSBwfv1GERInxG8EwAh6/37UHMIQRKIljCI4+gGCUGKtP8Ad3YKemderJ
5EFSBW1QN2Xxmnp5GtblqXqUPfIffBdZcet/p82conUee0H9sfsfhiACw17nfwQa
y+Dra+MkQGFkrI+TOPJgAt37/63bo2tjeHGuTVh+bc6FOUub/E0poM7nLGqyLJ06
Id3NGTocPxytMWF6jNJYpDqIoXVLoDlmr+pNx+o7ztZ1ke8WtnXhFUClU5GGLZ6l
O3YN8T3P0Usm1GyG9lQGEiBXFE6+yPecSSvPykuV4TPB5ne9xNEO8KxQVXnk3cqn
/TaK3C3T7A08cRGokyJPUzmrV7k5pHK7i5bQyOambNcDLxUmH9zMD2sl8FGa+WGt
BG6bGe5nHafvFnK5n0dnT6N1nmF0mgt3EK3OxQVdiuMzZrNOhPxNOF37W7w4LmsL
OA0Mpeqt7RTKTrDX1CztZgezbM7rLlvQeBnhWzWOV5qDZEdMahLZTo8Wq0oZOL4X
FgkgMhY4pNBdU53sHVvlaIX5TjqH0+JkYXAXmmzgSI7H9N3RvHingrIOAUIzCph4
GhsdHGDwET+WCO5SuDtwxXKNvneGYrWiQ5WhaTEJXb0LXb6Trgd2DS0ZZscLWm6B
au3aO48HZK4GEWgzN2oRTuBaG/vLXA+aZKh8kDBYyJj7bHWREXgjMWxIgFQrxPyx
b3eUc3EEH6iEptuYL1zFRCpr22rPXujFs9EPx0s+o67pbhzRa/eOjvEZX+wjt1hH
gKpDHdvdXJA5er1Y22tRXXed+KwyxzFadFtZyW1st4E7V7ROO4Rqw5Cnx6ncXb/Z
5ztdUOmx34dX3Ck8cydPc76+a5uO4XLTMI9Q3iIwDJBOloNbUahd5OK7FnQu637t
L/cQdlSHel5tRVjh84Jfhl7pDfV2zZyPeEVs3D3t8XoKAVzDo3YAad6sp4r8nCUb
UmxUUWAL9lRiS848gHAm+nZNcQF78RIY2lk6qq6DnFO30Q4B2JaLG2WTkcZ2uVx7
ezqGS4vqngA30c5r3KsI8ODevsvtFf6v6vicBsMd8j+ME+Qt/0PjAnCsT5AQes//
d8z/a4OerNZze4z+iczvXqwBtvrI+7TMhDq3WqlMK9nlKt3a0z2RHGGlCQ8jMtub
akAY2zocFupKgghFgbyFoS8BZx7Yl3mZXDZt5ZwYcj5kezmjEwY/YCO4rk+lFQc+
26mK7GYb+rhviUDaVKy2X5DZUvOAOd8VeYQUtOfJ6QxVKtCW0DakDRBDOb3cIk3h
F7toGs5wBFldupDkxU1TXS7dnKN1mgFumFWGNmhb8AJH0omt08VC23Jtj1O0A9sn
ZMFvA6KMp8s6FYZmkbj7RdcoudzWYdsCq+3SmrVIvq9iqJOxaIu1+6ho406UU2vF
ohHFJNVUDOr4sEIxeK0O6nJKHFZhclxeLK4DpvUqSdSqG1+eerx35ELXrPfF5gzq
BWs4joD2qSUehFTp8aXsremUp0mrLxp+tnVMFALaFWhZHg6HWorIohz2um5KZcV4
QUcNh4BdC9HZV8ikckSn5WM83neiONKavbQlS4MlANoplaQn67JbMLQ2XSPumQa1
OD9iBLYPiyDjudXR4en9xuHQdHmIDGp6VsjyyBvTE85DwIJMty65T2PDtkJqa4Gz
Va/KPcjRF8i38qUytVhdmrEUb1rqHDnx7lFyGd+2RC1FCYwFOMErfKO3oymKyceF
n8Q7oyfs1eqMEFsqJw1oOfhmaoQNCmJluerLmeSox20+g1idmdZA7zKolVXLMvKY
TpCp3KwzlSHYhjpmBCGHXZEp1CnlI0nalZdxHPxtUDLsEFlNGfqGBRCgY9CCd97w
YpuQ4HlY8Kyus6wBZ3LIb0tNXx2XmpOdd9EwqPv1VlB8Dgvdbr2S4dNWBnZVirLp
Qbgsh0MSKJ646reXI3K8nKSLaHL9nlrRQdVtsbWRviDVDwyrTzD+n9yPGf7fhP8j
5kO3+I/AN/k/gZHYPf7fMf6vLEaZs++FfvGg0pDIGkfRmLsj2PLX6R5NY6JGcywT
6x9OCcDrOOGjUgLwOk74qJQAvJYT3o3O93f6e3b958ZZ2cdvQ/55s/6DvEf/QbBr
/YeAifv4/yToP3DCsnQyfZP+s32j/mOO6Tp3ub75uf6TLipXpDDH5DWVbp7VCzve
sGxrnfDuWEEErgvprjN2eda4aFS9PzVXGWzLmTSsmvSgcTQyfgYtK6/LkOsy4D2F
nX15k4AAm6p+k9Y/FxD2LOBs+nMgph+o/YgXev+u9pM/746BZ4EotJ7YZ0qunQHX
ZJni8v5B4wWaXjKJTnfhLmWvRYMzIXYbFjI5jFzInZwlZZR0gmoAGoi39e6ENYEk
HsO0UyJ7umXRkl/i+LGOLxE6zD3bkFOqoJYZrS3Mo5bYjjSc16cLjwvABjZ3Tbgw
EIHu51MYjruBLihkPUwjBwTDKJjJ0MqZLpQpjMVG40i2HhaHDtNTcH08ZDpASGdm
Vh2T7DzUC/SINbE6epSnaWfJNGP36oT2b+QcHeOFULeg/XStYOQGpFdc6+EMcDBK
fXviBR7sukN3IxIljBR2fkm/UvlF3SHaEOu9Kng98MJNO5PObPM9s20E9IU2zrbV
NVXduLbrRP35fLmVfYCXdZ9mrHGr+yzi5y5+n7CIsCNRdBx901oTYGirG/vMgJcP
mP/XeqHOxIMszduZuT2I2qEqFtsYT9j4suzz3WwHhFkxa4eV4ATDkcJN0Tub7Obi
l4xiVww3PVTrTb0F53O84Qlbcl16TBnsXHb33UWn26oCVojgnBJk1lLYPuAkDTkf
L8mhkBJ2iWCpiC5OB8ScQXFWUTvJ47o+sYS6nRFWkbHTIfaBwTGDU7PBxRN5hsMn
97rPvb3K/29B/nmz/kOit/wPI+NaYFz/49j9/s8nR/8Jb/UfFixdZqes1VXSpDV9
3CxjcUVb/RwFc6SNybjHPOfImvRJ2OKeEoQ6QBb58aQspcM86u350UQOEGHRULYs
Ec0uDzIlkqqZ2q6txQOdKTuL4xNyu1G4OXtA95ICEEINTlmB7GqdqrH0TG7jhdyX
vs2yPshFrEmJ1dTmymAmDflxuQHlpgjqeJi/pP8syEMjzOWtnCabMJmljbhsIwM1
CpjqVwY78D7TH/gcWSUkqF0uQRaDK2/pxB6UAouR+r3iqCEHiQ/mogxSvcX05ukQ
6jt7cTwPEr9uiHq7BWMT2xU51cIUhPOxTu0rqannADguEKwdDeu1GNJz6bxXbOVy
nFKywvH7qaS7J1ZZbIUp4WYQ7+LMtf5DoESp0loF6Q4K5LsNryOnNhebXZ9ujcPA
uPDMZJcd2w5Q4TNrBLsMy4WAaO7eoGbKZSo6CB4d5mIHLiQZKDjKXfKzmXWj/zBr
o/IxNzemOTZbgzDarnmDbqXj4GtxsYVSA1xHnVSTeSqZFpqCKiD0etuj2BwV5Yuz
79UCoglCNqgzaEh+IUyD1Y2YIgak3kTDfnaKW2XV7jkvYzcRL0vAkdal3OL3Z0tA
bEmp3VOqKMtQsmpJcxDMmytnzEcHh7WtoB1yzTsNZhfJCYJ1Ap3SS+ACJj3MV5mG
Rp0y1Zos25ebOT47nU8kSB8RD/UuR8cWGddFYbKR2F0op5BLi2jaLdE8BigUVLYb
E/b8eGdXOeNJ3M1I51WYCsm035/wcEMbO/yUnKcCq66gTedIeGQW29O0lQNgtUB9
ZL7Yy71YZETcymuNFIN1RK0MGUr3Y5osBHZ9bhaYVlYvEewnVwN6Bf8/fvnnW9N/
yBv9B8Wge/z/jtB/Xk8JwOs44aNSAvA6TviolAC8lhPu9Z9X4n8IHntOURax52R3
G//jAvD5+S8MxbGb9R8K38f/nVgTV1du6X7+OfwHvZNXWfC4rMOn15ecLPaCz9/u
Ddxe9cr8qTPDXMwjiYAgRtx+iqDwhNnxT83o9DMTBJ4IgTtBRkdPYOwKpq5weCKq
5tOn9wnXJzn+b37F7cdM/2/M/2AUe3H+E7vZ/0eg+/2fO7ExZicvAr3yUPTxB0T7
xJivQOQx9BCwY+fq9i/QVIwJTI2/HiOPsXfc2im86MmFikTMlQunifwGHm9Rnf6R
UNadU/vN1YQcS4S6zK8mTOlOPvt6/PncO60TPnEIb4Z7h4eAWV5N6OtGPrvntcD0
7LaxVTMUgkkSewhwThtcTT4UmB4CrJNlj+bc1eRlXBsvGMHxavIc3h4C8+chcjX5
dHPGWbOEcPlYGXkrtajv8fEShNmNaezbQkRjewoX+alWtjYo5e2gGaTS1iHlZ326
uZQPgckLCyzSJ5f2TOoC0+RK10bj1szDVccKicPn6sDPUZ80Bg2BB40rEX4NLs9h
20HKCfeaefXSw6rVcRnCp23hXyRXJPM1sc4oprAi6XSw126Fw2qBdlB4sJonn37R
p0fz4jCO8mejtq2aKxB81Sfv2SX63DtOFj6pG+dREznwOE5l0Y6PeaQERdhGV5Nx
6O7R9TsM//OgaZwwuOP9Pwh7cf57hH7i5vw3gd/j/z3+fyz4/1Gh/XsSwV6K/2sk
fwvveFP8QyRxm/9hY43r+Efg+/Ofd2KGRMM/9VLu/5knkwM5IyjUP6A4jPuI5wfU
GEw4jsEocX2ghnQdGMbgA3bP8N9l8R+HReDfefwj7/7/H0ZCOPHs/A95H/93YV/6
P0b7Veqnf3f9W3/5n9/42+/75f/65g/4f3X4+p/9w0/8wt8Mv/97f/jX/zt88Stf
+/Ljv/unb379+OvZvw3aN/7jn59+6vt/Q7n6sU3/RS36oT/5cS+a/8pXGLL7gy+R
eY1dET/8qa/+8Q9Wf/HlP6r/9DNf+J9f+8Wf/c3f/vs/z4p/Eb8Q/PePfu2Xfu53
rB/59381fvIfH05+Xr6PwE9c/D8OCu9u4/+F/nt9BOBG/yXuz//djf77bYoYwLcr
XADfilhxv+B4a/EfF+e4fTtbQG+Kfxy6Pv+D4SiMosTN+V9yzAnu4/9O4v9DN3k+
ZHfoffs/6JgQ4NRkrtlz84N2gdArCLmC0JtdoDfrDU/PT8bsu3xiNUFN/3875/Pa
NBiH8Yt6CBS0Q2SDYcYEkSl9k75Nmkmn7ebWde2WLm3646Jp2q7FtU2btq496EGc
KMgu4sH5a4dN8NccCMLYP6AMwcv+Bg/e1NMuZimTdlvXyWxx4/s5pQ0N5SXPk/d9
nrclaSuHrBhbaKb6cHiUHOYxWe8SBkK1CTFVTWbSpDDAGwjZ1vATeRvaWPWnbFIh
msyQmKNYmhz38Sa7yG+ckGy5vJKSlF5E8v0ev8mq3bwHPCTYqv9mVEAN9//p+Z+m
f9qCMMvqv/+k4fnfEiqCJbcJfVPnuyR/9XS0YxBorSR4jTK/zWywKUlfjUftlEvW
a4qqzKsSE0pyvrf629Ubir6awigcGnVEnP0IiZ5wjr4ezjNiqr/IZ9IBl2eo6PU5
BrITiUwg5p5yxcsOWqKUKXvOLE7kHEhQBbtU0/Ek4+p4NDnGZ7zh0FiJvpETJxKF
hKx6Is6AXxicGmYUJmvxjXmDTk+qzBSuZMxq0aUKTszlE6WhdM3FBkU5XZLCPT2l
8UlHKOT1ubOBsqtnREzwI5G436TkSgkxzYVkxr9bYbTDCFT/r0y9yshXUrRhlxRF
G0sprxm2SY0q2/NYCrMGwkDAo6GZ/t+MCqhh/4/MVf2Pvv7DDMz/wP8Pg/+DyQEH
yP+bUQE23P+JqD/zfxpZ9P5fewv8vwXo/d/W7OecjaRZhGWaZq04LtGUjCPIwkUQ
krUXmI1xEstIUQmbOVD/IdN/EyrAPfZ/Ff2z+v5P7RD03wpit+2TyoevQvtisv3j
fJz48e1pxN3xs+1I74vpO89MxqurnY/XnlxeLFx702lcIjvurZ8ods/MHQtevPD+
bbBr+dR5amnN25XtflV+/fCLPbs62/fO+OD7yqzx9EzqbtfLk4GznxZurp+JHZ0+
7l5+tPr8vtj2OfXr0sLKnHgrqM6DAv9H/f/bCnCP/Z+ufzOm9PyfhfVfS9hvJkXs
N4ci/iZ7gtkGAAAAAAAAAAAAAAAAAAAAAAAAAABAPX4DY+BfEQB4AAA=
-- END MESSAGE ARCHIVE --

Appendix C. Original Requirements ✨

okay so this is the history section, bestie 🕰️ these requirements were cooked up while the mechanism was still being designed, and they're kept here purely for historical reasons. they're basically the vibe check the whole thing was built around 💅

the mechanism must allow a UAC or a proxy server to provide a strong cryptographic identity assurance in a request that can be verified by a proxy server or UAS. 🔐
user agents that receive identity assurances must be able to validate these assurances without performing any network lookup. 🫶
user agents that hold certificates on behalf of their user must be capable of adding this identity assurance to requests. 🎀
proxy servers that hold certificates on behalf of their domain must be capable of adding this identity assurance to requests; a UAC is not required to support this mechanism in order for an identity assurance to be added to a request in this fashion. 🌸
the mechanism must prevent replay of the identity assurance by an attacker. 🚫
in order to provide full replay protection, the mechanism must be capable of protecting the integrity of SIP message bodies (to ensure that media offers and answers are linked to the signaling identity). 🦋
it must be possible for a user to have multiple AoRs (i.e., accounts or aliases) that it is authorized to use within a domain, and for the UAC to assert one identity while authenticating itself as another, related, identity, as permitted by the local policy of the domain. 👑

References ✨

Normative References

[1] 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. 📚
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
[3] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. 🕶️
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. 🗺️
[5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. 🪪
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 🧩
[7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. 🧮
[8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. 🔤
[9] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. 📜
[10] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999. 🗂️
[11] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 🔒

Informative References

[12] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. 🌐
[13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. ☎️
[14] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. 🔢
[15] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", Work in Progress, February 2005. 🚧
[16] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages, RFC 4475, May 2006. 🧪

Authors' Addresses 🏡

Here's where you can find the authors, bestie 💌

Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA  94520
US

Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI:   http://www.neustar.biz/


Cullen Jennings
Cisco Systems
170 West Tasman Drive
MS: SJC-21/2
San Jose, CA  95134
USA

Phone: +1 408 902-3341
EMail: fluffy@cisco.com

Full Copyright Statement ⚖️

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. ✍️

The legal fine print is that this document and everything in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙃

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on how rights work for RFC documents lives in BCP 78 and BCP 79. 📖

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🗃️

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📬

Acknowledgement 🌷

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 💖

📦 where this page comes from

ietf: rfc4474 2006-08
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms