< draft-ietf-cat-kerberos-pk-init-15.txt		draft-ietf-cat-kerberos-pk-init-16.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-15.txt Clifford Neuman		draft-ietf-cat-kerberos-pk-init-16.txt Clifford Neuman
	Updates: RFC 1510bis USC/ISI		Updates: RFC 1510bis USC/ISI
	expires May 25, 2002 Matthew Hur		expires March 12, 2002 Matthew Hur
	Cisco		Microsoft Corporation
	Ari Medvinsky		Ari Medvinsky
	Keen.com, Inc.		Liberate Technologies
	Sasha Medvinsky		Sasha Medvinsky
	Motorola		Motorola, Inc.
	John Wray		John Wray
	Iris Associates, Inc.		Iris Associates, Inc.
	Jonathan Trostle		Jonathan Trostle
	Cisco
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial 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
	all provisions of Section 10 of RFC 2026. Internet-Drafts are		all provisions of Section 10 of RFC 2026. Internet-Drafts are
	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 also		its areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	skipping to change at line 45 ¶		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-15.txt, and expires May 25, 2002.		draft-ietf-cat-kerberos-pk-init-16.txt, and expires March 12,
	Please send comments to the authors.		2002. 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 1510bis [1]) to provide a method for using public		specification (RFC 1510bis [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 73 ¶		skipping to change at line 72 ¶
	public key certification infrastructures.		public key certification infrastructures.
	Public key cryptography can be integrated into Kerberos in a number		Public key cryptography can be integrated into Kerberos in a number
	of ways. One is to associate a key pair with each realm, which can		of ways. One is to associate a key pair with each realm, which can
	then be used to facilitate cross-realm authentication; this is the		then be used to facilitate cross-realm authentication; this is the
	topic of another draft proposal. Another way is to allow users with		topic of another draft proposal. Another way is to allow users with
	public key certificates to use them in initial authentication. This		public key certificates to use them in initial authentication. This
	is the concern of the current document.		is the concern of the current document.
	PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in		PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
	combination with DSA keys as the primary, required mechanism. Note		combination with RSA keys as the primary, required mechanism. Note
	that PKINIT supports the use of separate signature and encryption		that PKINIT supports the use of separate signature and encryption
	keys.		keys.
	PKINIT enables access to Kerberos-secured services based on initial		PKINIT enables access to Kerberos-secured services based on initial
	authentication utilizing public key cryptography. PKINIT utilizes		authentication utilizing public key cryptography. PKINIT utilizes
	standard public key signature and encryption data formats within the		standard public key signature and encryption data formats within the
	standard Kerberos messages. The basic mechanism is as follows: The		standard Kerberos messages. The basic mechanism is as follows: The
	user sends an AS-REQ message to the KDC as before, except that if that		user sends an AS-REQ message to the KDC as before, except that if that
	user is to use public key cryptography in the initial authentication		user is to use public key cryptography in the initial authentication
	step, his certificate and a signature accompany the initial request		step, his certificate and a signature accompany the initial request
	skipping to change at line 162 ¶		skipping to change at line 161 ¶
	KDC_ERR_INVALID_CERTIFICATE 71		KDC_ERR_INVALID_CERTIFICATE 71
	KDC_ERR_REVOKED_CERTIFICATE 72		KDC_ERR_REVOKED_CERTIFICATE 72
	KDC_ERR_REVOCATION_STATUS_UNKNOWN 73		KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
	KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74		KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74
	KDC_ERR_CLIENT_NAME_MISMATCH 75		KDC_ERR_CLIENT_NAME_MISMATCH 75
	KDC_ERR_KDC_NAME_MISMATCH 76		KDC_ERR_KDC_NAME_MISMATCH 76
	We utilize the following typed data for errors:		We utilize the following typed data for errors:
	TD-PKINIT-CMS-CERTIFICATES 101		TD-PKINIT-CMS-CERTIFICATES 101
	TD-KRB-PRINCIPAL 102		TD-DH-PARAMETERS 102
	TD-KRB-REALM 103
	TD-TRUSTED-CERTIFIERS 104		TD-TRUSTED-CERTIFIERS 104
	TD-CERTIFICATE-INDEX 105		TD-CERTIFICATE-INDEX 105
	We utilize the following encryption types (which map directly to		We utilize the following encryption types (which map directly to
	OIDs):		OIDs):
	dsaWithSHA1-CmsOID 9		dsaWithSHA1-CmsOID 9
	md5WithRSAEncryption-CmsOID 10		md5WithRSAEncryption-CmsOID 10
	sha1WithRSAEncryption-CmsOID 11		sha1WithRSAEncryption-CmsOID 11
	rc2CBC-EnvOID 12		rc2CBC-EnvOID 12
	skipping to change at line 314 ¶		skipping to change at line 312 ¶
	3.1.2. Algorithm Identifiers		3.1.2. Algorithm Identifiers
	PKINIT does not define, but does permit, the algorithm identifiers		PKINIT does not define, but does permit, the algorithm identifiers
	listed below.		listed below.
	3.1.2.1. Signature Algorithm Identifiers		3.1.2.1. Signature Algorithm Identifiers
	The following signature algorithm identifiers specified in [8] and		The following signature algorithm identifiers specified in [8] and
	in [12] are used with PKINIT:		in [12] are used with PKINIT:
	id-dsa-with-sha1 (DSA with SHA1)
	md5WithRSAEncryption (RSA with MD5)
	sha-1WithRSAEncryption (RSA with SHA1)		sha-1WithRSAEncryption (RSA with SHA1)
			md5WithRSAEncryption (RSA with MD5)
			id-dsa-with-sha1 (DSA with SHA1)
	3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier		3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
	The following algorithm identifier shall be used within the		The following algorithm identifier shall be used within the
	SubjectPublicKeyInfo data structure: dhpublicnumber		SubjectPublicKeyInfo data structure: dhpublicnumber
	This identifier and the associated algorithm parameters are		This identifier and the associated algorithm parameters are
	specified in RFC 2459 [12].		specified in RFC 2459 [12].
	3.1.2.3. Algorithm Identifiers for RSA Encryption		3.1.2.3. Algorithm Identifiers for RSA Encryption
	skipping to change at line 441 ¶		skipping to change at line 439 ¶
	Diffie-Hellman certificate in this field in order to convey		Diffie-Hellman certificate in this field in order to convey
	its static Diffie Hellman certificate to the KDC to enable		its static Diffie Hellman certificate to the KDC to enable
	static-ephemeral Diffie-Hellman mode for the reply; in this		static-ephemeral Diffie-Hellman mode for the reply; in this
	case, the client does NOT place its public value in the		case, the client does NOT place its public value in the
	AuthPack (defined below). As another example, the client may		AuthPack (defined below). As another example, the client may
	place an RSA encryption certificate in this field. However,		place an RSA encryption certificate in this field. However,
	there MUST always be (at least) a signature certificate.		there MUST always be (at least) a signature certificate.
	4. When a DH key is being used, the public exponent is provided		4. When a DH key is being used, the public exponent is provided
	in the subjectPublicKey field of the SubjectPublicKeyInfo and		in the subjectPublicKey field of the SubjectPublicKeyInfo and
	the DH parameters are supplied as a DHParameter in the		the DH parameters are supplied as a DomainParameters in the
	AlgorithmIdentitfier parameters. The DH paramters SHOULD be		AlgorithmIdentitfier parameters. The DH paramters SHOULD be
	chosen from the First and Second defined Oakley Groups [The		chosen from the First and Second defined Oakley Groups [The
	Internet Key Exchange (IKE) RFC-2409], if a server will not		Internet Key Exchange (IKE) RFC-2409], if a server will not
	accept either of these groups, it will respond with a krb-error		accept either of these groups, it will respond with a krb-
	of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a		error of KDC_ERR_KEY_TOO_WEAK. The accompanying e-data is
	DHParameter with appropriate parameters for the client to use.		a SEQUENCE of TypedData that includes type
			TD-DH-PARAMETERS (102) whose data-value is DomainParameters
			with appropriate Diffie-Hellman parameters for the client to
			use.
	5. The KDC may wish to use cached Diffie-Hellman parameters		5. The KDC may wish to use cached Diffie-Hellman parameters
	(see Section 3.2.2, KDC Response). To indicate acceptance		(see Section 3.2.2, KDC Response). To indicate acceptance
	of cached parameters, the client sends zero in the nonce		of cached parameters, the client sends zero in the nonce
	field of the PKAuthenticator. Zero is not a valid value		field of the PKAuthenticator. Zero is not a valid value
	for this field under any other circumstances. If cached		for this field under any other circumstances. If cached
	parameters are used, the client and the KDC MUST perform		parameters are used, the client and the KDC MUST perform
	key derivation (for the appropriate cryptosystem) on the		key derivation (for the appropriate cryptosystem) on the
	resulting encryption key, as specified in RFC 1510bis. (With		resulting encryption key, as specified in RFC 1510bis. (With
	a zero nonce, message binding is performed using the nonce		a zero nonce, message binding is performed using the nonce
	skipping to change at line 485 ¶		skipping to change at line 486 ¶
	-- cached DH parameters from KDC;		-- cached DH parameters from KDC;
	-- must be non-zero otherwise		-- must be non-zero otherwise
	pachecksum [3] Checksum		pachecksum [3] Checksum
	-- Checksum over KDC-REQ-BODY		-- Checksum over KDC-REQ-BODY
	-- Defined by Kerberos spec;		-- Defined by Kerberos spec;
	-- must be unkeyed, e.g. sha1 or rsa-md5		-- must be unkeyed, e.g. sha1 or rsa-md5
	}		}
	SubjectPublicKeyInfo ::= SEQUENCE {		SubjectPublicKeyInfo ::= SEQUENCE {
	algorithm AlgorithmIdentifier,		algorithm AlgorithmIdentifier,
	-- dhKeyAgreement		-- dhPublicNumber
	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 [7]		} -- as specified by the X.509 recommendation [7]
	AlgorithmIdentifier ::= SEQUENCE {		AlgorithmIdentifier ::= SEQUENCE {
	algorithm OBJECT IDENTIFIER,		algorithm OBJECT IDENTIFIER,
	-- for dhKeyAgreement, this is		-- for dhPublicNumber, this is
	-- { iso (1) member-body (2) US (840)		-- { iso (1) member-body (2) US (840)
	-- rsadsi (113459) pkcs (1) 3 1 }		-- ansi-x942(10046) number-type(2) 1 }
	-- from PKCS #3 [17]		-- from RFC 2459 [12]
	parameters ANY DEFINED by algorithm OPTIONAL		parameters ANY DEFINED by algorithm OPTIONAL
	-- for dhKeyAgreement, this is		-- for dhPublicNumber, this is
	-- DHParameter		-- DomainParameters
	} -- as specified by the X.509 recommendation [7]		} -- as specified by the X.509 recommendation [7]
	DHParameter ::= SEQUENCE {		DomainParameters ::= SEQUENCE {
	prime INTEGER,		p INTEGER, -- odd prime, p=jq +1
	-- p		g INTEGER, -- generator, g
	base INTEGER,		q INTEGER, -- factor of p-1
	-- g		j INTEGER OPTIONAL, -- subgroup factor
	privateValueLength INTEGER OPTIONAL		validationParms ValidationParms OPTIONAL
	-- l		} -- as defined in RFC 2459 [12]
	} -- as defined in PKCS #3 [17]
			ValidationParms ::= SEQUENCE {
			seed BIT STRING,
			-- seed for the system parameter
			-- generation process
			pgenCounter INTEGER
			-- integer value output as part
			-- of the of the system parameter
			-- prime generation process
			} -- as defined in RFC 2459 [12]
	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 1510bis revisions as a SEQUENCE of TypedData:		is defined in RFC 1510bis 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 1510bis		} -- per Kerberos RFC 1510bis
	where:		where one of the TypedData elements is:
	data-type = TD-PKINIT-CMS-CERTIFICATES = 101		data-type = TD-PKINIT-CMS-CERTIFICATES = 101
	data-value = CertificateSet // as specified by CMS [8]		data-value = CertificateSet // as specified by CMS [8]
	The PKAuthenticator carries information to foil replay attacks, to		The PKAuthenticator carries information to foil replay attacks, to
	bind the pre-authentication data to the KDC-REQ-BODY, and to bind the		bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
	request and response. The PKAuthenticator is signed with the client's		request and response. The PKAuthenticator is signed with the client's
	signature key.		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 client's certificate chain, if
	(userCert), if one is provided in the request. This is done by		one is provided in the request. This is done by verifying the
	verifying the certification path against the KDC's policy of		certification path against the KDC's policy of legitimate
	legitimate certifiers.		certifiers.
	If the client's certificate chain contains no certificate signed by		If the KDC cannot find a trusted client certificate chain within
	a CA trusted by the KDC, then the KDC sends back an error message		the PA-PK-AS-REQ, then the KDC sends back an error message of type
	of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data		KDC_ERR_CANT_VERIFY_CERTIFICATE. Certificate chain validation is
	is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)		defined in RFC 2459 [12]. The accompanying e-data for this error
	whose data-value is an OCTET STRING which is the DER encoding of		code is a SEQUENCE of TypedData that includes type
			TD-TRUSTED-CERTIFIERS (104) whose data-value is an OCTET STRING
			which is the DER encoding of
	TrustedCertifiers ::= SEQUENCE OF PrincipalName		TrustedCertifiers ::= SEQUENCE OF PrincipalName
	-- X.500 name encoded as a principal name		-- X.500 name encoded as a principal name
	-- see Section 3.1		-- see Section 3.1
	If while verifying a certificate chain the KDC determines that the		If while verifying a certificate chain the KDC determines that the
	signature on one of the certificates in the CertificateSet from		signature on one of the certificates in the CertificateSet from
	the signedAuthPack fails verification, then the KDC returns an		the signedAuthPack fails verification, then the KDC returns an
	error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying		error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying
	e-data is a SEQUENCE of one TypedData (with type		e-data is a SEQUENCE of TypedData that includes type
	TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING		TD-CERTIFICATE-INDEX (105) whose data-value is an OCTET STRING
	which is the DER encoding of the index into the CertificateSet		which is the DER encoding of the index into the CertificateSet
	ordered as sent by the client.		ordered as sent by the client.
	CertificateIndex ::= INTEGER		CertificateIndex ::= INTEGER
	-- 0 = 1st certificate,		-- 0 = 1st certificate,
	-- (in order of encoding)		-- (in order of encoding)
	-- 1 = 2nd certificate, etc		-- 1 = 2nd certificate, etc
	The KDC may also check whether any of the certificates in the		The KDC may also check whether any of the certificates in the
	client's chain has been revoked. If one of the certificates has		client's chain has been revoked. If one of the certificates has
	skipping to change at line 609 ¶		skipping to change at line 621 ¶
	message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the		message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
	timestamp (ctime and cusec) in the PKAuthenticator to assure that		timestamp (ctime and cusec) in the PKAuthenticator to assure that
	the request is not a replay. The KDC also verifies that its name		the request is not a replay. The KDC also verifies that its name
	is specified in the PKAuthenticator.		is specified in the PKAuthenticator.
	If the clientPublicValue field is filled in, indicating that the		If the clientPublicValue field is filled in, indicating that the
	client wishes to use Diffie-Hellman key agreement, then the KDC		client wishes to use Diffie-Hellman key agreement, then the KDC
	checks to see that the parameters satisfy its policy. If they do		checks to see that the parameters satisfy its policy. If they do
	not (e.g., the prime size is insufficient for the expected		not (e.g., the prime size is insufficient for the expected
	encryption type), then the KDC sends back an error message of type		encryption type), then the KDC sends back an error message of type
	KDC_ERR_KEY_TOO_WEAK, with an e-data containing a structure of		KDC_ERR_KEY_TOO_WEAK. The accompanying e-data is a SEQUENCE of
	type DHParameter with appropriate DH parameters for the client to		TypedData that includes type TD-DH-PARAMETERS (102) whose data-value
	retry the request. Otherwise, it generates its own public and		is DomainParameters with appropriate Diffie-Hellman parameters for
	private values for the response.		the client to retry the request. Otherwise, it generates its own
			public and private values for the response.
	The KDC also checks that the timestamp in the PKAuthenticator is		The KDC also checks that the timestamp in the PKAuthenticator is
	within the allowable window and that the principal name and realm		within the allowable window and that the principal name and realm
	are correct. If the local (server) time and the client time in the		are correct. If the local (server) time and the client time in the
	authenticator differ by more than the allowable clock skew, then the		authenticator differ by more than the allowable clock skew, then the
	KDC returns an error message of type KRB_AP_ERR_SKEW as defined in		KDC returns an error message of type KRB_AP_ERR_SKEW as defined in
	RFC 1510bis.		RFC 1510bis.
	Assuming no errors, the KDC replies as per RFC 1510bis, except as		Assuming no errors, the KDC replies as per RFC 1510bis, except as
	follows. The user's name in the ticket is determined by the		follows. The user's name in the ticket is determined by the
	skipping to change at line 925 ¶		skipping to change at line 938 ¶
	described in RFC 1510bis.		described in RFC 1510bis.
	3.2.4. Required Algorithms		3.2.4. 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 RSA for signatures
	* SHA1 digest for the Checksum in the PKAuthenticator		* SHA1 digest for the Checksum in the PKAuthenticator
	* using Kerberos checksum type 'sha1'		* using Kerberos checksum type 'sha1'
	* 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.
	skipping to change at line 976 ¶		skipping to change at line 989 ¶
	have escrowed keys for the purposes of authentication.		have escrowed keys for the purposes of authentication.
	As described in Section 3.2, PKINIT allows for the caching of the		As described in Section 3.2, PKINIT allows for the caching of the
	Diffie-Hellman parameters on the KDC side, for performance reasons.		Diffie-Hellman parameters on the KDC side, for performance reasons.
	For similar reasons, the signed data in this case does not vary from		For similar reasons, the signed data in this case does not vary from
	message to message, until the cached parameters expire. Because of		message to message, until the cached parameters expire. Because of
	the persistence of these parameters, the client and the KDC are to		the persistence of these parameters, the client and the KDC are to
	use the appropriate key derivation measures (as described in RFC		use the appropriate key derivation measures (as described in RFC
	1510bis) when using cached DH parameters.		1510bis) when using cached DH parameters.
			PKINIT does not provide for a "return routability test" to prevent
			attackers from mounting a denial of service attack on the KDC by
			causing it to perform needless expensive cryptographic operations.
			Strictly speaking, this is also true of base Kerberos, although the
			potential cost is not as great in base Kerberos, because it does
			not make use of public key cryptography.
	Lastly, PKINIT calls for randomly generated keys for conventional		Lastly, PKINIT calls for randomly generated keys for conventional
	cryptosystems. Many such systems contain systematically "weak"		cryptosystems. Many such systems contain systematically "weak"
	keys. For recommendations regarding these weak keys, see RFC		keys. For recommendations regarding these weak keys, see RFC
	1510bis.		1510bis.
	6. Transport Issues		6. Transport Issues
	Certificate chains can potentially grow quite large and span several		Certificate chains can potentially grow quite large and span several
	UDP packets; this in turn increases the probability that a Kerberos		UDP packets; this in turn increases the probability that a Kerberos
	message involving PKINIT extensions will be broken in transit. In		message involving PKINIT extensions will be broken in transit. In
	skipping to change at line 1071 ¶		skipping to change at line 1091 ¶
	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 May 25, 2002.		This draft expires March 12, 2002.
	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
	Matthew Hur		Matthew Hur
	Cisco Systems		Microsoft Corporation
	2901 Third Avenue		One Microsoft Way
	Seattle WA 98121		Redmond WA 98052
	Phone: (206) 256-3197		Phone: +1 425 707 3336
	E-Mail: mhur@cisco.com		E-mail: matthur@microsoft.com
	Ari Medvinsky		Ari Medvinsky
	Keen.com, Inc.		Liberate Technologies
	150 Independence Drive		2 Circle Star Way
	Menlo Park CA 94025		San Carlos CA 94070
	Phone: +1 650 289 3134		E-mail: ari@liberate.com
	E-mail: ari@keen.com
	Sasha Medvinsky		Sasha Medvinsky
	Motorola		Motorola, Inc.
	6450 Sequence Drive		6450 Sequence Drive
	San Diego, CA 92121		San Diego, CA 92121
	+1 858 404 2367		+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
	Cisco Systems		E-mail: jtrostle@world.std.com
	170 W. Tasman Dr.
	San Jose, CA 95134
	E-mail: jtrostle@cisco.com
End of changes. 29 change blocks.
	60 lines changed or deleted		79 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/