< draft-ietf-cat-kerberos-pk-init-09.txt		draft-ietf-cat-kerberos-pk-init-10.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-09.txt Clifford Neuman		draft-ietf-cat-kerberos-pk-init-10.txt Clifford Neuman
	Updates: RFC 1510 ISI		Updates: RFC 1510 ISI
	expires December 1, 1999 Matthew Hur		expires April 30, 2000 Matthew Hur
	CyberSafe Corporation		CyberSafe Corporation
	Ari Medvinsky		Ari Medvinsky
	Excite		Excite
	Sasha Medvinsky		Sasha Medvinsky
	General Instrument		General Instrument
	John Wray		John Wray
	Iris Associates, Inc.		Iris Associates, Inc.
	Jonathan Trostle		Jonathan Trostle
	Cisco		Cisco
	skipping to change at line 44 ¶		skipping to change at line 44 ¶
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	To learn the current status of any Internet-Draft, please check		To learn the current status of any Internet-Draft, please check
	the "1id-abstracts.txt" listing contained in the Internet-Drafts		the "1id-abstracts.txt" listing contained in the Internet-Drafts
	Shadow Directories on ftp.ietf.org (US East Coast),		Shadow Directories on ftp.ietf.org (US East Coast),
	nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or		nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
	munnari.oz.au (Pacific Rim).		munnari.oz.au (Pacific Rim).
	The distribution of this memo is unlimited. It is filed as		The distribution of this memo is unlimited. It is filed as
	draft-ietf-cat-kerberos-pk-init-09.txt, and expires December 1,		draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30,
	1999. Please send comments to the authors.		2000. Please send comments to the authors.
	1. Abstract		1. Abstract
	This document defines extensions (PKINIT) to the Kerberos protocol		This document defines extensions (PKINIT) to the Kerberos protocol
	specification (RFC 1510 [1]) to provide a method for using public		specification (RFC 1510 [1]) to provide a method for using public
	key cryptography during initial authentication. The methods		key cryptography during initial authentication. The methods
	defined specify the ways in which preauthentication data fields and		defined specify the ways in which preauthentication data fields and
	error data fields in Kerberos messages are to be used to transport		error data fields in Kerberos messages are to be used to transport
	public key data.		public key data.
	skipping to change at line 71 ¶		skipping to change at line 71 ¶
	perspective) and the ability to leverage existing and developing		perspective) and the ability to leverage existing and developing
	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 Diffie-Hellman keys in combination with digital		PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
	signature keys as the primary, required mechanism. It also allows		combination with digital signature keys as the primary, required
	for the use of RSA keys. Note that PKINIT supports the use of		mechanism. It also allows for the use of RSA keys and/or (static)
	separate signature and encryption keys.		Diffie-Hellman certificates. Note in particular that PKINIT supports
			the use of separate signature and encryption 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 a request to the KDC as before, except that if that user		user sends an AS-REQ message to the KDC as before, except that if that
	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
	in the preauthentication fields. Upon receipt of this request, the		in the preauthentication fields. Upon receipt of this request, the
	KDC verifies the certificate and issues a ticket granting ticket		KDC verifies the certificate and issues a ticket granting ticket
	(TGT) as before, except that the encPart from the AS-REP message		(TGT) as before, except that the encPart from the AS-REP message
	carrying the TGT is now encrypted utilizing either a Diffie-Hellman		carrying the TGT is now encrypted utilizing either a Diffie-Hellman
	derived key or the user's public key. This message is authenticated		derived key or the user's public key. This message is authenticated
	utilizing the public key signature of the KDC.		utilizing the public key signature of the KDC.
			Note that PKINIT does not require the use of certificates. A KDC
			may store the public key of a principal as part of that principal's
			record. In this scenario, the KDC is the trusted party that vouches
			for the principal (as in a standard, non-cross realm, Kerberos
			environment). Thus, for any principal, the KDC may maintain a
			secret key, a public key, or both.
	The PKINIT specification may also be used as a building block for		The PKINIT specification may also be used as a building block for
	other specifications. PKCROSS [3] utilizes PKINIT for establishing		other specifications. PKCROSS [3] utilizes PKINIT for establishing
	the inter-realm key and associated inter-realm policy to be applied		the inter-realm key and associated inter-realm policy to be applied
	in issuing cross realm service tickets. As specified in [4],		in issuing cross realm service tickets. As specified in [4],
	anonymous Kerberos tickets can be issued by applying a NULL		anonymous Kerberos tickets can be issued by applying a NULL
	signature in combination with Diffie-Hellman in the PKINIT exchange.		signature in combination with Diffie-Hellman in the PKINIT exchange.
	Additionally, the PKINIT specification may be used for direct peer		Additionally, the PKINIT specification may be used for direct peer
	to peer authentication without contacting a central KDC. This		to peer authentication without contacting a central KDC. This
	application of PKINIT is described in PKTAPP [5] and is based on		application of PKINIT is described in PKTAPP [5] and is based on
	concepts introduced in [6, 7]. For direct client-to-server		concepts introduced in [6, 7]. For direct client-to-server
	skipping to change at line 174 ¶		skipping to change at line 182 ¶
	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).
	In many cases, PKINIT requires the encoding of an X.500 name as a		In many cases, PKINIT requires the encoding of the X.500 name of a
	Realm. In these cases, the realm will be represented using a		certificate authority as a Realm. When such a name appears as
	different style, specified in RFC 1510 with the following example:		a ream it will be represented using the "other" form of the realm
			name as specified in the naming constraints section of RFC1510.
	NAMETYPE:rest/of.name=without-restrictions
	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:
	X500-RFC2253:RFC2253Encode(DistinguishedName)		<nametype> + ":" + <string>
			where nametype is "X500-RFC2253" and string is the result of doing
			an RFC2253 encoding of the distinguished name, i.e.
			"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
	readable UTF encoding of an X.500 name, as defined by		function returing a readable UTF encoding of an X.500 name, as
	RFC 2253 [14] (part of LDAPv3).		defined by RFC 2253 [14] (part of LDAPv3 [18]).
	To ensure that this encoding is unique, we add the following rule		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		The order in which the attributes appear in the RFC 2253
	encoding must be the reverse of the order in the ASN.1		encoding must be the reverse of the order in the ASN.1
	encoding of the X.500 name that appears in the public key		encoding of the X.500 name that appears in the public key
	certificate. The order of the relative distinguished names		certificate. The order of the relative distinguished names
	(RDNs), as well as the order of the AttributeTypeAndValues		(RDNs), as well as the order of the AttributeTypeAndValues
	within each RDN, will be reversed. (This is despite the fact		within each RDN, will be reversed. (This is despite the fact
	that an RDN is defined as a SET of AttributeTypeAndValues, where		that an RDN is defined as a SET of AttributeTypeAndValues, where
	an order is normally not important.)		an order is normally not important.)
	Similarly, PKINIT may require the encoding of an X.500 name as a		Similarly, in cases where the KDC does not provide a specific
	PrincipalName. In these cases, the name-type of the principal name		policy based mapping from the X.500 name or X.509 Version 3
	shall be set to KRB_NT-X500-PRINCIPAL. This new name type is		SubjectAltName extension in the user's certificate to a Kerberos
	defined as:		principal name, PKINIT requires the direct encoding of the X.500
			name as a PrincipalName. In this case, the name-type of the
			principal name shall be set to KRB_NT-X500-PRINCIPAL. This new
			name type is defined in RFC 1510 as:
	KRB_NT_X500_PRINCIPAL 6		KRB_NT_X500_PRINCIPAL 6
	The name-string shall be set as follows:		The name-string shall be set as follows:
	RFC2253Encode(DistinguishedName)		RFC2253Encode(DistinguishedName)
	as described above.		as described above. When this name type is used, the principal's
			realm shall be set to the certificate authority's distinguished
			name using the X500-RFC2253 realm name format described earlier in
			this section
	RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:		RFC 1510 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
	}		}
	For the purposes of encoding an X.500 name within this structure,		For the purposes of encoding an X.500 name within this structure,
	the name-string shall be encoded as a single GeneralString.		the name-string shall be encoded as a single GeneralString.
	Note that name mapping may be required or optional based on		Note that name mapping may be required or optional based on
	policy.		policy. All names must conform to validity requirements as given
			in RFC 1510.
	3.1.1. Encryption and Key Formats		3.1.1. Encryption and Key Formats
	In the exposition below, we use the terms public key and private		In the exposition below, we use the terms public key and private
	key generically. It should be understood that the term "public		key generically. It should be understood that the term "public
	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.		not preclude the assignment of bitwise identical keys for RSA
			keys.
	In the case of Diffie-Hellman, the key shall be produced from the		In the case of Diffie-Hellman, the key shall be produced from the
	agreed bit string as follows:		agreed bit string as follows:
	* Truncate the bit string to the appropriate length.		* Truncate the bit string to the appropriate length.
	* Rectify parity in each byte (if necessary) to obtain the key.		* Rectify parity in each byte (if necessary) to obtain the key.
	For instance, in the case of a DES key, we take the first eight		For instance, in the case of a DES key, we take the first eight
	bytes of the bit stream, and then adjust the least significant bit		bytes of the bit stream, and then adjust the least significant bit
	of each byte to ensure that each byte has odd parity.		of each byte to ensure that each byte has odd parity.
	skipping to change at line 300 ¶		skipping to change at line 319 ¶
	The full definition of the above algorithm identifiers and their		The full definition of the above algorithm identifiers and their
	corresponding parameters (an IV for block chaining) is provided in		corresponding parameters (an IV for block chaining) is provided in
	the CMS specification [11].		the CMS specification [11].
	3.2. Public Key Authentication		3.2. Public Key Authentication
	Implementation of the changes in this section is REQUIRED for		Implementation of the changes in this section is REQUIRED for
	compliance with PKINIT.		compliance with PKINIT.
	It is assumed that all public keys are signed by some certification		3.2.1. Client Request
	authority (CA). The initial authentication request is sent as per
	RFC 1510, except that a preauthentication field containing data		Public keys may be signed by some certification authority (CA), or
	signed by the user's private key accompanies the request:		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
			use of certificates.
			The initial authentication request is sent as per RFC 1510, except
			that a preauthentication field containing data signed by the user's
			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] SignedData
	-- defined in CMS [11]		-- defined in CMS [11]
	-- AuthPack (below) defines the data		-- AuthPack (below) defines the data
	-- that is signed		-- that is signed
	trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,		trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
	-- CAs that the client trusts		-- CAs that the client trusts
	kdcCert [2] IssuerAndSerialNumber OPTIONAL		kdcCert [2] IssuerAndSerialNumber OPTIONAL
	-- as defined in CMS [11]		-- as defined in CMS [11]
	-- specifies a particular KDC		-- specifies a particular KDC
	-- certificate if the client		-- certificate if the client
	-- already has it;		-- already has it;
	-- must be accompanied by
	-- a single trustedCertifier
	encryptionCert [3] IssuerAndSerialNumber OPTIONAL		encryptionCert [3] IssuerAndSerialNumber OPTIONAL
	-- For example, this may be the		-- For example, this may be the
	-- client's Diffie-Hellman		-- client's Diffie-Hellman
	-- certificate, or it may be the		-- certificate, or it may be the
	-- client's RSA encryption		-- client's RSA encryption
	-- certificate.		-- certificate.
	}		}
	TrustedCas ::= CHOICE {		TrustedCas ::= CHOICE {
	principalName [0] KerberosName,		principalName [0] KerberosName,
	-- 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 OPTIONAL		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:		Usage of SignedData:
	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 IETF.		Message Syntax, a product of the S/MIME working group of the IETF.
	- The encapContentInfo field must contain the PKAuthenticator		- 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.
	skipping to change at line 358 ¶		skipping to change at line 381 ¶
	- The eContent field is data of the type AuthPack (below).		- The eContent field is data of the type AuthPack (below).
	- The signerInfos field contains the signature of AuthPack.		- The signerInfos field contains the signature of AuthPack.
	- The Certificates field, when non-empty, contains the client's		- The Certificates field, when non-empty, contains the client's
	certificate chain. If present, the KDC uses the public key from		certificate chain. If present, the KDC uses the public key from
	the client's certificate to verify the signature in the request.		the client's certificate to verify the signature in the request.
	Note that the client may pass different certificates that are used		Note that the client may pass different certificates that are used
	for signing or for encrypting. Thus, the KDC may utilize a		for signing or for encrypting. Thus, the KDC may utilize a
	different client certificate for signature verification than the		different client certificate for signature verification than the
	one it uses to encrypt the reply to the client. For example, the		one it uses to encrypt the reply to the client. For example, the
	client may place a Diffie-Hellman certificate in this field in		client may place a Diffie-Hellman certificate in this field in
	order to convey its static Diffie Hellman certificate to the KDC		order to convey its static Diffie Hellman certificate to the KDC to
	enable static-ephemeral Diffie-Hellman mode for the reply. As		enable static-ephemeral Diffie-Hellman mode for the reply; in this
	another example, the client may place an RSA encryption		case, the client does NOT place its public value in the AuthPack
	certificate in this field.		(defined below). As another example, the client may place an RSA
			encryption certificate in this field. However, there must always
			be (at least) a signature certificate.
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
	-- if client is using Diffie-Hellman		-- if client is using Diffie-Hellman
			-- (ephemeral-ephemeral only)
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	kdcName [0] PrincipalName,		kdcName [0] PrincipalName,
	kdcRealm [1] Realm,		kdcRealm [1] Realm,
	cusec [2] INTEGER,		cusec [2] INTEGER,
	-- for replay prevention		-- for replay prevention as in RFC1510
	ctime [3] KerberosTime,		ctime [3] KerberosTime,
	-- for replay prevention		-- for replay prevention as in RFC1510
	nonce [4] INTEGER		nonce [4] INTEGER
	}		}
	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)
	skipping to change at line 413 ¶		skipping to change at line 439 ¶
	TypedData ::= SEQUENCE {		TypedData ::= SEQUENCE {
	data-type [0] INTEGER,		data-type [0] INTEGER,
	data-value [1] OCTET STRING,		data-value [1] OCTET STRING,
	} -- per Kerberos RFC 1510 revisions		} -- per Kerberos RFC 1510 revisions
	where:		where:
	data-type = TD-PKINIT-CMS-CERTIFICATES = 101		data-type = TD-PKINIT-CMS-CERTIFICATES = 101
	data-value = CertificateSet // as specified by CMS [11]		data-value = CertificateSet // as specified by CMS [11]
	The PKAuthenticator carries information to foil replay attacks,		The PKAuthenticator carries information to foil replay attacks, and
	to bind the request and response. The PKAuthenticator is signed		to bind the request and response. The PKAuthenticator is signed
	with the private key corresponding to the public key in the		with the client's signature key.
	certificate found in userCert (or cached by the KDC).
	The trustedCertifiers field contains a list of certification
	authorities trusted by the client, in the case that the client does
	not possess the KDC's public key certificate. If the KDC has no
	certificate signed by any of the trustedCertifiers, then it returns
	an error of type KDC_ERR_KDC_NOT_TRUSTED.
	KDCs should try to (in order of preference):		3.2.2. KDC Response
	1. Use the KDC certificate identified by the serialNumber included
	in the client's request.
	2. Use a certificate issued to the KDC by the client's CA (if in the
	middle of a CA key roll-over, use the KDC cert issued under same
	CA key as user cert used to verify request).
	3. Use a certificate issued to the KDC by one of the client's
	trustedCertifier(s);
	If the KDC is unable to comply with any of these options, then the
	KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
	client.
	Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication		Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
	type, the KDC attempts to verify the user's certificate chain		type, the KDC attempts to verify the user's certificate chain
	(userCert), if one is provided in the request. This is done by		(userCert), if one is provided in the request. This is done by
	verifying the certification path against the KDC's policy of		verifying the certification path against the KDC's policy of
	legitimate certifiers. This may be based on a certification		legitimate certifiers. This may be based on a certification
	hierarchy, or it may be simply a list of recognized certifiers in a		hierarchy, or it may be simply a list of recognized certifiers in a
	system like PGP.		system like PGP.
	If the client's certificate chain contains no certificate signed by		If the client's certificate chain contains no certificate signed by
	a CA trusted by the KDC, then the KDC sends back an error message		a CA trusted by the KDC, then the KDC sends back an error message
	of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data		of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data
	is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)		is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
	whose data-value is an OCTET STRING which is the DER encoding of		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 the signature on one of the certificates in the client's chain		If while verifying a certificate chain the KDC determines that the
	fails verification, then the KDC returns an error of type		signature on one of the certificates in the CertificateSet from
	KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE		the signedAuthPack fails verification, then the KDC returns an
	of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose		error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying
	data-value is an OCTET STRING which is the DER encoding of		e-data is a SEQUENCE of one TypedData (with type
			TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
			which is the DER encoding of the index into the CertificateSet
			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
	been revoked, then the KDC returns an error of type		been revoked, then the KDC returns an error of type
	KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the		KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
	certificate's revocation status is unknown, the KDC returns an		the certificate's revocation status is unknown or not
	error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation		available, then if required by policy, the KDC returns the
	status is unavailable, the KDC returns an error of type		appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
	KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three		KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
	cases, the affected certificate is identified by the accompanying		cases, the affected certificate is identified by the accompanying
	e-data, which contains a CertificateIndex as described for		e-data, which contains a CertificateIndex as described for
	KDC_ERR_INVALID_CERTIFICATE.		KDC_ERR_INVALID_CERTIFICATE.
	If the certificate chain can be verified, but the name of the		If the certificate chain can be verified, but the name of the
	client in the certificate does not match the client's name in the		client in the certificate does not match the client's name in the
	request, then the KDC returns an error of type		request, then the KDC returns an error of type
	KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data		KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
	field in this case.		field in this case.
	skipping to change at line 515 ¶		skipping to change at line 527 ¶
	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. Otherwise, it generates its own public and		KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
	private values for the response.		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.		KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
	Assuming no errors, the KDC replies as per RFC 1510, except as		Assuming no errors, the KDC replies as per RFC 1510, 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
	following decision algorithm:		following decision algorithm:
	1. If the KDC has a mapping from the name in the certificate		1. If the KDC has a mapping from the name in the certificate
	to a Kerberos name, then use that name.		to a Kerberos name, then use that name.
	Else		Else
	2. If the certificate contains a Kerberos name in an extension		2. If the certificate contains the SubjectAltName extention
	field, and local KDC policy allows, then use that name.		and the local KDC policy defines a mapping from the
			SubjectAltName to a Kerberos name, then use that name.
	Else		Else
	3. Use the name as represented in the certificate, mapping		3. Use the name as represented in the certificate, mapping
	as necessary (e.g., as per RFC 2253 for X.500 names). In		mapping as necessary (e.g., as per RFC 2253 for X.500
	this case the realm in the ticket shall be the name of the		names). In this case the realm in the ticket shall be the
	certification authority that issued the user's certificate.		name of the certifier that issued the user's certificate.
			Note that a principal name may be carried in the subject alt name
			field of a certificate. This name may be mapped to a principal
			record in a security database based on local policy, for example
			the subject alt name may be kerberos/principal@realm format. In
			this case the realm name is not that of the CA but that of the
			local realm doing the mapping (or some realm name chosen by that
			realm).
			If a non-KDC X.509 certificate contains the principal name within
			the subjectAltName version 3 extension , that name may utilize
			KerberosName as defined below, or, in the case of an S/MIME
			certificate [17], may utilize the email address. If the KDC
			is presented with as S/MIME certificate, then the email address
			within subjectAltName will be interpreted as a principal and realm
			separated by the "@" sign, or as a name that needs to be
			canonicalized. If the resulting name does not correspond to a
			registered principal name, then the principal name is formed as
			defined in section 3.1.
			The trustedCertifiers field contains a list of certification
			authorities trusted by the client, in the case that the client does
			not possess the KDC's public key certificate. If the KDC has no
			certificate signed by any of the trustedCertifiers, then it returns
			an error of type KDC_ERR_KDC_NOT_TRUSTED.
			KDCs should try to (in order of preference):
			1. Use the KDC certificate identified by the serialNumber included
			in the client's request.
			2. Use a certificate issued to the KDC by the client's CA (if in the
			middle of a CA key roll-over, use the KDC cert issued under same
			CA key as user cert used to verify request).
			3. Use a certificate issued to the KDC by one of the client's
			trustedCertifier(s);
			If the KDC is unable to comply with any of these options, then the
			KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
			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 a random key generated only for this particular response. This		with the Diffie Hellman derived key or a random key generated
	random key is sealed in the preauthentication field:		for this particular response which is carried in the padata field of
			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] SignedData,
	-- Defined in CMS and used only with		-- Defined in CMS and used only with
	-- Diffie-Helman key exchange		-- Diffie-Hellman key exchange (if the
			-- client public value was present in the
			-- request).
	-- This choice MUST be supported		-- This choice MUST be supported
	-- by compliant implementations.		-- by compliant implementations.
	encKeyPack [1] EnvelopedData,		encKeyPack [1] EnvelopedData,
	-- Defined in CMS		-- Defined in CMS
	-- The temporary key is encrypted		-- The temporary key is encrypted
	-- using the client public key		-- using the client public key
	-- key		-- key
	-- SignedReplyKeyPack, encrypted		-- SignedReplyKeyPack, encrypted
	-- with the temporary key, is also		-- with the temporary key, is also
	-- included.		-- included.
	skipping to change at line 583 ¶		skipping to change at line 636 ¶
	- The certificates field must contain the certificates necessary		- The certificates field must contain the certificates necessary
	for the client to establish trust in the KDC's certificate		for the client to establish trust in the KDC's certificate
	based on the list of trusted certifiers sent by the client in		based on the list of trusted certifiers sent by the client in
	the PA-PK-AS-REQ. This field may be empty if the client did		the PA-PK-AS-REQ. This field may be empty if the client did
	not send to the KDC a list of trusted certifiers (the		not send to the KDC a list of trusted certifiers (the
	trustedCertifiers field was empty, meaning that the client		trustedCertifiers field was empty, meaning that the client
	already possesses the KDC's certificate).		already possesses the KDC's certificate).
	- The signerInfos field is a SET that must contain at least one		- The signerInfos field is a SET that must contain at least one
	member, since it contains the actual signature.		member, since it contains the actual signature.
			KdcDHKeyInfo ::= SEQUENCE {
			-- used only when utilizing Diffie-Hellman
			nonce [0] INTEGER,
			-- binds responce to the request
			subjectPublicKey [2] BIT STRING
			-- Equals public exponent (g^a mod p)
			-- INTEGER encoded as payload of
			-- BIT STRING
			}
	Usage of EnvelopedData:		Usage of EnvelopedData:
	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 IETF.		Message Syntax, a product of the S/MIME working group of the IETF.
	It contains an temporary key encrypted with the PKINIT		It contains an 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.
	- The originatorInfo field is not required, since that information		- The originatorInfo field is not required, since that information
	may be presented in the signedData structure that is encrypted		may be presented in the signedData structure that is encrypted
	within the encryptedContentInfo field.		within the encryptedContentInfo field.
	- The optional unprotectedAttrs field is not required for PKINIT.		- The optional unprotectedAttrs field is not required for PKINIT.
	skipping to change at line 621 ¶		skipping to change at line 684 ¶
	- The certificates field must contain the certificates necessary		- The certificates field must contain the certificates necessary
	for the client to establish trust in the KDC's certificate		for the client to establish trust in the KDC's certificate
	based on the list of trusted certifiers sent by the client in		based on the list of trusted certifiers sent by the client in
	the PA-PK-AS-REQ. This field may be empty if the client did		the PA-PK-AS-REQ. This field may be empty if the client did
	not send to the KDC a list of trusted certifiers (the		not send to the KDC a list of trusted certifiers (the
	trustedCertifiers field was empty, meaning that the client		trustedCertifiers field was empty, meaning that the client
	already possesses the KDC's certificate).		already possesses the KDC's certificate).
	- The signerInfos field is a SET that must contain at least one		- The signerInfos field is a SET that must contain at least one
	member, since it contains the actual signature.		member, since it contains the actual signature.
	KdcDHKeyInfo ::= SEQUENCE {
	-- used only when utilizing Diffie-Hellman
	nonce [0] INTEGER,
	-- binds responce to the request
	subjectPublicKey [2] BIT STRING
	-- Equals public exponent (g^a mod p)
	-- INTEGER encoded as payload of
	-- BIT STRING
	}
	ReplyKeyPack ::= SEQUENCE {		ReplyKeyPack ::= SEQUENCE {
	-- not used for Diffie-Hellman		-- not used for Diffie-Hellman
	replyKey [0] EncryptionKey,		replyKey [0] EncryptionKey,
	-- used to encrypt main reply		-- used to encrypt main reply
	-- ENCTYPE is at least as strong as		-- ENCTYPE is at least as strong as
	-- ENCTYPE of session key		-- ENCTYPE of session key
	nonce [1] INTEGER,		nonce [1] INTEGER,
	-- binds response to the request		-- binds response to the request
	-- must be same as the nonce		-- must be same as the nonce
	-- passed in the PKAuthenticator		-- passed in the PKAuthenticator
	}		}
	Since each certifier in the certification path of a user's		Since each certifier in the certification path of a user's
	certificate is essentially a separate realm, the name of each		certificate is equivalent to a separate Kerberos realm, the name
	certifier must be added to the transited field of the ticket. The		of each certifier in the certificate chain must be added to the
	format of these realm names is defined in Section 3.1 of this		transited field of the ticket. The format of these realm names is
	document. If applicable, the transit-policy-checked flag should be		defined in Section 3.1 of this document. If applicable, the
	set in the issued ticket.		transit-policy-checked flag should be set in the issued ticket.
	The KDC's certificate must bind the public key to a name derivable		The KDC's certificate(s) must bind the public key(s) of the KDC to
	from the name of the realm for that KDC. X.509 certificates shall		a name derivable from the name of the realm for that KDC. X.509
	contain the principal name of the KDC as the SubjectAltName version		certificates shall contain the principal name of the KDC
	3 extension. Below is the definition of this version 3 extension, as		(defined in section 8.2 of RFC 1510) as the SubjectAltName version
	specified by the X.509 standard:		3 extension. Below is the definition of this version 3 extension,
			as specified by the X.509 standard:
	subjectAltName EXTENSION ::= {		subjectAltName EXTENSION ::= {
	SYNTAX GeneralNames		SYNTAX GeneralNames
	IDENTIFIED BY id-ce-subjectAltName		IDENTIFIED BY id-ce-subjectAltName
	}		}
	GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName		GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
	GeneralName ::= CHOICE {		GeneralName ::= CHOICE {
	otherName [0] INSTANCE OF OTHER-NAME,		otherName [0] INSTANCE OF OTHER-NAME,
	skipping to change at line 677 ¶		skipping to change at line 731 ¶
	OTHER-NAME ::= TYPE-IDENTIFIER		OTHER-NAME ::= TYPE-IDENTIFIER
	In this definition, otherName is a name of any form defined as an		In this definition, otherName is a name of any form defined as an
	instance of the OTHER-NAME information object class. For the purpose		instance of the OTHER-NAME information object class. For the purpose
	of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will		of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
	be chosen and replaced by the type KerberosName:		be chosen and replaced by the type KerberosName:
	KerberosName ::= SEQUENCE {		KerberosName ::= SEQUENCE {
	realm [0] Realm,		realm [0] Realm,
	-- as define in RFC 1510		-- as defined in RFC 1510
	principalName [1] PrincipalName,		principalName [1] PrincipalName,
	-- as define in RFC 1510		-- as defined in RFC 1510
	}		}
	This specific syntax is identified within subjectAltName by setting		This specific syntax is identified within subjectAltName by setting
	the OID id-ce-subjectAltName to krb5PrincipalName, where (from the		the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
	Kerberos specification) we have		Kerberos specification) we have
	krb5 OBJECT IDENTIFIER ::= { iso (1)		krb5 OBJECT IDENTIFIER ::= { iso (1)
	org (3)		org (3)
	dod (6)		dod (6)
	internet (1)		internet (1)
	security (5)		security (5)
	kerberosv5 (2) }		kerberosv5 (2) }
	krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }		krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
	This specification may also be used to specify a Kerberos name		(This specification may also be used to specify a Kerberos name
	within the user's certificate.		within the user's certificate.) The KDC's certificate may be signed
			directly by a CA, or there may be intermediaries if the server resides
	If a non-KDC X.509 certificate contains the principal name within		within a large organization, or it may be unsigned if the client
	the subjectAltName version 3 extension , that name may utilize		indicates possession (and trust) of the KDC's certificate.
	KerberosName as defined below, or, in the case of an S/MIME
	certificate [17], may utilize the email address. If the KDC
	is presented with as S/MIME certificate, then the email address
	within subjectAltName will be interpreted as a principal and realm
	separated by the "@" sign, or as a name that needs to be
	canonicalized. If the resulting name does not correspond to a
	registered principal name, then the principal name is formed as
	defined in section 3.1.
	The client then extracts the random key used to encrypt the main		The client then extracts the random key used to encrypt the main
	reply. This random key (in encPaReply) is encrypted with either the		reply. This random key (in encPaReply) is encrypted with either the
	client's public key or with a key derived from the DH values		client's public key or with a key derived from the DH values
	exchanged between the client and the KDC.		exchanged between the client and the KDC. The client uses this
			random key to decrypt the main reply, and subsequently proceeds as
			described in RFC 1510.
	3.2.2. Required Algorithms		3.2.3. Required Algorithms
	Not all of the algorithms in the PKINIT protocol specification have		Not all of the algorithms in the PKINIT protocol specification have
	to be implemented in order to comply with the proposed standard.		to be implemented in order to comply with the proposed standard.
	Below is a list of the required algorithms:		Below is a list of the required algorithms:
	- Diffie-Hellman public/private key pairs		- Diffie-Hellman public/private key pairs
	- utilizing Diffie-Hellman ephemeral-ephemeral mode		- utilizing Diffie-Hellman ephemeral-ephemeral mode
	- SHA1 digest and DSA for signatures		- SHA1 digest and DSA for signatures
	- 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
	skipping to change at line 823 ¶		skipping to change at line 871 ¶
	[9] B.C. Neuman, Proxy-Based Authorization and Accounting for		[9] B.C. Neuman, Proxy-Based Authorization and Accounting for
	Distributed Systems. In Proceedings of the 13th International		Distributed Systems. In Proceedings of the 13th International
	Conference on Distributed Computing Systems, May 1993.		Conference on Distributed Computing Systems, May 1993.
	[10] ITU-T (formerly CCITT) Information technology - Open Systems		[10] ITU-T (formerly CCITT) Information technology - Open Systems
	Interconnection - The Directory: Authentication Framework		Interconnection - The Directory: Authentication Framework
	Recommendation X.509 ISO/IEC 9594-8		Recommendation X.509 ISO/IEC 9594-8
	[11] R. Housley. Cryptographic Message Syntax.		[11] R. Housley. Cryptographic Message Syntax.
	draft-ietf-smime-cms-13.txt, April 1999.		draft-ietf-smime-cms-13.txt, April 1999, approved for publication
			as RFC.
	[12] PKCS #7: Cryptographic Message Syntax Standard,		[12] PKCS #7: Cryptographic Message Syntax Standard,
	An RSA Laboratories Technical Note Version 1.5		An RSA Laboratories Technical Note Version 1.5
	Revised November 1, 1993		Revised November 1, 1993
	[13] R. Rivest, MIT Laboratory for Computer Science and RSA Data		[13] 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.		March 1998.
	Request for Comments 2268.		Request for Comments 2268.
	[14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access		[14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
	Protocol (v3): UTF-8 String Representation of Distinguished Names.		Protocol (v3): UTF-8 String Representation of Distinguished Names.
	Request for Comments 2253.		Request for Comments 2253.
	[15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public		[15] 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, January 1999.
	Request for Comments 2459.		Request for Comments 2459.
	[16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography		[16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
	Specifications, October 1998.		Specifications, October 1998. Request for Comments 2437.
	Request for Comments 2437.
	[17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.		[17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME
	S/MIME Version 2 Certificate Handling, March 1998.		Version 2 Certificate Handling, March 1998. Request for
	Request for Comments 2312		Comments 2312.
			[18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access
			Protocol (v3), December 1997. Request for Comments 2251.
	8. Acknowledgements		8. Acknowledgements
	Some of the ideas on which this proposal is based arose during		Some of the ideas on which this proposal is based arose during
	discussions over several years between members of the SAAG, the IETF		discussions over several years between members of the SAAG, the IETF
	CAT working group, and the PSRG, regarding integration of Kerberos		CAT working group, and the PSRG, regarding integration of Kerberos
	and SPX. Some ideas have also been drawn from the DASS system.		and SPX. Some ideas have also been drawn from the DASS system.
	These changes are by no means endorsed by these groups. This is an		These changes are by no means endorsed by these groups. This is an
	attempt to revive some of the goals of those groups, and this		attempt to revive some of the goals of those groups, and this
	proposal approaches those goals primarily from the Kerberos		proposal approaches those goals primarily from the Kerberos
	perspective. Lastly, comments from groups working on similar ideas		perspective. Lastly, comments from groups working on similar ideas
	in DCE have been invaluable.		in DCE have been invaluable.
	9. Expiration Date		9. Expiration Date
	This draft expires December 1, 1999.		This draft expires April 30, 2000.
	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
End of changes. 43 change blocks.
	121 lines changed or deleted		172 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/