draft-josefsson-kerberos5-starttls-08.txt		draft-josefsson-kerberos5-starttls.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD AB		Internet-Draft SJD AB
	Intended status: Informational January 22, 2010		Intended status: Informational February 2, 2010
	Expires: July 26, 2010		Expires: August 6, 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-08		draft-josefsson-kerberos5-starttls-08
	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.		additional security features.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 July 26, 2010.		This Internet-Draft will expire on August 6, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 8, line 10		skipping to change at page 8, line 10
	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. 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		A goal for the protocol described in this memo is that it should be
	the server certificate. The goal is that support for TLS in Kerberos		as easy to implement and deploy on clients as support for UDP/TCP.
	V5 clients should be as easy to implement and deploy as support for		Since many client environments do not have secure long-term storage
	UDP/TCP. Use of TLS, even without server certificate validation,		(and server certificate validation requires some form of long-term
	protects against some attacks that Kerberos V5 over UDP/TCP do not.		storage), the Kerberos V5 STARTTLS protocol does not require clients
	(For example, passive network sniffing between the user and the KDC		to verify server certificates. If server certification had been
	to track which Kerberos services are used by the user.) To require		required, then environments with constrained clients such as those
	server certificates to be validated at all times would lead to		mentioned would be forced to disable TLS; this would arguably be
	disabling of TLS when clients are unable to validate server		worse than TLS without server certificate validation as use of TLS,
	certificates, and this may have worse security properties than using		even without server certificate validation, protects against some
	TLS and not validate the server certificate would have.		attacks that Kerberos V5 over UDP/TCP do not. For example, even
			without server certificate validation, TLS does protect against
			passive network sniffing aimed at tracking Kerberos service usage by
			a given client.
	Many client environments do not have secure long-term storage, which		Note however that use of TLS without server certificate verification
	is required to validate certificates. This makes it impossible to		opens up for a range of active attacks such as man-in-the-middle.
	use server certificate validation on a large number of client
	systems.
	When clients have the ability, they MUST validate the server		When clients have the ability, they MUST 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		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 ::=
End of changes. 4 change blocks.
	18 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/