Internet DRAFT - draft-wing-sipping-multipart-mixed
draft-wing-sipping-multipart-mixed
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
<?xml version="1.0" encoding="UTF-8"?>
<sdpng xmlns="http://www.iana.org/sdpng"
...
</sdpng>
--yradnuoB
Content-ID: <98efj3.2@10.1.1.1>
Content-Type: application/sdpng
Content-Disposition: session
<?xml version="1.0" encoding="UTF-8"?>
<sdpng xmlns="http://www.iana.org/sdpng"
...
</sdpng>
--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>
$
$ <?xml version="1.0" encoding="UTF-8"?>
$ <sdpng xmlns="http://www.iana.org/sdpng"
$...
$ </sdpng>
$ --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]
