Internet Draft M. Barnes Document: draft-barnes-sipping-sec-inserted-info-01.txt Nortel Category: Standards Track Expires: April 2004 October 2003 A Mechanism to Secure SIP information 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 proposes a standard mechanism for securing information in SIP requests and responses, inserted by intermediaries, which may be used by other intermediaries or the endpoints as the basis for services. Thus, the requirements and proposed solution are intended as a general middle-to-middle and middle-to-end security mechanism applicable to both headers and message bodies. This mechanism is optional, however, the use of it enhances the overall security of SIP by ensuring the integrity of the information inserted by an intermediary. Table of Contents 1. Background.....................................................3 2. Requirements Summary...........................................5 Barnes Expires – April 2004 [Page 1] SIP Secure Header Insertion October 2003 3. Solution Considerations and Options............................6 4. Detailed Solution Description..................................6 5. Examples.......................................................6 6. Receiving Secured Information in a Request.....................6 7. Secured Information in Responses...............................7 8. Security Considerations........................................7 9. IANA Considerations............................................7 Normative References..............................................7 Informative References............................................8 Overview This draft proposes a standard mechanism for securing information, in SIP Requests and Responses, inserted by intermediaries. One of the security concerns are headers, or message bodies, containing information which can reflect some aspect of a user's identity and service routing, such as the Request-URIs contained in the History- Info header [11], thus confidentiality is an objective. Another security objective is to ensure that the information carried in these headers is protected from being accessed or manipulated by non- authorized entities. Integrity of information inserted by intermediaries is important in that end applications making use of the information could make false or misleading decisions about the routing and handling of a request or response based upon this information. RFC 3261 [1] describes the security services required for the SIP protocol in terms of addressing the end-to-end and hop-by-hop (TLS) security requirements. 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. While some of the information to be secured by the proposal in this draft may also be deemed to reveal information about the originator of the request (e.g. History-Info), the general problem is different, since the information is inserted by an intermediary and not by a SIP UA. As identified in the End-to-Middle Security proposal [12], the model whereby there are trusted and partially-trusted (in terms of SIP routing only) intermediaries involved in the routing and forwarding of a request means that TLS would not be suitable. The End-to-Middle proposal addresses the requirements for an end-to-middle solution to handle the problem of securing information in a Request sent by a SIP UA that may be needed by an intermediary under this model. This draft complements the End-to-Middle proposal by addressing the middle-to-middle problem of securing information added to a SIP Barnes Expires - April 2004 [Page 2] SIP Secure Header Insertion October 2003 Request or Response by an intermediary, used by another intermediary. It also addresses the middle-to-end security problem of ensuring the integrity of the information added by an intermediary, received by a SIP UA. Section 1 summarizes the background of the problem to be solved with some examples scenarios. Section 2 identifies the requirements. Section 3 discusses some considerations for the solution options, with the remaining sections expected to detail the solution once the requirements are agreed. 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]. 1. Background The following provides some the scenarios under which a Middle-to- Middle (m2m) and Middle-to-End (m2e) security model would be applicable. One of the fundamental considerations for these scenarios is that the User is trusting a Proxy to provide a service and add information through whatever mechanisms are established for the authorization of that service on the users behalf (e.g. Local Policy or configuration, Require header, Supported header, Session Policy [13], etc.). Thus, it is within the scope of this service authorization mechanism that the policy to secure any information added to a Request would be specified (i.e. authorization of the service implies authorization to secure the information). This first scenario involves User#1 in a Visited network, where there is no expectation of services beyond fundamental routing. UA1 includes a Header field, such as History-Info, in the Request, which Proxy#1 uses. The security for this can be provided by the End-to- Middle proposal. However, Proxy#1, who is trusted by the UA makes a change to that header and adds another header prior to forwarding the request. Since, Proxy#1 does not know whether Proxy#2 is authorized to alter the information, but the information is needed at UA2, it must be secured such that any manipulation of the information could be detected by UA#2. Barnes Expires - April 2004 [Page 3] SIP Secure Header Insertion October 2003 Visited network +---------------------+ | +-----+ +-----+ | +-----+ +-----+ +-----+ User#1 -->| | H1 |---->| * |---->| H1' | | | | H1'| | | | | | | | H2 |---->| * |---->| H2 | | +-----+ +-----+ | +-----+ +-----+ +-----+ | UA#1 Proxy A | Proxy#1 Proxy#2 UA#2 +---------------------+ H1: Header added initially by UA#1 which is protected by e2m security H1': Proxy#1 modifies H1 (after validating based on e2m security) H2 : Added by Proxy#1 (secured along with H1' using m2e security) *: Headers are forwarded in the Request, but are not manipulated. Figure 1: Middle-to-End Request This second scenario (Figure 2) involves User#2 in a Visited network, where there is no expectation of services beyond fundamental routing. UA1 includes a Header field, such as History-Info, in the Request, which Proxy#1 uses. The security for this can be provided by the End- to-Middle proposal. However, Proxy#1, who is trusted by the UA, makes a change to that header (H1) and adds another header (H2) prior to forwarding the request. Proxy#1 secures the information prior to sending to Proxy#2. Proxy#2 retargets the request to UA#3 (for example, based upon a response from UA#2 and internal routing decisions). Proxy#2 does not know whether Proxy#3 is authorized to alter the information, but the information may be needed at UA#3, so the information must be secured such that any unauthorized manipulation of the information could be detected by UA#3. Visited network +---------------------+ Proxy#1 Proxy#2 | +-----+ +-----+ | +-----+ +-----+ +-----+ User#2 -->| | H1 |---->| * |---->| H1' |---->| H1' |---->| H1'| | | | | | | | H2 | | H2' |<----| H2 | | | | | | | | | | H3 | +-----+ | +-----+ +-----+ | +-----+ +-----+ UA#2 | UA#1 Proxy A | | +---------------------+ v +-----+ +-----+ | |---->| H1'| | * |<----| H2'| | | | H3 | +-----+ +-----+ Proxy#3 UA#3 Barnes Expires - April 2004 [Page 4] SIP Secure Header Insertion October 2003 H1: Header added initially by UA#1 which is protected by e2m security H1': Proxy#1 modifies H1 (after validating using e2m security model) H2 : Added by Proxy#1. Secures along with H1' using m2m model. H2': Proxy#2 modifies H2 (after validating using m2m model) based on the response From UA#2. H3: Added by Proxy#2 based upon information in H2' and/or H1'. Secured along with H1'and H2' using m2m/m2e. *: Headers are forwarded in the Request/Responses, but not accessed. Figure 2: Middle-to-Middle Request From detailing the scenarios, it becomes apparent that the security resembles a transitive model, with each trusted intermediary involved effectively vouching for the previous intermediary, and the information being validated at each of the trusted intermediaries. Thus, the end UA need only needs the keys/certificates necessary to validate the information received from the last intermediary and not for each intermediary involved in manipulating the Request. This minimizes the amount of security certificates/keys needed by each intermediary and UA. 2. Requirements Summary The following summarizes the fundamental requirements for middle-to- middle and middle-to-end security of information (headers or message bodies) inserted by intermediaries: 1) REQ-1: An entity, receiving a request or response containing information inserted by an intermediary, which makes use of the information, MUST be able to validate the integrity of information to ensure it has not been altered. Thus, implying the following detailed requirements: REQ-1a: The entity (intermediary or UAs) SHOULD be able to determine whether a header or message body has been secured. REQ-1b: A mechanism MUST be defined such that the entity MAY validate the integrity of the information. 2) REQ-2: Intermediaries adding information to the requests and responses SHOULD secure the information prior to forwarding the request or response. Thus, implying the following detailed requirements: Barnes Expires - April 2004 [Page 5] SIP Secure Header Insertion October 2003 REQ-2a: A mechanism MUST be defined such that the entities MAY secure the information in a manner whereby only trusted entities are able to access the information. 3) REQ-3: SHOULD work with existing SIP security mechanisms, including end-to-end encryption and TLS. 4) REQ-4: SHOULD work with End-to-Middle security mechanisms. 5) REQ-5: SHOULD have no impact on intermediaries that don't make use of or add information to the requests and responses. 3. Solution Considerations and Options [Editor's note: Once there is agreement on the requirements and scenarios, this can be detailed] 4. Detailed Solution Description [Editor's note: Once there is agreement on the proposed solution, this will be detailed] 5. Examples [Editor's note: Once there is agreement on the proposed solution, this will be detailed] 6. Receiving Secured Information in a Request Only entities making use of the information that has been secured need to verify the secured information. When an entity receives a request containing secured information, if it does not need to make use of any of the information which is contained in the message, then it can just forward the secured information 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 the secured information, and some guidance for applications wanting to make us of the information.] Barnes Expires - April 2004 [Page 6] SIP Secure Header Insertion October 2003 7. Secured Information in Responses The focus is the security of information in Requests that might influence behavior and subsequent responses to those requests. Thus, new secured information is not included in responses, but rather MAY be forwarded in the response, depending on the recommendations for that information. [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.] 8. Security Considerations Securing information inserted by intermediaries improves the overall security of SIP. For example, the capturing of the History-Info header information in a secure manner 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. 9. IANA Considerations Normative References [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. Barnes Expires - April 2004 [Page 7] SIP Secure Header Insertion October 2003 [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", RFC 3552, July 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- 01.txt, Work in Progress, October 2003. [12] K. Ono, S. Tachimoto, "End-to-middle security in the Session Initiation Protocol", draft-ono-sipping-end2middle-security-00.txt, Work in Progress, June 2003. [13] Rosenberg, J., "Requirements for Session Policy for the Session Initiation Protocol (SIP)", draft-ietf-sipping-session-policy-req-00 (work in progress), June 2003. Acknowledgements The author would like to thank Kumiko Ono, Cyrus Shaoul and Gonzalo Camarillo for their discussion and support of this topic. Also, thanks to Rohan Mahy for not liking the initial AIIHB proposal (it was really yucky). Author's Address Mary Barnes Nortel Networks 2380 Performance Drive Richardson, TX USA 75082 Phone: 1-972-684-5432 Email: mary.barnes@nortelnetworks.com Barnes Expires - April 2004 [Page 8] SIP Secure Header Insertion October 2003 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 - April 2004 [Page 9]