< draft-ietf-cat-kerberos-pk-init-11.txt		draft-ietf-cat-kerberos-pk-init-12.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-11.txt Clifford Neuman		draft-ietf-cat-kerberos-pk-init-12.txt Clifford Neuman
	Updates: RFC 1510 USC/ISI		Updates: RFC 1510 USC/ISI
	expires September 15, 2000 Matthew Hur		expires January 15, 2001 Matthew Hur
	CyberSafe Corporation		CyberSafe Corporation
	Ari Medvinsky		Ari Medvinsky
	Keen.com, Inc.		Keen.com, Inc.
	Sasha Medvinsky		Sasha Medvinsky
	Motorola		Motorola
	John Wray		John Wray
	Iris Associates, Inc.		Iris Associates, Inc.
	Jonathan Trostle		Jonathan Trostle
	Cisco		Cisco
	skipping to change at line 44 ¶		skipping to change at line 44 ¶
	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.
	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 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-init-11.txt, and expires September 15,		draft-ietf-cat-kerberos-pk-init-11.txt, and expires January 15,
	2000. Please send comments to the authors.		2001. Please send comments to the authors.
	1. Abstract		1. Abstract
	This document defines extensions (PKINIT) to the Kerberos protocol		This document defines extensions (PKINIT) to the Kerberos protocol
	specification (RFC 1510 [1]) to provide a method for using public		specification (RFC 1510 [1]) to provide a method for using public
	key cryptography during initial authentication. The methods		key cryptography during initial authentication. The methods
	defined specify the ways in which preauthentication data fields and		defined specify the ways in which preauthentication data fields and
	error data fields in Kerberos messages are to be used to transport		error data fields in Kerberos messages are to be used to transport
	public key data.		public key data.
	skipping to change at line 426 ¶		skipping to change at line 426 ¶
	The SignedData data type is specified in the Cryptographic		The SignedData data type is specified in the Cryptographic
	Message Syntax, a product of the S/MIME working group of the		Message Syntax, a product of the S/MIME working group of the
	IETF. The following describes how to fill in the fields of		IETF. The following describes how to fill in the fields of
	this data:		this data:
	1. The encapContentInfo field must contain the PKAuthenticator		1. The encapContentInfo field must contain the PKAuthenticator
	and, optionally, the client's Diffie Hellman public value.		and, optionally, the client's Diffie Hellman public value.
	a. The eContentType field shall contain the OID value for		a. The eContentType field shall contain the OID value for
	pkdata: iso (1) org (3) dod (6) internet (1) security (5)		pkauthdata: iso (1) org (3) dod (6) internet (1)
	kerberosv5 (2) pkinit (3) pkdata (1)		security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
	b. The eContent field is data of the type AuthPack (below).		b. The eContent field is data of the type AuthPack (below).
	2. The signerInfos field contains the signature of AuthPack.		2. The signerInfos field contains the signature of AuthPack.
	3. The Certificates field, when non-empty, contains the client's		3. The Certificates field, when non-empty, contains the client's
	certificate chain. If present, the KDC uses the public key		certificate chain. If present, the KDC uses the public key
	from the client's certificate to verify the signature in the		from the client's certificate to verify the signature in the
	request. Note that the client may pass different certificate		request. Note that the client may pass different certificate
	chains that are used for signing or for encrypting. Thus,		chains that are used for signing or for encrypting. Thus,
	skipping to change at line 457 ¶		skipping to change at line 457 ¶
	there must always be (at least) a signature certificate.		there must always be (at least) a signature certificate.
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
	-- if client is using Diffie-Hellman		-- if client is using Diffie-Hellman
	-- (ephemeral-ephemeral only)		-- (ephemeral-ephemeral only)
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	kdcName [0] PrincipalName,		cusec [0] INTEGER,
	kdcRealm [1] Realm,
	cusec [2] INTEGER,
	-- for replay prevention as in RFC1510		-- for replay prevention as in RFC1510
	ctime [3] KerberosTime,		ctime [1] KerberosTime,
	-- for replay prevention as in RFC1510		-- for replay prevention as in RFC1510
	nonce [4] INTEGER		nonce [2] INTEGER,
			pachecksum [3] Checksum
			-- Checksum over KDC-REQ-BODY
			-- Defined by Kerberos spec
	}		}
	SubjectPublicKeyInfo ::= SEQUENCE {		SubjectPublicKeyInfo ::= SEQUENCE {
	algorithm AlgorithmIdentifier,		algorithm AlgorithmIdentifier,
	-- dhKeyAgreement		-- dhKeyAgreement
	subjectPublicKey BIT STRING		subjectPublicKey BIT STRING
	-- for DH, equals		-- for DH, equals
	-- public exponent (INTEGER encoded		-- public exponent (INTEGER encoded
	-- as payload of BIT STRING)		-- as payload of BIT STRING)
	} -- as specified by the X.509 recommendation [10]		} -- as specified by the X.509 recommendation [10]
	AlgorithmIdentifier ::= SEQUENCE {		AlgorithmIdentifier ::= SEQUENCE {
	algorithm ALGORITHM.&id,		algorithm OBJECT IDENTIFIER,
	parameters ALGORITHM.&type		-- for dhKeyAgreement, this is
			-- { iso (1) member-body (2) US (840)
			-- rsadsi (113459) pkcs (1) 3 1 }
			-- from PKCS #3 [20]
			parameters ANY DEFINED by algorithm OPTIONAL
			-- for dhKeyAgreement, this is
			-- DHParameter
	} -- as specified by the X.509 recommendation [10]		} -- as specified by the X.509 recommendation [10]
			DHParameter ::= SEQUENCE {
			prime INTEGER,
			-- p
			base INTEGER,
			-- g
			privateValueLength INTEGER OPTIONAL
			-- l
			} -- as defined in PKCS #3 [20]
	If the client passes an issuer and serial number in the request,		If the client passes an issuer and serial number in the request,
	the KDC is requested to use the referred-to certificate. If none		the KDC is requested to use the referred-to certificate. If none
	exists, then the KDC returns an error of type		exists, then the KDC returns an error of type
	KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the		KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
	other hand, the client does not pass any trustedCertifiers,		other hand, the client does not pass any trustedCertifiers,
	believing that it has the KDC's certificate, but the KDC has more		believing that it has the KDC's certificate, but the KDC has more
	than one certificate. The KDC should include information in the		than one certificate. The KDC should include information in the
	KRB-ERROR message that indicates the KDC certificate(s) that a		KRB-ERROR message that indicates the KDC certificate(s) that a
	client may utilize. This data is specified in the e-data, which		client may utilize. This data is specified in the e-data, which
	is defined in RFC 1510 revisions as a SEQUENCE of TypedData:		is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
	TypedData ::= SEQUENCE {		TypedData ::= SEQUENCE {
	data-type [0] INTEGER,		data-type [0] INTEGER,
	data-value [1] OCTET STRING,		data-value [1] OCTET STRING,
	} -- per Kerberos RFC 1510 revisions		} -- per Kerberos RFC 1510 revisions
	where:		where:
	data-type = TD-PKINIT-CMS-CERTIFICATES = 101		data-type = TD-PKINIT-CMS-CERTIFICATES = 101
	data-value = CertificateSet // as specified by CMS [11]		data-value = CertificateSet // as specified by CMS [11]
	The PKAuthenticator carries information to foil replay attacks, and		The PKAuthenticator carries information to foil replay attacks, to
	to bind the request and response. The PKAuthenticator is signed		bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
	with the client's signature key.		request and response. The PKAuthenticator is signed with the client's
			signature key.
	3.2.2. KDC Response		3.2.2. KDC Response
	Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication		Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
	type, the KDC attempts to verify the user's certificate chain		type, the KDC attempts to verify the user's certificate chain
	(userCert), if one is provided in the request. This is done by		(userCert), if one is provided in the request. This is done by
	verifying the certification path against the KDC's policy of		verifying the certification path against the KDC's policy of
	legitimate certifiers. This may be based on a certification		legitimate certifiers. This may be based on a certification
	hierarchy, or it may be simply a list of recognized certifiers in a		hierarchy, or it may be simply a list of recognized certifiers in a
	system like PGP.		system like PGP.
	skipping to change at line 699 ¶		skipping to change at line 716 ¶
	are replaced with parity bits, according to FIPS PUB 74.		are replaced with parity bits, according to FIPS PUB 74.
	4. If the reply key is (3-key) 3-DES, N=192 bits, where some		4. If the reply key is (3-key) 3-DES, N=192 bits, where some
	of the bits are replaced with parity bits, according to		of the bits are replaced with parity bits, according to
	FIPS PUB 74.		FIPS PUB 74.
	5. The encapContentInfo field must contain the KdcDHKeyInfo as		5. The encapContentInfo field must contain the KdcDHKeyInfo as
	defined below.		defined below.
	a. The eContentType field shall contain the OID value for		a. The eContentType field shall contain the OID value for
	pkdata: iso (1) org (3) dod (6) internet (1) security (5)		pkdhkeydata: iso (1) org (3) dod (6) internet (1)
	kerberosv5 (2) pkinit (3) pkdata (1)		security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
	b. The eContent field is data of the type KdcDHKeyInfo		b. The eContent field is data of the type KdcDHKeyInfo
	(below).		(below).
	6. The certificates field must contain the certificates		6. The certificates field must contain the certificates
	necessary for the client to establish trust in the KDC's		necessary for the client to establish trust in the KDC's
	certificate based on the list of trusted certifiers sent by		certificate based on the list of trusted certifiers sent by
	the client in the PA-PK-AS-REQ. This field may be empty if		the client in the PA-PK-AS-REQ. This field may be empty if
	the client did not send to the KDC a list of trusted		the client did not send to the KDC a list of trusted
	certifiers (the trustedCertifiers field was empty, meaning		certifiers (the trustedCertifiers field was empty, meaning
	skipping to change at line 763 ¶		skipping to change at line 780 ¶
	id-signedData: iso (1) member-body (2) us (840)		id-signedData: iso (1) member-body (2) us (840)
	rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)		rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
	b. The encryptedContent field is encrypted data of the CMS		b. The encryptedContent field is encrypted data of the CMS
	type signedData as specified below.		type signedData as specified below.
	i. The encapContentInfo field must contains the		i. The encapContentInfo field must contains the
	ReplyKeyPack.		ReplyKeyPack.
	* The eContentType field shall contain the OID value		* The eContentType field shall contain the OID value
	for pkdata: iso (1) org (3) dod (6) internet (1)		for pkrkeydata: iso (1) org (3) dod (6) internet (1)
	security (5) kerberosv5 (2) pkinit (3) pkdata (1)		security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
	* The eContent field is data of the type ReplyKeyPack		* The eContent field is data of the type ReplyKeyPack
	(below).		(below).
	ii. The certificates field must contain the certificates		ii. The certificates field must contain the certificates
	necessary for the client to establish trust in the		necessary for the client to establish trust in the
	KDC's certificate based on the list of trusted		KDC's certificate based on the list of trusted
	certifiers sent by the client in the PA-PK-AS-REQ.		certifiers sent by the client in the PA-PK-AS-REQ.
	This field may be empty if the client did not send		This field may be empty if the client did not send
	to the KDC a list of trusted certifiers (the		to the KDC a list of trusted certifiers (the
	skipping to change at line 870 ¶		skipping to change at line 887 ¶
	3.2.3. Required Algorithms		3.2.3. Required Algorithms
	Not all of the algorithms in the PKINIT protocol specification have		Not all of the algorithms in the PKINIT protocol specification have
	to be implemented in order to comply with the proposed standard.		to be implemented in order to comply with the proposed standard.
	Below is a list of the required algorithms:		Below is a list of the required algorithms:
	* Diffie-Hellman public/private key pairs		* Diffie-Hellman public/private key pairs
	* utilizing Diffie-Hellman ephemeral-ephemeral mode		* utilizing Diffie-Hellman ephemeral-ephemeral mode
	* SHA1 digest and DSA for signatures		* SHA1 digest and DSA for signatures
			* SHA1 digest also for the Checksum in the PKAuthenticator
	* 3-key triple DES keys derived from the Diffie-Hellman Exchange		* 3-key triple DES keys derived from the Diffie-Hellman Exchange
	* 3-key triple DES Temporary and Reply keys		* 3-key triple DES Temporary and Reply keys
	4. Logistics and Policy		4. Logistics and Policy
	This section describes a way to define the policy on the use of		This section describes a way to define the policy on the use of
	PKINIT for each principal and request.		PKINIT for each principal and request.
	The KDC is not required to contain a database record for users		The KDC is not required to contain a database record for users
	who use public key authentication. However, if these users are		who use public key authentication. However, if these users are
	skipping to change at line 1003 ¶		skipping to change at line 1021 ¶
	Version 2 Certificate Handling, March 1998. Request for		Version 2 Certificate Handling, March 1998. Request for
	Comments 2312.		Comments 2312.
	[18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access		[18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access
	Protocol (v3), December 1997. Request for Comments 2251.		Protocol (v3), December 1997. Request for Comments 2251.
	[19] ITU-T (formerly CCITT) Information Processing Systems - Open		[19] ITU-T (formerly CCITT) Information Processing Systems - Open
	Systems Interconnection - Specification of Abstract Syntax Notation		Systems Interconnection - Specification of Abstract Syntax Notation
	One (ASN.1) Rec. X.680 ISO/IEC 8824-1		One (ASN.1) Rec. X.680 ISO/IEC 8824-1
			[20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
			Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
	8. Acknowledgements		8. Acknowledgements
	Some of the ideas on which this proposal is based arose during		Some of the ideas on which this proposal is based arose during
	discussions over several years between members of the SAAG, the IETF		discussions over several years between members of the SAAG, the IETF
	CAT working group, and the PSRG, regarding integration of Kerberos		CAT working group, and the PSRG, regarding integration of Kerberos
	and SPX. Some ideas have also been drawn from the DASS system.		and SPX. Some ideas have also been drawn from the DASS system.
	These changes are by no means endorsed by these groups. This is an		These changes are by no means endorsed by these groups. This is an
	attempt to revive some of the goals of those groups, and this		attempt to revive some of the goals of those groups, and this
	proposal approaches those goals primarily from the Kerberos		proposal approaches those goals primarily from the Kerberos
	perspective. Lastly, comments from groups working on similar ideas		perspective. Lastly, comments from groups working on similar ideas
	in DCE have been invaluable.		in DCE have been invaluable.
	9. Expiration Date		9. Expiration Date
	This draft expires September 15, 2000.		This draft expires January 15, 2001.
	10. Authors		10. Authors
	Brian Tung		Brian Tung
	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, bcn}@isi.edu		E-mail: {brian, bcn}@isi.edu
	skipping to change at line 1047 ¶		skipping to change at line 1068 ¶
	Keen.com, Inc.		Keen.com, Inc.
	150 Independence Drive		150 Independence Drive
	Menlo Park CA 94025		Menlo Park CA 94025
	Phone: +1 650 289 3134		Phone: +1 650 289 3134
	E-mail: ari@keen.com		E-mail: ari@keen.com
	Sasha Medvinsky		Sasha Medvinsky
	Motorola		Motorola
	6450 Sequence Drive		6450 Sequence Drive
	San Diego, CA 92121		San Diego, CA 92121
	Phone +1 619 404 2825		+1 858 404 2367
	E-mail: smedvinsky@gi.com		E-mail: smedvinsky@gi.com
	John Wray		John Wray
	Iris Associates, Inc.		Iris Associates, Inc.
	5 Technology Park Dr.		5 Technology Park Dr.
	Westford, MA 01886		Westford, MA 01886
	E-mail: John_Wray@iris.com		E-mail: John_Wray@iris.com
	Jonathan Trostle		Jonathan Trostle
	170 W. Tasman Dr.		170 W. Tasman Dr.
End of changes. 16 change blocks.
	22 lines changed or deleted		43 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/