SIPPING M. Munakata
Internet-Draft S. Schubert
Intended status: Informational T. Ohba
Expires: April 15, 2007 NTT
October 15, 2006
Clarification of Privacy Mechanism for SIP
draft-munakata-sipping-privacy-clarified-00
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 15, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document is an informational RFC to clarify the use of privacy
mechanism for Session Initiation Protocol (SIP) that is specified in
RFC 3323 and extended in subsequent RFCs, such as RFC 3325. It is
intended to clarify the semantics of each privacy header value
(priv-value) and the handling of the relevant target SIP headers
for each of the priv-value. It also provides some guidelines on
providing privacy considerations for future specifications that
define SIP headers which may be influenced by the privacy mechanism.
Munakata, et al. Expires April 15, 2007 [Page 1]
Internet-Draft Clarification of Privacy Mechanism for SIP October 2006
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Clarification of the existing privacy mechanism .................3
3.1. Clarification of the existing priv-values ..................4
3.2. Target for each priv-value .................................5
4. Guidelines on the privacy considerations for future RFCs ........6
4.1. Guidelines on considering the impact of the
existing privacy mechanism to future SIP headers ...........6
4.2. Guidelines on specifying new priv-values ...................6
5. Security Considerations .........................................7
6. IANA Considerations .............................................7
7. Normative References ............................................7
1. Introduction
This document clarifies the privacy mechanism for Session Initiation
Protocol (SIP) [2] defined in RFC 3323 [3] and extended in RFCs 3325
[4] and 4244 [5]. It describes the practical manner of operations of
the privacy mechanism as BCP (Best Current Practice) and has no
intention to change the existing definitions of the privacy mechanism.
In RFC 3323, the semantics of basic set of priv-values (header,
session, user, none, and critical) is defined, but it has some
ambiguities. Moreover, the target headers to be obscured per priv-
value are not explicitly specified. These ambiguities may result in
different interpretations of header handling per priv-value at an
entity who sets a Privacy header and at an entity who processes the
Privacy header, which could lead to an adverse impact on
interoperability.
Additional priv-values, "id" and "history", are defined in RFCs 3325
and 4244 respectively.
In RFC 4244 that defines History-Info header, the priv-value of
"history" is defined in order to request privacy on History-Info
headers, and the target to be obscured for "history" privacy is
specified as History-Info headers alone. In addition, the RFC
clearly describes that History-Info headers are also the target when
"header" and "session" privacy are requested.
On the other hand, RFC 3325 defines P-Asserted-Identity header and a
priv-value of "id", which is used to request privacy manipulation on
the P-Asserted-Identity headers alone, but it does not specify how
other priv-values may impact the privacy handling of P-Asserted-
Identity header. Because of this implicitness, it has been observed
that some implementations are suffering from the inability to realize
the intended privacy due to the discrepancy of interpretations.
Munakata, et al. Expires April 15, 2007 [Page 2]
Internet-Draft Clarification of Privacy Mechanism for SIP October 2006
This document tries to clarify the target to be obscured among the
existing SIP headers for each of the priv-value. It also offers
guidelines on providing privacy considerations in the future draft
and RFC that defines a new SIP header imposing a privacy implication.
2. Terminology
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].
priv-value: Values registered with IANA defined to be used in Privacy
header. The existing priv-values are "header", "session",
"user", "none", and "critical" defined in RFC 3323 [3],
"id" defined in RFC 3325 [4], and "history" defined in
RFC 4244 [5].
3. Clarification of the existing privacy mechanism
This section describes the semantics of each priv-value according to
the existing privacy mechanism documents, RFCs 3323 [3], 3325 [4],
and 4244 [5], and organizes the target to be obscured among the
existing SIP headers.
3.1. Clarification of the existing priv-values
This section tries to provide clear semantics on each of the priv-
value defined in RFCs 3323, 3325, and 4244. The first sentence of
each definition is taken from the description registered with IANA.
The rest of the definition is extracts from the RFCs and it needs
more clarification.
priv-value (RFC) Outline of definitions
user (3323) Request that privacy services provide a user-level
privacy function. This privacy level is usually
set only by intermediaries, in order to communicate
that user level privacy functions must be provided
by the network, presumably because the user agent
is unable to provide them. The privacy service
must remove any non-essential informational headers
that have been added by the user agent.
Munakata, et al. Expires April 15, 2007 [Page 3]
Internet-Draft Clarification of Privacy Mechanism for SIP October 2006
header (3323) Request that privacy services modify headers that
cannot be set arbitrarily by the user (Contact/Via).
The user requests that a privacy service obscure
those headers which cannot be completely expunged
of identifying information without the assistance
of intermediaries (such as Via and Contact). Also,
no unnecessary headers should be added by the
service that might reveal personal information
about the originator of the request.
session (3323) Request that privacy services provide privacy for
session media. The user requests that a privacy
service provide anonymization for the session(s)
(described, for example, in a Session Description
Protocol [6] body) initiated by this message. This
will mask the IP address from which the session
traffic would ordinarily appear to originate.
none (3323) Privacy services must not perform any privacy
function. The user requests that a privacy service
apply no privacy functions to this message. The
privacy services must not perform any privacy
function and must not remove or modify the Privacy
header.
critical (3323) Privacy service must perform the specified services
or fail the request. The user asserts that the
privacy services requested for this message are
critical. If the privacy service is incapable of
performing all of the levels of privacy specified
in the Privacy header then the privacy service must
fail the request with a 500 (Server Error) response
code.
id (3325) Privacy requested for Third-Party Asserted Identity.
It indicates that the Network Asserted Identity to
be kept private. Proxy must remove all the P-
Asserted-Identity header fields before forwarding
messages to elements that are not trusted.
history (4244) Privacy requested for History-Info header(s). It
indicates that a specific or all History-Info
headers should not be forwarded. Proxy should
remove any hi-entry(s) prior to forwarding to
domain for which the proxy is not responsible,
depending upon local policy.
Note: Where each privacy service is executed is out of scope. It
depends on implementations and network policy.
Munakata, et al. Expires April 15, 2007 [Page 4]
Internet-Draft Clarification of Privacy Mechanism for SIP October 2006
3.2. Target for each priv-value
Table 1 below shows the recommended behaviors of proxies who
accomplish the privacy service when each of the priv-value is set in
a Privacy header in the request. The other existing SIP headers that
are not shown in Table 1 are regarded as a non-target of these priv-
values.
Note 1: The scope of the target in this document is only SIP headers.
SDP, RTP and other parameters are out of scope.
Note 2: This is just a recommendation and the detailed behaviors are
dependent upon implementations and network policy.
Note 3: This clarification does not prevent proxies to manipulate
other headers depending on the local policy.
Note 4: The behaviors without question mark are specified in RFCs
3323, 3325, and 4244. The behaviors with question mark need
discussions.
Note 5: There may be more headers to be included in this table.
Further study will be necessary.
Target headers user header session id history
From modify
Contact modify
Reply-To delete
Via strip*
Call-Info delete not add
User-Agent delete
Organization delete not add
Server not add
Subject delete
Call-ID modify
In-Reply-To delete
Warning modify?
Record-Route strip*
P-Asserted-Identity delete
History-Info not add not add delete
Path strip*?
Referred-By modify?
Replaces modify?
Service-Route strip*?
Target-Dialog modify?
Table 1: Recommended proxy behaviors for each priv-value
Munakata, et al. Expires April 15, 2007 [Page 5]
Internet-Draft Clarification of Privacy Mechanism for SIP October 2006
*strip: Privacy services operating on requests should remove all
Via/Record-Route/Path/Service-Route headers that have been
added to the request prior to its arrival at the privacy
service and then should add a single Via/Record-Route/Path/
Service-Route header representing themselves.
4. Guidelines on providing the privacy considerations for future RFCs.
This section gives the guidelines on providing the privacy
considerations when new SIP headers and/or new priv-values will be
defined in the future.
4.1. Guidelines on considering the impact of the existing privacy
mechanism to future SIP headers
Whenever a new SIP header is defined in the future, it MUST be
considered whether the new header is a target of the existing privacy
mechanism. If the header is considered to be a target of any one of
the priv-values, the privacy considerations SHOULD be included in the
document that defines the new header. The privacy considerations
need to clearly specify the impact of the relevant priv-values for
the new header, including which priv-value results in manipulation of
the new header as well as the actual manipulations recommended to the
new header by proxy providing privacy services. Without the privacy
consideration descriptions, it is regarded that the new header is not
a target of any existing priv-values.
The example text for privacy considerations is as follows.
A UAC that wants to request the removal of XXX header due to
privacy considerations SHOULD include a Privacy header with a
priv-value(s) of "session" and/or "header" in the request. If a
priv-value(s) of "session" and/or "header" is present in a Privacy
header, proxies MUST remove the XXX header field before forwarding
the request to a UAS.
4.2. Guidelines on specifying new priv-values
Whenever a new priv-value is defined in the future, the target
headers MUST be clearly specified. The existing SIP headers that are
not specified as the target are regarded as a non-target of the new
priv-value.
Note: Unless new privacy mechanism is required to obscure specific
SIP header(s), it is RECOMMENDED to use existing priv-values
and avoid defining a new priv-value.
Munakata, et al. Expires April 15, 2007 [Page 6]
Internet-Draft Clarification of Privacy Mechanism for SIP October 2006
The example text for defining a new priv-value is as follows.
A UAC who wants to request the removal of XXX header field before
it is transmitted to a UAS MAY include a Privacy header in the
request with a priv-value of "xxx" defined in this document. If
this priv-value "xxx" is present in a Privacy header, proxies MUST
remove the XXX header field before forwarding the request to a UAS.
5. Security Considerations
This document adds no new security considerations to those discussed
in RFCs 3323 [3], 3325 [4], and 4244 [5].
6. IANA Considerations
This document requires no action by IANA.
7. Normative References
[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., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[5] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244, November 2005.
[6] Handley, M., Jacobson, V., C. Perkins, "SDP: Session Description
Protocol", RFC 4566, July 2006.
Munakata, et al. Expires April 15, 2007 [Page 7]
Internet-Draft Clarification of Privacy Mechanism for SIP October 2006
Authors' Addresses
Mayumi Munakata
NTT Corporation
Phone: +81 422 36 7565
EMail: munakata.mayumi at lab.ntt.co.jp
Shida Schubert
NTT Corporation
Phone: +1 604 762 5606
EMail: shida at ntt-at.com
Takumi Ohba
NTT Corporation
9-11, Midori-cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7748
EMail: ohba.takumi at lab.ntt.co.jp
URI: http://www.ntt.co.jp
Munakata, et al. Expires April 15, 2007 [Page 8]
Internet-Draft Clarification of Privacy Mechanism for SIP October 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Munakata, et al. Expires April 15, 2007 [Page 9]