< draft-ietf-cat-kerberos-pk-init-14.txt		draft-ietf-cat-kerberos-pk-init-15.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-14.txt Clifford Neuman		draft-ietf-cat-kerberos-pk-init-15.txt Clifford Neuman
	Updates: RFC 1510bis USC/ISI		Updates: RFC 1510bis USC/ISI
	expires January 15, 2002 Matthew Hur		expires May 25, 2002 Matthew Hur
	Cisco		Cisco
	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 45 ¶
	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-14.txt, and expires January 15,		draft-ietf-cat-kerberos-pk-init-15.txt, and expires May 25, 2002.
	2002. Please send comments to the authors.		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 179 ¶		skipping to change at line 180 ¶
	dsaWithSHA1-CmsOID 9		dsaWithSHA1-CmsOID 9
	md5WithRSAEncryption-CmsOID 10		md5WithRSAEncryption-CmsOID 10
	sha1WithRSAEncryption-CmsOID 11		sha1WithRSAEncryption-CmsOID 11
	rc2CBC-EnvOID 12		rc2CBC-EnvOID 12
	rsaEncryption-EnvOID (PKCS#1 v1.5) 13		rsaEncryption-EnvOID (PKCS#1 v1.5) 13
	rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14		rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14
	des-ede3-cbc-Env-OID 15		des-ede3-cbc-Env-OID 15
	These mappings are provided so that a client may send the		These mappings are provided so that a client may send the
	appropriate enctypes in the AS-REQ message in order to indicate		appropriate enctypes in the AS-REQ message in order to indicate
	support for the corresponding OIDs (for performing PKINIT).		support for the corresponding OIDs (for performing PKINIT). The
			above encryption types are utilized only within CMS structures
			within the PKINIT preauthentication fields. Their use within
			the Kerberos EncryptedData structure is unspecified.
	In many cases, PKINIT requires the encoding of the X.500 name of a		In many cases, PKINIT requires the encoding of the X.500 name of a
	certificate authority as a Realm. When such a name appears as		certificate authority as a Realm. When such a name appears as
	a realm it will be represented using the "Other" form of the realm		a realm it will be represented using the "Other" form of the realm
	name as specified in the naming constraints section of RFC 1510bis.		name as specified in the naming constraints section of RFC 1510bis.
	For a realm derived from an X.500 name, NAMETYPE will have the value		For a realm derived from an X.500 name, NAMETYPE will have the value
	X500-RFC2253. The full realm name will appear as follows:		X500-RFC2253. The full realm name will appear as follows:
	<nametype> + ":" + <string>		<nametype> + ":" + <string>
	where nametype is "X500-RFC2253" and string is the result of doing		where nametype is "X500-RFC2253" and string is the result of doing
	an RFC2253 encoding of the distinguished name, i.e.		an RFC2253 encoding of the distinguished name, i.e.
	"X500-RFC2253:" + RFC2253Encode(DistinguishedName)		"X500-RFC2253:" + RFC2253Encode(DistinguishedName)
	where DistinguishedName is an X.500 name, and RFC2253Encode is a		where DistinguishedName is an X.500 name, and RFC2253Encode is a
	function returing a readable UTF encoding of an X.500 name, as		function returing a readable UTF encoding of an X.500 name, as
	defined by RFC 2253 [11] (part of LDAPv3 [15]).		defined by RFC 2253 [11] (part of LDAPv3 [15]).
	To ensure that this encoding is unique, we add the following rule		Each component of a DistinguishedName is called a
			RelativeDistinguishedName, where a RelativeDistinguishedName is a
			SET OF AttributeTypeAndValue. RFC 2253 does not specify the order
			in which to encode the elements of the RelativeDistinguishedName and
			so to ensure that this encoding is unique, we add the following rule
	to those specified by RFC 2253:		to those specified by RFC 2253:
	The order in which the attributes appear in the RFC 2253		When converting a multi-valued RelativeDistinguishedName
	encoding MUST be the reverse of the order in the ASN.1		to a string, the output consists of the string encodings
	encoding of the X.500 name that appears in the public key		of each AttributeTypeAndValue, in the same order as
	certificate. The order of the relative distinguished names		specified by the DER encoding.
	(RDNs), as well as the order of the AttributeTypeAndValues
	within each RDN, will be reversed. (This is despite the fact
	that an RDN is defined as a SET of AttributeTypeAndValues, where
	an order is normally not important.)
	Similarly, in cases where the KDC does not provide a specific		Similarly, in cases where the KDC does not provide a specific
	policy-based mapping from the X.500 name or X.509 Version 3		policy-based mapping from the X.500 name or X.509 Version 3
	SubjectAltName extension in the user's certificate to a Kerberos		SubjectAltName extension in the user's certificate to a Kerberos
	principal name, PKINIT requires the direct encoding of the X.500		principal name, PKINIT requires the direct encoding of the X.500
	name as a PrincipalName. In this case, the name-type of the		name as a PrincipalName. In this case, the name-type of the
	principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new		principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new
	name type is defined in RFC 1510bis as:		name type is defined in RFC 1510bis as:
	KRB_NT_X500_PRINCIPAL 6		KRB_NT_X500_PRINCIPAL 6
	For this type, the name-string MUST be set as follows:		For this type, the name-string MUST be set as follows:
	RFC2253Encode(DistinguishedName)		RFC2253Encode(DistinguishedName)
	as described above. When this name type is used, the principal's		as described above. When this name type is used, the principal's
	realm MUST be set to the certificate authority's distinguished		realm MUST be set to the certificate authority's distinguished
	name using the X500-RFC2253 realm name format described earlier in		name using the X500-RFC2253 realm name format described earlier in
	this section.		this section.
			Note that the same string may be represented using several different
			ASN.1 data types. As the result, the reverse conversion from an
			RFC2253-encoded principal name back to an X.500 name may not be
			unique and may result in an X.500 name that is not the same as the
			original X.500 name found in the client certificate.
			RFC 1510bis describes an alternate encoding of an X.500 name into a
			realm name. However, as described in RFC 1510bis, the alternate
			encoding does not guarantee a unique mapping from a
			DistinguishedName inside a certificate into a realm name and
			similarly cannot be used to produce a unique principal name. PKINIT
			therefore uses an RFC 2253-based name mapping approach, as specified
			above.
	RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows:		RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows:
	PrincipalName ::= SEQUENCE {		PrincipalName ::= SEQUENCE {
	name-type[0] INTEGER,		name-type[0] INTEGER,
	name-string[1] SEQUENCE OF GeneralString		name-string[1] SEQUENCE OF GeneralString
	}		}
	The following rules relate to the the matching of PrincipalNames		The following rules relate to the the matching of PrincipalNames
	with regard to the PKI name constraints for CAs as laid out in RFC		with regard to the PKI name constraints for CAs as laid out in RFC
	2459 [12]. In order to be regarded as a match (for permitted and		2459 [12]. In order to be regarded as a match (for permitted and
	skipping to change at line 280 ¶		skipping to change at line 298 ¶
	key" may be used to refer to either a public encryption key or a		key" may be used to refer to either a public encryption key or a
	signature verification key, and that the term "private key" may be		signature verification key, and that the term "private key" may be
	used to refer to either a private decryption key or a signature		used to refer to either a private decryption key or a signature
	generation key. The fact that these are logically distinct does		generation key. The fact that these are logically distinct does
	not preclude the assignment of bitwise identical keys for RSA		not preclude the assignment of bitwise identical keys for RSA
	keys.		keys.
	In the case of Diffie-Hellman, the key is produced from the agreed		In the case of Diffie-Hellman, the key is produced from the agreed
	bit string as follows:		bit string as follows:
	* Truncate the bit string to the appropriate length.		* Truncate the bit string to the required length.
	* Rectify parity in each byte (if necessary) to obtain the key.		* Apply the specific cryptosystem's random-to-key function.
	For instance, in the case of a DES key, we take the first eight		Appropriate key constraints for each valid cryptosystem are given
	bytes of the bit stream, and then adjust the least significant bit		in RFC 1510bis.
	of each byte to ensure that each byte has odd parity. Appropriate
	key constraints for each valid cryptosystem are given in RFC
	1510bis.
	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:
	skipping to change at line 355 ¶		skipping to change at line 370 ¶
	they may be maintained by the KDC in which case the KDC is the		they may be maintained by the KDC in which case the KDC is the
	trusted authority. Note that the latter mode does not require the		trusted authority. Note that the latter mode does not require the
	use of certificates.		use of certificates.
	The initial authentication request is sent as per RFC 1510bis, except		The initial authentication request is sent as per RFC 1510bis, except
	that a preauthentication field containing data signed by the user's		that a preauthentication field containing data signed by the user's
	private key accompanies the request:		private key accompanies the request:
	PA-PK-AS-REQ ::= SEQUENCE {		PA-PK-AS-REQ ::= SEQUENCE {
	-- PA TYPE 14		-- PA TYPE 14
	signedAuthPack [0] SignedData		signedAuthPack [0] ContentInfo,
	-- Defined in CMS [8];		-- Defined in CMS [8];
			-- SignedData OID is {pkcs7 2}
	-- AuthPack (below) defines the		-- AuthPack (below) defines the
	-- data that is signed.		-- data that is signed.
	trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,		trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
	-- This is a list of CAs that the		-- This is a list of CAs that the
	-- client trusts and that certify		-- client trusts and that certify
	-- KDCs.		-- KDCs.
	kdcCert [2] IssuerAndSerialNumber OPTIONAL		kdcCert [2] IssuerAndSerialNumber OPTIONAL
	-- As defined in CMS [8];		-- As defined in CMS [8];
	-- specifies a particular KDC		-- specifies a particular KDC
	-- certificate if the client		-- certificate if the client
	skipping to change at line 388 ¶		skipping to change at line 404 ¶
	-- as defined below		-- as defined below
	caName [1] Name		caName [1] Name
	-- fully qualified X.500 name		-- fully qualified X.500 name
	-- as defined by X.509		-- as defined by X.509
	issuerAndSerial [2] IssuerAndSerialNumber		issuerAndSerial [2] IssuerAndSerialNumber
	-- Since a CA may have a number of		-- Since a CA may have a number of
	-- certificates, only one of which		-- certificates, only one of which
	-- a client trusts		-- a client trusts
	}		}
	Usage of SignedData:		The type of the ContentInfo in the signedAuthPack is SignedData.
			Its usage is as follows:
	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 MUST contain the OID value for		a. The eContentType field MUST contain the OID value for
	skipping to change at line 462 ¶		skipping to change at line 479 ¶
	cusec [0] INTEGER,		cusec [0] INTEGER,
	-- for replay prevention as in RFC 1510bis		-- for replay prevention as in RFC 1510bis
	ctime [1] KerberosTime,		ctime [1] KerberosTime,
	-- for replay prevention as in RFC 1510bis		-- for replay prevention as in RFC 1510bis
	nonce [2] INTEGER,		nonce [2] INTEGER,
	-- zero only if client will accept		-- zero only if client will accept
	-- 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
	}		}
	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 [7]		} -- as specified by the X.509 recommendation [7]
	skipping to change at line 660 ¶		skipping to change at line 678 ¶
	KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the		KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
	client.		client.
	The KDC encrypts the reply not with the user's long-term key, but		The KDC encrypts the reply not with the user's long-term key, but
	with the Diffie Hellman derived key or a random key generated		with the Diffie Hellman derived key or a random key generated
	for this particular response which is carried in the padata field of		for this particular response which is carried in the padata field of
	the TGS-REP message.		the TGS-REP message.
	PA-PK-AS-REP ::= CHOICE {		PA-PK-AS-REP ::= CHOICE {
	-- PA TYPE 15		-- PA TYPE 15
	dhSignedData [0] SignedData,		dhSignedData [0] ContentInfo,
	-- Defined in CMS and used only with		-- Defined in CMS [8] and used only with
	-- Diffie-Hellman key exchange (if the		-- Diffie-Hellman key exchange (if the
	-- client public value was present in the		-- client public value was present in the
	-- request).		-- request).
			-- SignedData OID is {pkcs7 2}
	-- This choice MUST be supported		-- This choice MUST be supported
	-- by compliant implementations.		-- by compliant implementations.
	encKeyPack [1] EnvelopedData,		encKeyPack [1] ContentInfo
	-- Defined in CMS		-- Defined in CMS [8].
	-- The temporary key is encrypted		-- The temporary key is encrypted
	-- using the client public key		-- using the client public key
	-- key		-- key.
			-- EnvelopedData OID is {pkcs7 3}
	-- SignedReplyKeyPack, encrypted		-- SignedReplyKeyPack, encrypted
	-- with the temporary key, is also		-- with the temporary key, is also
	-- included.		-- included.
	}		}
	Usage of SignedData:		The type of the ContentInfo in the dhSignedData is SignedData.
			Its usage is as follows:
	When the Diffie-Hellman option is used, dhSignedData in		When the Diffie-Hellman option is used, dhSignedData in
	PA-PK-AS-REP provides authenticated Diffie-Hellman parameters		PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
	of the KDC. The reply key used to encrypt part of the KDC reply		of the KDC. The reply key used to encrypt part of the KDC reply
	message is derived from the Diffie-Hellman exchange:		message is derived from the Diffie-Hellman exchange:
	1. Both the KDC and the client calculate a secret value		1. Both the KDC and the client calculate a secret value
	(g^ab mod p), where a is the client's private exponent and		(g^ab mod p), where a is the client's private exponent and
	b is the KDC's private exponent.		b is the KDC's private exponent.
	skipping to change at line 750 ¶		skipping to change at line 771 ¶
	-- BIT STRING		-- BIT STRING
	nonce [1] INTEGER,		nonce [1] INTEGER,
	-- Binds response to the request		-- Binds response to the request
	-- Exception: Set to zero when KDC		-- Exception: Set to zero when KDC
	-- is using a cached DH value		-- is using a cached DH value
	dhKeyExpiration [2] KerberosTime OPTIONAL		dhKeyExpiration [2] KerberosTime OPTIONAL
	-- Expiration time for KDC's cached		-- Expiration time for KDC's cached
	-- DH value		-- DH value
	}		}
	Usage of EnvelopedData:		The type of the ContentInfo in the encKeyPack is EnvelopedData. Its
			usage is as follows:
	The EnvelopedData data type is specified in the Cryptographic		The EnvelopedData 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. It contains a temporary key encrypted with the PKINIT		IETF. It contains a temporary key encrypted with the PKINIT
	client's public key. It also contains a signed and encrypted		client's public key. It also contains a signed and encrypted
	reply key.		reply key.
	1. The originatorInfo field is not required, since that		1. The originatorInfo field is not required, since that
	information may be presented in the signedData structure		information may be presented in the signedData structure
	that is encrypted within the encryptedContentInfo field.		that is encrypted within the encryptedContentInfo field.
	skipping to change at line 855 ¶		skipping to change at line 877 ¶
	otherName [0] OtherName,		otherName [0] OtherName,
	...		...
	}		}
	OtherName ::= SEQUENCE {		OtherName ::= SEQUENCE {
	type-id OBJECT IDENTIFIER,		type-id OBJECT IDENTIFIER,
	value [0] EXPLICIT ANY DEFINED BY type-id		value [0] EXPLICIT ANY DEFINED BY type-id
	}		}
	For the purpose of specifying a Kerberos principal name, the value		For the purpose of specifying a Kerberos principal name, the value
	in OtherName MUST be a KerberosName as defined in RFC 1510bis:		in OtherName MUST be a KerberosName, defined as follows:
	KerberosName ::= SEQUENCE {		KerberosName ::= SEQUENCE {
	realm [0] Realm,		realm [0] Realm,
	principalName [1] PrincipalName		principalName [1] PrincipalName
	}		}
	This specific syntax is identified within subjectAltName by setting		This specific syntax is identified within subjectAltName by setting
	the type-id in OtherName to krb5PrincipalName, where (from the		the type-id in OtherName to krb5PrincipalName, where (from the
	Kerberos specification) we have		Kerberos specification) we have
	skipping to change at line 904 ¶		skipping to change at line 926 ¶
	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 DSA for signatures
	* SHA1 digest also for the Checksum in the PKAuthenticator		* SHA1 digest for the Checksum in the PKAuthenticator
			* 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.
	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 928 ¶		skipping to change at line 951 ¶
	If this flag is set and a request message does not contain the		If this flag is set and a request message does not contain the
	PKINIT preauthentication field, then the KDC sends back as error of		PKINIT preauthentication field, then the KDC sends back as error of
	type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication		type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
	field of type PA-PK-AS-REQ must be included in the request.		field of type PA-PK-AS-REQ must be included in the request.
	5. Security Considerations		5. Security Considerations
	PKINIT raises a few security considerations, which we will address		PKINIT raises a few security considerations, which we will address
	in this section.		in this section.
	First of all, PKINIT introduces a new trust model, where KDCs do not		First of all, PKINIT extends the cross-realm model to the public
	(necessarily) certify the identity of those for whom they issue		key infrastructure. Anyone using PKINIT must be aware of how the
	tickets. PKINIT does allow KDCs to act as their own CAs, in the		certification infrastructure they are linking to works.
	limited capacity of self-signing their certificates, but one of the
	additional benefits is to align Kerberos authentication with a global
	public key infrastructure. Anyone using PKINIT in this way must be
	aware of how the certification infrastructure they are linking to
	works.
	Also, PKINIT introduces the possibility of interactions between		Also, as in standard Kerberos, PKINIT presents the possibility of
	different cryptosystems, which may be of widely varying strengths.		interactions between different cryptosystems of varying strengths,
	Many systems, for instance, allow the use of 512-bit public keys.		and this now includes public-key cryptosystems. Many systems, for
	Using such keys to wrap data encrypted under strong conventional		instance, allow the use of 512-bit public keys. Using such keys
	cryptosystems, such as triple-DES, is inappropriate; it adds a		to wrap data encrypted under strong conventional cryptosystems,
	weak link to a strong one at extra cost. Implementors and		such as triple-DES, may be inappropriate.
	administrators should take care to avoid such wasteful and
	deceptive interactions.
	Care should be taken in how certificates are choosen for the purposes		Care should be taken in how certificates are choosen for the purposes
	of authentication using PKINIT. Some local policies require that key		of authentication using PKINIT. Some local policies require that key
	escrow be applied for certain certificate types. People deploying		escrow be applied for certain certificate types. People deploying
	PKINIT should be aware of the implications of using certificates that		PKINIT should be aware of the implications of using certificates that
	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.
	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. PKINIT implementations MUST avoid use of these keys, either		keys. For recommendations regarding these weak keys, see RFC
	by discarding those keys when they are generated, or by fixing them		1510bis.
	in some way (e.g., by XORing them with a given mask). These
	precautions vary from system to system; it is not our intention to
	give an explicit recipe for them here.
	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
	light of the possibility that the Kerberos specification will		light of the possibility that the Kerberos specification will
	require KDCs to accept requests using TCP as a transport mechanism,		require KDCs to accept requests using TCP as a transport mechanism,
	we make the same recommendation with respect to the PKINIT		we make the same recommendation with respect to the PKINIT
	extensions as well.		extensions as well.
	skipping to change at line 1058 ¶		skipping to change at line 1071 ¶
	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 January 15, 2002.		This draft expires May 25, 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		Cisco Systems
	500 108th Ave. NE, Suite 500		2901 Third Avenue
	Bellevue, WA 98004		Seattle WA 98121
	Phone: (408) 525-0034		Phone: (206) 256-3197
	E-Mail: mhur@cisco.com		E-Mail: mhur@cisco.com
	Ari Medvinsky		Ari Medvinsky
	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
End of changes. 27 change blocks.
	58 lines changed or deleted		71 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/