SIP R. Sparks Internet-Draft dynamicsoft Expires: March 14, 2003 September 13, 2002 Internet Media Type message/sipfrag draft-ietf-sip-sipfrag-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 March 14, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document registers the message/sipfrag MIME media type. This type is similar to message/sip , but allows certain subsets of well formed SIP messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/ sipfrag is used with the REFER method to convey information about the status of a referenced request. Sparks Expires March 14, 2003 [Page 1] Internet-Draft message/sipfrag September 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition: message/sipfrag . . . . . . . . . . . . . . . . . 3 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Valid message/sipfrag parts . . . . . . . . . . . . . . . . . 4 3.2 Invalid message/sipfrag parts . . . . . . . . . . . . . . . . 5 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . 7 Non-Normative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Sparks Expires March 14, 2003 [Page 2] Internet-Draft message/sipfrag September 2002 1. Introduction The message/sip MIME media type defined in [1] carries an entire well formed SIP message. Section 23.4 of [1] describes the use of message/sip in concert with S/MIME to enhance end-to-end security. The concepts in that section can be extended to allow SIP entities to make assertions about a subset of a SIP message (for example, as described in [3]). The message/sipfrag type defined in this document is used to represent this subset. A subset of a SIP message is also used by the REFER method defined in [4] to carry the status of referenced requests. Allowing only a portion of a SIP message to be carried allows information that could compromise privacy and confidentiality to be protected by removal. This document does NOT provide a mechanism to segment a SIP message into multiple pieces for separate transport and later reassembly. The message/partial type defined in [2] provides a solution for that problem. 2. Definition: message/sipfrag A valid message/sipfrag part is one that could be obtained by starting with some valid SIP message and deleting any of the following o the entire start line o one or more entire header fields o the body The following ABNF [3] rule describes a message/sipfrag part using the SIP grammar elements defined in [1]. The expansion of any element is subject to the restrictions on valid SIP messages defined there. sipfrag = [ start-line ] *message-header [ CRLF [ message-body ] ] If the message/sipfrag part contains a body, it MUST also contain the appropriate header fields describing that body (such as Content- Length) as required by Section 7.4 of [1] and the null-line separating the header from the body. Sparks Expires March 14, 2003 [Page 3] Internet-Draft message/sipfrag September 2002 3. Examples 3.1 Valid message/sipfrag parts This section uses a vertical bar and a space to the left of each example to illustrate the example's extent. Each line of the message/sipfrag element begins with the first character after the "| " pair. The first two examples show that a message/sipfrag part can consist of only a start line. | INVITE sip:alice@atlanta.com SIP/2.0 or | SIP/2.0 603 Declined The next two show that Subsets of a full SIP message may be represented. | REGISTER sip:atlanta.com SIP/2.0 | To: sip:alice@atlanta.com | Contact: ;q=0.9, | ;q=0.1 | SIP/2.0 400 Bad Request | Warning: 399 atlanta.com Your Event header field was malformed A message/sipfrag part does not have to contain a start line. This example shows a part that might be signed to make assertions about a particular message. (See [5].) | From: Alice | To: Bob | Contact: | Date: Thu, 21 Feb 2002 13:02:03 GMT | Call-ID: a84b4c76e66710 | Cseq: 314159 INVITE The next two examples show message/sipfrag parts that contain bodies. Sparks Expires March 14, 2003 [Page 4] Internet-Draft message/sipfrag September 2002 | SIP/2.0 200 OK | Content-Type: application/sdp | Content-Length: 247 | | v=0 | o=alice 2890844526 2890844526 IN IP4 host.anywhere.com | s= | c=IN IP4 host.anywhere.com | t=0 0 | m=audio 49170 RTP/AVP 0 | a=rtpmap:0 PCMU/8000 | m=video 51372 RTP/AVP 31 | a=rtpmap:31 H261/90000 | m=video 53000 RTP/AVP 32 | a=rtpmap:32 MPV/90000 | Content-Type: text/plain | Content-Length: 11 | | Hi There! 3.2 Invalid message/sipfrag parts This section uses the character "X" followed by a space to the left of each example to illustrate the example's extent. Each line of the invalid message/sipfrag element begins with the first character after the "X " pair. The start line, if present, must be complete and valid per [1]. X INVITE X INVITE sip:alice@atlanta.com SIP/1.09 X SIP/2.0 X 404 Not Found All header fields must be valid per [1]. Sparks Expires March 14, 2003 [Page 5] Internet-Draft message/sipfrag September 2002 X INVITE sip:alice@atlanta.com SIP/2.0 X Via: SIP/2.0/UDP ;branch=z9hG4bK29342a X To: <>;tag=39234 X To: sip:alice@atlanta.com X From: sip:bob@biloxi.com;tag=1992312 X Call-ID: this is invalid X INVITE sip:alice@atlanta.com SIP/2.0 X From: ;tag=z9hG4bK2912;tag=z9hG4bK99234 If a body is present in the message/sipfrag part, the headers required by Section 7.4 of [1] and the null-line separating the header from the body. X MESSAGE sip:alice@atlanta.com SIP/2.0 X Hi There! 4. Discussion Section 23 of [1], and memos [4] and [5] provide motivation and detailed examples of carrying all or part of a SIP message in a MIME part. Briefly, using this representation along with S/MIME enables protecting and making assertions about portions of a SIP message header. It also enables applications to describe the messaging involved in a SIP transaction using portions of the messages themselves. The SIP REFER method [4], for instance, uses this to report the result of a SIP request to an authorized third party. However, as that document details, it is rarely desirable to include the entire SIP response message in this report as a message/sip MIME part. Doing so has significant negative security implications. The message/sipfrag type, on the other hand, allows a sender to select what information is exposed. Further, it allows information required in a full SIP message that is not pertinent to a description of that message to be elided, reducing message size. For instance, this allows a SIP element responding to a REFER to say "I got a 400 Bad Request with this Warning header field" without having to include the Via, To, From, Call-ID, CSeq and Content-Length header fields mandatory in a full SIP message. The message protection mechanism discussed in Section 23 of [1] assumes an entire SIP message is being protected. However, there are several header fields in a full SIP message that necessarily change during transport. [1] discusses how to inspect and ignore those changes. This idea is refined in [5] to allow protection of a subset Sparks Expires March 14, 2003 [Page 6] Internet-Draft message/sipfrag September 2002 of the entire message, avoiding the extra work and potential errors involved in ignoring parts of the message that may legitimately change in transit. That document also describes constructing cryptographic assertions about pertinent subsets of a SIP message header before the full header (including hop-by-hop transport specific information) may be available. 5. IANA Considerations The message/sipfrag media type is defined by the following information: Media type name: message Media subtype name: sipfrag Required parameters: none Optional parameters: version version: The SIP-Version number of the enclosed message (e.g., "2.0"). If not present, the version defaults to "2.0". Encoding scheme: SIP messages consist of an 8-bit header optionally followed by a binary MIME data object. As such, SIP messages must be treated as binary. Under normal circumstances SIP messages are transported over binary-capable transports, no special encodings are needed. Security considerations: see below 6. Security Considerations A message/sipfrag mime-part may contain sensitive information or information used to affect processing decisions at the receiver. When exposing that information or modifying it during transport would do harm, its level of protection can be improved using the S/MIME mechanisms described in section 23 of [1], with the limitations described in section 26 of that document, and the mechanisms described in [5]. Applications using message/sipfrag to represent a subset of the header fields from a SIP message must consider the implications of the message/sipfrag part being captured and replayed and include sufficient information to mitigate risk. Any SIP extension which uses message/sipfrag MUST describe the replay and cut and paste threats unique to its particular usage. For example, [5] discusses how a subset of a SIP message can be used to assert the identity of the entity making a SIP request. The draft details what information must be contained in the subset to bind the assertion to the request. Normative References Sparks Expires March 14, 2003 [Page 7] Internet-Draft message/sipfrag September 2002 [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] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Non-Normative References [4] Sparks, R., "The SIP Refer Method", Internet-Draft