draft-josefsson-kerberos5-starttls-06.txt		draft-josefsson-kerberos5-starttls-07.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD AB		Internet-Draft SJD AB
	Updates: 4120 (if approved) March 9, 2009		Intended status: Informational July 31, 2009
	Intended status: Informational		Expires: February 1, 2010
	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-06		draft-josefsson-kerberos5-starttls-07
	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 42
	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 10, 2009.		This Internet-Draft will expire on February 1, 2010.
	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 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.
	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. Validation of Server Certificate . . . . . . . . . . . . . . . 9		5. Server Certificates . . . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction and Background		1. Introduction and Background
	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. Validation of Server Certificate		5. Server Certificates
	The TLS protocol can provide server authentication using, for		The TLS protocol may be used in a mode that provides server
	example, X.509 and OpenPGP. By validating the server certificate,		authentication using, for example, X.509 and OpenPGP.
	clients can be certain that it is talking to the intended KDC.
	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		Requiring server certificates to be used at all times would enable
	attacks in those situations.		attacks in those situations.
	Many clients does not have secure long-term storage that is required		Many client environments do not have secure long-term storage, which
	to validate certificates. This makes it impossible to implement		is required to validate certificates. This makes it impossible to
	server certificate validation in practice on a large number of		use server certificate validation on a large number of client
	deployed systems.		systems.
	When clients have the ability, they need to be able to validate the		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. For this reason, if a KDC presents a X.509
	server certificate over TLS, it MUST contain an otherName Subject		server 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 ::=
	skipping to change at page 9, line 45		skipping to change at page 9, line 44
	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 map realm names to a copy of the
	server's certificate) and compare that with the authentication		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, there is an		When the server presents a X.509 server certificate, clients MAY use
	alternative way that clients MAY use to validate the server		"Certification Path Validation" as described in [RFC5280] to validate
	certificate. In this mode, the KDC server certificate is validated		the KDC server certificate. In addition, unless the client can
	by "Certification Path Validation" as described in [RFC5280]. In		otherwise verify that the server certificate is bound to the KDC of
	addition, the client MUST verify that the server certificate contains		the target realm, the client MUST verify that the server certificate
	the id-krb5starttls-san SAN and that the value is identical with the		contains the id-krb5starttls-san SAN and that the value is identical
	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		Jeffrey Hutzelman and Sam Hartman provided comments that improved the
	skipping to change at page 12, line 14		skipping to change at page 12, line 14
	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.
			If server authentication is used, some information about the server
			(such as its name) is visible to passive attackers.
	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.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
End of changes. 10 change blocks.
	22 lines changed or deleted		23 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/