Network Working Group S. Schubert Internet-Draft sip101 Intended status: Standards Track October 15, 2006 Expires: April 18, 2007 Requirements for Header Integrity Protection for the Session Initiation Protocol (SIP) draft-schubert-sipping-header-integrity-reqs-00.txt 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 April 18, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document lays out a set of requirements related to integrity protection over the headers for the Session Initiation Protocol (SIP). While mechanism such as SIP-Identity and S/MIME may be used to provide integrity protection between the end-points, it can not provide integrity protections over some of the headers which may benefit from having an integrity protection. Schubert Expires April 18, 2007 [Page 1] Internet-Draft Requirements for Header October 2006 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Possible Solution . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. Normative Reference . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 6 Schubert Expires April 18, 2007 [Page 2] Internet-Draft Requirements for Header October 2006 1. Requirements notation 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[1]. 2. Introduction This document explores requirements of the Session Initiation Protocol (SIP) [2] for enabling integrity protection over the SIP headers. This effort stems from the recent specifications that are looking into using the SIP header as a way to reference a resource which may be located outside of the requestor's domain(e.g. location conveyance). Any other information placed in the SIP headers used for routing but is desirably protected for its integrity end-to-end may benefit from this specification as well. SIP-Identity[3] can be used to provide integrity protection over the message body and some of the headers but it can not selectively choose the headers to be protected. S/MIME can alos be used to provide integrity protection over the body and with the use of SIPfrag can even provide protection over the selected headers, but due to its complexity and lack of deployments it is not likely to be a solution anytime soon. This document lays out a set of requirements for providing integrity protection over selected headers and provides a quick overview of the solution in mind. 3. Requirements Followings are some of the numbers describing the SIPPING WG. Req 1: The mechanism MUST support a way to provide an integrity protection over the SIP headers in SIP requests. Req 2: The mechanism MUST allow SIP UACs to indicate to an authentication service those SIP headers that need to be protected for its integrity. The mechanism SHOULD also provide a way for SIP intermediaries to recognize that an integrity protection will be needed, and either forward requests to an authentication service themselves or notify the UAC of the need to do so. Schubert Expires April 18, 2007 [Page 3] Internet-Draft Requirements for Header October 2006 Req 3: The mechanism MUST allow SIP UACs to indicate to an authenticatino service whether it desires integrity protection or not. Req 4: Authenticatino services MUST have a way to authenticate SIP UAC. Req 5: Intermediaries and UAS MUST have a way to verify the integrity of the SIP headers that are indicated protected. Req 6: The mechanism MUST have a single baseline mandatory-to- include-headers/message-body-part to make sure it covers enough information that the assertin cannot be replayed. Req 7: It MUST be possible for a UAS or proxy server to reject a request that does not verify in its verification process and inform the sending UAC that it must resend the request or send it without the integrity protection. Req 8: he recipient of a request MUST be able to ascertain which authentication service and domain provided the integrity protection. 4. Possible Solution The idea is to do sip-identity over the headers which UAC desires integrity protection. 1: UAC would indicate the headers to be protected in a new header which lists the target headers to be protected and forward the message to an authentication service. 2: The authentication service authenticates the UAC and generates a signature over the target headers indicated in the new SIP header and other mandatory-to-incude message parts. 3: The authentication service inserts the signature in yet another new SIP header and includes identity-info header with the location of certificate used to generate a signature. 4: The UAS or proxy receiving the message would verify the signature as it would with SIP-Identity, with an exception of its need to look up the new header for the headers to include in its computation of signature for verification. 5. Security Considerations TBD. 6. IANA Considerations There is no IANA Considerations. Schubert Expires April 18, 2007 [Page 4] Internet-Draft Requirements for Header October 2006 7. Normative Reference [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Peterson, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Jennings, C. and J. Peterson, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, Aug 2006. Author's Address Shida Schubert SIP101 1094 15 Ave W Vancouver, BC V6H 1R6 Canada Phone: +1 604 762 5606 Email: shida@sip101.net URI: http://www.sip101.net/ Schubert Expires April 18, 2007 [Page 5] Internet-Draft Requirements for Header October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Schubert Expires April 18, 2007 [Page 6]