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]