Internet Draft M. Barnes Document: draft-barnes-sipping-sec-inserted-info-02.txt Nortel Category: Informational Expires: April 22, 2005 Oct. 22 2004 A Mechanism to Secure SIP information inserted by Intermediaries Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 April 22nd, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft discusses 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. The requirements are based on the need for 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. Barnes Expires – April 2005 [Page 1] SIP Secure Header Insertion October 2004 Table of Contents 1. Background.....................................................3 2. Requirements Summary...........................................5 3. Solution Considerations and Options............................6 3.1 SIP Identity...............................................6 3.2 Adding Message Bodies......................................7 4. Detailed Solution Description..................................7 5. Examples.......................................................7 6. Receiving Secured Information in a Request.....................7 7. Secured Information in Responses...............................8 8. Security Considerations........................................8 Informative References............................................8 Full Copyright Statement..........................................9 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 [SIPHISTI], 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] describes the security services required for the SIP protocol in terms of addressing the end-to-end and hop-by-hop (TLS) security requirements. As identified in the End-to-Middle Security requirements [SIPE2MRQ], 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 Request or Response by an intermediary, used by another intermediary. It also addresses the middle-to-end security problem of ensuring the Barnes Expires - April 2005 [Page 2] SIP Secure Header Insertion October 2004 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. 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 trusts 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 [SIPSPCRQ], 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. Visited network +---------------------+ | +-----+ +-----+ | +-----+ +-----+ +-----+ User#1 -->| | H1 |---->| * |---->| H1' | | | | H1'| | | | | | | | H2 |---->| * |---->| H2 | | +-----+ +-----+ | +-----+ +-----+ +-----+ | UA#1 Proxy A | Proxy#1 Proxy#2 UA#2 Barnes Expires - April 2005 [Page 3] SIP Secure Header Insertion October 2004 +---------------------+ 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 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'. Barnes Expires - April 2005 [Page 4] SIP Secure Header Insertion October 2004 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: 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. Barnes Expires - April 2005 [Page 5] SIP Secure Header Insertion October 2004 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: This section is currently preliminary, but is intended to capture some of the relevant discussion of options from IETF-60 around the applicability of the updated Identity proposal and the adding message bodies proposal.] 3.1 SIP Identity As mentioned previously, the SIP Identity [SIPATHID] solution provides end-to-end security of identity related information. It proposes a way to distribute cryptographically-secure authenticated identities. The end-to-end security appears to make it an unacceptable alternative for securing identity related information inserted by intermediaries. However, consideration and application of some fundamental SIP functionality (per [RFC3261]) can make it a much more attractive option. Following along the lines of the current specification in [RFC 3261] on determining request targets, which specifies that retargeting is only applicable if the Request-URI reflects a domain for which the element is responsible, per the following excerpt from [RFC3261] "If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding". the current specification is sufficient in that it provides flexibility in implementation, while still ensuring that retargeting occurs only in specific situations. In the scenarios where a request has been retargeted and the domain to which it is being forwarded is not one for which the forwarding intermediary is responsible, any request that has been retargeted MUST be redirected back to the originating UAC. This will then allow the UAC to secure the information added by the intermediary end-to-end, thus using basic SIP functionality to obviate the need for any new functionality at the intermediaries. This proposal does seem to put a large burden on points of inter- working and the UAC, rather than the intermediary and it may be difficult to make backwards compatible. However, it should be recognized that this scenario in the case of History-Info is a corner case and not the most likely one involving History-Info, thus impact is likely less than perceived. However, the impact on the current SIP identity related headers would be a bit higher. The most Barnes Expires - April 2005 [Page 6] SIP Secure Header Insertion October 2004 important advantage of this approach is that it obviates the need for intermediary involvement and a transitive trust model. 3.2 Adding Message Bodies Another proposal [SIPADDBD] proposes to "relax" the restriction that proxies cannot add message bodies to allow securing of information added by intermediaries. This would provide a general purpose mechanism, thus avoiding the requirement to define P-headers for cases where this functionality is useful. This proposal doesn't entirely resolve the "robust" security problem for History-Info, as another intermediary needs to unpack the information in order to access the index per the transitive model introduced in section 1. However, this approach does facilitate inter-working in terms of standardizing the approach, so that alternative proprietary implementations would no longer be needed to cover the scenarios. 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 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 2005 [Page 7] SIP Secure Header Insertion October 2004 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 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. Informative References [RFC3261] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261, June, 2002. [SIPATHID] J. Peterson, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip- identity-03.txt, Work in Progress, September 2004. [SIPBDADD] R. Mahy, "SIP Body Addition", draft-mahy-sipping-body-add- 00.txt, July, 2004. [SIPE2MRQ] K. Ono, S. Tachimoto, "Requirements for End-to-Middle Security for the Session Initiation Protocol", draft-ietf-sipping- e2m-sec-reqs-04.txt, Work in Progress, October, 2004. [SIPHISTI] M. Barnes, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", draft-ietf-sip- history-info-04.txt, Work in Progress, October 2004. [SIPSPCRQ] J. Rosenberg, "Requirements for Session Policy for the Session Initiation Protocol (SIP)", draft-ietf-sipping-session- policy-req-02 (work in progress), July 2004. Barnes Expires - April 2005 [Page 8] SIP Secure Header Insertion October 2004 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. Author's Address Mary Barnes Nortel Networks 2380 Performance Drive Richardson, TX USA 75082 Phone: 1-972-684-5432 Email: mary.barnes@nortelnetworks.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and 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 which may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr.org. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. Barnes Expires - April 2005 [Page 9] SIP Secure Header Insertion October 2004 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. Barnes Expires - April 2005 [Page 10]