< draft-ietf-sip-saml-03.txt		draft-ietf-sip-saml-04.txt >
	SIP H. Tschofenig		SIP H. Tschofenig
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Updates: 4474 (if approved) J. Hodges		Updates: 4474 (if approved) J. Hodges
	Intended status: Standards Track J. Peterson		Intended status: Standards Track J. Peterson
	Expires: May 21, 2008 NeuStar, Inc.		Expires: January 15, 2009 NeuStar, Inc.
	J. Polk		J. Polk
	Cisco		Cisco
	D. Sicker		D. Sicker
	CU Boulder		CU Boulder
	November 18, 2007		July 14, 2008
	SIP SAML Profile and Binding		SIP SAML Profile and Binding
	draft-ietf-sip-saml-03.txt		draft-ietf-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 40 ¶		skipping to change at page 1, line 40 ¶
	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 May 21, 2008.		This Internet-Draft will expire on January 15, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document specifies a Session Initiation Protocol (SIP) profile		This document specifies a Session Initiation Protocol (SIP) profile
	of Security Assertion Markup Language (SAML) as well as a SAML SIP		of Security Assertion Markup Language (SAML) as well as a SAML SIP
	binding. The defined SIP SAML Profile composes with the mechanisms		binding. The defined SIP SAML Profile composes with the mechanisms
	defined in the SIP Identity specification and satisfy requirements		defined in the SIP Identity specification and satisfy requirements
	presented in "Trait-based Authorization Requirements for the Session		presented in "Trait-based Authorization Requirements for the Session
	Initiation Protocol (SIP)".		Initiation Protocol (SIP)".
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 6		3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 7		3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 8		3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9
	4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 9		4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10
	5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 11		5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12
	6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 13		6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 14
	6.1. AS-driven SIP SAML URI-based Attribute Assertion		6.1. AS-driven SIP SAML URI-based Attribute Assertion
	Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 13		Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 14
	6.1.1. Required Information . . . . . . . . . . . . . . . . . 13		6.1.1. Required Information . . . . . . . . . . . . . . . . . 14
	6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 13		6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 14
	6.1.3. Profile Description . . . . . . . . . . . . . . . . . 17		6.1.3. Profile Description . . . . . . . . . . . . . . . . . 18
	6.1.4. Assertion Profile Description . . . . . . . . . . . . 20		6.1.4. Assertion Profile Description . . . . . . . . . . . . 21
	6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 22		6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 23
	6.2. The TBD "call-by-value" Profile . . . . . . . . . . . . . 24		6.2. The TBD "call-by-value" Profile . . . . . . . . . . . . . 25
	7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 25		7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 26
	7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 25		7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 26
	8. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 26		8. The 'saml-shusb' Option Tag . . . . . . . . . . . . . . . . . 27
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 31		9. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 28
	9.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 31		10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	9.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 32		10.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 33
	9.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 32		10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 33
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33		10.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 34
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
	13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 37		13.1. IANA Registration for New SIP Option Tag . . . . . . . . . 37
	14.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 37		13.2. 477 'Use Identity Header with SAML Assertion' Response
	14.2. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 37		Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38		13.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 37
	15.1. Normative References . . . . . . . . . . . . . . . . . . . 38		13.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 37
	15.2. Informative References . . . . . . . . . . . . . . . . . . 39		14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42		15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	Intellectual Property and Copyright Statements . . . . . . . . . . 43		15.1. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 40
			15.2. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 40
			15.3. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 40
			16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
			16.1. Normative References . . . . . . . . . . . . . . . . . . . 41
			16.2. Informative References . . . . . . . . . . . . . . . . . . 42
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
			Intellectual Property and Copyright Statements . . . . . . . . . . 45
	1. Introduction		1. Introduction
	This document specifies composition of the Security Assertion Markup		This document specifies composition of the Security Assertion Markup
	Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate		Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate
	richer authorization mechanisms and enable "trait-based		richer authorization mechanisms and enable "trait-based
	authorization." Trait-based authorization is where one is authorized		authorization." Trait-based authorization is where one is authorized
	to make use of some resource based on roles or traits rather than		to make use of some resource based on roles or traits rather than
	ones identifier(s). Motivations for trait-based authorization, along		ones identifier(s). Motivations for trait-based authorization, along
	with use-case scenarios, are presented in [RFC4484].		with use-case scenarios, are presented in [RFC4484].
	skipping to change at page 12, line 50 ¶		skipping to change at page 13, line 50 ¶
	Figure 1: SIP-SAML-based Network Asserted Identity		Figure 1: SIP-SAML-based Network Asserted Identity
	Since the AS already being trusted to create and add the Identity		Since the AS already being trusted to create and add the Identity
	header containing the SIP Identity Assertion, and to supply a pointer		header containing the SIP Identity Assertion, and to supply a pointer
	to its domain certificate, having it point instead to a SAML		to its domain certificate, having it point instead to a SAML
	assertion conveying the domain certificate and possibly some user		assertion conveying the domain certificate and possibly some user
	profile attributes, does not significantly alter the first-order		profile attributes, does not significantly alter the first-order
	security considerations examined in [RFC4474]. This specification		security considerations examined in [RFC4474]. This specification
	provides some additional security considerations analysis below in		provides some additional security considerations analysis below in
	Section 9.		Section 10.
	6. SIP SAML Profiles		6. SIP SAML Profiles
	This section defines two "SIP SAML profiles":		This section defines two "SIP SAML profiles":
	o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch		o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch
	Profile"		Profile"
	o The to-be-determined (TBD) "call-by-value" profile		o The to-be-determined (TBD) "call-by-value" profile
	skipping to change at page 20, line 44 ¶		skipping to change at page 21, line 44 ¶
	SIP request it received.		SIP request it received.
	6.1.4. Assertion Profile Description		6.1.4. Assertion Profile Description
	This section defines the particulars of how the sender, i.e., the		This section defines the particulars of how the sender, i.e., the
	SAML Authority, MUST construct certain portions of the SAML		SAML Authority, MUST construct certain portions of the SAML
	assertions it issues. The schema for SAML assertions themselves is		assertions it issues. The schema for SAML assertions themselves is
	defined in Section 2.3 of [OASIS.saml-core-2.0-os].		defined in Section 2.3 of [OASIS.saml-core-2.0-os].
	An example SAML assertion, formulated according to this profile is		An example SAML assertion, formulated according to this profile is
	given in Section 8.		given in Section 9.
	Overall SAML assertion profile requirements:		Overall SAML assertion profile requirements:
	The SAML assertion MUST be signed by the same key as used to sign		The SAML assertion MUST be signed by the same key as used to sign
	the contents of the Identity header field. Signing of SAML		the contents of the Identity header field. Signing of SAML
	assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os].		assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os].
	In the following subsections, the SAML assertion profile is specified		In the following subsections, the SAML assertion profile is specified
	element-by-element, in a top-down, depth-first manner, beginning with		element-by-element, in a top-down, depth-first manner, beginning with
	the outermost element, "<Assertion>". Where applicable, the		the outermost element, "<Assertion>". Where applicable, the
	skipping to change at page 26, line 5 ¶		skipping to change at page 27, line 5 ¶
	to [OASIS.saml-bindings-2.0-os]):		to [OASIS.saml-bindings-2.0-os]):
	Section 3.7.5.3 Security Considerations:		Section 3.7.5.3 Security Considerations:
	Support for TLS 1.0 or SSL 3.0 is mandatory to implement.		Support for TLS 1.0 or SSL 3.0 is mandatory to implement.
	Section 3.7.5.4 Error Reporting:		Section 3.7.5.4 Error Reporting:
	All SHOULDs in this section are to be interpreted as MUSTs.		All SHOULDs in this section are to be interpreted as MUSTs.
	8. Example SAML Assertions		8. The 'saml-shusb' Option Tag
			This document creates and IANA registers one new option tag: "saml-
			shusb". This option tag is to be used, as defined in RFC 3261, in
			the Require, Supported and Unsupported headers. It is used to
			indicate support for this SIP extension, this option tag is included
			in a Supported header of the SIP request.
			9. Example SAML Assertions
	This section presents two examples of a SAML assertion, one unsigned		This section presents two examples of a SAML assertion, one unsigned
	(for clarity), the other signed (for accuracy).		(for clarity), the other signed (for accuracy).
	In the first example, Figure 5, the assertion is attesting with		In the first example, Figure 4, the assertion is attesting with
	respect to the subject (lines 7-15) "Alice@example.com" (line 11).		respect to the subject (lines 7-15) "Alice@example.com" (line 11).
	The validity conditions are expressed in lines 16-23, via both a		The validity conditions are expressed in lines 16-23, via both a
	validity period expressed as temporal endpoints, and an "audience		validity period expressed as temporal endpoints, and an "audience
	restriction" stating that this assertion's semantics are valid for		restriction" stating that this assertion's semantics are valid for
	only the relying party named "example2.com". Also, the assertion's		only the relying party named "example2.com". Also, the assertion's
	issuer is noted in lines 4-5.		issuer is noted in lines 4-5.
	The above items correspond to some aspects of this specification's		The above items correspond to some aspects of this specification's
	SAML assertion profile, as noted below in Security Considerations		SAML assertion profile, as noted below in Security Considerations
	dicussions, see: Section 9.1 and Section 9.2.		dicussions, see: Section 10.1 and Section 10.2.
	In lines 24-36, Alice's telephone number is conveyed, in a "typed"		In lines 24-36, Alice's telephone number is conveyed, in a "typed"
	fashion, using LDAP/X.500 schema as the typing means.		fashion, using LDAP/X.500 schema as the typing means.
	1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"		1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
	2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0"		2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
	3 xmlns="urn:oasis:names:tc:SAML:2.0:assertion">		3 xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
	4 <Issuer>		4 <Issuer>
	5 example.com		5 example.com
	6 </Issuer>		6 </Issuer>
	skipping to change at page 27, line 43 ¶		skipping to change at page 29, line 43 ¶
	29 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"		29 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
	30 Name="urn:oid:2.5.4.20"		30 Name="urn:oid:2.5.4.20"
	31 FriendlyName="telephoneNumber">		31 FriendlyName="telephoneNumber">
	32 <saml:AttributeValue xsi:type="xs:string">		32 <saml:AttributeValue xsi:type="xs:string">
	33 +1-888-555-1212		33 +1-888-555-1212
	34 </saml:AttributeValue>		34 </saml:AttributeValue>
	35 </saml:Attribute>		35 </saml:Attribute>
	36 </AttributeStatement>		36 </AttributeStatement>
	37 </Assertion>		37 </Assertion>
	Figure 5: Unsigned SAML Assertion Illustrating Conveyance of		Figure 4: Unsigned SAML Assertion Illustrating Conveyance of
	Subject Attribute		Subject Attribute
	In the second example, Figure 6, the information described above is		In the second example, Figure 5, the information described above is
	the same, the addition is that this version of the assertion is		the same, the addition is that this version of the assertion is
	signed. All the signature information is conveyed in the <ds:		signed. All the signature information is conveyed in the <ds:
	signature> element, lines 7-47. Thus this assertion's origin and its		signature> element, lines 7-47. Thus this assertion's origin and its
	integrity are assured. Since this assertion is the same as the one		integrity are assured. Since this assertion is the same as the one
	in the first example above, other than having a signature added, the		in the first example above, other than having a signature added, the
	second example below addresses the same Security Considerations		second example below addresses the same Security Considerations
	aspects, plus those requiring a Signature.		aspects, plus those requiring a Signature.
	1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"		1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
	2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0"		2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
	skipping to change at page 30, line 35 ¶		skipping to change at page 32, line 35 ¶
	70 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"		70 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
	71 Name="urn:oid:2.5.4.20"		71 Name="urn:oid:2.5.4.20"
	72 FriendlyName="telephoneNumber">		72 FriendlyName="telephoneNumber">
	73 <saml:AttributeValue xsi:type="xs:string">		73 <saml:AttributeValue xsi:type="xs:string">
	74 +1-888-555-1212		74 +1-888-555-1212
	75 </saml:AttributeValue>		75 </saml:AttributeValue>
	76 </saml:Attribute>		76 </saml:Attribute>
	77 </AttributeStatement>		77 </AttributeStatement>
	78 </Assertion>		78 </Assertion>
	Figure 6: Signed SAML Assertion Illustrating Conveyance of Subject		Figure 5: Signed SAML Assertion Illustrating Conveyance of Subject
	Attribute		Attribute
	9. Security Considerations		10. Security Considerations
	This section discusses security considerations when using SAML with		This section discusses security considerations when using SAML with
	SIP.		SIP.
	9.1. Man-in-the-middle Attacks and Stolen Assertions		10.1. Man-in-the-Middle Attacks and Stolen Assertions
	Threat:		Threat:
	By making SAML assertions available via HTTP-based requests by a		By making SAML assertions available via HTTP-based requests by a
	potentially unbounded set of requesters, it is conceivably		potentially unbounded set of requesters, it is conceivably
	possible that anyone would be able to simply request one and		possible that anyone would be able to simply request one and
	obtain it. By SIP intermediaries on the signaling path for		obtain it. By SIP intermediaries on the signaling path for
	example. Or, an HTTP intermediary/proxy could intercept the		example. Or, an HTTP intermediary/proxy could intercept the
	assertion as it is being returned to a requester.		assertion as it is being returned to a requester.
	skipping to change at page 31, line 40 ¶		skipping to change at page 33, line 40 ¶
	the corresponding private key with which to generate the signed		the corresponding private key with which to generate the signed
	Identity header value.		Identity header value.
	Also, the SIP SAML assertion profile specified herein that the		Also, the SIP SAML assertion profile specified herein that the
	subject's SAML assertion must adhere to causes it to be not useful		subject's SAML assertion must adhere to causes it to be not useful
	to arbitrary parties. The subject's assertion:		to arbitrary parties. The subject's assertion:
	* should be signed, thus causing any alterations to break its		* should be signed, thus causing any alterations to break its
	integrity and make such alterations detectable.		integrity and make such alterations detectable.
	* does not contain an authentication statement. Thus no parties
	implementing this specification should be relying on SAML
	assertions specified herein as sufficient in and of themselves
	to allow access to resources.
	* relying party is represented in the SAML assertion's Audience		* relying party is represented in the SAML assertion's Audience
	Restriction.		Restriction.
	* Issuer is represented in the SAML assertion.		* Issuer is represented in the SAML assertion.
	* validity period for assertion is restricted.		* validity period for assertion is restricted.
	* etc.		10.2. Forged Assertion
	9.2. Forged Assertion
	Threat:		Threat:
	A malicious user could forge or alter a SAML assertion in order to		A malicious user could forge or alter a SAML assertion in order to
	communicate with the SIP entities.		communicate with the SIP entities.
	Countermeasures:		Countermeasures:
	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 are employed, e.g.,		mechanisms for protecting the SAML assertion are employed, e.g.,
	signing the SAML assertion itself. Section 5.1 of		signing the SAML assertion itself. Section 5.1 of
	[OASIS.saml-core-2.0-os] specifies the signing of SAML assertions.		[OASIS.saml-core-2.0-os] specifies the signing of SAML assertions.
	Additionally, the assertion content dictated by the SAML assertion		Additionally, the assertion content dictated by the SAML assertion
	profile herein ensures ample evidence for a relying party to		profile herein ensures ample evidence for a relying party to
	verify the assertion and its relationship with the received SIP		verify the assertion and its relationship with the received SIP
	request.		request.
	9.3. Replay Attack		10.3. Replay Attack
	Threat:		Threat:
	Theft of SIP message protected by the mechanisms described herein		Theft of SIP message protected by the mechanisms described herein
	and replay of it at a later time.		and replay of it at a later time.
	Countermeasures:		Countermeasures:
	There are various provisions within [RFC4474] that prevent a		There are various provisions within [RFC4474] that prevent a
	replay attack.		replay attack.
	10. Contributors		11. Contributors
	The authors would like to thank Marcus Tegnander and Henning		The authors would like to thank Marcus Tegnander and Henning
	Schulzrinne for his contributions to earlier versions of this		Schulzrinne for his contributions to earlier versions of this
	document.		document.
	11. Acknowledgments		12. Acknowledgments
	We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida		We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida
	Schubert, Jason Fischl and Vijay Gurbani for their comments to this		Schubert, Jason Fischl, Sebastian Felis, Nie Pin, Marcos Dytz, Erkki
	draft. The "AS-driven SIP SAML URI-based Attribute Assertion Fetch		Koivusalo, Richard Barnes, Marc Willekens, Marc Willekens, Steffen
	Profile" is based on an idea by Jon Peterson.		Fries and Vijay Gurbani for their comments to this draft. The "AS-
			driven SIP SAML URI-based Attribute Assertion Fetch Profile" is based
			on an idea by Jon Peterson.
	12. IANA Considerations		13. IANA Considerations
	[Editor's Note: A future version of this document will provide IANA		13.1. IANA Registration for New SIP Option Tag
	considerations.]
	13. Open Issues		The SIP option tag "saml-shusb" is created by this document, with the
			definition and rule in Section 4.4 of this document, to be added to
			sip-parameters within IANA.
			13.2. 477 'Use Identity Header with SAML Assertion' Response Code
			This document registers a new SIP response code. It is sent when a
			verifier receives a SIP request that lacks an Identity header with a
			SAML assertion in order to indicate that the request should be re-
			sent with an Identity header pointing to a SAML assertion. This
			response code is defined by the following information, which has been
			added to the method and response-code sub-registry under
			http://www.iana.org/assignments/sip-parameters.
			Response Code Number: 477
			Default Reason Phrase: Use Identity Header with SAML Assertion
			13.3. 478 'Unknown SAML Assertion Content' Response Code
			This document registers a new SIP response code. It is used when the
			verifier is unable to parse the content of the SAML assertion
			referenced by the URI of the Identity-Info header, because, for
			example, the assertion contains only unknown elements in in the SAML
			assertion, or the SAML assertion XML document is garbled. This
			response code is defined by the following information, which has been
			added to the method and response-code sub-registry under
			http://www.iana.org/assignments/sip-parameters.
			Response Code Number: 478
			Default Reason Phrase: Unknown SAML Assertion Content
			13.4. 479 'Invalid SAML Assertion' Response Code
			This document registers a new SIP response code. It is used when the
			verifier is unable to process the SAML assertion referenced by the
			URI of the Identity-Info header, because, for example, the assertion
			is self-signed, or signed by a root certificate authority for whom
			the verifier does not possess a root certificate. This response code
			is defined by the following information, which has been added to the
			method and response-code sub-registry under
			http://www.iana.org/assignments/sip-parameters.
			Response Code Number: 479
			Default Reason Phrase: Invalid SAML Assertion
			14. Open Issues
	A list of open issues can be found at:		A list of open issues can be found at:
	http://www.tschofenig.com:8080/saml-sip/		http://www.tschofenig.priv.at:8080/saml-sip/
	14. Change Log		15. Change Log
	RFC Editor - Please remove this section before publication.		RFC Editor - Please remove this section before publication.
	14.1. -02 to -03		15.1. -03 to -04
			Updated IANA consideration section.
			Added option tag
			Updated acknowledgments section
			Minor editorial changes to the security considerations section
			15.2. -02 to -03
	Denoted that this I-D is intended to update RFC4474 per SIP working		Denoted that this I-D is intended to update RFC4474 per SIP working
	group consensus at IETF-69. This is the tact adopted in order to		group consensus at IETF-69. This is the tact adopted in order to
	address the impedance mismatch between the nature of the URIs		address the impedance mismatch between the nature of the URIs
	specified as to be placed in the Identity-Info header field, and what		specified as to be placed in the Identity-Info header field, and what
	is specified in RFC4474 as the allowable value of that header field.		is specified in RFC4474 as the allowable value of that header field.
	Added placeholder "TBD" section for a to-be-determined "call-by-		Added placeholder "TBD" section for a to-be-determined "call-by-
	value" profile, per SIP working group consensus at IETF-69.		value" profile, per SIP working group consensus at IETF-69.
	Removed use-case appendicies (per recollection of JHodges during		Removed use-case appendicies (per recollection of JHodges during
	IETF-69 discussion as being WG consensus, but such is not noted in		IETF-69 discussion as being WG consensus, but such is not noted in
	the minutes).		the minutes).
	14.2. -00 to -02		15.3. -00 to -02
	Will detail in -04 rev.		Will detail in -04 rev.
	15. References		16. References
	15.1. Normative References		16.1. Normative References
	[OASIS.saml-bindings-2.0-os]		[OASIS.saml-bindings-2.0-os]
	Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.		Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
	Maler, "Bindings for the OASIS Security Assertion Markup		Maler, "Bindings for the OASIS Security Assertion Markup
	Language (SAML) V2.0", OASIS		Language (SAML) V2.0", OASIS
	Standard saml-bindings-2.0-os, March 2005.		Standard saml-bindings-2.0-os, March 2005.
	[OASIS.saml-core-2.0-os]		[OASIS.saml-core-2.0-os]
	Cantor, S., Kemp, J., Philpott, R., and E. Maler,		Cantor, S., Kemp, J., Philpott, R., and E. Maler,
	"Assertions and Protocol for the OASIS Security Assertion		"Assertions and Protocol for the OASIS Security Assertion
	skipping to change at page 39, line 29 ¶		skipping to change at page 42, line 29 ¶
	[RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,		[RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,
	"Trait-Based Authorization Requirements for the Session		"Trait-Based Authorization Requirements for the Session
	Initiation Protocol (SIP)", RFC 4484, August 2006.		Initiation Protocol (SIP)", RFC 4484, August 2006.
	[W3C.xmldsig-core]		[W3C.xmldsig-core]
	Eastlake, D., Reagle , J., and D. Solo, "XML-Signature		Eastlake, D., Reagle , J., and D. Solo, "XML-Signature
	Syntax and Processing", W3C Recommendation xmldsig-core,		Syntax and Processing", W3C Recommendation xmldsig-core,
	October 2000, <http://www.w3.org/TR/xmldsig-core/>.		October 2000, <http://www.w3.org/TR/xmldsig-core/>.
	15.2. Informative References		16.2. Informative References
	[I-D.ietf-sip-content-indirect-mech]
	Burger, E., "A Mechanism for Content Indirection in
	Session Initiation Protocol (SIP) Messages",
	draft-ietf-sip-content-indirect-mech-05 (work in
	progress), October 2004.
	[I-D.ietf-sipping-certs]
	Jennings, C. and J. Peterson, "Certificate Management
	Service for The Session Initiation Protocol (SIP)",
	draft-ietf-sipping-certs-03 (work in progress),
	March 2006.
	[I-D.jennings-sipping-pay]
	Jennings, C., "Payment for Services in Session Initiation
	Protocol (SIP)", draft-jennings-sipping-pay-06 (work in
	progress), July 2007.
	[I-D.peterson-message-identity]
	Peterson, J., "Security Considerations for Impersonation
	and Identity in Messaging Systems",
	draft-peterson-message-identity-00 (work in progress),
	October 2004.
	[IANA.application.samlassertion-xml]		[IANA.application.samlassertion-xml]
	OASIS Security Services Technical Committee (SSTC),		OASIS Security Services Technical Committee (SSTC),
	"application/samlassertion+xml MIME Media Type		"application/samlassertion+xml MIME Media Type
	Registration", IANA MIME Media Types Registry application/		Registration", IANA MIME Media Types Registry application/
	samlassertion+xml, December 2004.		samlassertion+xml, December 2004.
	[OASIS.saml-conformance-2.0-os]		[OASIS.saml-conformance-2.0-os]
	Mishra, P., Philpott, R., and E. Maler, "Conformance		Mishra, P., Philpott, R., and E. Maler, "Conformance
	Requirements for the Security Assertion Markup Language		Requirements for the Security Assertion Markup Language
	skipping to change at page 42, line 9 ¶		skipping to change at page 44, line 9 ¶
	Certificate Profile for Authorization", RFC 3281,		Certificate Profile for Authorization", RFC 3281,
	April 2002.		April 2002.
	[RFC3323] Peterson, J., "A Privacy Mechanism for the Session		[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
	Initiation Protocol (SIP)", RFC 3323, November 2002.		Initiation Protocol (SIP)", RFC 3323, November 2002.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Linnoitustie 6
	Munich, Bavaria 81739		Espoo 02600
	Germany		Finland
	Email: Hannes.Tschofenig@siemens.com		Phone: +358 (50) 4871445
			Email: Hannes.Tschofenig@gmx.net
			URI: http://www.tschofenig.priv.at
	Jeff Hodges		Jeff Hodges
	NeuStar, Inc.		NeuStar, Inc.
	2000 Broadway Street		2000 Broadway Street
	Redwood City, CA 94063		Redwood City, CA 94063
	US		US
	Email: Jeff.Hodges@neustar.biz		Email: Jeff.Hodges@neustar.biz
	Jon Peterson		Jon Peterson
	skipping to change at page 43, line 7 ¶		skipping to change at page 45, line 7 ¶
	Douglas C. Sicker		Douglas C. Sicker
	University of Colorado at Boulder		University of Colorado at Boulder
	ECOT 430		ECOT 430
	Boulder, CO 80309		Boulder, CO 80309
	US		US
	Email: douglas.sicker@colorado.edu		Email: douglas.sicker@colorado.edu
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 43, line 44 ¶		skipping to change at line 1481 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 36 change blocks.
	106 lines changed or deleted		147 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/