RFC 3893

RFC 3893: Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format 🎀

Okay bestie, this is RFC 3893 from the Network Working Group 🦋 It was written by J. Peterson at NeuStar, it's a Standards Track document, and it's dated September 2004. So this is an official spec, not just vibes. The title block doesn't list any RFCs it obsoletes or updates, so there's no drama there 💅

Status of This Memo ✨

This document is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements 💖 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the memo can be distributed with no limits at all 🌸

Copyright Notice 🌈

Copyright (C) The Internet Society (2004).

Abstract 🦋

So RFC 3261 brought in the idea of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response, so the headers get reference integrity 🔒 This document goes further and gives a more specific way to get integrity and authentication from an 'authenticated identity body', which is a digitally-signed SIP message or message fragment ✨ It also defines a standard format for these bodies, called Authenticated Identity Bodies (AIBs), and it covers some things recipients of SIP messages with these bodies should think about when processing them 🧚

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
    1.1.  Requirements Notation. . . . . . . . . . . . . . . . . .  3
2.  AIB Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Example of a Request with AIB  . . . . . . . . . . . . . . . .  5
4.  AIBs for Identifying Third-Parties . . . . . . . . . . . . . .  6
5.  Identity in non-INVITE Requests  . . . . . . . . . . . . . . .  7
6.  Identity in Responses  . . . . . . . . . . . . . . . . . . . .  7
7.  Receiving an AIB . . . . . . . . . . . . . . . . . . . . . . .  7
8.  Encryption of Identity . . . . . . . . . . . . . . . . . . . .  8
9.  Example of Encryption  . . . . . . . . . . . . . . . . . . . .  8
10. Security Considerations  . . . . . . . . . . . . . . . . . . .  9
11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
    12.1. Normative References . . . . . . . . . . . . . . . . . . 11
    12.2. Informative References . . . . . . . . . . . . . . . . . 11
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
14. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

1. Introduction 💅

Okay so, Section 23.4 of RFC 3261 [1] describes an integrity mechanism that works by signing tunneled 'message/sip' MIME bodies inside SIP requests 🔐 The point is to copy the headers of a SIP request into a body carried in that same request, so you can put a digital signature over those headers. And the signature on that body also gives you authentication. It's giving security 😭

The big thing driving the tunneled 'message/sip' mechanism is that you need a cryptographically verifiable identity inside a SIP request 🎀 The baseline SIP protocol lets a user agent show its user's identity in a bunch of different headers, but the main one is the From header. The From header has a URI (like 'sip:alice@example.com') and an optional display-name (like "Alice") that says who started the request 💖 And a user can have lots of identities for different contexts, which is very main character of them 👑

Usually that URI is an address-of-record you can dereference to contact whoever sent the request. Like, it's usually the same address-of-record a user registers their devices under so they can get incoming requests 📞 The administrator of the SIP service in the domain named by the host part of that address-of-record is the one who assigns and maintains it. BUT the From field can basically be set to anything by whoever is using the user agent, so the From header doesn't give any built-in proof that the sender is actually allowed to claim that identity 🙈 Even so, lots of SIP user agents will happily show whatever is in the From field as the caller's identity (kinda like caller ID), the same way email programs show the From field as the sender 📧

To give the recipient more confidence about who the sender is, you can put a cryptographic signature over the headers of the SIP request. That lets the signer assert an identity that can be verified ✨ The catch is that signing just the From header isn't enough, because it could be cut and pasted into a replay or forwarding attack. So you need more headers to tie the signature to the request 🦋 RFC 3261 recommends copying all of the headers from the request into a signed MIME body. BUT SIP messages can be huge, and a lot of those headers don't matter for figuring out who sent it or proving reference integrity with the request. On top of that, some headers can change in transit for totally valid reasons 🌸 So this big tunneled 'message/sip' body will almost always differ from the headers in the request when the UAS receives it, and the UAS has the hard job of figuring out which header changes were legit and which were security violations 😬 That's why you want a happy medium: sign just enough headers to figure out who the sender is and match it to the request 🫶 'message/sipfrag' [4] gives a way to include a subset of SIP headers in a MIME body, and the Authenticated Identity Body (AIB) format in Section 2 is based on 'message/sipfrag' 🧚

For end-to-end privacy reasons, you may also want to encrypt AIBs, and the procedures for that are in Section 8 🔐

This document proposes that the AIB format should be used instead of the existing tunneled 'message/sip' mechanism from RFC 3261, section 23.4, to provide the identity of the caller. If you need integrity over other, unrelated headers, then the 'message/sip' mechanism should be used instead 🍓

1.1. Requirements Notation 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].

2. AIB Format 💖

So, to share authenticated identity between parties in the network, this section defines a special MIME body format called the Authenticated Identity Body (AIB) format 🎀 AIBs let a party in a SIP transaction cryptographically sign the headers that assert the identity of the message's originator, and they also carry some other headers needed for reference integrity 🔏

An AIB is a MIME body of type 'message/sipfrag'. For more on building sipfrags, including examples, see [4]. This MIME body MUST have a Content-Disposition [3] disposition-type of 'aib', which is a new value defined in this document just for authenticated identity bodies 🦋 The Content-Disposition header SHOULD also include a 'handling' parameter that says this MIME body is optional. That way, if the user agent server doesn't support this mechanism, it can still try to process the request 🌈

AIBs using the 'message/sipfrag' MIME type MUST contain the following headers when providing identity for an INVITE request: From, Date, Call-ID, and Contact. They SHOULD also contain the To and CSeq header. The security properties of these headers, and the situations where they should be used, are covered in Section 10 🧚 AIBs MAY contain any other headers that help uniquely identify the transaction or provide related reference integrity ✨ Here's an example of the AIB format for an INVITE:

Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional

From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.net>
Contact: <sip:alice@pc33.example.com>
Date: Thu, 21 Feb 2002 13:02:03 GMT
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE

Unsigned AIBs MUST be treated by any recipient according to the rules in Section 7 for AIBs that don't validate 🙅‍♀️ After the AIB has been signed, it SHOULD be added to any existing MIME bodies in the request (like SDP). If needed, you do that by changing the outermost MIME body to a 'multipart/mixed' format 💅

3. Example of a Request with AIB 🎀

Here's a full SIP INVITE request with an AIB in it, so you can see how it all fits together 🦋

INVITE sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.net>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.example.com>
Content-Type: multipart/mixed; boundary=unique-boundary-1

--unique-boundary-1

Content-Type: application/sdp
Content-Length: 147

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

--unique-boundary-1
Content-Type: multipart/signed;
  protocol="application/pkcs7-signature";
  micalg=sha1; boundary=boundary42
Content-Length: 608

--boundary42
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional

From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.net>
Contact: <sip:alice@pc33.example.com>
Date: Thu, 21 Feb 2002 13:02:03 GMT
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE

--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
   handling=required

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756

--boundary42--

--unique-boundary-1--

4. AIBs for Identifying Third-Parties ✨

okay so this section is about the special cases where a few SIP messages get swapped with a third party before an INVITE goes out, and the third party's identity needs to ride along in that later INVITE 🧚. how you address identity in those situations is outside the scope of this document, so we're not going there today 🙈. at a high level, a third party's identity might be carried in a supplemental AIB 💜. and a supplemental AIB showing up doesn't stop a 'regular' AIB (the kind specified in this document) from showing up too 🫶.

example cases where supplemental AIBs might pop up:

The use of the REFER [5] method, for example, has a requirement for the recipient of an INVITE to ascertain the identity of the referrer who caused the INVITE to be sent.

Third-party call control (3PCC [6]) has an even more complicated identity problem. A central controller INVITEs one party, gathers identity information (and session context) from that party, and then uses this information to INVITE another party. Ideally, the controller would also have a way to share a cryptographic identity signature given by the first party INVITEd by the controller to the second party invited by the controller.

okay the tea 🫖💅: in both of these cases, the Call-ID and CSeq of the original request (the 3PCC INVITE or REFER) won't match the ones in the later INVITE, and the To or From won't match either 😭. since the Call-ID and CSeq can't be used to guarantee reference integrity in the REFER case or the 3PCC case, it's way harder to link an AIB back to the subsequent INVITE request 💀.

so some other headers might be used to provide reference integrity between the headers in a supplemental AIB and the headers of a 3PCC or REFER-generated INVITE. but that usage is outside the scope of this document 🙈. for AIBs to work in these third-party contexts, more specification work is needed to figure out which additional headers (if any) need to be in an AIB in a specific third-party case, and how to tell the primary AIB in a message apart from a third-party AIB 🌈.

5. Identity in non-INVITE Requests 🎀

the rules for filling in an AIB in requests within a dialog basically mirror the INVITE rules: From, Call-ID, Date, and Contact header fields are REQUIRED 💖.

some non-INVITE requests, though, can have different identity requirements 👀. new SIP methods or extensions that leverage AIB security MUST identify any special identity requirements in the Security Considerations of their specification 🔥. no skipping that part, bestie 🫶.

6. Identity in Responses 🦋

a lot of the practices from the earlier sections can be applied to responses too ✨. just note that a brand new set of headers has to be generated to fill the AIB in a response 🧚. the From header field of the AIB in the response to an INVITE MUST correspond to the address-of-record of the responder, NOT to the From header field received in the request 💅. the To header field of the request MUST NOT be included 🙅. a new Date header field and Contact header field should be generated for the AIB in a response 🌸. the Call-ID and CSeq should, however, be copied from the request 💜.

usually the To header field of the request will match the responder's address-of-record 🍓. in some architectures where re-targeting is used, though, that might not be the case 🌈. some recipients of response AIBs may consider it a cause for security concern if the To header field of the request is not the same as the address-of-record in the From header field of the AIB in a response 😭.

7. Receiving an AIB 💖

when a user agent gets a request with an AIB in it, it MUST verify the signature, including validating the certificate of the signer 🔐. then it MUST compare the identity of the signer (the subjectAltName) with, in the INVITE case, the domain portion of the URI in the From header field of the request (for non-INVITE requests, other headers MAY be subject to this comparison) 👀. the two should correspond exactly. if they don't, the user agent MUST report this condition to its user before proceeding 🚨.

user agents MAY tell apart plausibly minor variations (like 'example.com' vs. 'sip.example.com') from major variations (like 'example.com' vs. 'example.org') when reporting these discrepancies 🧐. that way the user gets some idea of how to handle it 💅. analysis and comparison of the Date, Call-ID, and Contact header fields as described in Section 10 MUST also be performed 🌟. any discrepancies or violations MUST be reported to the user 📣.

when the originating user agent of a request gets a response containing an AIB, it SHOULD compare the identity in the From header field of the AIB in the response with the original value of the To header field in the request 🦋. if these represent different identities, the user agent SHOULD render the identity in the AIB of the response to its user ✨. but a discrepancy here isn't necessarily a security breach, ngl 🙈. normal re-targeting may have just sent the request to a different final destination 🧚. so implementors may decide it's unnecessary to alert the user of a security violation in this case 🌸.

8. Encryption of Identity 🔒

a lot of SIP entities that support S/MIME signatures also support S/MIME encryption, as described in RFC 3261, Section 23.4.3 💜.

encrypting an AIB means only the holder of a specific key can decrypt the body 🗝️. but that one key could be spread across a whole network of hosts that live under common policies 🏰. so the security of the AIB depends on that key being distributed securely 😬. for some networks (federations of trusted hosts under a common policy), wide distribution of a decryption key could be appropriate 🌈. some telephone networks, for example, might need this model 📞.

when an AIB is encrypted, it SHOULD be encrypted before it's signed 🫶. implementations MUST still accept AIBs that have been signed and then encrypted 💅.

9. Example of Encryption 🎀

here's an example of an encrypted and signed AIB (without any of the preceding SIP headers) ✨. in a version of this body sent over the wire, the text wrapped in asterisks would be ciphertext 🔐.

Content-Type: multipart/signed;
  protocol="application/pkcs7-signature";
  micalg=sha1; boundary=boundary42
Content-Length: 568
Content-Disposition: aib; handling=optional

--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
  name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
  handling=required
Content-Length: 231

***********************************************************
* Content-Type: message/sipfrag                           *
* Content-Disposition: aib; handling=optional             *
*                                                         *
* From: sip:alice@example.com                             *
* Call-ID: a84b4c76e66710                                 *
* Contact: sip:alice@device21.example.com                 *
* Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
***********************************************************

--boundary42

Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
   handling=required

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756

--boundary42--

10. Security Considerations 🔐

okay bestie, this is the serious section, so let's get into it 🫶 The whole purpose of an AIB is to give the sender of a SIP message an identity. That identity lives in the From header field of the AIB. Other headers come along for the ride too, but only to help catch replays and cut-and-paste attacks that someone might use to impersonate the caller 🕵️‍♀️. The contents of the From header field of a valid AIB are fine to display as a "Caller ID" for whoever sent the SIP message 📞✨.

This document mandates the inclusion of the Contact, Date, Call-ID, and From header fields within an AIB, and recommends the inclusion of CSeq and To header fields, when "message/sipfrag" is used to represent the identity of a request's sender. If these headers get left out, some important security properties of AIB are lost 😭. In general, the considerations for including various headers in an AIB are the same as the ones RFC 3261 gives for including headers in tunneled "message/sip" MIME bodies (see Section 23 in particular) 🧠.

The From header field says who the sender of the message is. If you left that out, the creator of the AIB would basically not be asserting an identity at all 💀. The Date and Contact headers give you reference integrity and replay protection, as described in RFC 3261, Section 23.4.2 🔁. Implementations of this specification MUST follow the rules for accepting the Date header field in tunneled "message/sip" requests described in RFC 3261, Section 23.4.2. This makes sure outdated AIBs can't get replayed 🙅‍♀️ (the suggested interval is that the Date header must indicate a time within 3600 seconds of the receipt of a message). Implementations MUST also record Call-IDs received in AIBs, and MUST remember those Call-IDs for at least the duration of a single Date interval (i.e., 3600 seconds) 📝. So if an AIB gets replayed inside the Date interval, receivers will spot it as invalid because of a duplicate Call-ID 🚨. And if it gets replayed after the Date interval, receivers will spot it as invalid because the Date is stale 🥀.

Okay, this next part is the big one 👀. The Contact header field is there to tie the AIB to the particular device instance that generated the request 📱. Say an active attacker intercepts a request containing an AIB and cut-and-pastes that AIB into their own request, reusing the From, Contact, Date, and Call-ID fields that appear in the AIB. They still would not be eligible to receive SIP requests from the called user agent, because those requests get routed to the URI identified in the Contact header field 🙅‍♀️💅.

The To and CSeq header fields provide properties that are generally useful, but not for every possible application of AIBs 🤏. If a new AIB is issued every time a new SIP transaction starts in a dialog, the CSeq header field gives you a really valuable property: replay protection for that particular transaction 🎯. But if one AIB is used for the whole dialog, the later transactions in the dialog would reuse the same AIB that showed up in the INVITE transaction. Using a single AIB for an entire dialog reduces the load on the generator of the AIB 🫠. The To header field usually designates the original URI the caller meant to reach, so it may differ from the Request-URI if re-targeting happens somewhere in the network 🧭. That's why including the To header field in the AIB helps catch cut-and-paste attacks where an AIB sent to one destination gets reused to impersonate the sender toward a different destination 🚫. Still, including the To header field probably wouldn't make sense for many third-party AIB cases (as described in Section 4), and it isn't necessary for responses either 🤷‍♀️.

---

11. IANA Considerations 📋

This document defines a new MIME Content-Disposition disposition-type value of aib 🎀. This value is reserved for MIME bodies that contain an authenticated identity, as described in section Section 2 🔐.

12. References 📚

12.1. Normative References

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

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

[3] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.

[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.

12.2. Informative References

[5] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.

[6] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.

13. Acknowledgements 🫶

The author would like to thank Robert Sparks, Jonathan Rosenberg, Mary Watson, and Eric Rescorla for their comments 💖. Rohan Mahy also provided some valuable guidance 🌸.

14. Author's Address 💌

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

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

15. Full Copyright Statement ©️

Copyright (C) The Internet Society (2004).

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

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ⚖️

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

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

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

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 💕.