< draft-ietf-sip-asserted-identity-01.txt		draft-ietf-sip-asserted-identity-02.txt >
			A new Request for Comments is now available in online RFC libraries.
	SIP WG C. Jennings		RFC 3325
	Internet-Draft Cisco Systems
	Expires: December 5, 2002 J. Peterson
	NeuStar, Inc.
	M. Watson
	Nortel Networks
	June 6, 2002
	Private Extensions to the Session Initiation Protocol (SIP) for
	Asserted Identity within Trusted Networks
	draft-ietf-sip-asserted-identity-01
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.
	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 December 5, 2002.
	Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract
	This document describes private extensions to SIP that enable a
	network of trusted SIP servers to assert the identity of
	authenticated users , and the application of existing privacy
	mechanisms to the identity problem. 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 use between different trust domains, or
	use in the Internet at large.
	Table of Contents
	1. Applicability Statement . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6
	7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 7
	8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7
	9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1 The P-Asserted-Identity Header . . . . . . . . . . . . . . . 8
	9.2 The "id" Privacy Type . . . . . . . . . . . . . . . . . . . 9
	10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1 Network Asserted Identity passed to trusted gateway . . . . 9
	10.2 Network Asserted Identity Withheld . . . . . . . . . . . . . 11
	11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13
	11.1 Protocol requirements . . . . . . . . . . . . . . . . . . . 13
	11.2 Authentication requirements . . . . . . . . . . . . . . . . 13
	11.3 Security requirements . . . . . . . . . . . . . . . . . . . 13
	11.4 Scope of Trust Domain . . . . . . . . . . . . . . . . . . . 13
	11.5 Implicit handling when no Privacy header is present . . . . 13
	12. Security Considerations . . . . . . . . . . . . . . . . . . 14
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
	13.1 Registration of "P-Asserted-Identity" SIP header field . . . 14
	13.2 Registration of "id" privacy type for SIP Privacy header . . 14
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
	Normative References . . . . . . . . . . . . . . . . . . . . 15
	Informational References . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
	Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
	1. Applicability Statement
	This document describes private extensions to SIP [1] that enable a
	network of trusted SIP servers to assert the identity of end users or
	end systems, and to convey indications of end-user requested privacy.
	The use of these extensions is only applicable inside a 'Trust
	Domain' as defined in Short term requirements for Network Asserted
	Identity [5]. Nodes in such a Trust Domain are explicitly trusted by
	its users and end-systems to publicly assert the identity of each
	party, and to be responsible for withholding that identity outside of
	the Trust Domain when privacy is requested. The means by which the
	network determines the identity to assert is outside the scope of
	this document (though it commonly entails some form of
	authentication).
	A key requirement of [5] is that the behavior of all nodes within a
	given Trust Domain 'T' is known to comply to a certain set of
	specifications known as 'Spec(T)'. Spec(T) MUST specify behavior for
	the following:
	1. The manner in which users are authenticated
	2. The mechanisms used to secure the communication among nodes
	within the Trust Domain
	3. The mechanisms used to secure the communication between UAs and
	nodes within the Trust Domain
	4. The manner used to determine which hosts are part of the Trust
	Domain
	5. The default privacy handling when no Privacy header field is
	present
	6. That nodes in the Trust Domain are compliant to SIP [1]
	7. That nodes in the Trust Domain are compliant to this document
	8. Privacy handling for identity as described in Section 7.
	An example of a suitable Spec(T) is shown in Section 11.
	This document does NOT offer a general privacy or identity model
	suitable for inter-domain use or use in the Internet at large. Its
	assumptions about the trust relationship between the user and the
	network may not apply in many applications. For example, these
	extensions do not accommodate a model whereby end users can
	independently assert their identity by use of the extensions defined
	here. Furthermore, since the asserted identities are not
	cryptographically certified, they are subject to forgery, replay, and
	falsification in any architecture that does not meet the requirements
	of [5].
	The asserted identities also lack an indication of who specifically
	is asserting the identity, and so it must be assumed that the Trust
	Domain is asserting the identity. Therefore, the information is only
	meaningful when securely received from a node known to be a member of
	the Trust Domain.
	Despite these limitations, there are sufficiently useful specialized
	deployments that meet the assumptions described above, and can accept
	the limitations that result, to warrant informational publication of
	this mechanism. An example deployment would be a closed network
	which emulates a traditional circuit switched telephone network.
	2. Conventions
	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 RFC-2119 [3].
	Throughout this document requirements for or references to proxy
	servers or proxy behavior apply similarly to other intermediaries
	within a Trust Domain (ex: B2BUAs).
	The terms Identity, Network Asserted Identity and Trust Domain in
	this document have meanings as defined in [5].
	3. Introduction
	Various providers offering a telephony service over IP networks have
	selected SIP as a call establishment protocol. Their environments
	require a way for trusted network elements operated by the service
	providers (for example SIP proxy servers) to communicate the identity
	of the subscribers to such a service, yet also need to withhold this
	information from entities that are not trusted when necessary. Such
	networks typically assume some level of transitive trust amongst
	providers and the devices they operate.
	These networks need to support certain traditional telephony services
	and meet basic regulatory and public safety requirements. These
	include Calling Identity Delivery services, Calling Identity Delivery
	Blocking, and the ability to trace the originator of a call. While
	baseline SIP can support each of these services independently,
	certain combinations cannot be supported without the extensions
	described in this document. For example, a caller that wants to
	maintain privacy and consequently provides limited information in the
	SIP From header field will not be identifiable by recipients of the
	call unless they rely on some other means to discover the identity of
	the caller. Masking identity information at the originating user
	agent will prevent certain services, e.g., call trace, from working
	in the Public Switched Telephone Network (PSTN) or being performed at
	intermediaries not privy to the authenticated identity of the user.
	This document attempts to provide a network asserted identity service
	using a very limited, simple mechanism, based on requirements in [5].
	This work is derived from a previous attempt, [6], to solve several
	problems related to privacy and identity in Trust Domains . A more
	comprehensive mechanism, [7] which uses cryptography to address this
	problem is the subject of current study by the SIP working group.
	Providing privacy in a SIP network is more complicated than in the
	PSTN. In SIP networks, the participants in a session typically are
	normally able to exchange IP traffic directly without involving any
	SIP service provider. The IP addresses used for these sessions may
	themselves reveal private information. A general purpose mechanism
	for providing privacy in a SIP environment is discussed in [2]. This
	document applies that privacy mechanism to the problem of network
	asserted identity.
	4. Overview
	The mechanism proposed in this document relies on a new header field
	called 'P-Asserted-Identity' that contains a URI (commonly a SIP URI)
	and an optional display-name, for example:
	P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
	A proxy server which handles a message can, after authenticating the
	originating user in some way (for example: Digest authentication),
	insert such a P-Asserted-Identity header field into the message and
	forward it to other trusted proxies. A proxy that is about to
	forward a message to a proxy server or UA that it does not trust MUST
	remove all the P-Asserted-Identity header field values if the user
	requested that this information be kept private. Users can request
	this type of privacy as described in Section 7.
	The formal syntax for the P-Asserted-Identity header is presented in
	Section 9.
	5. Proxy Behavior
	A proxy in a Trust Domain can receive a message from a node that it
	trusts, or a node that it does not trust. When a proxy receives a
	message from a node it does not trust and it wishes to add a P-
	Asserted-Identity header field, the proxy MUST authenticate the
	originator of the message, and use the identity which results from
	this authentication to insert a P-Asserted-Identity header field into
	the message.
	If the proxy receives a message (request or response) from a node
	that it trusts, it can use the information in the P-Asserted-Identity
	header field, if any, as if it had authenticated the user itself.
	If there is no P-Asserted-Identity header field present, a proxy MAY
	add one containing at most one SIP or SIP URIs, and at most one tel
	URL. If the proxy received the message from an element that it does
	not trust and there is a P-Asserted-Identity header present which
	contains a SIP or SIP URI, the proxy MUST replace that SIP or SIPS
	URI with a single SIP or SIP URI or remove it. Similarly, if the
	proxy received the message from an element that it does not trust and
	there is a P-Asserted-Identity header present which contains a tel
	URI, the proxy MUST replace that tel URI with a single tel URI or
	remove it.
	When a proxy forwards a message to another node, it must first
	determine if it trusts that node or not. If it trusts the node, the
	proxy does not remove any P-Asserted-Identity header fields that it
	generated itself, or that it received from a trusted source. If it
	does not trust the element, then the proxy MUST examine the Privacy
	header field (if present) to determine if the user requested that
	asserted identity information be kept private.
	6. Hints for Multiple Identities
	If an P-Asserted-Identity header is already present in the message
	that a proxy receives from an entity that it does not trust, the
	proxy MAY use this information as a hint suggesting which of multiple
	valid identities for the authenticated user should be asserted. If
	such a hint does not correspond to any valid identity known to the
	proxy for that user, the proxy MUST not forward the user-provided P-
	Asserted-Identity header. In this case, the proxy can add an P-
	Asserted-Identity header of its own construction, or it can reject
	the request (for example, with a 403 Forbidden).
	A user agent only sends a hint to proxy server in a Trust Domain;
	user agents MUST NOT populate the P-Asserted-Identity header in a
	message that is not sent directly to a proxy that is trusted by the
	user agent. Were a user agent to send a message containing a P-
	Asserted-Identity header to a node outside a Trust Domain, then the
	hinted identity might not be managed appropriately by the network,
	which could have negative ramifications for privacy.
	7. Requesting Privacy
	Parties who wish to request the removal of P-Asserted-Identity header
	fields before they are transmitted to an element that is not trusted
	may add the "id" privacy token to the Privacy header field. The
	Privacy header field is defined in [6]. If this token is present,
	proxies MUST remove all the P-Asserted-Identity header fields before
	forwarding messages to elements that are not trusted. If the Privacy
	header field value is set to "none" then the proxy MUST NOT remove
	the P-Asserted-Identity header fields.
	When a proxy is forwarding the request to an element that is not
	trusted and there is no Privacy header field, the proxy MAY include
	the P-Asserted-Identity header field or it MAY remove it. This
	decision is a policy matter of the Trust Domain and MUST be specified
	in Spec(T). It is RECOMMENDED that unless local privacy policies
	prevent it, the P-Asserted-Identity header fields SHOULD NOT be
	removed, since removal may cause services based on Asserted Identity
	to fail.
	However, it should be noted that unless all users of the Trust Domain
	have access to appropriate privacy services, forwarding of the P-
	Asserted-Identity may result in disclosure of information which was
	not requested by and could not be prevented by the user. It is
	therefore STRONGLY RECOMMENDED that all users have access to privacy
	services as described in this document.
	Formal specification of the "id" Privacy header priv-value is
	described in Section 9.2. Some general guidelines for when users
	require privacy are given in [2].
	If multiple P-Asserted-Identity headers field values are present in a
	message, and privacy of the P-Asserted-Identity header field is
	requested, then all instances of the header field values MUST be
	removed before forwarding the request to an entity that is not
	trusted.
	8. User Agent Server Behavior
	Typically, a user agent renders the value of a P-Asserted-Identity
	header field that it receives to its user. It may consider the
	identity provided by a Trust Domain to be privileged, or
	intrinsically more trustworthy than the From header field of a
	request. However, any specific behavior is specific to
	implementations or services. This document also does not mandate any
	user agent handling for multiple P-Asserted-Identity header field
	values that happen to appear in a message (such as a SIP URI
	alongside a tel URL).
	However, if a User Agent Server receives a message from a previous
	element that it does not trust, it MUST NOT use the P-Asserted-
	Identity header field in any way.
	If a UA is part of the Trust Domain from which it received a message
	containing a P-Asserted-Identity header field, then it can use the
	value freely but it MUST ensure that it does not forward the
	information to any element that is not part of the Trust Domain.
	If a UA is not part of the Trust Domain from which it received a
	message containing a P-Asserted-Identity header field, then it can
	assume this information does not need to be kept private.
	9. Formal Syntax
	The following syntax specification uses the augmented Backus-Naur
	Form (BNF) as described in RFC-2234 [4].
	9.1 The P-Asserted-Identity Header
	The P-Asserted-Identity header field is used among trusted SIP
	entities (typically intermediaries) to carry the identity of the user
	sending a SIP message as it was verified by authentication.
	PAssertedID = "P-Asserted-Identity" HCOLON *(COMMA PAssertedID-value)
	PAssertedID-value = name-addr / addr-spec
	A P-Asserted-Identity header field value MUST consist of exactly one
	name-addr or addr-spec. There may be one or two P-Asserted-Identity
	values. If there is one value, it MUST be a sip, sips, or tel URI.
	If there are two values, one value MUST be a sip or sips URI and the
	other MUST be a tel URI. It is worth noting that proxies can (and
	will) add and remove this header field.
	This document adds the following entry to Table 2 of [1]:
	Header field where proxy ACK BYE CAN INV OPT REG
	------------ ----- ----- --- --- --- --- --- ---
	P-Asserted-Identity adr - o - o o -
	SUB NOT REF INF UPD PRA
	--- --- --- --- --- ---
	o o o - - -
	9.2 The "id" Privacy Type
	This specification adds a new privacy type ("priv-value") to the
	Privacy header, defined in [2]. The presence of this privacy type in
	a Privacy header field indicates that the user would like the Network
	Asserted Identity to be kept private with respect to SIP entities
	outside the Trust Domain with which the user authenticated. Note
	that a user requesting multiple types of privacy MUST include all of
	the requested privacy types in its Privacy header field value.
	priv-value = "id"
	Example:
	Privacy: id
	10. Examples
	10.1 Network Asserted Identity passed to trusted gateway
	In this example, proxy.cisco.com creates a P-Asserted-Identity header
	field from an identity it discovered from SIP Digest authentication.
	It forwards this information to a trusted proxy which forwards it to
	a trusted gateway. Note that these examples consist of partial SIP
	messages that illustrate only those headers relevant to the
	authenticated identity problem.
	* F1 useragent.cisco.com -> proxy.cisco.com
	INVITE sip:+14085551212@cisco.com SIP/2.0
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
	To: <sip:+14085551212@cisco.com>
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 1 INVITE
	Max-Forwards: 70
	Privacy: id
	* F2 proxy.cisco.com -> useragent.cisco.com
	SIP/2.0 407 Proxy Authorization
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
	To: <sip:+14085551212@cisco.com>;tag=123456
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 1 INVITE
	Proxy-Authenticate: .... realm="sip.cisco.com"
	* F3 useragent.cisco.com -> proxy.cisco.com
	INVITE sip:+14085551212@cisco.com SIP/2.0
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
	To: <sip:+14085551212@cisco.com>
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 2 INVITE
	Max-Forwards: 70
	Privacy: id
	Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy"
	* F4 proxy.cisco.com -> proxy.pstn.net (trusted)
	INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
	Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
	To: <sip:+14085551212@cisco.com>
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 2 INVITE
	Max-Forwards: 69
	P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
	P-Asserted-Identity: tel:+14085264000
	Privacy: id
	* F5 proxy.pstn.net -> gw.pstn.net (trusted)
	INVITE sip:+14085551212@gw.pstn.net SIP/2.0
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
	Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
	Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2
	To: <sip:+14085551212@cisco.com>
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 2 INVITE
	Max-Forwards: 68
	P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
	P-Asserted-Identity: tel:+14085264000
	Privacy: id
	10.2 Network Asserted Identity Withheld
	In this example, the User Agent sends an INVITE to the first proxy,
	which authenticates this with SIP Digest. The first proxy creates a
	P-Asserted-Identity header field and forwards it to a trusted proxy
	(outbound.cisco.com). The next proxy removes the P-Asserted-Identity
	header field, and the request for Privacy before forwarding this
	request onward to the biloxi.com proxy server which it does not
	trust.
	* F1 useragent.cisco.com -> proxy.cisco.com
	INVITE sip:bob@biloxi.com SIP/2.0
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
	To: <sip:bob@biloxi.com>
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 1 INVITE
	Max-Forwards: 70
	Privacy: id
	* F2 proxy.cisco.com -> useragent.cisco.com
	SIP/2.0 407 Proxy Authorization
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
	To: <sip:bob@biloxi.com>;tag=123456
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 1 INVITE
	Proxy-Authenticate: .... realm="cisco.com"
	* F3 useragent.cisco.com -> proxy.cisco.com
	INVITE sip:bob@biloxi.com SIP/2.0
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
	To: <sip:bob@biloxi.com>
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 2 INVITE
	Max-Forwards: 70
	Privacy: id
	Proxy-Authorization: .... realm="cisco.com" user="fluffy"
	* F4 proxy.cisco.com -> outbound.cisco.com (trusted)
	INVITE sip:bob@biloxi SIP/2.0
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
	Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
	To: <sip:bob@biloxi.com>
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 2 INVITE
	Max-Forwards: 69
	P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>
	Privacy: id
	* F5 outbound.cisco.com -> proxy.biloxi.com (not trusted)
	INVITE sip:bob@biloxi SIP/2.0
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
	Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
	Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
	To: <sip:bob@biloxi.com>
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 2 INVITE
	Max-Forwards: 68
	Privacy: id
	* F6 proxy.biloxi.com -> bobster.biloxi.com
	INVITE sip:bob@bobster.biloxi.com SIP/2.0
	Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
	Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
	Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
	Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456
	To: <sip:bob@biloxi.com>
	From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
	Call-ID: 245780247857024504
	CSeq: 2 INVITE
	Max-Forwards: 67
	Privacy: id
	11. Example of Spec(T)
	The integrity of the mechanism described in this document relies on
	one node knowing (through configuration) that all of the nodes in a
	Trust Domain will behave in a predetermined way. This requires the
	predetermined behavior to be clearly defined and for all nodes in the
	Trust Domain to be compliant. The specification set that all nodes
	in a Trust Domain T must comply with is termed 'Spec(T)'.
	The remainder of this section presents an example Spec(T), which is
	not normative in any way.
	11.1 Protocol requirements
	The following specifications MUST be supported:
	1. SIP [1]
	2. This document.
	11.2 Authentication requirements
	Users MUST be authenticated using SIP Digest Authentication.
	11.3 Security requirements
	Connections between nodes within the Trust Domain and between UAs and
	nodes in the Trust Domain MUST use TLS using a cipher suite of
	RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in
	the trust domain MUST be performed and confidentiality MUST be
	negotiated.
	11.4 Scope of Trust Domain
	The Trust Domain specified in this agreement consists of hosts which
	posses a valid certificate which is a) signed by examplerootca.org;
	b) whose subjectAltName ends with one of the following domain names:
	trusted.div1.carrier-a.net, trusted.div2.carrier-a.net, sip.carrier-
	b.com; and c) whose domain name corresponds to the hostname in the
	subjectAltName in the certificate.
	11.5 Implicit handling when no Privacy header is present
	The elements in the trust domain must support the 'id' privacy
	service therefore absence of a Privacy header can be assumed to
	indicate that the user is not requesting any privacy. If no Privacy
	header field is present in a request, elements in this Trust Domain
	MUST act as if no privacy is requested.
	12. Security Considerations
	The mechanism provided in this document is a partial consideration of
	the problem of identity and privacy in SIP. For example, these
	mechanisms provide no means by which end users can securely share
	identity information end-to-end without a trusted service provider.
	Identity information which the user designates as 'private' can be
	inspected by any intermediaries participating in the Trust Domain.
	This information is secured by transitive trust, which is only as
	reliable as the weakest link in the chain of trust.
	When a trusted entity sends a message to any destination with that
	party's identity in a P-Asserted-Identity header field, the entity
	MUST take precautions to protect the identity information from
	eavesdropping and interception to protect the confidentiality and
	integrity of that identity information. The use of transport or
	network layer hop-by-hop security mechanisms, such as TLS or IPSec
	with appropriate cipher suites, can satisfy this requirement.
	13. IANA Considerations
	13.1 Registration of "P-Asserted-Identity" SIP header field
	This document defines a new private SIP header field, "P-Asserted-
	Identity". As recommended by the policy of the Transport Area, this
	header should be registered by the IANA in the SIP header registry,
	using the RFC number of this document as its reference.
	Name of Header: P-Asserted-Identity
	Short form: none
	Registrant: Cullen Jennings
	fluffy@cisco.com
	Normative description:
	Section 9.1 of this document
	13.2 Registration of "id" privacy type for SIP Privacy header
	Name of privacy type: id
	Short Description: Privacy requested for Third-Party Asserted Identity
	Registrant: Cullen Jennings
	fluffy@cisco.com
	Normative description:
	Section 9.2 of this document
	14. Acknowledgements
	Thanks to Bill Marshall and Flemming Andreason[6], Mark Watson[5],
	and Jon Peterson[7] for authoring drafts which represent the bulk of
	the text making up this document. Thanks to many people for useful
	comments including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat.
	Normative References
	[1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation
	Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),
	February 2002.
	[2] Peterson, J., "A Privacy Mechanism for the Session Initiation
	Protocol (SIP)", draft-ietf-sip-privacy-general-00 (work in
	progress), May 2002.
	[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.
	[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.
	Informational References
	[5] Watson, M., "Short term requirements for Network Asserted
	Identity", draft-ietf-sipping-nai-reqs-01 (work in progress),
	May 2002.
	[6] Andreasen, F., "SIP Extensions for Network-Asserted Caller
	Identity and Privacy within Trusted Networks", draft-ietf-sip-
	privacy-04 (work in progress), March 2002.
	[7] Peterson, J., "Enhancements for Authenticated Identity
	Management in the Session Initiation Protocol (SIP)", draft-
	peterson-sip-identity-00 (work in progress), April 2002.
	Authors' Addresses
	Cullen Jennings
	Cisco Systems
	170 West Tasman Drive
	MS: SJC-21/3
	San Jose, CA 95134
	USA
	Phone: +1 408 527-9132
	EMail: fluffy@cisco.com
	Jon Peterson		Title: Private Extensions to the Session Initiation
	NeuStar, Inc.		Protocol (SIP) for Asserted Identity within
	1800 Sutter Street, Suite 570		Trusted Networks
	Concord, CA 94520		Author(s): C. Jennings, J. Peterson, M. Watson
	USA		Status: Informational
			Date: November 2002
			Mailbox: fluffy@cisco.com, Jon.Peterson@NeuStar.biz,
			mwatson@nortelnetworks.com
			Pages: 18
			Characters: 36170
			Updates/Obsoletes/SeeAlso: None
	Phone: +1 925/363-8720		I-D Tag: draft-ietf-sip-asserted-identity-02.txt
	EMail: Jon.Peterson@NeuStar.biz
	Mark Watson		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3325.txt
	Nortel Networks
	Maidenhead Office Park (Bray House)
	Westacott Way
	Maidenhead, Berkshire
	England
	Phone: +44 (0)1628-434456		This document describes private extensions to the Session Initiation
	EMail: mwatson@nortelnetworks.com		Protocol (SIP) that enable a network of trusted SIP servers to assert
			the identity of authenticated users, and the application of existing
			privacy mechanisms to the identity problem. 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 use between different trust domains, or
			use in the Internet at large.
	Full Copyright Statement		This document is a product of the Session Initiation Protocol Working
			Group and the Session Initiation Proposal Investigation Working Groups
			of the IETF.
	Copyright (C) The Internet Society (2002). All Rights Reserved.		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	This document and translations of it may be copied and furnished to		This announcement is sent to the IETF list and the RFC-DIST list.
	others, and derivative works that comment on or otherwise explain it		Requests to be added to or deleted from the IETF distribution list
	or assist in its implementation may be prepared, copied, published		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	and distributed, in whole or in part, without restriction of any		added to or deleted from the RFC-DIST distribution list should
	kind, provided that the above copyright notice and this paragraph are		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	revoked by the Internet Society or its successors or assigns.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and the information contained herein is provided on an		To: rfc-info@RFC-EDITOR.ORG
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		Subject: getting rfcs
	TASK FORCE DISCLAIMS 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.
	Acknowledgement		help: ways_to_get_rfcs
	Funding for the RFC Editor function is currently provided by the		Requests for special distribution should be addressed to either the
	Internet Society.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	726 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/