< draft-tschofenig-enroll-bootstrapping-saml-00.txt		draft-tschofenig-enroll-bootstrapping-saml-01.txt >
	Credential and Provisioning H. Tschofenig		Credential and Provisioning H. Tschofenig
	(Enroll) Siemens		(Enroll) Siemens
	Internet-Draft G. Giaretta		Internet-Draft G. Giaretta
	Expires: August 16, 2005 TILab		Expires: January 19, 2006 TILab
	A. Gomez-Skarmeta		A. Gomez-Skarmeta
	University of Murcia		University of Murcia
	February 12, 2005		J. Polk
			Cisco
			July 18, 2005
	Enriching Bootstrapping with Authorization Information		Enriching Bootstrapping with Authorization Information
	draft-tschofenig-enroll-bootstrapping-saml-00.txt		draft-tschofenig-enroll-bootstrapping-saml-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she 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		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 16, 2005.		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
	Some work has been done in the area of bootstrapping in the IETF		Bootstrapping refers to the process of creating state (typically
	recently. Bootstrapping refers to the process of creating state		security associations) between two or more entities based on a trust
	(typically security associations) between two or more entities based		relationship between these two or more parties AND a trusted third
	on a trust relationship between these two or more parties and a		party. Some work has been done in the area of bootstrapping in the
	trusted third party. So far work has mostly focused on creating		IETF recently. So far, the focus was on creating security
	security associations. This document aims to attach authorization		associations. This document aims to attach authorization information
	information to the bootstrapping process.		to the bootstrapping process.
	Table of Contents		Table of Contents
	1. Introduction and Problem Statement . . . . . . . . . . . . . . 3		1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1 Authorization in QoS signaling protocols . . . . . . . . . 9		4.1 Authorization in QoS signaling protocols . . . . . . . . . 9
	4.2 SIP Service Bootstrapping . . . . . . . . . . . . . . . . 11		4.2 SIP Service Bootstrapping . . . . . . . . . . . . . . . . 11
	5. Obtaining a SAML Artifact/Assertion . . . . . . . . . . . . . 13		5. Obtaining a SAML Artifact/Assertion . . . . . . . . . . . . . 13
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	9.2 Informative References . . . . . . . . . . . . . . . . . . 22		9.2 Informative References . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
	Intellectual Property and Copyright Statements . . . . . . . . 26		Intellectual Property and Copyright Statements . . . . . . . . 26
	1. Introduction and Problem Statement		1. Introduction and Problem Statement
	Some work has been done in the area of bootstrapping in the IETF		Some work has been done in the area of bootstrapping in the IETF
	recently. The goal of bootstrapping is to create state (typically		recently. The goal of bootstrapping is to create state (typically
	security related information such as security associations) between		security related information such as security associations) between
	two or more entities. We focus on the two party case and call them		two or more entities. We focus on the two party case and call them
	Alice and Bob. To securely establish state is simple if (a) Alice		Alice and Bob. To securely establish state is simple if (a) Alice and
	and Bob share some information to protect the signaling exchange		Bob share some information to protect the signaling exchange (e.g.,
	(e.g., share secret or the ability to verify a digital signature) and		shared secret or the ability to verify a digital signature) and (b)
	(b) if they are able to authorize the other party. (a) is the		if they are able to authorize the other party. The following
	problem of key management problem and (b) addresses an important		statements describe (a) the problem of key management and (b)
	aspect in real world deployments - authorization.		addresses an important aspect in real world deployments -
			authorization.
	Hence, to develop a satisfactory bootstrapping solution it is		Hence, to develop a satisfactory bootstrapping solution it is
	necessary to solve these two aspects:		necessary to solve these two aspects:
	o In order to solve the key management problem a number of		o In order to solve the key management problem, a number of
	mechanisms have been introduced including bootstrapping		mechanisms have been introduced including bootstrapping
	mechanisms. For example, [9] and [10] give an overview of		mechanisms. For example, [9] and [10] give an overview of
	bootstrapping (and imprinting) and give protocol and architectural		bootstrapping (and imprinting) and describe protocol and
	considerations. Moreover, the problem of bootstrapping is a hot		architectural considerations. Moreover, the problem of
	topic in MIP6 WG: for a Mobile IPv6 bootstrapping problem		bootstrapping is a hot topic in MIP6 WG: for a Mobile IPv6
	statement see [11]. Several solutions have also been proposed so		bootstrapping problem statement see [11]. Several solutions have
	far: some of them, such as [12] and [13], exploit the		also been proposed so far: some of them, such as [12] and [13],
	authentication and protocol exchanges performed by the mobile node		exploit the authentication and protocol exchanges performed by the
	for network access (e.g. PANA, EAP) in order to bootstrap a		mobile node for network access (e.g., PANA, EAP) in order to
	Mobile IPv6 security association with the HA: in this way, to		bootstrap a Mobile IPv6 security association with the HA: in this
	bootstrap a MIPv6 SA no other authentication phase is needed.		way, to bootstrap a MIPv6 SA no other authentication phase is
	Other solutions are completely independent from network access		needed. Other solutions are completely independent from network
	authentication: for example, [14] proposes to use IKEv2, while		access authentication: for example, [14] proposes to use IKEv2,
	with [15] a MIPv6 security association for [16] is created using		while with [15] a MIPv6 security association for [16] is created
	PANA [1]. Finally, a solution for bootstrapping a DHCP RFC 3118		using PANA [1]. Finally, a solution for bootstrapping a DHCP RFC
	[17] security association using EAP/PANA was specified in [18] and		3118 [17] security association using EAP/PANA was specified in
	in [19] and a proposal to bootstrap a Kerberos Ticket Granting		[18] and in [19] and a proposal to bootstrap a Kerberos Ticket
	Ticket based on a successful EAP protocol exchange is provided in		Granting Ticket based on a successful EAP protocol exchange is
	[20].		provided in [20]. Recently, two further contributions [21] and
			[22] were published that aim to reuse EAP for the purpose of
			bootstrapping information.
	o The aspect of authorization has received little attention in the		o The aspect of authorization has received little attention in the
	existing literature. Its importance has been discovered during		existing literature. Its importance has been discovered during
	the work on the EAP keying framework [21] document but does not go		the work on the EAP keying framework [23] document but does not go
	beyond investigating information carried by AAA protocols.		beyond investigating information carried by AAA protocols.
	Actually the authentication and the implicit authorization		Actually, the authentication and the implicit authorization
	performed through a pre-shared key or a key management protocol		performed through a pre-shared key or a key management protocol
	may not be sufficient to conclude that a node (a user) is		may not be sufficient to conclude that a node (a user) is
	authorized for a particular service. Considering the case of		authorized for a particular service. Considering the case of
	Mobile IPv6 service as an example, the fact that the MN shares a		Mobile IPv6 service as an example, the fact that the MN shares a
	pre-shared key with the Home Agent and is able to setup an IPsec		pre-shared key with the Home Agent and is able to setup an IPsec
	Security Association to protect Mobile IPv6 signaling does not		Security Association to protect Mobile IPv6 signaling does not
	imply that it is authorized to provide the Mobile IPv6 service.		imply that it is authorized to provide the Mobile IPv6 service.
	For example the Mobility Service Provider (MSP) might want to		For example, the Mobility Service Provider (MSP) might want to
	prevent the usage of MIPv6 if the credit of the MN is going to		prevent the usage of MIPv6 if the credit of the MN is going to
	exhaust or based on the time of the day. This implies that		exhaust or based on the time of the day. This implies that
	solving the key management problem is not enough to bootstrap a		solving the key management problem is not enough to bootstrap a
	service: a mechanism to explicitely authorize th user is needed to		service: a mechanism to explicitly authorize the user is needed to
	design a bootstrapping solution.		design a bootstrapping solution.
	This document describes a "single sign-on" framework that addresses		This document describes a "single sign-on" framework that addresses
	these issues through the usage of EAP and the AAA infrastracture of		these issues through the usage of EAP and the AAA infrastructure of
	the involved service providers (i.e. the home and the visited		the involved service providers (i.e., the home and the visited
	service providers). This framework does not depend on the EAP		service providers). This framework does not depend on a particular
	method, the EAP lower layer, the AAA protocol used even if some EAP		EAP method, the EAP lower layer, the AAA protocol used. Several
	method (e.g. PEAPv2, which creates a secure channel between the		mechanisms can be used to carry authorization data, such as Diameter,
	client and the server) and some EAP lower layer (e.g. PANA) could		PANA or EAP.
	bring some (more) benefits. Several mechanisms can be used to carry
	authorization data, such as Diameter, PANA or EAP.
	This document addresses authorization by utilizing capabilities of		This document addresses authorization by utilizing capabilities of
	the Security Assertion Markup Language (SAML). For details about		the Security Assertion Markup Language (SAML). For details about
	SAML see [2], [3] and [22]. Please note that it would be possible to		SAML see [2], [3] and [24]. Please note that it would be possible to
	use other languages for describing authorization capabilities as		use other languages for describing authorization capabilities as
	well, such as SPKI [23] or X.509 Authorization Certificates [24].		well, such as SPKI [25] or X.509 Authorization Certificates [26].
	Based on the previously published solution it can be seen that the		Based on the previously published solution, it can be seen that the
	Extensible Authentication Protocol (EAP) [4] plays an important role		Extensible Authentication Protocol (EAP) [4] plays an important role
	in a bootstrapping solution since		in a bootstrapping solution since
	o it provides support for multiple authentication and key exchange		o it provides support for multiple authentication and key exchange
	protocols;		protocols.
	o allows three entities to be involved (EAP peer, EAP server and the		o allows three entities to be involved (EAP peer, EAP server and the
	Authenicator);		Authenticator).
	o extensively deployed in the context of operational environments.		o extensively deployed in the context of operational environments.
	As a protocol between the Authenticator and the EAP server RADIUS [5]		As a protocol between the Authenticator and the EAP server RADIUS [5]
	and DIAMETER [6] are important to complete the architecture.		and DIAMETER [6] are important to complete the architecture.
	The manage of the authorization process related to the bootstrapping		The manage of the authorization process related to the bootstrapping
	is being considered as an important aspect of the services deployment		is being considered as an important aspect of the services deployment
	within the next generation networks. In this context the proposal of		within the next generation networks. In this context, this document
	this document is to describe how the use of SAML could provide the		aims to describe how the SAML could be used to provide the user
	user consumer of a service of the material needed to access in a		consumer of a service of the material needed to access in a secure
	secure way the services and to link it with the permission and grants		way the services and to link it with the permission and grants
	associated to the user.		associated to the user.
	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 [7].		document are to be interpreted as described in [7].
	3. Framework		3. Framework
	This section illustrates the bootstrapping framework and the involved		This section illustrates the bootstrapping framework and the involved
	entities. The framework is based on a single sign-on paradigm: a		entities. The framework is based on a single sign-on paradigm: a
	first authentication and authorization protocol exchange is exploited		first authentication and authorization protocol exchange is exploited
	to exchange general authorization data and to bootstrap subsequent		to exchange general authorization data and to bootstrap subsequent
	security associations and services. The framework is independent		security associations and services. The framework is independent
	from the container used to carry the needed authorization data;		from the container used to carry the needed authorization data;
	however in this draft the usage of SAML is described, since it seems		however, in this draft the usage of SAML has been taken into account,
	to offer several advantages.		since it offers several advantages such as extensility, flexibilty
			etc.,
	Figure 1 shows the entities typically involved in bootstrapping.		Figure 1 shows the entities typically involved in bootstrapping.
	+---------------+ +---------------+		+---------------+ +---------------+
	| | (A) | |		| | (A) | |
	| Bootstrapping |<-------------------> | Bootstrapping |		| Bootstrapping |<-------------------> | Bootstrapping |
	| Client (BC) | Protocol or | Agent (BA) |		| Client (BC) | Protocol or | Agent (BA) |
	| | API | |		| | API | |
	+---------------+ +---------------+		+---------------+ +---------------+
	^		^
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 37 ¶
	Protocol or |(B)		Protocol or |(B)
	API |		API |
	v		v
	+---------------+		+---------------+
	| |		| |
	| Bootstrapping |		| Bootstrapping |
	| Target (BT) |		| Target (BT) |
	| |		| |
	+---------------+		+---------------+
	Figure 1: Bootstrapping Framework		Figure 1: Bootstrapping Framework
	Existing bootstrapping proposals nicely fit into this architecture.		Existing bootstrapping proposals nicely fit into this architecture.
	Below we provide an attempt for classification based on the following		Below, we provide an attempt for classification based on the
	distinguishing properties:		following distinguishing properties:
	o Which protocol is used between the BC and the BA?		o Which protocol is used between the BC and the BA?
	o Which protocol is used between the BA and the BT?		o Which protocol is used between the BA and the BT?
	o What information is bootstrapped?		o What information is bootstrapped?
	The authors argue that the first two bullets are the most important		Ideally, a generic bootstrapping protocol would provide enough
	once. Ideally a generic bootstrapping protocol would provide enough		flexibility for bootstrapping a variety of (bootstrapping) data
	flexility for bootstrapping a variety of bootstrapping data items.		items.
	As an example we classify a few proposals:		As an example, we list a few proposals and show their properties in
			the subsequent table below:
	+---------------+----------+----------+-------------------+		+---------------+----------+----------+-------------------+
	| Protocol | BC<->BA | BA<->BT | Bootstrapped Info |		| Proposal | BC<->BA | BA<->BT | Bootstrapped Info |
	+---------------+----------+----------+-------------------+		+---------------+----------+----------+-------------------+
	|IKEv2 (1) | IKEv2 | API | IPsec SAs |		|IKEv2 (1) | IKEv2 | API | IPsec SAs |
	|...............|..........|..........|...................|		|...............|..........|..........|...................|
	|Jee et al. (2) | PANA + |DIAMETER | IKE SA |		|Jee et al. (2) | PANA + |DIAMETER | IKE SA |
	| | DIAMETER | | |		| | DIAMETER | | |
	|...............|..........|..........|...................|		|...............|..........|..........|...................|
	|Tschofenig et | | | |		|Tschofenig et | | | |
	| al (3) | PANA | API | SA for MIP6 Auth. |		| al (3) | PANA | API | SA for MIP6 Auth. |
	|...............|..........|..........|...................|		|...............|..........|..........|...................|
	|MIP6 Auth.(4) | MIP6 Ext.| API | SA for MIP6 Auth. |		|MIP6 Auth.(4) | MIP6 Ext.| API | SA for MIP6 Auth. |
	|...............|..........|..........|...................|		|...............|..........|..........|...................|
	|Giaretta et al.| EAP | Not | IKE SA |		|Giaretta et al.| EAP | Not | IKE SA |
	| (5) | | specified| |		| (5) | | specified| |
	|...............|..........|..........|...................|		|...............|..........|..........|...................|
	|Bournelle et | PANA | Not | IKE SA |		|Bournelle et | PANA | Not | IKE SA |
	| al (6) | | specified| |		| al (6) | | specified| |
	+---------------+----------+----------+-------------------+		+---------------+----------+----------+-------------------+
	where (1) refers to [25], [14] and also to , (2) refers to [12], (3)		where (1) refers to [27], [14] and also to , (2) refers to [12], (3)
	refers to [15], (4) refers to [16], (5) refers to [13] and (6) refers		refers to [15], (4) refers to [16], (5) refers to [13] and (6) refers
	to [26]. It is a matter of taste to call [25] or [16] a		to [28]. It is a matter of taste to call [27] or [16] a
	bootstrapping protocol.		bootstrapping protocol.
	The bootstrapping framework, shown in Figure 1, can nicely be mapped		The bootstrapping framework, shown in Figure 1, can nicely be mapped
	to the Authorization Framework Figure 3. The Bootstrapping client		to the Authorization Framework shown in Figure 3. The Bootstrapping
	corresponds to the entity that is used to request the		client corresponds to the entity that is used to request the
	assertion/artifact, the Bootstrapping Agent can be related to the		assertion/artifact, the Bootstrapping Agent can be related to the
	Assertion Granting Entity and the Assertion Verifying Entity		Assertion Granting Entity and the Assertion Verifying Entity
	corresponds to the Bootstrapping Target.		corresponds to the Bootstrapping Target.
	When Alice is successfully authorized it receives the Artifact either
	via PANA, IKEv2 or any other protected channel established via
	certain EAP methods. Alice might want to make the Artifact available
	to other protocols. When Alice wants to make a service request with
	Bob then the Artifact is attached. Bob will need to interact with
	Cecil in order to fetch the Assertion. Bob might want to use
	DIAMETER to fetch the Assertion and to execute functions such as
	accounting and credit control. DIAMETER is particularly attractive
	if keying material needs to be distribued to create a security
	association between Alice and Bob to secure subsequent communication.
	If the establishment of keying material is not important then other
	mechanisms (such as HTTP) could be used.
	+----------------+ Trust Relationship +----------------+		+----------------+ Trust Relationship +----------------+
	| +------------+ |<.......................>| +------------+ |		| +------------+ |<.......................>| +------------+ |
	| | Protocol | | | | Assertion | |		| | Protocol | | | | Assertion | |
	| | requesting | | Request | | Granting | |		| | requesting | | Request | | Granting | |
	| | authz | |------------------------>| | Entity | |		| | authz | |------------------------>| | Entity | |
	| | assertions | |<------------------------| +------------+ |		| | assertions | |<------------------------| +------------+ |
	| +------------+ | Artifact/Assertion | Entity Cecil |		| +------------+ | Artifact/Assertion | Entity Cecil |
	| ^ | +----------------+		| ^ | +----------------+
	| | | ^ ^|		| | | ^ ^|
	| | | . || HTTP or		| | | . || HTTP or
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 29 ¶
	| | | v |v		| | | v |v
	| v | +----------------+		| v | +----------------+
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| | Protocol | | Service Request + | | Assertion | |		| | Protocol | | Service Request + | | Assertion | |
	| | using authz| | Assertion/Artifact | | Verifying | |		| | using authz| | Assertion/Artifact | | Verifying | |
	| | assertion | | ----------------------- | | Entity | |		| | assertion | | ----------------------- | | Entity | |
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| Entity Alice | <---------------------- | Entity Bob |		| Entity Alice | <---------------------- | Entity Bob |
	+----------------+ Response/Error +----------------+		+----------------+ Response/Error +----------------+
	Figure 3: Authorization Framework		Figure 3: Authorization Framework
			When Alice is successfully authenticated and authorized by Bob, he
			receives the Artifact either via PANA, IKEv2 or any other protected
			channel established via certain EAP methods. Alice might want to
			make the Artifact available to other protocols. When Alice wants to
			make a service request with Bob then the Artifact is attached. Bob
			will need to interact with Cecil in order to fetch the Assertion.
			Bob might want to use DIAMETER to fetch the Assertion and to execute
			functions such as accounting and credit control. DIAMETER is
			particularly attractive if keying material needs to be distribtued to
			create a security association between Alice and Bob to secure
			subsequent communication. If the establishment of keying material is
			not important then other mechanisms (such as HTTP) could be used.
	4. Scenarios		4. Scenarios
	The content of this section is partially based on [27] which		The content of this section is partially based on [29] which
	addresses trait-based authorization in SIP. This document has a		addresses trait-based authorization in SIP. This document has a
	strong relationship with [27] but aims to be more generic (instead of		strong relationship with [29] but aims to be more generic (instead of
	focusing on SIP). Furthermore, Section 4.1 borrows also from [28]		focusing on SIP). Furthermore, Section 4.1 borrows also from [30]
	and from [29].		and from [31].
	Two scenarios are meant to illustrate the functionality of SAML for		Two scenarios are meant to illustrate the functionality of SAML for
	authorization in combination with bootstrapping. First, we describe		authorization in combination with bootstrapping. First, we describe
	how authorization in a QoS signaling environment can be used and then		how authorization in a QoS signaling environment can be used and then
	we illustrate a SIP service authorization example.		we illustrate a SIP service authorization example.
	4.1 Authorization in QoS signaling protocols		4.1 Authorization in QoS signaling 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 also requires multiple
	the entity enforcing the decisions and the entity computing the		messages between the entity enforcing the decisions and the entity
	authorization decision. Particularly in a mobile environment these		computing the authorization decision. Particularly, in a mobile
	entities are physically separated - or not even in the same		environment these entities are physically separated - or not even in
	administrative domain. Accordingly, the notion of "single sign-on"		the same administrative domain. Accordingly, the notion of "single
	is another potential application of authorization assertions, and		sign-on" is another potential application of authorization
	trait-based authorization - a user is authenticated and authorized		assertions, and trait-based authorization - a user is authenticated
	through one protocol, and can reuse the resulting authorization		and authorized through one protocol, and can reuse the resulting
	assertion in other, potential unrelated protocol exchanges.		authorization assertion in other, unrelated protocol exchanges.
	For example, in some environments it is useful to make the		For example, in some environments it is useful to make the
	authorization decision for a "high-level" service (such a voice		authorization decision for a "high-level" service (such a voice
	call). The authorization for the "voice call" itself might include		call). The authorization for the "voice call" itself might include
	authorization for SIP signaling and also for lower level network		authorization for SIP signaling and also for lower level network
	functions, for example a quality-of-service (QoS) reservation to		functions, for example a quality-of-service (QoS) reservation to
	improve the performance of real-time media sessions established by		improve the performance of real-time media sessions established by
	SIP. Since the SIP signaling protocol and the QoS reservation		SIP. Since the SIP signaling protocol and the QoS reservation
	protocol are totally separate, it is necessary to link the		protocol are totally separate, it is necessary to link the
	authorization decisions of the two protocols. The authorization		authorization decisions of the two protocols. The authorization
	decision might be valid for a number of different protocol exchanges,		decision might be valid for a number of different protocol exchanges,
	for different protocols and for a certain duration or some other		for different protocols and for a certain duration or some other
	attributes.		attributes.
	To enable this mechanism as part of the initial authorization step an		To enable this mechanism as part of the initial authorization step,
	authorization assertion is returned to the end host of the SIP UAC		an 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 similarly honor the
	of the assertion in the context of QoS. Upon the initial generation		use of the assertion in the context of QoS. Upon the initial
	of the assertion by an authorization server, traits could be added		generation of the assertion by an authorization server, traits could
	that specify the desire level of quality that should be granted to		be added that specify the desire level of quality that should be
	the media associated with a SIP session.		granted to the media associated with a SIP session.
	The message flow shown in Figure 4 illustrates such an exchange where		The message flow shown in Figure 4 illustrates such an exchange where
	a client (such as a SIP user agent) uses some signaling exchange		a client (such as a SIP user agent) uses some signaling exchange
	which allows the end host to obtain an Artifact. This is Artifact is		which allows the end host to obtain an Artifact. This is Artifact is
	later used as input for a QoS signaling protocol and provides client		later used as an input for a QoS signaling protocol and provides
	authorization. The QoS aware router can either process the request		client authorization. The QoS aware router can either process the
	locally or use the Diameter QoS application for verifying the		request locally or use the Diameter QoS application for verifying the
	authorization decision at the entity which created the Artifact. In		authorization decision at the entity which created the Artifact. In
	order to perform the processing local it is required to obtain an		order to perform the processing locally, it is required to obtain an
	Assertion rather than an Artifact (which is not further illustrated		Assertion rather than an Artifact (which is not further illustrated
	in Figure 4). The DIAMETER QoS application contacts the Application		in Figure 4). The DIAMETER QoS application contacts the Application
	Server to obtain the Assertion, to authorize the request and to start		Server to obtain the Assertion, to authorize the request and to start
	accounting.		accounting.
	Diameter QoS		Diameter QoS
	Application		Application
	Enabled Router Application		Enabled Router Application
	Enforcement Pt Server		Enforcement Pt Server
	Application +		Application +
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 45 ¶
	| | \ + / |		| | \ + / |
	| Authorization \- + -/ |		| Authorization \- + -/ |
	| Enforcement -+-- |		| Enforcement -+-- |
	| Decision + |		| Decision + |
	| | + |		| | + |
	| | + |		| | + |
	| Allow or Terminate Flow |		| Allow or Terminate Flow |
	<-----------+*+------------------------->		<-----------+*+------------------------->
	| | + |		| | + |
	Figure 4: Message flow with NSIS and Diameter QoS Application		Figure 4: Message flow with NSIS and Diameter QoS Application
	4.2 SIP Service Bootstrapping		4.2 SIP Service Bootstrapping
	This scenario exploits the inclusion of SAML for SIP which has been		This scenario exploits the inclusion of SAML for SIP which has been
	introduced with [30].		introduced with [32].
	In Figure 5 user Alice runs a protocol with an Authentication Server		In Figure 5, user Alice runs a protocol with an Authentication Server
	whereby authentication and authorization is provided. This protocol		whereby authentication and authorization is provided. This protocol
	exchange might be based on a number of protocols, such as EAP, PANA,		exchange might be based on a number of protocols, such as EAP, PANA,
	HTTP or something similar. It is not required that the		HTTP or something similar. It is not required that the
	authentication and key exchange protocol terminates at this entity		authentication and key exchange protocol terminates at this entity
	but the Artificat is created and returned the the user (based on a		but the Artifact is created and returned the user (based on a
	successful protocol execution). When a SIP message (e.g., an INVITE)		successful protocol execution). When a SIP message (e.g., an INVITE)
	is sent towards a SIP Server or even to another SIP UA then the		is sent towards a SIP Server or even to another SIP UA then the
	Artifact is attached to the SIP message. As shown in Figure 5 the		Artifact is attached to the SIP message. As shown in Figure 5 the
	SIP service contacts the Authentication Server (for example via		SIP service contacts the Authentication Server (for example via
	DIAMETER) to request the Assertion. This message exchange also		DIAMETER) to request the Assertion. This message exchange also
	allows the SIP service to obtain keying material.		allows the SIP service to obtain keying material.
	+--------+ +--------------+ +--------+		+--------+ +--------------+ +--------+
	|User | |Authentication| |SIP |		|User | |Authentication| |SIP |
	|Alice | |Server | |Service |		|Alice | |Server | |Service |
	skipping to change at page 12, line 29 ¶		skipping to change at page 12, line 42 ¶
	| | Fetch Assertion |		| | Fetch Assertion |
	| |<---------------------|		| |<---------------------|
	| | |		| | |
	| | Assertion |		| | Assertion |
	| |--------------------->|		| |--------------------->|
	| | |		| | |
	| 200 OK | |		| 200 OK | |
	|<----------------------+----------------------|		|<----------------------+----------------------|
	| | |		| | |
	Figure 5: Message flow for SIP service authorization		Figure 5: Message flow for SIP service authorization
	5. Obtaining a SAML Artifact/Assertion		5. Obtaining a SAML Artifact/Assertion
	This section describes how an end host obtains an Artifact via PANA		This section describes how an end host obtains an Artifact via PANA
	or EAP which subsequently be used for service authorization.		or EAP which subsequently be used for service authorization.
	Depending on whether the home network or the visited network should		Depending on whether the home network or the visited network should
	create an Assertion/Artifact EAP and/or PANA will be used. If for		create an Assertion/Artifact EAP and/or PANA will be used. If for
	example, services in the visited network should be authorized then an		example, services in the visited network should be authorized then an
	entity in the visited network should create the Assertion/Artifact		entity in the visited network should create the Assertion/Artifact
	and it will be returned via PANA to the end host.		and it will be returned via PANA to the end host.
	skipping to change at page 13, line 25 ¶		skipping to change at page 13, line 25 ¶
	It is not suggested to exchange a SAML Assertion either via EAP or		It is not suggested to exchange a SAML Assertion either via EAP or
	via PANA. An Assertion is an XML document which is, for security		via PANA. An Assertion is an XML document which is, for security
	reasons, digitally signed. Both PANA and EAP/EAP methods suffer from		reasons, digitally signed. Both PANA and EAP/EAP methods suffer from
	size limitations. EAP and most EAP methods do not support		size limitations. EAP and most EAP methods do not support
	fragmentation. PANA should avoid IP layer fragmentation.		fragmentation. PANA should avoid IP layer fragmentation.
	A number of mechanisms exist to fetch an Assertion with the help of		A number of mechanisms exist to fetch an Assertion with the help of
	an Artifact. HTTP is the most common mechanisms. This document also		an Artifact. HTTP is the most common mechanisms. This document also
	suggests to use DIAMETER to assist in this step since it additionally		suggests to use DIAMETER to assist in this step since it additionally
	allows to distribute previously created keying material, to benefit		allows to distribute previously created keying material, to benefit
	from accounting extensions [31] and other DIAMETER applications such		from accounting extensions [33] and other DIAMETER applications such
	as Credit Control [32].		as Credit Control [34].
	EDITOR's Note: A "notification" mechanism might be useful to indicate		EDITOR's Note: A "notification" mechanism might be useful to indicate
	that the user wants to obtain an Artifact (or that the server does		that the user wants to obtain an Artifact (or that the server does
	not provide this extension).		not provide this extension).
	5.1 SAML Artifact transport in EAP methods		5.1 SAML Artifact transport in EAP methods
	Currently there are a number of EAP authentication methods that have		Currently, there are a number of EAP authentication methods that have
	the capability to convey generic information items (e.g., PEAPv2		the capability to convey generic information items (e.g., PEAPv2
	[33], EAP-PSK [34] or EAP-IKEv2 [35]). In fact they are being used		[35], EAP-PSK [36] or EAP-IKEv2 [37]). In fact they are being used
	send additional information during authentication proccess inside a		to send additional information during authentication process inside a
	protected channel between an EAP peer and the authenticator or		protected channel between an EAP peer and the authenticator or
	between the EAP peer and the EAP server in the case authenticator is		between the EAP peer and the EAP server in the case authenticator is
	acting as a pass-through. This capability is, for example, being		acting as a pass-through. This capability is, for example, being
	considered to transport MIPv6 authorization data [13]. Following		considered to transport MIPv6 authorization data [13]. Following
	this approach SAML information (i.e., the SAML artifact) could be		this approach, a SAML artifact could be conveyed within an EAP method
	conveyed in this kinds of EAP methods too by creating another payload		(by creating another payload/AVP that carries this information).
	or AVP that carries this information.
	5.2 SAML Artifact transport in PANA		5.2 SAML Artifact transport in PANA
	Another alternative, that would allow to use EAP methods that are not		Another alternative, that would allow to use EAP methods that are not
	able to transport generic information (e.g., EAP-TLS [36]), is to use		able to transport generic information (e.g., EAP-TLS [38]), is to use
	PANA protocol to convey authorization information (SAML artifact)		PANA protocol to convey authorization information (SAML artifact)
	from the PANA Authentication Agent (PAA) to the PANA Authentication		from the PANA Authentication Agent (PAA) to the PANA Authentication
	Client (PaC). The usage of PANA provides more flexibility with		Client (PaC). The usage of PANA provides more flexibility with
	respect to the entity creating the artifact and the bootstrapped		respect to the entity creating the artifact and the bootstrapped
	service. This circumstance is shown in Figure 6. The PANA protocol		service. This circumstance is shown in Figure 6. The PANA protocol
	is used between the PAA and PaC. It might be necessary that a AAA		is used between the PAA and PaC. It might be necessary that a AAA
	server is contacted. EAP is carried inside PANA and might then again		server is contacted. EAP is carried inside PANA and might then again
	be encapsulated into a AAA protocol such as RADIUS or DIAMETER (see		be encapsulated into a AAA protocol such as RADIUS or DIAMETER (see
	[37] and [38]). AAA interaction with EAP is typically the case if a		[39] and [40]). AAA interaction with EAP is typically the case if a
	user roams to a visited network and the EAP method runs between the		user roams to a visited network and the EAP method runs between the
	EAP peer and the EAP server (whereby the EAP server is at the user's		EAP peer and the EAP server (whereby the EAP server is at the user's
	home network). The service which will be later used might be at a		home network). The service which will be later used might be at a
	different administrative domain. The service could be at the visited		different administrative domain. The service could be at the visited
	network, at the home network or at any other network. To allow		network, at the home network or at any other network. To allow
	bootstrapping to work it is necessary to have an existing trust		bootstrapping to work, it is necessary to have an existing trust
	relationship between the entity that created the SAML assertion and		relationship between the entity that created the SAML assertion and
	the service which will later use it. DIAMETER might be used between		the service which will later use it. DIAMETER might be used between
	these two entities to transfer keying material (and other		these two entities to transfer keying material (and other
	information).		information).
	If PANA terminates at the first hop router, as proposed in [1], then		If PANA terminates at the first hop router, as proposed in [1], then
	PANA allows to create the SAML artifact in the visited network (by		PANA allows to create the SAML artifact in the visited network (by
	some entity) and to subsequently use services either in the visited		some entity) and to subsequently use services either in the visited
	network itself (as shown in Figure 4 or in networks which have some		network itself (as shown in Figure 4 or in networks which have some
	trust relationship with the visited network with regard to the later		trust relationship with the visited network with regard to the later
	skipping to change at page 15, line 32 ¶		skipping to change at page 15, line 32 ¶
	|		|
	|API/AAA		|API/AAA
	v		v
	+----------------+		+----------------+
	| Entity |		| Entity |
	| Running the |		| Running the |
	| bootstrapped |		| bootstrapped |
	| Service |		| Service |
	+----------------+		+----------------+
	Figure 6: SAML Artifact transport in PANA		Figure 6: SAML Artifact transport in PANA
	To create a working solution it is necessary that the SAML artifact		To create a feasible solution, it is necessary that the SAML artifact
	can be carried in a AAA protocol (e.g., DIAMETER or RADIUS) between		can be carried in a AAA protocol (e.g., DIAMETER or RADIUS) between
	the AAA server and the PAA and is then finally delivered from the PAA		the AAA server and the PAA and is then finally delivered from the PAA
	to the PaC by using PANA. According to the PANA specification [1]		to the PaC by using PANA. According to the PANA specification [1]
	the PANA-FirstAuth-End-Request (PFER) (if both NAP and ISP		the PANA-FirstAuth-End-Request (PFER) (if both NAP and ISP
	authentication is carried out) and/or Pana-Binding-Request (PBR)		authentication is carried out) and/or Pana-Binding-Request (PBR)
	message can transport new AVPs. Confidentiality protection must be		message can transport new AVPs. Confidentiality protection must be
	provided for this purpose. Authorization information could be		provided for this purpose. Authorization information could be
	carried by defining new AVPs to be transported inside these messages.		carried by defining new AVPs to be transported inside these messages.
	Note that new attributes or AVPs to carry SAML in DIAMETER (or		Note that the new attributes or AVPs to carry SAML in DIAMETER (or
	RADIUS) also need to be defined.		RADIUS) also need to be defined.
	6. Binding Authorization Information to Credentials		6. Binding Authorization Information to Credentials
	SAML introduces the concept of a holder-of-the-key assertion to bind		SAML introduces the concept of a holder-of-the-key assertion to bind
	the assertions (authorization information) to a cryptographic key.		the assertions (authorization information) to a cryptographic key.
	See Section 5.1 of [2]		See Section 5.1 of [2]
	A number of credentials can be used with the KeyInfo element of the		A number of credentials can be used with the KeyInfo element of the
	Holder-of-the-Key assertion as described in Section 4.4 of [8], such		Holder-of-the-Key assertion as described in Section 4.4 of [8], such
	skipping to change at page 16, line 39 ¶		skipping to change at page 16, line 39 ¶
	o SPKIData element carries information related to SPKI public key		o SPKIData element carries information related to SPKI public key
	pairs, certificates and other SPKI data.		pairs, certificates and other SPKI data.
	o MgmtData element can contain a string value used to convey in-band		o MgmtData element can contain a string value used to convey in-band
	key distribution or agreement data		key distribution or agreement data
	These concept allows the SAML assertion to be associated with the		These concept allows the SAML assertion to be associated with the
	bootstrapped credentials. For example, binding a public key to a		bootstrapped credentials. For example, binding a public key to a
	SAML assertion might also be a helpful when the public / private key		SAML assertion might also be a helpful when the public / private key
	pair is also bootstrapped based using EAP and uses a pseudonym to		pair is also bootstrapped based using EAP and uses a pseudonym to
	allow user identity confidentiality. In this case this approach		allow user identity confidentiality. In this case, this approach
	would provide credential based authorization. This would then allow		would provide credential based authorization. This would then allow
	subsequent application layer protocols interactions to be secured		subsequent application layer protocols interactions to be secured
	while authorization information can be attached and provided via		while authorization information can be attached and provided via
	SAML.		SAML.
	Binding a Kerberos Ticket Granting Ticket or a Kerberos Service		Binding a Kerberos Granting Ticket or a Kerberos Service Ticket to a
	Ticket to a SAML assertion is also possible but a Kerberos ticket		SAML assertion is also possible but a Kerberos ticket does not have a
	does not have a unique identifier, such as a SerialNumber provided by		unique identifier, such as a SerialNumber provided by X.509
	X.509 certificates. One possible approach to attach the same unique		certificates. One possible approach is to attach the same unique and
	and randomly chosen identifier to both, the KeyName element and to		randomly chosen identifier to both, the KeyName element and to the
	the authorization-data field of the encrypted part of the Kerberos		authorization-data field of the encrypted part of the Kerberos
	ticket.		ticket.
	Furthermore, it is possible to binding the SAML assertion to the		Furthermore, it is possible to bind the SAML assertion to the AAA-
	AAA-key. This binding therefore associates the network		key. This binding, therefore, associates the network authentication
	authentication and authorization protocol run to the assertion. Each		and authorization protocol run to the assertion. Each time the user
	time the user needs to re-authenticate, the assertion can be		needs to re-authenticate, the assertion can be presented to grant
	presented to grant access to the network (and also allowing the both		access to the network (and also allowing the both entities to
	entities to generate a new AAA-key). Such a procedure might be		generate a new AAA-key). Such a procedure might be helpful when
	helpful when handovers within different access routers in the access		handovers within different access routers in the access network is
	network is desired (intra-domain mobility) or even with inter-domain		desired (intra-domain mobility) or even with inter-domain mobility.
	mobility.
	7. Security Considerations		7. Security Considerations
	The security of the proposed mechanism relies on the selected EAP		The security of the proposed mechanism relies on the selected EAP
	method, on SAML and on the bootstrapping mechanism. A security		method, on SAML and on the bootstrapping mechanism. A security
	analysis of different EAP methods is outside the scope of this		analysis of different EAP methods is outside the scope of this
	document. It is assumed that the bootstrapping mechanism (possibly		document. It is assumed that the bootstrapping mechanism (possibly
	involving AAA key distribution mechanisms) and the selected EAP		involving AAA key distribution mechanisms) and the selected EAP
	method is secure.		method is secure.
	skipping to change at page 19, line 26 ¶		skipping to change at page 19, line 26 ¶
	It is recommended to protect the assertion using a digital		It is recommended to protect the assertion using a digital
	signature. Note that the current proposal uses Artifacts in most		signature. Note that the current proposal uses Artifacts in most
	places (EAP methods or PANA) and makes it therefore difficult for		places (EAP methods or PANA) and makes it therefore difficult for
	an adversary to be able to mount such an attack.		an adversary to be able to mount such an attack.
	7.4 Replay Attack		7.4 Replay Attack
	Threat:		Threat:
	An adversary who is able to gain access to an Assertion or an		An adversary who is able to gain access to an Assertion or an
	Artificat might be able to attach this token to a resource request		Artifcat might be able to attach this token to a resource request
	to gain special priviliges.		to gain special privileges.
	Countermeasures:		Countermeasures:
	The Artificat must be encrypted when the user obtains it. It also		The Artifact must be encrypted when the user obtains it. It also
	needs to be transmitted encrypted when it is used for		needs to be transmitted encrypted when it is used for
	authorization. To make it even more difficult for an adversary to		authorization. To make it even more difficult for an adversary to
	reuse the Artificat it is possible to associate credentials		reuse the Artifact it is possible to associate credentials (either
	(either symmetric or asymmetric keying material) with the		symmetric or asymmetric keying material) with the Assertion. An
	Assertion. An adversary can then only impersonate the legitimate		adversary can then only impersonate the legitimate user if he
	user if he knows the Artificat or Assertion and the corresponding		knows the Artifact or Assertion and the corresponding credentials.
	credentials.
	7.5 Privacy		7.5 Privacy
	Threat:		Threat:
	An adversary might be able to eavesdrop both the EAP communication		An adversary might be able to eavesdrop both the EAP communication
	and the usage of SAML Artifacts and Assertions. This information		and the usage of SAML Artifacts and Assertions. This information
	might reveal user identities and usage patterns.		might reveal user identities and usage patterns.
	Countermeasures:		Countermeasures:
	skipping to change at page 20, line 4 ¶		skipping to change at page 19, line 50 ¶
	Threat:		Threat:
	An adversary might be able to eavesdrop both the EAP communication		An adversary might be able to eavesdrop both the EAP communication
	and the usage of SAML Artifacts and Assertions. This information		and the usage of SAML Artifacts and Assertions. This information
	might reveal user identities and usage patterns.		might reveal user identities and usage patterns.
	Countermeasures:		Countermeasures:
	EAP methods provide mechanisms to hide the true user identity.		EAP methods provide mechanisms to hide the true user identity.
	This is, however, useless if a SAML Assertion again reveals the		This is, however, useless if a SAML Assertion again reveals the
	true user identity. Since the Assertion is possibly only		true user identity. Since the Assertion is possibly only
	exchanged using DIAMETER an adversary needs to be located at a AAA		exchanged using DIAMETER an adversary needs to be located at a AAA
	client or server. The Artifcat itself does not reveal user		client or server. The Artifcat itself does not reveal user
	specific information since it is only a pointer to the Assertion.		specific information since it is only a pointer to the Assertion.
	Only legimiate entities are allowed to fetch the Assertion using		Only legitimate entities are allowed to fetch the Assertion using
	an Artifact. Furthermore, SAML does not mandate the inclusion of		an Artifact. Furthermore, SAML does not mandate the inclusion of
	a user identity in the Assertion.		a user identity in the Assertion.
	8. Acknowledgments		8. Acknowledgments
	We would like to thank Goeman Stefan and Rainer Falk for sharing		We would like to thank Goeman Stefan and Rainer Falk for sharing
	their thoughts with us. Furthermore, we would like to thank the		their thoughts with us. Furthermore, we would like to thank the
	authors of [27] on trait-based authorization for SIP (namely Jon		authors of [29] on trait-based authorization for SIP (namely Jon
	Peterson, James Polk, Douglas Sicker and Marcus Tegnander) for their		Peterson, James Polk, Douglas Sicker and Marcus Tegnander) for their
	discussions on the usage of SAML for IETF protocols.		discussions on the usage of SAML for IETF protocols.
	The authors are working in two EU funded projects, namely Ambient		The authors are working in two EU funded projects, namely Ambient
	Networks and DAIDALOS.		Networks and DAIDALOS.
	Parts of this document are a byproduct of the Ambient Networks		Parts of this document are a byproduct of the Ambient Networks
	Project, partially funded by the European Commission under its Sixth		Project, partially funded by the European Commission under its Sixth
	Framework Programme. It is provided "as is" and without any express		Framework Programme. It is provided "as is" and without any express
	or implied warranties, including, without limitation, the implied		or implied warranties, including, without limitation, the implied
	warranties of fitness for a particular purpose. The views and		warranties of fitness for a particular purpose. The views and
	conclusions contained herein are those of the authors and should not		conclusions contained herein are those of the authors and should not
	be interpreted as necessarily representing the official policies or		be interpreted as necessarily representing the official policies or
	endorsements, either expressed or implied, of the Ambient Networks		endorsements, either expressed or implied, of the Ambient Networks
	Project or the European Commission.		Project or the European Commission.
	The work described in this document is partiarly based on results of		The work described in this document is partially based on results of
	IST FP6 Integrated Project DAIDALOS. DAIDALOS receives research		IST FP6 Integrated Project DAIDALOS. DAIDALOS receives research
	funding from the European Community's Sixth Framework Programme.		funding from the European Community's Sixth Framework Programme.
	Apart from this, the European Commission has no responsibility for		Apart from this, the European Commission has no responsibility for
	the content of this paper. The information in this document is		the content of this paper. The information in this document is
	provided as is and no guarantee or warranty is given that the		provided as is and no guarantee or warranty is given that the
	information is fit for any particular purpose. The user thereof uses		information is fit for any particular purpose. The user thereof uses
	the information at its sole risk and liability. The views and		the information at its sole risk and liability. The views and
	conclusions contained herein are those of the authors and should not		conclusions contained herein are those of the authors and should not
	be interpreted as necessarily representing the official policies or		be interpreted as necessarily representing the official policies or
	endorsements, either expressed or implied, of Daidalos Project or the		endorsements, either expressed or implied, of Daidalos Project or the
	European Commission.		European Commission.
	9. References		9. References
	9.1 Normative References		9.1 Normative References
	[1] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin,		[1] Forsberg, D., "Protocol for Carrying Authentication for Network
	"Protocol for Carrying Authentication for Network Access		Access (PANA)", draft-ietf-pana-pana-09 (work in progress),
	(PANA)", Internet-Draft draft-ietf-pana-pana-07, December 2004.		July 2005.
	[2] Maler, E., Philpott, R. and P. Mishra, "Bindings and Profiles		[2] Maler, E., Philpott, R., and P. Mishra, "Bindings and Profiles
	for the OASIS Security Assertion Markup Language (SAML) V1.1",		for the OASIS Security Assertion Markup Language (SAML) V1.1",
	September 2003.		September 2003.
	[3] Maler, E., Philpott, R. and P. Mishra, "Assertions and Protocol		[3] Maler, E., Philpott, R., and P. Mishra, "Assertions and Protocol
	for the OASIS Security Assertion Markup Language (SAML) V1.1",		for the OASIS Security Assertion Markup Language (SAML) V1.1",
	September 2003.		September 2003.
	[4] Blunk, L., "Extensible Authentication Protocol (EAP)",		[4] Blunk, L., "Extensible Authentication Protocol (EAP)",
	Internet-Draft draft-ietf-eap-rfc2284bis-09, February 2004.		draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004.
	[5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote		[5] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
	Authentication Dial In User Service (RADIUS)", RFC 2865, June		Authentication Dial In User Service (RADIUS)", RFC 2865,
	2000.		June 2000.
	[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,		[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
	"Diameter Base Protocol", RFC 3588, September 2003.		"Diameter Base Protocol", RFC 3588, September 2003.
	[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	[8] Eastlake, D., Reagle, J. and D. Solo, "XML-Signature Syntax and		[8] Eastlake, D., Reagle, J., and D. Solo, "XML-Signature Syntax and
	Processing, W3C Recommendation (available at		Processing, W3C Recommendation (available at
	http://www.w3.org/TR/xmldsig-core/)", February 2002.		http://www.w3.org/TR/xmldsig-core/)", February 2002.
	9.2 Informative References		9.2 Informative References
	[9] Tschofenig, H. and D. Kroeselberg, "Next Steps for ENROLL",		[9] Tschofenig, H. and D. Kroeselberg, "Next Steps for ENROLL",
	Internet-Draft draft-tschofenig-enroll-next-steps-00, October		draft-tschofenig-enroll-next-steps-00 (work in progress),
	2004.		October 2004.
	[10] Pritikin, M., "Trusted Transitive Introduction Model",		[10] Pritikin, M., "Trusted Transitive Introduction Model",
	Internet-Draft draft-pritikin-ttimodel-01, July 2004.		draft-pritikin-ttimodel-01 (work in progress), July 2004.
	[11] Patel, A., "Problem Statement for bootstrapping Mobile IPv6",		[11] Patel, A., "Problem Statement for bootstrapping Mobile IPv6",
	Internet-Draft draft-ietf-mip6-bootstrap-ps-01, October 2004.		draft-ietf-mip6-bootstrap-ps-03 (work in progress), July 2005.
	[12] Jee, J., "Diameter Mobile IPv6 Bootstrapping Application using		[12] Jee, J., "Diameter Mobile IPv6 Bootstrapping Application using
	PANA", Internet-Draft draft-jee-mip6-bootstrap-pana-00, October		PANA", draft-jee-mip6-bootstrap-pana-00 (work in progress),
	2004.		October 2004.
	[13] Giaretta, G., "MIPv6 Authorization and Configuration based on		[13] Giaretta, G., "MIPv6 Authorization and Configuration based on
	EAP", Internet-Draft draft-giaretta-mip6-authorization-eap-02,		EAP", draft-giaretta-mip6-authorization-eap-02 (work in
	October 2004.		progress), October 2004.
	[14] Kempf, J., "Bootstrapping Mobile IPv6",		[14] Kempf, J., "Bootstrapping Mobile IPv6",
	Internet-Draft draft-chakrabarti-mip6-bmip-00, December 2004.		draft-chakrabarti-mip6-bmip-01 (work in progress),
			February 2005.
	[15] Tschofenig, H., Bournelle, J. and S. Thiruvengadam,		[15] Tschofenig, H., Bournelle, J., and S. Thiruvengadam,
	"Bootstrapping Mobile IPv6 using PANA",		"Bootstrapping Mobile IPv6 using PANA",
	Internet-Draft draft-tschofenig-mip6-bootstrapping-pana-00,		draft-tschofenig-mip6-bootstrapping-pana-00 (work in progress),
	October 2004.		October 2004.
	[16] Leung, K., "Authentication Protocol for Mobile IPv6",		[16] Leung, K., "Authentication Protocol for Mobile IPv6",
	Internet-Draft draft-ietf-mip6-auth-protocol-04, February 2005.		draft-ietf-mip6-auth-protocol-04 (work in progress),
			February 2005.
	[17] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",		[17] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
	RFC 3118, June 2001.		RFC 3118, June 2001.
	[18] Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping		[18] Yegin, A., Tschofenig, H., and D. Forsberg, "Bootstrapping
	RFC3118 Delayed DHCP Authentication Using EAP-based Network		RFC3118 Delayed DHCP Authentication Using EAP-based Network
	Access Authentication",		Access Authentication", draft-yegin-eap-boot-rfc3118-01 (work
	Internet-Draft draft-yegin-eap-boot-rfc3118-01, January 2005.		in progress), January 2005.
	[19] Tschofenig, H., "Bootstrapping RFC3118 Delayed authentication		[19] Tschofenig, H., "Bootstrapping RFC3118 Delayed authentication
	using PANA",		using PANA", draft-tschofenig-pana-bootstrap-rfc3118-01 (work
	Internet-Draft draft-tschofenig-pana-bootstrap-rfc3118-01,		in progress), October 2003.
	October 2003.
	[20] Tschofenig, H., "Bootstrapping Kerberos",		[20] Tschofenig, H., "Bootstrapping Kerberos",
	Internet-Draft draft-tschofenig-pana-bootstrap-kerberos-00,		draft-tschofenig-pana-bootstrap-kerberos-00 (work in progress),
	July 2004.		July 2004.
	[21] Aboba, B., "Extensible Authentication Protocol (EAP) Key		[21] Mahy, R., "An Extensible Authentication Protocol (EAP)
	Management Framework", Internet-Draft draft-ietf-eap-keying-04,		Enrollment Method", draft-mahy-eap-enrollment-00 (work in
	November 2004.		progress), July 2005.
	[22] Maler, E. and J. Hughes, "Technical Overview of the OASIS		[22] Cam-Winget, N., "Dynamic Provisioning using EAP-FAST",
			draft-cam-winget-eap-fast-provisioning-00 (work in progress),
			July 2005.
			[23] Aboba, B., "Extensible Authentication Protocol (EAP) Key
			Management Framework", draft-ietf-eap-keying-06 (work in
			progress), April 2005.
			[24] Maler, E. and J. Hughes, "Technical Overview of the OASIS
	Security Assertion Markup Language (SAML) V1.1", March 2004.		Security Assertion Markup Language (SAML) V1.1", March 2004.
	[23] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.		[25] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
	and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September		and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
	1999.		September 1999.
	[24] Farrell, S. and R. Housley, "An Internet Attribute Certificate		[26] Farrell, S. and R. Housley, "An Internet Attribute Certificate
	Profile for Authorization", RFC 3281, April 2002.		Profile for Authorization", RFC 3281, April 2002.
	[25] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[27] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004.		draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
	[26] Bournelle, J., "Bootstrapping Mobile IPv6 using PANA",		[28] Bournelle, J., "Bootstrapping Mobile IPv6 using PANA",
	Internet-Draft draft-bournelle-pana-mip6-00, December 2004.		draft-bournelle-pana-mip6-00 (work in progress), December 2004.
	[27] Peterson, J., "Trait-based Authorization Requirements for the		[29] Peterson, J., "Trait-based Authorization Requirements for the
	Session Initiation Protocol (SIP)",		Session Initiation Protocol (SIP)",
	Internet-Draft draft-ietf-sipping-trait-authz-00, February		draft-ietf-sipping-trait-authz-01 (work in progress),
	2004.		February 2005.
	[28] Alfano, F., "Diameter Quality of Service Application",		[30] Alfano, F., "Diameter Quality of Service Application",
	Internet-Draft draft-alfano-aaa-qosprot-01, October 2004.		draft-alfano-aaa-qosprot-02 (work in progress), February 2005.
	[29] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for		[31] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-
	Quality-of-Service signaling",		of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in
	Internet-Draft draft-ietf-nsis-qos-nslp-05, October 2004.		progress), February 2005.
	[30] Tschofenig, H., "Using SAML for SIP",		[32] Tschofenig, H., "Using SAML for SIP",
	Internet-Draft draft-tschofenig-sip-saml-02, December 2004.		draft-tschofenig-sip-saml-03 (work in progress), July 2005.
	[31] Aboba, B. and J. Wood, "Authentication, Authorization and		[33] Aboba, B. and J. Wood, "Authentication, Authorization and
	Accounting (AAA) Transport Profile", RFC 3539, June 2003.		Accounting (AAA) Transport Profile", RFC 3539, June 2003.
	[32] Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H.		[34] Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H.
	Hakala, "Diameter Credit-control Application",		Hakala, "Diameter Credit-control Application",
	Internet-Draft draft-ietf-aaa-diameter-cc-06, August 2004.		draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004.
	[33] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected		[35] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected
	EAP Protocol (PEAP) Version 2",		EAP Protocol (PEAP) Version 2",
	Internet-Draft draft-josefsson-pppext-eap-tls-eap-10, October		draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
	2004.		October 2004.
	[34] Bersani, F., "The EAP-PSK Protocol: a Pre-Shared Key EAP		[36] Bersani, F., "The EAP-PSK Protocol: a Pre-Shared Key EAP
	Method", Internet-Draft draft-bersani-eap-psk-06, November		Method", draft-bersani-eap-psk-07 (work in progress),
	2004.		February 2005.
	[35] Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method		[37] Tschofenig, H., "EAP IKEv2 Method (EAP-IKEv2)",
	(EAP-IKEv2)", Internet-Draft draft-tschofenig-eap-ikev2-05,		draft-tschofenig-eap-ikev2-06 (work in progress), May 2005.
	October 2004.
	[36] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",		[38] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
	RFC 2716, October 1999.		RFC 2716, October 1999.
	[37] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial		[39] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
	In User Service) Support For Extensible Authentication Protocol		In User Service) Support For Extensible Authentication Protocol
	(EAP)", RFC 3579, September 2003.		(EAP)", RFC 3579, September 2003.
	[38] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible		[40] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application",		Authentication Protocol (EAP) Application",
	Internet-Draft draft-ietf-aaa-eap-10, November 2004.		draft-ietf-aaa-eap-10 (work in progress), November 2004.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	skipping to change at page 26, line 5 ¶		skipping to change at page 25, line 40 ¶
	Email: gerardo.giaretta@tilab.com		Email: gerardo.giaretta@tilab.com
	Antonio F. Gomez-Skarmeta		Antonio F. Gomez-Skarmeta
	University of Murcia		University of Murcia
	Campus de Espinardo s/n		Campus de Espinardo s/n
	Murcia, E-30100		Murcia, E-30100
	Spain		Spain
	Email: skarmeta@dif.um.es		Email: skarmeta@dif.um.es
			James Polk
			Cisco
			2200 East President George Bush Turnpike
			Richardson, Texas 75082
			US
			Email: jmpolk@cisco.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. 107 change blocks.
	231 lines changed or deleted		246 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/