Subject: [Sip] Protocol Action: A Privacy Mechanism for the Session Initiation Protocol (SIP) to Proposed Standard From: The IESG Date: Mon, 24 Jun 2002 17:46:01 -0400 To: IETF-Announce: ; CC: RFC Editor , Internet Architecture Board , sip@ietf.org The IESG has approved the Internet-Draft A Privacy Mechanism for the Session Initiation Protocol (SIP) 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 o Short term requirements for Network Asserted Identity 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. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip