SIP WG H. Kaplan Internet Draft Acme Packet Intended status: Standards Track Updates: 3261 Expires: September 4, 2009 March 4, 2009 A Secure Call-ID for the Session Initiation Protocol (SIP) draft-kaplan-sip-secure-call-id-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 4, 2009. Copyright and License Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Many SIP devices generate Call-ID values which contain their system IP Address, due to examples and normative text in RFC 3261. This Kaplan Expires September 1, 2009 [Page 1] SIP Secure Call-ID March 2009 has led to some middleboxes, such as SBC's, to change the Call-ID for security reasons. This draft updates RFC 3261 to require SIP User Agents to generate benign Call-IDs, in such a manner that they can be detected as secure and not need to be changed. Table of Contents 1. Introduction................................................2 2. Applicability...............................................3 3. Overview of the Change......................................3 3.1. User Agent Behavior.....................................4 3.2. Proxy Behavior..........................................4 3.3. B2BUA Behavior..........................................4 4. Call-ID ABNF Rules..........................................4 5. Security Considerations.....................................5 6. IANA Considerations.........................................5 7. Acknowledgments.............................................5 8. References..................................................5 8.1. Normative References....................................5 8.2. Informative References..................................6 Author's Address..................................................6 Acknowledgment....................................................6 1. Introduction Based on [RFC 3261] normative language and ABNF rules, the Call-ID header value is not required to contain a host portion; however, in practice it frequently does. The reason for this dates back to [RFC 2543], which required it, and also to the examples and language used in RFC 3261. For example, section 4 of RFC 3261 states: Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. Furthermore, even though it recommends cryptographically random identifiers, section 8.1.1.4 of RFC 3261 states "Implementations MAY use the form 'localid@host'" for Call-ID values. All examples shown in RFC 3261, and all examples in virtually every RFC which extend or apply to SIP, continue that unfortunate heritage by using Call-ID's containing IP Addresses. Due to this common usage, SIP security devices such as Session Border Controllers (SBCs) frequently replace the Call-ID values. The rationale for such replacement is simple: it reveals IP Addresses or FQDN's of potentially sensitive machines. Kaplan Expires - September 2009 [Page 2] SIP Secure Call-ID March 2009 The problem introduced from changing Call-ID values is not within the dialog created by them, since Call-ID changing middleboxes are dialog-stateful B2BUA's typically anyway, and change the Call-ID values in each direction to match what the UA expects. The problem is when out-of-dialog messages make references to Call-ID values. The following are the known list of currently defined uses which reference a Call-ID value: o In-Reply-To [RFC3261] o Replaces [Replaces] o Join [Join] o Target-Dialog [Target-Dialog] o Event Package for INVITE-Initiated Dialog [dialog-events] o Event Package for Conference State [RFC4575] o Event Package for Key Press Stimulus [KPML] o Event Package for Voice Quality Reporting [rtcp-summary] This document proposes an update to RFC 3261, to specify a mandatory requirement to generate Call-ID values which do not contain IP Addresses, and to redefine the Call-ID value ABNF rules to indicate such. 2. Applicability This draft applies to RFC 3261 and any extension which relies on Call-ID values. 3. Overview of the Change The generation of the Call-ID value is detailed in RFC 3261. This draft replaces the sentence in section 8.1.1.4 of RFC 3261 which says: Implementations MAY use the form "localid@host". With the new text: Implementations MUST NOT use the form "localid@host" when generating Call-ID values. The UA's Hostname or IP Address MUST NOT be contained in the Call-ID value in any form, and MAY only be used as an input to a random value generator if and only if the IP Address or Hostname cannot be extracted/surmised from the final Call-ID value. Using the IP Address or Hostname in the Call-ID value leads to security concerns which may cause security devices along the SIP path to change the value, which may affect certain applications of SIP. [NOTE: do we need to replace all examples, and/or section 4's sentence as well?] Kaplan Expires - September 2009 [Page 3] SIP Secure Call-ID March 2009 3.1. User Agent Behavior User Agents complying with this document MUST follow the updated text above in section 3.0, when generating new Call-ID values. If they receive a Call-ID value in a new request which does not follow this document's new rules, they MUST continue to accept them and operate following RFC 3261. This document only updates generation policies, not the rules for receiving Call-ID values and using them. 3.2. Proxy Behavior SIP Proxies MUST continue to accept legacy RFC 3261 Call-ID values, as well as the ones in this document, as opaque strings. 3.3. B2BUA Behavior It is RECOMMENDED that SIP B2BUA's not change Call-ID values for requests they generate as a UAC, from those received as a UAS. For example, changing Call-ID values in order to match requests in valid spiral scenarios can be avoided by using Record-Route headers appropriately. In some circumstances not changing Call-ID's is potentially impossible, however changing them for security reasons should no longer be required if the requirements of this document are met. Security devices SHOULD automatically detect if the Call- ID value is of this form, and be able to avoid changing it in such cases. 4. Call-ID ABNF Rules In RFC 3261, the Call-ID value is defined by the "callid" ABNF element, which is re-used by the In-Reply-To header, the Replaces header in [RFC 3891], and elsewhere. The ABNF rules for callid in RFC 3261 are: callid = word [ "@" word ] Kaplan Expires - September 2009 [Page 4] SIP Secure Call-ID March 2009 This document updates RFC 3261 to use the following ABNF rule for callid instead: callid = word Note that the character '@' is not a legal token in the "word" ABNF type, and is typically a separator token. Therefore, it is easy to discern when a Call-ID is of the old format. Security devices should still verify a hostname or IP-Address is not in the string, however. [OPEN ISSUE: should we make this a fixed format, defined randomization mechanism to avoid detecting the vendor type from the Call-ID format?] 5. Security Considerations There are no security issues with using a random value for the Call- ID, without appending the hostname or IP Address to it. Adding an IP Address (which is the most common practice) does not actually increase the randomness by much, and in fact since many User Agent's are in private address spaces behind NATs and thus have the same IP Address, it does not create uniqueness either. Implementations SHOULD use cryptographically random values, with at least 128 bits of randomness. From a security perspective, since the To and From tag values are also used for dialog matching, any reduction in randomness created by not adding an IP Address portion to the Call- ID would be trivial. 6. IANA Considerations This document asks nothing of IANA. [right?] 7. Acknowledgments Thanks to Bob Penfield for his comments. The list of current uses which need matching was taken from [draft-transparent-b2bua]. 8. References 8.1. Normative References [RFC3261] 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. Kaplan Expires - September 2009 [Page 5] SIP Secure Call-ID March 2009 8.2. Informative References [RFC2543] Rosenberg, J., Schulzrinne, H., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002 [Replaces] Elwell, J., "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [Join] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004. [Target-Dialog] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006. [dialog-events] Elwell, J., "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Orit, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [KPML] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [rtcp-summary] Pendleton, A., Clark, A., Johnston, A., Sinnreich, H., "Session Initiation Protocol Package for Voice Quality Reporting Event", draft-ietf-sipping-rtcp-summary-05, October, 2008. Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan Expires - September 2009 [Page 6]