Guidelines for Using the Privacy Mechanism for SIP
draft-munakata-sip-privacy-guideline-04
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5379.
|
|
|---|---|---|---|
| Authors | Mayumi Munakata , Takumi Ohba , Shida Schubert | ||
| Last updated | 2022-02-10 (Latest revision 2008-09-25) | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | ISE state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5379 (Informational) | |
| Action Holders |
(None)
|
||
| Telechat date | (None) | ||
| Responsible AD | Jon Peterson | ||
| Send notices to | (None) |
draft-munakata-sip-privacy-guideline-04
Internet Engineering Task Force M. Munakata
Internet-Draft S. Schubert
Intended status: Informational T. Ohba
Expires: March 30, 2009 NTT
September 26, 2008
Guidelines for Using the Privacy Mechanism for SIP
draft-munakata-sip-privacy-guideline-04
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 March 30, 2009.
Abstract
This is an informational document that provides guidelines for using
the privacy mechanism for Session Initiation Protocol (SIP), that is
specified in RFC 3323 and subsequently extended in RFCs 3325 and
4244. It is intended to clarify the handling of the target SIP
headers/parameters and SDP parameters for each of the privacy header
values (priv-values).
Munakata, et al. Expires March 30, 2009 [Page 1]
Internet-Draft SIP Privacy Guideline September 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Semantics of Existing priv-values . . . . . . . . . . . . . . 4
4. Target for Each priv-value . . . . . . . . . . . . . . . . . . 5
4.1. Target SIP Headers for Each priv-value . . . . . . . . . . 5
4.2. Target SDP Parameters for Each priv-value . . . . . . . . 7
4.3. Treatment of priv-value Not Supported by the Privacy
Service . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Recommended Treatment of User-Privacy-Sensitive Information . 7
5.1. Target SIP Headers . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Call-ID . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.2. Call-Info . . . . . . . . . . . . . . . . . . . . . . 8
5.1.3. Contact . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.4. From . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.5. History-Info . . . . . . . . . . . . . . . . . . . . . 10
5.1.6. In-Reply-To . . . . . . . . . . . . . . . . . . . . . 10
5.1.7. Organization . . . . . . . . . . . . . . . . . . . . . 11
5.1.8. P-Asserted-Identity . . . . . . . . . . . . . . . . . 11
5.1.9. Record-Route . . . . . . . . . . . . . . . . . . . . . 12
5.1.10. Referred-By . . . . . . . . . . . . . . . . . . . . . 14
5.1.11. Reply-To . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.12. Server . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.13. Subject . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.14. User-Agent . . . . . . . . . . . . . . . . . . . . . . 16
5.1.15. Via . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.16. Warning . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Target SDP Parameters . . . . . . . . . . . . . . . . . . 17
5.2.1. c/m Lines . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2. o Line . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.3. i/u/e/p Lines . . . . . . . . . . . . . . . . . . . . 18
5.3. Considerations for Non-Target SIP Headers/Parameters . . . 18
5.3.1. Identity/Identity-Info . . . . . . . . . . . . . . . . 18
5.3.2. Path . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.3. Replaces Header/Parameter . . . . . . . . . . . . . . 19
5.3.4. Route . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3.5. Service-Route . . . . . . . . . . . . . . . . . . . . 22
5.3.6. Target-Dialog . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Munakata, et al. Expires March 30, 2009 [Page 2]
Internet-Draft SIP Privacy Guideline September 2008
1. Introduction
This document clarifies the privacy mechanism for Session Initiation
Protocol (SIP) [RFC3261] defined in [RFC3323], which was later
extended in [RFC3325] and [RFC4244]. This document describes the
practical manner of operations of the privacy mechanism as a
guideline and does not change the existing privacy mechanism.
In RFC 3323, the semantics of the basic set of priv-values (header,
session, user, none, and critical) is defined, but there are some
ambiguities, in regards to the target information to be obscured per
priv-value, which are not explicitly specified. An ambiguity such as
this could result in different interpretations of privacy handling
for each of the priv-values defined, both at an entity setting a
Privacy header and at an entity processing the Privacy header, which
could have an adverse impact on interoperability.
Additional priv-values, "id" and "history", are defined in RFCs 3325
and 4244, respectively.
In RFC 4244, the priv-value "history" is defined in order to request
privacy for History-Info headers, and the target to be obscured for
"history" priv-value is specified as only the History-Info headers.
In addition, the RFC clearly describes that History-Info headers are
also the target when "header" and "session" level privacy are
requested.
On the other hand, RFC 3325 defines the P-Asserted-Identity header
and a priv-value "id", which is used to request privacy for only the
P-Asserted-Identity header, but it does not specify how other priv-
values may impact the privacy handling of the P-Asserted-Identity
header. Because of this lack of specification, it has been observed
that some implementations are suffering from the inability to achieve
the intended privacy due to discrepancies in interpretations.
This document tries to clarify the SIP headers and SDP parameters to
be obscured for each of the priv-values to alleviate the potential
interoperability issues already seen due to a lack of explicit text.
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 [RFC2119].
Munakata, et al. Expires March 30, 2009 [Page 3]
Internet-Draft SIP Privacy Guideline September 2008
Note: This document is an informational, therefore, it does not
specify any new normative behaviors of privacy mechanism. All
the RFC 2119 language in this document is derived from the
normative text in the existing RFCs such as RFC 3323.
priv-value: Values registered with IANA to be used in the Privacy
header. Registered priv-values are "header", "session",
"user", "none", and "critical" defined in [RFC3323], "id"
defined in [RFC3325], and "history" defined in [RFC4244].
privacy service:
A network entity that executes privacy functions before
forwarding messages to the next hop. It is sometimes
abbreviated to PS in this document.
user-level privacy:
Privacy for user-inserted information that can be
anonymized by the user agent itself.
3. Semantics of Existing priv-values
This section provides the semantics of each priv-value defined in
RFCs 3323, 3325, and 4244. The descriptions are taken from the IANA
registration.
Privacy Type Description Reference
------------- ---------------------------------- ----------
user Request that privacy services [RFC3323]
provide a user-level privacy function
header Request that privacy services modify [RFC3323]
headers that cannot be set arbitrarily
by the user (Contact/Via).
session Request that privacy services provide [RFC3323]
privacy for session media
none Privacy services must not perform any [RFC3323]
privacy function
critical Privacy service must perform the [RFC3323]
specified services or fail the request
id Privacy requested for Third-Party [RFC3325]
Asserted Identity
Munakata, et al. Expires March 30, 2009 [Page 4]
Internet-Draft SIP Privacy Guideline September 2008
history Privacy requested for [RFC4244]
History-Info header(s)
4. Target for Each priv-value
Tables in this section show the recommended treatment of SIP headers
and SDP parameters per priv-value. SIP headers and SDP parameters
not shown in the tables are regarded as non-targets of these priv-
values. Some non-target SIP headers/SDP parameters may carry
privacy-sensitive information which may need privacy treatment
regardless of the privacy level requested. This is further described
in 6.4.
The way in which SIP headers and SDP parameters listed here are
obscured may depend on the implementation and network policy. This
document does not prevent different variations that may exist based
on local policy but tries to provide recommendations for how a
privacy service treats SIP headers and SDP parameters.
Note: The scope of these tables is SIP headers and related parameters
specified in RFCs.
4.1. Target SIP Headers for Each priv-value
Table 1 below shows a recommended treatment of each SIP header for
each priv-value. Detailed descriptions of the recommended treatment
per SIP header are covered in Section 5.
The "where" column describes the request and response types in which
the header needs the treatment to maintain privacy. Values in this
column are:
R: The header needs the treatment when it appears in a request;
r: The header needs the treatment when it appears in a response.
The next five columns show the recommended treatment for each priv-
value:
delete: The header is recommended to be deleted at a privacy
service.
not add: The header is recommended not to be added at a privacy
service.
Munakata, et al. Expires March 30, 2009 [Page 5]
Internet-Draft SIP Privacy Guideline September 2008
anonymize: The header is recommended to be anonymized at a
privacy service. How to anonymize the header depends
on the header. Details are given in Section 5.
anonymize*: An asterisk indicates that the involvement of a
privacy service and treatment of the relevant header
depends on the circumstance. Details are given in
Section 5.
Target headers where user header session id history
----------------------------------------------------------------------
Call-ID (Note) R anonymize - - - -
Call-Info Rr delete not add - - -
Contact R - anonymize - - -
From R anonymize - - - -
History-Info Rr - delete delete - delete
In-Reply-To R delete - - - -
Organization Rr delete not add - - -
P-Asserted-Identity Rr - delete - delete -
Record-Route Rr - anonymize - - -
Referred-By R anonymize* - - - -
Reply-To Rr delete - - - -
Server r delete not add - - -
Subject R delete - - - -
User-Agent R delete - - - -
Via R - anonymize - - -
Warning r anonymize - - - -
Table 1: Recommended PS behavior for each SIP header
Note: Any time a privacy service modifies a Call-ID, it MUST retain
the former and modified values as indicated in Section 5.3 in
RFC 3323. It MUST then restore the former value in a Call-ID
header, other corresponding headers and parameters(such as In-
Reply-To, Replaces, and Target-Dialog) in any messages that are
sent using the modified Call-ID to the originating user agent.
It should also modify a Call-ID header and other corresponding
headers/parameters (such as Target-Dialog and "replaces"
parameter) in any further relevant messages that are sent by
the originating user agent. Refer to Section 5.1.1 (Call-ID)
for the detailed behavior.
Path, Replaces, Route, Service-Route, and Target-Dialog headers are
not targets of these priv-values (and should not be anonymized or
modified by a user agent and a privacy service based on a priv-value
in a Privacy header). Refer to Section 5.3 for details.
Munakata, et al. Expires March 30, 2009 [Page 6]
Internet-Draft SIP Privacy Guideline September 2008
4.2. Target SDP Parameters for Each priv-value
The recommended PS behaviors for each SDP parameters are simple. The
c, m, o, i, u, e, and p-lines in SIP request/response are recommended
to be anonymized when user privacy is requested with Privacy:session.
4.3. Treatment of priv-value Not Supported by the Privacy Service
As specified in RFC 3323, if the priv-value of "critical" is present
in the Privacy header of a request, and if the privacy service is
incapable of performing all of the levels of privacy specified in the
Privacy header, it MUST fail the request with a 500 (Server Error)
response code as indicated in Section 5 in RFC 3323.
Since the protection of privacy is important, even if the priv-value
"critical" is not present in the Privacy header, the privacy service
should fail the request with a 500 response code when it is incapable
of performing all of the levels of privacy specified in the Privacy
header.
5. Recommended Treatment of User-Privacy-Sensitive Information
The following SIP headers and related parameters may concern privacy.
This section describes what kind of user-privacy-sensitive
information may be included in each SIP header/parameter, and how to
maintain privacy for such information at a user agent or a privacy
service when the information is indeed privacy sensitive.
5.1. Target SIP Headers
This section describes privacy considerations and recommended
treatment for each SIP header that may reveal user-privacy-sensitive
information. This section goes into details about how each header
affects privacy, the desired treatment of the value by the user agent
and privacy service, and other instructions/additional notes
necessary to provide privacy.
5.1.1. Call-ID
This field frequently contains an IP address or hostname of a UAC
(User Agent Client) appended to the Call-ID value.
A user agent executing a user-level privacy function on its own
SHOULD substitute for the IP address or hostname that is frequently
appended to the Call-ID value a suitably long random value (the value
used as the 'tag' for the From header of the request might even be
reused) as indicated in Section 4.1 in RFC 3323
Munakata, et al. Expires March 30, 2009 [Page 7]
Internet-Draft SIP Privacy Guideline September 2008
A privacy service MAY anonymize the Call-ID header when the request
contains Privacy:user by substituting for the IP address or hostname
in the Call-ID a suitably long random value (such as a From tag
value) so that it is sufficiently unique as indicated in Section 5.3
in RFC 3323.
Call-ID is essential to dialog matching, so any time a privacy
service modifies this field, it MUST retain the former value and
restore it in a Call-ID header in any messages that are sent to/by
the originating user agent inside the dialog as indicated in Section
5.3 in RFC 3323. A privacy service should be prepared to receive a
request outside the dialog containing the value of the Call-ID set by
the PS in other SIP headers (e.g., In-Reply-To/Replaces/
Target-Dialog), at least while the dialog state is active for the
dialog whose Call-ID was modified by that PS. When such a request is
received, the Call-ID value contained in the relevant headers
indicated above should be replaced by the retained value.
Note: This is possible only if the privacy service maintains the
state and retains all the information it modified to provide
privacy. Some PSs are known to encrypt information prior to
obfuscation in the Via header etc. In this case, the PS cannot
correlate the modified Call-ID value with the original Call-ID.
Further challenges are imposed when the PS needs to stay on a
signaling path to ensure that it receives all the messages
targeted towards the caller that a PS provides privacy for,
especially when the request is out-of-dialog.
Refer to the corresponding sections, 5.1.6 (In-Reply-To), 5.3.3
(Replaces), and 5.3.6 (Target-Dialog), for detailed discussion.
5.1.2. Call-Info
This field contains additional information about the user.
A user agent executing a user-level privacy function on its own
SHOULD NOT add a Call-Info header as indicated in Section 4.1 in RFC
3323.
A privacy service MUST delete a Call-Info header if one exists when
user privacy is requested with Privacy:user as indicated in Section
5.3 in RFC 3323. A privacy service SHOULD NOT add a Call-Info header
when user privacy is requested with Privacy:header as indicated in
Section 5.1 in RFC 3323.
Munakata, et al. Expires March 30, 2009 [Page 8]
Internet-Draft SIP Privacy Guideline September 2008
5.1.3. Contact
This field contains a URI used to reach the user agent for mid-dialog
requests and possibly out-of-dialog requests, such as REFER
[RFC3315]. Since the Contact header is essential for routing further
requests to the user agent, it must include a functional URI even
when it is anonymized.
A user agent MUST NOT anonymize a Contact header, unless it can
obtain an IP address or contact address that is functional yet has
characteristic of anonymity as indicated in Section 4.1.1.3 in RFC
3323.
Since RFC 3323 was published there have been proposals that allows UA
to obtain an IP address or contact address with a characteristic of
anonymity.
The mechanisms that are discussed at the time of this writing are
GRUU [I-D.ietf-sip-gruu] which provides a functional Contact address
with a short life span making it ideal for privacy sensitive call,
and TURN [I-D.ietf-behave-turn], through which an IP address of a
relay can be obtained for use in Contact header.
A privacy service SHOULD anonymize a Contact header by replacing the
existing Contact header field value with the URI that dereference to
the privacy service when user privacy is requested with Privacy:
header as indicated in Section 5.1 in RFC 3323. This is generally
done by replacing the IP address or host name with that of the
privacy service.
5.1.4. From
This field contains the identity of the user, such as display-name
and URI.
A user agent executing a user-level privacy function on its own
SHOULD anonymize a From header using an anonymous display-name and an
anonymous URI as indicated in Section 4.1 in RFC 3323.
A privacy service should anonymize a From header when user privacy is
requested with Privacy:user.
Note: This does not prevent a privacy service from anonymizing the
From header based on local policy.
The anonymous display-name and anonymous URI mentioned in this
section use display-name "Anonymous" and a URI with "anonymous" in
the user portion of the From header and the hostname value
Munakata, et al. Expires March 30, 2009 [Page 9]
Internet-Draft SIP Privacy Guideline September 2008
"anonymous.invalid", as indicated in Section 4.1.1.3 in RFC 3323.
The recommended form of the From header for anonymity is:
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
The tag value varies from dialog to dialog, but the rest of this
header form is recommended as shown.
5.1.5. History-Info
History-Info [RFC4244] header URIs to which the request was forwarded
or retargeted can reveal general routing information.
A user agent executing a user-level privacy function on its own
SHOULD NOT add a History-Info header as indicated in Section 3.3 in
RFC 4244.
A privacy service SHOULD delete the History-Info headers when user
privacy is requested with Privacy:header, Privacy:session, or
Privacy:history as indicated in Section 3.3 in RFC 4244.
The privacy could be also expressed for a specific History-Info entry
by inserting "privacy=history" in the History-Info header. In such a
case, a privacy service SHOULD delete the History-Info entry as
indicated in Section 4.3.3.1.1 in RFC 3323.
Refer to [RFC4244] for detailed behavior for dealing with History-
Info headers.
5.1.6. In-Reply-To
The In-Reply-To header contains a Call-ID of the referenced dialog.
The replying user may be identified by the Call-ID in an In-Reply-To
header.
Alice > INV(Call-ID:C1) > Bob
Bob > INV(In-Reply-To:C1) > Alice
In this case, unless the In-Reply-To header is deleted, Alice might
notice that the replying user is Bob because Alice's UA knows that
the Call-ID relates to Bob.
A user agent executing a user-level privacy function on its own
should not add an In-Reply-To header as implied in Section 4.1 in RFC
3323.
A privacy service MUST delete the In-Reply-To header when user
Munakata, et al. Expires March 30, 2009 [Page 10]
Internet-Draft SIP Privacy Guideline September 2008
privacy is requested with Privacy:user as indicated in Section 5.3 in
RFC 3323.
In addition, since an In-Reply-To header contains the Call-ID of the
dialog it is replying to, special attention is required, as described
in Section 5.1.1 (Call-ID) regardless of the priv-value or presence
of a Privacy header. Once a privacy service modifies a Call-ID in
the request, a privacy service should restore the former value in an
In-Reply-To header, if present in the INVITE request replying to the
original request, as long as the privacy service maintains the dialog
state.
Example:
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > INV(In-Reply-To:C2, Privacy:none) > PS >
INV(In-Reply-To:C1) > Alice
Note: This is possible only if the privacy service maintains the
state and retains all the information that it modified to
provide privacy even after the dialog has been terminated,
which is unlikely. Call-back is difficult to achieve when a
privacy service is involved in forming the dialog to be
referenced.
5.1.7. Organization
This field contains additional information about the user.
A user agent executing a user-level privacy function on its own
should not add an Organization header as implied in Section 4.1 in
RFC 3323.
A privacy service MUST delete the Organization header if one exists
when user privacy is requested with Privacy:user as indicated in
Section 5.3 in RFC 3323. A privacy service SHOULD NOT add an
Organization header when user privacy is requested with Privacy:
header as indicated in Section 5.1 in RFC 3323.
5.1.8. P-Asserted-Identity
This header contains a network-verified and network-asserted identity
of the user sending a SIP message.
A privacy service MUST delete the P-Asserted-Identity headers when
user privacy is requested with Privacy:id as indicated in Section 7
in RFC 3325 and should delete the P-Asserted-Identity headers when
user privacy is requested with Privacy:header before it forwards the
message to an entity that is not trusted.
Munakata, et al. Expires March 30, 2009 [Page 11]
Internet-Draft SIP Privacy Guideline September 2008
It is recommended for a privacy service to remove the P-Asserted-
Identity header if user privacy is requested with Privacy:id or
Privacy:header even when forwarding to a trusted entity unless it can
be confident that the message will not be routed to an untrusted
entity without going through another privacy service.
5.1.9. Record-Route
This field may reveal information about the administrative domain of
the user.
In order to hide Record-Route headers while keeping routability to
the sender, privacy services can execute a practice referred to as
"stripping". Stripping means removing all the Record-Route headers
that have been added to the request prior to its arrival at the
privacy service and then adding a single Record-Route header
representing itself. In this case, the privacy service needs to
retain the removed headers and restore them in a response.
Alternatively, privacy services can remove the Record-Route headers
and encrypt them into a single Record-Route header field. In this
case, the privacy service needs to decrypt the header and restore the
former values in a response.
A privacy service SHOULD strip or encrypt any Record-Route headers
that have been added to a message before it reaches the privacy
service when user privacy is requested with Privacy:header as
indicated in Section 5.1 in RFC 3323.
As in the case of a Call-ID, if a privacy service modifies the
Record-Route headers, it MUST be able to restore Route headers with
retained values as indicated in Section 5.1 in RFC 3323. Some
examples where the restoration of the Route headers is necessary and
unnecessary are given below.
When a UAC (Alice) requires privacy for a request, a privacy service
does not have to restore the Route headers (See Example 1).
On the other hand, when a UAS (User Agent Server) (Bob) requires
privacy for a response, a privacy service has to restore the Route
headers in the response (See Example 2).
Munakata, et al. Expires March 30, 2009 [Page 12]
Internet-Draft SIP Privacy Guideline September 2008
Example 1:
Restoration of Route header is UNNECESSARY when UAC requires privacy
Alice > INV(Privacy:header) > P1 >
INV(Record-Route:P1, Privacy:header) > PS >
INV(Record-Route:PS) > P2 >
INV(Record-Route:P2,PS) > Bob
Bob > 200(Record-Route:P2,PS) > P2 > PS >
200(Record-Route:P2,PS,P1) > P1 > Alice
Alice > re-INV(Route:P2,PS,P1, Privacy:header) > P1 >
re-INV(Route:P2,PS, Privacy:header) > PS >
re-INV(Route:P2) > P2 > re-INV > Bob
Alice P1 PS P2 Bob
| | | | |
| INV Priv |INV Priv RR:P1 | INV RR:PS | INV RR:P2,PS |
|---------------->|---------------->|---------------->|-------------->|
| | | | |
| 200 RR:P2,PS,P1 | 200 RR:P2,PS,P1 | 200 RR:P2,PS | 200 RR:P2,PS |
|<----------------|<----------------|<----------------|<--------------|
| | | | |
| INV R:P2,PS,P1 | INV R:P2,PS | INV R:P2 | INV |
|---------------->|---------------->|---------------->|-------------->|
| | | | |
Figure 1: Example when restoration of Route header is UNNECESSARY
Example 2:
Restoration of Route header is NECESSARY when UAS requires privacy
Alice > INV > P1 > INV(Record-Route:P1) > P2 >
INV(Record-Route:P2,P1) > Bob
Bob > 200(Record-Route:P2,P1, Privacy:header) > P2 > PS' >
200(Record-Route:PS',P1) > P1 > Alice
Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') > PS' >
re-INV(Route:P2) > P2 > Bob
Munakata, et al. Expires March 30, 2009 [Page 13]
Internet-Draft SIP Privacy Guideline September 2008
Alice P1 PS' P2 Bob
| | | | |
| INV |INV RR:P1 | | INV RR:P2,P1 |
|-------------->|---------------------------------->|---------------->|
| | | | |
| 200 RR:PS',P1 | 200 RR:PS',P1 |200 Priv RR:P2,P1|200 Priv RR:P2,P1|
|<--------------|<----------------|<----------------|<----------------|
| | | | |
| INV R:PS',P1 | INV R:PS' | INV R:P2 | INV |
|-------------->|---------------->|---------------->|---------------->|
| | | | |
Figure 2: Example when restoration of Route header is NECESSARY
Note: In Figures 1 and 2, Priv means Privacy:header, RR means Record-
Route header, and R means Route header.
5.1.10. Referred-By
The Referred-By [RFC3892] header carries a SIP URI representing the
identity of the referrer.
The Referred-By header is an anonymization target when the REFER
request with the Referred-By header is sent by the user (referrer)
whose privacy is requested to be processed in the privacy service.
A user agent that constructs REFER requests executing a user-level
privacy function on its own should anonymize a Referred-By header by
using an anonymous URI.
A privacy service should anonymize a Referred-By header in a REFER
request by using an anonymous URI when user privacy is requested with
Privacy:user.
On the other hand, the Referred-By header is not an anonymization
target when it appears in a request other than REFER (e.g., INVITE)
because the URI in the Referred-By header does not represent the
sender of the request.
Munakata, et al. Expires March 30, 2009 [Page 14]
Internet-Draft SIP Privacy Guideline September 2008
Example 1:
Referrer requests no privacy and referee requests privacy
Alice > REF(Referred-By:Alice) > Bob
Bob > INV(Referred-By:Alice, Privacy:user) > PS >
INV(Referred-By:Alice) > Carol
Example 2:
Referrer requests privacy and referee requests privacy
Alice > REF(Referred-By:Alice, Privacy:user) > PS >
REF(Referred-By:X) > Bob
Bob > INV(Referred-By:X, Privacy:user) > PS >
INV(Referred-By:X) > Carol
5.1.11. Reply-To
This field contains a URI that can be used to reach the user on
subsequent call-backs.
A user agent executing a user-level privacy function on its own
should not add a Reply-To header in the message as implied in Section
4.1 in RFC 3323.
A privacy service MUST delete a Reply-To header when user privacy is
requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
5.1.12. Server
This field contains information about the software used by the UAS to
handle the request.
A user agent executing a user-level privacy function on its own
should not add a Server header in the response as implied in Section
4.1 in RFC 3323.
A privacy service must delete a Server header in a response when user
privacy is requested with Privacy:user. A privacy service SHOULD NOT
add a Server header in a response when user privacy is requested with
Privacy:header as indicated in Section 5.1 in RFC 3323.
5.1.13. Subject
This field contains freeform text about the subject of the call. It
may include text describing something about the user.
A user agent executing a user-level privacy function on its own
should not include any information identifying the caller in a
Subject header.
Munakata, et al. Expires March 30, 2009 [Page 15]
Internet-Draft SIP Privacy Guideline September 2008
A privacy service MUST delete a Subject header when user privacy is
requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
5.1.14. User-Agent
This field contains UAC's information.
A user agent executing a user-level privacy function on its own
should not add a User-Agent header as implied in Section 4.1 in RFC
3323.
A privacy service MUST delete a User-Agent header when user privacy
is requested with Privacy:user as indicated in Section 5.3 in RFC
3323.
5.1.15. Via
The bottommost Via header added by a user agent contains the IP
address and port or hostname that are used to reach the user agent
for responses. Via headers added by proxies may reveal information
about the administrative domain of the user.
A user agent MUST NOT anonymize a Via header as indicated in Section
4.1.1.3 in RFC 3323, unless it can obtain an IP address that is
functional yet has characteristic of anonymity. This may be possible
by obtaining an IP address specifically for this purpose either from
the service provider or through feature such as TURN.
A privacy service SHOULD strip or encrypt any Via headers that have
been added prior to reaching the privacy service when user privacy is
requested with Privacy:header as indicated in Section 5.1 in RFC
3323. Refer to Section 5.1.9 (Record-Route) for details of stripping
and encryption.
A privacy service MUST recover the original values of Via headers
when handling a response in order to route the response to the
originator as indicated in Section 5.1 in RFC 3323.
No Via stripping is required when handling responses.
5.1.16. Warning
This field may contain the host name of the UAS.
A user agent executing a user-level privacy function on its own
should not include the host name representing its identity in a
Warning header.
Munakata, et al. Expires March 30, 2009 [Page 16]
Internet-Draft SIP Privacy Guideline September 2008
A privacy service should anonymize a Warning header by deleting the
host name portion (if it represents a UAS's identity) from the header
when user privacy is requested with Privacy:user.
5.2. Target SDP Parameters
This section describes privacy considerations for each SDP [RFC4566]
parameter that may reveal information about the user.
When privacy functions for user-inserted information are requested to
be executed at a privacy service, user agents MUST NOT encrypt SDP
bodies in messages using S/MIME as indicated in Section 4.2 in RFC
3323.
5.2.1. c/m Lines
The c and m lines in the SDP body convey the IP address and port for
receiving media.
A user agent must not anonymize the IP address and port in the c and
m lines, unless it can obtain an IP address that is functional yet
has characteristic of anonymity as implied in Section 4.1.1.3 in RFC
3323. This may be possible by obtaining an IP address specifically
for this purpose either from the service provider or through feature
such as TURN.
A privacy service must anonymize the IP address and port in c and m
lines using a functional anonymous IP address and port when user
privacy is requested with Privacy:session. This is generally done by
replacing the IP address and port present in the SDP with that of a
relay server.
5.2.2. o Line
The username and IP address in this parameter may reveal information
about the user.
A user agent may anonymize the user name in an o line by setting
username to "-" and anonymize the IP address in the o line by
replacing it with a value so that it is sufficiently unique.
A privacy service must anonymize the username and IP address in the o
line by setting the username to "-" and replacing the IP address with
a value so that it is sufficiently unique when user privacy is
requested with Privacy:session.
Munakata, et al. Expires March 30, 2009 [Page 17]
Internet-Draft SIP Privacy Guideline September 2008
5.2.3. i/u/e/p Lines
These lines may contain information about the user.
A user agent executing a session-level privacy function on its own
should not include user's information in the i, u, e, and p lines.
A privacy service should modify the i, u, e, and p lines to delete
the user's identity information when user privacy is requested with
Privacy:session.
5.3. Considerations for Non-Target SIP Headers/Parameters
5.3.1. Identity/Identity-Info
The Identity [RFC4474] header field contains a signature used for
validating the identity. The Identity-Info header field contains a
reference to the certificate of the signer of Identity headers. An
Identity-Info header may reveal information about the administrative
domain of the user.
The signature in an Identity header provides integrity protection
over the From, To, Call-ID, Cseq, Date, and Contact headers and over
the message body. The integrity protection is violated if a privacy
service modifies these headers and/or the message body for the
purpose of user privacy protection.
Once those integrity protected headers (such as From and Call-ID) are
modified, the Identity/Identity-Info header fields are not valid any
more. Thus a privacy service acting on a request for Privacy:user,
Privacy:header or Privacy:session can invalidate integrity protection
provided by an upstream authentication service that has inserted
Identity/Identity-Info header fields. The use of such a privacy
service should be avoided if integrity protect needs to be retained.
Otherwise, if the privacy service invalidates the integrity
protection, it should remove the Identity/Identity-Info header
fields.
An authentication service downstream of the privacy service may add
Identity/Identity-Info header fields if the domain name of the From
header field URI has not been anonymized (e.g.,
'sip:anonymous@example.com') and it is able to authenticate the UAC.
This authenticated yet anonymous From header means "this is a known
user in my domain that I have authenticated, but I am keeping its
identity private" as indicated in Section 12 in RFC 4474.
The desired deployment will have a privacy service located before or
co-located with the identity service; thus, integrity and privacy can
Munakata, et al. Expires March 30, 2009 [Page 18]
Internet-Draft SIP Privacy Guideline September 2008
both be provided seamlessly.
5.3.2. Path
This field may contain information about the administrative domain
and/or the visited domain of the user agent. However, the Path
header is not the target of any priv-values.
Given that Path header [RFC3327] only appears in REGISTER requests/
responses and is essential for call to reach the registered UA in the
visited domain. It serves no purpose to withhold or hide the
information contained in the Path header, rather it is harmful.
The only reason privacy may be considered desirable is if the visited
domain wants to withhold its topology from the home domain of the
user. In doing so, the domain withholding the topology needs to
ensure it provides sufficient information that home domain can route
the call to the visited domain, thus reaching the UA.
However, anonymization of network-privacy-sensitive information is
out of scope.
5.3.3. Replaces Header/Parameter
The Replaces [RFC3891] header and the "replaces" parameter contain
identifiers of a dialog to be replaced, which are composed of
Call-ID, local tag, and remote tag.
The sender of the INVITE with a Replaces header is never the
originating user agent or terminating user agent of the target dialog
to be replaced. Therefore the Call-ID within the Replaces header is
never generated by the sender. Therefore, this header is outside the
anonymization target per priv-value.
The "replaces" parameter, which appears in a Refer-To header in a
REFER request, is not the target of any particular priv-values
either. As described in Section 5.1.1 (Call-ID), regardless of the
priv-value or the presence of a Privacy header, once a privacy
service modifies a Call-ID in the request, it should monitor headers
that may contain Call-ID and restore the portion of the value
representing the modified Call-ID to the original Call-ID value in a
Replaces header received.
The main challenge for this to function properly is that a privacy
service has to be on a signaling path to the originator for every
dialog. This is generally not possible and that results in REFER
request not functioning at all time. This is a trade-off that is
anticipated when privacy is imposed.
Munakata, et al. Expires March 30, 2009 [Page 19]
Internet-Draft SIP Privacy Guideline September 2008
The privacy requirements mentioned in section 5.1.1 will cause the
Replaces header and "replaces" parameter to contain values which will
fail the resulting dialog establishment in some situations, and this
loss of functionality is allowed and/or intended as illustrated
above. (i.e., it is not the responsibility of a privacy service to
ensure that these features always work).
The functionality of "replaces" parameter when anonymized depends on
the circumstances in which it is used. REFER may work or may not
work depending on the following three criteria.
1. Who generated the Call-ID.
2. Where the privacy service is on the signaling path.
3. Who initiates the REFER with "replaces" parameter.
A few examples that explore when the Replaces header/parameter works
or fails are given below.
Example 1:
Transfer initiated by the originator, PS added for INV and REF
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > Bob (SUCCEED)
Example 2:
Transfer initiated by the originator, PS added only for INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1) > Bob (FAIL)
Note: Example 2 would succeed if the same PS (that modifies the
Call-ID in the INVITE from Alice) is also added for REFER and
modifies the value in the "replaces" parameter from C1 to C2
even if there is no Privacy header in the REFER.
Munakata, et al. Expires March 30, 2009 [Page 20]
Internet-Draft SIP Privacy Guideline September 2008
Example 3:
Transfer initiated by the originator, PS added only for REF
Alice > INV(Call-ID:C1) > INV(Call-ID:C1) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1, Privacy:user) > PS' >
INV(Replaces:C1) > Bob (SUCCEED)
Example 4:
Transfer initiated by the terminating party, PS added for both INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > REF(Refer-To:Alice?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > PS > INV(Replaces:C1) > Alice (SUCCEED)
Note: Example 4 succeeds because the same PS (that modifies the
Call-ID in the INVITE from Alice) checks the incoming requests
and modifies the value in a Replaces header in the INVITE from
Carol to the former value of Call-ID (C1).
Example 5:
Hold
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Music-Server
Music-Server > INV(Replaces:C1) > Bob (FAIL)
Note: Example 5 would succeed if the same PS (that modifies the
Call-ID in the INVITE from Alice) is added for the INVITE from
the Music-Server and modifies the value in a Replaces header
from C1 to C2.
As the above examples shown, in some scenarios, information carried
in the Replaces header/parameter would result in failure of the
REFER. This will not happen if the Call-ID is not modified at a
privacy service.
5.3.4. Route
This field may contain information about the administrative domain of
the user agent, but the Route header is not the target of any priv-
values.
Route headers appear only in SIP requests to force routing through
the listed set of proxies. If a privacy service anonymizes the Route
header, the routing does not function. Furthermore, there is no risk
in revealing the information in the Route headers to further network
entities including the terminating user agent because a proxy removes
Munakata, et al. Expires March 30, 2009 [Page 21]
Internet-Draft SIP Privacy Guideline September 2008
the value from the Route header when it replaces the value in the
Request-URI, as defined in RFC 3261.
A privacy service that modifies Record-Route headers may need to
restore the values in Route headers as necessary. As indicated in
Section 5.1 in RFC 3323, if a privacy service modifies the Record-
Route headers, it MUST be able to restore Route headers with retained
values. Please refer to Section 5.1.9 (Record-Route) for further
detail and examples.
5.3.5. Service-Route
Service-Route headers [RFC3608] appear only in 200 OK responses to
REGISTER requests and contain information about the registrar. The
purpose of the privacy mechanism defined in RFC 3323 is to secure the
user's privacy, so the case where a registrar sets a Privacy header
is not considered here. Therefore, the Service-Route header is not
the target of any priv-values.
5.3.6. Target-Dialog
The Target-Dialog [RFC4538] header faces exactly the same issues as
seen for the Replaces header. Please refer to Section 5.3.2
(Replaces) for why this is not a target for any particular priv-
values and how a privacy service still needs to evaluate and modify
the value contained, even if no privacy is requested.
6. Security Considerations
This guideline draft adds no new security considerations to those
discussed in [RFC3323], [RFC3325], and [RFC4244].
7. IANA Considerations
This document requires no action by IANA.
8. Acknowledgements
The authors would like to thank John Elwell, Jon Peterson, Jonathan
Rosenberg, Mary Barnes, Paul Kyzivat, and Roland Jesske for their
reviews and comments.
9. References
Munakata, et al. Expires March 30, 2009 [Page 22]
Internet-Draft SIP Privacy Guideline September 2008
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] 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.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3325] 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.
[RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 4244,
November 2005.
9.2. Informative References
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-09 (work in progress), July 2008.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002.
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Service Route Discovery
During Registration", RFC 3608, October 2003.
Munakata, et al. Expires March 30, 2009 [Page 23]
Internet-Draft SIP Privacy Guideline September 2008
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP)
Referred-By Mechanism", RFC 3892, September 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4538] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Authors' Addresses
Mayumi Munakata
NTT Corporation
Phone: +81 422 36 7502
Email: munakata.mayumi@lab.ntt.co.jp
Shida Schubert
NTT Corporation
Phone: +1 808 280 8588
Email: shida@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@lab.ntt.co.jp
URI: http://www.ntt.co.jp
Munakata, et al. Expires March 30, 2009 [Page 24]
Internet-Draft SIP Privacy Guideline September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Munakata, et al. Expires March 30, 2009 [Page 25]