Diff: draft-ietf-cat-kerberos-pk-init-17.txt - draft-ietf-cat-kerberos-pk-init-18.txt

	< draft-ietf-cat-kerberos-pk-init-17.txt	draft-ietf-cat-kerberos-pk-init-18.txt >


	INTERNET-DRAFT Brian Tung	INTERNET-DRAFT Brian Tung

	draft-ietf-cat-kerberos-pk-init-17.txt Clifford Neuman	draft-ietf-cat-kerberos-pk-init-18.txt Clifford Neuman
	Updates: RFC 1510bis USC/ISI	Updates: RFC 1510bis USC/ISI

	expires May 31, 2004 Matthew Hur	expires August 20, 2004 Matthew Hur
	Ari Medvinsky	Ari Medvinsky
	Microsoft Corporation	Microsoft Corporation
	Sasha Medvinsky	Sasha Medvinsky
	Motorola, Inc.	Motorola, Inc.
	John Wray	John Wray
	Iris Associates, Inc.	Iris Associates, Inc.
	Jonathan Trostle	Jonathan Trostle

	Public Key Cryptography for Initial Authentication in Kerberos	Public Key Cryptography for Initial Authentication in Kerberos


	skipping to change at line 36 ¶	skipping to change at line 35 ¶
	at any time. It is inappropriate to use Internet-Drafts as	at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."	reference 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

	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-17.txt and expires May 31, 2004.	draft-ietf-cat-kerberos-pk-init-18.txt and expires August 20, 2004.
	Please send comments to the authors.	Please send comments to the authors.

	1. Abstract	1. Abstract

	This draft describes protocol extensions (hereafter called PKINIT)	This draft describes protocol extensions (hereafter called PKINIT)
	to the Kerberos protocol specification (RFC 1510bis [1]). These	to the Kerberos protocol specification (RFC 1510bis [1]). These
	extensions provide a method for integrating public key cryptography	extensions provide a method for integrating public key cryptography
	into the initial authentication exchange, by passing cryptographic	into the initial authentication exchange, by passing cryptographic
	certificates and associated authenticators in preauthentication data	certificates and associated authenticators in preauthentication data
	fields.	fields.

	skipping to change at line 72 ¶	skipping to change at line 71 ¶
	TGT and its associated session key can then be used for any	TGT and its associated session key can then be used for any
	subsequent requests. One implication of this is that all further	subsequent requests. One implication of this is that all further
	authentication is independent of the method by which the initial	authentication is independent of the method by which the initial
	authentication was performed. Consequently, initial authentication	authentication was performed. Consequently, initial authentication
	provides a convenient place to integrate public-key cryptography	provides a convenient place to integrate public-key cryptography
	into Kerberos authentication.	into Kerberos authentication.

	As defined, Kerberos authentication exchanges use symmetric-key	As defined, Kerberos authentication exchanges use symmetric-key
	cryptography, in part for performance. (Symmetric-key cryptography	cryptography, in part for performance. (Symmetric-key cryptography
	is typically 10-100 times faster than public-key cryptography,	is typically 10-100 times faster than public-key cryptography,

	depending on the public-key operations. [c]) One cost of using	depending on the public-key operations. [cite]) One cost of using
	symmetric-key cryptography is that the keys must be shared, so that	symmetric-key cryptography is that the keys must be shared, so that
	before a user can authentication himself, he must already be	before a user can authentication himself, he must already be
	registered with the KDC.	registered with the KDC.

	Conversely, public-key cryptography--in conjunction with an	Conversely, public-key cryptography--in conjunction with an
	established certification infrastructure--permits authentication	established certification infrastructure--permits authentication
	without prior registration. Adding it to Kerberos allows the	without prior registration. Adding it to Kerberos allows the
	widespread use of Kerberized applications by users without requiring	widespread use of Kerberized applications by users without requiring
	them to register first--a requirement that has no inherent security	them to register first--a requirement that has no inherent security
	benefit.	benefit.

	skipping to change at line 134 ¶	skipping to change at line 133 ¶

	Section 3.1 of this document defines the necessary message formats.	Section 3.1 of this document defines the necessary message formats.
	Section 3.2 describes their syntax and use in greater detail.	Section 3.2 describes their syntax and use in greater detail.
	Implementation of all specified formats and uses in these sections	Implementation of all specified formats and uses in these sections
	is REQUIRED for compliance with PKINIT.	is REQUIRED for compliance with PKINIT.

	3.1. Definitions	3.1. Definitions

	3.1.1. Required Algorithms	3.1.1. Required Algorithms


	[What is the current list of required algorithm? --brian]	At minimum, PKINIT must be able to use the following algorithms:

		Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype
		(as required by clarifications).
		Signature algorithm: SHA-1 digest and RSA.
		Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
		with a non-zero nonce.
		Unkeyed checksum type for the paChecksum member of
		PKAuthenticator: SHA1 (unkeyed).

	3.1.2. Defined Message and Encryption Types	3.1.2. Defined Message and Encryption Types

	PKINIT makes use of the following new preauthentication types:	PKINIT makes use of the following new preauthentication types:

	PA-PK-AS-REQ TBD	PA-PK-AS-REQ TBD
	PA-PK-AS-REP TBD	PA-PK-AS-REP TBD

		PA-PK-OCSP-REQ TBD
		PA-PK-OCSP-REP TBD

		PKINIT also makes use of the following new authorization data type:

		AD-INITIAL-VERIFIED-CAS TBD

	PKINIT introduces the following new error types:	PKINIT introduces the following new error types:

	KDC_ERR_CLIENT_NOT_TRUSTED 62	KDC_ERR_CLIENT_NOT_TRUSTED 62
	KDC_ERR_KDC_NOT_TRUSTED 63	KDC_ERR_KDC_NOT_TRUSTED 63
	KDC_ERR_INVALID_SIG 64	KDC_ERR_INVALID_SIG 64
	KDC_ERR_KEY_TOO_WEAK 65	KDC_ERR_KEY_TOO_WEAK 65
	KDC_ERR_CERTIFICATE_MISMATCH 66	KDC_ERR_CERTIFICATE_MISMATCH 66
	KDC_ERR_CANT_VERIFY_CERTIFICATE 70	KDC_ERR_CANT_VERIFY_CERTIFICATE 70
	KDC_ERR_INVALID_CERTIFICATE 71	KDC_ERR_INVALID_CERTIFICATE 71

	skipping to change at line 259 ¶	skipping to change at line 272 ¶
	caName [0] Name,	caName [0] Name,
	-- Fully qualified X.500 name	-- Fully qualified X.500 name
	-- as defined in X.509 [11].	-- as defined in X.509 [11].
	issuerAndSerial [1] IssuerAndSerialNumber,	issuerAndSerial [1] IssuerAndSerialNumber,
	-- Identifies a specific CA	-- Identifies a specific CA
	-- certificate, if the client	-- certificate, if the client
	-- only trusts one.	-- only trusts one.
	...	...
	}	}


	[Should we even allow principalName as a choice? --brian]

	AuthPack ::= SEQUENCE {	AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,	pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
	-- Defined in X.509,	-- Defined in X.509,
	-- reproduced below.	-- reproduced below.
	-- Present only if the client	-- Present only if the client
	-- is using ephemeral-ephemeral	-- is using ephemeral-ephemeral
	-- Diffie-Hellman.	-- Diffie-Hellman.
	}	}


	skipping to change at line 284 ¶	skipping to change at line 295 ¶
	-- cusec and ctime are used as	-- cusec and ctime are used as
	-- in RFC 1510bis, for replay	-- in RFC 1510bis, for replay
	-- prevention.	-- prevention.
	nonce [2] INTEGER,	nonce [2] INTEGER,
	-- Binds reply to request,	-- Binds reply to request,
	-- except is zero when client	-- except is zero when client
	-- will accept cached	-- will accept cached
	-- Diffie-Hellman parameters	-- Diffie-Hellman parameters
	-- from KDC and MUST NOT be	-- from KDC and MUST NOT be
	-- zero otherwise.	-- zero otherwise.

		-- MUST be < 2^32.
	paChecksum [3] Checksum,	paChecksum [3] Checksum,

	-- Defined in RFC 1510bis.	-- Defined in [15].
	-- Performed over KDC-REQ-BODY,	-- Performed over KDC-REQ-BODY,
	-- must be unkeyed.	-- must be unkeyed.
	...	...
	}	}


	SubjectPublicKeyInfo ::= SEQUENCE {	IMPORTS
	-- As defined in X.509.	-- from X.509
	algorithm AlgorithmIdentifier,	SubjectPublicKeyInfo, AlgorithmIdentifier, DomainParameters,
	-- Equals dhpublicnumber (see	ValidationParms
	-- AlgorithmIdentifier, below)	FROM PKIX1Explicit88 { iso (1) identified-organization (3)
	-- for PKINIT.	dod (6) internet (1) security (5) mechanisms (5)
	subjectPublicKey BIT STRING	pkix (7) id-mod (0) id-pkix1-explicit-88 (1) }
	-- Equals public exponent
	-- (INTEGER encoded as payload
	-- of BIT STRING) for PKINIT.
	}

	AlgorithmIdentifier ::= SEQUENCE {
	-- As defined in X.509.
	algorithm OBJECT IDENTIFIER,
	-- dhpublicnumber is
	-- { iso (1) member-body (2)
	-- US (840) ansi-x942 (10046)
	-- number-type (2) 1 }
	-- From RFC 2459 [11].
	parameters ANY DEFINED BY algorithm OPTIONAL
	-- Content is DomainParameters
	-- (see below) for PKINIT.
	}

	DomainParameters ::= SEQUENCE {
	-- As defined in RFC 2459.
	p INTEGER,
	-- p is the odd prime, equals
	-- jq+1.
	g INTEGER,
	-- Generator.
	q INTEGER,
	-- Divides p-1.
	j INTEGER OPTIONAL,
	-- Subgroup factor.
	validationParms ValidationParms OPTIONAL
	}

	ValidationParms ::= SEQUENCE {
	-- As defined in RFC 2459.
	seed BIT STRING,
	-- Seed for the system parameter
	-- generation process.
	pgenCounter INTEGER
	-- Integer value output as part
	-- of the system parameter
	-- generation process.
	}

	The ContentInfo in the signedAuthPack is filled out as follows:	The ContentInfo in the signedAuthPack is filled out as follows:

	1. The eContent field contains data of type AuthPack. It MUST	1. The eContent field contains data of type AuthPack. It MUST
	contain the pkAuthenticator, and MAY also contain the	contain the pkAuthenticator, and MAY also contain the
	user's Diffie-Hellman public value (clientPublicValue).	user's Diffie-Hellman public value (clientPublicValue).

	2. The eContentType field MUST contain the OID value for	2. The eContentType field MUST contain the OID value for
	pkauthdata: { iso (1) org (3) dod (6) internet (1)	pkauthdata: { iso (1) org (3) dod (6) internet (1)
	security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}	security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}

	skipping to change at line 415 ¶	skipping to change at line 385 ¶
	-- order of encoding),	-- order of encoding),
	-- 1 = second certificate, etc.	-- 1 = second certificate, etc.

	If more than one signature is invalid, the KDC sends one TypedData	If more than one signature is invalid, the KDC sends one TypedData
	per invalid signature.	per invalid signature.

	The KDC MAY also check whether any of the certificates in the user's	The KDC MAY also check whether any of the certificates in the user's
	chain have been revoked. If any of them have been revoked, the KDC	chain have been revoked. If any of them have been revoked, the KDC
	returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC	returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
	attempts to determine the revocation status but is unable to do so,	attempts to determine the revocation status but is unable to do so,

	it returns an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. In	it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
	either case, the certificate or certificates affected are identified	The certificate or certificates affected are identified exactly as
	exactly as for an error of type KDC_ERR_INVALID_CERTIFICATE (see	for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
	above).


	If the certificate chain is successfully validated, but the name in	If the certificate chain is successfully validated, but the user's
	the user's certificate does not match the name given in the request,	certificate is not authorized to the client's principal name in the
	the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH. There	AS-REQ (when present), the KDC MUST return an error of type
	is no accompanying e-data for this error.	KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
		this error.

	Even if the chain is validated, and the names in the certificate and	Even if the chain is validated, and the names in the certificate and
	the request match, the KDC may decide not to trust the client. For	the request match, the KDC may decide not to trust the client. For
	example, the certificate may include (or not include) an Enhanced	example, the certificate may include (or not include) an Enhanced
	Key Usage (EKU) OID in the extensions field. As a matter of local	Key Usage (EKU) OID in the extensions field. As a matter of local
	policy, the KDC may decide to reject requests on the basis of the	policy, the KDC may decide to reject requests on the basis of the
	absence or presence of specific EKU OIDs. In this case, the KDC	absence or presence of specific EKU OIDs. In this case, the KDC
	returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED. For the	returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED. For the
	benefit of implementors, we define a PKINIT EKU OID as follows:	benefit of implementors, we define a PKINIT EKU OID as follows:
	{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)	{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)

	pkinit (3) pkekuoid (2) }.	pkinit (3) pkekuoid (4) }.

	If the certificate chain and usage check out, but the client's	If the certificate chain and usage check out, but the client's
	signature on the signedAuthPack fails to verify, the KDC returns an	signature on the signedAuthPack fails to verify, the KDC returns an
	error of type KDC_ERR_INVALID_SIG. There is no accompanying e-data	error of type KDC_ERR_INVALID_SIG. There is no accompanying e-data
	for this error.	for this error.


	[What about the case when all this checks out but one or more
	certificates is rejected for other reasons? For example, perhaps
	the key is too short for local policy. --DRE]

	The KDC must check the timestamp to ensure that the request is not	The KDC must check the timestamp to ensure that the request is not

	a replay, and that the time skew falls within acceptable limits. If	a replay, and that the time skew falls within acceptable limits.
	the check fails, the KDC returns an error of type KRB_AP_ERR_REPEAT	The recommendations for ordinary (that is, non-PKINIT) skew times
	or KRB_AP_ERR_SKEW, respectively.	apply here. If the check fails, the KDC returns an error of type
		KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively.

	Finally, if the clientPublicValue is filled in, indicating that the	Finally, if the clientPublicValue is filled in, indicating that the
	client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC	client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
	checks to see if the parameters satisfy its policy. If they do not,	checks to see if the parameters satisfy its policy. If they do not,
	it returns an error of type KDC_ERR_KEY_TOO_WEAK. The accompanying	it returns an error of type KDC_ERR_KEY_TOO_WEAK. The accompanying
	e-data is a SEQUENCE OF TypedData, whose data-type is	e-data is a SEQUENCE OF TypedData, whose data-type is
	TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing	TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing
	the DER encoding of a DomainParameters (see above), including	the DER encoding of a DomainParameters (see above), including
	appropriate Diffie-Hellman parameters with which to retry the	appropriate Diffie-Hellman parameters with which to retry the
	request.	request.


	[This makes no sense. For example, maybe the key is too strong for
	local policy. --DRE]

	In order to establish authenticity of the reply, the KDC will sign	In order to establish authenticity of the reply, the KDC will sign
	some key data (either the random key used to encrypt the reply in	some key data (either the random key used to encrypt the reply in
	the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to	the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to
	generate the reply-encrypting key in the case of a ReplyKeyPack).	generate the reply-encrypting key in the case of a ReplyKeyPack).
	The signature certificate to be used is to be selected as follows:	The signature certificate to be used is to be selected as follows:

	1. If the client included a kdcCert field in the PA-PK-AS-REQ,	1. If the client included a kdcCert field in the PA-PK-AS-REQ,
	use the referred-to certificate, if the KDC has it. If it	use the referred-to certificate, if the KDC has it. If it
	does not, the KDC returns an error of type	does not, the KDC returns an error of type
	KDC_ERR_CERTIFICATE_MISMATCH.	KDC_ERR_CERTIFICATE_MISMATCH.

	skipping to change at line 496 ¶	skipping to change at line 460 ¶
	3.2.3. KDC Reply	3.2.3. KDC Reply

	Assuming that the client's request has been properly validated, the	Assuming that the client's request has been properly validated, the
	KDC proceeds as per RFC 1510bis, except as follows.	KDC proceeds as per RFC 1510bis, except as follows.

	The user's name as represented in the AS-REP must be derived from	The user's name as represented in the AS-REP must be derived from
	the certificate provided in the client's request. If the KDC has	the certificate provided in the client's request. If the KDC has
	its own mapping from the name in the certificate to a Kerberos name,	its own mapping from the name in the certificate to a Kerberos name,
	it uses that Kerberos name.	it uses that Kerberos name.


	Otherwise, if the certificate contains a subjectAltName extension	Otherwise, if the certificate contains a SubjectAltName extension
	with PrincipalName, it uses that name. In this case, the realm in	with a KerberosName in the otherName field, it uses that name.
	the ticket is that of the local realm (or some other realm name
	chosen by that realm). (OID and syntax for this extension to be
	specified here.) Otherwise, the KDC returns an error of type
	KDC_ERR_CLIENT_NAME_MISMATCH.


	In addition, the certifiers in the certification path of the user's	AnotherName ::= SEQUENCE {
	certificate MUST be added to an authdata (to be specified at a later	-- Defined in [11].
	time).	type-id OBJECT IDENTIFIER,
		value [0] EXPLICIT ANY DEFINED BY type-id
		}

		KerberosName ::= SEQUENCE {
		realm [0] Realm,
		principalName [1] PrincipalName
		}

		with OID

		krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1)
		security (5) kerberosv5 (2) }

		krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }

		In this case, the realm in the ticket is that of the local realm (or
		some other realm name chosen by that realm). Otherwise, the KDC
		returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH.

		In addition, the KDC MUST set the initial flag in the issued TGT
		and add an authorization data of type AD-INITIAL-VERIFIED-CAS to
		the TGT. The value is an OCTET STRING containing the DER encoding
		of InitialVerifiedCAs:

		InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
		ca [0] Name,
		ocspValidated [1] BOOLEAN,
		...
		}

		The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
		containers if the list of CAs satisfies the KDC's realm's policy.
		(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
		Furthermore, any TGS must copy such authorization data from tickets
		used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
		including the AD-IF-RELEVANT container, if present.

		AP servers that understand this authorization data type SHOULD apply
		local policy to determine whether a given ticket bearing such a type
		(not contained within an AD-IF-RELEVANT container) is acceptable.
		(This corresponds to the AP server checking the transited field when
		the TRANSITED-POLICY-CHECKED flag has not been set.) If such a data
		type is contained within an AD-IF-RELEVANT container, AP servers
		still MAY apply local policy to determine whether the authorization
		data is acceptable.

	The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then	The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then
	encrypts the reply as usual, but not with the user's long-term key.	encrypts the reply as usual, but not with the user's long-term key.
	Instead, it encrypts it with either a random encryption key, or a	Instead, it encrypts it with either a random encryption key, or a

	key derived through a Diffie-Hellman exchange. Which is the case is	key derived from a Diffie-Hellman exchange. Which is the case is
	indicated by the contents of the PA-PK-AS-REP (note tags):	indicated by the contents of the PA-PK-AS-REP (note tags):

	PA-PK-AS-REP ::= CHOICE {	PA-PK-AS-REP ::= CHOICE {
	-- PAType YY (TBD)	-- PAType YY (TBD)
	dhSignedData [0] ContentInfo,	dhSignedData [0] ContentInfo,
	-- Type is SignedData.	-- Type is SignedData.
	-- Content is KDCDHKeyInfo	-- Content is KDCDHKeyInfo
	-- (defined below).	-- (defined below).
	encKeyPack [1] ContentInfo,	encKeyPack [1] ContentInfo,
	-- Type is EnvelopedData.	-- Type is EnvelopedData.

	skipping to change at line 576 ¶	skipping to change at line 581 ¶

	5. If the client and KDC agree to use cached parameters, the	5. If the client and KDC agree to use cached parameters, the
	KDC SHOULD return a zero in the nonce field and include the	KDC SHOULD return a zero in the nonce field and include the
	expiration time of the cached values in the dhKeyExpiration	expiration time of the cached values in the dhKeyExpiration
	field. If this time is exceeded, the client SHOULD NOT use	field. If this time is exceeded, the client SHOULD NOT use
	the reply. If the time is absent, the client SHOULD NOT use	the reply. If the time is absent, the client SHOULD NOT use
	the reply and MAY resubmit a request with a non-zero nonce,	the reply and MAY resubmit a request with a non-zero nonce,
	thus indicating non-acceptance of the cached parameters.	thus indicating non-acceptance of the cached parameters.

	The key is derived as follows: Both the KDC and the client calculate	The key is derived as follows: Both the KDC and the client calculate

	the value g^(ab) mod p, where a and b are the client and KDC's	the value g^(ab) mod p, where a and b are the client's and KDC's
	private exponents, respectively. They both take the first N bits of	private exponents, respectively. They both take the first k bits of
	this secret value and convert it into a reply key, where N depends	this secret value as a key generation seed, where the parameter k
	on the key type.	(the size of the seed) is dependent on the selected key type, as
		specified in the Kerberos crypto draft [15]. The seed is then
		converted into a protocol key by applying to it a random-to-key
		function, which is also dependent on key type.


	1. For example, if the key type is DES, N = 64 bits, where some	The protocol key is used to derive the integrity key Ki and the
	of the bits are replaced with parity bits, according to FIPS	encryption key Ke according to [15]. Ke and Ki are used to generate
	PUB 74 [c].	the encrypted part of the AS-REP.


	2. If the key type is (three-key) 3DES, N = 192 bits, where	1. For example, if the encryption type is DES with MD4, k = 64
	some of the bits are replaced with parity bits, again	bits and the random-to-key function consists of replacing
	according to FIPS PUB 74.	some of the bits with parity bits, according to FIPS PUB 74
		[cite]. In this case, the key derivation function for Ke is
		the identity function, and Ki is not needed because the
		checksum in the EncryptedData is not keyed.

		2. If the encryption type is three-key 3DES with HMAC-SHA1,
		k = 168 bits and the random-to-key function is
		DES3random-to-key as defined in [15]. This function inserts
		parity bits to create a 192-bit 3DES protocol key that is
		compliant with FIPS PUB 74 [cite]. Ke and Ki are derived
		from this protocol key according to [15] with the key usage
		number set to 3 (AS-REP encrypted part).

	If the KDC and client are not using Diffie-Hellman, the KDC encrypts	If the KDC and client are not using Diffie-Hellman, the KDC encrypts
	the reply with an encryption key, packed in the encKeyPack, which	the reply with an encryption key, packed in the encKeyPack, which
	contains data of type ReplyKeyPack:	contains data of type ReplyKeyPack:

	ReplyKeyPack ::= SEQUENCE {	ReplyKeyPack ::= SEQUENCE {
	replyKey [0] EncryptionKey,	replyKey [0] EncryptionKey,
	-- Defined in RFC 1510bis.	-- Defined in RFC 1510bis.
	-- Used to encrypt main reply.	-- Used to encrypt main reply.

	-- MUST be at least as strong as	-- MUST be at least as large
	-- enctype of session key.	-- as session key.
	nonce [1] INTEGER,	nonce [1] INTEGER,
	-- Binds reply to request.	-- Binds reply to request.

		-- MUST be < 2^32.
	...	...
	}	}


	[What exactly does "at least as strong" mean? --DRE]

	The fields of the ContentInfo for encKeyPack MUST be filled in as	The fields of the ContentInfo for encKeyPack MUST be filled in as
	follows:	follows:

	1. The innermost data is of type SignedData. The eContent for	1. The innermost data is of type SignedData. The eContent for
	this data is of type ReplyKeyPack.	this data is of type ReplyKeyPack.

	2. The eContentType for this data contains the OID value for	2. The eContentType for this data contains the OID value for
	pkrkeydata: { iso (1) org (3) dod (6) internet (1)	pkrkeydata: { iso (1) org (3) dod (6) internet (1)
	security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }	security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }


	skipping to change at line 652 ¶	skipping to change at line 670 ¶
	3.2.4. Validation of KDC Reply	3.2.4. Validation of KDC Reply

	Upon receipt of the KDC's reply, the client proceeds as follows. If	Upon receipt of the KDC's reply, the client proceeds as follows. If
	the PA-PK-AS-REP contains a dhSignedData, the client obtains and	the PA-PK-AS-REP contains a dhSignedData, the client obtains and
	verifies the Diffie-Hellman parameters, and obtains the shared key	verifies the Diffie-Hellman parameters, and obtains the shared key
	as described above. Otherwise, the message contains an encKeyPack,	as described above. Otherwise, the message contains an encKeyPack,
	and the client decrypts and verifies the temporary encryption key.	and the client decrypts and verifies the temporary encryption key.
	In either case, the client then decrypts the main reply with the	In either case, the client then decrypts the main reply with the
	resulting key, and then proceeds as described in RFC 1510bis.	resulting key, and then proceeds as described in RFC 1510bis.


		3.2.5. Support for OCSP

		OCSP (Online Certificate Status Protocol) [cite] allows the use of
		on-line requests for a client or server to determine the validity of
		each other's certificates. It is particularly useful for clients
		authenticating each other across a constrained network. These
		clients will not have to download the entire CRL to check for the
		validity of the KDC's certificate.

		In these cases, the KDC generally has better connectivity to the
		OCSP server, and it therefore processes the OCSP request and
		response and sends the results to the client. The changes proposed
		in this section allow a client to request an OCSP response from the
		KDC when using PKINIT. This is similar to the way that OCSP is
		handled in [cite].

		OCSP support is provided in PKINIT through the use of additional
		preauthentication data. The following new preauthentication types
		are defined:

		PA-PK-OCSP-REQ ::= SEQUENCE {
		-- PAType TBD
		responderIDList [0] SEQUENCE of ResponderID OPTIONAL,
		-- ResponderID is a DER-encoded
		-- ASN.1 type defined in [cite]
		requestExtensions [1] Extensions OPTIONAL
		-- Extensions is a DER-encoded
		-- ASN.1 type defined in [cite]
		}

		PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse
		-- OCSPResponse is a DER-encoded
		-- ASN.1 type defined in [cite]

		A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.
		KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a
		PA-PK-OCSP-REQ from the client. The KDC may either send a cached
		OCSP response or send an on-line request to the OCSP server.

		When using OCSP, the response is signed by the OCSP server, which is
		trusted by the client. Depending on local policy, further
		verification of the validity of the OCSP server may need to be done.

	4. Security Considerations	4. Security Considerations

	PKINIT raises certain security considerations beyond those that can	PKINIT raises certain security considerations beyond those that can
	be regulated strictly in protocol definitions. We will address them	be regulated strictly in protocol definitions. We will address them
	in this section.	in this section.

	PKINIT extends the cross-realm model to the public-key	PKINIT extends the cross-realm model to the public-key
	infrastructure. Anyone using PKINIT must be aware of how the	infrastructure. Anyone using PKINIT must be aware of how the
	certification infrastructure they are linking to works.	certification infrastructure they are linking to works.


	skipping to change at line 674 ¶	skipping to change at line 735 ¶
	now includes public-key cryptosystems. Many systems, for example,	now includes public-key cryptosystems. Many systems, for example,
	allow the use of 512-bit public keys. Using such keys to wrap data	allow the use of 512-bit public keys. Using such keys to wrap data
	encrypted under strong conventional cryptosystems, such as 3DES, may	encrypted under strong conventional cryptosystems, such as 3DES, may
	be inappropriate.	be inappropriate.

	PKINIT calls for randomly generated keys for conventional	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.


		PKINIT allows the use of a zero nonce in the PKAuthenticator when
		cached Diffie-Hellman parameters are used. In this case, message
		binding is performed using the nonce in the main request in the same
		way as it is done for ordinary (that is, non-PKINIT) AS-REQs. The
		nonce field in the KDC request body is signed through the checksum
		in the PKAuthenticator, and it therefore cryptographically binds the
		AS-REQ with the AS-REP. If cached parameters are also used on the
		client side, the generated session key will be the same, and a
		compromised session key could lead to the compromise of future
		cached exchanges. It is desirable to limit the use of cached
		parameters to just the KDC, in order to eliminate this exposure.

	Care should be taken in how certificates are chosen for the purposes	Care should be taken in how certificates are chosen for the purposes
	of authentication using PKINIT. Some local policies may require	of authentication using PKINIT. Some local policies may require
	that key escrow be applied for certain certificate types. People	that key escrow be applied for certain certificate types. People
	deploying PKINIT should be aware of the implications of using	deploying PKINIT should be aware of the implications of using
	certificates that have escrowed keys for the purposes of	certificates that have escrowed keys for the purposes of
	authentication.	authentication.

	PKINIT does not provide for a "return routability" test to prevent	PKINIT does not provide for a "return routability" test to prevent
	attackers from mounting a denial-of-service attack on the KDC by	attackers from mounting a denial-of-service attack on the KDC by
	causing it to perform unnecessary and expensive public-key	causing it to perform unnecessary and expensive public-key
	operations. Strictly speaking, this is also true of standard	operations. Strictly speaking, this is also true of standard
	Kerberos, although the potential cost is not as great, because	Kerberos, although the potential cost is not as great, because
	standard Kerberos does not make use of public-key cryptography.	standard Kerberos does not make use of public-key cryptography.

		It might be possible to address this using a preauthentication field
		as part of the proposed Kerberos preauthenticatino framework.

	5. Acknowledgements	5. 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.

	6. Expiration Date	6. Expiration Date


	This draft expires May 31, 2004.	This draft expires August 20, 2004.

	7. Bibliography	7. Bibliography

	[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service	[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
	(V5). Request for Comments 1510.	(V5). Request for Comments 1510.

	[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service	[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
	for Computer Networks, IEEE Communications, 32(9):33-38. September	for Computer Networks, IEEE Communications, 32(9):33-38. September
	1994.	1994.


	skipping to change at line 744 ¶	skipping to change at line 819 ¶
	RFC.	RFC.

	[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA	[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA
	Laboratories Technical Note Version 1.5. Revised November 1, 1993	Laboratories Technical Note Version 1.5. Revised November 1, 1993

	[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data	[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
	Security, Inc. A Description of the RC2(r) Encryption Algorithm.	Security, Inc. A Description of the RC2(r) Encryption Algorithm.
	March 1998. Request for Comments 2268.	March 1998. Request for Comments 2268.

	[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public	[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public

	Key Infrastructure, Certificate and CRL Profile, January 1999.	Key Infrastructure, Certificate and CRL Profile, April 2002.
	Request for Comments 2459.	Request for Comments 3280.

	[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography	[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
	Specifications, October 1998. Request for Comments 2437.	Specifications, October 1998. Request for Comments 2437.

	[13] ITU-T (formerly CCITT) Information Processing Systems - Open	[13] 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.

	[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA	[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
	Laboratories Technical Note, Version 1.4, Revised November 1, 1993.	Laboratories Technical Note, Version 1.4, Revised November 1, 1993.


		[15] K. Raeburn. Encryption and Checksum Specifications for
		Kerberos 5, October 2003. draft-ietf-krb-wg-crypto-06.txt.

		[16] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
		T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
		Request for Comments 3546.

		[17] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
		Internet X.509 Public Key Infrastructure: Online Certificate Status
		Protocol - OCSP, June 1999. Request for Comments 2560.

	8. Authors	8. 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


End of changes. 33 change blocks.
	105 lines changed or deleted	191 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/