draft-josefsson-kerberos5-starttls-04.txt		draft-josefsson-kerberos5-starttls-05.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD		Internet-Draft SJD AB
	Intended status: Informational December 5, 2008		Updates: 4120 (if approved) March 2, 2009
	Expires: June 8, 2009		Intended status: Informational
			Expires: September 3, 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-04		draft-josefsson-kerberos5-starttls-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79. This document may contain material
	have been or will be disclosed, and any of which he or she becomes		from IETF Documents or IETF Contributions published or made publicly
	aware will be disclosed, in accordance with Section 6 of BCP 79.		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 June 8, 2009.		This Internet-Draft will expire on September 3, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			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. This document updates RFC 4120.
	Table of Contents		Table of Contents
	1. Introduction and Background . . . . . . . . . . . . . . . . . 3		1. Introduction and Background . . . . . . . . . . . . . . . . . 4
	2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 5		2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 6
	3. Channel Binding Pre-Authentication Data . . . . . . . . . . . 6		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 8
	5. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . . . 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].
	skipping to change at page 6, line 5		skipping to change at page 7, line 5
	the length of the Kerberos V5 packet. However, to conform with this		the length of the Kerberos V5 packet. However, to conform with this
	specification, any KDC-REQ (AS-REQ or TGS-REQ) message MUST contain		specification, any KDC-REQ (AS-REQ or TGS-REQ) message MUST contain
	the "pa-channel-binding" pre-authentication data.		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 furhter data and MUST be
	closed.		closed.
	3. Channel Binding Pre-Authentication Data		3. Examples
	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
	}
	Here we define a new pre-authentication data, called "pa-channel-
	binding". It has a padata-type integer value of #TBD. The contents
	of the padata-value field is the channel binding data, as discussed
	in [RFC5056].
	4. 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
	[ Kerberos V5 TCP extension mechanism negotiation starts ]		[ Kerberos V5 TCP extension mechanism negotiation starts ]
	[0x70000000 & STARTTLS-bit] -------->		[0x70000000 & STARTTLS-bit] -------->
	skipping to change at page 8, line 5		skipping to change at page 8, line 5
	4 octet length field		4 octet length field
	Kerberos V5 AS-REQ -------->		Kerberos V5 AS-REQ -------->
	4 octet length field		4 octet length field
	Kerberos V5 AS-REP		Kerberos V5 AS-REP
	<--------		<--------
	* Indicates optional or situation-dependent messages that are not		* Indicates optional or situation-dependent messages that are not
	always sent.		always sent.
	5. STARTTLS aware KDC Discovery		4. STARTTLS aware KDC Discovery
	Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name		Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name
	System (DNS) SRV records [RFC2782] can be used to find the address of		System (DNS) SRV records [RFC2782] can be used to find the address of
	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.
	6. IANA Considerations		5. 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		6. Acknowledgements
	Jeffrey Hutzelman provided comments that improved the protocol and		Jeffrey Hutzelman provided comments that improved the protocol and
	document.		document.
	8. Security Considerations		7. Security Considerations
	The security considerations in Kerberos V5, TLS, and the extension		The security considerations in Kerberos V5, TLS, and the extension
	mechanism framework are inherited.		mechanism framework 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.
	9. References		8. References
	9.1. Normative 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.
	[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.
	[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure		8.2. Informative References
	Channels", RFC 5056, November 2007.
	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
	Simon Josefsson		Simon Josefsson
	Simon Josefsson Datakonsult AB		Simon Josefsson Datakonsult AB
	Hagagatan 24		Hagagatan 24
	Stockholm 113 47		Stockholm 113 47
	Sweden		Sweden
	Email: simon@josefsson.org		Email: simon@josefsson.org
	URI: http://josefsson.org/		URI: http://josefsson.org/
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 15 change blocks.
	47 lines changed or deleted		47 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/