draft-josefsson-krb5starttls-bootstrap-00.txt		draft-josefsson-krb5starttls-bootstrap-01.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD AB		Internet-Draft SJD AB
	Updates: 4120 (if approved) March 2, 2009		Updates: 4120 (if approved) March 3, 2009
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 3, 2009		Expires: September 4, 2009
	Strengthening the Kerberos V5 Reply Key using TLS		Kerberos V5 Reply Keys From TLS
	draft-josefsson-krb5starttls-bootstrap-00		draft-josefsson-krb5starttls-bootstrap-01
	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 3, 2009.		This Internet-Draft will expire on September 4, 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 to strengthen the Kerberos V5 reply key		This document describes how the Kerberos V5 over TLS protocol
	using keying material derived from TLS, by using a pre-authentication		together with a users' long term shared secret can be used to 1)
	mechanism. The goals are to 1) allow clients to securely learn a		allow clients to securely learn a realm's KDC X.509 certificate, 2)
	realm's KDC X.509 certificate, 2) distribute the X.509 trust anchors		distribute the X.509 trust anchors used by the KDC, and 3) make it
	used by the KDC, and 3) make it possible for clients to use Kerberos		possible for clients to use Kerberos V5 over TLS without having to
	V5 over TLS without having to validate the server certificates.		validate the server certificates.
			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
			KDC by instead using TLS user authentication.
			This goals are achieved by introducing two new Kerberos V5 pre-
			authentication mechanisms that modify how the Kerberos V5 reply key
			is derived.
	Table of Contents		Table of Contents
	1. Introduction and Background . . . . . . . . . . . . . . . . . 3		1. Introduction and Background . . . . . . . . . . . . . . . . . 4
	2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. TLS Exporter Function . . . . . . . . . . . . . . . . . . . . 5
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		3. Reply Key Strengthening . . . . . . . . . . . . . . . . . . . 6
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		4. Avoiding Use Of Long-Term Shared Key . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6.2. Informative References . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
			8.2. Informative References . . . . . . . . . . . . . . . . . . 12
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
	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		mechanism that uses Kerberos V5 over TLS
	[I-D.josefsson-kerberos5-starttls] to achieve:		[I-D.josefsson-kerberos5-starttls] to achieve:
	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. This is achieved by		Key Distribution Center (KDC) certificates.
	having the client connect to a KDC, take a note of the server's
	certificate, and verify them as belonging to the KDC the user
	trusts by properly decrypting the Kerberos V5 response using the
	user's password. Only the correct KDC will be able to generate a
	Kerberos V5 response using the user's password and the secrets
	derived from the TLS channel.
	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. This is achieved the same		Center (KDC) in a Kerberos V5 realm.
	way as before, but rather than remembering the server certificate,
	it remembers the trust anchor.
	o The ability to use Kerberos V5 over TLS without having to validate		o The ability to use Kerberos V5 over TLS without having to validate
	the server certificates.		the server certificates.
			These goals are achieved by having the client connect to a KDC, take
			a note of the server's certificate, and verify them as belonging to
			the KDC the user trusts by properly decrypting the Kerberos V5
			response using the user's password. Only the correct KDC will be
			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 mechanism to achieve the above goals is for the KDC to strengthen
	the Kerberos V5 reply key using keying material derived from the TLS		the Kerberos V5 reply key using keying material derived from the TLS
	channel [RFC5246] using the algorithm specified in Keying Material		channel [RFC5246] using the algorithm specified in Keying Material
	Exporters for Transport Layer Security (TLS)		Exporters for Transport Layer Security (TLS)
	[I-D.ietf-tls-extractor].		[I-D.ietf-tls-extractor].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The document also describes a pre-authentication mechanism that can
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		be used to achieve:
	document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Protocol
	The client and KDC MUST support Kerberos V5 over TLS
	[I-D.josefsson-kerberos5-starttls]. If the client do not (yet) have
	trust anchors for the KDC, it should disable verification of the
	server certificate.
	To signal that the client wishes the KDC to strengthen the reply key		o Allow use of Kerberos V5 without a long-term shared secret between
	using keying material derived from the TLS session, it sends a pre-		the user and the KDC.
	authentication mechanism called "pa-krb5starttls-bootstrap". It has
	a pdata-type integer value of #TBD.
	The pre-authentication structure is defined in RFC 4120 as:		This goal is achieved by having the client authenticate itself using
			TLS, and having the KDC request that the client send a PA-ENC-
			TIMESTAMP pre-authentication data encrypted using a key derived from
			the TLS channel. If successful, the KDC will encrypt the response
			using a reply key derived only from the TLS channel.
	PA-DATA ::= SEQUENCE {		This document requires that both the client and the KDC MUST support
	-- NOTE: first tag is [1], not [0]		Kerberos V5 over TLS [I-D.josefsson-kerberos5-starttls].
	padata-type [1] Int32,
	padata-value [2] OCTET STRING -- might be encoded AP-REQ
	}
	The content of the padata-value should be the DER encoding of the		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	empty string.		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC2119].
	When receiving the request to use the "pa-krb5starttls-bootstrap"		2. TLS Exporter Function
	pre-authentication message, the KDC needs to decide whether to honor
	it or not. This is a policy decision that can depend on several
	reasons, including the content of the request. If the KDC decides
	that it does not wish to honor the "pa-krb5starttls-bootstrap"
	request, the KDC MUST fail the request by returning
	KDC_ERR_PREAUTH_FAILED.
	When the KDC decides to honor the client's request, it will process		The following function Krb5KeyFromTLS is used elsewhere to derive
	the incoming request as usual except that the KDC-REP reply key is		keys from a TLS session.
	post processed as follows. The post processing uses Keying Material
	Exporters for Transport Layer Security (TLS)
	[I-D.ietf-tls-extractor]. The channel binding input "tlscb" value
	MUST be the client's TLS Finished message data as described in the
	"tls-unique" channel binding registration.
	StrengthenKrb5ReplyKeyUsingTLS (inkey, inkey_len,		Krb5KeyFromTLS (inkey, inkey_len, tlscb, tlscb_len, length, label)
	tlscb, tlscb_len)
	Input: inkey encryption key, an octet string		Input: inkey encryption key, an octet string
	inkey_len length of encryption key,		inkey_len length of encryption key,
	a positive integer		a positive integer
	tlscb channel binding data, an octet string,		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,
			a positive integer
			label the TLS PRF label to use,
			a IANA registered string
	Output: outkey derived key, a inlen-octet string		Output: outkey derived key, an "length"-octet string
	Steps:		Steps:
	1. Perform the TLS Exporter step:		1. 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"		The "context_value" should be the concatenation of "inkey"
	followed by "tlscb".		followed by "tlscb".
	Consequently, the length of "context_value" (which used to		Consequently, the length of "context_value" (which used to
	derived "context_value_length") will be the sum of		derived "context_value_length") will be the sum of
	"inkey_len" and "tlscb_len".		"inkey_len" and "tlscb_len".
	Use the value of "inkey_len" as the value of the "length"		The values of "length" and "label" are as the inputs to this
	variable.		function.
	3. Output the derived key "outkey".		3. Output the derived key "outkey".
	The client will strengthen the KDC-REP reply key using the same		3. Reply Key Strengthening
			If the client do not (yet) have trust anchors for the KDC, it should
			delay verification of the server certificate.
			To signal that the client wishes the KDC to strengthen the reply key
			using keying material derived from the TLS session, it sends a pre-
			authentication mechanism called "pa-krb5starttls-strengthen". It has
			a pdata-type integer value of #TBD.
			The pre-authentication structure is defined in RFC 4120 as:
			PA-DATA ::= SEQUENCE {
			-- NOTE: first tag is [1], not [0]
			padata-type [1] Int32,
			padata-value [2] OCTET STRING -- might be encoded AP-REQ
			}
			The content of the padata-value should be the DER encoding of the
			empty string.
			When receiving the request to use the "pa-krb5starttls-strengthen"
			pre-authentication message, the KDC needs to decide whether to honor
			it or not. This is a policy decision that can depend on several
			reasons, including the content of the request. If the KDC decides
			that it does not wish to honor the "pa-krb5starttls-strengthen"
			request, the KDC MUST fail the request by returning
			KDC_ERR_PREAUTH_FAILED.
			When the KDC decides to honor the client's request, it will process
			the incoming request as usual except that the KDC-REP reply key is
			post processed. The post processing uses Keying Material Exporters
			for Transport Layer Security (TLS) [I-D.ietf-tls-extractor], by
			invoking the Krb5KeyFromTLS function with the following inputs:
			inkey: user's long term shared secret
			inkey_len: length of "inkey"
			tlscb: the client's TLS Finished message data,
			as described in the "tls-unique" channel binding
			registration.
			tlscb_len: length of "tlscb".
			length: same as "inkey_len"
			label: "Kerberos V5 strengthen key"
			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		On successful decryption of the KDC-REP, the clients is certain that
	it is talking to a KDC that knows the client's shared key without any		it is talking to a KDC that knows the client's shared key without any
	man-in-the-middle. The client can then remember the KDC server		man-in-the-middle. The client can then remember the KDC server
	certificate and/or trust anchors transferred during the TLS		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		The client MAY skip using this protocol for future connections, and
	instead rely on the standard Kerberos V5 over TLS protocol with		instead rely on the standard Kerberos V5 over TLS protocol with
	proper validation of server certificate.		proper validation of server certificate.
	3. IANA Considerations		4. Avoiding Use Of Long-Term Shared Key
	None.		The ETYPE-INFO-TLS pre-authentication type is sent by the KDC in a
			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.
	4. Acknowledgements		ETYPE-INFO-TLS ::= SEQUENCE OF Int32 -- EncryptionType
			-- in preference order --,
			The client choses a supported encryption type and re-send the request
			with a PA-ENC-TIMESTAMP encrypted using a key derived from the TLS
			session by using Krb5KeyFromTLS with the following input:
			inkey: empty string
			inkey_len: 0
			tlscb: the client's TLS Finished message data,
			as described in the "tls-unique" channel binding
			registration.
			tlscb_len: length of "tlscb".
			length: key length of the chosen encryption type
			label: "Kerberos V5 pre-auth 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 response.
			Note that this means the long term shared key will not be involved in
			deriving the reply that protects the Kerberos V5 response.
			(The reason for encrypting the response is because Kerberos V5 does
			not have any null encryption scheme.)
			5. IANA Considerations
			The IANA is requested to allocate the string "kerberos V5 reply key"
			in the TLS Exporter label registry.
			6. Acknowledgements
	Nicolas Williams mentioned the advantages in		Nicolas Williams mentioned the advantages in
	<http://permalink.gmane.org/gmane.ietf.krb-wg/5016>.		<http://permalink.gmane.org/gmane.ietf.krb-wg/5016>, and also
			suggested the use of PA-ENC-TIMESTAMP.
	5. Security Considerations		7. 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.
	6. References		By using ETYPE-INFO-TLS the long-term shared key of the user is no
			longer involved in deriving the Kerberos V5 ticket. Instead only the
			authentication from the TLS channel is used. This changes the
			cryptographic model of Kerberos V5 significantly, and makes it
			possible to operate Kerberos V5 without even having a long term
			shared key for a particular user. This changes how a Kerberos V5
			security analysis should be made, so be aware of this model change
			when reading other literature.
	6.1. Normative References		8. References
			8.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.
	[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.
	6.2. Informative References		8.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. 30 change blocks.
	80 lines changed or deleted		172 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/