Internet Draft M. Barnes Document: draft-barnes-sipping-sec-inserted-info-00.txt Nortel Category: Standards Track Expires: December 2003 June 2003 A Mechanism to Secure SIP Identity headers inserted by Intermediaries 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft defines a standard mechanism for securing SIP headers that are inserted into requests and responses. The fundamental requirements, for securing the headers inserted by an intermediary routing or retargeting a request or response, are summarized. The solution is directed towards headers that contain identity related information, such as Record-Route, Via, and History-Info. The proposed solution defines an Authenticated Inserted Identity Header Body based on S/MIME to secure the headers. This mechanism is optional, however, the use of it enhances the overall security of SIP by ensuring the integrity of the inserted headers. Table of Contents 1. Requirements Summary...........................................3 Barnes Expires û December 2003 [Page 1] SIP Secure Identity Header Insertion June 2003 3. Authenticated Inserted Identity Header Body Description........3 4. Example of a Request with an AIIHB.............................5 6. Receiving an AIIHB.............................................6 5. AIIHB in Responses.............................................6 7. Encryption of Header information...............................6 8. Interactions with AIB..........................................7 9. Security Considerations........................................7 10. IANA Considerations...........................................7 Normative References..............................................7 Informative References............................................8 Overview This draft proposes a general mechanism to secure headers inserted by an intermediary routing or retargeting a request. RFC 3261 [1] describes the security services required for the SIP protocol. The SIP Authenticated Identity Body (AIB) Format [2] provides an additional security mechanism, which provides reference integrity of the headers in a request which can assert identity information about the originator of the request. The primary difference between the problem discussed in this document and the problem domain of [2] is that the header information is being inserted by an entity routing or retargeting a Request, resulting in a slightly different problem than the basic SIP header or Identity problem. The area of primary concern is the Request-URIs, since they can reflect some aspect of a user's identity and service routing and are essentially carried in and captured by the Record-Route [1] and History-Info [8] headers. Another objective of this solution is to ensure that the information carried in these headers is protected from being accessed or manipulated by non-authorized entities. Integrity of inserted headers is important in that end applications making use of the header information could make false or misleading decisions about the routing and handling of a request or response based upon this information. This solution proposes the definition of an Authenticated Inserted Header Identity Body (AIIHB) in a manner similar to that defined for the Authenticated Identity Body defined in [2] to protect the header Information from being manipulated by a rogue application. The AIIHB provides reference integrity of the headers, inserted into a request or response, which can assert identity information about the intermediaries routing and/or retargeting the request or response. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. Barnes Expires - December 2003 [Page 2] SIP Secure Identity Header Insertion June 2003 1. Requirements Summary The following summarizes the fundamental requirements for which this solution is proposed: 1) REQ-1: Ability for an entity receiving a request or response containing the header(s) inserted by an intermediary to determine whether any of the previously added header(s) have been altered. 2) REQ-2: Ability for an entity receiving a request or response containing the header(s) inserted by an intermediary to authenticate the identity represented by the header(s). 2. Discussion of AIIHB as the proposed Solution Initial consideration of AIIHB as the proposed solution to meet the requirements resulted in the following area of concern: There can be significant overhead in the use of S/MIME. This is especially highlighted for the History-Info scenario [11], since each entity adding a History-Info header would need to validate the information in the other History-Info headers already in the message prior to adding the new header. The entirety of the History-Info headers must then be re-signed. However, the benefits of the AIIHB proposal were deemed to outweigh the value of considering other alternatives: 1. The use of AIIHB fully meets the requirements. 2. The use of S/MIME is already an option for SIP implementations, thus the AIIHB proposal should minimize the impact of its implementation. 3. AIIHB complements the use of AIB. It should also be noted that there are systems where there is deemed to be a level of trust amongst the intermediaries as discussed in [10], thus the use of AIIHB for those systems would be optional. 3. Authenticated Inserted Identity Header Body Description This solution option is modeled after the Authenticated Identity Body (AIB) format as defined in [2], which provides reference integrity of the headers in a request which can assert identity information about the originator of the request. The primary difference between the proposal in this document and [2] is that the header information is being inserted by an entity routing or retargeting a Request, resulting in a slightly different problem than the basic SIP header or Identity problem. However, it is entirely consistent with the AIB Barnes Expires - December 2003 [Page 3] SIP Secure Identity Header Insertion June 2003 model whereby the network intermediary performs the role of an 'authentication service'. The following summarizes the differences between the requirements for headers inserted by intermediaries and the headers described in [2], which must be considered in defining the AIIHB: 1. The authenticated identity body relates to a header field which is inserted by an intermediary rather than the From field of the Request. 2. The authenticated identity is being requested to be authenticated by the intermediary which is inserting the header in the request/response and NOT by the user associated with the identity contained in the header. 3. There may be multiple instances of the same header in a message. An AIIHB is a MIME body of type 'message/sipfrag' ([5]). This body MUST have a Content-Disposition disposition-type of 'aiihb', a new value defined in this document specifically for authenticated inserted header identity bodies. The Content-Disposition header SHOULD also contain a 'handling' parameter indicating that this MIME body is optional (i.e. if this mechanism is not supported by the user agent server, it can still attempt to process the request). AIIHBs using the 'message/sipfrag' MIME type MUST contain the following headers when providing identity for an INVITE request: From, Call-ID and the Identity related header(s) for which AIIHB is providing reference integrity. AIIHBs MAY also contain the To and CSeq headers. An example of the AIIHB format for an INVITE is: Content-Type: message/sipfrag Content-Disposition: aiihb; handling=optional Record-Route: From: BigGuy To: LittleGuy Call-Id: 12345600@here.com History-Info: ; index=1 Unsigned AIIHBs MUST NOT be honored by any recipients. After the AIIHB has been signed, it SHOULD be added it to any existing MIME bodies in the request (such as SDP), if necessary by transitioning the outermost MIME body to a 'multipart/mixed' format. Barnes Expires - December 2003 [Page 4] SIP Secure Identity Header Insertion June 2003 4. Example of a Request with an AIIHB The following shows a full SIP INVITE request with an AIB: INVITE sip:UserA@ims.nortelnetworks.com SIP/2.0 Via: SIP/2.0/UDPims.nortelnetworks.com:5060;branch=1 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE History-Info: ; index=1 Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-Length: --boundary42 Content-Type: message/sipfrag Content-Disposition: aiihb; handling=optional Record-Route: From: BigGuy To: LittleGuy Call-Id: 12345600@here.com History-Info: ; index=1 --boundary42 Barnes Expires - December 2003 [Page 5] SIP Secure Identity Header Insertion June 2003 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- --unique-boundary-1ù [Editor's note: The above example needs validating as it was quickly cut and pasted from several examples in other drafts and thus it's extremely likely that it has inaccuracies.] 6. Receiving an AIIHB Only entities which need to make use of the information for which AIIHB is providing reference integrity need to verify the AIIHB. When an entity receives a request containing an AIIHB, if it does not need to make use of any of the information which is contained in the AIIHB, then it can just forward the AIIHB in the request. [Editor's note: This obviously needs additional normative detail around the processing by an entity that wants to make us of the AIIHB, both by the addition of a History-Info entry and some guidance for applications wanting to make us of the information.] 5. AIIHB in Responses The focus of AIIHB is the security of headers inserted in Requests that might influence behavior and subsequent responses to those requests. Thus, new AIIHB information is not included in responses, but rather MAY be forwarded in the response, depending the recommendations for that header. [Editor's note: This obviously needs additional normative detail, particularly around the processing by an entity that wants to make us of the information in the responses and how the integrity is maintained and validated.] 7. Encryption of Header information Barnes Expires - December 2003 [Page 6] SIP Secure Identity Header Insertion June 2003 As with the AIB, the security of the AIIHB is predicated on the secure distribution of the key. When an AIIHB is encrypted, the AIIHB SHOULD always be encrypted before it is signed. Note that this means that the recipients of the request, even if they are unable to inspect the AIIHB, will still be able to see who signed that body (although it will not necessarily be obvious that the body contains an AIIHB). 8. Interactions with AIB It could be suggested that in the case of an AIB added by the originator of the request that the information carried in the AIB would be redundant and unnecessary in the AIIHB. However, it is the inclusion of this information also in the AIIHB that provides greater assurance that the inserted Headers are indeed valid. This also removes the need for the intermediary that is protecting these headers to verify the AIB, which would be required if they were depended upon. When a user agent receives a request containing both an AIB and an AIIHB, it should first validate the AIIHB as described in section 6 to ensure the hop by hop integrity of the message prior to validating the AIB as described in [2]. 9. Security Considerations This document RECOMMENDs the inclusion of the From, Call-ID and the Identity related header(s) headers in AIIHBs. If these headers are omitted, some important security properties of AIIHB are lost. The use of AIIHB to capture inserted headers improves the overall security of SIP. For example, the capturing of the History-Info header information in a secure manner using the AIIHB provides an additional means (without requiring signed keys for all the involved entities) for the original requestor to be assured that the request was properly retargeted. 10. IANA Considerations This document defines a new MIME Content-Disposition disposition-type value of 'aiihb'. This value is reserved for MIME bodies that contain an authenticated inserted header, as described in section 3. Normative References Barnes Expires - December 2003 [Page 7] SIP Secure Identity Header Insertion June 2003 [1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261, June, 2002. [2] J. Peterson, " SIP Authenticated Identity Body (AIB) Format", draft-ietf-sip-authid-body-01.txt, Work in Progress, February, 2003. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] J. Peterson, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity- 01.txt, Work in Progress, February 2003. [5] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, September 2002. [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [7] R. Troost, S. Dorner, K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. Informative References [8] M. Barnes, M. Watson, C. Jennings, J. Peterson, "SIP Generic Request History Capability û Requirements", draft-ietf-sipping-req- history-04.txt, Work in Progress, June 2003. [9] E. Rescorla, B. Korver, "Guidelines for Writing RFC Text on Security Considerations", draft-iab-sec-cons-03.txt, Work in Progress, February 2003. [10] C. Jennings, J. Peterson, M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [11] M. Barnes, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", draft-ietf-sip-history-info- 00.txt, Work in Progress, June 2003. Acknowledgements Barnes Expires - December 2003 [Page 8] SIP Secure Identity Header Insertion June 2003 Author's Address Mary Barnes Nortel Networks 2380 Performance Drive Richardson, TX USA 75022 Phone: 1-972-684-5432 Email: mbarnes@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Barnes Expires - December 2003 [Page 9]