< draft-ietf-cat-kerberos-pk-init-07.txt		draft-ietf-cat-kerberos-pk-init-08.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-07.txt Clifford Neuman		Updates: RFC 1510 ISI
	Updates: RFC 1510 ISI		expires November 12, 1999 Matthew Hur
	expires May 15, 1999 John Wray		CyberSafe Corporation
	Digital Equipment Corporation		Ari Medvinsky
	Ari Medvinsky		Excite
	Matthew Hur		Sasha Medvinsky
	Sasha Medvinsky		General Instrument
	CyberSafe Corporation		John Wray
	Jonathan Trostle		Iris Associates, Inc.
	Cisco		Jonathan Trostle
			Cisco
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial Authentication in Kerberos
	0. Status Of This Memo		0. Status Of This Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance with
	documents of the Internet Engineering Task Force (IETF), its		all provisions of Section 10 of RFC 2026. Internet-Drafts are
	areas, and its working groups. Note that other groups may also		working documents of the Internet Engineering Task Force (IETF),
			its areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
			The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt
			The list of Internet-Draft Shadow Directories can be accessed at
			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-07.txt, and expires May 15, 1999.		draft-ietf-cat-kerberos-pk-init-09.txt, and expires November 12,
	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 63 ¶		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.
	One of the guiding principles in the design of PKINIT is that		PKINIT utilizes Diffie-Hellman keys in combination with digital
	changes should be as minimal as possible. As a result, the basic		signature keys as the primary, required mechanism. It also allows
	mechanism of PKINIT is as follows: The user sends a request to the		for the use of RSA keys. Note that PKINIT supports the use of
	KDC as before, except that if that user is to use public key		separate signature and encryption keys.
	cryptography in the initial authentication step, his certificate
	accompanies the initial request, in the preauthentication fields.
	Upon receipt of this request, the KDC verifies the certificate and
	issues a ticket granting ticket (TGT) as before, except that
	the encPart from the AS-REP message carrying the TGT is now
	encrypted in a randomly-generated key, instead of the user's
	long-term key (which is derived from a password). This
	random key is in turn encrypted using the public key from the
	certificate that came with the request and signed using the KDC's
	private key, and accompanies the reply, in the preauthentication
	fields.
	PKINIT also allows for users with only digital signature keys to		PKINIT enables access to Kerberos-secured services based on initial
	authenticate using those keys, and for users to store and retrieve		authentication utilizing public key cryptography. PKINIT utilizes
	private keys on the KDC.		standard public key signature and encryption data formats within 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
			is to use public key cryptography in the initial authentication
			step, his certificate and a signature accompany the initial request
			in the preauthentication fields. Upon receipt of this request, the
			KDC verifies the certificate and issues a ticket granting ticket
			(TGT) as before, except that the encPart from the AS-REP message
			carrying the TGT is now encrypted utilizing either a Diffie-Hellman
			derived key or the user's public key. This message is authenticated
			utilizing the public key signature of the KDC.
	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], anonymous		in issuing cross realm service tickets. As specified in [4],
	Kerberos tickets can be issued by applying a NULL signature in		anonymous Kerberos tickets can be issued by applying a NULL
	combination with Diffie-Hellman in the PKINIT exchange. Additionally,		signature in combination with Diffie-Hellman in the PKINIT exchange.
	The PKINIT specification may be used for direct peer to peer		Additionally, the PKINIT specification may be used for direct peer
	authentication without contacting a central KDC. This application		to peer authentication without contacting a central KDC. This
	of PKINIT is described in PKTAPP [5] and is based on concepts		application of PKINIT is described in PKTAPP [5] and is based on
	introduced in [6, 7]. For direct client-to-server authentication,		concepts introduced in [6, 7]. For direct client-to-server
	the client uses PKINIT to authenticate to the end server (instead		authentication, the client uses PKINIT to authenticate to the end
	of a central KDC), which then issues a ticket for itself. This		server (instead of a central KDC), which then issues a ticket for
	approach has an advantage over SSL [8] in that the server does not		itself. This approach has an advantage over TLS [8] in that the
	need to save state (cache session keys). Furthermore, an		server does not need to save state (cache session keys).
	additional benefit is that Kerberos tickets can facilitate		Furthermore, an additional benefit is that Kerberos tickets can
	delegation (see [9]).		facilitate delegation (see [9]).
	3. Proposed Extensions		3. Proposed Extensions
	This section describes extensions to RFC 1510 for supporting the		This section describes extensions to RFC 1510 for supporting the
	use of public key cryptography in the initial request for a ticket		use of public key cryptography in the initial request for a ticket
	granting ticket (TGT).		granting ticket (TGT).
	In summary, the following changes to RFC 1510 are proposed:		In summary, the following change to RFC 1510 is proposed:
	* Users may authenticate using either a public key pair or a		* Users may authenticate using either a public key pair or a
	conventional (symmetric) key. If public key cryptography is		conventional (symmetric) key. If public key cryptography is
	used, public key data is transported in preauthentication		used, public key data is transported in preauthentication
	data fields to help establish identity.		data fields to help establish identity. The user presents
	* Users may store private keys on the KDC for retrieval during		a public key certificate and obtains an ordinary TGT that may
	Kerberos initial authentication.		be used for subsequent authentication, with such
			authentication using only conventional cryptography.
	This proposal addresses two ways that users may use public key
	cryptography for initial authentication. Users may present public
	key certificates, or they may generate their own session key,
	signed by their digital signature key. In either case, the end
	result is that the user obtains an ordinary TGT that may be used for
	subsequent authentication, with such authentication using only
	conventional cryptography.
	Section 3.1 provides definitions to help specify message formats.		Section 3.1 provides definitions to help specify message formats.
	Section 3.2 and 3.3 describe the extensions for the two initial		Section 3.2 describes the extensions for the initial authentication
	authentication methods. Section 3.4 describes a way for the user to		method.
	store and retrieve his private key on the KDC, as an adjunct to the
	initial authentication.
	3.1. Definitions		3.1. Definitions
	The extensions involve new preauthentication fields; we propose the		The extensions involve new preauthentication fields; we introduce
	addition of the following 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-AS-SIGN 16		PA-PK-KEY-REQ 18
	PA-PK-KEY-REQ 17		PA-PK-KEY-REP 19
	PA-PK-KEY-REP 18
	The extensions also involve new error types; we propose the addition		The extensions also involve new error types; we introduce the
	of 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
			We utilize the following typed data for errors:
			ETD-PKINIT-CMS-CERTIFICATES 101
			ETD-KRB-PRINCIPAL 102
			ETD-KRB-REALM 103
			We utilize the following encryption types (which map directly to
			OIDs):
			sha1WithRSAEncryption-CmsOID 8
			dsaWithSHA1-CmsOID 9
			md4WithRsaEncryption-CmsOID 10
			md5WithRSAEncryption-CmsOID 11
			rc2CBC-EnvOID 12
			rc4-EnvOID 13
	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 ASCII encoding of an X.500 name, as defined by
	RFC 2253 [14] (part of LDAPv3). (RFC 2253 obsoleted RFC 1779, which		RFC 2253 [14] (part of LDAPv3).
	is not supported by this version of PKINIT.)
	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, PKINIT may require the encoding of an X.500 name as a
	PrincipalName. In these cases, the name-type of the principal name		PrincipalName. In these cases, the name-type of the principal name
	shall be set to NT-X500-PRINCIPAL. This new name type is defined		shall be set to KRB_NT-X500-PRINCIPAL. This new name type is
	as:		defined as:
	#define CSFC5c_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.
	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.
	All additional symmetric keys specified in this draft shall use the		In the case of Diffie-Hellman, the key shall be produced from the
	same encryption type as the session key in the response from the		agreed bit string as follows:
	KDC. These include the temporary keys used to encrypt the signed
	random key encrypting the response, as well as the key derived from
	Diffie-Hellman agreement. In the case of Diffie-Hellman, the key
	shall be produced from the 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.
	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		These are the algorithm identifiers for use in the Signature data
	structure:		structure as specified in CMS [11]:
	sha-1WithRSAEncryption ALGORITHM PARAMETER NULL		sha-1WithRSAEncryption ALGORITHM PARAMETER NULL
	::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs-1(1) 5 }		pkcs-1(1) 5 }
	dsaWithSHA1 ALGORITHM PARAMETER NULL		dsaWithSHA1 ALGORITHM PARAMETER NULL
	::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)		::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
	oIWSecAlgorithm(2) dsaWithSHA1(27) }		oIWSecAlgorithm(2) dsaWithSHA1(27) }
	md4WithRsaEncryption ALGORITHM PARAMETER NULL		md4WithRsaEncryption ALGORITHM PARAMETER NULL
	skipping to change at line 263 ¶		skipping to change at line 271 ¶
	base INTEGER,		base INTEGER,
	-- g		-- g
	privateValueLength INTEGER OPTIONAL		privateValueLength INTEGER OPTIONAL
	} -- as specified by the X.509 recommendation [9]		} -- 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:
	rsaEncryption ALGORITHM PARAMETER NULL		id-RSAES-OAEP OBJECT IDENTIFIER
	::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs-1(1) rsaEncryption(1)		pkcs-1(1) 7 }
	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, for encrypting the temporary key with a Diffie-Hellman-
	derived key, or for encrypting the reply key:		derived key, or for encrypting the reply key:
	desCBC ALGORITHM PARAMETER IV8		desCBC ALGORITHM PARAMETER IV8
	::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)		::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
	oIWSecAlgorithm(2) desCBC(7) }		oIWSecAlgorithm(2) desCBC(7) }
	skipping to change at line 356 ¶		skipping to change at line 364 ¶
	70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf		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		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		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		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		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		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		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		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		f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab
	3.2. Standard 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] SignedAuthPack		signedAuthPack [0] SignedData
	userCert [1] SEQUENCE OF Certificate OPTIONAL,		-- defined in CMS [11]
	-- the user's certificate chain;		-- AuthPack (below) defines the data
	-- if present, the KDC must use		-- that is signed
	-- the public key from this		trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
	-- particular certificate chain to
	-- verify the signature in the
	-- request
	trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL,
	-- CAs that the client trusts		-- CAs that the client trusts
	serialNumber [3] CertificateSerialNumber OPTIONAL		kdcCert [2] IssuerAndSerialNumber OPTIONAL
	-- specifying a particular KDC		-- as defined in CMS [11]
			-- 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
	}		}
	CertificateSerialNumber ::= INTEGER		Usage of SignedData:
	-- as specified by PKCS #6 [15]		The SignedData data type is specified in the Cryptographic
			Message Syntax, a product of the S/MIME working group of the IETF.
	SignedAuthPack ::= SEQUENCE {		- The encapContentInfo field must contain the PKAuthenticator
	authPack [0] AuthPack,		and, optionally, the client's Diffie Hellman public value.
	authPackSig [1] Signature,		- The eContentType field shall contain the OID value for
	-- of authPack		id-data: iso(1) member-body(2) us(840) rsadsi(113549)
	-- using user's private key		pkcs(1) pkcs7(7) data(1)
	}		- The eContent field is data of the type AuthPack (below).
			- The signerInfos field is a SET of SignerInfo that is required by
			CMS; however, the set may contain zero elements. When non-empty,
			this field contains the client's certificate chain. If present,
			the KDC uses the public key from the client's certificate to
			verify the signature in the request. Note that the client may
			pass different certificates that are used for signing or for
			encrypting. Thus, the KDC may utilize a different client
			certificate for signature verification than the one it uses to
			encrypt the reply to the client.
	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,
	cusec [2] INTEGER,		cusec [2] INTEGER,
	-- for replay prevention		-- for replay prevention
	ctime [3] KerberosTime,		ctime [3] KerberosTime,
	-- for replay prevention		-- for replay prevention
	nonce [4] INTEGER		nonce [4] INTEGER
	}		}
	Signature ::= SEQUENCE {
	signatureAlgorithm [0] SignatureAlgorithmIdentifier,
	pkcsSignature [1] BIT STRING
	-- octet-aligned big-endian bit
	-- string (encrypted with signer's
	-- private key)
	}
	SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
	AlgorithmIdentifier ::= SEQUENCE {
	algorithm ALGORITHM.&id,
	parameters ALGORITHM.&type
	} -- as specified by the X.509 recommendation [10]
	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 [9]
	Certificate ::= SEQUENCE {		AlgorithmIdentifier ::= SEQUENCE {
	certType [0] INTEGER,		algorithm ALGORITHM.&id,
	-- type of certificate		parameters ALGORITHM.&type
	-- 1 = X.509v3 (DER encoding)		} -- as specified by the X.509 recommendation [10]
	-- 2 = PGP (per PGP specification)
	-- 3 = PKIX (per PKCS #6 [15])
	certData [1] OCTET STRING
	-- actual certificate
	-- type determined by certType
	}
	If the client passes a certificate 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.		than one certificate. The KDC should include information in the
			KRB-ERROR message that indicates the KDC certificate(s) that a
			client may utilize. This data is specified in the e-typed-data
			type as follows:
			ETypedData ::= SEQUENCE {
			e-data-type [1] INTEGER,
			e-data-value [2] OCTET STRING,
			} -- per Kerberos RFC 1510 revisions
			where:
			e-data-type = ETD-PKINIT-CMS-CERTIFICATES = 101
			e-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, and to optionally pass the		to bind the request and response. The PKAuthenticator is signed
	client's Diffie-Hellman public value (i.e. for using DSA in
	combination with Diffie-Hellman). 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 userCert field is a sequence of certificates, the first of which
	must be the user's public key certificate. Any subsequent
	certificates will be certificates of the certifiers of the user's
	certificate. These cerificates may be used by the KDC to verify the
	user's public key. This field may be left empty if the KDC already
	has the user's certificate.
	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_CERTIFICATE_MISMATCH.		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.
	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 verification of the user's certificate fails, the KDC sends back
	an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data		an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data
	field contains additional information pertaining to this error, and		field contains additional information pertaining to this error, and
	is formatted as follows:		is formatted as follows:
	METHOD-DATA ::= SEQUENCE {		METHOD-DATA ::= SEQUENCE {
	method-type [0] INTEGER,		method-type [0] INTEGER,
			-- 0 = not specified
	-- 1 = cannot verify public key		-- 1 = cannot verify public key
	-- 2 = invalid certificate		-- 2 = invalid certificate
	-- 3 = revoked certificate		-- 3 = revoked certificate
	-- 4 = invalid KDC name		-- 4 = invalid KDC name
	-- 5 = client name mismatch		-- 5 = client name mismatch
	method-data [1] OCTET STRING OPTIONAL		method-data [1] OCTET STRING OPTIONAL
	} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)		} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
	The values for the method-type and method-data fields are described		The values for the method-type and method-data fields are described
	in Section 3.2.1.		in Section 3.2.1.
	If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
	verifies that it has a certificate issued by one of the certifiers
	trusted by the client. If it does not have a suitable certificate,
	the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
	the client.
	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 in the PKAuthenticator to assure that the request is not a		timestamp (ctime and cusec) in the PKAuthenticator to assure that
	replay. The KDC also verifies that its name is specified in the		the request is not a replay. The KDC also verifies that its name
	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. If the local (server) time and the		within the allowable window and that the principal name and realm
	client time in the authenticator differ by more than the allowable		are correct. If the local (server) time and the client time in the
	clock skew, then the KDC returns an error message of type		authenticator differ by more than the allowable clock skew, then the
	KRB_AP_ERR_SKEW.		KDC returns an error message of type KRB_AP_ERR_SKEW. If the
			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. Else		to a Kerberos name, then use that name.
			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.
	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		as necessary (e.g., as per RFC 2253 for X.500 names). In
	this case the realm in the ticket shall be the name of the		this case the realm in the ticket shall be the name of the
	certification authority that issued the user's certificate.		certification authority that issued the user's certificate.
	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 ::= SEQUENCE {		PA-PK-AS-REP ::= CHOICE {
	-- PA TYPE 15		-- PA TYPE 15
	encKeyPack [1] EnvelopedKeyPack,		dhSignedData [0] SignedData,
	-- temporary key is encrypted		-- Defined in CMS and used only with
	-- using either the client public		-- Diffie-Helman key exchange
	-- key or the Diffie-Hellman key		encKeyPack [1] EnvelopedData,
	-- specified by SignedKDCPublicValue.		-- Defined in CMS
	-- SignedReplyKeyPack, encrypted		-- The temporary key is encrypted
	-- with the temporary key, is also		-- using the client public key
	-- included.		-- key
	signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL,		-- SignedReplyKeyPack, encrypted
	-- if one was passed in the request		-- with the temporary key, is also
	kdcCert [3] SEQUENCE OF Certificate OPTIONAL		-- included.
	-- the KDC's certificate chain
	}
	The EnvelopedKeyPack data type below contains an encrypted
	temporary key (either with the PKINIT client's public key or with a
	symmetric key, resulting from the Diffie-Hellman exchange). It also
	contains a signed and encrypted reply key. This data structure is
	similar to EnvelopedData, defined in CMS [11] and PKCS #7 [12].
	EnvelopedKeyPack ::= SEQUENCE {
	version Version,
	-- Always set to 0.
	recipientInfos RecipientInfos,
	-- This is a SET, which must contain
	-- exactly one member. Contains a
	-- temporary key, encrypted with the
	-- client's public key. This
	-- temporary key is used to encrypt
	-- the reply key.
	encryptedContentInfo EncryptedContentInfo
	-- contains the signed and encrypted
	-- reply key
	}
	Version ::= INTEGER
	RecipientInfos ::= SET OF RecipientInfo
	RecipientInfo ::= SEQUENCE {
	version Version,
	-- shall be 0
	rid RecipientIdentifier,
	-- Since this is an optional field,
	-- it supports both CMS and PKCS #7
	keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
	EncryptedKey OCTET STRING
	-- the temporary key, encrypted with
	-- the PKINIT client's public key
	}
	KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
	RecipientIdentifier ::= IssuerAndSerialNumber
	-- Corresponds to the X.509 V3 extension
	-- SubjectKeyIdentifier.
	IssuerAndSerialNumber ::= SEQUENCE {
	issuer Name,
	-- a distinguished name, as defined
	-- by X.509
	serialNumber CertificateSerialNumber
	}
	CertificateSerialNumber ::= INTEGER
	EncryptedContentInfo ::= SEQUENCE {
	contentType ContentType,
	-- shall be:
	-- iso(1) member-body(2) us(840)
	-- rsadsi(113549) pkcs(1) pkcs7(7)
	-- EnvelopedData(3)
	contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier
	-- Algorithm used to encrypt the
	-- SignedReplyKeyPack.
	encryptedContent OCTET STRING
	-- The encrypted data is of the type
	-- SignedReplyKeyPack.
	}		}
	ContentType ::= OBJECT IDENTIFIER		Usage of SignedData:
			If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
			provides authenticated Diffie-Hellman parameters of the KDC. The
			reply key used to encrypt part of the KDC reply message is derived
			from the Diffie-Hellman exchange:
			- Both the KDC and the client calculate a secret value (g^ab mod p),
			where a is the client's private exponent and b is the KDC's
			private exponent.
			- 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 the reply key
			type.
			- If the reply key is DES, N=64 bits, where some of the bits are
			replaced with parity bits, according to FIPS PUB 74.
			- If the reply key is (3-key) 3-DES, N=192 bits, where some of the
			bits are replaced with parity bits, according to FIPS PUB 74.
			- The encapContentInfo field must contain the KdcDHKeyInfo as
			defined below.
			- The eContentType field shall contain the OID value for
			id-data: iso(1) member-body(2) us(840) rsadsi(113549)
			pkcs(1) pkcs7(7) data(1)
			- The certificates field must contain the certificates necessary
			for the client to establish trust in the KDC's 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 did
			not send to the KDC a list of trusted certifiers (the
			trustedCertifiers field was empty, meaning that the client
			already possesses the KDC's certificate).
			- The signerInfos field is a SET that must contain at least one
			member, since it contains the actual signature.
	ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier		Usage of EnvelopedData:
			The EnvelopedData data type is specified in the Cryptographic
			Message Syntax, a product of the S/MIME working group of the IETF.
			It contains an temporary key encrypted with the PKINIT
			client's public key. It also contains a signed and encrypted
			reply key.
			- The originatorInfo field is not required, since that information
			may be presented in the signedData structure that is encrypted
			within the encryptedContentInfo field.
			- The optional unprotectedAttrs field is not required for PKINIT.
			- The recipientInfos field is a SET which must contain exactly one
			member of the KeyTransRecipientInfo type for encryption
			with an RSA public key.
			- The encryptedKey field (in KeyTransRecipientInfo) contains
			the temporary key which is encrypted with the PKINIT client's
			public key.
			- The encryptedContentInfo field contains the signed and encrypted
			reply key.
			- The contentType field shall contain the OID value for
			id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
			pkcs(1) pkcs7(7) signedData(2)
			- The encryptedContent field is encrypted data of the CMS type
			signedData as specified below.
			- The encapContentInfo field must contains the ReplyKeyPack.
			- The eContentType field shall contain the OID value for
			id-data: iso(1) member-body(2) us(840) rsadsi(113549)
			pkcs(1) pkcs7(7) data(1)
			- The eContent field is data of the type ReplyKeyPack (below).
			- The certificates field must contain the certificates necessary
			for the client to establish trust in the KDC's 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 did
			not send to the KDC a list of trusted certifiers (the
			trustedCertifiers field was empty, meaning that the client
			already possesses the KDC's certificate).
			- The signerInfos field is a SET that must contain at least one
			member, since it contains the actual signature.
	SignedReplyKeyPack ::= SEQUENCE {		KdcDHKeyInfo ::= SEQUENCE {
	replyKeyPack [0] ReplyKeyPack,		-- used only when utilizing Diffie-Hellman
	replyKeyPackSig [1] Signature,		nonce [0] INTEGER,
	-- of replyKeyPack		-- binds responce to the request
	-- using KDC's private key		subjectPublicKey [2] BIT STRING
			-- Equals public exponent (g^a mod p)
			-- INTEGER encoded as payload of
			-- BIT STRING
	}		}
	ReplyKeyPack ::= SEQUENCE {		ReplyKeyPack ::= SEQUENCE {
	replyKey [0] EncryptionKey,		-- not used for Diffie-Hellman
	-- used to encrypt main reply		replyKey [0] EncryptionKey,
	-- of same ENCTYPE as session key		-- used to encrypt main reply
	nonce [1] INTEGER		-- ENCTYPE is at least as strong as
	-- binds response to the request		-- ENCTYPE of session key
	-- must be same as the nonce		nonce [1] INTEGER,
	-- passed in the PKAuthenticator		-- binds response to the request
	}		-- must be same as the nonce
			-- passed in the PKAuthenticator
	SignedKDCPublicValue ::= SEQUENCE {
	kdcPublicValue [0] SubjectPublicKeyInfo,
	-- as described above
	kdcPublicValueSig [1] Signature
	-- of kdcPublicValue
	-- using KDC's private key
	}		}
	The kdcCert field is a sequence of certificates, the first of which
	must be the KDC's public key certificate. Any subsequent
	certificates will be certificates of the certifiers of the KDC's
	certificate. The last of these must have as its certifier one of
	the certifiers sent to the KDC in the PA-PK-AS-REQ. These
	cerificates may be used by the client to verify the KDC's public
	key. This field is empty if the client did not send to the KDC a
	list of trusted certifiers (the trustedCertifiers field was empty).
	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 essentially a separate realm, the name of each
	certifier shall be added to the transited field of the ticket. The		certifier must be added to the transited field of the ticket. The
	format of these realm names is defined in Section 3.1 of this		format of these realm names is defined in Section 3.1 of this
	document. If applicable, the transit-policy-checked flag should be		document. If applicable, the transit-policy-checked flag should be
	set in the issued ticket.		set in the issued ticket.
	The KDC's certificate must bind the public key to a name derivable		The KDC's certificate must bind the public key to a name derivable
	from the name of the realm for that KDC. X.509 certificates shall		from the name of the realm for that KDC. X.509 certificates shall
	contain the principal name of the KDC as the SubjectAltName version		contain the principal name of the KDC as the SubjectAltName version
	3 extension. Below is the definition of this version 3 extension, as		3 extension. Below is the definition of this version 3 extension, as
	specified by the X.509 standard:		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,
	...		...
	}		}
	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 replaced by the type KerberosPrincipalName:
	KerberosPrincipalName ::= SEQUENCE {		KerberosPrincipalName ::= SEQUENCE {
	nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ),		nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ),
	name [1] OTHER-NAME.&type ( { PrincipalNameTypes }		name [1] OTHER-NAME.&type ( { PrincipalNameTypes }
	{ @nameType } )		{ @nameType } )
	}		}
	PrincipalNameTypes OTHER-NAME ::= {		PrincipalNameTypes OTHER-NAME ::= {
	{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }		{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
	}		}
	PrincipalNameSrvInst ::= GeneralString		PrincipalNameSrvInst ::= GeneralString
	where (from the Kerberos specification) we have		where (from the Kerberos specification) we have
	skipping to change at line 768 ¶		skipping to change at line 762 ¶
	-- 1 = 2nd certificate, etc		-- 1 = 2nd certificate, etc
	If method-type=4, the KDC name or realm in the PKAuthenticator does		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		not match the principal name of the KDC. There is no method-data
	field in this case.		field in this case.
	If method-type=5, the client name or realm in the certificate does		If method-type=5, the client name or realm in the certificate does
	not match the principal name of the client. There is no		not match the principal name of the client. There is no
	method-data field in this case.		method-data field in this case.
	3.2.2. Required Algorithms and Data Formats		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 and data formats:		Below is a list of the required algorithms:
	- Diffie-Hellman public/private key pairs
	- SHA1 digest and DSA for signatures
	- X.509 version 3 certificates
	- 3-key triple DES keys derived from the Diffie-Hellman Exchange
	- 3-key triple DES Temporary and Reply keys
	3.3. Digital Signature
	Implementation of the changes in this section are OPTIONAL for
	compliance with PKINIT.
	We offer this option with the warning that it requires the client to
	generate a random key; the client may not be able to guarantee the
	same level of randomness as the KDC.
	If the user registered, or presents a certificate for, a digital
	signature key with the KDC instead of an encryption key, then a
	separate exchange must be used. The client sends a request for a
	TGT as usual, except that it (rather than the KDC) generates the
	random key that will be used to encrypt the KDC response. This key
	is sent to the KDC along with the request in a preauthentication
	field, encrypted with the KDC's public key:
	PA-PK-AS-SIGN ::= SEQUENCE {
	-- PA TYPE 16
	encKeyPack [1] EnvelopedKeyPack,
	-- temporary key is encrypted
	-- using the KDC public
	-- key.
	-- SignedRandomKeyPack, encrypted
	-- with the temporary key, is also
	-- included.
	userCert [2] SEQUENCE OF Certificate OPTIONAL
	-- the user's certificate chain;
	-- if present, the KDC must use
	-- the public key from this
	-- particular certificate chain to
	-- verify the signature in the
	-- request
	}
	In the above message, the content of the encKeyPack is similar to
	the content of the encKeyPack field in the PA-PK-AS-REP message,
	except that it is the KDC's public key and not the client's public
	key that is used to encrypt the temporary key. And, the
	encryptedContentInfo field inside the EnvelopedKeyPack contains
	encrypted data of the type SignedRandomKeyPack instead of the
	SignedReplyKeyPack.
	SignedRandomKeyPack ::= SEQUENCE {
	randomkeyPack [0] RandomKeyPack,
	randomkeyPackSig [1] Signature
	-- of keyPack
	-- using user's private key
	}
	RandomKeyPack ::= SEQUENCE {
	randomKey [0] EncryptionKey,
	-- will be used to encrypt reply
	randomKeyAuth [1] PKAuthenticator
	}
	If the KDC does not accept client-generated random keys as a matter
	of policy, then it sends back an error message of type
	KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as
	follows.
	Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
	the randomKey. It then replies as per RFC 1510, except that the
	reply is encrypted not with a password-derived user key, but with
	the randomKey sent in the request. Since the client already knows
	this key, there is no need to accompany the reply with an extra
	preauthentication field. The transited field of the ticket should
	specify the certification path as described in Section 3.2.
	3.4. Retrieving the User's Private Key from the KDC
	Implementation of the changes described in this section are OPTIONAL
	for compliance with PKINIT. (This section may or may not fall under
	the purview of a patent for private key storage; please see Section
	8 for more information.)
	When the user's private key is not stored local to the user, he may
	choose to store the private key (normally encrypted using a
	password-derived key) on the KDC. In this case, the client makes a
	request as described above, except that instead of preauthenticating
	with his private key, he uses a symmetric key shared with the KDC.
	For simplicity's sake, this shared key is derived from the password-
	derived key used to encrypt the private key, in such a way that the
	KDC can authenticate the user with the shared key without being able
	to extract the private key.
	We provide this option to present the user with an alternative to
	storing the private key on local disk at each machine where he
	expects to authenticate himself using PKINIT. It should be noted
	that it replaces the added risk of long-term storage of the private
	key on possibly many workstations with the added risk of storing the
	private key on the KDC in a form vulnerable to brute-force attack.
	Denote by K1 the symmetric key used to encrypt the private key.
	Then construct symmetric key K2 as follows:
	* Perform a hash on K1.
	* Truncate the digest to Length(K1) bytes.
	* Rectify parity in each byte (if necessary) to obtain K2.
	The KDC stores K2, the public key, and the encrypted private key.
	This key pair is designated as the "primary" key pair for that user.
	This primary key pair is the one used to perform initial
	authentication using the PA-PK-AS-REP preauthentication field. If
	he desires, he may also store additional key pairs on the KDC; these
	may be requested in addition to the primary. When the client
	requests initial authentication using public key cryptography, it
	must then include in its request, instead of a PA-PK-AS-REQ, the
	following preauthentication sequence:
	PA-PK-KEY-REQ ::= SEQUENCE {
	-- PA TYPE 17
	signedPKAuth [0] SignedPKAuth,
	trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
	-- CAs that the client trusts
	keyIDList [2] SEQUENCE OF Checksum OPTIONAL
	-- payload is hash of public key
	-- corresponding to desired
	-- private key
	-- if absent, KDC will return all
	-- stored private keys
	}
	Checksum ::= SEQUENCE {
	cksumtype [0] INTEGER,
	checksum [1] OCTET STRING
	} -- as specified by RFC 1510
	SignedPKAuth ::= SEQUENCE {
	pkAuth [0] PKAuthenticator,
	pkAuthSig [1] Signature
	-- of pkAuth
	-- using the symmetric key K2
	}
	If a keyIDList is present, the first identifier should indicate
	the primary private key. No public key certificate is required,
	since the KDC stores the public key along with the private key.
	If there is no keyIDList, all the user's private keys are returned.
	Upon receipt, the KDC verifies the signature using K2. If the
	verification fails, the KDC sends back an error of type
	KDC_ERR_INVALID_SIG. If the signature verifies, but the requested
	keys are not found on the KDC, then the KDC sends back an error of
	type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as
	described in Section 3.2, except that in addition, the KDC appends
	the following preauthentication sequence:
	PA-PK-KEY-REP ::= SEQUENCE {
	-- PA TYPE 18
	encKeyRep [0] EncryptedData
	-- of type EncKeyReply
	-- using the symmetric key K2
	}
	EncKeyReply ::= SEQUENCE {
	keyPackList [0] SEQUENCE OF KeyPack,
	-- the first KeyPair is
	-- the primary key pair
	nonce [1] INTEGER
	-- binds reply to request
	-- must be identical to the nonce
	-- sent in the SignedAuthPack
	}
	KeyPack ::= SEQUENCE {
	keyID [0] Checksum,
	encPrivKey [1] OCTET STRING
	}
	Upon receipt of the reply, the client extracts the encrypted private		- Diffie-Hellman public/private key pairs
	keys (and may store them, at the client's option). The primary		- SHA1 digest and DSA for signatures
	private key, which must be the first private key in the keyPack		- 3-key triple DES keys derived from the Diffie-Hellman Exchange
	SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;		- 3-key triple DES Temporary and Reply keys
	this key in turn is used to decrypt the main reply as described in
	Section 3.2.
	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 or Public Key		that use either the Standard Public Key Authentication. However,
	Authentication with a Digital Signature. However, if these users		if these users are registered with the KDC, it is recommended that
	are registered with the KDC, it is recommended that the database		the database record for these users be modified to an additional
	record for these users be modified to include three additional flags		flag in the attributes field to indicate that the user should
	in the attributes field.		authenticate using PKINIT. If this flag is set and a request
			message does not contain the PKINIT preauthentication field, then
	The first flag, use_standard_pk_init, indicates that the user should		the KDC sends back as error of type KDC_ERR_PREAUTH_REQUIRED
	authenticate using standard PKINIT as described in Section 3.2. The		indicating that a preauthentication field of type PA-PK-AS-REQ must
	second flag, use_digital_signature, indicates that the user should
	authenticate using digital signature PKINIT as described in Section
	3.3. The third flag, store_private_key, indicates that the user
	has stored his private key on the KDC and should retrieve it using
	the exchange described in Section 3.4.
	If one of the preauthentication fields defined above is included in
	the request, then the KDC shall respond as described in Sections 3.2
	through 3.4, ignoring the aforementioned database flags. If more
	than one of the preauthentication fields is present, the KDC shall
	respond with an error of type KDC_ERR_PREAUTH_FAILED.
	In the event that none of the preauthentication fields defined above
	are included in the request, the KDC checks to see if any of the
	above flags are set. If the first flag is set, then it sends back
	an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
	preauthentication field of type PA-PK-AS-REQ must be included in the
	request.
	Otherwise, if the first flag is clear, but the second flag is set,
	then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
	indicating that a preauthentication field of type PA-PK-AS-SIGN must
	be included in the request.
	Lastly, if the first two flags are clear, but the third flag is set,
	then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
	indicating that a preauthentication field of type PA-PK-KEY-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
	skipping to change at line 1031 ¶		skipping to change at line 819 ¶
	deceptive interactions.		deceptive interactions.
	Lastly, PKINIT calls for randomly generated keys for conventional		Lastly, PKINIT calls for randomly generated keys for conventional
	cryptosystems. Many such systems contain systematically "weak"		cryptosystems. Many such systems contain systematically "weak"
	keys. PKINIT implementations MUST avoid use of these keys, either		keys. PKINIT implementations MUST avoid use of these keys, either
	by discarding those keys when they are generated, or by fixing them		by discarding those keys when they are generated, or by fixing them
	in some way (e.g., by XORing them with a given mask). These		in some way (e.g., by XORing them with a given mask). These
	precautions vary from system to system; it is not our intention to		precautions vary from system to system; it is not our intention to
	give an explicit recipe for them here.		give an explicit recipe for them here.
	5. Transport Issues		6. Transport Issues
	Certificate chains can potentially grow quite large and span several		Certificate chains can potentially grow quite large and span several
	UDP packets; this in turn increases the probability that a Kerberos		UDP packets; this in turn increases the probability that a Kerberos
	message involving PKINIT extensions will be broken in transit. In		message involving PKINIT extensions will be broken in transit. In
	light of the possibility that the Kerberos specification will		light of the possibility that the Kerberos specification will
	require KDCs to accept requests using TCP as a transport mechanism,		require KDCs to accept requests using TCP as a transport mechanism,
	we make the same recommendation with respect to the PKINIT		we make the same recommendation with respect to the PKINIT
	extensions as well.		extensions as well.
	6. Bibliography		7. Bibliography
	[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service		[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
	(V5). Request for Comments 1510.		(V5). Request for Comments 1510.
	[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service		[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
	for Computer Networks, IEEE Communications, 32(9):33-38. September		for Computer Networks, IEEE Communications, 32(9):33-38. September
	1994.		1994.
	[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,		[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
	A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm		A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
	skipping to change at line 1071 ¶		skipping to change at line 859 ¶
	draft-ietf-cat-pktapp-00.txt		draft-ietf-cat-pktapp-00.txt
	[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos		[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
	Using Public Key Cryptography. Symposium On Network and Distributed		Using Public Key Cryptography. Symposium On Network and Distributed
	System Security, 1997.		System Security, 1997.
	[7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction		[7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
	Protocol. In Proceedings of the USENIX Workshop on Electronic		Protocol. In Proceedings of the USENIX Workshop on Electronic
	Commerce, July 1995.		Commerce, July 1995.
	[8] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL		[8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
	Protocol, Version 3.0 - IETF Draft.		Request for Comments 2246, January 1999.
	[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. Hously. Cryptographic Message Syntax.		[11] R. Housley. Cryptographic Message Syntax.
	draft-ietf-smime-cms-04.txt, March 1998.		draft-ietf-smime-cms-10.txt, December 1998.
	[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] Ron Rivest, MIT Laboratory for Computer Science and		[13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
	RSA Data Security, Inc. A Description of the RC2(r) Encryption		Security, Inc. A Description of the RC2(r) Encryption Algorithm
	Algorithm, November 1997.		March 1998.
			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] PKCS #6: Cryptographic Message Syntax Standard,
	An RSA Laboratories Technical Note Version 1.5
	Revised November 1, 1993
	7. Patent Issues
	The private key storage and retrieval process described in Section
	3.4 may be covered by U.S. Patent 5,418,854 (Charles Kaufman, Morrie
	Gasser, Butler Lampson, Joseph Tardo, Kannan Alagappan, all then of
	Digital Corporation). At this time, inquiries into this patent are
	inconclusive. We solicit discussion from any party who can illuminate
	the coverage of this particular patent.
	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 May 15, 1999.		This draft expires November 12, 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
	John Wray
	Digital Equipment Corporation
	550 King Street, LKG2-2/Z7
	Littleton, MA 01460
	Phone: +1 508 486 5210
	E-mail: wray@tuxedo.enet.dec.com
	Ari Medvinsky
	Matthew Hur		Matthew Hur
	Sasha Medvinsky
	CyberSafe Corporation		CyberSafe Corporation
	1605 NW Sammamish Road Suite 310		1605 NW Sammamish Road
	Issaquah WA 98027-5378		Issaquah WA 98027-5378
	Phone: +1 206 391 6000		Phone: +1 425 391 6000
	E-mail: {ari.medvinsky, matt.hur, sasha.medvinsky}@cybersafe.com		E-mail: matt.hur@cybersafe.com
			Ari Medvinsky
			Excite
			555 Broadway
			Redwood City, CA 94063
			Phone +1 650 569 2119
			E-mail: amedvins@excitecorp.com
			Sasha Medvinsky
			General Instrument
			6450 Sequence Drive
			San Diego, CA 92121
			Phone +1 619 404 2825
			E-mail: smedvinsky@gi.com
			John Wray
			Iris Associates, Inc.
			5 Technology Park Dr.
			Westford, MA 01886
			E-mail: John_Wray@iris.com
	Jonathan Trostle		Jonathan Trostle
	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. 65 change blocks.
	540 lines changed or deleted		327 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/