draft-josefsson-krb5starttls-bootstrap-01.txt		draft-josefsson-krb5starttls-bootstrap-02.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD AB		Internet-Draft SJD AB
	Updates: 4120 (if approved) March 3, 2009		Updates: 4120 (if approved) March 6, 2009
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 4, 2009		Expires: September 7, 2009
	Kerberos V5 Reply Keys From TLS		Deriving Keys From TLS for Kerberos V5
	draft-josefsson-krb5starttls-bootstrap-01		draft-josefsson-krb5starttls-bootstrap-02
	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		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	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 September 4, 2009.		This Internet-Draft will expire on September 7, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	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 describes how the Kerberos V5 over TLS protocol		This document describes how clients can use the Kerberos V5 over TLS
	together with a users' long term shared secret can be used to 1)		protocol together with its long term key to 1) avoid having to
	allow clients to securely learn a realm's KDC X.509 certificate, 2)		validate the server certificate, 2) securely learn a KDC's server
	distribute the X.509 trust anchors used by the KDC, and 3) make it		certificate, and 3) learn the trust anchors used by the KDC.
	possible for clients to use Kerberos V5 over TLS without having to
	validate the server certificates.
	We also describe how the Kerberos V5 over TLS protocol can be used to		We also describe how the Kerberos V5 over TLS protocol can be used to
	4) avoid the need for a long term shared key between the user and the		4) avoid the need for a long term shared key between the client and
	KDC by instead using TLS user authentication.		the KDC by instead using TLS client authentication.
	This goals are achieved by introducing two new Kerberos V5 pre-		These goals are achieved by introducing a new Kerberos V5 pre-
	authentication mechanisms that modify how the Kerberos V5 reply key		authentication type that modify how the Kerberos V5 reply key is
	is derived.		derived.
	Table of Contents		Table of Contents
	1. Introduction and Background . . . . . . . . . . . . . . . . . 4		1. Introduction and Background . . . . . . . . . . . . . . . . . . 3
	2. TLS Exporter Function . . . . . . . . . . . . . . . . . . . . 5		2. The Krb5KeyFromTLS Function . . . . . . . . . . . . . . . . . . 3
	3. Reply Key Strengthening . . . . . . . . . . . . . . . . . . . 6		3. The PA-TLS Pre-Authentication Type . . . . . . . . . . . . . . 4
	4. Avoiding Use Of Long-Term Shared Key . . . . . . . . . . . . . 8		4. Reply Key Strengthening . . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. Avoiding Use Of Long-Term Shared Key . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . . 9
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction and Background		1. Introduction and Background
	This document describes a Kerberos V5 [RFC4120] pre-authentication		This document describes a Kerberos V5 [RFC4120] pre-authentication
	mechanism that uses Kerberos V5 over TLS		type that uses Kerberos V5 over TLS
	[I-D.josefsson-kerberos5-starttls] to achieve:		[I-D.josefsson-kerberos5-starttls] to achieve:
			o The ability to use Kerberos V5 over TLS without having to validate
			the server certificates.
	o Allow Kerberos V5 clients to securely learn a Kerberos V5 realm's		o Allow Kerberos V5 clients to securely learn a Kerberos V5 realm's
	Key Distribution Center (KDC) certificates.		Key Distribution Center (KDC) certificates.
	o Securely distribute the trust anchors used by the Key Distribution		o Securely distribute the trust anchors used by the Key Distribution
	Center (KDC) in a Kerberos V5 realm.		Center (KDC) in a Kerberos V5 realm.
	o The ability to use Kerberos V5 over TLS without having to validate		These goals are achieved by having the client connect to a KDC
	the server certificates.		without verifying the server certificates, take a note of the server
			certificate and the certificate chain, and verify them as belonging
	These goals are achieved by having the client connect to a KDC, take		to the KDC the client trusts by properly decrypting the Kerberos V5
	a note of the server's certificate, and verify them as belonging to		response using the clients long term key. Only the correct KDC will
	the KDC the user trusts by properly decrypting the Kerberos V5		be able to generate a Kerberos V5 response using the clients long-
	response using the user's password. Only the correct KDC will be		term key and the secrets derived from the TLS channel [RFC5246].
	able to generate a Kerberos V5 response using the user's password and
	the secrets derived from the TLS channel.
	The mechanism to achieve the above goals is for the KDC to strengthen
	the Kerberos V5 reply key using keying material derived from the TLS
	channel [RFC5246] using the algorithm specified in Keying Material
	Exporters for Transport Layer Security (TLS)
	[I-D.ietf-tls-extractor].
	The document also describes a pre-authentication mechanism that can		The document also describes a mechanism to achieve:
	be used to achieve:
	o Allow use of Kerberos V5 without a long-term shared secret between		o Allow use of Kerberos V5 without a long-term shared secret between
	the user and the KDC.		the client and the KDC.
	This goal is achieved by having the client authenticate itself using		This goal is achieved by having the client authenticate itself using
	TLS, and having the KDC request that the client send a PA-ENC-		TLS, and having the KDC request that the client send a PA-ENC-
	TIMESTAMP pre-authentication data encrypted using a key derived from		TIMESTAMP pre-authentication data encrypted using a key derived from
	the TLS channel. If successful, the KDC will encrypt the response		the TLS channel. If successful, the KDC will encrypt the response
	using a reply key derived only from the TLS channel.		using a reply key derived only from the TLS channel.
	This document requires that both the client and the KDC MUST support		This document requires that both the client and the KDC MUST support
	Kerberos V5 over TLS [I-D.josefsson-kerberos5-starttls].		Kerberos V5 over TLS [I-D.josefsson-kerberos5-starttls].
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. TLS Exporter Function		2. The Krb5KeyFromTLS Function
	The following function Krb5KeyFromTLS is used elsewhere to derive		The following function Krb5KeyFromTLS is used to derive keys from a
	keys from a TLS session.		TLS session. This builds on the Keying Material Exporters for
			Transport Layer Security (TLS) [I-D.ietf-tls-extractor] framework and
			uses functions defined in Encryption and Checksum Specifications for
			Kerberos 5 [RFC3961].
	Krb5KeyFromTLS (inkey, inkey_len, tlscb, tlscb_len, length, label)		Krb5KeyFromTLS (ltkey, ltkey_len,
			tlscb, tlscb_len,
			enctype,
			label)
	Input: inkey encryption key, an octet string		Input: ltkey long term key,
	inkey_len length of encryption key,		an octet string
	a positive integer		ltkey_len length of long term key,
	tlscb channel binding data, an octet string,		an integer larger or equal to 0
			tlscb channel binding data,
			an octet string
	tlscb_len length of channel binding data,		tlscb_len length of channel binding data,
	a positive integer		a positive integer
	length number of bytes to derive,		etype number assigned for an encryption type
	a positive integer
	label the TLS PRF label to use,		label the TLS PRF label to use,
	a IANA registered string		a IANA registered string
	Output: outkey derived key, an "length"-octet string		Output: protkey derived protocol-key
	Steps:		Steps:
	1. Perform the TLS Exporter step:		1. Set "length" to the key-generation seed length, K, for the
			encryption type "enctype" as per RFC 3961.
			2. Set "context_value" to the concatenation of "ltkey" followed
			by "tlscb". Note that "ltkey" may be empty.
			3. Derive the value for "context_value_length" from the sum of
			"ltkey_len" and "tlscb_len".
			4. Perform the TLS Exporter step:
	outkey = PRF(master_secret, label,		outkey = PRF(master_secret, label,
	SecurityParameters.client_random +		SecurityParameters.client_random +
	SecurityParameters.server_random +		SecurityParameters.server_random +
	context_value_length + context_value		context_value_length + context_value
	)[length]		)[length]
	The "context_value" should be the concatenation of "inkey"		5. Output random-to-key(outkey). The random-to-key function is
	followed by "tlscb".		defined in RFC 3961.
	Consequently, the length of "context_value" (which used to		3. The PA-TLS Pre-Authentication Type
	derived "context_value_length") will be the sum of
	"inkey_len" and "tlscb_len".
	The values of "length" and "label" are as the inputs to this		The PA-TLS pre-authentication type is sent by the client to a KDC.
	function.		It requests that the server uses a different Kerberos V5 reply key.
			If the "only-tls" flag is true, the reply key will be derived from
			only the TLS session. If the "only-tls" flag is false, the key will
			be derived from both the TLS session and the the client long-term
			key. The exact semantic is described in sub-sequent sections.
	3. Output the derived key "outkey".		The syntax of PA-TLS is defined as follows.
	3. Reply Key Strengthening		PA-TLS ::= EncryptedData -- PA-TLS-ENC
	If the client do not (yet) have trust anchors for the KDC, it should		PA-TLS-ENC ::= SEQUENCE {
	delay verification of the server certificate.		patimestamp [0] KerberosTime -- client's time --,
			pausec [1] Microseconds OPTIONAL,
			only-tls [2] BOOLEAN
			}
	To signal that the client wishes the KDC to strengthen the reply key		The client choses the encryption type to use. Kerberos V5 [RFC4120]
	using keying material derived from the TLS session, it sends a pre-		mandates support for AES256-CTS-HMAC-SHA1-96 [RFC3962]. If the
	authentication mechanism called "pa-krb5starttls-strengthen". It has		client do not have out of band information to use another encryption
	a pdata-type integer value of #TBD.		type, clients MUST use AES256-CTS-HMAC-SHA1-96.
	The pre-authentication structure is defined in RFC 4120 as:		The key used to encrypt the PA-TLS-ENC is derived using
			Krb5KeyFromTLS with the following input:
	PA-DATA ::= SEQUENCE {		ltkey: empty string
	-- NOTE: first tag is [1], not [0]		ltkey_len: 0
	padata-type [1] Int32,		tlscb: the client's TLS Finished message data,
	padata-value [2] OCTET STRING -- might be encoded AP-REQ		as described in the "tls-unique" channel binding
	}		registration.
			tlscb_len: length of "tlscb".
			etype: the encryption type number chosen by the client
			label: "Kerberos pre-auth key"
	The content of the padata-value should be the DER encoding of the		The server process an PA-TLS by verifying that the encryption type is
	empty string.		acceptable. If this fails, the server MAY respond with a PA-ETYPE-
			INFO-TLS as defined below. The server proceed and derive the keys
			and decrypt the PA-TLS. If this fails, the server MUST respond with
			a KDC_ERR_PREAUTH_FAILED error.
	When receiving the request to use the "pa-krb5starttls-strengthen"		When the PA-TLS is successfully decrypted, the KDC needs to decide
	pre-authentication message, the KDC needs to decide whether to honor		whether to honor the request or not. This is a policy decision that
	it or not. This is a policy decision that can depend on several		can depend on several reasons, including the content of the request.
	reasons, including the content of the request. If the KDC decides
	that it does not wish to honor the "pa-krb5starttls-strengthen"		When the "tls-only" flag is true, the server MUST verify that TLS has
	request, the KDC MUST fail the request by returning		authenticated the client (e.g., by a X.509 client certificate,
			OpenPGP key, or SRP password). The KDC may perform policy checks
			whether a particular client should be allowed to use this pre-
			authentication type.
			If for any reason the server decides that it does not wish to accept
			the PA-TLS request, the server MUST fail the request by returning
	KDC_ERR_PREAUTH_FAILED.		KDC_ERR_PREAUTH_FAILED.
	When the KDC decides to honor the client's request, it will process		An PA-ETYPE-INFO-TLS message is used by the KDC to demand that a
	the incoming request as usual except that the KDC-REP reply key is		client sends a PA-TLS. The PA-ETYPE-INFO-TLS contains, by the KDC,
	post processed. The post processing uses Keying Material Exporters		acceptable encryption types. The PA-ETYPE-INFO-TLS message can be
	for Transport Layer Security (TLS) [I-D.ietf-tls-extractor], by		used by a KDC to require that clients uses PA-TLS, or to require that
	invoking the Krb5KeyFromTLS function with the following inputs:		clients send a PA-TLS using some particular encryption types.
	inkey: user's long term shared secret		The PA-ETYPE-INFO-TLS is used as follows. The KDC sends a KRB-ERROR
	inkey_len: length of "inkey"		packet with the KDC_ERR_PREAUTH_REQUIRED error-code and store a
			METHOD-DATA containing an PA-ETYPE-INFO-TLS in the e-data field.
			PA-ETYPE-INFO-TLS ::= SEQUENCE OF Int32 -- EncryptionType
			-- in preference order --,
			The client responds by sending a PA-TLS encrypted using one of the
			indicated types, or fail for policy reasons (e.g., none of the
			proposed encryption types are acceptable).
			4. Reply Key Strengthening
			If the client do not have the required information needed to verify a
			server certificate, it will delay verification of the server
			certificate. The server MUST include a root certificate in the TLS
			certificate_list.
			The client sends a PA-TLS type with the "tls-only" flag set to FALSE.
			The server process the PA-TLS as described earlier. On success, the
			server process the incoming requests as usual except that any KDC-REP
			reply key is post processed using the Krb5KeyFromTLS function with
			the following inputs:
			ltkey: client long term key in protocol-key format
			ltkey_len: length of "ltkey"
	tlscb: the client's TLS Finished message data,		tlscb: the client's TLS Finished message data,
	as described in the "tls-unique" channel binding		as described in the "tls-unique" channel binding
	registration.		registration.
	tlscb_len: length of "tlscb".		tlscb_len: length of "tlscb".
	length: same as "inkey_len"		etype: encryption type number of client long-term key
	label: "Kerberos V5 strengthen key"		label: "Kerberos strengthen key"
	The client will strengthen its local KDC-REP reply key using the same		The client will strengthen its local KDC-REP reply key using the same
	procedure.		procedure. On successful decryption of the KDC-REP, the clients is
			certain that it is talking to a KDC that knows the client's shared
	On successful decryption of the KDC-REP, the clients is certain that		key without any man-in-the-middle. The client can then remember the
	it is talking to a KDC that knows the client's shared key without any		server certificate and/or trust anchors transferred during the TLS
	man-in-the-middle. The client can then remember the KDC server
	certificate and/or trust anchors transferred during the TLS
	handshake, to be used during future Kerberos V5 over TLS connections.		handshake, to be used during future Kerberos V5 over TLS connections.
	The client MAY skip using this protocol for future connections, and		If the client can securely store the information required to validate
	instead rely on the standard Kerberos V5 over TLS protocol with		the server in the future, the client MAY skip using the PA-TLS for
	proper validation of server certificate.		future connections, and instead rely on the standard Kerberos V5 over
			TLS protocol with proper validation of server certificate.
	4. Avoiding Use Of Long-Term Shared Key
	The ETYPE-INFO-TLS pre-authentication type is sent by the KDC in a		5. Avoiding Use Of Long-Term Shared Key
	KRB-ERROR indicating a requirement for additional pre-authentication
	before sending a reply protected using a key derived only from the
	TLS session. It is used to notify a client of which encryption type
	to use for the encryption of an encrypted timestamp for the purposes
	of sending a PA-ENC-TIMESTAMP pre-authentication value using an
	encryption key derived from the TLS session.
	ETYPE-INFO-TLS ::= SEQUENCE OF Int32 -- EncryptionType		The client can use TLS to authenticate it, and then ask the KDC to
	-- in preference order --,		use the TLS authentication to authenticate the Kerberos request. The
			latter step is performed by sending a PA-TLS type with "only-tls" set
			to TRUE.
	The client choses a supported encryption type and re-send the request		The server process the PA-TLS as described earlier. On success, the
	with a PA-ENC-TIMESTAMP encrypted using a key derived from the TLS		server process the incoming Kerberos requests as usual except that
	session by using Krb5KeyFromTLS with the following input:		the KDC-REP reply key will be generated by Krb5KeyFromTLS with the
			following inputs:
	inkey: empty string		ltkey: empty string
	inkey_len: 0		ltkey_len: 0
	tlscb: the client's TLS Finished message data,		tlscb: the client's TLS Finished message data,
	as described in the "tls-unique" channel binding		as described in the "tls-unique" channel binding
	registration.		registration.
	tlscb_len: length of "tlscb".		tlscb_len: length of "tlscb".
	length: key length of the chosen encryption type		etype: encryption type used for the PA-TLS
	label: "Kerberos V5 pre-auth key"		label: "Kerberos derive key"
	The KDC verifies the PA-ENC-TIMESTAMP and if successful it knows it
	is talking to the authenticated user and can send a response
	encrypted using the same encryption type as the client selected but
	with a key derived using Krb5KeyFromTLS with the same inputs except
	for:
	label: "Kerberos V5 derive key"
	The client derives the key the same way, and will be able to decrypt		The client derives the key the same way, and will be able to decrypt
	the response.		the response.
	Note that this means the long term shared key will not be involved in		Note that this means the long term shared key will not be involved in
	deriving the reply that protects the Kerberos V5 response.		deriving the reply that protects the Kerberos V5 response.
	(The reason for encrypting the response is because Kerberos V5 does		(The reason for encrypting the response is because Kerberos V5 does
	not have any null encryption scheme.)		not have any null encryption scheme.)
	5. IANA Considerations		6. IANA Considerations
	The IANA is requested to allocate the string "kerberos V5 reply key"		The IANA is requested to allocate the strings "Kerberos pre-auth
	in the TLS Exporter label registry.		key", "Kerberos strengthen key", and "Kerberos derive key" in the TLS
			Exporter label registry.
	6. Acknowledgements		7. Acknowledgements
	Nicolas Williams mentioned the advantages in		Nicolas Williams mentioned the advantages in
	<http://permalink.gmane.org/gmane.ietf.krb-wg/5016>, and also		<http://permalink.gmane.org/gmane.ietf.krb-wg/5016>, and suggested
	suggested the use of PA-ENC-TIMESTAMP.		the use of (what became) PA-TLS.
	7. Security Considerations		8. Security Considerations
	The security considerations in Kerberos V5 [RFC4120], TLS [RFC5246],		The security considerations in Kerberos V5 [RFC4120], TLS [RFC5246],
	Kerberos V5 TCP extension [RFC5021], and Kerberos V5 over TLS		Kerberos V5 TCP extension [RFC5021], and Kerberos V5 over TLS
	[I-D.josefsson-kerberos5-starttls] are inherited.		[I-D.josefsson-kerberos5-starttls] are inherited.
	By using ETYPE-INFO-TLS the long-term shared key of the user is no		By request PA-TLS with only-tls set to TRUE the client's long-term
	longer involved in deriving the Kerberos V5 ticket. Instead only the		key is no longer involved in deriving the Kerberos V5 ticket.
	authentication from the TLS channel is used. This changes the		Instead only the authentication from the TLS channel is used. This
	cryptographic model of Kerberos V5 significantly, and makes it		changes the cryptographic model of Kerberos V5 significantly, and
	possible to operate Kerberos V5 without even having a long term		makes it possible to operate Kerberos V5 without even having a long
	shared key for a particular user. This changes how a Kerberos V5		term shared key for a particular user. This changes how a Kerberos
	security analysis should be made, so be aware of this model change		V5 security analysis should be made, so be aware of this model change
	when reading other literature.		when reading other literature.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] 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.
			[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
			Kerberos 5", RFC 3961, February 2005.
			[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
			Encryption for Kerberos 5", RFC 3962, February 2005.
	[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The		[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
	Kerberos Network Authentication Service (V5)", RFC 4120,		Kerberos Network Authentication Service (V5)", RFC 4120,
	July 2005.		July 2005.
	[I-D.josefsson-kerberos5-starttls]		[I-D.josefsson-kerberos5-starttls]
	Josefsson, S., "Using Kerberos V5 over the Transport Layer		Josefsson, S., "Using Kerberos V5 over the Transport Layer
	Security (TLS) protocol",		Security (TLS) protocol",
	draft-josefsson-kerberos5-starttls-04 (work in progress),		draft-josefsson-kerberos5-starttls-04 (work in progress),
	December 2008.		December 2008.
	[I-D.ietf-tls-extractor]		[I-D.ietf-tls-extractor]
	Rescorla, E., "Keying Material Exporters for Transport		Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", draft-ietf-tls-extractor-04 (work		Layer Security (TLS)", draft-ietf-tls-extractor-04 (work
	in progress), February 2009.		in progress), February 2009.
	8.2. Informative References		9.2. Informative References
	[RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key		[RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key
	Distribution Center (KDC) Exchanges over TCP", RFC 5021,		Distribution Center (KDC) Exchanges over TCP", RFC 5021,
	August 2007.		August 2007.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	Author's Address		Author's Address
End of changes. 52 change blocks.
	149 lines changed or deleted		191 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/