< draft-housley-tls-authz-extns-08.txt		draft-housley-tls-authz-extns-09.txt >
	Internet-Draft M. Brown		Internet-Draft M. Brown
	Intended Status: Experimental RedPhone Security		Intended Status: Experimental RedPhone Security
	Updates: 5246 (once approved) R. Housley		Updates: 5246 (once approved) R. Housley
	Vigil Security		Vigil Security
	Expires: 21 March 2010 17 September 2009		Expires: 14 April 2010 14 October 2009
	Transport Layer Security (TLS) Authorization Extensions		Transport Layer Security (TLS) Authorization Extensions
	<draft-housley-tls-authz-extns-08.txt>		<draft-housley-tls-authz-extns-09.txt>
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		Abstract
	This document specifies authorization extensions to the Transport		This document specifies authorization extensions to the Transport
	Layer Security (TLS) Handshake Protocol. Extensions carried in the		Layer Security (TLS) Handshake Protocol. Extensions carried in the
	client and server hello messages to confirm that both parties support		client and server hello messages to confirm that both parties support
	the desired authorization data types. Then, if supported by both the		the desired authorization data types. Then, if supported by both the
	client and the server, authorization information is exchanged in the		client and the server, authorization information, such as Attribute
	supplemental data handshake message.		Certificates or SAML Assertions, is exchanged in the supplemental
			data handshake message.
	1. Introduction		1. Introduction
	Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1][TLS1.2] is		Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1][TLS1.2] is
	being used in an increasing variety of operational environments,		being used in an increasing variety of operational environments,
	including ones that were not envisioned at the time of the original		including ones that were not envisioned at the time of the original
	design for TLS. The extensions introduced in this document are		design for TLS. The extensions introduced in this document are
	designed to enable TLS to operate in environments where authorization		designed to enable TLS to operate in environments where authorization
	information needs to be exchanged between the client and the server		information needs to be exchanged between the client and the server
	before any protected data is exchanged. The use of these TLS		before any protected data is exchanged. The use of these TLS
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 42 ¶
	all of these are handled within TLS. If each application requires		all of these are handled within TLS. If each application requires
	unique authorization information, then it might best be carried		unique authorization information, then it might best be carried
	within the TLS-protected application protocol. However, care must be		within the TLS-protected application protocol. However, care must be
	taken to ensure appropriate bindings when identification,		taken to ensure appropriate bindings when identification,
	authentication, and authorization information are handled at		authentication, and authorization information are handled at
	different protocol layers.		different protocol layers.
	This document describes authorization extensions for the TLS		This document describes authorization extensions for the TLS
	Handshake Protocol in both TLS 1.0, TLS 1.1, and TLS 1.2. These		Handshake Protocol in both TLS 1.0, TLS 1.1, and TLS 1.2. These
	extensions observe the conventions defined for TLS Extensions that		extensions observe the conventions defined for TLS Extensions that
	were originally defined in [TLSEXT], and are now part of TLS 1.2		were originally defined in [TLSEXT1] and revised in [TLSEXT2]; TLS
	[TLS1.2]. TLS Extensions use general extension mechanisms for the		Extensions are now part of TLS 1.2 [TLS1.2]. TLS Extensions use
	client hello message and the server hello message. The extensions		general extension mechanisms for the client hello message and the
	described in this document confirm that both the client and the		server hello message. The extensions described in this document
	server support the desired authorization data types. Then, if		confirm that both the client and the server support the desired
	supported, authorization information is exchanged in the supplemental		authorization data types. Then, if supported, authorization
	data handshake message [TLSSUPP].		information is exchanged in the supplemental data handshake message
			[TLSSUPP].
	The authorization extensions may be used in conjunction with TLS 1.0,		The authorization extensions may be used in conjunction with TLS 1.0,
	TLS 1.1, and TLS 1.2. The extensions are designed to be backwards		TLS 1.1, and TLS 1.2. The extensions are designed to be backwards
	compatible, meaning that the Handshake Protocol Supplemental Data		compatible, meaning that the Handshake Protocol Supplemental Data
	messages will only contain authorization information of a particular		messages will only contain authorization information of a particular
	type if the client indicates support for them in the client hello		type if the client indicates support for them in the client hello
	message and the server indicates support for them in the server hello		message and the server indicates support for them in the server hello
	message.		message.
	Clients typically know the context of the TLS session that is being		Clients typically know the context of the TLS session that is being
	skipping to change at page 6, line 49 ¶		skipping to change at page 6, line 49 ¶
	however, the AC is fetched with the supplied URL. A one-way hash		however, the AC is fetched with the supplied URL. A one-way hash
	value is provided to ensure that the intended AC is obtained.		value is provided to ensure that the intended AC is obtained.
	When the saml_assertion_url value is present, the authorization data		When the saml_assertion_url value is present, the authorization data
	is a SAML Assertion; however, the SAML Assertion is fetched with the		is a SAML Assertion; however, the SAML Assertion is fetched with the
	supplied URL. A one-way hash value is provided to ensure that the		supplied URL. A one-way hash value is provided to ensure that the
	intended SAML Assertion is obtained.		intended SAML Assertion is obtained.
	Implementations that support either x509_attr_cert_url or		Implementations that support either x509_attr_cert_url or
	saml_assertion_url MUST support URLs that employ the http scheme		saml_assertion_url MUST support URLs that employ the http scheme
	[UPGRADE]. These implementations MUST confirm that the hash value		[HTTP]. These implementations MUST confirm that the hash value
	computed on the fetched authorization matches the one received in the		computed on the fetched authorization matches the one received in the
	handshake. Mismatch of the hash values SHOULD be treated as though		handshake. Mismatch of the hash values SHOULD be treated as though
	the authorization was not provided, which will result in a		the authorization was not provided, which will result in a
	bad_certificate alert (see Section 4).		bad_certificate_hash_value alert (see Section 4). Implementations
			MUST deny access if the authorization cannot be obtained from the
			provided URL, sending certificate_unobtainable alert (see Section 4).
	3. Supplemental Data Handshake Message Usage		3. Supplemental Data Handshake Message Usage
	As shown in Figure 1, supplemental data can be exchanges in two		As shown in Figure 1, supplemental data can be exchanges in two
	places in the handshake protocol. The client_authz extension		places in the handshake protocol. The client_authz extension
	determines what authorization data formats are acceptable for		determines what authorization data formats are acceptable for
	transfer from the client to the server, and the server_authz		transfer from the client to the server, and the server_authz
	extension determines what authorization data formats are acceptable		extension determines what authorization data formats are acceptable
	for transfer from the server to the client. In both cases, the		for transfer from the server to the client. In both cases, the
	syntax specified in [TLSSUPP] is used along with the authz_data type		syntax specified in [TLSSUPP] is used along with the authz_data type
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	3.2. Server Authorization Data		3.2. Server Authorization Data
	The SupplementalData message sent from the server to the client		The SupplementalData message sent from the server to the client
	contains authorization data associated with the TLS server. This		contains authorization data associated with the TLS server. This
	authorization information is expected to include statements about the		authorization information is expected to include statements about the
	server's qualifications, reputation, accreditation, and so on.		server's qualifications, reputation, accreditation, and so on.
	Wherever possible, authorizations that can be misappropriated for		Wherever possible, authorizations that can be misappropriated for
	fraudulent use ought to be avoided. The format of the authorization		fraudulent use ought to be avoided. The format of the authorization
	data depends on the format negotiated in the server_authz hello		data depends on the format negotiated in the server_authz hello
	message extensions. The AuthorizationData structure is described in		message extensions. The AuthorizationData structure is described in
	Section 3.3, and the following fictitious example of a single		Section 3.3, and the following fictitious example of a single 5-octet
	5-character SAML Assertion illustrates the use:		SAML Assertion illustrates the use:
	17 # Handshake.msg_type == supplemental_data(23)		17 # Handshake.msg_type == supplemental_data(23)
	00 00 11 # Handshake.length = 15		00 00 11 # Handshake.length = 17
	00 00 0e # length of SupplementalData.supp_data = 14		00 00 0e # length of SupplementalData.supp_data = 14
	?? ?? # SupplementalDataEntry.supp_data_type = TBD		?? ?? # SupplementalDataEntry.supp_data_type = TBD
	00 0a # SupplementalDataEntry.supp_data_length = 10		00 0a # SupplementalDataEntry.supp_data_length = 10
	00 08 # length of AuthorizationData.authz_data_list = 8		00 08 # length of AuthorizationData.authz_data_list = 8
	01 # authz_format = saml_assertion(1)		01 # authz_format = saml_assertion(1)
	00 05 # length of SAMLAssertion		00 05 # length of SAMLAssertion
	aa aa aa aa aa # SAML assertion (fictitious: "aa aa aa aa aa")		aa aa aa aa aa # SAML assertion (fictitious: "aa aa aa aa aa")
	{{ RFC Editor: Please replace "TBD" with the value assigned by		{{ RFC Editor: Please replace "TBD" with the value assigned by
	IANA, and replace "?? ??" with the hexadecimal value assigned		IANA, and replace "?? ??" with the hexadecimal value assigned
	skipping to change at page 9, line 51 ¶		skipping to change at page 9, line 51 ¶
	opaque MD5Hash[16];		opaque MD5Hash[16];
	opaque SHA1Hash[20];		opaque SHA1Hash[20];
	opaque SHA224Hash[28];		opaque SHA224Hash[28];
	opaque SHA256Hash[32];		opaque SHA256Hash[32];
	opaque SHA384Hash[48];		opaque SHA384Hash[48];
	opaque SHA256Hash[64];		opaque SHA512Hash[64];
	3.3.1. X.509 Attribute Certificate		3.3.1. X.509 Attribute Certificate
	When X509AttrCert is used, the field contains an ASN.1 DER-encoded		When X509AttrCert is used, the field contains an ASN.1 DER-encoded
	X.509 Attribute Certificate (AC) that follows the profile in RFC 3281		X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
	[ATTRCERT]. An AC is a structure similar to a public key certificate		[ATTRCERT]. An AC is a structure similar to a public key certificate
	(PKC) [PKIX1]; the main difference being that the AC contains no		(PKC) [PKIX1]; the main difference being that the AC contains no
	public key. An AC may contain attributes that specify group		public key. An AC may contain attributes that specify group
	membership, role, security clearance, or other authorization		membership, role, security clearance, or other authorization
	information associated with the AC holder.		information associated with the AC holder.
	skipping to change at page 11, line 50 ¶		skipping to change at page 11, line 50 ¶
	Implementations that support either x509_attr_cert_url or		Implementations that support either x509_attr_cert_url or
	saml_assertion_url MUST support URLs that employ the http scheme.		saml_assertion_url MUST support URLs that employ the http scheme.
	Other schemes may also be supported. When dereferencing these URLs,		Other schemes may also be supported. When dereferencing these URLs,
	circular dependencies MUST be avoided. Avoiding TLS when		circular dependencies MUST be avoided. Avoiding TLS when
	dereferencing these URLs is one way to avoid circular dependencies.		dereferencing these URLs is one way to avoid circular dependencies.
	Therefore, clients using the HTTP scheme MUST NOT use these TLS		Therefore, clients using the HTTP scheme MUST NOT use these TLS
	extensions if UPGRADE in HTTP [UPGRADE] is used. For other schemes,		extensions if UPGRADE in HTTP [UPGRADE] is used. For other schemes,
	similar care must be used to avoid using these TLS extensions.		similar care must be used to avoid using these TLS extensions.
	Implementations that support either x509_attr_cert_url or		Implementations that support either x509_attr_cert_url or
	saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]		saml_assertion_url MUST support both SHA-1 [SHS] and SHA-256 [SHS] as
	as one-way hash functions. Other one-way hash functions may also be		one-way hash functions. Other one-way hash functions may also be
	supported. Additional one-way hash functions can be added to the		supported. Additional one-way hash functions can be added to the
	IANA TLS HashAlgorithm registry in the future.		IANA TLS HashAlgorithm registry in the future.
	Implementations that support x509_attr_cert_url MUST support		Implementations that support x509_attr_cert_url MUST support
	responses that employ the "application/pkix-attr-cert" Multipart		responses that employ the "application/pkix-attr-cert" Multipart
	Internet Mail Extension (MIME) type.		Internet Mail Extension (MIME) type as defined in [ACTYPE].
	Implementations that support saml_assertion_url MUST support		Implementations that support saml_assertion_url MUST support
	responses that employ the "application/samlassertion+xml" MIME type.		responses that employ the "application/samlassertion+xml" MIME type
			as defined in Appendix A of [SAMLBIND].
	TLS Authorizations SHOULD follow the additional guidance provided in		TLS Authorizations SHOULD follow the additional guidance provided in
	Section 3.3 of [TLSEXT] regarding client certificate URLs.		Section 3.3 of [TLSEXT2] regarding client certificate URLs.
	4. Alert Messages		4. Alert Messages
	This document specifies the reuse TLS Alert messages related to		This document specifies the reuse TLS Alert messages related to
	public-key certificate processing for any errors that arise during		public-key certificate processing for any errors that arise during
	authorization processing. The following updated definitions for the		authorization processing, while preserving the AlertLevels as
	Alert messages are used to describe errors that arise while		authoritatively defined in [TLS1.2] or [TLSEXT2]. All Alerts used in
	processing authorizations. For ease of comparison, we reproduce the		authorization processing are fatal.
	of Alert message definition from Section 7.2 of [TLS1.2]:
			The following updated definitions for the Alert messages are used to
			describe errors that arise while processing authorizations. For ease
			of comparison, we reproduce the Alert message definition from Section
			7.2 of [TLS1.2], augmented with two values defined [TLSEXT2]:
	enum { warning(1), fatal(2), (255) } AlertLevel;		enum { warning(1), fatal(2), (255) } AlertLevel;
	enum {		enum {
	close_notify(0),		close_notify(0),
	unexpected_message(10),		unexpected_message(10),
	bad_record_mac(20),		bad_record_mac(20),
	decryption_failed_RESERVED(21),		decryption_failed_RESERVED(21),
	record_overflow(22),		record_overflow(22),
	decompression_failure(30),		decompression_failure(30),
	skipping to change at page 13, line 6 ¶		skipping to change at page 13, line 11 ¶
	access_denied(49),		access_denied(49),
	decode_error(50),		decode_error(50),
	decrypt_error(51),		decrypt_error(51),
	export_restriction_RESERVED(60),		export_restriction_RESERVED(60),
	protocol_version(70),		protocol_version(70),
	insufficient_security(71),		insufficient_security(71),
	internal_error(80),		internal_error(80),
	user_canceled(90),		user_canceled(90),
	no_renegotiation(100),		no_renegotiation(100),
	unsupported_extension(110),		unsupported_extension(110),
			certificate_unobtainable(111),
			bad_certificate_hash_value(114),
	(255)		(255)
	} AlertDescription;		} AlertDescription;
	struct {		struct {
	AlertLevel level;		AlertLevel level;
	AlertDescription description;		AlertDescription description;
	} Alert;		} Alert;
	TLS processing of alerts includes some ambiguity because the message		TLS processing of alerts includes some ambiguity because the message
	does not indicate which certificate in a certification path gave rise		does not indicate which certificate in a certification path gave rise
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 37 ¶
	could not be located or could not be matched with a known,		could not be located or could not be matched with a known,
	trusted CA. Similarly in authorization processing, unknown_ca		trusted CA. Similarly in authorization processing, unknown_ca
	indicates that the authorization issuer is not known and		indicates that the authorization issuer is not known and
	trusted.		trusted.
	access_denied		access_denied
	In certificate processing, access_denied indicates that a valid		In certificate processing, access_denied indicates that a valid
	certificate was received, but when access control was applied,		certificate was received, but when access control was applied,
	the sender decided not to proceed with negotiation. Similarly		the sender decided not to proceed with negotiation. Similarly
	in authorization processing, access_denied indicates that the		in authorization processing, access_denied indicates that the
	authorization was not sufficient to grant access. In		authorization was not sufficient to grant access.
	certificate processing, access_denied is always fatal, but in
	authorization processing, access_denied can be a warning or		certificate_unobtainable
	fatal.		The client_certificate_url extension defined in RFC 4366
			[TLSEXT2] specifies that download errors lead to a
			certificate_unobtainable alert. Similarly in authorization
			processing, certificate_unobtainable indicates that a URL does
			not result in an authorization. While certificate processing
			does not require this alert to be fatal, this is a fatal alert
			in authorization processing.
			bad_certificate_hash_value
			In certificate processing, bad_certificate_hash_value indicates
			that a downloaded certificate does not match the expected hash.
			Similarly in authorization processing,
			bad_certificate_hash_value indicates that a downloaded
			authorization does not match the expected hash.
	5. IANA Considerations		5. IANA Considerations
	This document defines a two TLS extensions: client_authz(TBD) and		This document defines a two TLS extensions: client_authz(TBD) and
	server_authz(TBD). These extension type values are assigned from the		server_authz(TBD). These extension type values are assigned from the
	TLS Extension Type registry defined in [TLSEXT].		TLS Extension Type registry defined in [TLSEXT2].
	This document defines one TLS supplemental data type:		This document defines one TLS supplemental data type:
	authz_data(TBD). This supplemental data type is assigned from the		authz_data(TBD). This supplemental data type is assigned from the
	TLS Supplemental Data Type registry defined in [TLSSUPP].		TLS Supplemental Data Type registry defined in [TLSSUPP].
	This document establishes a new registry, to be maintained by IANA,		This document establishes a new registry, to be maintained by IANA,
	for TLS Authorization Data Formats. The first four entries in the		for TLS Authorization Data Formats. The first four entries in the
	registry are x509_attr_cert(0), saml_assertion(1),		registry are x509_attr_cert(0), saml_assertion(1),
	x509_attr_cert_url(2), and saml_assertion_url(3). TLS Authorization		x509_attr_cert_url(2), and saml_assertion_url(3). TLS Authorization
	Data Format identifiers with values in the inclusive range 0-63		Data Format identifiers with values in the inclusive range 0-63
	skipping to change at page 16, line 4 ¶		skipping to change at page 16, line 22 ¶
	want to provide authorization information until the client is		want to provide authorization information until the client is
	authenticated. The double handshake illustrated in Figure 2 provides		authenticated. The double handshake illustrated in Figure 2 provides
	a technique to ensure that the parties are mutually authenticated		a technique to ensure that the parties are mutually authenticated
	before either party provides authorization information.		before either party provides authorization information.
	The use of bearer SAML assertions allows an eavesdropper or a man-in-		The use of bearer SAML assertions allows an eavesdropper or a man-in-
	the-middle to capture the SAML assertion and try to reuse it in		the-middle to capture the SAML assertion and try to reuse it in
	another context. The constraints discussed in Section 3.3.2 might be		another context. The constraints discussed in Section 3.3.2 might be
	effective against an eavesdropper, but they are less likely to be		effective against an eavesdropper, but they are less likely to be
	effective against a man-in-the-middle. Authentication of both		effective against a man-in-the-middle. Authentication of both
			parties in the TLS session, which involves the use of client
			authentication, will prevent an undetected man-in the-middle, and the
			use of the double handshake illustrated in Figure 2 will prevent the
			disclosure of the bearer SAML assertion to any party other than the
			TLS peer.
			AuthzDataFormats that point to authorization data, such as
			x509_attr_cert_url and saml_assertion_url, rather than simply
			including the authorization data in the handshake may be exploited by
			an attacker. Implementations that accept pointers to authorization
			SHOULD adopt a policy of least privilege that limits the acceptable
			references that they will attempt to use. For more information, see
			Section 6.3 of [TLSEXT2].
	Client Server		Client Server
	ClientHello (no extensions) --------> |0		ClientHello (no extensions) --------> |0
	ServerHello (no extensions) |0		ServerHello (no extensions) |0
	Certificate* |0		Certificate* |0
	ServerKeyExchange* |0		ServerKeyExchange* |0
	CertificateRequest* |0		CertificateRequest* |0
	<-------- ServerHelloDone |0		<-------- ServerHelloDone |0
	Certificate* |0		Certificate* |0
	ClientKeyExchange |0		ClientKeyExchange |0
	skipping to change at page 16, line 38 ¶		skipping to change at page 17, line 39 ¶
	ClientKeyExchange |1		ClientKeyExchange |1
	CertificateVerify* |1		CertificateVerify* |1
	[ChangeCipherSpec] |1		[ChangeCipherSpec] |1
	Finished --------> |2		Finished --------> |2
	[ChangeCipherSpec] |1		[ChangeCipherSpec] |1
	<-------- Finished |2		<-------- Finished |2
	Application Data <-------> Application Data |2		Application Data <-------> Application Data |2
	Figure 2. Double Handshake to Protect Authorization Data		Figure 2. Double Handshake to Protect Authorization Data
	parties in the TLS session, which involves the use of client
	authentication, will prevent an undetected man-in the-middle, and the
	use of the double handshake illustrated in Figure 2 will prevent the
	disclosure of the bearer SAML assertion to any party other than the
	TLS peer.
	AuthzDataFormats that point to authorization data, such as
	x509_attr_cert_url and saml_assertion_url, rather than simply
	including the authorization data in the handshake may be exploited by
	an attacker. Implementations that accept pointers to authorization
	SHOULD adopt a policy of least privilege that limits the acceptable
	references that they will attempt to use. For more information, see
	Section 6.3 of [TLS1.2].
	7. Acknowledgement		7. Acknowledgement
	The authors thank Scott Cantor for his assistance with the SAML		The authors thank Scott Cantor for his assistance with the SAML
	Assertion portion of the document.		Assertion portion of the document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
			[ACTYPE] Housley, R., "The application/pkix-attr-cert Content
			Type for Attribute Certificates", work in progress.
	[ATTRCERT] Farrell, S., and R. Housley, "An Internet Attribute		[ATTRCERT] Farrell, S., and R. Housley, "An Internet Attribute
	Certificate Profile for Authorization", RFC 3281,		Certificate Profile for Authorization", RFC 3281,
	April 2002.		April 2002.
			[HTTP] Fielding, R, J. Gettys, J. Mogul, H. Frystyk,
			L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext
			Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing		[IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing
	an IANA Considerations Section in RFCs", RFC 5226,		an IANA Considerations Section in RFCs", RFC 5226,
	May 2008.		May 2008.
	[PKIX1] Cooper, D., S. Santesson, S. Farrell, S. Boeyen,		[PKIX1] Cooper, D., S. Santesson, S. Farrell, S. Boeyen,
	R. Housley, and W. Polk, "Internet X.509 Public Key		R. Housley, and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation		Infrastructure Certificate and Certificate Revocation
	List (CRL) Profile", RFC 5280, May 2008.		List (CRL) Profile", RFC 5280, May 2008.
	[TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
	RFC 2246, January 1999.
	[TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol, Version 1.1", RFC 4346, February 2006.
	[TLS1.2] Dierks, T., and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol, Version 1.2", RFC 5246, August 2008.
	[TLSSUPP] Santesson, S., " TLS Handshake Message for Supplemental
	Data", RFC 4680, September 2006.
	[SAML1.1] OASIS Security Services Technical Committee, "Security		[SAML1.1] OASIS Security Services Technical Committee, "Security
	Assertion Markup Language (SAML) Version 1.1		Assertion Markup Language (SAML) Version 1.1
	Specification Set", September 2003.		Specification Set", September 2003.
	[SAML2.0] OASIS Security Services Technical Committee, "Security		[SAML2.0] OASIS Security Services Technical Committee, "Security
	Assertion Markup Language (SAML) Version 2.0		Assertion Markup Language (SAML) Version 2.0
	Specification Set", March2005.		Specification Set", March 2005.
	[SHA1] National Institute of Standards and Technology (NIST),		[SAMLBIND] OASIS Security Services Technical Committee, "Bindings
	FIPS PUB 180-1, Secure Hash Standard, 17 April 1995.		for the OASIS Security Assertion Markup Language (SAML)
			V2.0", March 2005.
	[SHA2] National Institute of Standards and Technology (NIST),		[SHS] National Institute of Standards and Technology (NIST),
	FIPS PUB 180-2: Secure Hash Standard, 1 August 2002.		FIPS PUB 180-3, Secure Hash Standard (SHS),
			October 2008.
	[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version
			1.0", RFC 2246, January 1999.
			[TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer
			Security (TLS) Protocol, Version 1.1", RFC 4346,
			February 2006.
			[TLS1.2] Dierks, T., and E. Rescorla, "The Transport Layer
			Security (TLS) Protocol, Version 1.2", RFC 5246,
			August 2008.
			[TLSEXT2] Blake-Wilson, S., Nystrom, M., Hopwood, D.,
			Mikkelsen, J., and T. Wright, "Transport Layer
			Security (TLS) Extensions", RFC 4366, April 2006.
			[TLSSUPP] Santesson, S., " TLS Handshake Message for Supplemental
			Data", RFC 4680, September 2006.
	[UPGRADE] Khare, R., and S. Lawrence, "Upgrading to TLS Within		[UPGRADE] Khare, R., and S. Lawrence, "Upgrading to TLS Within
	HTTP/1.1", RFC 2817, May 2000.		HTTP/1.1", RFC 2817, May 2000.
	[UTF-8] Yergeau, F., "UTF-8, a transformation format of		[UTF-8] Yergeau, F., "UTF-8, a transformation format of
	ISO 10646", RFC 2279, January 1998.		ISO 10646", RFC 3629, November 2003.
	[UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of		[UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of
	ISO 10646", RFC 2781, February 2000.		ISO 10646", RFC 2781, February 2000.
	8.2. Informative References		8.2. Informative References
	[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,		[TLSEXT1] Blake-Wilson, S., Nystrom, M., Hopwood, D.,
	and T. Wright, "Transport Layer Security (TLS) Extensions",		Mikkelsen, J., and T. Wright, "Transport Layer
	RFC 3546, June 2003.		Security (TLS) Extensions", RFC 3546, June 2003.
	Authors' Addresses		Authors' Addresses
	Mark Brown		Mark Brown
	RedPhone Security		RedPhone Security
	2019 Palace Avenue		2019 Palace Avenue
	Saint Paul, MN 55105		Saint Paul, MN 55105
	USA		USA
	mark <at> redphonesecurity <dot> com		mark <at> redphonesecurity <dot> com
End of changes. 28 change blocks.
	66 lines changed or deleted		105 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/