SIPPING Working Group James Polk Internet-Draft Cisco Systems Expires: Jan 11th, 2006 July 11th, 2005 Requirements for Assured End-to-End Signaling Security within the Session Initiation Protocol draft-polk-sipping-e2e-sec-assurance-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/ietf/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 January 11th, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Session Initiation Protocol (SIP) has existing mechanisms for securing its signaling messages. SIP has several transport layers it works across: TCP, UDP, SCTP, and TLS over TCP. There currently is no mechanism to ensure that if TLS over TCP is chosen by the originating UAC, the messaging will remain encrypted on a hop-by-hop basis to the destination UAS. This document discusses this scenario, providing the requirements for such to exist, and offering pieces of a possible solution for this set of requirements. Polk Expires January 11, 2006 [Page 1] Internet-Draft SIP E2E Assured Signaling Security Jan 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions used in this document . . . . . . . . . . . . 3 2. Rationale for E2E Signaling Security . . . . . . . . . . . . 4 3. Requirements for E2E Security in Signaling . . . . . . . . . 4 4. High Level Offering at a Solution . . . . . . . . . . . . . . 5 4.1 Step 1 to High Level Offering . . . . . . . . . . . . . . 5 4.2 Step 2 to High Level Offering . . . . . . . . . . . . . . 6 4.3 Rejection Response from Intermediary . . . . . . . . . . 7 5. Diagrams for Discussion . . . . . . . . . . . . . . . . . . . 7 5.1 Diagram for Discussion Involving 3 Domains . . . . . . . 7 5.2 Diagram for Discussion Involving >3 Domains . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1 Normative References . . . . . . . . . . . . . . . . . . 9 8.2 Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 1. Introduction The Session Initiation Protocol (SIP) has many mechanisms for securing its signaling messages. SIP also has several transport layers it works across: TCP, UDP, SCTP, and TLS over TCP. According to RFC 3261 [RFC3261], these transport layers can change per SIP element hop through an infrastructure. Most of the time, this is a valuable capability, as SIP elements would know best (or at least better) which transport layer is more appropriate given the level of service that element wants or needs to provide than the UAC would. However, there can be cases in which a user agent wants to ensure its messages are transmitted with end-to-end security even if they require a hop-by-hop nature for message routing and other services to be offered by the underlying infrastructure in place. Currently this is not possible within SIP. SIP does have the ability to encrypt message bodies using S/MIME, but this does not address encrypting message headers from source to destination. SIP necessitates hop-by-hop view and modifications to certain headers to succeed. In this hop-by-hop nature of SIP, a UAC can have a false sense of security if it originates a transaction using TLS (or IPsec for that matter) and the first hop Proxy (or any SIP intermediary along the path) changes the transport layer from TLS to merely UDP, TCP or SCTP. SIP intermediaries have no means to inform the UAC of this change even if one wanted to. At the same time, if the last hop proxy/intermediary changes transport layers to TLS - whether the UAC initiated TLS or not - the Polk Expires January 11, 2006 [Page 2] Internet-Draft SIP E2E Assured Signaling Security Jan 2006 UAS implicitly believes the entire messaging path was secure - when in fact the only known hop that was secure was the last hop towards the UAS. This document should not address cases in which the UAC did not transmit over TLS initially, even if as the results of a 407 (Proxy Authentication Required) challenge adjusting the transport layer to TLS from one of the other offerings; as that challenge is intended to provide integrity protection of the authorization header to that specific Proxy, and not beyond. This should only apply to SIP messages from UACs that initiate TLS by the user's choice/ configuration for that flow of messages. This document cannot account for SIP elements that wish to lie about the security status of a message. That said, this document can provide the necessary indications for an agreement to exist between two or more entities that the transit element or receiver did indeed comply with the agreement for securing the signaling when the message was processed. This document discusses the requirements for such a security assurance to the user agent client (UAC) of a SIP message flow that its messages remained encrypted on a hop-by-hop basis to the destination user agent server (UAS). Although this document frequently discusses securing SIP signaling messages as using TLS (because RFC3261 made its implementation mandatory for SIP), IPsec is another optional means of securing SIP messaging hop-by-hop. To keep from repeating the two options over and over again, for the most part, TLS will be written from now on - even though either is functionally the same in this document's context. [RFC3261] provides the means for hop-by-hop encryption, but also the ability to change the transport layers per hop. There are strong hints at maintaining TLS (a SIPS URI) if it is received along a message path. This document wants to make sure that is more robust. [RFC3329] provided the agreement of security only between the UAC and its first hop proxy. [RFC3840] provides a means for a UAC to convey its preference for message handling, but did not cover other than to state the SIPS URI should be used if the UAC does not want caller preferences to be viewed by any element other than the SIP Server. This effort does (pretty much) that, and it should be discussed as to whether this is an extension of the caller prefs efforts, or is independent of it. 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL Polk Expires January 11, 2006 [Page 3] Internet-Draft SIP E2E Assured Signaling Security Jan 2006 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Rationale for E2E Signaling Security User's (through their user agents) should not implicitly trust that just because the first hop was secured using TLS (or IPsec), the message remained secure from unwanted observation from that SIP hop element to the destination SIP element. Nothing written here can or should prevent jurisdictions from viewing what the local law allows them to view within the messages, but this document can take the assurance a user has for secure communications one step further towards this theme: "If I encrypted a SIP message, I want to know if it remained encrypted in transit (between SIP elements) all the way to who I wanted to contact with that message. If it did not, I want to know it did not." If, by chance, the first and last hops a message took were encrypted along its path, there is no means to know if a message was in cleartext in between those two SIP intermediaries. 3. Requirements for E2E Security in Signaling Here is a set of requirements for consideration to achieve the goal of informing the UAC that a message sent by it was processed successfully by a SIP intermediary along the SIP path to the destination UAS and the transport layer was changed from TLS to something else not secure: Req#1 - a user agent client that sets the transport layer of a SIP message to TLS over TCP MUST be assured that message arrived at the destination user agent server using TLS over TCP Req#2 - there MUST be a means within a SIP message to indicate "TLS over TCP is mandatory" in the processing of the message towards the next SIP element Req#3 - this indication that "TLS over TCP is mandatory" within a SIP message MUST be readable, MAY be added, but MUST NOT be modified in message processing by SIP intermediaries Req#4 - whenever this "TLS over TCP is mandatory" requirement in a SIP message cannot be met, a rejection indication MUST be sent conveying this rejection. The rejection indication SHOULD convey exactly why the message is being rejected. Polk Expires January 11, 2006 [Page 4] Internet-Draft SIP E2E Assured Signaling Security Jan 2006 NOTE to Req#4 - the author is not sure what to do if this indication was added by an intermediary in the path of the message and a SIP element further downstream cannot or will not support the indication. Does the intermediary swallow the message and formulate another one the downstream element can support? Or, does the injecting intermediary react with a new SIP request message not mandating TLS? As this document was written fairly quickly, with little time to coordinate with others within the SIP community, additional requirements can be added and the above modified based on discussions within the WG. 4. High Level Offering at a Solution Here is a list of steps that can be taken to satisfy the requirements listed above as is. If those requirements change, whether through modification or addition, this offered (high level) solution will have to change as well. Obviously, discussion is necessary on this general idea. 4.1 Step 1 to High Level Offering An obvious means for identifying a certain mandatory handling of SIP messages is through the use of the Proxy-Require header. Since there is no current value to indicate end-to-end signaling security, one would have to be created. For example: Proxy-Require: e2e-sec This would satisfy Req#2 above which calls for an indication within the SIP message that it is to be treated in a certain way. This header/option-tag indicates to the receiving SIP element to continue with the transport layer security which was received from the previous hop SIP element. The Proxy-Require header is visible to the processing of SIP intermediaries, satisfying Req#3 above. This header and option-tag MUST be readable by SIP intermediaries. The header (or option-tag) MAY be added by any SIP intermediary to a message it does not exist in. This header and its option-tag MUST NOT be modified or deleted by any SIP intermediary during processing and transmission. This satisfies Req#4 from above. If the UAC wants to inform the destination UAS it originated TLS over TCP for this message, SIPFRAG [RFC3420] SHOULD be used to hide this fact from all intermediaries that may modify or delete the Proxy-Require and/or Require header, including its option-tag(s). NOTE - The author is not sure how to address the likelihood that the Polk Expires January 11, 2006 [Page 5] Internet-Draft SIP E2E Assured Signaling Security Jan 2006 Proxy-Require header (meant for Proxies only) will not satisfy all SIP intermediaries, and that the additional "Require" header will have to also be present in the SIP message from the UAC to satisfy B2BUAs and BCs in the signaling path. This appears to be redundant, yet perhaps necessary. 4.2 Step 2 to High Level Offering Although this may meet with some amount of controversy, one means of providing the necessary indications per hop back to the UAC is to create implicit subscriptions based on the Proxy-Require header option-tag: "e2e-sec" just being in the Request message. This would mandate that each SIP intermediary compliant with this specification send a one-time NOTIFY to the UAC that it complied with the request that the message be forwarded as requested (encrypted) for that hop it controlled. The UAC would be aware of these NOTIFY messages coming and create a state table, waiting for the successful Response to the Request message it sent. If could be possible that these NOTIFY messages are sent to a remote server from the UAC and a combined single NOTIFY is sent to the UAC from this server the UAC trusts. The tuple within the NOTIFY with the same Call-ID, to and from and tags from the original Request message should suffice as identification to the UAC which Request message these NOTIFY messages are associated to. The subscription need not be long lasting - therefore it is not foreseen it should last longer than it takes the SIP intermediary to complete the NOTIFY transaction. Either the UAC could implicitly trust all the NOTIFY messages that were sent, or there could be a means of the UAS for informing the UAC which intermediaries the message transited. This could be accomplished as part of the XML of the NOTIFY message from the UAS to the UAC, or it could be part of a new header that lists all the SIP intermediaries the UAS is aware of from the VIA headers in the Request message. The UAS could take all the intermediary's URIs and build this new header's header values (similar to a Route header) and return that in a 200 OK of the original transaction. An example could be: Hop-Record: server1.atlanta.example.com, server10.atlanta.example.com, bigbox3.biloxi.example.com for the 3 Proxies the original SIP Request traversed from the VIA headers received by the UAS. No order is likely necessary. Polk Expires January 11, 2006 [Page 6] Internet-Draft SIP E2E Assured Signaling Security Jan 2006 This listing of the SIP elements by URI in the 200 OK would give the UAC receiving such a message the necessary information to match against all the tuple matching NOTIFY messages it received for that Request message and compare to see if all the SIP element URIs had positive indications indicated in their NOTIFY message to that UAC. If the list matched, the UAC can know as best as possible that the original Request message transited to the UAS encrypted all the way. If the list doesn't match, it will know that something went wrong - but that the UAS still received the request message. If the list contained in this new header in the 200 OK matches the list of received NOTIFY messages from SIP intermediaries, this satisfies Req#1 above. NOTE - The author doesn't know what to do about this list of intermediaries in the 200 OK being inconsistent with the list of NOTIFY respondents, divulging that there are more SIP elements that were present in the UAS's response. This c/should lead the UAC to conclude there are intermediaries acting as B2BUAs or BCs between it and the UAS. This is topology information the UAC might not have the privilege to know otherwise. This is a potential security risk with this solution. 4.3 Rejection Response from Intermediary Section 8.1.3.5 of [RFC3261] states clearly that the proper rejection indication to an unsupported extension to SIP is a 420 (Bad Extension) Response accompanied with an Unsupported Header listing all extensions not supported by that SIP element; this includes Proxy-Require and Require header option-tags. This satisfies Req#4 above. 5. Diagrams for Discussion For early discussions of the document, please consider the following two layer 7 diagrams for those discussions: 5.1 Diagram for Discussion Involving 3 Domains ____________ _____________________ ____________ | | | | | | | UAC -- PS1 --- PS2 --- PS3 --- PS4 --- PS5 -- UAS | |____________| |_____________________| |____________| Domain 1 Domain 2 Domain 3 Figure 1. 3 Domain Diagram - Alice is the user of the UAC. Polk Expires January 11, 2006 [Page 7] Internet-Draft SIP E2E Assured Signaling Security Jan 2006 - Bob is the user of the UAS. - PS1 is the outbound Proxy for the UAC. - PS5 is the inbound Proxy for the UAS. - PS2, PS3 and PS4 are within the same domain (separate from PS1 and PS5 5.2 Diagram for Discussion Involving >3 Domains Consider the following layer 7 diagram for discussion: ____________ _____ _____ _____ ____________ | | | | | | | | | | | UAC -- PS1 --- PS2 --- PS3 --- PS4 --- PS5 -- UAS | |____________| |_____| |_____| |_____| |____________| Domain 1 Domain 2 ^ Domain 4 Domain 5 Domain 3 Figure 2. 5 Domain Diagram - Alice is the user of the UAC. - Bob is the user of the UAS. - PS1 is the outbound Proxy for the UAC. - PS5 is the inbound Proxy for the UAS. - PS2, PS3 and PS4 are each in separate domains (and separate from PS1 and PS5) 6. IANA Considerations This document makes no request of the IANA at this time. If this document progresses further to the SIP WG for extensions to the SIP protocol as is, the Proxy-Require and Require header option-tag "e2e-sec" and the header "hop-record" (with no option- tags) will be called out here for registration. Modifications to this document will modify this section. 7. Security Considerations This document attempts to address a security hole within the SIP architecture, but probably opens up more security holes in its present form. Providing the possibility of a topology view of an infrastructure between a UAC and UAS could reveal SIP elements that would otherwise know be known to that endpoint. This could be of concern to the UAC's home network administrators. Part of the High Level solution offered here creates implicit Polk Expires January 11, 2006 [Page 8] Internet-Draft SIP E2E Assured Signaling Security Jan 2006 subscriptions back to a UAC that doesn't have a relationship with each SIP intermediary along a message path. Asking that each intermediary send a NOTIFY message back to the UAC opens up a means of both: - overloading the UAC with NOTIFY message (although there will not be that many packets send overall) - provides each intermediary a target endsystem to send packets to The latter of the two above could lead to abuse (a point of attack) or a security hole. 8. References 8.1 Normative References [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. 8.2 Informative References [RFC3329] J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003 [RFC3840] J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol", RFC 3840, August 2004 Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Fax: none Email: jmpolk@cisco.com Polk Expires January 11, 2006 [Page 9] Internet-Draft SIP E2E Assured Signaling Security Jan 2006 Intellectual Property Statement 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 procedures with respect to rights in RFC 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Polk Expires October 29, 2005 [Page 10]