draft-josefsson-kerberos5-starttls-05.txt		draft-josefsson-kerberos5-starttls-06.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 9, 2009
	Intended status: Informational		Intended status: Informational
	Expires: September 3, 2009		Expires: September 10, 2009
	Using Kerberos V5 over the Transport Layer Security (TLS) protocol		Using Kerberos V5 over the Transport Layer Security (TLS) protocol
	draft-josefsson-kerberos5-starttls-05		draft-josefsson-kerberos5-starttls-06
	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. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 43		skipping to change at page 1, line 43
	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 10, 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
	skipping to change at page 3, line 17		skipping to change at page 3, line 17
	This document specify how the Kerberos V5 protocol can be transported		This document specify how the Kerberos V5 protocol can be transported
	over the Transport Layer Security (TLS) protocol, to provide		over the Transport Layer Security (TLS) protocol, to provide
	additional security features. This document updates RFC 4120.		additional security features. This document updates RFC 4120.
	Table of Contents		Table of Contents
	1. Introduction and Background . . . . . . . . . . . . . . . . . 4		1. Introduction and Background . . . . . . . . . . . . . . . . . 4
	2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 6		2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 6
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 8		4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. Validation of Server Certificate . . . . . . . . . . . . . . . 9
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . . 13
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
	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 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 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
	clients should use a broken pre-auth type. Since clients in		clients should use a broken pre-auth type. Since clients in
	general cannot know the encryption types other servers support, or		general cannot know the encryption types other servers support, or
	the pre-auth types servers prefer or require, it is difficult for		the pre-auth types servers prefer or require, it is difficult for
	the client to detect if there was a man-in-the-middle or if the		the client to detect if there was a man-in-the-middle or if the
	remote server simply did not support a stronger encryption type or		remote server simply did not support a stronger encryption type or
	preferred another pre-auth type.		preferred another pre-auth type.
	o Kerberos exchanges are privacy protected. Part of many Kerberos		o Kerberos exchanges are privacy protected. Part of many Kerberos
	packets are transfered without privacy protection (i.e.,		packets are transferred without privacy protection (i.e.,
	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.
	skipping to change at page 6, line 28		skipping to change at page 6, line 28
	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.
	If the handshake succeeds, the Kerberos V5 authentication protocol is		If the handshake succeeds, the Kerberos V5 authentication protocol is
	performed within the protected TLS channel, like a normal TCP		performed within the protected TLS channel, like a normal TCP
	Kerberos V5 exchange. In particular, this means that every Kerberos		Kerberos V5 exchange. In particular, this means that every Kerberos
	V5 packet will be prefixed by a 4-octet length field, that indicate		V5 packet will be prefixed by a 4-octet length field, that indicate
	the length of the Kerberos V5 packet. However, to conform with this		the length of the Kerberos V5 packet.
	specification, any KDC-REQ (AS-REQ or TGS-REQ) message MUST contain
	the "pa-channel-binding" pre-authentication data.
	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 furhter 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.
	Client Server		Client Server
	skipping to change at page 9, line 5		skipping to change at page 9, line 5
	an KDC. We define a new Proto of "tls" to indicate that the		an KDC. We define a new Proto of "tls" to indicate that the
	particular KDC is intended to support this STARTTLS extension. The		particular KDC is intended to support this STARTTLS extension. The
	Service, Realm, TTL, Class, SRV, Priority, Weight, Port and Target		Service, Realm, TTL, Class, SRV, Priority, Weight, Port and Target
	have the same meaning as in RFC 4120.		have the same meaning as in RFC 4120.
	For example:		For example:
	_kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.		_kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
	_kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.		_kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
	5. IANA Considerations		5. Validation of Server Certificate
			The TLS protocol can provide server authentication using, for
			example, X.509 and OpenPGP. By validating the server certificate,
			clients can be certain that it is talking to the intended KDC.
			The Kerberos V5 STARTTLS protocol do not require clients to verify
			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
			UDP/TCP. Use of TLS, even without server certificate validation,
			protects against some attacks that Kerberos V5 over UDP/TCP do not.
			Requiring server certificates to be used at all times would enable
			attacks in those situations.
			Many clients does not have secure long-term storage that is required
			to validate certificates. This makes it impossible to implement
			server certificate validation in practice on a large number of
			deployed systems.
			When clients have the ability, they need to be able to validate the
			server certificate. For this reason, if a KDC presents a X.509
			server certificate over TLS, it MUST contain an otherName Subject
			Alternative Name (SAN) identified using a type-id of id-krb5starttls-
			san. The intention is to bind the server certificate to the Kerberos
			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.
			id-krb5starttls-san OBJECT IDENTIFIER ::=
			{ iso(1) identified-organization(3) dod(6) internet(1)
			private(4) enterprise(1) gnu(11591)
			shishi(6) krb5starttls-san(1) }
			To validate a server certificate, the client MAY use local
			configuration (e.g., a list that map realm names to a copy of the
			server's certificate) and compare that with the authentication
			information provided from the server via TLS. For illustration, the
			server certificate could be a X.509 certificate or an OpenPGP key.
			In this mode, the client need no processing related to id-
			krb5starttls-san.
			When the server presents a X.509 server certificate, there is an
			alternative way that clients MAY use to validate the server
			certificate. In this mode, the KDC server certificate is validated
			by "Certification Path Validation" as described in [RFC5280]. In
			addition, the client MUST verify that the server certificate contains
			the id-krb5starttls-san SAN and that the value is identical with the
			intended Kerberos realm.
			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].
	6. Acknowledgements		7. Acknowledgements
	Jeffrey Hutzelman provided comments that improved the protocol and		Jeffrey Hutzelman and Sam Hartman provided comments that improved the
	document.		protocol and document.
	7. Security Considerations		8. Security Considerations
	The security considerations in Kerberos V5, TLS, and the extension		The security considerations in Kerberos V5, TLS, and the Kerberos V5
	mechanism framework 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.
	To protect against the inherent downgrade attack in the extension		To protect against the inherent downgrade attack in the extension
	framework, implementations SHOULD offer a policy mode that requires		framework, implementations SHOULD offer a policy mode that requires
	this extension to always be successfully negotiated, for a particular		this extension to always be successfully negotiated, for a particular
	realm, or generally. For interoperability with implementations that		realm, or generally. For interoperability with implementations that
	do not support this extension, the policy mode SHOULD be disabled by		do not support this extension, the policy mode SHOULD be disabled by
	default.		default.
	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.
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	February 2000.		February 2000.
	[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.
	[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.
	[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.
	8.2. Informative References		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
			Housley, R., and W. Polk, "Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 5280, May 2008.
			9.2. Informative References
	[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,		[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
	"Using the Secure Remote Password (SRP) Protocol for TLS		"Using the Secure Remote Password (SRP) Protocol for TLS
	Authentication", RFC 5054, November 2007.		Authentication", RFC 5054, November 2007.
	[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport		[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
	Layer Security (TLS) Authentication", RFC 5081,		Layer Security (TLS) Authentication", RFC 5081,
	November 2007.		November 2007.
	Author's Address		Author's Address
End of changes. 17 change blocks.
	27 lines changed or deleted		79 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/