< draft-ietf-sipping-trait-authz-00.txt		draft-ietf-sipping-trait-authz-01.txt >
	SIPPING WG J. Peterson		SIPPING WG J. Peterson
	Internet-Draft NeuStar		Internet-Draft NeuStar
	Expires: August 7, 2004 J. Polk		Expires: August 17, 2005 J. Polk
	Cisco		Cisco
	D. Sicker		D. Sicker
	CU Boulder		CU Boulder
	H. Tschofenig		H. Tschofenig
	Siemens		Siemens
	February 7, 2004		February 16, 2005
	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-00		draft-ietf-sipping-trait-authz-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	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 Internet-		other groups may also distribute working documents as
	Drafts.		Internet-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 http://		The list of current Internet-Drafts can be accessed at
	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 7, 2004.		This Internet-Draft will expire on August 17, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	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 . . . . . . . . . . . . . . . . . 7
	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		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
	Normative References . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Informative References . . . . . . . . . . . . . . . . . . . . 14		8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
			8.2 Informative References . . . . . . . . . . . . . . . . . . . 13
	A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . 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
	attributes of the principal that originated a SIP request.		attributes of the principal that originated a SIP request.
	skipping to change at page 4, line 48 ¶		skipping to change at page 4, line 48 ¶
	architectures have been proposed to provide single sign-on services		architectures have been proposed to provide single sign-on services
	across multiple providers.		across multiple providers.
	Although trait-based identity offers an alternative to traditional		Although trait-based identity offers an alternative to traditional
	identity architectures, this effort should be considered		identity architectures, this effort should be considered
	complementary to the end-to-end cryptographic SIP identity effort		complementary to the end-to-end cryptographic SIP identity effort
	[3]. An authentication service might also act as an authorization		[3]. An authentication service might also act as an authorization
	service, generating some sort of trait assertion token instead of an		service, generating some sort of trait assertion token instead of an
	authenticated identity body.		authenticated identity body.
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
	RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as		RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
	described in RFC2119 [2] and indicate requirement levels for		described in RFC2119 [2] and indicate requirement levels for
	compliant SIP implementations.		compliant SIP implementations.
	3. Trait-based Authorization Framework		3. Trait-based Authorization Framework
	A trait-based authorization architecture entails the existence of an		A trait-based authorization architecture entails the existence of an
	authorization service. Devices must send requests to an		authorization service. Devices must send requests to an
	authorization service in order to receive an assertion that can be		authorization service in order to receive an assertion that can be
	used in the context of a given network request. Different network		used in the context of a given network request. Different network
	request types will often necessitate different or additional		request types will often necessitate different or additional
	attributes in assertions from the authorization service.		attributes in assertions from the authorization service.
	For the purposes of SIP, SIP requests might be supplied to an		For the purposes of SIP, SIP requests might be supplied to an
	authorization service to provide the basis for an assertion. It		authorization service to provide the basis for an assertion. It
	skipping to change at page 7, line 42 ¶		skipping to change at page 7, line 42 ¶
	Trait-based authorization has significant applicability to SIP.		Trait-based authorization has significant applicability to SIP.
	There are numerous instances in which it is valuable to assert		There are numerous instances in which it is valuable to assert
	particular facts about a principal other than the principal's		particular facts about a principal other than the principal's
	identity to aid the recipient of a request in making an authorization		identity to aid the recipient of a request in making an authorization
	policy decision. For example, a telephony service provider might		policy decision. For example, a telephony service provider might
	assert that a particular user is a 'customer' as a trait. An		assert that a particular user is a 'customer' as a trait. An
	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 34 ¶
	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
	skipping to change at page 9, line 36 ¶		skipping to change at page 9, line 36 ¶
	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 'mci.com'). Since these assertions would
	travel end-to-end from the originating service provider to the		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 17 ¶
	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 44 ¶
	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 33 ¶		skipping to change at page 11, line 33 ¶
	authorization assertion is returned to the end host of the SIP UAC		authorization assertion is returned to the end host of the SIP UAC
	(cryptographically protected). If QoS is necessary, the end host		(cryptographically protected). If QoS is necessary, the end host
	might reuse the returned assertion in the QoS signaling protocol.		might reuse the returned assertion in the QoS signaling protocol.
	Any domains in the federation that would honor the assertion		Any domains in the federation that would honor the assertion
	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]).
	3. Authorization services MUST be capable of delivering an		4. Authorization services MUST have a way to authenticate a SIP UAC.
	assertion to a SIP UAC, either by reference or by value. It MAY		5. The assertions generated by authorization services MUST be
	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 per-		attacks. Note that reference integrity MAY apply on a
	message, per-transaction, or per-dialog basis.		per-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
	traits and/or attributes of the principal in question. In other		traits and/or attributes of the principal in question. In other
	words, it must be possible to show only some of the attributes		words, it must be possible to show only some of the attributes
	of a given principal to particular recipients, based on the		of a given principal to particular recipients, based on the
	cryptographically- assured identity of the recipient.		cryptographically- assured identity of the recipient.
	13. It MUST be possible to provide an assertion that contains no		13. It MUST be possible to provide an assertion that contains no
	identity - that is, to present only attributes or traits of the		identity - that is, to present only attributes or traits of the
	principal making a request, rather than the identity of the		principal making a request, rather than the identity of the
	principal.		principal.
	14. The manner in which an assertion is distributed MUST permit		14. The manner in which an assertion is distributed MUST permit
	cryptographic authentication and integrity properties to be		cryptographic authentication and integrity properties to be
	applied to the assertion by the authorization service.		applied to the assertion by the authorization service.
	15. It MUST be possible for a UAS or proxy server to reject a		15. It MUST be possible for a UAS or proxy server to reject a
	request that lacks a present and valid authorization assertion,		request that lacks a present and valid authorization assertion,
	and to inform the sending UAC that it must acquire such an		and to inform the sending UAC that it must acquire such an
	assertion in order to complete the request.		assertion in order to complete the request.
	16. The recipient of a request containing an assertion MUST be able		16. The recipient of a request containing an assertion MUST be able
	to ascertain which authorization service generated the		to ascertain which authorization service generated the
	assertion.		assertion.
	17. It MUST be possible for a UAS or proxy server to reject a		17. It MUST be possible for a UAS or proxy server to reject a
	request containing an assertion that does not provide any		request containing an assertion that does not provide any
	attributes or traits that are known to the recipient, or that		attributes or traits that are known to the recipient, or that
	are relevant to the request in question.		are relevant to the request in question.
	18. It SHOULD be possible for a UAC to attach multiple assertions to		18. It SHOULD be possible for a UAC to attach multiple assertions to
	a single SIP request, in cases where multiple authorization		a single SIP request, in cases where multiple authorization
	services must provide assertions in order for a request to		services must provide assertions in order for a request to
	complete.		complete.
	6. Security Considerations		6. Security Considerations
	The subject of this document is an authorization system for SIP that		The subject of this document is an authorization system for SIP that
	is not predicated on the distribution of end-users' identities, but		is not predicated on the distribution of end-users' identities, but
	rather shares traits of the users. As such, the bulk of this		rather shares traits of the users. As such, the bulk of this
	document discusses security.		document discusses security.
	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.
	Normative References		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.
	Informative References		8.2 Informative References
	[3] Peterson, J., "Enhancements for Authenticated Identity		[3] Peterson, J., "Enhancements for Authenticated Identity
	Management in the Session Initiation Protocol (SIP)", draft-		Management in the Session Initiation Protocol (SIP)",
	ietf-sip-peterson-identity-01 (work in progress), July 2002.		draft-ietf-sip-peterson-identity-04 (work in progress), February
			2005.
	[4] Olson, S., "A Mechanism for Content Indirection in SIP		[4] Burger, E., "A Mechanism for Content Indirection in SIP
	Messages", draft-ietf-sip-content-indirect-mech-03 (work in		Messages", draft-ietf-sip-content-indirect-mech-05 (work in
	progress), June 2003.		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", November
	2002, <http://www.oasis-open.org>.		2002, <http://www.oasis-open.org>.
	Authors' Addresses		Authors' Addresses
	skipping to change at page 15, line 20 ¶		skipping to change at page 15, line 4 ¶
	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		Appendix A. Acknowledgments
	The authors thank Christopher Eagan for his valuable input.		The authors thank Christopher Eagan for his valuable input.
	Full Copyright Statement		Intellectual Property Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			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
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
	This document and translations of it may be copied and furnished to		Copies of IPR disclosures made to the IETF Secretariat and any
	others, and derivative works that comment on or otherwise explain it		assurances of licenses to be made available, or the result of an
	or assist in its implementation may be prepared, copied, published		attempt made to obtain a general license or permission for the use of
	and distributed, in whole or in part, without restriction of any		such proprietary rights by implementers or users of this
	kind, provided that the above copyright notice and this paragraph are		specification can be obtained from the IETF on-line IPR repository at
	included on all such copies and derivative works. However, this		http://www.ietf.org/ipr.
	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		The IETF invites any interested party to bring to its attention any
	revoked by the Internet Society or its successors or assigns.		copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
	This document and the information contained herein is provided on an		Disclaimer of Validity
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	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		This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM 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.
			Copyright Statement
			Copyright (C) The Internet Society (2005). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
			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. 50 change blocks.
	101 lines changed or deleted		99 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/