< draft-ietf-cat-kerberos-pk-cross-07.txt		draft-ietf-cat-kerberos-pk-cross-08.txt >
	INTERNET-DRAFT Matthew Hur		INTERNET-DRAFT Matthew Hur
	draft-ietf-cat-kerberos-pk-cross-07.txt Cisco Systems		draft-ietf-cat-kerberos-pk-cross-08.txt Cisco Systems
	Updates: RFC 1510 Brian Tung		Updates: RFC 1510 Brian Tung
	expires May 15, 2001 Tatyana Ryutov		November 8, 2001 (Expires May 8, 2001) Tatyana Ryutov
	Clifford Neuman		Clifford Neuman
	ISI		ISI
	Ari Medvinsky		Ari Medvinsky
	Keen.com		Liberate
	Gene Tsudik		Gene Tsudik
	UC Irvine		UC Irvine
	Bill Sommerfeld		Bill Sommerfeld
	Sun Microsystems		Sun Microsystems
	Public Key Cryptography for Cross-Realm Authentication in Kerberos		Public Key Cryptography for Cross-Realm Authentication in Kerberos
	0. Status Of this Memo		0. Status Of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	skipping to change at line 30 ¶		skipping to change at line 30 ¶
	working documents of the Internet Engineering Task Force (IETF),		working documents of the Internet Engineering Task Force (IETF),
	its areas, and its working groups. Note that other groups may		its areas, and its working groups. Note that other groups may
	also distribute working documents as Internet-Drafts.		also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as ``work in		as reference material or to cite them other than as ``work in
	progress.''		progress.''
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	To learn the current status of any Internet-Draft, please check		To learn the current status of any Internet-Draft, please check
	the ``1id-abstracts.txt'' listing contained in the Internet-Drafts		the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
	Shadow Directories on ftp.ietf.org (US East Coast),		Shadow Directories on ftp.ietf.org (US East Coast),
	nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or		nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
	munnari.oz.au (Pacific Rim).		munnari.oz.au (Pacific Rim).
			The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/1id-abstracts.html
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html
	The distribution of this memo is unlimited. It is filed as		The distribution of this memo is unlimited. It is filed as
	draft-ietf-cat-kerberos-pk-cross-07.txt, and expires May 15, 2001.		draft-ietf-cat-kerberos-pk-cross-07.txt, and expires May 15, 2001.
	Please send comments to the authors.		Please send comments to the authors.
	1. Abstract		1. Abstract
	This document defines extensions to the Kerberos protocol		This document defines extensions to the Kerberos protocol
	specification [1] to provide a method for using public key		specification [KERB] to provide a method for using public key
	cryptography to enable cross-realm authentication. The methods		cryptography to enable cross-realm authentication. The methods
	defined here specify the way in which message exchanges are to be		defined here specify the way in which message exchanges are to be
	used to transport cross-realm secret keys protected by encryption		used to transport cross-realm secret keys protected by encryption
	under public keys certified as belonging to KDCs.		under public keys certified as belonging to KDCs.
	2. Introduction		2. Introduction
	Symmetric and asymmetric key systems may co-exist within hybrid		Symmetric and asymmetric key systems may co-exist within hybrid
	architectures in order to leverage the advantages and mitigiate		architectures in order to leverage the advantages and mitigiate
	issues within the respective systems. An example of a hybrid		issues within the respective systems. An example of a hybrid
	skipping to change at line 178 ¶		skipping to change at line 178 ¶
	The basic operation of the PKCROSS protocol is as follows:		The basic operation of the PKCROSS protocol is as follows:
	1. The client submits a request to the local KDC for		1. The client submits a request to the local KDC for
	credentials for the remote realm. This is just a typical		credentials for the remote realm. This is just a typical
	cross realm request that may occur with or without PKCROSS.		cross realm request that may occur with or without PKCROSS.
	2. The local KDC submits a PKINIT request to the remote KDC to		2. The local KDC submits a PKINIT request to the remote KDC to
	obtain a "special" PKCROSS ticket. This is a standard		obtain a "special" PKCROSS ticket. This is a standard
	PKINIT request, except that PKCROSS flag (bit 9) is set in		PKINIT request, except that PKCROSS flag (bit 9) is set in
	the kdc-options field in the AS_REQ.		the kdc-options field in the AS_REQ. Note that the service
			name in the request is for pkcross/realm@REALM instead of
			krbtgt/realm@REALM.
	3. The remote KDC responds as per PKINIT, except that		3. The remote KDC responds as per PKINIT, except that
	the ticket contains a TicketExtension, which contains		the ticket contains a TicketExtension, which contains
	policy information such as lifetime of cross realm tickets		policy information such as lifetime of cross realm tickets
	issued by KDC_l to a client. The local KDC must reflect		issued by KDC_l to a client. The local KDC must reflect
	this policy information in the credentials it forwards to		this policy information in the credentials it forwards to
	the client. Call this ticket XTKT_(l,r) to indicate that		the client. Call this ticket XTKT_(l,r) to indicate that
	this ticket is used to authenticate the local KDC to the		this ticket is used to authenticate the local KDC to the
	remote KDC.		remote KDC.
	skipping to change at line 281 ¶		skipping to change at line 283 ¶
	5.2. Local KDC's Request to Remote KDC		5.2. Local KDC's Request to Remote KDC
	When the local KDC receives a request for cross-realm		When the local KDC receives a request for cross-realm
	authentication, it first checks its ticket cache to see if it has a		authentication, it first checks its ticket cache to see if it has a
	valid PKCROSS ticket, XTKT_(l,r). If it has a valid XTKT_(l,r),		valid PKCROSS ticket, XTKT_(l,r). If it has a valid XTKT_(l,r),
	then it does not need to send a request to the remote KDC (see		then it does not need to send a request to the remote KDC (see
	section 5.5).		section 5.5).
	If the local KDC does not have a valid XTKT_(l,r), it sends a		If the local KDC does not have a valid XTKT_(l,r), it sends a
	request to the remote KDC in order to establish a cross realm key		request to the remote KDC (for pkcross/realm@REALM) in order to
	and obtain the XTKT_(l,r). This request is in fact a PKINIT request		establish a cross realm key and obtain the XTKT_(l,r). This request
	as described in the PKINIT specification; i.e., it consists of an AS-		is in fact a PKINIT request as described in the PKINIT specification;
	REQ with a PA-PK-AS-REQ included as a preauthentication field.		i.e., it consists of an AS-REQ with a PA-PK-AS-REQ included as a
	Note, that the AS-REQ MUST have the PKCROSS flag (bit 9) set in the		preauthentication field. Note, that the AS-REQ MUST have the PKCROSS
	kdc_options field of the AS-REQ. Otherwise, this exchange exactly		flag (bit 9) set in the kdc_options field of the AS-REQ. Otherwise,
	follows the description given in the PKINIT specification.		this exchange exactly follows the description given in the PKINIT
			specification.
	5.3. Remote KDC's Response to Local KDC		5.3. Remote KDC's Response to Local KDC
	When the remote KDC receives the PKINIT/PKCROSS request from the		When the remote KDC receives the PKINIT/PKCROSS request from the
	local KDC, it sends back a PKINIT response as described in		local KDC, it sends back a PKINIT response as described in
	the PKINIT specification with the following exception: the encrypted		the PKINIT specification with the following exception: the encrypted
	part of the Kerberos ticket is not encrypted with the krbtgt key;		part of the Kerberos ticket is not encrypted with the krbtgt key;
	instead, it is encrypted with the ticket granting server's PKCROSS		instead, it is encrypted with the ticket granting server's PKCROSS
	key. This key, rather than the krbtgt key, is used because it		key. This key, rather than the krbtgt key, is used because it
	encrypts a ticket used for verifying a cross realm request rather		encrypts a ticket used for verifying a cross realm request rather
	than for issuing an application service ticket. Note that, as a		than for issuing an application service ticket. This is the reason
	matter of policy, the session key for the XTKT_(l,r) MAY be of		that the name pkcross/realm@REALM is used instead of
	greater strength than that of a session key for a normal PKINIT		krbtgt/realm@REALM. Note that, as a matter of policy, the session
	reply, since the XTKT_(l,r) SHOULD be much longer lived than a		key for the XTKT_(l,r) MAY be of greater strength than that of a
	normal application service ticket.		session key for a normal PKINIT reply, since the XTKT_(l,r) SHOULD
			be much longer lived than a normal application service ticket.
	In addition, the remote KDC SHOULD include policy information in the		In addition, the remote KDC SHOULD include policy information in the
	XTKT_(l,r). This policy information would then be reflected in the		XTKT_(l,r). This policy information would then be reflected in the
	cross-realm TGT, TGT_(c,r). Otherwise, the policy for TGT_(c,r)		cross-realm TGT, TGT_(c,r). Otherwise, the policy for TGT_(c,r)
	would be dictated by KDC_l rather than by KDC_r. The local KDC MAY		would be dictated by KDC_l rather than by KDC_r. The local KDC MAY
	enforce a more restrictive local policy when creating a cross-realm		enforce a more restrictive local policy when creating a cross-realm
	ticket, TGT_(c,r). For example, KDC_r may dictate a lifetime		ticket, TGT_(c,r). For example, KDC_r may dictate a lifetime
	policy of eight hours, but KDC_l may create TKT_(c,r) with a		policy of eight hours, but KDC_l may create TKT_(c,r) with a
	lifetime of four hours, as dictated by local policy. Also, the		lifetime of four hours, as dictated by local policy. Also, the
	remote KDC MAY include other information about itself along with the		remote KDC MAY include other information about itself along with the
	skipping to change at line 457 ¶		skipping to change at line 461 ¶
	[KERB] J. Kohl and C. Neuman, "The Kerberos Network		[KERB] J. Kohl and C. Neuman, "The Kerberos Network
	Authentication Service (V5)", RFC 1510, September 1993.		Authentication Service (V5)", RFC 1510, September 1993.
	[TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",		[TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky,		[PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky,
	J. Wray, J. Trostle. Public Key Cryptography for Initial		J. Wray, J. Trostle. Public Key Cryptography for Initial
	Authentication in Kerberos.		Authentication in Kerberos.
	draft-ietf-cat-kerberos-pk-init-12.txt		draft-ietf-cat-kerberos-pk-init-14.txt
	[PKTAPP] A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman.		[PKTAPP] A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman.
	Public Key Utilizing Tickets for Application		Public Key Utilizing Tickets for Application
	Servers (PKTAPP). draft-ietf-cat-kerberos-pk-tapp-03.txt		Servers (PKTAPP). draft-ietf-cat-kerberos-pk-tapp-03.txt
	[X509] ITU-T (formerly CCITT) Information technology - Open		[X509] ITU-T (formerly CCITT) Information technology - Open
	Systems Interconnection - The Directory: Authentication		Systems Interconnection - The Directory: Authentication
	Framework Recommendation X.509 ISO/IEC 9594-8		Framework Recommendation X.509 ISO/IEC 9594-8
	[NEUMAN] B.C. Neuman, "Proxy-Based Authorization and Accounting for		[NEUMAN] B.C. Neuman, "Proxy-Based Authorization and Accounting for
	Distributed Systems". Proceedings of the 13th		Distributed Systems". Proceedings of the 13th
	International Conference on Distributed Computing Systems,		International Conference on Distributed Computing Systems,
	May 1993		May 1993
	[KERB94] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication		[KERB94] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication
	Service for Computer Networks, IEEE Communications,		Service for Computer Networks, IEEE Communications,
	32(9):33-38. September 1994.		32(9):33-38. September 1994.
	[KERB-REV] C.Neuman, J. Kohl, T. Ts'o. The Kerberos Network		[KERB-REV] C.Neuman, J. Kohl, T. Ts'o. The Kerberos Network
	Authentication Service (V5).		Authentication Service (V5).
	draft-ietf-cat-kerberos-revisions-07.txt		draft-ietf-cat-kerberos-revisions-08.txt
	11. Authors' Addresses		11. Authors' Addresses
	Matthew Hur		Matthew Hur
	Cisco Systems		Cisco Systems
	500 108th Ave. NE, Suite 500		2901 Third Avenue
	Bellevue, WA 98004		Seattle, WA 98121
	Phone:		Phone: +1 206 256 3197
	EMail: mhur@cisco.com		E-Mail: mhur@cisco.com
	Brian Tung		Brian Tung
	Tatyana Ryutov		Tatyana Ryutov
	Clifford Neuman		Clifford Neuman
	USC/Information Sciences Institute		USC/Information Sciences Institute
	4676 Admiralty Way Suite 1001		4676 Admiralty Way Suite 1001
	Marina del Rey, CA 90292-6695		Marina del Rey, CA 90292-6695
	Phone: +1 310 822 1511		Phone: +1 310 822 1511
	E-Mail: {brian, tryutov, bcn}@isi.edu		E-Mail: {brian, tryutov, bcn}@isi.edu
	Ari Medvinsky		Ari Medvinsky
	Keen.com		Liberate
	2480 Sand Hill Road, Suite 200		2 Circle Star Way
	Menlo Park, CA 94025		San Carlos, CA 94070-6200
	Phone +1 650 289 3134		Phone: +1 650 701 4000
	E-mail: ari@keen.com		EMail: ari@liberate.com
	Gene Tsudik		Gene Tsudik
	ICS Dept, 458 CS Building		ICS Dept, 458 CS Building
	Irvine CA 92697-3425		Irvine CA 92697-3425
	Phone: +1 310 448 9329		Phone: +1 310 448 9329
	E-Mail: gts@ics.uci.edu		E-Mail: gts@ics.uci.edu
	Bill Sommerfeld		Bill Sommerfeld
	Sun Microsystems		Sun Microsystems
	E-Mail: sommerfeld@east.sun.com		E-Mail: sommerfeld@east.sun.com
End of changes. 13 change blocks.
	34 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/