Subject: Protocol Action: A Privacy Mechanism for the Session Initiation Protocol (SIP) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 24 Jun 2002 17:46:01 -0400

The IESG has approved the Internet-Draft A Privacy Mechanism for the
Session Initiation Protocol (SIP) <draft-ietf-sip-privacy-general-01.txt>
for publication as a Proposed Standard

The IESG also approved publication of the following Internet-Drafts
for publication as Informational RFCs:

 o Extensions to the Session Initiation Protocol (SIP) for Asserted
   Identity
     <draft-ietf-sip-asserted-identity-01.txt>

 o Short term requirements for Network Asserted Identity
     <draft-ietf-sipping-nai-reqs-02.txt>

These documents are the product of the Session Initiation Protocol
Working Group and the Session Initiation Proposal Investigation
(sipping) Working Group.  The IESG contact persons are Allison Mankin
and Scott Bradner.

Technical Summary

  The document 'A Privacy Mechanism for the Session Initiation Protocol
  (SIP)' defines new mechanisms for the Session Initiation Protocol (SIP) in
  support of privacy. In this context, privacy is defined as the withholding
  of the identity of a person (and related personal information) from one or
  more parties in an exchange of communications, specifically a SIP dialog.
  These parties potentially include the intended destination(s) of messages
  and/or any intermediaries handling these messages. Withholding the
  identity of a user will, among other things, render the other parties in
  the dialog unable to send new SIP requests to the user outside of the
  context of the current dialog. Specifically, guidelines are provided for
  the creation of messages that do not divulge personal identity information.
  A new "privacy service" logical role for intermediaries is defined to
  address some privacy requirements that user agents cannot satisfy
  themselves. Finally, means are presented by which a user can request
  particular functions from a privacy service.

  SIP allows users to assert their identity in a number of ways e.g. using
  the From: header. However, there is no requirement
  for these identities to be anything other than the users desired alias. The
  document 'Short term requirements for Network Asserted Identity' describes
  the requirements for a Network Asserted Identity which is an identity
  initially derived by a SIP network intermediary as a result of an
  authentication process.

  The document 'Private Extensions to the Session Initiation Protocol (SIP)
  for Asserted Identity within Trusted Networks' describes optional SIP
  extensions for the use of Network Asserted Identities within a trusted
  network. The use of these extensions is only applicable inside an
  administrative domain with previously agreed-upon policies for generation,
  transport and usage of such information. This document does NOT offer a
  general privacy or identity model suitable for inter-domain use or use in
  the Internet at large.

Working Group Summary
 
  The SIP working group supported publication of these documents though
  some of the discussions were protracted.
 
Protocol Quality
 
  These documents were reviewed for the IESG by Allison Mankin

Note to RFC Editor:

1. Please change the title of draft-ietf-sip-asserted-identity-01.txt

From: Extensions to the Session Initiation Protocol (SIP) for Asserted
      Identity

To: Private Extensions to the Session Initiation Protocol (SIP) for
    Asserted Identity

2. In draft-ietf-sip-privacy-general-01.txt, please make the following
   changes:

Section 4.2:

Old:
< Note that requesting session privacy when end-to-end session
< encryption is not possible raises serious security concerns (see
< Section 6.2).
New:
> Note that requesting session privacy in the absence of any end-to-
> end session encryption raises some serious security concerns (see
< Section 6.2).

Section 4.2:

Old:
< user: This privacy level is set only by intermediaries, in order to
< communicate that user level privacy functions (as discussed in
< Section 5.3) must be provided by the network, presumably because
< the user agent is unable to provide them. User agents MUST NOT
< set the "user" privacy level.
New:
> user: This privacy level is usually set only by intermediaries, in
> order to communicate that user level privacy functions (as
> discussed in Section 5.3) must be provided by the network,
> presumably because the user agent is unable to provide them. User
> agents MAY however set this privacy level for REGISTER requests,
> but SHOULD NOT set 'user' level privacy for other requests.

Section 4.4:

Old:
< record. The user would then register their normal address-of-record
< as a contact address with the third-party service.
New:
> record. A privacy service provider might offer these anonymous
> callback URIs to users in the same way that an ordinary SIP service
> provider grants addresses-of-record. The user would then register
> their normal address-of-record as a contact address with the third-
> party service.

Section 5:

Old:
< not be capable of fulfilling the requested level of privacy. It MAY,
< however, re-route the request to another server which is capable of
< providing the needed functions, if it can. If the 'critical' privacy
< level is present in the Privacy header of a request, then if the
< privacy service is incapable of performing all of the levels of
< privacy specified in the Privacy header then it MUST either fail the
< request, or it MUST forward the request to another privacy service
< which can fulfill these functions (note that before forwarding the
< request, the privacy service SHOULD complete a subset of the
< functions if it can).
New:
> not be capable of fulfilling the requested level of privacy. If the
> 'critical' privacy level is present in the Privacy header of a
> request, then if the privacy service is incapable of performing all
> of the levels of privacy specified in the Privacy header then it MUST
> fail the request with a 500 (Server Error) response code.
> The reason phrase of the
> status line of the response SHOULD contain appropriate text
> indicating that there has been a privacy failure as well as an
> enumeration of the priv-value(s) which were not supported by the
> privacy service (the reason phrase SHOULD also respect any Accept-
> Language header in the request if possible).

Section 7:

Old:
< IANA registration for "Privacy" header field values is required.
< Only approved RFCs of the SIP WG can register "Privacy" header field
< values.
New:
> New values for the "Privacy" header can only be defined by IETF
> Consensus including RFC publication (RFC 2434).
> IANA registration for the "Privacy"
> header field values is required along with the RFC publication.