draft-josefsson-kerberos5-starttls-07.txt		draft-josefsson-kerberos5-starttls-08.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD AB		Internet-Draft SJD AB
	Intended status: Informational July 31, 2009		Intended status: Informational January 22, 2010
	Expires: February 1, 2010		Expires: July 26, 2010
	Using Kerberos V5 over the Transport Layer Security (TLS) protocol		Using Kerberos V5 over the Transport Layer Security (TLS) protocol
	draft-josefsson-kerberos5-starttls-07		draft-josefsson-kerberos5-starttls-08
			Abstract
			This document specify how the Kerberos V5 protocol can be transported
			over the Transport Layer Security (TLS) protocol, to provide
			additional security features.
	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. This document may contain material		provisions of BCP 78 and BCP 79.
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	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.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 1, 2010.		This Internet-Draft will expire on July 26, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the BSD License.
	This document specify how the Kerberos V5 protocol can be transported		This document may contain material from IETF Documents or IETF
	over the Transport Layer Security (TLS) protocol, to provide		Contributions published or made publicly available before November
	additional security features.		10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction and Background . . . . . . . . . . . . . . . . . 4		1. Introduction and Background . . . . . . . . . . . . . . . . . 3
	2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 6		2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 4
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 8		4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 6
	5. Server Certificates . . . . . . . . . . . . . . . . . . . . . 9		5. Server Certificates . . . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction and Background		1. Introduction and Background
	This document describe how a Kerberos V5 [RFC4120] implementation may		This document describe how a Kerberos V5 [RFC4120] implementation may
	upgrade communication between clients and Key Distribution Centers		upgrade communication between clients and Key Distribution Centers
	(KDCs) to use the Transport Layer Security (TLS) [RFC5246] protocol.		(KDCs) to use the Transport Layer Security (TLS) [RFC5246] protocol.
	The TLS protocol offer integrity and privacy protected exchanges that		The TLS protocol offer integrity and privacy protected exchanges that
	can be authentication using X.509 certificates, OpenPGP keys		can be authentication using X.509 certificates, OpenPGP keys
	[RFC5081], and user name and passwords via SRP [RFC5054].		[RFC5081], and user name and passwords via Secure Remote Password
			(SRP) [RFC5054].
	There are several reasons to use Kerberos V5 over TLS.		There are several reasons to use Kerberos V5 over TLS.
	o Prevents downgrade attacks affecting, e.g., encryption types and		o Prevents downgrade attacks affecting, e.g., encryption types and
	pre-auth data negotiation. The encryption type field in KDC-REQ,		pre-auth data negotiation. The encryption type field in KDC-REQ,
	and the METHOD-DATA field with the requested pre-auth types from		and the METHOD-DATA field with the requested pre-auth types from
	the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent		the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent
	without integrity or privacy protection in Kerberos 5. This		without integrity or privacy protection in Kerberos 5. This
	allows an active attacker to replace the encryption type with a		allows an active attacker to replace the encryption type with a
	compromised encryption type, e.g., 56-bit DES, or request that		compromised encryption type, e.g., 56-bit DES, or request that
	skipping to change at page 4, line 43		skipping to change at page 4, line 44
	encryption). That part contains information, such as the client		encryption). That part contains information, such as the client
	principal name, the server principal name, the encryption types		principal name, the server principal name, the encryption types
	supported by the client, the lifetime of tickets, etc. Revealing		supported by the client, the lifetime of tickets, etc. Revealing
	such information is, in some threat models, considered a problem.		such information is, in some threat models, considered a problem.
	o Additional authentication against the KDC. In some situations,		o Additional authentication against the KDC. In some situations,
	users are equipped with smart cards with a RSA authentication key.		users are equipped with smart cards with a RSA authentication key.
	In others, users have a OpenPGP client on their desktop, with a		In others, users have a OpenPGP client on their desktop, with a
	public OpenPGP key known to the server.		public OpenPGP key known to the server.
	o The TLS protocol has been studied by many parties. In some threat
	models, the designer prefer to reduce the number of protocols that
	can hurt the overall system security if they are compromised.
	o Explicit server authentication of the KDC to the client. In		o Explicit server authentication of the KDC to the client. In
	traditional Kerberos 5, authentication of the KDC is proved as a		traditional Kerberos 5, authentication of the KDC is proved as a
	side effect that the KDC knows your encryption key (i.e., your		side effect that the KDC knows your encryption key (i.e., your
	password).		password).
	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. Kerberos V5 STARTTLS Extension		2. Kerberos V5 STARTTLS Extension
	The STARTTLS extension uses the Kerberos V5 TCP extension mechanism		The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
	[RFC5021]. The extension uses bit #TBD in the extension bitmask.		[RFC5021]. The extension uses bit #TBD in the extension bitmask.
	The protocol is as follows. After the server has sent the 4-octet		The protocol is as follows. The client requests the extension by
	value 0x00000000 to indicate support of this extension, the stream		setting the STARTTLS bit in the TCP extension mechanism bitmask.
	will be controlled by the TLS protocol and its framing. The TLS		(How to deal with extension negotiation failures at this point is
	protocol is initiated by the client.		described in [RFC5021].) After the server has sent the 4-octet value
			0x00000000 to indicate support of this extension, the stream will be
			controlled by the TLS protocol and its framing. The TLS protocol is
			initiated by the client.
	Typically, the client initiate the TLS handshake protocol by sending		Typically, the client initiate the TLS handshake protocol by sending
	a client hello, and the server responds, and the handshake continues		a client hello, and the server responds, and the handshake continues
	until it either succeed or fails.		until it either succeed or fails.
	If for any reason the handshake fails, the STARTTLS protocol will		If for any reason the handshake fails, the STARTTLS protocol will
	also fail, and the TLS error is used as the error indication. In		also fail, and the TLS error is used as the error indication. In
	this case, no further messages can be exchanged over the same TCP		this case, no further messages can be exchanged over the same TCP
	session.		session.
	skipping to change at page 7, line 9		skipping to change at page 6, line 9
	When no further Kerberos V5 messages needs to be transferred in the		When no further Kerberos V5 messages needs to be transferred in the
	TLS session, the TLS session MUST be shut down properly using the		TLS session, the TLS session MUST be shut down properly using the
	close_notify alert. When the TLS session is shut down, the TCP		close_notify alert. When the TLS session is shut down, the TCP
	connection cannot be re-used to send any further data and MUST be		connection cannot be re-used to send any further data and MUST be
	closed.		closed.
	3. Examples		3. Examples
	A complete packet flow for a successful AS-REQ/REP exchange protected		A complete packet flow for a successful AS-REQ/REP exchange protected
	by this mechanism will be as follows. The "STARTTLS-bit" is a		by this mechanism will be as follows. The "STARTTLS-bit" is a
	4-octet value with only the bit allocated for this extension set.		4-octet value with only the bit allocated for this extension set, and
			| is the binary OR operation.
	Client Server		Client Server
	[ Kerberos V5 TCP extension mechanism negotiation starts ]		[ Kerberos V5 TCP extension mechanism negotiation starts ]
	[0x70000000 & STARTTLS-bit] -------->		0x80000000 | STARTTLS-bit -------->
	[0x00000000]		0x00000000
	<--------		<--------
	[ TLS negotiation starts ]		[ TLS negotiation starts ]
	ClientHello -------->		ClientHello -------->
	ServerHello		ServerHello
	Certificate*		Certificate*
	ServerKeyExchange*		ServerKeyExchange*
	CertificateRequest*		CertificateRequest*
	<-------- ServerHelloDone		<-------- ServerHelloDone
	skipping to change at page 9, line 15		skipping to change at page 8, line 15
	5. Server Certificates		5. Server Certificates
	The TLS protocol may be used in a mode that provides server		The TLS protocol may be used in a mode that provides server
	authentication using, for example, X.509 and OpenPGP.		authentication using, for example, X.509 and OpenPGP.
	The Kerberos V5 STARTTLS protocol do not require clients to verify		The Kerberos V5 STARTTLS protocol do not require clients to verify
	the server certificate. The goal is that support for TLS in Kerberos		the server certificate. The goal is that support for TLS in Kerberos
	V5 clients should be as easy to implement and deploy as support for		V5 clients should be as easy to implement and deploy as support for
	UDP/TCP. Use of TLS, even without server certificate validation,		UDP/TCP. Use of TLS, even without server certificate validation,
	protects against some attacks that Kerberos V5 over UDP/TCP do not.		protects against some attacks that Kerberos V5 over UDP/TCP do not.
	Requiring server certificates to be used at all times would enable		(For example, passive network sniffing between the user and the KDC
	attacks in those situations.		to track which Kerberos services are used by the user.) To require
			server certificates to be validated at all times would lead to
			disabling of TLS when clients are unable to validate server
			certificates, and this may have worse security properties than using
			TLS and not validate the server certificate would have.
	Many client environments do not have secure long-term storage, which		Many client environments do not have secure long-term storage, which
	is required to validate certificates. This makes it impossible to		is required to validate certificates. This makes it impossible to
	use server certificate validation on a large number of client		use server certificate validation on a large number of client
	systems.		systems.
	When clients have the ability, they need to be able to validate the		When clients have the ability, they MUST validate the server
	server certificate. For this reason, if a KDC presents a X.509		certificate. For this reason, if a KDC presents a X.509 server
	server certificate over TLS, it MUST contain an otherName Subject		certificate over TLS, it MUST contain an otherName Subject
	Alternative Name (SAN) identified using a type-id of id-krb5starttls-		Alternative Name (SAN) identified using a type-id of id-krb5starttls-
	san. The intention is to bind the server certificate to the Kerberos		san. The intention is to bind the server certificate to the Kerberos
	realm for the purpose of using Kerberos V5 STARTTLS. The value field		realm for the purpose of using Kerberos V5 STARTTLS. The value field
	of the otherName should contain the realm as the "Realm" ASN.1 type.		of the otherName should contain the realm as the "Realm" ASN.1 type.
	id-krb5starttls-san OBJECT IDENTIFIER ::=		id-krb5starttls-san OBJECT IDENTIFIER ::=
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	private(4) enterprise(1) gnu(11591)		private(4) enterprise(1) gnu(11591)
	shishi(6) krb5starttls-san(1) }		shishi(6) krb5starttls-san(1) }
	To validate a server certificate, the client MAY use local		To validate a server certificate, the client MAY use local
	configuration (e.g., a list that map realm names to a copy of the		configuration (e.g., a list that maps the Kerberos realm to a copy of
	server's certificate) and compare that with the authentication		the server's certificate) and compare that with the authentication
	information provided from the server via TLS. For illustration, the		information provided from the server via TLS. For illustration, the
	server certificate could be a X.509 certificate or an OpenPGP key.		server certificate could be a X.509 certificate or an OpenPGP key.
	In this mode, the client need no processing related to id-		In this mode, the client need no processing related to id-
	krb5starttls-san.		krb5starttls-san.
	When the server presents a X.509 server certificate, clients MAY use		When the server presents a X.509 server certificate, clients MAY use
	"Certification Path Validation" as described in [RFC5280] to validate		"Certification Path Validation" as described in [RFC5280] to validate
	the KDC server certificate. In addition, unless the client can		the KDC server certificate. In addition, unless the client can
	otherwise verify that the server certificate is bound to the KDC of		otherwise verify that the server certificate is bound to the KDC of
	the target realm, the client MUST verify that the server certificate		the target realm, the client MUST verify that the server certificate
	skipping to change at page 11, line 7		skipping to change at page 11, line 7
	to the intended Kerberos realm.		to the intended Kerberos realm.
	6. IANA Considerations		6. IANA Considerations
	The IANA is requested to allocate a bit in the "Kerberos TCP		The IANA is requested to allocate a bit in the "Kerberos TCP
	Extensions" registry for the extension described in this document, as		Extensions" registry for the extension described in this document, as
	per [RFC5021].		per [RFC5021].
	7. Acknowledgements		7. Acknowledgements
	Jeffrey Hutzelman and Sam Hartman provided comments that improved the		Miguel A. Garcia, Jeffrey Hutzelman, Sam Hartman, and Magnus Nystroem
	protocol and document.		(in alphabetical order) provided comments that improved the protocol
			and document.
	8. Security Considerations		8. Security Considerations
	The security considerations in Kerberos V5, TLS, and the Kerberos V5		The security considerations in Kerberos V5, TLS, and the Kerberos V5
	TCP extension mechanism are inherited.		TCP extension mechanism are inherited.
	Note that TLS does not protect against Man-In-The-Middle (MITM)		Note that TLS does not protect against Man-In-The-Middle (MITM)
	attacks unless clients verify the KDC's credentials (X.509		attacks unless clients verify the KDC's credentials (X.509
	certificate, OpenPGP key, etc) correctly.		certificate, OpenPGP key, etc) correctly.
End of changes. 17 change blocks.
	58 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/