< draft-ietf-cat-kerberos-pk-init-12.txt		draft-ietf-cat-kerberos-pk-init-13.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-12.txt Clifford Neuman		draft-ietf-cat-kerberos-pk-init-13.txt Clifford Neuman
	Updates: RFC 1510 USC/ISI		Updates: RFC 1510 USC/ISI
	expires January 15, 2001 Matthew Hur		expires August 31, 2001 Matthew Hur
	CyberSafe Corporation		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
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial Authentication in Kerberos
	skipping to change at line 44 ¶		skipping to change at line 44 ¶
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	To learn the current status of any Internet-Draft, please check		To learn the current status of any Internet-Draft, please check
	the "1id-abstracts.txt" listing contained in the Internet-Drafts		the "1id-abstracts.txt" listing contained in the Internet-Drafts
	Shadow Directories on ftp.ietf.org (US East Coast),		Shadow Directories on ftp.ietf.org (US East Coast),
	nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or		nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
	munnari.oz.au (Pacific Rim).		munnari.oz.au (Pacific Rim).
	The distribution of this memo is unlimited. It is filed as		The distribution of this memo is unlimited. It is filed as
	draft-ietf-cat-kerberos-pk-init-11.txt, and expires January 15,		draft-ietf-cat-kerberos-pk-init-11.txt, and expires August 31,
	2001. Please send comments to the authors.		2001. Please send comments to the authors.
	1. Abstract		1. Abstract
	This document defines extensions (PKINIT) to the Kerberos protocol		This document defines extensions (PKINIT) to the Kerberos protocol
	specification (RFC 1510 [1]) to provide a method for using public		specification (RFC 1510 [1]) to provide a method for using public
	key cryptography during initial authentication. The methods		key cryptography during initial authentication. The methods
	defined specify the ways in which preauthentication data fields and		defined specify the ways in which preauthentication data fields and
	error data fields in Kerberos messages are to be used to transport		error data fields in Kerberos messages are to be used to transport
	public key data.		public key data.
	skipping to change at line 72 ¶		skipping to change at line 72 ¶
	public key certification infrastructures.		public key certification infrastructures.
	Public key cryptography can be integrated into Kerberos in a number		Public key cryptography can be integrated into Kerberos in a number
	of ways. One is to associate a key pair with each realm, which can		of ways. One is to associate a key pair with each realm, which can
	then be used to facilitate cross-realm authentication; this is the		then be used to facilitate cross-realm authentication; this is the
	topic of another draft proposal. Another way is to allow users with		topic of another draft proposal. Another way is to allow users with
	public key certificates to use them in initial authentication. This		public key certificates to use them in initial authentication. This
	is the concern of the current document.		is the concern of the current document.
	PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in		PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
	combination with digital signature keys as the primary, required		combination with DSA keys as the primary, required mechanism. Note
	mechanism. It also allows for the use of RSA keys and/or (static)		that PKINIT supports the use of separate signature and encryption
	Diffie-Hellman certificates. Note in particular that PKINIT supports		keys.
	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 an AS-REQ message to the KDC as before, except that if that		user sends an AS-REQ message to the KDC as before, except that if that
	user is to use public key cryptography in the initial authentication		user is to use public key cryptography in the initial authentication
	step, his certificate and a signature accompany the initial request		step, his certificate and a signature accompany the initial request
	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		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		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		record. In this scenario, the KDC is the trusted party that vouches
	for the principal (as in a standard, non-cross realm, Kerberos		for the principal (as in a standard, non-cross realm, Kerberos
	environment). Thus, for any principal, the KDC may maintain a		environment). Thus, for any principal, the KDC may maintain a
	secret key, a public key, or both.		symmetric 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. PKINIT may be utilized to establish
	the inter-realm key and associated inter-realm policy to be applied		inter-realm keys for the purposes of issuing cross-realm service
	in issuing cross realm service tickets. As specified in [4],		tickets. It may also be used to issue anonymous Kerberos tickets
	anonymous Kerberos tickets can be issued by applying a NULL		using the Diffie-Hellman option. Efforts are under way to draft
	signature in combination with Diffie-Hellman in the PKINIT exchange.		specifications for these two application protocols.
	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
	authentication, the client uses PKINIT to authenticate to the end		authentication, the client uses PKINIT to authenticate to the end
	server (instead of a central KDC), which then issues a ticket for		server (instead of a central KDC), which then issues a ticket for
	itself. This approach has an advantage over TLS [8] in that the		itself. This approach has an advantage over TLS [8] in that the
	server does not need to save state (cache session keys).		server does not need to save state (cache session keys).
	Furthermore, an additional benefit is that Kerberos tickets can		Furthermore, an additional benefit is that Kerberos tickets can
	facilitate delegation (see [9]).		facilitate delegation (see [9]).
	skipping to change at line 184 ¶		skipping to change at line 184 ¶
	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 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 RFC1510.		name as specified in the naming constraints section of RFC1510.
	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 [14] (part of LDAPv3 [18]).		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, 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 shall 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 1510 as:		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:		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 shall 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.
	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 as a Kerberos name for		The following rules relate to the the matching of PrincipalNames
	use in Kerberos structures, the name-string shall be encoded as a		with regard to the PKI name constraints for CAs as laid out in RFC
	single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL,		2459 [15]. In order to be regarded as a match (for permitted and
	as noted above. All Kerberos names must conform to validity		excluded name trees), the following MUST be satisfied.
	requirements as given in RFC 1510. Note that name mapping may be
	required or optional, based on policy.
	We also define the following similar ASN.1 structure:
	CertPrincipalName ::= SEQUENCE {
	name-type[0] INTEGER,
	name-string[1] SEQUENCE OF UTF8String
	}
	When a Kerberos PrincipalName is to be placed within an X.509 data
	structure, the CertPrincipalName structure is to be used, with the
	name-string encoded as a single UTF8String. The name-type should be
	as identified in the original PrincipalName structure. The mapping
	between the GeneralString and UTF8String formats can be found in
	[19].
	The following rules relate to the the matching of PrincipalNames (or
	corresponding CertPrincipalNames) with regard to the PKI name
	constraints for CAs as laid out in RFC 2459 [15]. In order to be
	regarded as a match (for permitted and excluded name trees), the
	following must be satisfied.
	1. If the constraint is given as a user plus realm name, or		1. If the constraint is given as a user plus realm name, or
	as a user plus instance plus realm name (as specified in		as a client principal name plus realm name (as specified in
	RFC 1510), the realm name must be valid (see 2.a-d below)		RFC 1510), the realm name MUST be valid (see 2.a-d below)
	and the match must be exact, byte for byte.		and the match MUST be exact, byte for byte.
	2. If the constraint is given only as a realm name, matching		2. If the constraint is given only as a realm name, matching
	depends on the type of the realm:		depends on the type of the realm:
	a. If the realm contains a colon (':') before any equal		a. If the realm contains a colon (':') before any equal
	sign ('='), it is treated as a realm of type Other,		sign ('='), it is treated as a realm of type Other,
	and must match exactly, byte for byte.		and MUST match exactly, byte for byte.
	b. Otherwise, if the realm contains an equal sign, it
	is treated as an X.500 name. In order to match, every
	component in the constraint MUST be in the principal
	name, and have the same value. For example, 'C=US'
	matches 'C=US/O=ISI' but not 'C=UK'.
	c. Otherwise, if the realm name conforms to rules regarding		b. Otherwise, if the realm name conforms to rules regarding
	the format of DNS names, it is considered a realm name of		the format of DNS names, it is considered a realm name of
	type Domain. The constraint may be given as a realm		type Domain. The constraint may be given as a realm
	name 'FOO.BAR', which matches any PrincipalName within		name 'FOO.BAR', which matches any PrincipalName within
	the realm 'FOO.BAR' but not those in subrealms such as		the realm 'FOO.BAR' but not those in subrealms such as
	'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR'		'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR'
	matches PrincipalNames in subrealms of the form		matches PrincipalNames in subrealms of the form
	'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.		'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
	d. Otherwise, the realm name is invalid and does not match		c. Otherwise, the realm name is invalid and does not match
	under any conditions.		under any conditions.
	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 for RSA		not preclude the assignment of bitwise identical keys for RSA
	keys.		keys.
	In the case of Diffie-Hellman, the key shall be produced from the		In the case of Diffie-Hellman, the key is produced from the agreed
	agreed bit string as follows:		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.
	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 [11] and		The following signature algorithm identifiers specified in [11] and
	in [15] shall be used with PKINIT:		in [15] are used with PKINIT:
	id-dsa-with-sha1 (DSA with SHA1)		id-dsa-with-sha1 (DSA with SHA1)
	md5WithRSAEncryption (RSA with MD5)		md5WithRSAEncryption (RSA with MD5)
	sha-1WithRSAEncryption (RSA with SHA1)		sha-1WithRSAEncryption (RSA with SHA1)
	3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier		3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
	The following algorithm identifier shall be used within the		The following algorithm identifier shall be used within the
	SubjectPublicKeyInfo data structure: dhpublicnumber		SubjectPublicKeyInfo data structure: dhpublicnumber
	skipping to change at line 422 ¶		skipping to change at line 394 ¶
	-- 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		Message Syntax, a product of the S/MIME working group of the
	IETF. The following describes how to fill in the fields of		IETF. The following describes how to fill in the fields of
	this data:		this data:
	1. The encapContentInfo field must contain the PKAuthenticator		1. The encapContentInfo field MUST contain the PKAuthenticator
	and, optionally, the client's Diffie Hellman public value.		and, optionally, the client's Diffie Hellman public value.
	a. The eContentType field shall contain the OID value for		a. The eContentType field 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)
	b. The eContent field is data of the type AuthPack (below).		b. The eContent field is data of the type AuthPack (below).
	2. The signerInfos field contains the signature of AuthPack.		2. The signerInfos field contains the signature of AuthPack.
	3. The Certificates field, when non-empty, contains the client's		3. The Certificates field, when non-empty, contains the client's
	certificate chain. If present, the KDC uses the public key		certificate chain. If present, the KDC uses the public key
	from the client's certificate to verify the signature in the		from the client's certificate to verify the signature in the
	skipping to change at line 447 ¶		skipping to change at line 419 ¶
	chains that are used for signing or for encrypting. Thus,		chains that are used for signing or for encrypting. Thus,
	the KDC may utilize a different client certificate for		the KDC may utilize a different client certificate for
	signature verification than the one it uses to encrypt the		signature verification than the one it uses to encrypt the
	reply to the client. For example, the client may place a		reply to the client. For example, the client may place a
	Diffie-Hellman certificate in this field in order to convey		Diffie-Hellman certificate in this field in order to convey
	its static Diffie Hellman certificate to the KDC to enable		its static Diffie Hellman certificate to the KDC to enable
	static-ephemeral Diffie-Hellman mode for the reply; in this		static-ephemeral Diffie-Hellman mode for the reply; in this
	case, the client does NOT place its public value in the		case, the client does NOT place its public value in the
	AuthPack (defined below). As another example, the client may		AuthPack (defined below). As another example, the client may
	place an RSA encryption certificate in this field. However,		place an RSA encryption certificate in this field. However,
	there must always be (at least) a signature certificate.		there MUST always be (at least) a signature certificate.
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
	-- if client is using Diffie-Hellman		-- if client is using Diffie-Hellman
	-- (ephemeral-ephemeral only)		-- (ephemeral-ephemeral only)
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	cusec [0] INTEGER,		cusec [0] INTEGER,
	skipping to change at line 527 ¶		skipping to change at line 499 ¶
	bind the pre-authentication data to the KDC-REQ-BODY, and to bind the		bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
	request and response. The PKAuthenticator is signed with the client's		request and response. The PKAuthenticator is signed with the client's
	signature key.		signature key.
	3.2.2. KDC Response		3.2.2. KDC Response
	Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication		Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
	type, the KDC attempts to verify the user's certificate chain		type, the KDC attempts to verify the 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.
	hierarchy, or it may be simply a list of recognized certifiers in a
	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
	skipping to change at line 625 ¶		skipping to change at line 595 ¶
	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 the SubjectAltName extention		2. If the certificate contains the SubjectAltName extention
	and the local KDC policy defines a mapping from the		and the local KDC policy defines a mapping from the
	SubjectAltName to a Kerberos name, then use that name.		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
	mapping as necessary (e.g., as per RFC 2253 for X.500		as necessary (e.g., as per RFC 2253 for X.500 names). In
	names). In this case the realm in the ticket shall be the		this case the realm in the ticket MUST be the name of the
	name of the certifier that issued the user's certificate.		certifier that issued the user's certificate.
	Note that a principal name may be carried in the subject alt name		Note that a principal name may be carried in the subjectAltName
	field of a certificate. This name may be mapped to a principal		field of a certificate. This name may be mapped to a principal
	record in a security database based on local policy, for example		record in a security database based on local policy, for example
	the subject alt name may be kerberos/principal@realm format. In		the subjectAltName may be kerberos/principal@realm format. In
	this case the realm name is not that of the CA but that of the		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		local realm doing the mapping (or some realm name chosen by that
	realm).		realm).
	If a non-KDC X.509 certificate contains the principal name within		If a non-KDC X.509 certificate contains the principal name within
	the subjectAltName version 3 extension , that name may utilize		the subjectAltName version 3 extension, that name may utilize
	KerberosName as defined below, or, in the case of an S/MIME		KerberosName as defined below, or, in the case of an S/MIME
	certificate [17], may utilize the email address. If the KDC		certificate [17], may utilize the email address. If the KDC
	is presented with an S/MIME certificate, then the email address		is presented with an S/MIME certificate, then the email address
	within subjectAltName will be interpreted as a principal and realm		within subjectAltName will be interpreted as a principal and realm
	separated by the "@" sign, or as a name that needs to be		separated by the "@" sign, or as a name that needs to be mapped
	canonicalized. If the resulting name does not correspond to a		according to local policy. If the resulting name does not correspond
	registered principal name, then the principal name is formed as		to a registered principal name, then the principal name is formed as
	defined in section 3.1.		defined in section 3.1.
	The trustedCertifiers field contains a list of certification		The trustedCertifiers field contains a list of certification
	authorities trusted by the client, in the case that the client does		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		not possess the KDC's public key certificate. If the KDC has no
	certificate signed by any of the trustedCertifiers, then it returns		certificate signed by any of the trustedCertifiers, then it returns
	an error of type KDC_ERR_KDC_NOT_TRUSTED.		an error of type KDC_ERR_KDC_NOT_TRUSTED.
	KDCs should try to (in order of preference):		KDCs should try to (in order of preference):
	1. Use the KDC certificate identified by the serialNumber included		1. Use the KDC certificate identified by the serialNumber included
	in the client's request.		in the client's request.
	2. Use a certificate issued to the KDC by the client's CA (if in the		2. Use a certificate issued to the KDC by one of the client's
	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);		trustedCertifier(s);
	If the KDC is unable to comply with any of these options, then the		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		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.
	skipping to change at line 705 ¶		skipping to change at line 672 ¶
	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.
	2. Both the KDC and the client take the first N bits of this		2. Both the KDC and the client take the first N bits of this
	secret value and convert it into a reply key. N depends on		secret value and convert it into a reply key. N depends on
	the reply key type.		the reply key type.
	3. If the reply key is DES, N=64 bits, where some of the bits		a. For example, if the reply key is DES, N=64 bits, where
	are replaced with parity bits, according to FIPS PUB 74.		some of the bits are replaced with parity bits, according
			to FIPS PUB 74.
	4. If the reply key is (3-key) 3-DES, N=192 bits, where some		b. As another example, if the reply key is (3-key) 3-DES,
	of the bits are replaced with parity bits, according to		N=192 bits, where some of the bits are replaced with
	FIPS PUB 74.		parity bits, according to FIPS PUB 74.
	5. The encapContentInfo field must contain the KdcDHKeyInfo as		3. The encapContentInfo field MUST contain the KdcDHKeyInfo as
	defined below.		defined below.
	a. The eContentType field shall contain the OID value for		a. The eContentType field MUST contain the OID value for
	pkdhkeydata: iso (1) org (3) dod (6) internet (1)		pkdhkeydata: iso (1) org (3) dod (6) internet (1)
	security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)		security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
	b. The eContent field is data of the type KdcDHKeyInfo		b. The eContent field is data of the type KdcDHKeyInfo
	(below).		(below).
	6. The certificates field must contain the certificates		4. The certificates field MUST contain the certificates
	necessary for the client to establish trust in the KDC's		necessary for the client to establish trust in the KDC's
	certificate based on the list of trusted certifiers sent by		certificate based on the list of trusted certifiers sent by
	the client in the PA-PK-AS-REQ. This field may be empty if		the client in the PA-PK-AS-REQ. This field may be empty if
	the client did not send to the KDC a list of trusted		the client did not send to the KDC a list of trusted
	certifiers (the trustedCertifiers field was empty, meaning		certifiers (the trustedCertifiers field was empty, meaning
	that the client already possesses the KDC's certificate).		that the client already possesses the KDC's certificate).
	7. The signerInfos field is a SET that must contain at least		5. The signerInfos field is a SET that MUST contain at least
	one member, since it contains the actual signature.		one member, since it contains the actual signature.
	KdcDHKeyInfo ::= SEQUENCE {		KdcDHKeyInfo ::= SEQUENCE {
	-- used only when utilizing Diffie-Hellman		-- used only when utilizing Diffie-Hellman
	nonce [0] INTEGER,		nonce [0] INTEGER,
	-- binds responce to the request		-- binds responce to the request
	subjectPublicKey [2] BIT STRING		subjectPublicKey [2] BIT STRING
	-- Equals public exponent (g^a mod p)		-- Equals public exponent (g^a mod p)
	-- INTEGER encoded as payload of		-- INTEGER encoded as payload of
	-- BIT STRING		-- BIT STRING
	skipping to change at line 758 ¶		skipping to change at line 726 ¶
	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.
	2. The optional unprotectedAttrs field is not required for		2. The optional unprotectedAttrs field is not required for
	PKINIT.		PKINIT.
	3. The recipientInfos field is a SET which must contain exactly		3. The recipientInfos field is a SET which MUST contain exactly
	one member of the KeyTransRecipientInfo type for encryption		one member of the KeyTransRecipientInfo type for encryption
	with an RSA public key.		with a public key.
	a. The encryptedKey field (in KeyTransRecipientInfo)		a. The encryptedKey field (in KeyTransRecipientInfo)
	contains the temporary key which is encrypted with the		contains the temporary key which is encrypted with the
	PKINIT client's public key.		PKINIT client's public key.
	4. The encryptedContentInfo field contains the signed and		4. The encryptedContentInfo field contains the signed and
	encrypted reply key.		encrypted reply key.
	a. The contentType field shall contain the OID value for		a. The contentType field MUST contain the OID value for
	id-signedData: iso (1) member-body (2) us (840)		id-signedData: iso (1) member-body (2) us (840)
	rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)		rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
	b. The encryptedContent field is encrypted data of the CMS		b. The encryptedContent field is encrypted data of the CMS
	type signedData as specified below.		type signedData as specified below.
	i. The encapContentInfo field must contains the		i. The encapContentInfo field MUST contains the
	ReplyKeyPack.		ReplyKeyPack.
	* The eContentType field shall contain the OID value		* The eContentType field MUST contain the OID value
	for pkrkeydata: iso (1) org (3) dod (6) internet (1)		for 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)
	* The eContent field is data of the type ReplyKeyPack		* The eContent field is data of the type ReplyKeyPack
	(below).		(below).
	ii. The certificates field must contain the certificates		ii. The certificates field MUST contain the certificates
	necessary for the client to establish trust in the		necessary for the client to establish trust in the
	KDC's certificate based on the list of trusted		KDC's certificate based on the list of trusted
	certifiers sent by the client in the PA-PK-AS-REQ.		certifiers sent by the client in the PA-PK-AS-REQ.
	This field may be empty if the client did not send		This field may be empty if the client did not send
	to the KDC a list of trusted certifiers (the		to the KDC a list of trusted certifiers (the
	trustedCertifiers field was empty, meaning that the		trustedCertifiers field was empty, meaning that the
	client already possesses the KDC's certificate).		client already possesses the KDC's certificate).
	iii. The signerInfos field is a SET that must contain at		iii. The signerInfos field is a SET that MUST contain at
	least one member, since it contains the actual		least one member, since it contains the actual
	signature.		signature.
	ReplyKeyPack ::= SEQUENCE {		ReplyKeyPack ::= SEQUENCE {
	-- not used for Diffie-Hellman		-- not used for Diffie-Hellman
	replyKey [0] EncryptionKey,		replyKey [0] EncryptionKey,
			-- from RFC 1510bis
	-- 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
	}		}
			3.2.2.1. Use of transited Field
	Since each certifier in the certification path of a user's		Since each certifier in the certification path of a user's
	certificate is equivalent to a separate Kerberos realm, the name		certificate is equivalent to a separate Kerberos realm, the name
	of each certifier in the certificate chain must be added to the		of each certifier in the certificate chain MUST be added to the
	transited field of the ticket. The format of these realm names is		transited field of the ticket. The format of these realm names is
	defined in Section 3.1 of this document. If applicable, the		defined in Section 3.1 of this document. If applicable, the
	transit-policy-checked flag should be set in the issued ticket.		transit-policy-checked flag should be set in the issued ticket.
	The KDC's certificate(s) must bind the public key(s) of the KDC to		3.2.2.2. Kerberos Names in Certificates
			The KDC's certificate(s) MUST bind the public key(s) of the KDC to
	a name derivable from the name of the realm for that KDC. X.509		a name derivable from the name of the realm for that KDC. X.509
	certificates shall contain the principal name of the KDC		certificates MUST contain the principal name of the KDC
	(defined in section 8.2 of RFC 1510) as the SubjectAltName version		(defined in section 8.2 of RFC 1510) as the SubjectAltName version
	3 extension. Below is the definition of this version 3 extension,		3 extension. Below is the definition of this version 3 extension,
	as specified by the X.509 standard:		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
	skipping to change at line 843 ¶		skipping to change at line 816 ¶
	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 shall be a KerberosName as defined in RFC 1510, but with		in OtherName MUST be a KerberosName as defined in RFC 1510:
	the PrincipalName replaced by CertPrincipalName as mentioned in
	Section 3.1:
	KerberosName ::= SEQUENCE {		KerberosName ::= SEQUENCE {
	realm [0] Realm,		realm [0] Realm,
	principalName [1] CertPrincipalName -- defined above		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
	krb5 OBJECT IDENTIFIER ::= { iso (1)		krb5 OBJECT IDENTIFIER ::= { iso (1)
	org (3)		org (3)
	dod (6)		dod (6)
	internet (1)		internet (1)
	skipping to change at line 871 ¶		skipping to change at line 842 ¶
	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.) The KDC's certificate may be signed		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		directly by a CA, or there may be intermediaries if the server resides
	within a large organization, or it may be unsigned if the client		within a large organization, or it may be unsigned if the client
	indicates possession (and trust) of the KDC's certificate.		indicates possession (and trust) of the KDC's certificate.
			Note that the KDC's principal name has the instance equal to the
			realm, and those fields should be appropriately set in the realm
			and principalName fields of the KerberosName. This is the case
			even when obtaining a cross-realm ticket using PKINIT.
			3.2.3. Client Extraction of Reply
	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. The client uses this		exchanged between the client and the KDC. The client uses this
	random key to decrypt the main reply, and subsequently proceeds as		random key to decrypt the main reply, and subsequently proceeds as
	described in RFC 1510.		described in RFC 1510.
	3.2.3. 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 also for the Checksum in the PKAuthenticator
	* 3-key triple DES keys derived from the Diffie-Hellman Exchange		* 3-key triple DES keys derived from the Diffie-Hellman Exchange
	skipping to change at line 1038 ¶		skipping to change at line 1016 ¶
	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, 2001.		This draft expires August 31, 2001.
	10. Authors		10. Authors
	Brian Tung		Brian Tung
	Clifford Neuman		Clifford Neuman
	USC Information Sciences Institute		USC Information Sciences Institute
	4676 Admiralty Way Suite 1001		4676 Admiralty Way Suite 1001
	Marina del Rey CA 90292-6695		Marina del Rey CA 90292-6695
	Phone: +1 310 822 1511		Phone: +1 310 822 1511
	E-mail: {brian, bcn}@isi.edu		E-mail: {brian, bcn}@isi.edu
	Matthew Hur		Matthew Hur
	CyberSafe Corporation		Cisco Systems
	1605 NW Sammamish Road		500 108th Ave. NE, Suite 500
	Issaquah WA 98027-5378		Bellevue, WA 98004
	Phone: +1 425 391 6000		Phone: (408) 525-0034
	E-mail: matt.hur@cybersafe.com		EMail: 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
	Motorola		Motorola
	skipping to change at line 1078 ¶		skipping to change at line 1056 ¶
	+1 858 404 2367		+1 858 404 2367
	E-mail: smedvinsky@gi.com		E-mail: smedvinsky@gi.com
	John Wray		John Wray
	Iris Associates, Inc.		Iris Associates, Inc.
	5 Technology Park Dr.		5 Technology Park Dr.
	Westford, MA 01886		Westford, MA 01886
	E-mail: John_Wray@iris.com		E-mail: John_Wray@iris.com
	Jonathan Trostle		Jonathan Trostle
			Cisco Systems
	170 W. Tasman Dr.		170 W. Tasman Dr.
	San Jose, CA 95134		San Jose, CA 95134
	E-mail: jtrostle@cisco.com		E-mail: jtrostle@cisco.com
End of changes. 55 change blocks.
	111 lines changed or deleted		90 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/