< draft-ietf-cat-kerberos-pk-init-08.txt		draft-ietf-cat-kerberos-pk-init-09.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-08.txt Clifford Neuman		draft-ietf-cat-kerberos-pk-init-09.txt Clifford Neuman
	Updates: RFC 1510 ISI		Updates: RFC 1510 ISI
	expires November 12, 1999 Matthew Hur		expires December 1, 1999 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 November 12,		draft-ietf-cat-kerberos-pk-init-09.txt, and expires December 1,
	1999. Please send comments to the authors.		1999. 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 134 ¶		skipping to change at line 134 ¶
	Section 3.2 describes the extensions for the initial authentication		Section 3.2 describes the extensions for the initial authentication
	method.		method.
	3.1. Definitions		3.1. Definitions
	The extensions involve new preauthentication fields; we introduce		The extensions involve new preauthentication fields; we introduce
	the following preauthentication types:		the following preauthentication types:
	PA-PK-AS-REQ 14		PA-PK-AS-REQ 14
	PA-PK-AS-REP 15		PA-PK-AS-REP 15
	PA-PK-KEY-REQ 18
	PA-PK-KEY-REP 19
	The extensions also involve new error types; we introduce the		The extensions also involve new error types; we introduce the
	following types:		following types:
	KDC_ERR_CLIENT_NOT_TRUSTED 62		KDC_ERR_CLIENT_NOT_TRUSTED 62
	KDC_ERR_KDC_NOT_TRUSTED 63		KDC_ERR_KDC_NOT_TRUSTED 63
	KDC_ERR_INVALID_SIG 64		KDC_ERR_INVALID_SIG 64
	KDC_ERR_KEY_TOO_WEAK 65		KDC_ERR_KEY_TOO_WEAK 65
	KDC_ERR_CERTIFICATE_MISMATCH 66		KDC_ERR_CERTIFICATE_MISMATCH 66
			KDC_ERR_CANT_VERIFY_CERTIFICATE 70
			KDC_ERR_INVALID_CERTIFICATE 71
			KDC_ERR_REVOKED_CERTIFICATE 72
			KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
			KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74
			KDC_ERR_CLIENT_NAME_MISMATCH 75
			KDC_ERR_KDC_NAME_MISMATCH 76
	We utilize the following typed data for errors:		We utilize the following typed data for errors:
	ETD-PKINIT-CMS-CERTIFICATES 101		TD-PKINIT-CMS-CERTIFICATES 101
	ETD-KRB-PRINCIPAL 102		TD-KRB-PRINCIPAL 102
	ETD-KRB-REALM 103		TD-KRB-REALM 103
			TD-TRUSTED-CERTIFIERS 104
			TD-CERTIFICATE-INDEX 105
	We utilize the following encryption types (which map directly to		We utilize the following encryption types (which map directly to
	OIDs):		OIDs):
	sha1WithRSAEncryption-CmsOID 8
	dsaWithSHA1-CmsOID 9		dsaWithSHA1-CmsOID 9
	md4WithRsaEncryption-CmsOID 10		md5WithRSAEncryption-CmsOID 10
	md5WithRSAEncryption-CmsOID 11		sha1WithRSAEncryption-CmsOID 11
	rc2CBC-EnvOID 12		rc2CBC-EnvOID 12
	rc4-EnvOID 13		rsaEncryption-EnvOID (PKCS#1 v1.5) 13
			rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14
			des-ede3-cbc-Env-OID 15
			These mappings are provided so that a client may send the
			appropriate enctypes in the AS-REQ message in order to indicate
			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 an X.500 name as a
	Realm. In these cases, the realm will be represented using a		Realm. In these cases, the realm will be represented using a
	different style, specified in RFC 1510 with the following example:		different style, specified in RFC 1510 with the following example:
	NAMETYPE:rest/of.name=without-restrictions		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)		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 ASCII encoding of an X.500 name, as defined by		readable UTF encoding of an X.500 name, as defined by
	RFC 2253 [14] (part of LDAPv3).		RFC 2253 [14] (part of LDAPv3).
	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
	skipping to change at line 201 ¶		skipping to change at line 214 ¶
	defined as:		defined 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.
	Note that name mapping may be required or optional based on policy.		RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
			PrincipalName ::= SEQUENCE {
			name-type[0] INTEGER,
			name-string[1] SEQUENCE OF GeneralString
			}
			For the purposes of encoding an X.500 name within this structure,
			the name-string shall be encoded as a single GeneralString.
			Note that name mapping may be required or optional based on
			policy.
	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.
	skipping to change at line 230 ¶		skipping to change at line 254 ¶
	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
	These are the algorithm identifiers for use in the Signature data		The following signature algorithm identifiers specified in [11] and
	structure as specified in CMS [11]:		in [15] shall be used with PKINIT:
	sha-1WithRSAEncryption ALGORITHM PARAMETER NULL
	::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs-1(1) 5 }
	dsaWithSHA1 ALGORITHM PARAMETER NULL
	::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
	oIWSecAlgorithm(2) dsaWithSHA1(27) }
	md4WithRsaEncryption ALGORITHM PARAMETER NULL
	::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
	oIWSecAlgorithm(2) md4WithRSAEncryption(4) }
	md5WithRSAEncryption ALGORITHM PARAMETER NULL		id-dsa-with-sha1 (DSA with SHA1)
	::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		md5WithRSAEncryption (RSA with MD5)
	pkcs-1(1) md5WithRSAEncryption(4) }		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
	This algorithm identifier is used inside the SubjectPublicKeyInfo		The following algorithm identifier shall be used within the
	data structure:		SubjectPublicKeyInfo data structure: dhpublicnumber
	dhKeyAgreement ALGORITHM PARAMETER DHParameters
	::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs-3(3) dhKeyAgreement(1) }
	DHParameters ::= SEQUENCE {		This identifier and the associated algorithm parameters are
	prime INTEGER,		specified in RFC 2459 [15].
	-- p
	base INTEGER,
	-- g
	privateValueLength INTEGER OPTIONAL
	} -- as specified by the X.509 recommendation [9]
	3.1.2.3. Algorithm Identifiers for RSA Encryption		3.1.2.3. Algorithm Identifiers for RSA Encryption
	These algorithm identifiers are used inside the EnvelopedData data		These algorithm identifiers are used inside the EnvelopedData data
	structure, for encrypting the temporary key with a public key:		structure, for encrypting the temporary key with a public key:
	id-RSAES-OAEP OBJECT IDENTIFIER		rsaEncryption (RSA encryption, PKCS#1 v1.5)
	::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
	pkcs-1(1) 7 }
			Both of the above RSA encryption schemes are specified in [16].
			Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
			CMS specification says that it will likely include PKCS#1 v2.0 in
			the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext
			vulnerability discovered in PKCS#1 v1.5.)
	3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys		3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
	These algorithm identifiers are used inside the EnvelopedData data		These algorithm identifiers are used inside the EnvelopedData data
	structure, for encrypting the temporary key with a Diffie-Hellman-		structure in the PKINIT Reply, for encrypting the reply key with the
	derived key, or for encrypting the reply key:		temporary key:
			des-ede3-cbc (3-key 3-DES, CBC mode)
	desCBC ALGORITHM PARAMETER IV8		rc2-cbc (RC2, CBC mode)
	::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
	oIWSecAlgorithm(2) desCBC(7) }
	DES-EDE3-CBC ALGORITHM PARAMETER IV8
	::= { iso(1) member-body(2) US(840) rsadsi(113549)
	encryptionAlgorithm(3) desEDE3(7) }
	IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector
	rc2CBC ALGORITHM PARAMETER RC2-CBCParameter
	::= { iso(1) member-body(2) US(840) rsadsi(113549)
	encryptionAlgorithm(3) rc2CBC(2) }
	The rc2CBC algorithm parameters (RC2-CBCParameter) are defined
	in the following section.
	rc4 ALGORITHM PARAMETER NULL
	::= { iso(1) member-body(2) US(840) rsadsi(113549)
	encryptionAlgorithm(3) rc4(4) }
	The rc4 algorithm cannot be used with the Diffie-Hellman-derived
	keys, because its parameters do not specify the size of the key.
	3.1.2.5. rc2CBC Algorithm Parameters
	This definition of the RC2 parameters is taken from a paper by
	Ron Rivest [13]. Refer to [13] for the complete description of the
	RC2 algorithm.
	RC2-CBCParameter ::= CHOICE {
	iv IV,
	params SEQUENCE {
	version RC2Version,
	iv IV
	}
	}
	where
	IV ::= OCTET STRING -- 8 octets
	RC2Version ::= INTEGER -- 1-1024
	RC2 in CBC mode has two parameters: an 8-byte initialization
	vector (IV) and a version number in the range 1-1024 which
	specifies in a roundabout manner the number of effective key bits
	to be used for the RC2 encryption/decryption.
	The correspondence between effective key bits and version number
	is as follows:
	1. If the number EKB of effective key bits is in the range 1-255,
	then the version number is given by Table[EKB], where the
	256-byte translation table is specified below. It specifies a
	permutation on the numbers 0-255.
	2. If the number EKB of effective key bits is in the range
	256-1024, then the version number is simply EKB.
	The default number of effective key bits for RC2 is 32.
	If RC2-CBC is being performed with 32 effective key bits, the
	parameters should be supplied as a simple IV, rather than as a
	SEQUENCE containing a version and an IV.
	0 1 2 3 4 5 6 7 8 9 a b c d e f
	00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0		The full definition of the above algorithm identifiers and their
	10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a		corresponding parameters (an IV for block chaining) is provided in
	20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36		the CMS specification [11].
	30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c
	40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60
	50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa
	60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e
	70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf
	80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6
	90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3
	a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c
	b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2
	c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5
	d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5
	e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f
	f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab
	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		It is assumed that all public keys are signed by some certification
	authority (CA). The initial authentication request is sent as per		authority (CA). The initial authentication request is sent as per
	RFC 1510, except that a preauthentication field containing data		RFC 1510, except that a preauthentication field containing data
	signed by the user's private key accompanies the request:		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 PrincipalName 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		-- must be accompanied by
	-- a single trustedCertifier		-- a single trustedCertifier
			encryptionCert [3] IssuerAndSerialNumber OPTIONAL
			-- For example, this may be the
			-- client's Diffie-Hellman
			-- certificate, or it may be the
			-- client's RSA encryption
			-- certificate.
			}
			TrustedCas ::= CHOICE {
			principalName [0] KerberosName,
			-- as defined below
			caName [1] Name
			-- fully qualified X.500 name
			-- as defined by X.509
			issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL
			-- Since a CA may have a number of
			-- certificates, only one of which
			-- 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.
	- The eContentType field shall contain the OID value for		- The eContentType field shall contain the OID value for
	id-data: iso(1) member-body(2) us(840) rsadsi(113549)		id-data: iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs7(7) data(1)		pkcs(1) pkcs7(7) data(1)
	- The eContent field is data of the type AuthPack (below).		- The eContent field is data of the type AuthPack (below).
	- The signerInfos field is a SET of SignerInfo that is required by		- The signerInfos field contains the signature of AuthPack.
	CMS; however, the set may contain zero elements. When non-empty,		- The Certificates field, when non-empty, contains the client's
	this field contains the client's certificate chain. If present,		certificate chain. If present, the KDC uses the public key from
	the KDC uses the public key from the client's certificate to		the client's certificate to verify the signature in the request.
	verify the signature in the request. Note that the client may		Note that the client may pass different certificates that are used
	pass different certificates that are used for signing or for		for signing or for encrypting. Thus, the KDC may utilize a
	encrypting. Thus, the KDC may utilize a different client		different client certificate for signature verification than the
	certificate for signature verification than the one it uses to		one it uses to encrypt the reply to the client. For example, the
	encrypt the reply to the client.		client may place a Diffie-Hellman certificate in this field in
			order to convey its static Diffie Hellman certificate to the KDC
			enable static-ephemeral Diffie-Hellman mode for the reply. As
			another example, the client may place an RSA encryption
			certificate in this field.
	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
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	kdcName [0] PrincipalName,		kdcName [0] PrincipalName,
	kdcRealm [1] Realm,		kdcRealm [1] Realm,
	skipping to change at line 433 ¶		skipping to change at line 386 ¶
	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)
	} -- as specified by the X.509 recommendation [9]		} -- as specified by the X.509 recommendation [10]
	AlgorithmIdentifier ::= SEQUENCE {		AlgorithmIdentifier ::= SEQUENCE {
	algorithm ALGORITHM.&id,		algorithm ALGORITHM.&id,
	parameters ALGORITHM.&type		parameters ALGORITHM.&type
	} -- as specified by the X.509 recommendation [10]		} -- as specified by the X.509 recommendation [10]
	If the client passes an issuer and serial number in the request,		If the client passes an issuer and serial number in the request,
	the KDC is requested to use the referred-to certificate. If none		the KDC is requested to use the referred-to certificate. If none
	exists, then the KDC returns an error of type		exists, then the KDC returns an error of type
	KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the		KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
	other hand, the client does not pass any trustedCertifiers,		other hand, the client does not pass any trustedCertifiers,
	believing that it has the KDC's certificate, but the KDC has more		believing that it has the KDC's certificate, but the KDC has more
	than one certificate. The KDC should include information in the		than one certificate. The KDC should include information in the
	KRB-ERROR message that indicates the KDC certificate(s) that a		KRB-ERROR message that indicates the KDC certificate(s) that a
	client may utilize. This data is specified in the e-typed-data		client may utilize. This data is specified in the e-data, which
	type as follows:		is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
	ETypedData ::= SEQUENCE {		TypedData ::= SEQUENCE {
	e-data-type [1] INTEGER,		data-type [0] INTEGER,
	e-data-value [2] OCTET STRING,		data-value [1] OCTET STRING,
	} -- per Kerberos RFC 1510 revisions		} -- per Kerberos RFC 1510 revisions
	where:		where:
	e-data-type = ETD-PKINIT-CMS-CERTIFICATES = 101		data-type = TD-PKINIT-CMS-CERTIFICATES = 101
	e-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,
	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 private key corresponding to the public key in the
	certificate found in userCert (or cached by the KDC).		certificate found in userCert (or cached by the KDC).
	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
	skipping to change at line 491 ¶		skipping to change at line 444 ¶
	client.		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 verification of the user's certificate fails, the KDC sends back		If the client's certificate chain contains no certificate signed by
	an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data		a CA trusted by the KDC, then the KDC sends back an error message
	field contains additional information pertaining to this error, and		of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data
	is formatted as follows:		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
	METHOD-DATA ::= SEQUENCE {		TrustedCertifiers ::= SEQUENCE OF PrincipalName
	method-type [0] INTEGER,		-- X.500 name encoded as a principal name
	-- 0 = not specified		-- see Section 3.1
	-- 1 = cannot verify public key
	-- 2 = invalid certificate
	-- 3 = revoked certificate
	-- 4 = invalid KDC name
	-- 5 = client name mismatch
	method-data [1] OCTET STRING OPTIONAL
	} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
	The values for the method-type and method-data fields are described		If the signature on one of the certificates in the client's chain
	in Section 3.2.1.		fails verification, then the KDC returns an error of type
			KDC_ERR_INVALID_CERTIFICATE. The accompanying 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
			CertificateIndex ::= INTEGER
			-- 0 = 1st certificate,
			-- (in order of encoding)
			-- 1 = 2nd certificate, etc
			The KDC may also check whether any of the certificates in the
			client's chain has been revoked. If one of the certificates has
			been revoked, then the KDC returns an error of type
			KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the
			certificate's revocation status is unknown, the KDC returns an
			error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation
			status is unavailable, the KDC returns an error of type
			KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
			cases, the affected certificate is identified by the accompanying
			e-data, which contains a CertificateIndex as described for
			KDC_ERR_INVALID_CERTIFICATE.
			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
			request, then the KDC returns an error of type
			KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
			field in this case.
			Finally, if the certificate chain is verified, but the KDC's name
			or realm as given in the PKAuthenticator does not match the KDC's
			actual principal name, then the KDC returns an error of type
			KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again
			a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
			TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
			STRING whose data-value is the DER encoding of a PrincipalName or
			Realm as defined in RFC 1510 revisions.
			Even if all succeeds, the KDC may--for policy reasons--decide not
			to trust the client. In this case, the KDC returns an error message
			of type KDC_ERR_CLIENT_NOT_TRUSTED.
	If a trust relationship exists, the KDC then verifies the client's		If a trust relationship exists, the KDC then verifies the client's
	signature on AuthPack. If that fails, the KDC returns an error		signature on AuthPack. If that fails, the KDC returns an error
	message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the		message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
	timestamp (ctime and cusec) in the PKAuthenticator to assure that		timestamp (ctime and cusec) in the PKAuthenticator to assure that
	the request is not a replay. The KDC also verifies that its name		the request is not a replay. The KDC also verifies that its name
	is specified in the PKAuthenticator.		is specified in the PKAuthenticator.
	If the clientPublicValue field is filled in, indicating that the		If the clientPublicValue field is filled in, indicating that the
	client wishes to use Diffie-Hellman key agreement, then the KDC		client wishes to use Diffie-Hellman key agreement, then the KDC
	checks to see that the parameters satisfy its policy. If they do		checks to see that the parameters satisfy its policy. If they do
	not (e.g., the prime size is insufficient for the expected		not (e.g., the prime size is insufficient for the expected
	encryption type), then the KDC sends back an error message of type		encryption type), then the KDC sends back an error message of type
	KDC_ERR_KEY_TOO_WEAK. 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. If the		KDC returns an error message of type KRB_AP_ERR_SKEW.
	principal name or realm do not match the KDC, then the KDC returns
	an error message of type KDC_ERR_NAME_MISMATCH for which the
	e-typed-data may contain the correct name to use
	(EDT-KRB-PRINCIPAL=102 or EDT-KRB-REALM=103 where
	e-data-value = PrincipalName or Realm as defined by RFC 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 a Kerberos name in an extension
	field, and local KDC policy allows, then use that name.		field, and local KDC policy allows, then use that name.
	skipping to change at line 560 ¶		skipping to change at line 541 ¶
	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 a random key generated only for this particular response. This
	random key is sealed in the preauthentication field:		random key is sealed in the preauthentication field:
	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-Helman key exchange
			-- This choice MUST be supported
			-- 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 690 ¶		skipping to change at line 673 ¶
	GeneralName ::= CHOICE {		GeneralName ::= CHOICE {
	otherName [0] INSTANCE OF OTHER-NAME,		otherName [0] INSTANCE OF OTHER-NAME,
	...		...
	}		}
	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 replaced by the type KerberosPrincipalName:		be chosen and replaced by the type KerberosName:
	KerberosPrincipalName ::= SEQUENCE {
	nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ),
	name [1] OTHER-NAME.&type ( { PrincipalNameTypes }
	{ @nameType } )
	}
	PrincipalNameTypes OTHER-NAME ::= {		KerberosName ::= SEQUENCE {
	{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }		realm [0] Realm,
			-- as define in RFC 1510
			principalName [1] PrincipalName,
			-- as define in RFC 1510
	}		}
	PrincipalNameSrvInst ::= GeneralString		This specific syntax is identified within subjectAltName by setting
			the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
	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) }
	principalName OBJECT IDENTIFIER ::= { krb5 2 }		krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
	principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }		This specification may also be used to specify a Kerberos name
			within the user's certificate.
	(This specification can also be used to specify a Kerberos name		If a non-KDC X.509 certificate contains the principal name within
	within the user's certificate.)		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 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.
	3.2.1. Additional Information for Errors
	This section describes the interpretation of the method-type and
	method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
	If method-type=1, the client's public key certificate chain does not
	contain a certificate that is signed by a certification authority
	trusted by the KDC. The format of the method-data field will be an
	ASN.1 encoding of a list of trusted certifiers, as defined above:
	TrustedCertifiers ::= SEQUENCE OF PrincipalName
	If method-type=2, the signature on one of the certificates in the
	chain cannot be verified. The format of the method-data field will
	be an ASN.1 encoding of the integer index of the certificate in
	question:
	CertificateIndex ::= INTEGER
	-- 0 = 1st certificate,
	-- 1 = 2nd certificate, etc
	If method-type=3, one of the certificates in the chain has been
	revoked. The format of the method-data field will be an ASN.1
	encoding of the integer index of the certificate in question:
	CertificateIndex ::= INTEGER
	-- 0 = 1st certificate,
	-- 1 = 2nd certificate, etc
	If method-type=4, the KDC name or realm in the PKAuthenticator does
	not match the principal name of the KDC. There is no method-data
	field in this case.
	If method-type=5, the client name or realm in the certificate does
	not match the principal name of the client. There is no
	method-data field in this case.
	3.2.2. Required Algorithms		3.2.2. 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
	- 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
	4. Logistics and Policy		4. Logistics and Policy
	This section describes a way to define the policy on the use of		This section describes a way to define the policy on the use of
	PKINIT for each principal and request.		PKINIT for each principal and request.
	The KDC is not required to contain a database record for users		The KDC is not required to contain a database record for users
	that use either the Standard Public Key Authentication. However,		who use public key authentication. However, if these users are
	if these users are registered with the KDC, it is recommended that		registered with the KDC, it is recommended that the database record
	the database record for these users be modified to an additional		for these users be modified to an additional flag in the attributes
	flag in the attributes field to indicate that the user should		field to indicate that the user should authenticate using PKINIT.
	authenticate using PKINIT. If this flag is set and a request		If this flag is set and a request message does not contain the
	message does not contain the PKINIT preauthentication field, then		PKINIT preauthentication field, then the KDC sends back as error of
	the KDC sends back as error of type KDC_ERR_PREAUTH_REQUIRED		type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
	indicating that a preauthentication field of type PA-PK-AS-REQ must		field of type PA-PK-AS-REQ must be included in the request.
	be included in the request.
	5. Security Considerations		5. Security Considerations
	PKINIT raises a few security considerations, which we will address		PKINIT raises a few security considerations, which we will address
	in this section.		in this section.
	First of all, PKINIT introduces a new trust model, where KDCs do not		First of all, PKINIT introduces a new trust model, where KDCs do not
	(necessarily) certify the identity of those for whom they issue		(necessarily) certify the identity of those for whom they issue
	tickets. PKINIT does allow KDCs to act as their own CAs, in order		tickets. PKINIT does allow KDCs to act as their own CAs, in order
	to simplify key management, but one of the additional benefits is to		to simplify key management, but one of the additional benefits is to
	skipping to change at line 871 ¶		skipping to change at line 823 ¶
	[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-10.txt, December 1998.		draft-ietf-smime-cms-13.txt, April 1999.
	[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
			Key Infrastructure, Certificate and CRL Profile, January 1999.
			Request for Comments 2459.
			[16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
			Specifications, October 1998.
			Request for Comments 2437.
			[17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.
			S/MIME Version 2 Certificate Handling, March 1998.
			Request for Comments 2312
	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 November 12, 1999.		This draft expires December 1, 1999.
	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. 42 change blocks.
	235 lines changed or deleted		199 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/