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.
