< draft-ietf-sipping-trait-authz-01.txt		draft-ietf-sipping-trait-authz-02.txt >
	SIPPING WG J. Peterson		SIPPING WG J. Peterson
	Internet-Draft NeuStar		Internet-Draft NeuStar
	Expires: August 17, 2005 J. Polk		Expires: August 5, 2006 J. Polk
	Cisco		Cisco
	D. Sicker		D. Sicker
	CU Boulder		CU Boulder
	H. Tschofenig		H. Tschofenig
	Siemens		Siemens
	February 16, 2005		February 2006
	Trait-based Authorization Requirements for the Session Initiation		Trait-based Authorization Requirements for the Session Initiation
	Protocol (SIP)		Protocol (SIP)
	draft-ietf-sipping-trait-authz-01		draft-ietf-sipping-trait-authz-02
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	and any of which I become aware will be disclosed, in accordance with		have been or will be disclosed, and any of which he or she becomes
	RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 17, 2005.		This Internet-Draft will expire on August 5, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document lays out a set of requirements related to trait-based		This document lays out a set of requirements related to trait-based
	authorization for the Session Initiation Protocol. While some		authorization for the Session Initiation Protocol. While some
	authentication mechanisms are described in the base SIP		authentication mechanisms are described in the base SIP
	specification, trait-based authorization provides information used to		specification, trait-based authorization provides information used to
	make policy decisions based on the attributes of a participant in a		make policy decisions based on the attributes of a participant in a
	session. This approach provides a richer framework for		session. This approach provides a richer framework for
	authorization, as well as allow greater privacy for users of an		authorization, as well as allow greater privacy for users of an
	identity system.		identity system.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Trait-based Authorization Framework . . . . . . . . . . . . . 5		3. Trait-based Authorization Framework . . . . . . . . . . . . . 5
	4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 7		4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 7
	4.1 Settlement for Services . . . . . . . . . . . . . . . . . 7		4.1. Settlement for Services . . . . . . . . . . . . . . . . . 8
	4.2 Associating Gateways with Providers . . . . . . . . . . . 8		4.2. Associating Gateways with Providers . . . . . . . . . . . 8
	4.3 Permissions on Constrained Resources . . . . . . . . . . . 9		4.3. Permissions on Constrained Resources . . . . . . . . . . . 9
	4.4 Managing Priority and Precedence . . . . . . . . . . . . . 10		4.4. Managing Priority and Precedence . . . . . . . . . . . . . 10
	4.5 Linking Different Protocols . . . . . . . . . . . . . . . 10		4.5. Linking Different Protocols . . . . . . . . . . . . . . . 10
	5. Trait-based Authorization Requirements . . . . . . . . . . . . 11		5. Trait-based Authorization Requirements . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	8.2 Informative References . . . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . . 14
	A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . 16		Intellectual Property and Copyright Statements . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This document explores requirements of the Session Initiation		This document explores requirements of the Session Initiation
	Protocol [1] for enabling trait-based authorization. This effort		Protocol [1] for enabling trait-based authorization. This effort
	stems from the recognition that when SIP requests are received by a		stems from the recognition that when SIP requests are received by a
	User Agent Server (UAS), there are authorization requirements that		User Agent Server (UAS), there are authorization requirements that
	are orthogonal to ascertaining of the identity of the User Agent		are orthogonal to ascertaining of the identity of the User Agent
	Client (UAC). Supplemental authorization information might allow the		Client (UAC). Supplemental authorization information might allow the
	UAS to implement non-identity-based policies that depend on further		UAS to implement non-identity-based policies that depend on further
	skipping to change at page 7, line 49 ¶		skipping to change at page 8, line 5 ¶
	emergency services network might indicate that a particular user has		emergency services network might indicate that a particular user has
	a privileged status as a caller.		a privileged status as a caller.
	4. Example Use Cases		4. Example Use Cases
	The following use cases are by no means exhaustive, but provide a few		The following use cases are by no means exhaustive, but provide a few
	high-level examples of the sorts of services that trait-based		high-level examples of the sorts of services that trait-based
	authorization might provide. All of the cases below consider		authorization might provide. All of the cases below consider
	interdomain usage of authorization assertions.		interdomain usage of authorization assertions.
	4.1 Settlement for Services		4.1. Settlement for Services
	When endpoints in two domains share real-time communications		When endpoints in two domains share real-time communications
	services, sometimes there is a need for the domains to exchange		services, sometimes there is a need for the domains to exchange
	accounting and settlement information in real-time. The operators of		accounting and settlement information in real-time. The operators of
	valuable resources (for example, PSTN trunking, conference bridges,		valuable resources (for example, PSTN trunking, conference bridges,
	or the like) in the called domain may wish to settle with the calling		or the like) in the called domain may wish to settle with the calling
	domain (either with the operators of the domain, or a particular		domain (either with the operators of the domain, or a particular
	user), and some accounting operations might need to complete before a		user), and some accounting operations might need to complete before a
	call is terminated. For example, a caller in one domain might want		call is terminated. For example, a caller in one domain might want
	to access a conference bridge in another domain, and the called		to access a conference bridge in another domain, and the called
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 38 ¶
	about how to settle with it.		about how to settle with it.
	An authorization assertion created by the calling domain could		An authorization assertion created by the calling domain could
	provide the called domain with an assurance that a user's account can		provide the called domain with an assurance that a user's account can
	settle for a particular service. In some cases, no further		settle for a particular service. In some cases, no further
	information may be required to process a transaction, but if more		information may be required to process a transaction, but if more
	specific accounting data is needed, traits could also communicate the		specific accounting data is needed, traits could also communicate the
	network address of an accounting server, the settlement protocol that		network address of an accounting server, the settlement protocol that
	should be used, and so on.		should be used, and so on.
	4.2 Associating Gateways with Providers		4.2. Associating Gateways with Providers
	Imagine a case where a particular telephone service provider has		Imagine a case where a particular telephone service provider has
	deployed numerous PSTN-SIP gateways. When calls come in from the		deployed numerous PSTN-SIP gateways. When calls come in from the
	PSTN, they are eventually proxied to various SIP user agents. Each		PSTN, they are eventually proxied to various SIP user agents. Each
	SIP user agent server is interested to know the identity of the PSTN		SIP user agent server is interested to know the identity of the PSTN
	caller, of course, which could be given within SIP messages in any		caller, of course, which could be given within SIP messages in any
	number of ways (in SIP headers, bodies, or what have you). However,		number of ways (in SIP headers, bodies, or what have you). However,
	in order for the recipient to be able to trust the identity (in this		in order for the recipient to be able to trust the identity (in this
	instance, the calling party's telephone number) stated in the call,		instance, the calling party's telephone number) stated in the call,
	they must first trust that the call originated from the gateway, and		they must first trust that the call originated from the gateway, and
	that the gateway is operated by a known (and trusted) provider.		that the gateway is operated by a known (and trusted) provider.
	There are a number of ways that a service provider might try to		There are a number of ways that a service provider might try to
	address this problem. One possibility would be routing all calls		address this problem. One possibility would be routing all calls
	from gateways through a recognizable 'edge' proxy server (say,		from gateways through a recognizable 'edge' proxy server (say,
	'sip.mci.com'). Accordingly, any SIP entity that received a request		'sip.example.com'). Accordingly, any SIP entity that received a
	via the edge proxy server (assuming the use of hop-by-hop mutual		request via the edge proxy server (assuming the use of hop-by-hop
	cryptographic authentication) would know the service provider from		mutual cryptographic authentication) would know the service provider
	whom the call originated. However, it is possible that requests from		from whom the call originated. However, it is possible that requests
	the originating service provider's edge proxy might be proxied again		from the originating service provider's edge proxy might be proxied
	before reaching the destination user agent server, and thus in many		again before reaching the destination user agent server, and thus in
	cases the originating service provider's identity would be known only		many cases the originating service provider's identity would be known
	transitively. Moreover, in many architectures requests that did not		only transitively. Moreover, in many architectures requests that did
	originate from PSTN gateways could be sent through the edge proxy		not originate from PSTN gateways could be sent through the edge proxy
	server. In the end analysis, the recipient of the request is less		server. In the end analysis, the recipient of the request is less
	interested in knowing which carrier the request came from than in		interested in knowing which carrier the request came from than in
	knowing that the request came from a gateway.		knowing that the request came from a gateway.
	Another possible solution is to issue certificates to every gateway		Another possible solution is to issue certificates to every gateway
	corresponding to the hostname of the gateway ('gateway1.mci.com').		corresponding to the hostname of the gateway
	Gateways could therefore sign SIP requests directly, and this		('gateway1.example.com'). Gateways could therefore sign SIP requests
	property could be preserved end-to-end. But depending on the public		directly, and this property could be preserved end-to-end. But
	key infrastructure, this could however become costly for large		depending on the public key infrastructure, this could however become
	numbers of gateways, and moreover a user agent server that receives		costly for large numbers of gateways, and moreover a user agent
	the request has no direct assurance from a typical certificate that		server that receives the request has no direct assurance from a
	the host is in fact a gateway just because it happens to be named		typical certificate that the host is in fact a gateway just because
	'gateway1'.		it happens to be named 'gateway1'.
	Trait-based authorization would enable the trait 'is a gateway' to be		Trait-based authorization would enable the trait 'is a gateway' to be
	associated with an assertion that is generated by the service		associated with an assertion that is generated by the service
	provider (i.e. signed by 'mci.com'). Since these assertions would		provider (i.e. signed by 'example.com'). Since these assertions
	travel end-to-end from the originating service provider to the		would travel end-to-end from the originating service provider to the
	destination user agent server, SIP requests which carry them can pass		destination user agent server, SIP requests which carry them can pass
	through any number of intermediaries without discarding cryptographic		through any number of intermediaries without discarding cryptographic
	authentication information. This mechanism also does not rely on		authentication information. This mechanism also does not rely on
	hostname conventions to identity what constitutes a gateway and what		hostname conventions to identity what constitutes a gateway and what
	does not - it relies on an explicit and unambiguous attribute in an		does not - it relies on an explicit and unambiguous attribute in an
	assertion.		assertion.
	4.3 Permissions on Constrained Resources		4.3. Permissions on Constrained Resources
	Consider a scenario wherein two universities are making use of a		Consider a scenario wherein two universities are making use of a
	videoconferencing service over a constrained bandwidth resource.		videoconferencing service over a constrained bandwidth resource.
	Both universities would like to enforce policies that determine how		Both universities would like to enforce policies that determine how
	this constrained bandwidth will be allocated to members of their		this constrained bandwidth will be allocated to members of their
	respective communities. For example, faculty members might have		respective communities. For example, faculty members might have
	privileges to establish videoconferences during the day, while		privileges to establish videoconferences during the day, while
	students might not. Faculty might also be able to add students to a		students might not. Faculty might also be able to add students to a
	particular videoconference dynamically, or otherwise moderate the		particular videoconference dynamically, or otherwise moderate the
	content or attendance of the conference, whereas students might		content or attendance of the conference, whereas students might
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 21 ¶
	If the federation honored the traits "faculty", "staff", and		If the federation honored the traits "faculty", "staff", and
	"student", they could be leveraged to ensure appropriate use of the		"student", they could be leveraged to ensure appropriate use of the
	network resource between universities participating in the		network resource between universities participating in the
	federation. An assertion would then be attached to every request to		federation. An assertion would then be attached to every request to
	establish a session that indicated the role of the requestor. Only		establish a session that indicated the role of the requestor. Only
	if the requestor has the appropriate trait would the session request		if the requestor has the appropriate trait would the session request
	be granted. Ideally, these policies would be enforced by		be granted. Ideally, these policies would be enforced by
	intermediaries (SIP proxy servers) that are capable of inspecting and		intermediaries (SIP proxy servers) that are capable of inspecting and
	verifying the assertions.		verifying the assertions.
	4.4 Managing Priority and Precedence		4.4. Managing Priority and Precedence
	There is a significant amount of interest in the Internet telephony		There is a significant amount of interest in the Internet telephony
	community in assigning certain calls a 'priority' based on the		community in assigning certain calls a 'priority' based on the
	identity of the user, with the presumption that prioritized calls		identity of the user, with the presumption that prioritized calls
	will be granted preferential treatment when network resources are		will be granted preferential treatment when network resources are
	scarce. Different domains might have different criteria for		scarce. Different domains might have different criteria for
	assigning priority, and it is unlikely that a domain would correlate		assigning priority, and it is unlikely that a domain would correlate
	the identity of a non-local user with the need for priority, even in		the identity of a non-local user with the need for priority, even in
	situations where domains would like to respect one another's		situations where domains would like to respect one another's
	prioritization policies.		prioritization policies.
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 48 ¶
	contrasted here with a hypothetical trait-based system.		contrasted here with a hypothetical trait-based system.
	An assertion created by a domain for a particular request might have		An assertion created by a domain for a particular request might have
	an associated 'priority' attribute. Recipients of the request could		an associated 'priority' attribute. Recipients of the request could
	inspect and verify the signature associated with the assertion to		inspect and verify the signature associated with the assertion to
	determine which domain had authenticated the user and made the		determine which domain had authenticated the user and made the
	priority assessment. If the assertion's creator is trusted by the		priority assessment. If the assertion's creator is trusted by the
	evaluator, the given priority could be factored into any relevant		evaluator, the given priority could be factored into any relevant
	request processing.		request processing.
	4.5 Linking Different Protocols		4.5. Linking Different Protocols
	Cryptographic computations are expensive and computing authorization		Cryptographic computations are expensive and computing authorization
	decisions might require a lot of time and multiple messages between		decisions might require a lot of time and multiple messages between
	the entity enforcing the decisions and the entity computing the		the entity enforcing the decisions and the entity computing the
	authorization decision. Particularly in a mobile environment these		authorization decision. Particularly in a mobile environment these
	entities are physically separated - or not even in the same		entities are physically separated - or not even in the same
	administrative domain. Accordingly, the notion of "single sign-on"		administrative domain. Accordingly, the notion of "single sign-on"
	is another potential application of authorization assertions, and		is another potential application of authorization assertions, and
	trait-based authorization - a user is authenticated and authorized		trait-based authorization - a user is authenticated and authorized
	through one protocol, and can reuse the resulting authorization		through one protocol, and can reuse the resulting authorization
	skipping to change at page 11, line 37 ¶		skipping to change at page 11, line 40 ¶
	generated to authorize the SIP signaling would similar honor the use		generated to authorize the SIP signaling would similar honor the use
	of the assertion in the context of QoS. Upon the initial generation		of the assertion in the context of QoS. Upon the initial generation
	of the assertion by an authorization server, traits could be added		of the assertion by an authorization server, traits could be added
	that specify the desire level of quality that should be granted to		that specify the desire level of quality that should be granted to
	the media associated with a SIP session.		the media associated with a SIP session.
	5. Trait-based Authorization Requirements		5. Trait-based Authorization Requirements
	The following are the constraints and requirements for trait-based		The following are the constraints and requirements for trait-based
	authorization in SIP:		authorization in SIP:
	1. The mechanism MUST support a way for SIP user agents to embed an		1. The mechanism MUST support a way for SIP user agents to embed an
	authorization assertion in SIP requests. Assertions can be		authorization assertion in SIP requests. Assertions can be
	carried either by reference or by value.		carried either by reference or by value.
	2. The mechanism MUST allow SIP UACs to deliver to an authorization		2. The mechanism MUST allow SIP UACs to deliver to an authorization
	service those SIP requests that need to carry an assertion. The		service those SIP requests that need to carry an assertion. The
	mechanism SHOULD also provide a way for SIP intermediaries to		mechanism SHOULD also provide a way for SIP intermediaries to
	recognize that an assertion will be needed, and either forward		recognize that an assertion will be needed, and either forward
	requests to an authorization service themselves, or notify the		requests to an authorization service themselves, or notify the
	UAC of the need to do so.		UAC of the need to do so.
	3. Authorization services MUST be capable of delivering an assertion
	to a SIP UAC, either by reference or by value. It MAY also be
	possible for an authorization service to add assertions to
	requests itself, if the user profile permits this (for example,
	through the use of content-indirection as described in [4]).
	4. Authorization services MUST have a way to authenticate a SIP UAC.		3. Authorization services MUST be capable of delivering an
	5. The assertions generated by authorization services MUST be		assertion to a SIP UAC, either by reference or by value. It MAY
			also be possible for an authorization service to add assertions
			to requests itself, if the user profile permits this (for
			example, through the use of content-indirection as described in
			[4]).
			4. Authorization services MUST have a way to authenticate a SIP
			UAC.
			5. The assertions generated by authorization services MUST be
	capable of providing a set of values for a particular trait that		capable of providing a set of values for a particular trait that
	a principal is entitled to claim.		a principal is entitled to claim.
	6. The mechanism MUST provide a way for authorized SIP		6. The mechanism MUST provide a way for authorized SIP
	intermediaries (e.g. authorized proxy servers) to inspect		intermediaries (e.g. authorized proxy servers) to inspect
	assertions.		assertions.
	7. The mechanism MUST have a single baseline mandatory-to- implement		7. The mechanism MUST have a single baseline mandatory-to-
	authorization assertion scheme. The mechanism MUST also allow		implement authorization assertion scheme. The mechanism MUST
	support of other assertion schemes, which would be optional to		also allow support of other assertion schemes, which would be
	implement. One example of an assertion scheme is SAML [6].		optional to implement. One example of an assertion scheme is
	8. The mechanism MUST ensure reference integrity between a SIP		SAML [6].
			8. The mechanism MUST ensure reference integrity between a SIP
	request and assertion. Reference integrity refers to the		request and assertion. Reference integrity refers to the
	relationship between a SIP message and the assertion authorizing		relationship between a SIP message and the assertion authorizing
	the message. For example, a reference integrity check would		the message. For example, a reference integrity check would
	compare the sender of the message (as expressed in the SIP		compare the sender of the message (as expressed in the SIP
	request, for example in the "From" header field value) with the		request, for example in the "From" header field value) with the
	identity provided by the assertion. Reference integrity is		identity provided by the assertion. Reference integrity is
	necessary to prevent various sorts of relay and impersonation		necessary to prevent various sorts of relay and impersonation
	attacks. Note that reference integrity MAY apply on a		attacks. Note that reference integrity MAY apply on a per-
	per-message, per-transaction, or per-dialog basis.		message, per-transaction, or per-dialog basis.
	9. Assertion schemes used for this mechanism MUST be capable of		9. Assertion schemes used for this mechanism MUST be capable of
	asserting attributes and/or traits associated with the identity		asserting attributes and/or traits associated with the identity
	of the principal originating a SIP request. No specific traits		of the principal originating a SIP request. No specific traits
	or attributes are required by this specification.		or attributes are required by this specification.
	10. The mechanism MUST support a means for end-users to specify		10. The mechanism MUST support a means for end-users to specify
	policies to an authorization service for the distribution of		policies to an authorization service for the distribution of
	their traits and/or attributes to various destinations.		their traits and/or attributes to various destinations.
	11. The mechanism MUST provide a way of preventing unauthorized		11. The mechanism MUST provide a way of preventing unauthorized
	parties (either intermediaries or endpoints) from viewing the		parties (either intermediaries or endpoints) from viewing the
	contents of assertions.		contents of assertions.
	12. Assertion schemes MUST provide a way of selectively sharing the		12. Assertion schemes MUST provide a way of selectively sharing the
	skipping to change at page 13, line 34 ¶		skipping to change at page 13, line 41 ¶
	The distribution of authorization assertions requires numerous		The distribution of authorization assertions requires numerous
	security properties. An authorization service must be able to sign		security properties. An authorization service must be able to sign
	assertions, or provide some similar cryptographic assurance that can		assertions, or provide some similar cryptographic assurance that can
	provide non-repudiation for assertions. These requirements are		provide non-repudiation for assertions. These requirements are
	further detailed in Section 3.		further detailed in Section 3.
	7. IANA Considerations		7. IANA Considerations
	This document introduces no considerations for the IANA.		This document introduces no considerations for the IANA.
	8. References		Appendix A. Acknowledgments
	8.1 Normative References		The authors thank Christopher Eagan for his valuable input.
			8. References
			8.1. Normative References
	[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, May 2002.		Session Initiation Protocol", RFC 3261, May 2002.
	[2] Bradner, S., "Key words for use in RFCs to indicate requirement		[2] Bradner, S., "Key words for use in RFCs to indicate requirement
	levels", RFC 2119, March 1997.		levels", RFC 2119, March 1997.
	8.2 Informative References		8.2. Informative References
	[3] Peterson, J., "Enhancements for Authenticated Identity		[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated
	Management in the Session Initiation Protocol (SIP)",		Identity Management in the Session Initiation Protocol (SIP)",
	draft-ietf-sip-peterson-identity-04 (work in progress), February		draft-ietf-sip- identity-06 (work in progress), October 2005.
	2005.
	[4] Burger, E., "A Mechanism for Content Indirection in SIP		[4] Burger, E., "A Mechanism for Content Indirection in SIP
	Messages", draft-ietf-sip-content-indirect-mech-05 (work in		Messages", draft-ietf-sip-content-indirect-mech-05 (work in
	progress), October 2004.		progress), October 2004.
	[5] Peterson, J., "A Privacy Mechanism for the Session Initiation		[5] Peterson, J., "A Privacy Mechanism for the Session Initiation
	Protocol (SIP)", RFC 3323, November 2002.		Protocol (SIP)", RFC 3323, November 2002.
	[6] Organization for the Advancement of Structured Industry		[6] Organization for the Advancement of Structured Industry
	Standards, "Security Assertion Markup Language v1.0", November		Standards, "Security Assertion Markup Language v1.0",
	2002, <http://www.oasis-open.org>.		November 2002, <http://www.oasis-open.org>.
	Authors' Addresses		Authors' Addresses
	Jon Peterson		Jon Peterson
	NeuStar, Inc.		NeuStar, Inc.
	1800 Sutter St		1800 Sutter St
	Suite 570		Suite 570
	Concord, CA 94520		Concord, CA 94520
	US		US
	Phone: +1 925/363-8720		Phone: +1 925/363-8720
	EMail: jon.peterson@neustar.biz		Email: jon.peterson@neustar.biz
	URI: http://www.neustar.biz/		URI: http://www.neustar.biz/
	James M. Polk		James M. Polk
	Cisco Systems		Cisco Systems
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Suite 570		Suite 570
	Richardson, TX 75802		Richardson, TX 75802
	US		US
	EMail: jmpolk@cisco.com		Email: jmpolk@cisco.com
	Douglas C. Sicker		Douglas C. Sicker
	University of Colorado at Boulder		University of Colorado at Boulder
	ECOT 531		ECOT 531
	Boulder, CO 80309		Boulder, CO 80309
	US		US
	EMail: douglas.sicker@colorado.edu		Email: douglas.sicker@colorado.edu
	Hannes Tschofenig		Hannes Tschofenig
	Siemens AG		Siemens AG
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich 81739		Munich 81739
	Germany		Germany
	EMail: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	Appendix A. Acknowledgments
	The authors thank Christopher Eagan for his valuable input.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 16, line 41 ¶		skipping to change at page 16, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 35 change blocks.
	84 lines changed or deleted		86 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/