SIPPING D. Wing Internet-Draft Cisco Systems Expires: December 30, 2005 June 28, 2005 SIP Offer/Answer and Middlebox Communication with End-to-End Security draft-wing-sipping-multipart-mixed-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 December 30, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides a mechanism to allow middleboxes to see IP addresses, ports, and bandwidth when the session description is in an S/MIME-encrypted body. RFC Category The author intends this Internet Draft to be published as an Proposed Standards RFC. Wing Expires December 30, 2005 [Page 1] Internet-Draft SIP Multipart Mixed June 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Sending Offers . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Receiving Offers and Sending Answers . . . . . . . . . . . 4 2.3 Receiving Answers . . . . . . . . . . . . . . . . . . . . 4 2.4 Sensitive SDP Information . . . . . . . . . . . . . . . . 4 3. Interaction with Multipart/Alternative . . . . . . . . . . . . 4 4. Evaluation of End-to-Middle Security Requirements . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Offer Containing Plaintext and Encrypted Parts . . . . . . 8 5.2 Offer Containing SDP and SDPng Parts and S/MIME Session . 9 5.3 Offer Containing Multipart/Mixed and Multipart/Alternative . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 8.2 Informational References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Wing Expires December 30, 2005 [Page 2] Internet-Draft SIP Multipart Mixed June 2005 1. Introduction Network access and QoS is often enforced by middleboxes, such as SIP proxies coordinating access with firewalls and routers, or by firewalls which examine SIP signaling as it traverses the firewall. Such middleboxes need to know the IP addresses and UDP ports of authorized flows and need to know the bandwidth for flows to provide appropriate QoS. In SIP, S/MIME is specified as the means to provide end-to-end security[2]. However, the use of S/MIME prevents middleboxes from performing their tasks described above. This document describes how to use multipart/mixed to allow an endpoint to use S/MIME security to protect its SDP end-to-end, yet still provide the information necessary for middleboxes to authorize a media flow and provide appropriate QoS. The semantics of multipart/mixed in this document follow the semantics described in [3]. The technique described by this document does not meet all of the requirements of sipping-e2m-sec-reqs [4]. 2. Mechanism 2.1 Sending Offers A UA SHOULD construct a multipart/mixed body containing at least two parts: at least one part for consumption by the middleboxes and at least one part for consumption by the remote UA. This requirement is a SHOULD to provide the necessary port and bandwidth information to both the Answerer's middleboxes and the Offerer's middleboxes. There is at least a top-level multipart/mixed part containing two parts. The top-level multipart/mixed MUST have a Content-Disposition header field indicating "session" if an offer is contained therein. The first part contains a Content-Type of application/sdp and a Content-Disposition of "middlebox", and a second part contains a Content-Type appropriate for consumption by the remote peer with a Content-Disposition of "session". The SDP sent with the Content-Disposition of "middlebox" MUST be fully compliant with SDP [1] and its extensions. Section 2.4 contains the list of SDP information that is considered too private to reveal in the clear when S/MIME can provide end-to-end encryption of that information. Offers SHOULD utilize this list in determining which pieces of SDP information should be elided from the Wing Expires December 30, 2005 [Page 3] Internet-Draft SIP Multipart Mixed June 2005 plaintext multipart/mixed body parts. 2.2 Receiving Offers and Sending Answers If a UA receives an offer containing multipart/mixed, and is compliant with this document, the UA MUST ignore the parts containing a Content-Disposition of "middlebox". Such parts are intended by the Offerer to only be processed by middleboxes. The receiver should find a part with a Content-Disposition of "session" and Content-Type of application/sdp. If an Offer contained a multipart/mixed part, an answerer compliant with this specification MUST create an answer containing a multipart/mixed part. This is because the Offerer's network may require seeing the port and bandwidth information even if the Answerer's network has no such need. If an Offer did not contain a multipart/mixed part, the Answer MUST NOT contain a multipart/mixed part. This is because the Offerer might not support multipart/mixed. 2.3 Receiving Answers If the Answerer doesn't understand a multipart/mixed Offer, the Offer will be rejected. The UA MAY retry sending the Offer without the multipart/mixed part. However, if the Offerer's network requires disclosure of network ports or bandwidth, such an offer may not succeed in creating a usable media path to the Answerer. Techniques such as ICE [6] or preconditions [7] may be useful to discover when a viable media path wasn't established. 2.4 Sensitive SDP Information This section enumerates SDP information that is deemed too sensitive to disclose in unencrypted SDP. Other documents may add to this list. o= (owner/creator and session identifier) s= (session name) i= (session information, media title) u= (URI of description) e= (email address) p= (phone number) k= (encryption key) a=crypto ([11]) a=key-mgmt ([9] when using Null encryption algorithm of MIKEY [10]) 3. Interaction with Multipart/Alternative An Offer can contain both a multipart/mixed part and a multipart/ alternative part [5]. This might be necessary, for example, if an Wing Expires December 30, 2005 [Page 4] Internet-Draft SIP Multipart Mixed June 2005 Offer contains a part describing an RTP session and another S/MIME- encrypted part describing an SRTP session. See the example in section Section 5.3. Likewise, the opposite might occur -- an Offer might contain a multipart/alternative and inside of that are two multipart/mixed parts. This might be necessary, for example, if an Offer contains two alternatives, one with simple SDP and another with more complex SDPng. The Answer would indicate if SDPng was understood and the middlebox would apply the necessary network policy and QoS for the SDPng session in the Offer. 4. Evaluation of End-to-Middle Security Requirements This section evaluates the technique described in this document against End-to-Middle Security Requirements [4]. The requirements below are taken from that document. REQ-GEN-1: The solution SHOULD have little impact on the way a UA handles S/MIME-secured messages. This specification meets requirement REQ-GEN-1. Multipart/mixed doesn't change the handling of S/MIME itself, but multipart/mixed does require compliance with additional portions of MIME, which isn't required by [2]. REQ-GEN-2: It SHOULD NOT have an impact on proxy servers that do not provide services based on S/MIME-secured bodies in terms of handling the existing SIP headers. This specification meets requirement REG-GEN-2. REQ-GEN-3: It SHOULD NOT violate the standardized mechanism of proxy servers in terms of handling message bodies. This specification meets requirement REQ-GEN-3. However, if a proxy server was previously parsing application/sdp at the top level of a SIP message and interpreting the SDP in order to apply some network policy, that proxy server will now have to parse the multipart/mixed part. REQ-GEN-4: It SHOULD allow a UA to discover security policies of proxy servers. Security policies imply what data is needed to disclose and/or verify in a message. This specification does not meet requirement REQ-GEN-4. REQ-CONF-1: The solution MUST allow encrypted data to be shared with the recipient UA and a proxy server, when a UA wants. Wing Expires December 30, 2005 [Page 5] Internet-Draft SIP Multipart Mixed June 2005 This specification does not meet requirement REQ-CONF-1. REQ-CONF-2: It MUST NOT violate end-to-end encryption when the encrypted data does not need to be shared with any proxy servers. This specification does not meet requirement REQ-CONF-2. REQ-CONF-3: It SHOULD allow a UA to request a proxy server to view specific message bodies. The request itself SHOULD be secure, namely be authenticated for the UA and be verified for the data integrity. This specification does not meet requirement REQ-CONF-3. REQ-CONF-4: It MAY allow a UA to request that the recipient UA disclose information to the proxy server, to which the requesting UA is initially disclosing information. The request itself SHOULD be secure, namely be authenticated for the UA and be verified for the data integrity. This specification does not meet requirement REQ-CONF-4. REQ-INT-1: The solution SHOULD work even when the SIP end-to-end authentication and integrity services are enabled. This specification meets requirement REQ-INT-1. REQ-INT-2: It SHOULD allow a UA to request a proxy server to verify specific message bodies and authenticate the user. The request itself SHOULD be secure, namely be authenticated for the UA and be verified for the data integrity. This specification does not meet requirement REQ-INT-2. REQ-INT-3: It SHOULD allow a UA to request the recipient UA to send the verification data of the same information that the requesting UA is providing to the proxy server. The request itself SHOULD be secure, namely authenticated for the UA and be verified for the data integrity. This specification does not meet requirement REQ-INT-3. 5. Examples In the following examples, certain information is elided for brevity, as shown with ellipses ("..."). Encrypted portions are shown with "$". Wing Expires December 30, 2005 [Page 6] Internet-Draft SIP Multipart Mixed June 2005 In all of the examples, the plaintext SDP describes the session's ports, codecs, and packetization intervals, but doesn't include secrets such as the SRTP keys. This same technique can be used with "k=" (RTP [8]), a Null MIKEY key ([9], [10]), or sdescriptions [11]. Wing Expires December 30, 2005 [Page 7] Internet-Draft SIP Multipart Mixed June 2005 5.1 Offer Containing Plaintext and Encrypted Parts In this example, the unencrypted part doesn't include the SRTP keys, whereas the encrypted part does include the SRTP keys. INVITE sip:bob@biloxi.example.com SIP/2.0 ... Content-Type: multipart/mixed; boundary=yradnuoB Content-Disposition: session --yradnuoB Content-ID: <83rqjqef3.218.1@10.1.1.1> Content-Type: application/sdp Content-Disposition: middlebox v=0 o=alice 2890844526 2890844526 IN IP4 192.168.47.11 s=- c=IN IP4 192.168.47.11 t=0 0 m=video 51372 RTP/SAVP 31 m=audio 49170 RTP/SAVP 0 --yradnuoB Content-ID: <83rqjqef3.218.2@10.1.1.1> Content-Type: application/pkcs7-mime Content-Disposition: session $ Content-Type: application/sdp $ Content-Disposition: session $ $ v=0 $ o=alice 2890844526 2890844526 IN IP4 192.168.47.11 $ s=- $ c=IN IP4 192.168.47.11 $ t=0 0 $ m=video 51372 RTP/SAVP 31 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 $ inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 $ m=audio 49170 RTP/SAVP 0 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 $ inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 --yradnuoB-- Wing Expires December 30, 2005 [Page 8] Internet-Draft SIP Multipart Mixed June 2005 5.2 Offer Containing SDP and SDPng Parts and S/MIME Session In this example, the offer contains SDP and SDPng parts for consumption by an SDP-aware middlebox and by an SDPng-aware middlebox, and contains an encrypted part for consumption by the remote peer. INVITE sip:bob@biloxi.example.com SIP/2.0 ... Content-Type: multipart/mixed; boundary=yradnuoB Content-Disposition: session --yradnuoB Content-ID: <98efj3.1@10.1.1.1> Content-Type: application/sdp Content-Disposition: middlebox v=0 o=alice 2890844526 2890844526 IN IP4 192.168.47.11 s=- c=IN IP4 192.168.47.11 t=0 0 m=audio 51400 RTP/AVP 0 33 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 --yradnuoB Content-ID: <98efj3.2@10.1.1.1> Content-Type: application/sdpng Content-Disposition: middlebox --yradnuoB Content-ID: <98efj3.2@10.1.1.1> Content-Type: application/sdpng Content-Disposition: session --yradnuoB-- 5.3 Offer Containing Multipart/Mixed and Multipart/Alternative Wing Expires December 30, 2005 [Page 9] Internet-Draft SIP Multipart Mixed June 2005 This example combines multipart/mixed with multipart/alternative[5]. This would be used when an Offerer needs to communicate ports and bandwidth in SDP to a middlebox, and send an encrypted offer containing SDP and SDPng to the remote UA. INVITE sip:bob@biloxi.example.com SIP/2.0 ... Content-Type: multipart/mixed; boundary=dexiM Content-Type: session --dexiM Content-Type: application/sdp Content-Disposition: middlebox v=0 o=alice 2890844526 2890844526 IN IP4 192.168.47.11 s=- c=IN IP4 192.168.47.11 t=0 0 m=audio 51400 RTP/AVP 0 33 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 --dexiM Content-Type: application/pkcs7-mime Content-Disposition: session $ Content-Type: multipart/alternative; boundary=evitanretlA $ Content-Disposition: session $ $ --evitanretlA $ Content-Type: application/sdp $ Content-ID: <98efj3.1@10.1.1.1> $ $ v=0 $ o=alice 2890844526 2890844526 IN IP4 192.168.47.11 $ s=- $ c=IN IP4 192.168.47.11 $ t=0 0 $ m=video 51372 RTP/SAVP 31 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 $ inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 $ m=audio 49170 RTP/SAVP 0 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 $ inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 $ $ --evitanretlA $ Content-Type: application/sdpng Wing Expires December 30, 2005 [Page 10] Internet-Draft SIP Multipart Mixed June 2005 $ Content-ID: <98efj3.2@10.1.1.1> $ $ $ $ --evitanretlA-- --dexiM-- 6. Security Considerations This document provides a mechanism to protect sensitive information from a middlebox, but the mechanism is only effective if sensitive information is not included in the unencrypted part or parts. Sending sensitive information in unencrypted parts SHOULD be limited to only the information necessary to provide access to the network and QoS. This includes information such as IP address, UDP port, codec, and sample period. A User Agent may maliciously or accidentally provide incorrect information in the part intended for use by a middlebox, and different information in the part intended for use by the remote peer. For example, the utilized bandwidth might be below or above the expected bandwidth due to changing codecs for handling realtime fax. As another example, an endpoint might claim to send a small bandwidth audio stream but actually transmit a large bandwidth video stream. Policy enforcement, such as limiting bandwidth to that described in the middlebox section, can be helpful to thwart such abuse. 7. IANA Considerations This document requires IANA registration of the new Content- Disposition value "middlebox". 8. References 8.1 Normative References [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] 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. [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Wing Expires December 30, 2005 [Page 11] Internet-Draft SIP Multipart Mixed June 2005 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [4] Ono, K. and S. Tachimoto, "Requirements for End-to-middle Security for the Session Initiation Protocol (SIP)", draft-ietf-sipping-e2m-sec-reqs-06 (work in progress), March 2005. [5] Jennings, C., "SIP Offer/Answer with Multipart MIME", draft-jennings-sipping-multipart-00 (work in progress), February 2005. 8.2 Informational References [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", draft-ietf-mmusic-ice-04 (work in progress), February 2005. [7] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [9] Arkko, J., "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in progress), June 2005. [10] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [11] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-11 (work in progress), June 2005. Wing Expires December 30, 2005 [Page 12] Internet-Draft SIP Multipart Mixed June 2005 Author's Address Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: dwing@cisco.com Wing Expires December 30, 2005 [Page 13] Internet-Draft SIP Multipart Mixed June 2005 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. Wing Expires December 30, 2005 [Page 14]