RFC 8224
Authenticated Identity Management in the Session Initiation Protocol (SIP)
Part 1 of 11 💖 (the title block, abstract, status, copyright, table of contents, sections 1 and 2)
RFC 8224, Authenticated Identity Management in the Session Initiation Protocol (SIP) 🎀, is a Standards Track document from February 2018, so it's a real spec that implementers are meant to follow ✨. It was written by J. Peterson (NeuStar), C. Jennings (Cisco), E. Rescorla (RTFM, Inc.) and C. Wendt (Comcast). It's ISSN 2070-1721, and it obsoletes RFC 4474 🙈. The title block doesn't list any updates.
Abstract
okay so SIP's baseline security just isn't strong enough to cryptographically prove who is actually sending a SIP request 😭, especially when the request crosses from one domain to another. This doc fixes that by defining a way to securely identify whoever originated a request 🔐. It does this with a new SIP header field that carries a signature for checking the identity, plus a reference to the credentials of whoever signed it 🫶.
This document obsoletes RFC 4474.
Status of This Memo
This is an Internet Standards Track document 🦋.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 👑. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 💅.
For the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8224 🌸.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. ©️
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the date this document was published. Please read these carefully, because they spell out your rights and restrictions 📜. Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🧾.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Architectural Overview ..........................................5
4. Identity Header Field Syntax ....................................7
4.1. PASSporT Construction ......................................8
4.1.1. Example Full and Compact Forms of PASSporT
in Identity ........................................10
5. Example of Operations ..........................................11
5.1. Example Identity Header Construction ......................13
6. Signature Generation and Validation ............................14
6.1. Authentication Service Behavior ...........................14
6.1.1. Handling Repairable Errors .........................16
6.2. Verifier Behavior .........................................17
6.2.1. Authorization of Requests ..........................19
6.2.2. Failure Response Codes Sent by a
Verification Service ...............................19
6.2.3. Handling Retried Requests ..........................21
6.2.4. Handling the Full Form of PASSporT .................21
7. Credentials ....................................................22
7.1. Credential Use by the Authentication Service ..............22
7.2. Credential Use by the Verification Service ................23
7.3. "info" Parameter URIs .....................................24
7.4. Credential System Requirements ............................25
8. Identity Types .................................................26
8.1. Differentiating Telephone Numbers from URIs ...............26
8.2. Authority for Telephone Numbers ...........................27
8.3. Telephone Number Canonicalization Procedures ..............28
8.4. Authority for Domain Names ................................29
8.5. URI Normalization .........................................30
9. Extensibility ..................................................31
10. Backwards Compatibility with RFC 4474 .........................32
11. Privacy Considerations ........................................32
12. Security Considerations .......................................34
12.1. Protected Request Fields .................................34
12.1.1. Protection of the To Header and Retargeting .......36
12.2. Unprotected Request Fields ...............................37
12.3. Malicious Removal of Identity Headers ....................37
12.4. Securing the Connection to the Authentication Service ....38
12.5. Authorization and Transitional Strategies ................39
12.6. Display-Names and Identity ...............................40
13. IANA Considerations ...........................................40
13.1. SIP Header Fields ........................................40
13.2. SIP Response Codes .......................................41
13.3. Identity-Info Parameters .................................41
13.4. Identity-Info Algorithm Parameter Values .................41
14. Changes from RFC 4474 .........................................41
15. References ....................................................42
15.1. Normative References .....................................42
15.2. Informative References ...................................43
Acknowledgments ...................................................46
Authors' Addresses ................................................461. Introduction ✨
okay so this document is an upgrade to the existing ways SIP handles authenticated identity 💅 [RFC3261]. For this doc, an identity is either:
- a canonical address-of-record (AoR) SIP URI used to reach a user (like "sip:alice@atlanta.example.com") or
- a telephone number, which usually shows up either in a tel URI [RFC3966] or as the user part of a SIP URI.
[RFC3261] has a bunch of spots in a SIP request where users can state who they are, and the big one is the user-filled From header field 🙃. But without some kind of cryptographic authentication, the receiver has no way to check whether the From header was filled in honestly 😤. That leaves SIP open to impersonation attacks that make robocalling, voicemail hacking, swatting and similar problems easier, as described in [RFC7340] 💀. A cryptographic identity approach could give way stronger assurance than the Caller ID services the phone network has today, and it would be harder to spoof 🔥.
[RFC3261] encourages user agents (UAs) to support several authentication mechanisms, including Digest authentication, Transport Layer Security (TLS), and S/MIME (implementations may support other security schemes too). But honestly, few SIP UAs today support the end-user certificates needed to authenticate themselves (through S/MIME, for example), and Digest authentication has its own problem: the originator and destination have to share a secret ahead of time 🙄. In practice, originating UAs need a way to securely pass their users' identities to destinations they've never talked to before 🧚.
As a first attempt at closing that gap, [RFC4474] specified a way to sign parts of SIP requests to give an identity assurance 🌈. But [RFC4474] didn't line up with how deployments really work in several ways (see [SIP-RFC4474-CONCERNS]) 😭. Most importantly, [RFC4474] didn't handle telephone numbers as identifiers well, even though they're still used all over SIP deployments 📞. It also signed material that intermediaries in existing deployments often change 🙈. So this specification deprecates the syntax and behavior from [RFC4474]. It rethinks the problem using the threat model in [RFC7375] and lines up the signature format with PASSporT (Personal Assertion Token) [RFC8225] 🦋. Backwards-compatibility details are in Section 10 🎀.
2. Terminology 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] 🫶.
This doc also uses three terms that are specific to the mechanism:
- Identity: An identifier for the user of a communications service. For SIP, that's either a SIP URI or a telephone number. Identities are derived from an "identity field" in a SIP request, such as the From header field 🪪.
- Authentication Service: A logical role played by a SIP entity that adds Identity headers to SIP requests 🔏.
- Verification Service (or "Verifier"): A logical role played by a SIP entity that validates Identity headers in a SIP request 🔍.
3. Architectural Overview ✨
okay so the identity setup for SIP in this spec leans on a logical "authentication service" 🫶 that checks outgoing requests. It can live inside a UA or on a proxy server. Usually it's part of a network middleman like a proxy, and that's where the originating UAs send their unsigned requests. Once the sender has been authenticated through some prearranged method with the authentication service, the authentication service creates and adds an Identity header field to the request. This means computing crypto info, including a digital signature over some parts of the message, so other SIP entities can check that the sending user was authenticated and that their claim to a particular identity was authorized. These "verification services" 🕵️♀️ validate the signature and let people make policy decisions based on what the validation found. Iconic behaviour, honestly.
Policy decisions after validation depend a LOT on how much the verification service trusts the credentials the authentication service uses to sign requests. Robocalling, voicemail hacking, and swatting usually involve impersonating phone numbers, so credentials that relying parties trust to sign for telephone numbers are a key piece of the architecture 📞💀. Authority over telephone numbers is, sadly, not as easy to establish on the Internet as authority over traditional domain names. This document assumes that credentials for establishing authority over telephone numbers exist, for cases where the telephone number is the user's identity. It doesn't mandate or specify a credential system, though. [RFC8226] describes a credential system that is compatible with this architecture 🎀.
Addressing the vulnerabilities in the Secure Telephone Identity Revisited (STIR) problem statement [RFC7340] and threat model mostly means dealing with telephone numbers as identities, but SIP also has to handle signing for SIP URIs as identities 💅. This is typically easier, since these identities are issued by organizations that have authority over Internet domains. When a new user becomes associated with example.com, for example, the administrator of the SIP service for that domain can issue them an identity in that namespace, like sip:alice@example.com. Alice can then send REGISTER requests to example.com that make her UAs eligible to receive requests for sip:alice@example.com 🦋. Alternatively, Alice might own her own domain, in which case she can issue herself identities however she likes. But at the end of the day, the controller of the SIP service at example.com is the one who has to be responsible for authorizing the use of names in the example.com domain. So, for the purposes of SIP as defined in [RFC3261], the credentials needed to prove a user is authorized to use a particular From header field must ultimately derive from the domain owner. Either (1) a UA gives requests to the domain name owner so they can be signed with the domain owner's credentials, or (2) the UA must possess credentials proving that the domain owner has given the UA the right to a name. The domain owner really is the main character here 👑.
To share a cryptographic assurance of end-user SIP identity in an interdomain or intradomain context, an authentication service builds tokens based on the PASSporT format [RFC8225]. PASSporT is a special encoding of a JSON [RFC8259] object containing values derived from certain header field values in the SIP request ✨. The authentication service computes a signature over those JSON elements the way PASSporT specifies. The encoding of the resulting PASSporT then goes into the SIP Identity header field. To help validate the Identity header field, this specification also describes a parameter of the Identity header field that the recipient of a request can use to recover the signer's credentials 🔑.
Note that this document only covers identity assurance for SIP requests. Solving this problem for SIP responses is outside the scope of this work (see [RFC4916]) 🙈. Future work might specify ways a SIP implementation could gateway PASSporTs to other protocols 🌈.
4. Identity Header Field Syntax 💖
The Identity and Identity-Info header fields that were previously defined in [RFC4474] are deprecated by this document. This revised spec collapses the grammar of Identity-Info into the Identity header field via the info parameter. Note that, unlike the prior specification in [RFC4474], the Identity header field is now allowed to appear more than one time in a SIP request 🎀. The revised grammar for the Identity header field builds on the ABNF [RFC5234] in [RFC3261], Section 25. It looks like this:
Identity = "Identity" HCOLON signed-identity-digest SEMI
ident-info *( SEMI ident-info-params )
signed-identity-digest = 1*(base64-char / ".")
ident-info = "info" EQUAL ident-info-uri
ident-info-uri = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-type /
ident-info-extension
ident-info-alg = "alg" EQUAL token
ident-type = "ppt" EQUAL token
ident-info-extension = generic-param
base64-char = ALPHA / DIGIT / "/" / "+"In addition to the info parameter and the alg parameter previously defined in [RFC4474], this specification defines the optional ppt parameter (PASSporT Type) 🧚. The absoluteURI portion of ident-info-uri MUST contain a URI. See Section 7.3 for more on choosing how to advertise credentials through this parameter 🍓.
The signed-identity-digest contains a base64 encoding of a PASSporT [RFC8225]. That secures the request with a signature PASSporT generates over the JSON header and payload objects. Some of those header and claim element values will mirror values of the SIP request 💜.
4.1. PASSporT Construction
For SIP implementations to populate the PASSporT header JSON object with fields from a SIP request, the following elements MUST be placed as the values corresponding to the designated JSON keys:
- First, per the baseline PASSporT specification [RFC8225], the JSON
typkey MUST have the valuepassport. - Second, the JSON key
algMUST mirror the value of the optionalalgparameter in the SIP Identity header field. Note that if thealgparameter is absent from the Identity header, the default value isES256. - Third, the JSON key
x5uMUST have a value equivalent to the quoted URI in theinfoparameter, per the simple string comparison rules of [RFC3986], Section 6.2.1. - Fourth, if a PASSporT extension is in use, then the optional JSON key
pptMUST be present and have a value equivalent to the quoted value of thepptparameter of the Identity header field.
Here's an example of the PASSporT header JSON object without any extension 🌸:
{ "typ":"passport",
"alg":"ES256",
"x5u":"https://www.example.com/cert.cer" }To populate the PASSporT payload JSON object from a SIP request, the following elements MUST be placed as values corresponding to the designated JSON keys:
- First, the JSON
origobject MUST be populated. If the originating identity is a telephone number, then the array MUST be populated with a JSON object containing atnelement with a value set to the value of the quoted originating identity, a canonicalized telephone number (see Section 8.3). Otherwise, the object MUST be populated with a JSON object containing aurielement, set to the value of the AoR of the UA sending the message as taken from the addr-spec of the From header field, per the procedures in Section 8.5. - Second, the JSON
destarray MUST be populated. If the destination identity is a telephone number, then the array MUST be populated with a JSON object containing atnelement with a value set to the value of the quoted destination identity, a canonicalized telephone number (see Section 8.3). Otherwise, the array MUST be populated with a JSON object containing aurielement, set to the value of the addr-spec component of the To header field, which is the AoR to which the request is being sent, per the procedures in Section 8.5. Multiple JSON objects are permitted indestfor future compatibility reasons 🦋. - Third, the JSON key
iatMUST appear. The authentication service SHOULD set the value ofiatto an encoding of the value of the SIP Date header field as a JSON NumericDate (as UNIX time, per [RFC7519], Section 2). An authentication service MAY set the value ofiatto its own current clock time instead. If the authentication service uses its own clock time, then the use of the full form of PASSporT is REQUIRED. In either case, the authentication service MUST NOT generate a PASSporT for a SIP request if the Date header is outside of its local policy for freshness (sixty seconds is RECOMMENDED) ⏰. - Fourth, if the request contains a Session Description Protocol (SDP) message body and if that SDP contains one or more
a=fingerprintattributes, then the JSON keymkyMUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [RFC8225], Section 5.2.2.
For example:
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551213"]},
"iat":1443208345 }For info on the security properties of these SIP message elements and why including them mitigates replay attacks, see Section 12. Note that future extensions to PASSporT could introduce new claims, and that further SIP procedures could be required to extract information from the SIP request to populate the values of those claims. See Section 9 of this document 🔥.
The orig and dest arrays may contain identifiers of heterogeneous type. For example, the orig array might contain a tn claim, while the dest contains a uri claim. Also note that in some cases, the dest array may be populated with more than one value. This could, for example, occur when multiple dest identities are specified in a meshed conference. Defining how a SIP implementation would align multiple destination identities in PASSporT with such systems is left as a subject for future specifications 🌈.
After these two JSON objects, the header and the payload, have been constructed and base64-encoded, they must each be hashed and signed per [RFC8225], Section 6. The header, payload, and signature components together make up a full PASSporT object. The resulting PASSporT may be carried in SIP in either (1) a full form, which includes the header and payload as well as the signature, or (2) a compact form, which only carries the signature per [RFC8225], Section 7. The hashing and signing algorithm is specified by the alg parameter of the Identity header field and the mirrored alg parameter of PASSporT. All implementations of this specification MUST support the required signing algorithms of PASSporT. Right now there is one mandatory-to-support value for the alg parameter: ES256, as defined in [RFC7519], which connotes an Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 digital signature. that's the one, bestie 🌈👑
4.1.1. Example Full and Compact Forms of PASSporT in Identity
okay so bestie, this is where we look at what the PASSporT actually looks like inside an Identity header 🎀✨ As Appendix F of the JSON Web Signature (JWS) specification [RFC7515] points out, there are times when "it is useful to integrity-protect content that is not itself contained in a JWS." 🧐 Since most of the PASSporT header and payload fields already show up in the SIP request, SIP can skip the base64-encoded header and payload JSON objects in the Identity header field and just include a detached signature 💅 PASSporT calls this the compact form (see [RFC8225], Section 7). It's giving efficiency 🦋
When an authentication service builds an Identity header, the signed-identity-digest field MUST contain either a full or compact PASSporT 💖 Using the compact form is RECOMMENDED because it keeps message size down 🌸 But ngl, extensions often need the full form, so check Section 9 🔥
Here's an example of a full form PASSporT in an Identity header. The backslashes are only there for line folding 🌈
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w;info=<https://biloxi.example.org \
/biloxi.cert>The compact form of that same PASSporT object would show up in the Identity header like this 👑
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \
pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://biloxi.example.org/biloxi.cert>5. Example of Operations ✨
This section is an informative (non-normative) high-level example of how the mechanisms in this document work together 🧚 Nothing here is a hard requirement, it's just a story to help you get it 💜
Picture this: Bob has the home proxy of example.com and the AoR sip:12155551212@example.com;user=phone, and he wants to talk to Alice at sip:alice@example.com 💌 They've never talked before, and Alice follows best practices to stop impersonation attacks 🙈
Bob's UA makes an INVITE and puts his AoR in the From header field 🎀 Then he sends that INVITE to an authentication service proxy for his domain 💅
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. Signs for | | . Signed . | | .
. 12125551xxx| Auth |------------> | Verif | .
. | Svc | . INVITE . | Svc | .
. | Proxy | . . | Proxy | .
. > +-------+ . . +-------+ \ .
. / | . -> \ .
. / | . --. \ .
. / | . -- . \ .
. / | . -- . \ .
. / +-------+. -- . \ .
. / | |.<- . \ .
. / | Cert |. . > .
. +-------+ | Store |. . +-------+ .
. | | | |. . | | .
. | Bob | +-------+. . | Alice | .
. | UA | . . | UA | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................The proxy checks Bob's credentials and confirms he's allowed to claim the identity he put in the From header field 🔐 Then the proxy's authentication service builds a PASSporT with a JSON representation of values that mirror parts of the SIP request, including the identity in the From header field value ✨ While building it, the authentication service signs a hash of that JSON header and payload with the private key tied to the right credential for the identity (in this example, a certificate allowed to sign for numbers from 12155551000 to 12155551999) 🌸 The signature then goes into the request's Identity header field value as a compact form of PASSporT 💖 Or, if they want, the JSON header and payload can be included too, which is the full form 🦋
The authentication service is holding a private key with authority over Bob's phone number, so it's basically saying "yep, this originator was authenticated and is allowed to claim the identity in the From header field" 💅 The proxy also adds an "info" parameter to the Identity header field so Alice knows where to get the keying material (a public key) to validate the credentials, just in case she doesn't have it already 🫶
When Alice's domain gets the request, a proxy verification service checks the signature in the Identity header field, then confirms the authentication service's credentials really do have authority over the identity in the From header field 🔥 The same validation could also be done by a verification service in Alice's UA server (UAS) 👑 If everything checks out, the request gets shown to Alice 🌈 If validation fails, the receiving domain or Alice's UA could do something else with it 🙈
5.1. Example Identity Header Construction 🎀
For the following SIP request:
INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com>
From: Bob <sip:12155551212@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2015 19:12:25 GMT
Contact: <sip:12155551212@gateway.example.com>
Content-Type: application/sdp
Content-Length: ...
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/8000An authentication service is going to make a matching PASSporT object 🧚 The properly serialized PASSporT header and payload JSON objects would look like this. For the header, the values the authentication service picks at "example.com" might read:
{"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/
passport.cer"}The serialized payload pulls its values from the SIP request (the From, To, and Date header field values) like so 💜
{"dest":{"uri":["sip:alice@example.com"]},"iat":1443208345,
"orig":{"tn":"12155551212"}}Then the authentication service generates the signature over the object, following the procedures in [RFC8225], Section 6 🔐 That signature looks like this:
rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7wAn authentication service signing this request and using the compact form of PASSporT would add an Identity header field like this to the request 🦋
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://cert.example.org/passport.cer>6. Signature Generation and Validation 💖
SIP entities that play the authentication service and verification service roles will generate and validate the Identity header and the signature it contains, respectively 🌸
6.1. Authentication Service Behavior ✨
Okay bestie, the authentication service role 🔐 is the one that does the signing. Any entity that plays this role MUST possess the private key of one or more credentials that can be used to sign for a domain or a telephone number (see Section 7.1). It can be played by an intermediary like a proxy server, or by a UA. Intermediaries that play this role MUST be capable of authenticating one or more SIP users who can register for that identity. Commonly, a proxy server takes this role, since proxies are more likely to have a static hostname, hold the matching credentials, and have access to SIP registrar capabilities that let them authenticate users 💅. It's also possible that a redirect server could take it on, but that is left as a topic for future work 🧚.
An authentication service adds the Identity header field to SIP requests 🎀. The procedures below define the steps that must be taken when each Identity header field is added. A request can have more than one Identity header field, and an authentication service can add one to a request that already has one or more of them 🦋.
Entities playing the authentication service role follow these steps, in order, to generate an Identity header field for a SIP request:
Step 1: Check Authority for the Identity 👑
First, the authentication service has to figure out whether it is authoritative for the identity of the request's originator. It pulls the identity from the URI value in the "identity field", which in normal operations is the addr-spec part of the From header field. To decide whether the signature for the identity field should cover the entire URI or just a telephone number, the authentication service MUST follow the process described in Section 8.1. That section leads either to the telephone number canonicalization procedures in Section 8.3 or to the URI normalization procedures in Section 8.5 for domain names. Either way, if the authentication service is not authoritative for the identity in question, it SHOULD process and forward the request normally, unless local policy is to block such requests 🙈. The authentication service MUST NOT add an Identity header field if it does not have the authority to make the claim it asserts 🚫.
Step 2: Authenticate the Originator 🔥
Next, the authentication service MUST determine whether the originator of the request is authorized to claim the identity given in the identity field. To do that, it MUST authenticate the originator of the message. Some possible ways to do this include the following:
- If the authentication service is instantiated by a SIP intermediary (proxy server), it may authenticate the request with the authentication scheme used for registration in its domain (for example, Digest authentication) 🌸.
- If the authentication service is instantiated by a SIP UA, the UA may authenticate its own user through any system-specific means, perhaps simply by virtue of having physical access to the UA 💜.
Whether a particular username or telephone number may be used in the user part of the From header field is a matter of local policy for the authentication service. See Section 7.1 for more information.
Note that this check is only performed on the addr-spec in the identity field (for example, the URI of the originator, like sip:alice@atlanta.example.com). It does not cover the display-name portion of the From header field (for example, "Alice Atlanta"). For more information, see Section 12.6 🕵️♀️.
Step 3: Verify Date is Present and Valid ⏰
An authentication service MUST add a Date header field to SIP requests that don't have one. It MUST also ensure that any preexisting Date header field in the request is accurate. Local policy can dictate exactly how accurate the Date must be. A RECOMMENDED maximum discrepancy of sixty seconds will keep the request unlikely to upset any verifiers 🍓. If the Date header field value differs by more than one minute from the current time noted by the authentication service, the authentication service SHOULD reject the request 😭. Finally, the authentication service MUST verify that both the Date header field and the current time fall within the validity period of its credential ✨.
See Section 12.1 for information on how the Date header field helps verifiers.
Step 4: Populate and Add the Identity Header 🧩
After that, the authentication service MUST form a PASSporT object and add a matching Identity header field to the request, containing either the full or compact form of PASSporT. For the baseline PASSporT header (headers containing no ppt parameter), this follows the procedures in Section 4. If the authentication service is using an alternative ppt format, it MUST add an appropriate ppt parameter and follow the procedures associated with that extension (see Section 9). Once the Identity header field has been added to the request, the authentication service MUST also add an info parameter to the Identity header field. The info parameter holds a URI where the authentication service's credential can be acquired. See Section 7.3 for more on credential acquisition 🗝️.
An authentication service MAY use the full form of the PASSporT in the Identity header field. Including the full form is OPTIONAL, because the information in the baseline PASSporT headers and claims is usually redundant with information already carried elsewhere in the SIP request. Using the compact form can significantly shrink the SIP message size, especially when the PASSporT payload contains media keys 📉. The syntax of the compact form is given in [RFC8225], Section 7. Essentially, it contains only the signature component of the PASSporT 💖.
Note that, per the behavior specified in [RFC8225], use of the full form is mandatory when optional extensions are included. See Section 9.
6.1.1. Handling Repairable Errors 🛠️
Sometimes a request signed by an authentication service will get rejected by the verification service on the receiving side. The authentication service will then get a SIP 4xx status code in the backwards direction, such as a 438 ("Invalid Identity Header") response, which means a verification failure happened. If the authentication service did not originally send the full form of the PASSporT object in the Identity header field, it SHOULD retry the request with the full form after receiving a 438 response. However, implementations SHOULD NOT retry the request more than once 🔁. Authentication services implemented at proxy servers would retry such a request as a sequential fork, by reprocessing the destination as a new target and handling it serially as described in Section 16.6 of [RFC3261] 🦋.
The full form is useful on the verification side for debugging errors. There are also some known causes of verification failures, such as the Date header field value changing in transit (see Section 12.1 for more information), that can be resolved by including the full form of PASSporT 🌈.
Finally, the authentication service forwards the message normally 💅.
6.2. Verifier Behavior ✨
okay so this section is all about the verifier, aka the verification service 💅. it's a logical role for SIP entities, not a specific box. when a verifier gets a SIP message with one or more Identity header fields, it inspects the signature(s) to check who the message is actually from. then the results get fed into an authorization process, which is outside the scope of this doc, so we're not going there today 🫶.
A SIP request can have zero, one, or many Identity header fields. A verification service runs the steps below on each Identity header field that shows up in a request. If it can't use any Identity header in a request, because there are none or the "ppt" parameters are unsupported, AND local policy says an Identity header field is required (like a per-sending-domain or per-sending-user policy), then a 428 "Use Identity Header" response MUST be sent in the backwards direction. more on that and the other verifier responses is in Section 6.2.2 🦋.
to verify an Identity header field, an entity acting as a verifier MUST perform the following steps, in the order listed. and heads up, when an Identity header field has a full-form PASSporT object, the verifier MUST also follow the extra procedures in Section 6.2.4 🎀.
Step 1: Check for an Unsupported "ppt"
the verifier MUST inspect any optional "ppt" parameter in the Identity header. if there's no "ppt" parameter, the verifier just proceeds normally with Steps 2 through 5 🌸. if a "ppt" parameter value is present and the verifier doesn't support it, it MUST ignore the Identity header field 🙈. and if a supported "ppt" parameter value is present, the verifier proceeds with Step 2 and will ultimately follow the "ppt" variations described in Step 5 ✨.
Step 2: Determine the Originator's Identity
so to figure out whether the signature for the identity field should cover the entire identity field URI or just a telephone number, the verification service MUST follow the process described in Section 8.1 💅. that section will lead to either the telephone number canonicalization procedures in Section 8.3 (for telephone numbers) or the URI normalization procedures described in Section 8.5 (for domain names) 🔥.
Step 3: Identify Credential for Validation
the verifier must ensure that it has access to the proper keying material to validate the signature in the Identity header field. this usually means dereferencing a URI in the info parameter of the Identity header field 🔑. see Section 7.2 for more on these procedures. if the verifier doesn't support the credential described in the info parameter, then it treats the credential for this header field as unsupported 🙅♀️.
Step 4: Check the Freshness of Date
the verifier furthermore ensures that the value of the Date header field of the request meets local policy for freshness (sixty seconds is RECOMMENDED ⏰), and that it falls within the validity period of the credential used to sign the Identity header field. for more on the attacks this prevents, see Section 12.1 💀. if the full form of the PASSporT is present, the verifier SHOULD compare the iat value in the PASSporT to the Date header field value in the request 👀. if the two are different, and the iat value differs from the Date header field value but remains within verification service policy for freshness, the verification service SHOULD perform the computation required by Step 5, using the iat value instead of the Date header field value 🧚.
Step 5: Validate the Signature
the verifier MUST validate the signature in the Identity header field over the PASSporT object 🔐. for baseline PASSporT objects (with no Identity header field "ppt" parameter), the verifier MUST follow the procedures for generating the signature over a PASSporT object as described in Section 4 🍓. if a "ppt" parameter is present (and, per Step 1, is supported), the verifier follows the procedures for that "ppt" (see Section 9) 💜. if a verifier determines that the signature in the Identity header field does not correspond to the reconstructed signed-identity-digest, then the Identity header field should be considered invalid 💔.
6.2.1. Authorization of Requests
the verification of an Identity header field doesn't entail any particular treatment of the request 🤷♀️. how the message gets handled after verification depends on how the verification service is implemented and on local policy. this spec does not propose any authorization policy for UAs or proxy servers to follow based on: a valid Identity header field, an invalid Identity header field, no Identity header field at all, or a stale Date header field value 🙅. BUT it's anticipated that local policies could involve making different forwarding decisions in intermediary implementations, or changing how the user is alerted or how identity is rendered in UA implementations 📱✨.
so here's the tea: multiple Identity header fields in one message means a verification service could get a message with both valid AND invalid Identity header fields 😵💫. as a guideline, this specification recommends that only if a verifier determines that all Identity header fields within a message are invalid should the request be considered to have an invalid identity. and if at least one Identity header field value is valid and from a trusted source, then relying parties can use that header for authorization decisions, regardless of whether other untrusted or invalid Identity headers appear in a request 🫶🌈.
6.2.2. Failure Response Codes Sent by a Verification Service
[RFC4474] originally defined four response codes for failure conditions specific to the Identity header field and its original mechanism 📜. these status codes are retained in this specification, with some slight modifications. also, this specification details responding with a 403 "Forbidden" response when a stale Date header field value is received. see below 👇.
a 428 response will be sent (per Section 6.2) when an Identity header field is required but no Identity header field without a "ppt" parameter, or with a supported "ppt" value, has been received 🙋♀️. in the case where one or more Identity header fields with unsupported "ppt" values have been received, a verification service may send a 428 with a human-readable reason phrase like "Use Supported PASSporT Format" 💬. note, however, that this specification gives no guidance on how a verification service might decide to require an Identity header field for a particular SIP request. those authorization policies are outside the scope of this specification 🚫.
the 436 "Bad Identity Info" response code indicates an inability to acquire the credentials the verification service needs for validating the signature in an Identity header field 🥲. again, given the potential presence of multiple Identity header fields, this response code should only be sent when the verification service is unable to dereference the URIs and/or acquire the credentials associated with all Identity header fields in the request. this failure code could be repairable if the authentication service resends the request with an info parameter pointing to a credential that the verification service can access 🛠️.
the 437 "Unsupported Credential" response (previously "Unsupported Certificate"; see Section 13.2) is sent when a verification service can acquire, or already holds, the credential represented by the info parameter of at least one Identity header field in the request, but does not support said credential(s). reasons for that include failing to trust the issuing certification authority (CA), or failing to support the algorithm the credential was signed with 🚫🔏.
the 438 "Invalid Identity Header" response indicates that, of the set of Identity header fields in a request, no header field with a valid and supported PASSporT object has been received 💔. like the 428 response, this is sent by a verification service when its local policy dictates that a broken signature in an Identity header field is grounds for rejecting a request. BUT, note that in some cases an Identity header field may be broken for reasons other than an originator trying to spoof an identity. for example, when a transit network alters the Date header field of the request 🚚. sending a full-form PASSporT can repair some of these conditions (see Section 6.2.4), so the recommended way to attempt to repair this failure is to retry the request with the full form of PASSporT if it had originally been sent with the compact form 🔁✨. the alternative reason phrase "Invalid PASSporT" can be used when an extended full-form PASSporT lacks required headers or claims, or when an extended full-form PASSporT signaled with the "ppt" parameter lacks required claims for that extension 📝. sending a string along these lines will help humans debugging the sending system 🧑💻💖.
finally, a 403 response may be sent when the verification service receives a request with a Date header field value that is older than the local policy for freshness permits 🕰️. the same response may be used when the iat in the full form of a PASSporT has a value older than the local policy for freshness permits. the reason phrase "Stale Date" can be sent to help humans debug the failure 🫠.
future specifications may explore ways, including Reason codes or Warning headers, to communicate further information. that could be used to disambiguate the source of errors in cases with multiple Identity headers in a single request, or to provide similar detailed feedback for debugging purposes 🔮🌸.
6.2.3. Handling Retried Requests
if a verification service sends a failure response in the backwards direction, the authentication service may retry the request as described in Section 6.1.1 🔄. if the authentication service is instantiated at a proxy server, then it will retry the request as a sequential fork. verification services implemented at a proxy server will recognize this request as a spiral rather than a loop, thanks to the proxy behavior fix documented in [RFC5393], Section 4.2 🌀. BUT if the verification service is implemented in an endpoint, the endpoint will need to override the default UAS behavior (in particular, the SHOULD in [RFC3261], Section 8.2.2.2) to accept this request as a spiral rather than a loop 🦋💅.
6.2.4. Handling the Full Form of PASSporT 🎀
okay so if the full form of PASSporT is sitting in an Identity header, that unlocks the optional extensions from [RFC8225], Section 8.3 ✨ and it's giving extra info. the verification service can pull the canonical telephone numbers the authentication service made out of the "orig" and "dest" elements of the full form, plus an "iat" claim that matches the Date header field the authentication service used 💖. these are super handy for debugging canonicalization problems, and they can also stop unnecessary signature breakage caused by intermediaries that mess with certain SIP header field values in transit 🦋
BUT bestie, listen up 😭 the verification service MUST NOT treat the value in the "orig" of a full-form PASSporT as the originating identity of the call 🚫 the real originating identity always comes from the SIP signaling, and that's the value the verifier uses, following the procedures in Section 6.2 Step 2, to recompute the signature 💅 this is the one users actually see in normal SIP operations, not whatever is inside the PASSporT object. if a verifier just trusted that the "orig" matched the call without checking it against the call signaling, that would open the door to cut-and-paste attacks 💀 scary stuff!!
🌸 also, when the full form is present, the verification service MAY delay the cryptographic operation and first compute its own canonicalization of an originating telephone number, then compare it to the values in the "orig" element of PASSporT ✨ this lets the verifier check whether both ends agree on the canonical number form. if they don't agree, the signature validation would fail, so no cap, that's a quick way to see it 🙈
7. Credentials 🔐
okay this section is all about how credential systems get used by authentication and verification services, plus the requirements any credential system has to meet to fit this architecture 🧚 it does NOT pick a specific credential system, so you're free to choose what fits 💜
ngl the spec lets either a UA or a proxy server handle the authentication service function and/or the verification service function 🫶 for end-to-end security, it's obviously preferable for end systems to get their own credentials, and in that case UAs can act as authentication services 👑 but for some deployments, end-user credentials may be neither practical nor affordable, since a single user might have a ton of SIP UAs (phones, PCs, laptops, PDAs, gaming devices) 😭 syncing keying material across all of them can be prohibitively complex and need a good deal of extra endpoint behavior, and juggling several credentials for the devices can be burdensome too 🍓 so, for credential management alone, putting the authentication service at an intermediary may be more practical 💅 implementers need to understand this trade-off, periodt ✨
7.1. Credential Use by the Authentication Service 🌈
to act as an authentication service, a SIP entity MUST possess the private keying material of one or more credentials that cover domain names or telephone numbers 🔑 hmm, wait, let me be precise: the original wording here says "must" in lowercase, so there's no BCP 14 keyword to keep, and I'll just say it plainly. A credential can represent authority over one domain (like example.com) or a set of domains it enumerates 🌸 it can also cover a single telephone number or a range of them 📞 how the scope of a credential's authority is expressed depends on the credential mechanism itself 💜
who gets to use a particular username or telephone number in the From header field value? that's a local policy call for the authentication service 🎀 and it depends a lot on how authentication is done 🦋 for non-telephone-number user parts, one policy could be: the username in the "username" parameter of the Proxy-Authorization header field has to match the username in the From header field of the SIP message, exactly 💖 but honestly, that's too limiting in lots of cases 😭 a realm might use "username" parameters in Proxy-Authorization that don't line up with the user portion of From fields, or a user might manage multiple accounts in the same administrative domain 👑 in that second case, the domain might keep a mapping between the "username" parameter values and a set of one or more SIP URIs that could legitimately be asserted for that "username" ✨ for example, the username can correspond to the "private identity" defined by the Third Generation Partnership Project (3GPP) [TS-3GPP.23.228], in which case the From header field can contain any one of the public identities tied to that private identity 🧚 another policy could then be: the URI in the From header field must match exactly one of the mapped URIs for the "username" in the Proxy-Authorization header field 💅 this is a suitable approach for telephone numbers in particular 📞
this spec could also work with credentials covering a single name or URI, like alice@example.com or sip:alice@example.com 🌸 that would need a tweak to authentication service behavior so it operates on a whole URI instead of a domain name 🫶 since it's not believed to be a pressing use case, it's been deferred to future work, but implementers should totally note it as a possible future direction 🔮
there are exceptions to these policies for cases like anonymity 🙈 if the AoR in the From header field uses a form like "sip:anonymous@example.com" (see [RFC3323]), then the "example.com" proxy might authenticate only that the user is a valid user in the domain, and still insert the signature over the From header field as usual 💜
7.2. Credential Use by the Verification Service 🔍
to act as a verification service, a SIP entity has to have a way to acquire credentials for authorities over particular domain names, telephone numbers, and/or number ranges 🦋 dereferencing the URI found in the "info" parameter of the Identity header field (as described in Section 7.3) MUST be supported by all verification service implementations 💖 that gives everyone a baseline way to get credentials 💅 if the credential used to sign a message isn't already known to the verifier, SIP entities SHOULD discover it by dereferencing the "info" parameter 🌟 the exception is if they have some implementation-specific way of getting the keying material, like an offline store of periodically updated credentials 🍓 and the 436 "Bad Identity Info" response exists for cases where the verification service can't dereference the URI in the "info" parameter 🙈
this spec doesn't propose any particular policy for a verification service to decide whether the holder of a credential is the right party to sign for a given SIP identity 🤷♀️ guidance on that is deferred to the credential mechanism specifications 📜
verification service implementations may want some way to keep credentials around (following normal practices for credential lifetimes and revocation) so they don't keep needlessly downloading the same credential every time a request from the same identity shows up 💜 credentials cached this way can be indexed however local policy says, like by their scope of authority or by the URI in the "info" parameter value 🎀 how to cache credentials in more detail is deferred to the credential mechanism specifications ✨
7.3. "info" Parameter URIs 🔗
an "info" parameter MUST contain a URI that dereferences to a resource holding the public key components of the credential the authentication service used to sign a request 🔑 it's essential that a URI in the "info" parameter be dereferencable by any entity that could plausibly receive the request 😭 for common cases, that means the URI SHOULD be dereferencable by any entity on the public Internet 🌐 in constrained deployment environments, a service private to the environment MAY be used instead 🏠
the "info" parameter does more than give access to credentials for an identity 🦋 it also tells you which particular credential signed a request, when there are potentially multiple authorities eligible to sign 💅 for example, picture a domain that handles the authentication service role for a range of telephone numbers, while a UA belonging to Alice has acquired a credential for a single telephone number inside that range 📞 either one would be eligible to sign a SIP request for that number 🌸 verification services, though, need a way to tell which one actually did the signing, and the "info" parameter is what does that job 💖
7.4. Credential System Requirements ✨
Okay so this document is super chill and makes no recommendation for any specific credential system 🫶 Right now there are two main ways to prove you own a domain name: certificates (like X.509 v3, see [RFC5280]) and the domain name system itself (like DNS-Based Authentication of Named Entities (DANE), see [RFC6698]). Either one could totally work in the SIP identity context 💅 For example, an "info" parameter could give an HTTP URL with the Content-Type application/pkix-cert that points to a certificate (following the conventions of [RFC2585]). The "info" parameter might also use the DNS URL scheme (see [RFC4501]) to designate keys in the DNS 🌸
No comparable public credentials exist for telephone numbers yet 😭 but either approach could be applied to telephone numbers 🎀 A credential system based on certificates is given in [RFC8226], but this specification can work with other credential systems too. For example, using the DNS was proposed in [CIDER] ✨
In order for a credential system to work with this mechanism, its specification must detail:
- which URI schemes the credential will use in the
"info"parameter, and any special procedures required to dereference the URIs, - how the verifier can learn the scope of the credential,
- any special procedures required to extract keying material from the resources designated by the URI,
- any algorithms required to validate the credentials (e.g., for certificates, any algorithms used by certificate authorities to sign certificates themselves), and
- how the associated credentials will support the mandatory signing algorithm(s) required by PASSporT [RFC8225].
SIP entities cannot reliably predict where SIP requests will terminate 🙈 So when choosing a credential scheme for deployments of this specification, it is therefore essential that the trust anchor(s) for credentials be widely trusted, or that deployments restrict the use of this mechanism to environments where the reliance on particular trust anchors is assured by business arrangements or similar constraints.
Key lifecycle management is a big deal, bestie 😭 Credential systems must address key lifecycle management concerns: if a domain changed the credential available at the Identity header field"info"parameter URI before a verifier evaluates a request signed by an authentication service, that would cause obvious verifier failures. When a rollover occurs, authentication services SHOULD thus provide new"info"URIs for each new credential, and SHOULD continue to make older key acquisition URIs available for a duration longer than the plausible lifetime of a SIP transaction (a minute would most likely suffice). 🔥
8. Identity Types 🦋
The STIR problem statement [RFC7340] focuses primarily on cases where the called and calling parties identified in the To and From header field values use telephone numbers, since that's still the dominant use case in the deployment of SIP 📞 However, the Identity header mechanism also works with SIP URIs without telephone numbers (of the form "sip:user@host") and, potentially, other identifiers when SIP interworks with other protocols ✨
Authentication services confirm the identity of the originator of a call, which is typically found in the From header field value. The guidance in this specification also applies to extracting the URI containing the originator's identity from the P-Asserted-Identity header field value instead of the From header field value. In some trusted environments, the P-Asserted-Identity header field is used in lieu of the From header field to convey the AoR or telephone number of the originator of a request, so local policy might therefore dictate that the canonical identity derives from the P-Asserted-Identity header field rather than the From header field 👑
Ultimately, in any case where local policy canonicalizes the identity into a form different from how it appears in the From header field, the use of the full form of PASSporT by authentication services is RECOMMENDED 🎀 But because the "orig" claim of PASSporT itself could then divulge information about users or networks, implementers should be mindful of the guidelines in Section 11 🙈
8.1. Differentiating Telephone Numbers from URIs 🌈
In order to determine whether or not the user portion of a SIP URI is a telephone number, authentication services and verification services MUST perform the following procedure on any SIP URI they inspect that contains a numeric user part. Note that the same procedures are followed for creating the canonical form of a URI found in the From header field as the procedures used for a URI found in the To header field or the P-Asserted-Identity header field 💖
First, implementations will ascertain if the user portion of the URI constitutes a telephone number. Telephone numbers most commonly appear in SIP header field values in the username portion of a SIP URI (e.g., "sip:+17005551008@chicago.example.com;user=phone"). The user part of SIP URIs with the "user=phone" parameter conforms to the syntax of the tel URI scheme [RFC3966]. It is also possible for a tel URI to appear in SIP header fields outside the context of a SIP or Session Initiation Protocol Secure (SIPS) URI (e.g., "tel:+17005551008"). Thus, in standards-compliant environments, numbers will be explicitly labeled by the use of tel URIs or the "user=phone" parameter 🧚
Alternatively, implementations in environments that do not conform to those standards MAY follow local policies for identifying telephone numbers. For example, implementations could infer that the user part is a telephone number due to the presence of the "+" indicator at the start of the user portion. Absent even that indication, if there are numbers present in the user portion, implementations might conceivably also detect that the user portion of the URI contains a telephone number by determining whether or not those numbers would be dialable or routable in the local environment -- bearing in mind that the telephone number may be a valid E.164 number [E.164], a nationally specific number, or even a private branch exchange number. Implementations could also rely on external hints: for example, a verification service implementation could infer from the type of credential that signed a request that the signature must be over a telephone number. 🦋
Regardless of how the implementation detects telephone numbers, once a telephone number has been detected, implementations SHOULD follow the procedures in Section 8.3 ✨ If the URI field does not contain a telephone number, or if the result of the canonicalization of the From header field value does not form a valid E.164 telephone number, the authentication service and/or verification service SHOULD treat the entire URI as a SIP URI and apply the procedures in Section 8.5. These URI normalization procedures are invoked to canonicalize the URI before it is included in a PASSporT object in, for example, a "uri" claim. See Section 8.5 for that behavior 💅
8.2. Authority for Telephone Numbers 🌸
In order for telephone numbers to be used with the mechanism described in this document, authentication services must receive credentials from an authority for telephone numbers or telephone number ranges, and verification services must trust the authority employed by the authentication service that signs a request. Per Section 7.4, enrollment procedures and credential management are outside the scope of this document 🙈 approaches to credential management for telephone numbers are discussed in [RFC8226].
8.3. Telephone Number Canonicalization Procedures 💜
Once an implementation has identified a telephone number, it must construct a number string. That requires performing the following steps:
- Implementations MUST drop any "+"s, internal dashes, parentheses, or other non-numeric characters, except for the "#" or "" keys used in some special service numbers (typically, these will appear only in the To header field value). This MUST result in an ASCII string limited to "#", "", and digits without whitespace or visual separators.
- Next, an implementation must assess if the number string is a valid, globally routable number with a leading country code.
If not, implementations SHOULD convert the number into E.164 format, adding a country code if necessary. This may involve transforming the number from a dial string (see [RFC3966]), removing any national or international dialing prefixes, or performing similar procedures. It is only in the case that an implementation cannot determine how to convert the number to a globally routable format that this step may be skipped. This will be the case, for example, for nationally specific service numbers (e.g., 911, 112); however, calls to those numbers are routed in a very strict fashion, which ordinarily prevents them from reaching entities that don't understand the numbers. 🚨
- Some domains may need to take unique steps to convert their numbers into a global format, and such transformations during canonicalization can also be made in accordance with specific policies used within a local domain. For example, one domain may only use local number formatting and need to convert all To/From header field user portions to E.164 by prepending country-code and region-code digits; another domain might have prefixed usernames with trunk-routing codes, in which case the canonicalization will need to remove the prefix. This specification cannot anticipate all of the potential transformations that might be useful. 🌈
- The resulting canonical number string will be used as input to the hash calculation during signing and verifying processes.
The ABNF of this number string is:
tn-spec = 1*tn-char
tn-char = "#" / "*" / DIGITThe resulting number string is used in the construction of the telephone number field(s) in a PASSporT object. 🎀
8.4. Authority for Domain Names ✨
okay so bestie, this part is about how you prove you actually own a domain name when a SIP URI is being used as your identity 🌸 like, to use a SIP URI as an identity in this mechanism, the authentication and verification systems have to support the standard ways of proving authority over a domain name. that means the domain in the host part of the SIP URI, aka the bit after the @ 💅
A verifier MUST check that the user's identity matches the signing credential by following the procedures in [RFC5922], Section 7.2. ngl [RFC5922] is all about TLS and it's super certificate-focused, but the same procedures totally work for verifying identity too. you just swap in the "hostname of the server" for the domain part of the user's identity, which is the From header field of a SIP request that has an Identity header field 🦋
this gets a bit messy for two reasons 🙈 first, credentials describe their subjects in different ways, and they might even have multiple subjects, especially in "virtual hosting" setups where one application runs a bunch of domains (see [RFC5922], Section 7.8). second, some SIP services hand off SIP work to a subordinate domain and use the procedures in [RFC3263] so that requests for, say, "example.com" get routed to "sip.example.com". so a user with the AoR "sip:alice@example.com" might be going through a host like "sip.example.com", and that host could be the one acting as the authentication service 🧚
to deal with that second problem, a domain running an authentication service on a subordinate host might give that host the private keying material for a credential whose subject is a domain name matching the domain part of the AoRs the domain hands out to users. this is basically the same idea as routing inbound SIP requests to a domain 💜 when the NAPTR and SRV procedures of [RFC3263] send requests to a domain name that isn't the domain in the original Request-URI (like, for "sip:alice@example.com", the SRV records point to the service "sip1.example.org"), the client expects the certificate that comes back in any TLS exchange with that host to match the domain of the original Request-URI exactly, not the host's domain name 🎀
so, to make inbound routing to these SIP services work, a domain admin has to be willing to share the domain's private key with the service too. this design choice was made to make up for how insecure the DNS is, and it means some DNS-based "virtual hosting" approaches just can't be secured for SIP in environments where admins won't share keys with hosting services 😭 that's a real tradeoff, bestie.
8.5. URI Normalization 🍓
just like telephone numbers can get changed in a bunch of syntactic ways in transit, the same thing can happen to SIP and SIPS URIs that don't have telephone numbers as they go through certain intermediaries 🌈 so when you generate a PASSporT object from a SIP request, any SIP and SIPS URIs MUST be transformed into a canonical form that captures the AoR the URI represents, before they get put into PASSporT claims like "uri". here are the normalization procedures you need 💖
following the ABNF of [RFC3261], the SIP or SIPS URI in question MUST discard all elements after the "hostport" of the URI, including all uri-parameters and escaped headers, from its syntax. of the userinfo part of the SIP URI, only the user element is kept. any password (and any leading ":" before the password) MUST be removed, and since this userinfo can't contain a telephone-subscriber component, no further parameters can show up in the user portion ✨
the hostport part of the SIP or SIPS URI MUST also be stripped of any trailing port, along with the ":" that comes before the port, so only the host is left 🫶
the ABNF for this canonical URI form (following the syntax in [RFC3261]) is:
canon-uri = ( "sip" / "sips" ) ":" user "@" hostlast step: the URI gets run through the syntax-based URI normalization procedures of [RFC3986], Section 6.2.2. implementations MUST do case normalization (making the scheme, user, and host all lowercase) and percent-encoding normalization (decoding any percent-encoded octet that matches an unreserved character, per [RFC3986], Section 2.3). however, normalization has known challenges in some internationalized environments (see [IRI-COMPARISON]), so perfect normalization of URIs may not be possible in those environments 🌸
for future PASSporT applications, it might be useful to have an identifier without an attached protocol scheme. future specs that define PASSporT claims for SIP as a using protocol could use these basic procedures but drop the scheme component. a more exact definition is left to future specifications 🦋
9. Extensibility 👑
as future requirements might call for widening the scope of the Identity mechanism, this specification defines an optional "ppt" parameter for the Identity header field, which mirrors the "ppt" header in PASSporT 💅 the "ppt" parameter value MUST consist of a token containing an extension specification, which points to an extended set of one or more signed claims, per the type extensibility mechanism in [RFC8225], Section 8. per the guidance in that section, "ppt" is only used to enforce a mandatory extension. optional claims can be added to any PASSporT object without using "ppt", but the compact form of PASSporT MUST NOT be used when optional claims are in the PASSporT payload 🎀
multiple Identity header fields in the same SIP request are a big part of why extensions are possible 🌈 future extensions might let alternate information get signed, or let different parties provide the signatures instead of the authorities baseline STIR envisions. for example, a request might get one Identity added by an authentication service at the originating administrative domain, and then another Identity header field added by some further intermediary using a PASSporT extension. this spec doesn't define any specific purpose for multiple Identity header fields, but implementations MUST support receiving multiple header fields for future compatibility 💜
an authentication service can't assume verifiers will understand any given extension. verifiers that do support an extension may trigger appropriate application-level behavior when the extension is present, and extension authors should give application developers extension-specific guidance on this point 🧚
10. Backwards Compatibility with RFC 4474 🥺
this spec makes several big changes from the version of the Identity header field defined in [RFC4474]. but because of the problems listed in [SIP-RFC4474-CONCERNS], it's not believed that the original Identity header field ever got deployed, or even implemented in deployed products 💀
so this mechanism has no provisions for signatures generated with this spec to work with [RFC4474]-compliant implementations, and no related backwards-compatibility provisions either. hypothetically, if an [RFC4474]-compliant implementation got a message with this revised Identity header field, it would likely fail the request with a 436 response code, because the Identity-Info header field (Section 4) is missing 😭 for debugging, implementations of this spec might read a 436 with a reason phrase of "Bad Identity Info" (previously "Bad Identity-Info"; see Section 13.2) as a sign that the request failed because it hit a (hypothetical) verification service that is [RFC4474]-compliant 🔥
11. Privacy Considerations 🔒✨
Okay bestie, privacy time 🫶 The whole point of this mechanism is to give a reliable ID for whoever sent a SIP request. It's a cryptographic assurance that an authority says the originator can claim the URI in the request. That URI can contain or imply a bunch of personal info, like a human's name, their workplace or service provider, and possibly more 👀 The intrinsic privacy risks of that URI are no different from baseline SIP, though, so nothing brand new here. Per [RFC6973], implementers should make users aware of the privacy trade-off of providing secure identity 💅
The identity mechanism here is compatible with the standard SIP privacy practices in [RFC3323] 🧚 A SIP proxy server can be both a privacy service (as described in [RFC3323]) and an authentication service. A UA can put in any From header field value that the authentication service is willing to authorize, so there's no reason private SIP URIs with legit domains (like sip:anonymous@example.com) can't be signed by an authentication service. Building the Identity header field is the same for private URIs as it is for any other URI. Similar practices could support opportunistic signing of SIP requests for UA-integrated authentication services with self-signed certificates, but that's outside the scope of this spec and is left for future investigation 🔮
Now, even with anonymous SIP URIs, an authentication service must have a certificate matching the host portion of the addr-spec in the From header field value. So using domains like anonymous.invalid won't work for privacy services that also act as authentication services 🙅 The assurance you get from anonymous URIs with a valid domain portion is "this is a known user in my domain that I have authenticated, but I am keeping its identity private." 🦋
There are two things worth noting about this more anonymous form of identity 👑 First, you can wipe out any identifying info in a domain by using anonymous.invalid, but then we have to admit it's hard for a domain to be both anonymous and authenticated. The anonymous.invalid domain means no corresponding authority for that domain can exist, so authentication service functions for it are meaningless. Second, this one matters more for the threats this document mitigates [RFC7375]. None of the relevant attacks, which all rely on the attacker taking on a victim's identity or hiding their own identity behind someone else's, are enabled by an anonymous identity. So not being able to assert an authority over an anonymous domain is irrelevant to our threat model 💀
[RFC3325] defines the id priv-value token, which is specific to the P-Asserted-Identity header field 🌸 The kind of assertion the P-Asserted-Identity header field gives is very different from the Identity header field in this document. It carries extra info about the message originator that may go beyond what's in the From header field. P-Asserted-Identity holds a definitive identity for the originator that's known to a closed network of intermediaries. That network presumably uses this identity for billing or security purposes. The danger of this network-specific info leaking outside the closed network is what motivated the id priv-value token. The id priv-value token has no implications for the Identity header field, so privacy services MUST NOT remove the Identity header field when a priv-value of id appears in a Privacy header field 🫶
The full form of the PASSporT object gives the complete JSON objects used to generate the signed-identity-digest of the Identity header field value. That includes the canonicalized form of the telephone number of the call originator if the signature is over a telephone number 📞 In some contexts, local policy may require a canonicalization that differs a lot from the original From header field. Depending on those policies, the full form of PASSporT might spill info about the originating network or user that doesn't show up anywhere else in the SIP request 👀 If it were used to reflect the contents of the P-Asserted-Identity header field, for example, the object would need to be converted to the compact form when the P-Asserted-Identity header is removed, so nothing leaks outside a trust domain. In those contexts, a verifier can't rebuild the canonical form of the originator's identity, so the Identity signature validation process would fail. That's why using P-Asserted-Identity with the full form of PASSporT this way is NOT RECOMMENDED outside environments where SIP requests will never leave the trust domain 🚫
As a side note, history shows that closed networks never stay closed. Design your implementation assuming connectivity to the broader Internet 🌍💖
Finally, unlike [RFC3325], the mechanism described in this specification adds no information with privacy implications to SIP requests, apart from disclosing that an authentication service is willing to sign for an originator ✨
12. Security Considerations 🛡️💥
This document describes a mechanism that provides a signature over the Date header field of SIP requests, parts of the To and From header fields, and (when present) any media keying material in the message body 🔐 In general, the security considerations for these header fields are the same as those given in [RFC3261] for including header fields in tunneled "message/sip" MIME bodies (see Section 23 of [RFC3261] in particular). This section breaks down the individual security properties you get by including each of these header fields in the signature. Together, this set of header fields gives you what's needed to prevent impersonation 🎀 It also addresses the solution-specific attacks against in-band solutions listed in [RFC7375], Section 4.1.
12.1. Protected Request Fields 🎀
The From header field value (in ordinary operations) tells you who sent the message. For the purposes of this document, either the SIP AoR URI or an embedded telephone number gives the identity of a SIP user 🙋♀️ Note that in some deployments, the originator's identity may live in P-Asserted-Identity instead. The originator's identity is the key piece of info this mechanism secures. The rest of the signed parts of a SIP request are there to provide reference integrity and to prevent certain types of cut-and-paste attacks 💅
The Date header field value protects against cut-and-paste attacks, as described in [RFC3261], Section 23.4.2 ⏰ That spec recommends that implementations notify the user of a potential security issue if the signed Date header field value is stale by an hour or more. To prevent cut-and-paste of recently observed messages, this specification instead RECOMMENDS a much shorter interval of sixty seconds 🏃♀️ Implementations of this specification MUST NOT deem valid a request with an outdated Date header field. Also, per the behavior described in [RFC3893], Section 10, servers can keep state of recently received requests. So if an attacker replays an Identity header field within the Date interval, verifiers can catch that it's spoofed, because a message with an identical Date from the same source had recently been received 🕵️♀️
It's been observed in the wild that some networks change the Date header field value of SIP requests in transit 😤 To handle that kind of scenario, alternative behavior might be necessary. Verification services that observe a signature validation failure MAY therefore reconstruct the Date header field component of the signature from the iat carried in the full form of PASSporT. Provided the time recorded by iat falls within the local policy for freshness that would normally apply to the Date header, the verification service MAY treat the signature as valid, as long as it keeps adequate state to detect recent replays 🧠 Note that this will require authentication services in networks where these failures are observed to include the full form of the PASSporT object.
The To header field value gives the identity of the SIP user this request originally targeted 🎯 Covering the identity in the To header field with the Identity signature does two jobs. First, it prevents cut-and-paste attacks where an Identity header field from a legit request for one user gets cut and pasted into a request for a different user. Second, it preserves the starting URI scheme of the request, which helps prevent downgrade attacks against the use of SIPS 🔒 The To identity adds protection against cut-and-paste attacks beyond what the Date header field does. For example, without a signature over the To identity, an attacker who receives a call from a target could immediately cut and paste the Identity and From header field values from that INVITE into a new request to the target's voicemail service within the Date interval. The voicemail service would have no way of knowing that the Identity header field it got was originally signed for a call meant for a different number 😱 Note the caveats below in Section 12.1.1, though.
When signing a request that contains a fingerprint of keying material in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a signature over that fingerprint 🔑 This signature prevents certain classes of impersonation attacks where an attacker forwards or cuts and pastes a legit request. The target of the attack may accept the request, but the attacker still can't exchange media with the target, because they won't have a key matching the fingerprint 🙅♀️ For example, there are some baiting attacks, launched with the REFER method or through social engineering, where the attacker gets a request from the target and reoriginates it to a third party. A signature over just the From, To, and Date might not stop these, but securing a fingerprint for DTLS-SRTP could 🛑 This is a different form of impersonation than the kind commonly used for robocalling. Still, there's little point in establishing the identity of the user who originated a SIP request if that assurance isn't paired with a comparable assurance over the contents of the subsequent media communication 🎙️ This signature also reduces the potential for active eavesdropping attacks against the SIP media. In environments where DTLS-SRTP is unsupported, though, no field is signed and no protections are provided 💔
12.1.1. Protection of the To Header and Retargeting
Okay so bestie, picture this 👀. The recipient of a request might be super tempted to look at the original To header field and compare it to their own identity, just to check whether the identity info in this call got replayed. But ngl, any request can be legitimately retargeted 💅, so totally legit requests can land on a SIP endpoint whose user isn't the one named in the To header field value. 😭 That makes it really hard for any verifier to decide whether some earlier retargeting was "legitimate" 🫠. Retargeting can also get messy when identity info is sent in the backwards direction of a dialog, because the dialog identifiers might not match the credentials held by the dialog's ultimate target. If you want more on the problems of response identity, check out [SIP-RETARGET] 📚.
Any way for authentication services or verifiers to anticipate retargeting is outside the scope of this document 🙅♀️. It's probably got the same applicability to response identity that it has to requests in the backwards direction within a dialog. So no special guidance is given for implementers about the "connected party" problem (see [RFC4916]) 🌸. Authentication service behavior stays the same even if retargeting has happened for a dialog-forming request. Basically, the authentication service only gives an Identity header field for requests in the dialog when the user is authorized to assert the identity in the From header field 🎀. If they're not authorized, no Identity header field is provided. And per the threat model of [RFC7375], fixing "connected" identity doesn't really help with detecting robocalling or related impersonation attacks 📵. Not it. 💀
12.2. Unprotected Request Fields
Tea time ☕. [RFC4474] originally protected Contact, Call-ID, and CSeq. This document removes that protection 🥀. Without those values being protected, determined attackers get some chances to impersonate using cut-and-paste attacks 😬. BUT, the absence of these header field values doesn't seem to hurt the main focus of this document, which is stopping the simple, unauthorized claiming of an identity for robocalling, voicemail hacking, or swatting 🚫📞. That's the big one, and it's handled ✨.
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 field, an attacker could remove that Via header field and insert their own in a cut-and-paste attack. That would route all responses to the request to a host of the attacker's choosing 😈. However, signing the topmost Via header field doesn't stop this kind of attack either. The attacker could leave the topmost Via intact and just insert a new Via header field directly after it. Then responses get routed to the attacker's host "on their way" to the valid host, and the end result is exactly the same 🙃. It's possible an intermediary-based authentication service could guarantee that no Via hops get inserted between the sending UA and the authentication service. But it couldn't stop an attacker from adding a Via hop after the authentication service and preempting responses 🫣. Subsequent intermediaries have to be able to insert Via header fields for SIP to work properly, so this can't be prevented. So even though it's desirable, securing Via isn't possible through the sort of identity mechanism described here 💔. The best known practice for securing Via is using SIPS 🔐.
12.3. Malicious Removal of Identity Headers
Real talk, the Identity header field can't protect itself 🫠. Any attacker could strip the header field from a SIP request and then modify the request however they want. But this mechanism isn't meant to protect requests from man-in-the-middles who mess with SIP messages 🙅♀️. It's only meant to give SIP request originators a way to prove they are who they claim to be 🪪. At best, a man-in-the-middle who strips identity info could make it impossible to tell their sketchy messages apart from those sent by an authorized user 👀. Still, mounting that kind of attack takes way more effort than a trivial impersonation by just copying someone else's From header field 💪. This mechanism gives an authorized user a way to provide definitive assurance of their identity that an unauthorized user, an impersonator, can't 👑.
12.4. Securing the Connection to the Authentication Service
When there are no UA-based authentication services, the assurance this mechanism provides is strongest when a UA forms a direct connection to an intermediary-based authentication service 🔒. Ideally that connection is secured by TLS 🎀. There are two big reasons for this:
- If a user doesn't receive a certificate from the authentication service over the TLS connection that matches the expected domain (especially when the user gets a challenge through a mechanism like Digest), then a rogue server might be trying to pose as an authentication service for a domain it doesn't control 😱. It could be trying to collect shared secrets for that domain. A similar practice could be used for telephone numbers, though applying certificates for telephone numbers to TLS is left as a matter for future study 🔮.
- Without TLS, the various header field values and the body of the request won't have integrity protection when the request reaches an authentication service 🫥. So a prior legitimate or illegitimate intermediary could modify the message however they like 🙈.
Of these two concerns, the first one matters most for this mechanism's intended scope 💯. This mechanism is meant to prevent impersonation attacks, not man-in-the-middle attacks 🥰. The integrity it provides over parts of the header and body is only there to prevent replay attacks. Still, applications that rely on the presence of the Identity header field could maybe use this integrity protection for services other than replay protection 🧚.
So, direct TLS connections SHOULD be used between the UA client (UAC) and the authentication service whenever possible ✨. The opportunistic nature of this mechanism, though, makes it super hard to constrain UAC behavior 😩. Plus, some deployment architectures just can't make a direct connection work, and the UAC can't act as an authentication service itself 🏚️. So when a direct connection and TLS aren't possible, a UAC should use the SIPS mechanism, Digest "auth-int" for body integrity, or both when it can 🔐. Of course, the authentication service has the final say on whether to add an Identity header field to a request 👑. Domain policy has to identify the cases where the UAC's security association with the authentication service is too weak 🚩.
12.5. Authorization and Transitional Strategies
Ultimately, the worth of an assurance from an Identity header field is only as strong as the security practices of the authentication service that issued it 💅. Relying on an Identity header field generated by a remote administrative domain assumes that the issuing domain uses recommended administrative practices to authenticate its users 📋. But some authentication services might run policies that effectively make users unaccountable, like ones that accept unauthenticated registrations from anyone 🫠. The value of an Identity header field from those services is questionable 🤨. There's no magic way for a verifier to tell "good" signers from "bad" ones just by inspecting a SIP request ❌. Still, further work on authorization practices is expected to be built on top of this identity solution 🏗️. Without an identity solution like this, lots of promising authorization policy approaches are impossible 😭. That said, it is RECOMMENDED that authentication services based on proxy servers employ strong authentication practices 🫶.
You can't expect every SIP entity to support the Identity header field overnight 🌙. That leaves the verifier in a tricky spot 😵💫. When it gets a request from a given SIP user, how can it know whether the originator's domain supports Identity? Until Identity is supported everywhere, some transitional strategies are needed 🧩.
- A verifier could remember when it receives a request from a domain or telephone number that uses Identity. Then, in the future, it can view messages from that source that arrive without an Identity header field with skepticism 🧐.
- A verifier could consult some sort of directory that shows whether a given caller should have a signed identity. There are a number of potential ways this could be implemented, and it's 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 SIP 📈. That's the only way to guarantee verifiers can always expect this protection 🥹.
Finally, the presence or absence of Identity header fields can't be the only factor in an authorization decision ⚠️. Permissions might be granted to a message based on the specific verified Identity, or on any other aspect of a SIP request 🎯. Authorization policies are outside the scope of this specification. But this specification does advise any future authorization work not to assume that messages with valid Identity header fields are always good 🚫. Not every valid Identity is a good vibe 💀.
12.6. Display-Names and Identity
As a matter of interface design, SIP UAs might display the display-name portion of a caller's From header field as the caller's identity 🪞. There's a big precedent for this in email user interfaces 📧. Securing the display-name part of the From header field value is outside the scope of this document 🙈. It may be the subject of future work, like through the "ppt" name mechanism 🔮.
Without signing the display-name, authentication services might check and validate it, and compare it to a list of acceptable display-names the originator is allowed to use 📝. If the display-name doesn't meet policy constraints, the authentication service could return a 403 response code 🚫. In that case, the reason phrase should indicate the nature of the problem, for example, "Inappropriate Display Name" 💅. However, the display-name isn't always present. In lots of environments, the operational procedures needed for display-name validation may not exist at all 🤷♀️. So no normative guidance is given here 🫧.
13. IANA Considerations
IANA has completed a number of actions described in this document 🎀. The main one: the previous references to [RFC4474] in the "Session Initiation Protocol (SIP) Parameters" registry have been updated to point to this document, unless specified otherwise below 📌. Iconic behavior from IANA 👑.
13.1. SIP Header Fields ✨
Okay so, the Identity-Info header in the SIP "Header Fields" registry is now marked as deprecated by this document 🥀 bye bye, Identity-Info, we love you but you're retired now 💜
Also, Identity-Info reserved the compact form n back when it got registered. That compact form has been yanked from the registry 🙈 The Identity header, though, keeps the compact form y that [RFC4474] reserved. She's still standing ✨
13.2. SIP Response Codes 🎀
Two reason phrases got a glow-up 💅
436 "Bad Identity-Info"is now436 "Bad Identity Info"in the SIP "Response Codes" registry (no more hyphen, very clean).437 "Unsupported Certificate"is now437 "Unsupported Credential"🔥
13.3. Identity-Info Parameters 🧚
IANA has a registry for Identity-Info parameters, and per this spec it got renamed to "Identity Parameters" 🍓 New name, same iconic energy.
This spec adds one brand-new value to that registry: info, which is defined in Section 7.3 🌸
13.4. Identity-Info Algorithm Parameter Values 💀
IANA used to manage an "Identity-Info Algorithm Parameter Values" registry, and now this spec has deprecated it and closed it up 🫶 The reason is kinda cute: the algorithms for signing PASSporTs live in [RFC8225] instead of here, so the Identity header doesn't need its own algorithm parameter registry anymore. Everything has its own home now 🏡
14. Changes from RFC 4474 🦋
Okay bestie, here are the big changes from the original RFC 4474 (the main character moments, if you will 👑):
- The credential mechanism got generalized. Credential enrollment, acquisition, and trust are now outside the scope of this document 🌈
- This document shrinks the scope of the Identity signature so it no longer covers
CSeq,Call-ID,Contact, or the message body. Signing key fingerprints in SDP is now included, though 🔐 - The
Identity-Infoheader field got deprecated, and its components moved into parameters of theIdentityheader field. (That also obsoletes the previous version of the header field, so it's a full reinvention 💖) - The
Identityheader field can now show up multiple times in one request ✨ - The old signed-identity-digest format got replaced with PASSporT. The signing algorithms now live in their own separate spec 🧚
- Status code descriptions got revised 💅
15. References 📚
Here's the reading list, sorted into the "must-read" and "good-to-know" piles 🫶
15.1. Normative References
[E.164] International Telecommunication Union, "The international
public telecommunication numbering plan",
ITU-T Recommendation E.164, November 2010,
<https://www.itu.int/rec/T-REC-E.164/en>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, June 2002,
<https://www.rfc-editor.org/info/rfc3263>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004,
<https://www.rfc-editor.org/info/rfc3966>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, DOI 10.17487/RFC5922, June 2010,
<https://www.rfc-editor.org/info/rfc5922>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.15.2. Informative References
[CIDER] Kaplan, H., "A proposal for Caller Identity in a DNS-based
Entrusted Registry (CIDER)", Work in Progress,
draft-kaplan-stir-cider-00, July 2013.
[IRI-COMPARISON]
Masinter, L. and M. Duerst, "Comparison, Equivalence and
Canonicalization of Internationalized Resource
Identifiers", Work in Progress, draft-ietf-iri-
comparison-02, October 2012.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, DOI 10.17487/RFC2585, May 1999,
<https://www.rfc-editor.org/info/rfc2585>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323,
DOI 10.17487/RFC3323, November 2002,
<https://www.rfc-editor.org/info/rfc3323>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/info/rfc3325>.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
DOI 10.17487/RFC3893, September 2004,
<https://www.rfc-editor.org/info/rfc3893>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>.
[RFC4501] Josefsson, S., "Domain Name System Uniform Resource
Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006,
<https://www.rfc-editor.org/info/rfc4501>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916,
June 2007, <https://www.rfc-editor.org/info/rfc4916>.
[RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B.
Campen, "Addressing an Amplification Vulnerability in
Session Initiation Protocol (SIP) Forking Proxies",
RFC 5393, DOI 10.17487/RFC5393, December 2008,
<https://www.rfc-editor.org/info/rfc5393>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763,
May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model",
RFC 7375, DOI 10.17487/RFC7375, October 2014,
<https://www.rfc-editor.org/info/rfc7375>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515,
May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
[SIP-RETARGET]
Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements", Work in Progress,
draft-peterson-sipping-retarget-00, February 2005.
[SIP-RFC4474-CONCERNS]
Rosenberg, J., "Concerns around the Applicability of
RFC 4474", Work in Progress, draft-rosenberg-sip-rfc4474-
concerns-00, February 2008.
[TS-3GPP.23.228]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.228 7.7.0, March 2007,
<http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.Acknowledgments 🫶
The authors want to give a huge shoutout to Adam Roach, Jim Schaad, Ning Zhang, Syed Ali, Olle Jacobson, Dave Frankel, Robert Sparks, Dave Crocker, Stephen Kent, Brian Rosen, Alex Bobotek, Paul Kyzivat, Jonathan Lennox, Richard Shockey, Martin Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, Pierce Gorman, David Schwartz, Eric Burger, Alan Ford, Christer Holmberg, Philippe Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for their comments 💜 literally the whole squad.
Authors' Addresses 🎀
Jon Peterson
Neustar, Inc.
1800 Sutter St. Suite 570
Concord, CA 94520
United States of America
Email: jon.peterson@neustar.biz
Cullen Jennings
Cisco
400 3rd Avenue SW, Suite 350
Calgary, AB T2P 4H2
Canada
Email: fluffy@cisco.com
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
United States of America
Email: ekr@rtfm.com
Chris Wendt
Comcast
One Comcast Center
Philadelphia, PA 19103
United States of America
Email: chris-ietf@chriswendt.net📦 where this page comes from
- ietf: rfc8224 2018-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms