TOC 
Internet Engineering Task ForceM. Munakata
Internet-DraftS. Schubert
Intended status: InformationalT. Ohba
Expires: May 22, 2008NTT
 November 19, 2007


Guidelines for Using the Privacy Mechanism for SIP
draft-munakata-sip-privacy-guideline-01

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 May 22, 2008.

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 attributes for each of the privacy header values (priv-values).



Table of Contents

1.  Introduction
2.  Terminology
3.  Semantics of Existing priv-values
4.  Target for Each priv-value
    4.1.  Target SIP Headers for Each priv-value
    4.2.  Target SDP Attributes for Each priv-value
    4.3.  Treatment of priv-value Not Supported by the Privacy Service
5.  Recommended Treatment of User-Privacy-Related Information
    5.1.  Target SIP Headers
        5.1.1.  Call-ID
        5.1.2.  Call-Info
        5.1.3.  Contact
        5.1.4.  From
        5.1.5.  History-Info
        5.1.6.  In-Reply-To
        5.1.7.  Organization
        5.1.8.  P-Asserted-Identity
        5.1.9.  Record-Route
        5.1.10.  Referred-By
        5.1.11.  Reply-To
        5.1.12.  Server
        5.1.13.  Subject
        5.1.14.  User-Agent
        5.1.15.  Via
        5.1.16.  Warning
    5.2.  Target SDP Attributes
        5.2.1.  c/m Lines
        5.2.2.  o Line
        5.2.3.  i/u/e/p Lines
    5.3.  Considerations for Non-Target SIP Headers/Parameters
        5.3.1.  Identity/Identity-Info
        5.3.2.  Path
        5.3.3.  Replaces Header/Parameter
        5.3.4.  Route
        5.3.5.  Service-Route
        5.3.6.  Target-Dialog
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

This document clarifies the privacy mechanism for Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) defined in [RFC3323] (Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” November 2002.), which was later extended in [RFC3325] (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.) and [RFC4244] (Barnes, M., “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.). This document describes the practical manner of operations of the privacy mechanism as a guideline and has no intention of changing 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 headers to be obscured per priv-value 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 implicitness, 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 to be obscured for each of the priv-values to alleviate the potential interoperability issues already seen due to a lack of explicit text.



 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” November 2002.), "id" defined in [RFC3325] (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.), and "history" defined in [RFC4244] (Barnes, M., “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.).
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 headers that can be anonymized by the user agent itself.


 TOC 

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 requsted for Third-Party        [RFC3325]
              Asserted Identity

history       Privacy requested for                   [RFC4244]
              History-Info header(s)



 TOC 

4.  Target for Each priv-value

Tables in this section show the recommended treatment of SIP headers and SDP attributes per priv-value. SIP headers and SDP attributes not shown in the tables are regarded as non-targets of these priv-values. Some non-target SIP headers/SDP attributes 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 attributes 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 attributes.

Note:
The scope of these tables is SIP headers and related parameters specified in RFCs.


 TOC 

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.

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 (Note1)     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 1:
Any time a privacy service modifies a Call-ID, it MUST retain the former and modified values. 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.
Note 2:
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.


 TOC 

4.2.  Target SDP Attributes for Each priv-value

Table 2 below shows a recommended treatment of each SDP attribute per priv-value.


Target parameters  where   user   header    session    id   history
----------------------------------------------------------------------
SDP c/m lines        Rr     -       -      anonymize    -      -
SDP o lines          Rr     -       -      anonymize    -      -
SDP i/u/e/p lines    Rr     -       -      anonymize    -      -

      Table 2: Recommended PS behaviors for each SDP attribute



 TOC 

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.

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.



 TOC 

5.  Recommended Treatment of User-Privacy-Related Information

The following SIP headers and related parameters may concern privacy. This section describes what kind of user-privacy-related 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.



 TOC 

5.1.  Target SIP Headers

This section describes privacy considerations and recommended treatment for each SIP header that may reveal user-privacy-related 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.



 TOC 

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 exclude the host name and IP address from a Call-ID header.

A privacy service MAY delete the host name and IP address from a Call-ID header or anonymize them by using a functional anonymous URI or IP address when the request contains Privacy:user. This is generally done by replacing the IP address or host name with that of the privacy service.

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. 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.8 (In-Reply-To), 5.3.2 (Replaces), and 5.3.5 (Target-Dialog), for detailed discussion.



 TOC 

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.

A privacy service MUST delete a Call-Info header if one exists when user privacy is requested with Privacy:user. A privacy service SHOULD NOT add a Call-Info header when user privacy is requested with Privacy:header.



 TOC 

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] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.). 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 SHOULD NOT anonymize a Contact header, unless it can obtain an IP address or contact 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 GRUU [I‑D.ietf‑sip‑gruu] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.) and TURN [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),” July 2009.).

A privacy service SHOULD anonymize a Contact header using a functional anonymous URI when user privacy is requested with Privacy:header. This is generally done by replacing the IP address or host name with that of the privacy service.



 TOC 

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.

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 "anonymous.invalid", as indicated in RFC 3323.

The recommended form of the From header for anonymity is:

From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774



 TOC 

5.1.5.  History-Info

History-Info [RFC4244] (Barnes, M., “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.) 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.

A privacy service SHOULD delete the History-Info headers when user privacy is requested with Privacy:header, Privacy:session, or Privacy:history.

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.

Refer to [RFC4244] (Barnes, M., “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.) for detailed behavior for dealing with History-Info headers.



 TOC 

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 a 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.

A privacy service MUST delete the In-Reply-To header when user privacy is requested with Privacy:user.

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(Call-ID: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.


 TOC 

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.

A privacy service MUST delete the Organization header if one exists when user privacy is requested with Privacy:user. A privacy service SHOULD NOT add an Organization header when user privacy is requested with Privacy:header.



 TOC 

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 before it forwards the message to an entity that is not trusted when user privacy is requested with Privacy:header or Privacy:id.



 TOC 

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.

In addition, privacy services can remove the Record-Route headers and encrypt them into a single header. 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 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. 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).

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
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.


 TOC 

5.1.10.  Referred-By

The Referred-By [RFC3892] (Sparks, R., “The Session Initiation Protocol (SIP) Referred-By Mechanism,” September 2004.) 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 never represents the sender of the request.


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


 TOC 

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.

A privacy service MUST delete a Reply-To header when user privacy is requested with Privacy:user.



 TOC 

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.

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.



 TOC 

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 add a Subject header.

A privacy service MUST delete a Subject header when user privacy is requested with Privacy:user.



 TOC 

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.

A privacy service MUST delete a User-Agent header when user privacy is requested with Privacy:user.



 TOC 

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 SHOULD NOT anonymize a Via header, 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. Refer to Section 5.1.11 (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.

No Via stripping is required when handling responses.



 TOC 

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 MUST NOT include the host name representing its identity in a Warning header.

A privacy service SHOULD modify 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.



 TOC 

5.2.  Target SDP Attributes

This section describes privacy considerations for each SDP [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) attribute 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.



 TOC 

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 SHOULD 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. 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.



 TOC 

5.2.2.  o Line

The username and IP address in this attribute may reveal information about the user.

A user agent MAY anonymize the user name in an o line by setting username to "-" but SHOULD NOT anonymize the IP address in the o line, 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 MUST anonymize the username and IP address in the o line by setting the username to "-" and setting a functional anonymous IP address as the IP address when user privacy is requested with Privacy:session.



 TOC 

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.



 TOC 

5.3.  Considerations for Non-Target SIP Headers/Parameters



 TOC 

5.3.1.  Identity/Identity-Info

The Identity [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) 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.

The treatment of the Identity and Identity-Info headers may depend on the deployment scenario: the desired deployment will have a privacy service located before or co-located with the identity service; thus, integrity and privacy can both be provided seamlessly.

When the privacy service is located after the identity services, several different scenarios can be considered.

When a privacy service receives a request with an Identity header and it has the capability to provide a signature, it may re-compute the signature using its own certificate and replace the value of the Identity header and replace the value of the Identity-Info header with a reference to its own certificate after executing privacy functions on relevant headers that are considered to be privacy sensitive (From, Contact, etc.) and/or the message body.

If the privacy service cannot compute the signature because it lacks the authority or lacks a valid certificate, it may delete both the Identity and the Identity-Info headers when user privacy is requested with Privacy:user, Privacy:header, or Privacy:session. However, because the message loses the valuable property that identity service provides, this is not RECOMMENDED.



 TOC 

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.

Path headers [RFC3327] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” December 2002.) only appear in REGISTER requests and responses. Given that a user agent sends a REGISTER request with Privacy:user or Privacy:header, Path headers inserted by intermediaries may contain information about the domain where the user is visiting, and there is no point in hiding such user location information from the registrar that receives the REGISTER request.

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. However, anonymization of network-privacy-related information is out of scope.



 TOC 

5.3.3.  Replaces Header/Parameter

The Replaces [RFC3891] (Mahy, R., Biggs, B., and R. Dean, “The Session Initiation Protocol (SIP) "Replaces" Header,” September 2004.) 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 is not the target of any particular priv-values either. The parameter appears in a Refer-To header in a REFER request, and its functionality 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.

In addition, 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.

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


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.
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


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

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.



 TOC 

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 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 . Please refer to Section 5.1.11 (Record-Route) for details.



 TOC 

5.3.5.  Service-Route

Service-Route headers [RFC3608] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration,” October 2003.) 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.

Furthermore, if the Service-Route is replaced with another value that is less sensitive (that of an SBC etc.), it is not because it was requested by the user but probably for the convenience of the domain policy/network policy. The use of privacy for this purpose seems illogical.



 TOC 

5.3.6.  Target-Dialog

The Target-Dialog [RFC4538] (Rosenberg, J., “Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP),” June 2006.) 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.



 TOC 

6.  Security Considerations

This guideline draft adds no new security considerations to those discussed in [RFC3323] (Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” November 2002.), [RFC3325] (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.), and [RFC4244] (Barnes, M., “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.).



 TOC 

7.  IANA Considerations

This document requires no action by IANA.



 TOC 

8.  References



 TOC 

8.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[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 (TXT).
[RFC3323] Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” RFC 3323, November 2002 (TXT).
[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 (TXT).
[RFC4244] Barnes, M., “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” RFC 4244, November 2005 (TXT).


 TOC 

8.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-16 (work in progress), July 2009 (TXT).
[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 (TXT).
[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 (TXT).
[RFC3327] Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” RFC 3327, December 2002 (TXT).
[RFC3608] Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration,” RFC 3608, October 2003 (TXT).
[RFC3891] Mahy, R., Biggs, B., and R. Dean, “The Session Initiation Protocol (SIP) "Replaces" Header,” RFC 3891, September 2004 (TXT).
[RFC3892] Sparks, R., “The Session Initiation Protocol (SIP) Referred-By Mechanism,” RFC 3892, September 2004 (TXT).
[RFC4474] Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” RFC 4474, August 2006 (TXT).
[RFC4538] Rosenberg, J., “Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP),” RFC 4538, June 2006 (TXT).
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT).


 TOC 

Authors' Addresses

  Mayumi Munakata
  NTT Corporation
Phone:  +81 422 36 7565
Email:  munakata.mayumi@lab.ntt.co.jp
  
  Shida Schubert
  NTT Corporation
Phone:  +1 604 762 5606
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


 TOC 

Full Copyright Statement

Intellectual Property