< draft-tschofenig-sip-saml-03.txt		draft-tschofenig-sip-saml-04.txt >
	SIP H. Tschofenig		SIP H. Tschofenig
	Internet-Draft Siemens		Internet-Draft Siemens
	Expires: January 7, 2006 J. Peterson		Expires: January 19, 2006 J. Peterson
	NeuStar, Inc.		NeuStar, Inc.
	J. Polk		J. Polk
	Cisco		Cisco
	D. Sicker		D. Sicker
	CU Boulder		CU Boulder
	M. Tegnander		M. Tegnander
	LYIT		LYIT
	July 6, 2005		July 18, 2005
	Using SAML for SIP		Using SAML for SIP
	draft-tschofenig-sip-saml-03.txt		draft-tschofenig-sip-saml-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		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
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 January 7, 2006.		This Internet-Draft will expire on January 19, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes how to use the Security Assertion Markup		This document defines a mechanism for using the Security Assertion
	Language (SAML) to offer trait-based authorization. As such, it		Markup Language (SAML) in concert with the Session Initiation
	provides an alternative to existing authorization mechanisms for SIP.		Protocol (SIP). In particular, it provides a way for SIP to refer to
			SAML objects, and for recipients of SIP messages to use SAML in order
			to make more informed authorization decisions.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . 5		3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . 5
	4. SAML Introduction . . . . . . . . . . . . . . . . . . . . . 6		4. SAML Introduction . . . . . . . . . . . . . . . . . . . . . 6
	4.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.2 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3 Request/Response Protocol . . . . . . . . . . . . . . . . 7		4.3 Request/Response Protocol . . . . . . . . . . . . . . . . 7
	4.4 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.4 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.5 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.5 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Assertion Handling Models . . . . . . . . . . . . . . . . . 9		5. Assertion Handling Models . . . . . . . . . . . . . . . . . 9
	6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 14		6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6.1 Network Asserted Identities . . . . . . . . . . . . . . . 14		6.1 Network Asserted Identities . . . . . . . . . . . . . . . 14
	6.2 SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 16		6.2 SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 16
	6.3 PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 17		6.3 PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 17
	6.4 Compensation using SIP and SAML . . . . . . . . . . . . . 18		6.4 Compensation using SIP and SAML . . . . . . . . . . . . . 18
	7. SIP-SAML Extension . . . . . . . . . . . . . . . . . . . . . 20		7. SIP-SAML Extension . . . . . . . . . . . . . . . . . . . . . 20
	8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9. Requirement Comparison . . . . . . . . . . . . . . . . . . . 23		9. Requirement Comparison . . . . . . . . . . . . . . . . . . . 23
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	scenarios are presented in [I-D.ietf-sipping-trait-authz].		scenarios are presented in [I-D.ietf-sipping-trait-authz].
	Security Assertion Markup Language (SAML) [I-D.saml-tech-overview-		Security Assertion Markup Language (SAML) [I-D.saml-tech-overview-
	1.1-03] is an XML extension for security information exchange that is		1.1-03] is an XML extension for security information exchange that is
	being developed by OASIS. SAML is a XML-based framework for creating		being developed by OASIS. SAML is a XML-based framework for creating
	and exchanging security information.		and exchanging security information.
	To provide trait-based authorization a few solutions are possible:		To provide trait-based authorization a few solutions are possible:
	authorization certificates, SPKI or extensions to the authenticated		authorization certificates, SPKI or extensions to the authenticated
	identity body [I-D.ietf-sip-authid-body]. The authors selected SAML		identity body [I-D.ietf-sip-authid-body]. The authors selected SAML
	due to the amount of work done in the area of SAML which provides		due to its increasing use in environments such as the Liberty
	some assurance that this technology is mature enough.		Alliance and the Internet2 project, areas where the applicability to
			SIP is widely desired.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The SIP entity 'Authentication Service' was introduced with		The SIP entity 'Authentication Service' was introduced with
	[I-D.ietf-sip-identity]. We reuse this term to refer to an entity		[I-D.ietf-sip-identity]. We reuse this term to refer to an entity
	that authenticates and authorizes a user and creates an assertion.		that authenticates and authorizes a user and creates an assertion.
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 36 ¶
	o The attributes stored in assertions are, for example, roles,		o The attributes stored in assertions are, for example, roles,
	membership to a certain organization, specific access rights or		membership to a certain organization, specific access rights or
	information about the authentication. A definition of most of		information about the authentication. A definition of most of
	these attributes is application dependent and not defined in this		these attributes is application dependent and not defined in this
	document. The SAML specification itself provides a number of		document. The SAML specification itself provides a number of
	common attributes and provides extension points for future		common attributes and provides extension points for future
	enhancements. A brief overview of the available attributes within		enhancements. A brief overview of the available attributes within
	an assertion is given in Section 4.1.		an assertion is given in Section 4.1.
			In order for SAML to be used in a practical system, participating
			entities must agree on attributes and traits that will be used.
			Without this pre-existing agreement, SAML cannot be usefully
			deployed. This document does not discuss the manner in which
			participating entites might discover one another or agree on the
			syntax and semantics of attributes and traits.
	o SIP is not used as a request/response protocol between the Relying		o SIP is not used as a request/response protocol between the Relying
	Party and the Asserting Party to fetch an assertion based on a		Party and the Asserting Party to fetch an assertion based on a
	received artifact.		received artifact.
	4. SAML Introduction		4. SAML Introduction
	In SAML there are three main entities: the user, the asserting party		In SAML there are three main entities: the user, the asserting party
	and the relying party. A user requests an assertions and receives		and the relying party. A user requests assertions and receives them
	them after a successful authentication and authorization protocol		after a successful authentication and authorization protocol
	execution. The asserting party provides assurance that a particular		execution. The asserting party provides assurance that a particular
	user has been given proper authorization. The relying party has to		user has been given proper authorization. The relying party has to
	trust the asserting party with regard to the provided information and		trust the asserting party with regard to the provided information and
	then decides whether or not to accept the assertions provided, giving		then decides whether or not to accept the assertions provided, giving
	different levels of privileges.		different levels of privileges.
	The components of SAML are:		The components of SAML are:
	o Assertions/Artifact		o Assertions/Artifact
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 36 ¶
	The artifact used in the Browser/Artifact profile, is a base-64		The artifact used in the Browser/Artifact profile, is a base-64
	encoded string that is 40 bytes long. 20 bytes consists of the		encoded string that is 40 bytes long. 20 bytes consists of the
	typecode, which is the source id. The remaining 20 bytes consists of		typecode, which is the source id. The remaining 20 bytes consists of
	a random number that servers use to look up an assertion. The source		a random number that servers use to look up an assertion. The source
	server stores the assertion temporarily. The destination server		server stores the assertion temporarily. The destination server
	receives the artifact and pulls the assertion from the source site.		receives the artifact and pulls the assertion from the source site.
	The purpose of the artifact is to act as a token that references an		The purpose of the artifact is to act as a token that references an
	assertion for the subject who holds the artifact.		assertion for the subject who holds the artifact.
			Note that artifacts were designed to be used specifically in a web
			context where the asserting party is clear due to the client/server
			nature of the protocol. Artifacts are not globally-derefenceable;
			one cannot tell simply be inspecting an artifact out of context which
			server generated the artifact. For the more peer-to-peer
			architecture of SIP, enhancements are required to make the context of
			artifact generation known to relying parties.
	4.3 Request/Response Protocol		4.3 Request/Response Protocol
	SAML defines a request/response protocol for obtaining assertions.		SAML defines a request/response protocol for obtaining assertions.
	The request asks for an assertion or makes queries for		The request asks for an assertion or makes queries for
	authentication, attribute and authorization decisions. The response		authentication, attribute and authorization decisions. The response
	carries back the requested assertion.		carries back the requested assertion.
	4.4 Bindings		4.4 Bindings
	The bindings in SAML maps between the SAML protocol and a transport		The bindings in SAML maps between the SAML protocol and a transport
	skipping to change at page 8, line 16 ¶		skipping to change at page 8, line 24 ¶
	When using a profile, SAML is used to provide assertions about a		When using a profile, SAML is used to provide assertions about a
	resource in the body of the message itself. In Version 1.1 of SAML,		resource in the body of the message itself. In Version 1.1 of SAML,
	there are two profiles specified, the Browser/Artifact profile and		there are two profiles specified, the Browser/Artifact profile and
	the Browser/POST profile. The Browser/Artifact profile represents a		the Browser/POST profile. The Browser/Artifact profile represents a
	"pull" model, where a special reference to the assertion called an		"pull" model, where a special reference to the assertion called an
	artifact, is sent to the relying party from the asserting party. The		artifact, is sent to the relying party from the asserting party. The
	artifact is then used to "pull" the assertion from the asserting		artifact is then used to "pull" the assertion from the asserting
	party. The Browser/POST profile represents a "push" model, where an		party. The Browser/POST profile represents a "push" model, where an
	assertion is posted (using the HTTP POST command) directly to the		assertion is posted (using the HTTP POST command) directly to the
	relying party. These two models are described in Figure 1 and		relying party. These two models are described in Figure 2 and
	Figure 2.		Figure 1.
	5. Assertion Handling Models		5. Assertion Handling Models
	As mentioned in Section 4.5, two main models can be used in SAML and		As mentioned in Section 4.5, two main models can be used in SAML and
	therefore also with the SIP-SAML extension defined in this document:		therefore also with the SIP-SAML extension defined in this document:
	The Push and the Pull model.		The Push and the Pull model.
	In the Pull model the end host requests an assertion from the		A 'Push' model (or mode) means to transmit information towards
	Asserting Party and receives, after successful authentication and		another entity. Here we call that transmitting the information 'by-
	authorization, an artifact. The artifact is a special form of an		value'. An example of this model (or mode) is an email attachment
	assertion. This artifact can be compared with the call-by reference		(file). That attachment is included in the original transmission, as
	approach where a reference to the assertion is stored at the		is 'by-value'.
	Asserting Party and can later be dereferenced into the real assertion
	on a request by a replying party. The Relying Party later fetches		Whereas, a 'Pull' model (or mode) means to transmit an identifier for
	the SAML assertion after receiving a request by the user which		where a piece of information is (located somewhere else). This
	includes the artifact. For communicating the SAML request and		piece of information still requires retrieval by the receiver of this
	response messages, a separate message exchange is needed with a		transmission. Here we call that transmitting the information 'by-
	protocol such as SOAP or HTTP. This is outside the scope of this		reference'. An example of this model (or mode) is including a URI in
	document.		that email, to be accessed directly by the receiver of the email in a
			subsequent operation.
			Either the end host or an intermediate proxy might request an
			assertion or an artifact. The Push and the Pull model used for HTTP
			does not match with its usage in SIP.
			With the 'per-value' model either a user requests an assertion from
			the Asserting Party or the user triggers the Asserting Party to
			attach an assertion to the outgoing request. The assertion, which is
			added to the service request, can be verified by the Relying Party
			without additional protocol interactions with the Asserting Party.
			The assertion therefore contains enough information to authorize the
			service request.
			Figure 1 shows the protocol exchange where the user fetches the
			assertion.
	+----------+ +--------------+ +--------------+		+----------+ +--------------+ +--------------+
	| User | | Asserting | | Relying |		| User | | Asserting | | Relying |
	| | | Party | | Party |		| | | Party | | Party |
	+----+-----+ +------+-------+ +------+-------+		+----+-----+ +------+-------+ +------+-------+
	| | |		| | |
	| Request Assertion | |		| Request Assertion | |
	|--------------------->| |		|--------------------->| |
	| | |		| | |
	| User Authentication | |		| User Authentication | |
	| and Authorization | |		| and Authorization | |
	|<---------------------| |		|<---------------------| |
	|--------------------->| |		|--------------------->| |
	| | |		| | |
	| Artifact | |		| Assertion | |
	|<---------------------| |		|<---------------------| |
	| | |		| | |
	| Request + Artifact |		| Request + Assertion |
	|----------------------+------------------------->|		|----------------------+------------------------->|
	| | |		| | |
	| | SAML request |
	| |<-------------------------|
	| | |
	| |SAML response + Assertion |
	| |------------------------->|
	| | |		| | |
	| Accept/Reject |		| Accept/Reject |
	|<---------------------+--------------------------|		|<---------------------+--------------------------|
	| | |		| | |
	Figure 1: SAML Pull model		Figure 1: Example for a 'Per-value' Interaction
	With the Push model, the user requests an assertion from the		With the 'per-reference' model either the user contacts the Asserting
	Asserting Party. The user can also trigger the Asserting Party to		Party to obtain an artifact or the user triggers the Asserting Party
	attach an assertion to the request. The assertion, which is added to		to attach the artifact to the outgoing request. The artifact is a
	the service request, can be verified by the Relying Party without		reference to an assertion is stored at the Asserting Party and can
	additional protocol interactions with the Asserting Party. The		later be dereferenced into the assertion on a request. The Relying
	assertion therefore contains enough information to authorize the		Party later fetches the SAML assertion after receiving the artifact
	service request. This model realizes a call-by value style of		by the user. For communicating the SAML request and response
	communication.		messages, a separate message exchange is needed with a protocol, such
			as SOAP. A description of this protocol interaction is outside the
			scope of this document.
			Figure 2 shows an example protocol interaction where the user fetches
			the artifact.
	+----------+ +--------------+ +--------------+		+----------+ +--------------+ +--------------+
	| User | | Asserting | | Relying |		| User | | Asserting | | Relying |
	| | | Party | | Party |		| | | Party | | Party |
	+----+-----+ +------+-------+ +------+-------+		+----+-----+ +------+-------+ +------+-------+
	| | |		| | |
	| Request Assertion | |		| Request Assertion | |
	|--------------------->| |		|--------------------->| |
	| | |		| | |
	| | |
	| User Authentication | |		| User Authentication | |
	| and Authorization | |		| and Authorization | |
	|<---------------------| |		|<---------------------| |
	|--------------------->| |		|--------------------->| |
	| | |		| | |
	| | |		| Artifact | |
	| Assertion | |
	|<---------------------| |		|<---------------------| |
	| | |		| | |
	| Request + Assertion |		| Request + Artifact |
	|----------------------+------------------------->|		|----------------------+------------------------->|
	| | |		| | |
			| | SAML request |
			| |<-------------------------|
			| | |
			| |SAML response + Assertion |
			| |------------------------->|
	| | |		| | |
	| Accept/Reject |		| Accept/Reject |
	|<---------------------+--------------------------|		|<---------------------+--------------------------|
	| | |		| | |
	Figure 2: SAML Push model		Figure 2: Example for a 'Per-reference' Interaction
	The usage of SAML in HTTP-based environments and in SIP is, however,		The usage of SAML in HTTP-based environments and in SIP is, however,
	affected by some architectural differences.		affected by some architectural differences.
	The function of the entities in the Push and the Pull model are shown
	in Figure 1 and in Figure 2.
	The user has to request an assertion at the Asserting Party and both		The user has to request an assertion at the Asserting Party and both
	entities mutually authenticate each other. The requested assertion		entities mutually authenticate each other. The requested assertion
	is sent to the user in a confidential manner to prevent eavesdroppers		is sent to the user in a confidential manner to prevent eavesdroppers
	from obtaining this assertion. The Relying Party trusts the		from obtaining this assertion. The Relying Party trusts the
	Asserting Party. It is assumed that the accessed resource is located		Asserting Party. It is assumed that the accessed resource is located
	at the Relying Party and that this entity does not become malicious		at the Relying Party and that this entity does not become malicious
	or act on behalf of the user to impersonate him or her to other		or act on behalf of the user to impersonate him or her to other
	parties with regard to access to his resources. To prevent some		parties with regard to access to his resources. To prevent some
	degree of misuse, attributes in the assertion limit its applicability		degree of misuse, attributes in the assertion limit its applicability
	for certain applications, servers or time frame.		for certain applications, servers or time frame.
	skipping to change at page 12, line 20 ¶		skipping to change at page 12, line 20 ¶
	confidentially protected to prevent eavesdroppers between the SIP UA		confidentially protected to prevent eavesdroppers between the SIP UA
	and the SIP proxy to learn the assertion), can store this assertion		and the SIP proxy to learn the assertion), can store this assertion
	to impersonate the user in future requests towards other SIP end		to impersonate the user in future requests towards other SIP end
	users. The fact that multiple parties see the assertion along the		users. The fact that multiple parties see the assertion along the
	path (i.e., SIP proxies) make the situation worse. The assertion		path (i.e., SIP proxies) make the situation worse. The assertion
	might include some attributes which restrict its usage (such as		might include some attributes which restrict its usage (such as
	recipient(s), unique identifier for the message or a time-based		recipient(s), unique identifier for the message or a time-based
	constraint) but they cannot fully prevent impersonation.		constraint) but they cannot fully prevent impersonation.
	This problem appears if SAML assertions are not bound to a particular		This problem appears if SAML assertions are not bound to a particular
	protocol run. Binding the assertion to a particular protocol session		SIP transaction or dialog. Binding the assertion to a particular
	is not useful if the property of single-sign on is required.		protocol session is not useful if the property of single-sign on is
			required.
	To provide referential integrity, a solution as mentioned in		To provide referential integrity the solution described in [I-D.ietf-
	[I-D.ietf-sip-authid-body] can be used. which allows a party in a SIP		sip-authid-body] can be reused. Such an approach allows a party in a
	transaction to cryptographically sign the headers that assert the		SIP transaction to cryptographically sign the headers that assert the
	identity of the originator of a message, and provide some other		identity of the originator of a message, and provide some other
	headers necessary for reference integrity. An authenticated identity		headers necessary for reference integrity. An authenticated identity
	body (AIB) is a MIME body of type 'message/sipfrag'. This MIME body		body (AIB) is a MIME body of type 'message/sipfrag'. This MIME body
	has a Content-Disposition type of 'aib'. The MIME body is optional.		has a Content-Disposition type of 'aib'. The MIME body is optional.
	The header fields From, Contact, Date and Call-ID must be used for		The header fields From, Contact, Date and Call-ID must be used for
	providing identity. Contact and Date header fields are required for		providing identity. Contact and Date header fields are required for
	providing reference integrity. AIBs may contain other headers that		providing reference integrity. AIBs may contain other headers that
	help to uniquely identify the transaction or that provides related		help to uniquely identify the transaction or that provides related
	reference integrity.		reference integrity.
	skipping to change at page 15, line 4 ¶		skipping to change at page 15, line 4 ¶
	binding to the SIP message in order to prevent cut-and-paste attacks.		binding to the SIP message in order to prevent cut-and-paste attacks.
	The provided SAML assertion can then be used to assist during the		The provided SAML assertion can then be used to assist during the
	authorization procedure. If Bob does not understand the extension		authorization procedure. If Bob does not understand the extension
	defined in this document, he silently ignores it. When the 200 OK		defined in this document, he silently ignores it. When the 200 OK
	message arrives at Bob's AS, the same procedure as when Alice sent		message arrives at Bob's AS, the same procedure as when Alice sent
	her INVITE to her AS can be performed, if desired. This exchange is		her INVITE to her AS can be performed, if desired. This exchange is
	not shown in Figure 4.		not shown in Figure 4.
	Note that this scenario does not imply that the SAML assertions are		Note that this scenario does not imply that the SAML assertions are
	solely used by SIP UAs. Assertions can also be helpful for SIP		solely used by SIP UAs. Assertions can also be helpful for SIP
	proxies or B2B UAs. Additionally, a push model is shown in this		proxies or B2B UAs.
	section but it is reasonable to use a pull as well. For simplicity
	reasons a push model should be prefered since an additional message
	exchange between the Authentication Service and the UA can be
	omitted.
	+--------+ +--------------+ +--------+		+--------+ +--------------+ +--------+
	|Alice@ | |Authentication| | Bob@ |		|Alice@ | |Authentication| | Bob@ |
	|example | |Service | |example2|		|example | |Service | |example2|
	|.com | |@example.com | |com |		|.com | |@example.com | |com |
	| | | | | |		| | | | | |
	+---+----+ +------+-------+ +---+----+		+---+----+ +------+-------+ +---+----+
	| | |		| | |
	| INVITE | |		| INVITE | |
	|---------------------->| |		|---------------------->| |
	skipping to change at page 20, line 11 ¶		skipping to change at page 20, line 11 ¶
	of a service access. In fact, the assertion might specify these type		of a service access. In fact, the assertion might specify these type
	of constraints directly or indirectly with the help of recurring		of constraints directly or indirectly with the help of recurring
	service requests/responses.		service requests/responses.
	7. SIP-SAML Extension		7. SIP-SAML Extension
	To carry SAML assertions and artifacts two mechanisms are defined:		To carry SAML assertions and artifacts two mechanisms are defined:
	o The SIP header may either carry an Artifcat or a CID URI [RFC2392]		o The SIP header may either carry an Artifcat or a CID URI [RFC2392]
	pointing to an assertion in the SIP body. The name of this new		pointing to an assertion in the SIP body. The name of this new
	SIP header is SAML-Payload. A SAML artifact consists of a		SIP header is SAML-Assertion. A SAML artifact consists of a
	TypeCode, SourceID and an AssertionHandle. It is thereby assumed		TypeCode, SourceID and an AssertionHandle. It is thereby assumed
	that the Relying Party will maintain a table of sourceID values as		that the Relying Party will maintain a table of sourceID values as
	well as URLs for Asserting Parties to contact. This information		well as URLs for Asserting Parties to contact. This information
	is communicated out-of-band. This document also allows the		is communicated out-of-band. This document also allows the
	Asserting Party to add a URL to point to the assertion to prevent		Asserting Party to add a URL to point to the assertion to prevent
	this level of indirection.		this level of indirection.
	o The SIP body may carry one or more SAML assertions. The MIME type		o The SIP body may carry one or more SAML assertions. The MIME type
	of this SAML assertion is defined in [I-D.hodges-saml-mediatype].		of this SAML assertion is defined in [I-D.hodges-saml-mediatype].
	skipping to change at page 25, line 16 ¶		skipping to change at page 25, line 16 ¶
	To avoid this kind of attack, the entities must assure that proper		To avoid this kind of attack, the entities must assure that proper
	mechanisms for protecting the SAML assertion needs to be in place.		mechanisms for protecting the SAML assertion needs to be in place.
	It is recommended to protect the assertion using a digital		It is recommended to protect the assertion using a digital
	signature.		signature.
	10.4 Replay Attack		10.4 Replay Attack
	Threat:		Threat:
	In the case of using SIP with the SAML pull model, the threat of		In the case of using SIP with a 'by-reference' model, the threat
	replay lies in the fact that the artifact is a one-time-use		of replay lies in the fact that the artifact is a one-time-use
	subject. The same artifact can be used again to gain access to		subject. The same artifact can be used again to gain access to
	resources.		resources.
	Countermeasures:		Countermeasures:
	Cases where multiple requests are made which references the same		Cases where multiple requests are made which references the same
	request must be tracked in order to avoid the threat.		request must be tracked in order to avoid the threat.
	11. Contributors		11. Contributors
	skipping to change at page 29, line 36 ¶		skipping to change at page 29, line 36 ¶
	Canonicalization versus Replication:		Canonicalization versus Replication:
	To provide reference integrity a few selected fields need to be		To provide reference integrity a few selected fields need to be
	hashed, signed and placed into the assertion. Two approaches are		hashed, signed and placed into the assertion. Two approaches are
	available for this purpose. Hence it needs to be studied how the		available for this purpose. Hence it needs to be studied how the
	interworking between reference integrity and the usage of obtained		interworking between reference integrity and the usage of obtained
	SAML assertion can be properly accomplished. For example, who		SAML assertion can be properly accomplished. For example, who
	indicates which fields are included?		indicates which fields are included?
			Alignment with SIP Identity:
			It might be good to avoid the definition of a second set of
			response codes for SAML conditions which will overlap with the
			response codes defined for SIP Identity draft.
	Placement of Assertions and Keys in Messages:		Placement of Assertions and Keys in Messages:
	This document assumes that the assertions are added to the SIP		This document assumes that the assertions are added to the SIP
	body and artifacts or references to assertions located in the SIP		body and artifacts or references to assertions located in the SIP
	body are added to the SIP header. A central question is therefore		body are added to the SIP header. A central question is therefore
	where these assertions should be attached? Should the SIP user		where these assertions should be attached? Should the SIP user
	agent or intermediate SIP proxies add assertions/artifacts? In		agent or intermediate SIP proxies add assertions/artifacts? In
	the scenarios depicted in Section 6, we have both approaches		the scenarios depicted in Section 6, we have both approaches
	depending on what kind of scenario it is. In Figure 4, they are		depending on what kind of scenario it is. In Figure 4, they are
	added at the UA and in contrast we have Figure 7, where the		added at the UA and in contrast we have Figure 7, where the
	skipping to change at page 35, line 5 ¶		skipping to change at page 34, line 45 ¶
	US		US
	Email: douglas.sicker@colorado.edu		Email: douglas.sicker@colorado.edu
	Marcus Tegnander		Marcus Tegnander
	Letterkenny Institute of Technology		Letterkenny Institute of Technology
	Port Road		Port Road
	Letterkenny, Donegal		Letterkenny, Donegal
	Ireland		Ireland
			Email: schwed@gmail.com
	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
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
End of changes. 30 change blocks.
	63 lines changed or deleted		102 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/