< draft-ietf-cat-kerberos-pk-init-01.txt		draft-ietf-cat-kerberos-pk-init-02.txt >
	INTERNET-DRAFT Clifford Neuman		INTERNET-DRAFT Clifford Neuman
	draft-ietf-cat-kerberos-pk-init-01.txt Brian Tung		draft-ietf-cat-kerberos-pk-init-02.txt Brian Tung
	Updates: RFC 1510 ISI		Updates: RFC 1510 ISI
	expires December 7, 1996 John Wray		expires April 19, 1997 John Wray
	Digital Equipment Corporation		Digital Equipment Corporation
			Jonathan Trostle
			CyberSafe Corporation
	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. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	skipping to change at line 30 ¶		skipping to change at line 32 ¶
	reference material or to cite them other than as ``work in pro-		reference material or to cite them other than as ``work in pro-
	gress.''		gress.''
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-		``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
	dow Directories on ds.internic.net (US East Coast), nic.nordu.net		dow Directories on ds.internic.net (US East Coast), nic.nordu.net
	(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific		(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
	Rim).		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-01.txt, and expires December 7, 1996.		draft-ietf-cat-kerberos-pk-init-02.txt, and expires April 19, 1997.
	Please send comments to the authors.		Please send comments to the authors.
	1. Abstract		1. Abstract
	This document defines extensions to the Kerberos protocol specifi-		This document defines extensions to the Kerberos protocol
	cation (RFC 1510, "The Kerberos Network Authentication Service		specification (RFC 1510, "The Kerberos Network Authentication
	(V5)", September 1993) to provide a method for using public key		Service (V5)", September 1993) to provide a method for using public
	cryptography during initial authentication. The method defined		key cryptography during initial authentication. The method defined
	specifies the way in which preauthentication data fields and error		specifies the way in which preauthentication data fields and error
	data fields in Kerberos messages are to be used to transport public		data fields in Kerberos messages are to be used to transport public
	key data.		key data.
	2. Motivation		2. Motivation
	Public key cryptography presents a means by which a principal may		Public key cryptography presents a means by which a principal may
	demonstrate possession of a key, without ever having divulged this		demonstrate possession of a key, without ever having divulged this
	key to anyone else. In conventional cryptography, the encryption key		key to anyone else. In conventional cryptography, the encryption
	and decryption key are either identical or can easily be derived from		key and decryption key are either identical or can easily be
	one another. In public key cryptography, however, neither the public		derived from one another. In public key cryptography, however,
	key nor the private key can be derived from the other (although the		neither the public key nor the private key can be derived from the
	private key RECORD may include the information required to generate		other (although the private key RECORD may include the information
	BOTH keys). Hence, a message encrypted with a public key is private,		required to generate BOTH keys). Hence, a message encrypted with a
	since only the person possessing the private key can decrypt it;		public key is private, since only the person possessing the private
	similarly, someone possessing the private key can also encrypt a		key can decrypt it; similarly, someone possessing the private key
	message, thus providing a digital signature.		can also encrypt a message, thus providing a digital signature.
	Furthermore, conventional keys are often derived from passwords, so		Furthermore, conventional keys are often derived from passwords, so
	messages encrypted with these keys are susceptible to dictionary		messages encrypted with these keys are susceptible to dictionary
	attacks, whereas public key pairs are generated from a pseudo-random		attacks, whereas public key pairs are generated from a
	number sequence. While it is true that messages encrypted using		pseudo-random number sequence. While it is true that messages
	public key cryptography are actually encrypted with a conventional		encrypted using public key cryptography are actually encrypted with
	secret key, which is in turn encrypted using the public key pair,		a conventional secret key, which is in turn encrypted using the
	the secret key is also randomly generated and is hence not vulnerable		public key pair, the secret key is also randomly generated and is
	to a dictionary attack.		hence not vulnerable to a dictionary attack.
	The advantages provided by public key cryptography have produced a		The advantages provided by public key cryptography have produced a
	demand for its integration into the Kerberos authentication protocol.		demand for its integration into the Kerberos authentication
	The primary advantage of registering public keys with the KDC lies in		protocol. The public key integration into Kerberos described in
	the ease of recovery in case the KDC is compromised. With Kerberos as		this document has three goals.
	it currently stands, compromise of the KDC is disastrous. All
	keys become known by the attacker and all keys must be changed.
	If users register public keys, compromise of the KDC does not divulge		First, by allowing users to register public keys with the KDC, the
	their private key. Compromise of security on the KDC is still a		KDC can be recovered much more easily in the event it is
	problem, since an attacker can impersonate any user by certifying a		compromised. With Kerberos as it currently stands, compromise of
	bogus key with the KDC's private key. However, all bogus		the KDC is disastrous. All keys become known by the attacker and
	certificates can be invalidated by revoking and changing the		all keys must be changed. Second, we allow users that have public
	KDC's public key. Legitimate users have to re-certify their public		key certificates signed by outside authorities to obtain Kerberos
	keys with the new KDC key, but the users's keys themselves do not		credentials for access to Kerberized services. Third, we obtain the
	need to be changed. Keys for application servers are conventional		above benefits while maintaining the performance advantages of
	symmetric keys and must be changed.		Kerberos over protocols that use only public key authentication.
	Note: If a user stores his private key, in an encrypted form, on the		If users register public keys, compromise of the KDC does not
	KDC, then he does have to change the key pair, since the private key		divulge their private key. Compromise of security on the KDC is
	is encrypted using a symmetric key derived from a password (as		still a problem, since an attacker can impersonate any user by
	described below), and is therefore vulnerable to dictionary attack.		creating a ticket granting ticket for the user. When the compromise
	Assuming good password policy, however, legitimate users may be		is detected, the KDC can be cleaned up and restored from backup
	allowed to use the old password for a limited time, solely for the		media and loaded with a backup private/public key pair. Keys for
	purpose of changing the key pair. The realm administrator is then		application servers are conventional symmetric keys and must be
	not forced to re-key all users.		changed.
	There are two important areas where public key cryptography will have		Note: If a user stores his private key, in an encrypted form, on
	immediate use: in the initial authentication of users registered with		the KDC, then it may be desirable to change the key pair, since the
	the KDC or using public key certificates from outside authorities,		private key is encrypted using a symmetric key derived from a
	and to establish inter-realm keys for cross-realm authentication.		password (as described below), and can therefore be vulnerable to
	This memo describes a method by which the first of these can be done.		dictionary attack if a good password policy is not used.
	The second case will be the topic for a separate proposal.		Alternatively, if the encrypting symmetric key has 56 bits, then it
			may also be desirable to change the key pair after a short period
			due to the short key length. The KDC does not have access to the
			user's unencrypted private key.
			There are two important areas where public key cryptography will
			have immediate use: in the initial authentication of users
			registered with the KDC or using public key certificates from
			outside authorities, and to establish inter-realm keys for
			cross-realm authentication. This memo describes a method by which
			the first of these can be done. The second case will be the topic
			for a separate proposal.
	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		discussions over several years between members of the SAAG, the
	IETF-CAT working group, and the PSRG, regarding integration of		IETF-CAT working group, and the PSRG, regarding integration of
	Kerberos and SPX. Some ideas are drawn from the DASS system, and		Kerberos and SPX. Some ideas are drawn from the DASS system, and
	similar extensions have been discussed for use in DCE. These changes		similar extensions have been discussed for use in DCE. These
	are by no means endorsed by these groups. This is an attempt to		changes are by no means endorsed by these groups. This is an
	revive some of the goals of that group, and the proposal approaches		attempt to revive some of the goals of that group, and the
	those goals primarily from the Kerberos perspective.		proposal approaches those goals primarily from the Kerberos
			perspective.
	3. Initial authentication of users with public keys		3. Initial authentication of users with public keys
	This section describes the extensions to Version 5 of the Kerberos		This section describes the extensions to Version 5 of the Kerberos
	protocol that will support the use of public key cryptography by		protocol that will support the use of public key cryptography by
	users in the initial request for a ticket granting ticket. This		users in the initial request for a ticket granting ticket.
	proposal is based on the implementation already made available;
	nevertheless, we solicit any comments on modifications or additions
	to the protocol description below.
	Roughly speaking, the following changes to RFC 1510 are proposed:		Roughly speaking, the following changes to RFC 1510 are proposed:
	a. The KDC's response is encrypted using a random nonce key,		Users can initially authenticate using public key or conventional
	rather than the user's secret key.		(symmetric key) cryptography. After a KDC compromise, the KDC
	b. This random key accompanies the response in a		replies with an error message that informs the client of the new
	preauthentication field, encrypted and signed using the		KDC public backup key. Users must authenticate using public key
	public key pairs of the user and the KDC.		cryptography in response to the error message. If applicable, the
	Certificate and message formats are also defined in this section.		client generates the new user secret key at this point as well.
	This proposal will allow users either to use keys registered directly		Public key initial authentication is performed using either the
	with the KDC, or to use keys already registered for use with X.509,		RSA encryption or Diffie Hellman public key algorithms. There is
	PEM, or PGP, to obtain Kerberos credentials. These credentials can		also an option to allow the user to store his/her private key
	then be used, as before, with application servers supporting Kerberos.		encrypted in the user password in the KDC database; this option
	Use of public key cryptography will not be a requirement for Kerberos,		solves the problem of transporting the user private key to
	but if one's organization runs a KDC supporting public key, then users		different workstations. The combination of this option and the
	may choose to be registered with a public key pair, instead of the		provision for conventional symmetric key authentication allows
	current secret key.		organizations to smoothly migrate to public key cryptography.
			This proposal will allow users either to use keys registered
			directly with the KDC, or to use keys already registered for use
			with X.509, PEM, or PGP, to obtain Kerberos credentials. These
			credentials can then be used, as before, with application servers
			supporting Kerberos. Use of public key cryptography will not be a
			requirement for Kerberos, but if one's organization runs a KDC
			supporting public key, then users may choose to be registered with
			a public key pair, instead of or in addition to the current secret
			key.
	The application request and response between Kerberos clients and		The application request and response between Kerberos clients and
	application servers will continue to be based on conventional		application servers will continue to be based on conventional
	cryptography, or will be converted to use user-to-user		cryptography, or will be converted to use user-to-user
	authentication. There are performance issues and other reasons		authentication. There are performance issues and other reasons
	that servers may be better off using conventional cryptography.		that servers may be better off using conventional cryptography.
	For this proposal, we feel that 80 percent of the benefits of		For this proposal, we feel that 80 percent of the benefits of
	integrating public key with Kerberos can be attained for 20 percent		integrating public key with Kerberos can be attained for 20 percent
	of the effort, by addressing only initial authentication. This		of the effort, by addressing only initial authentication. This
	proposal does not preclude separate extensions.		proposal does not preclude separate extensions.
	With these changes, users will be able to register public keys, only		With these changes, users will be able to register public keys,
	in realms that support public key, and they will then only be able		only in realms that support public key, but they will still be able
	to perform initial authentication from a client that supports public key,		to perform initial authentication from a client that does not
	although they will be able to use services registered in any realm.		support public key. They will be able to use services registered in
	Furthermore, users registered with conventional keys will be able		any realm. Furthermore, users registered with conventional keys
	to use any client.		will be able to use any client.
	This proposal addresses three ways in which users may use public key		This proposal addresses three ways in which users may use public
	cryptography for initial authentication with Kerberos, with minimal		key cryptography for initial authentication with Kerberos, with
	change to the existing protocol. Users may register keys directly		minimal change to the existing protocol. Users may register keys
	with the KDC, or they may present certificates by outside certification		directly with the KDC, or they may present certificates by outside
	authorities (or certifications by other users) attesting to the		certification authorities (or certifications by other users)
	association of the public key with the named user. In both cases,		attesting to the association of the public key with the named user.
	the end result is that the user obtains a conventional ticket		In both cases, the end result is that the user obtains a
	granting ticket or conventional server ticket that may be used for		conventional ticket granting ticket or conventional server ticket
	subsequent authentication, with such subsequent authentication using		that may be used for subsequent authentication, with such
	only conventional cryptography.		subsequent authentication using only conventional cryptography.
	Additionally, users may also register a digital signature key with		Additionally, users may also register a digital signature
	the KDC. We provide this option for the licensing benefits, as well		verification key with the KDC. We provide this option for the
	as a simpler variant of the initial authentication exchange. However,		licensing benefits, as well as a simpler variant of the initial
	this option relies on the client to generate random keys.		authentication exchange. However, this option relies on the client
			to generate random keys.
	We first consider the case where the user's key is registered with		We first consider the case where the user's key is registered with
	the KDC.		the KDC.
	3.1 Definitions		3.1 Definitions
	Before we proceed, we will lay some groundwork definitions for		Before we proceed, we will lay some groundwork definitions for
	encryption and signatures. We propose the following definitions		encryption and signatures. We propose the following definitions
	of signature and encryption modes (and their corresponding values		of signature and encryption modes (and their corresponding values
	on the wire):		on the wire):
	#define ENCTYPE_SIGN_MD5_RSA 0x0011		#define ENCTYPE_SIGN_MD5_RSA 0x0011
	#define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021		#define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021
	#define ENCTYPE_ENCRYPT_RSA_PUB 0x0022		#define ENCTYPE_ENCRYPT_RSA_PUB 0x0022
	allowing further modes to be defined accordingly.		allowing further modes to be defined accordingly.
	In the exposition below, we will use the notation E (T, K) to denote		In the exposition below, we will use the notation E (T, K) to
	the encryption of data T, with key (or parameters) K.		denote the encryption of data T, with key (or parameters) K.
	If E is ENCTYPE_SIGN_MD5_RSA, then		If E is ENCTYPE_SIGN_MD5_RSA, then
	E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)}		E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)}
	If E is ENCTYPE_ENCRYPT_RSA_PRIV, then		If E is ENCTYPE_ENCRYPT_RSA_PRIV, then
	E (T, K) = RSAEncryptPrivate (T, K)		E (T, K) = RSAEncryptPrivate (T, K)
	Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then		Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then
	E (T, K) = RSAEncryptPublic (T, K)		E (T, K) = RSAEncryptPublic (T, K)
	3.2 Initial request for user registered with public key on KDC		3.2 Initial request for user registered with public key on KDC
	In this scenario it is assumed that the user is registered with a		In this scenario it is assumed that the user is registered with a
	public key on the KDC. The user's private key may be held by the		public key on the KDC. The user's private key may be held by the
	user, or it may be stored on the KDC, encrypted so that it cannot be		user, or it may be stored on the KDC, encrypted so that it cannot
	used by the KDC.		be used by the KDC.
	3.2.1 User's private key is stored locally		3.2.1 User's private key is stored locally
	If the user stores his private key locally, the initial request to		Implementation of the changes in this section is REQUIRED.
	the KDC for a ticket granting ticket proceeds according to RFC 1510,
	except that a preauthentication field containing a nonce signed by		In this section, we present the basic Kerberos V5 pk-init protocol
	the user's private key is included. The preauthentication field		that all conforming implementations must support. The key features
	may also include a list of the root certifiers trusted by the user.		of the protocol are: (1) easy, automatic (for the clients) recovery
			after a KDC compromise, (2) the ability for a realm to support a
			mix of old and new Kerberos V5 clients with the new clients being a
			mix of both public key and symmetric key configured clients, and
			(3) support for Diffie-Hellman (DH) key exchange as well as RSA
			public key encryption. The benefit of having new clients being able
			to use either symmetric key or public key initial authentication is
			that it allows an organization to roll out the new clients as
			rapidly as possible without having to be concerned about the need
			to purchase additional hardware to support the CPU intensive public
			key cryptographic operations.
			In order to give a brief overview of the four protocols in this
			section, we now give diagrams of the protocols. We denote
			encryption of message M with key K by {M}K and the signature of
			message M with key K by [M]K. All messages from the KDC to the
			client are AS_REP messages unless denoted otherwise; similarly, all
			messages from the client to the KDC are AS_REQ messages unless
			denoted otherwise. Since only the padata fields are affected by
			this specification in the AS_REQ and AS_REP messages, we do not
			show the other fields. We first show the RSA encryption option in
			normal mode:
			certifier list, [cksum, time, nonce, kdcRealm,
			kdcName]User PrivateKey
			C ------------------------------------------------------> KDC
			list of cert's, {[encReplyKey, nonce]KDC privkey}
			EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
			C <------------------------------------------------------ KDC
			We now show RSA encryption in recovery mode:
			certifier list, [cksum, time, nonce, kdcRealm,
			kdcName]User PrivateKey
			C ------------------------------------------------------> KDC
			KRB_ERROR (error code KDC_RECOVERY_NEEDED)
			error data: [nonce, algID (RSA),
			KDC PublicKey Kvno and PublicKey, KDC Salt]
			Signed with KDC PrivateKey
			C <------------------------------------------------------ KDC
			certifier list, [cksum, time, nonce, kdcRealm, kdcName,
			{newUserSymmKey, nonce}KDC public key]User PrivateKey
			C ------------------------------------------------------> KDC
			list of cert's, {[encReplyKey, nonce]KDC privkey}
			EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
			C <------------------------------------------------------ KDC
			Next, we show Diffie Hellman in normal mode:
			certifier list, [cksum, time, nonce, kdcRealm, kdcName,
			User DH public parameter]User PrivateKey
			C ------------------------------------------------------> KDC
			list of cert's, {encReplyKey, nonce}DH shared symmetric
			key, [KDC DH public parameter]KDC Private Key
			C <------------------------------------------------------ KDC
			Finally, we show Diffie Hellman in recovery mode:
			certifier list, [cksum, time, nonce, kdcRealm, kdcName,
			User DH public parameter]User PrivateKey
			C ------------------------------------------------------> KDC
			KRB_ERROR (error code KDC_RECOVERY_NEEDED)
			error data: [nonce, algID (DH), KDC DH public
			parameter, KDC DH ID, KDC PublicKey
			Kvno and PublicKey, KDC Salt]
			Signed with KDC PrivateKey
			C <------------------------------------------------------ KDC
			certifier list, [cksum, time, nonce, kdcRealm,
			kdcName, User DH public parameter, {newUserSymmKey,
			nonce}DH shared key, KDC DH ID]User PrivateKey
			C ------------------------------------------------------> KDC
			list of cert's, {encReplyKey, nonce}DH shared
			symmetric key
			C <------------------------------------------------------ KDC
			If the user stores his private key locally, the initial request
			to the KDC for a ticket granting ticket proceeds according to
			RFC 1510, except that a preauthentication field containing a
			nonce signed by the user's private key is included. The
			preauthentication field may also include a list of the root
			certifiers trusted by the user.
	PA-PK-AS-ROOT ::= SEQUENCE {		PA-PK-AS-ROOT ::= SEQUENCE {
	rootCert[0] SEQUENCE OF OCTET STRING,		rootCert[0] SEQUENCE OF OCTET STRING,
	signedAuth[1] SignedPKAuthenticator		signedAuth[1] SignedPKAuthenticator
	}		}
	SignedPKAuthenticator ::= SEQUENCE {		SignedPKAuthenticator ::= SEQUENCE {
	authent[0] PKAuthenticator,		authent[0] PKAuthenticator,
	authentSig[1] Signature		authentSig[1] Signature
	}		}
	skipping to change at line 223 ¶		skipping to change at line 330 ¶
	PA-PK-AS-ROOT ::= SEQUENCE {		PA-PK-AS-ROOT ::= SEQUENCE {
	rootCert[0] SEQUENCE OF OCTET STRING,		rootCert[0] SEQUENCE OF OCTET STRING,
	signedAuth[1] SignedPKAuthenticator		signedAuth[1] SignedPKAuthenticator
	}		}
	SignedPKAuthenticator ::= SEQUENCE {		SignedPKAuthenticator ::= SEQUENCE {
	authent[0] PKAuthenticator,		authent[0] PKAuthenticator,
	authentSig[1] Signature		authentSig[1] Signature
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	cksum[0] Checksum OPTIONAL,		cksum[0] Checksum OPTIONAL,
	cusec[1] INTEGER,		cusec[1] INTEGER,
	ctime[2] KerberosTime,		ctime[2] KerberosTime,
	nonce[3] INTEGER,		nonce[3] INTEGER,
	kdcRealm[4] Realm,		kdcRealm[4] Realm,
	kdcName[5] PrincipalName		kdcName[5] PrincipalName,
			clientPubValue[6] SubjectPublicKeyInfo OPTIONAL,
			-- DH algorithm
			recoveryData[7] RecoveryData OPTIONAL
			-- Recovery Alg.
			}
			RecoveryData ::= SEQUENCE {
			clientRecovData[0] ClientRecovData,
			kdcPubValueId[1] INTEGER OPTIONAL
			-- DH algorithm, copied
			-- from KDC response
			}
			ClientRecovData ::= CHOICE {
			newPrincKey[0] EncryptedData, -- EncPaPkAsRoot
			-- encrypted with
			-- either KDC
			-- public key or
			-- DH shared key
			recovDoneFlag[1] INTEGER -- let KDC know that
			-- recovery is done
			-- when user uses a
			-- mix of clients or
			-- does not want to
			-- keep a symmetric
			-- key in the database
			}
			EncPaPkAsRoot ::= SEQUENCE {
			newSymmKey[0] EncryptionKey -- the principal's new
			-- symmetric key
			nonce[1] INTEGER -- the same nonce as
			-- the one in the
			-- PKAuthenticator
	}		}
	Signature ::= SEQUENCE {		Signature ::= SEQUENCE {
	sigType[0] INTEGER,		sigType[0] INTEGER,
	kvno[1] INTEGER OPTIONAL,		kvno[1] INTEGER OPTIONAL,
	sigHash[2] OCTET STRING		sigHash[2] OCTET STRING
	}		}
	Notationally, sigHash is then		Notationally, sigHash is then
	sigType (authent, userPrivateKey)		sigType (authent, userPrivateKey)
	where userPrivateKey is the user's private key (corresponding to the		where userPrivateKey is the user's private key (corresponding to the
	public key held in the user's database record). Valid sigTypes are		public key held in the user's database record). Valid sigTypes are
	thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect		thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect
	that other types may be listed (and given on-the-wire values between		that other types may be listed (and given on-the-wire values between
	0x0011 and 0x001f).		0x0011 and 0x001f).
	The format of each certificate depends on the particular		The format of each certificate depends on the particular service
	service used. (Alternatively, the KDC could send, with its reply,		used. (Alternatively, the KDC could send, with its reply, a
	a sequence of certifications (see below), but since the KDC is likely		sequence of certifications (see below), but since the KDC is likely
	to have more certifications than users have trusted root certifiers,		to have more certifications than users have trusted root certifiers,
	we have chosen the first method.) In the event that the client		we have chosen the first method.) In the event that the client
	believes it already possesses the current public key of the KDC,		believes it already possesses the current public key of the KDC, a
	a zero-length root-cert field is sent.		zero-length root-cert field is sent.
	The fields in the signed authenticator are the same as those		The fields in the signed authenticator are the same as those in the
	in the Kerberos authenticator; in addition, we include a client-		Kerberos authenticator; in addition, we include a client-generated
	generated nonce, and the name of the KDC. The structure is itself		nonce, and the name of the KDC. The structure is itself signed
	signed using the user's private key corresponding to the public key		using the user's private key corresponding to the public key
	registered with the KDC.		registered with the KDC. We include the newSymmKey field so clients
			can generate a new symmetric key (for users, this key is based on
			a password and a salt value generated by the KDC) and
			confidentially send this key to the KDC during the recovery phase.
	Typically, preauthentication using a secret key would not be included,		We now describe the recovery phase of the protocol. There is a bit
	but if included it may be ignored by the KDC. (We recommend that it		associated with each principal in the database indicating whether
	not be included: even if the KDC should ignore the preauthentication,		recovery for that principal is necessary. After a KDC compromise,
	an attacker may not, and use an intercepted message to guess the		the KDC software is reloaded from backup media and a new backup
	password off-line.)		KDC public/private pair is generated. The public half of this pair
			is then either made available to the KDC, or given to the
			appropriate certification authorities for certification. The private
			half is not made available to the KDC until after the next
			compromise clean-up. If clients are maintaining a copy of the KDC
			public key, they also have a copy of the backup public key.
	The response from the KDC would be identical to the response in RFC 1510,		After the reload of KDC software, the bits associated with
	except that instead of being encrypted in the secret key shared by the		recovery of each principal are all set. The KDC clears the bit
	client and the KDC, it is encrypted in a random key freshly generated		for each principal that undergoes the recovery phase. In addition,
	by the KDC (of type ENCTYPE_ENC_CBC_CRC). A preauthentication field		there is a bit associated with each principal to indicate whether
	(specified below) accompanies the response, optionally containing a		there is a valid symmetric key in the database for the principal.
	certificate with the public key for the KDC (since we do not assume		These bits are all cleared after the reload of the KDC software
	that the client knows this public key), and a package containing the		(the old symmetric keys are no longer valid). Finally, there is a
	secret key in which the rest of the response is encrypted, along with		bit associated with each principal indicating whether that
	the same nonce used in the rest of the response, in order to prevent		principal still uses non-public key capable clients. If a user
	replays. This package is itself encrypted with the private key of the		principal falls into this category, a public key capable client
	KDC, then encrypted with the public key of the user.		cannot transparently re-establish a symmetric key for that user,
			since the older clients would not be able to compute the new
			symmetric key that includes hashing the password with a KDC
			supplied salt value. The re-establishment of the symmetric key
			in this case is outside the scope of this protocol.
			One method of re-establishing a symmetric key for public key
			capable clients is to generate a hash of the user password and a
			KDC supplied salt value. The KDC salt is changed after every
			compromise of the KDC. In the recovery protocol, if the principal
			does not still use old clients, the KDC supplied salt is sent to
			the client principal in a KRB_ERROR message with error code
			KDC_RECOVERY_NEEDED. The error data field of the message contains
			the following structure which is encoded into an octet string.
			PA-PK-KDC-ERR ::= CHOICE {
			recoveryDhErr SignedDHError, -- Used during recovery
			-- when algorithm is DH
			-- based
			recoveryPKEncErr SignedPKEncError -- Used during recovery
			-- for PK encryption
			-- (RSA,...)
			}
			SignedDHError ::= SEQUENCE {
			dhErr DHError,
			dhErrSig Signature
			}
			SignedPKEncError ::= SEQUENCE {
			pkEncErr PKEncryptError,
			pkEncErrSig Signature
			}
			DHError ::= SEQUENCE {
			nonce INTEGER, -- From AS_REQ
			algorithmId INTEGER, -- DH algorithm
			kdcPubValue SubjectPublicKeyInfo, -- DH algorithm
			kdcPubValueId INTEGER, -- DH algorithm
			kdcPublicKeyKvno INTEGER OPTIONAL, -- New KDC public
			-- key kvno
			kdcPublicKey OCTET STRING OPTIONAL, -- New KDC pubkey
			kdcSalt OCTET STRING OPTIONAL -- If user uses
			-- only new
			-- clients
			}
			PKEncryptError ::= SEQUENCE {
			nonce INTEGER, -- From AS_REQ
			algorithmId INTEGER, -- Public Key
			-- encryption alg
			kdcPublicKeyKvno INTEGER OPTIONAL, -- New KDC public
			-- key kvno
			kdcPublicKey OCTET STRING OPTIONAL, -- New KDC public
			-- key
			kdcSalt OCTET STRING OPTIONAL -- If user uses
			-- only new
			-- clients
			}
			The KDC_RECOVERY_NEEDED error message is sent in response to a
			client AS_REQ message if the client principal needs to be
			recovered, unless the client AS_REQ contains the PKAuthenticator
			with a nonempty RecoveryData field (in this case the client has
			already received the KDC_RECOVERY_NEEDED error message. We will
			also see in section 3.2.2 that a different error response is
			sent by the KDC if the encrypted user private key is stored in
			the KDC database.) If the client principal uses only new clients,
			then the kdcSalt field is returned; otherwise, the kdcSalt field
			is absent.
			If the client uses the Diffie Hellman algorithm during the recovery
			phase then the DHError field contains the public Diffie Hellman
			parameter (kdcPubValue) for the KDC along with an identifier
			(kdcPubValueID). The client will then send this identifier to
			the KDC in an AS_REQ message; the identifier allows the KDC to
			look up the Diffie Hellman private value corresponding to the
			identifier. Depending on how often the KDC updates its private
			Diffie Hellman parameters, it will have to store anywhere between a
			handful and several dozen of these identifiers and their parameters.
			The KDC must send its Diffie Hellman public value to the client
			first so the client can encrypt its new symmetric key.
			In the case where the user principal does not need to be recovered
			and the user still uses old clients as well as new clients, the
			KDC_ERR_NULL_KEY error is sent in response to symmetric AS_REQ
			messages when there is no valid symmetric key in the KDC database.
			This situation can occur if the user principal has been recovered
			but no new symmetric key has been established in the database.
			In addition, the two error messages with error codes
			KDC_ERR_PREAUTH_FAILED and KDC_ERR_PREAUTH_REQUIRED are modified
			so the error data contains the kdcSalt encoded as an OCTET STRING.
			The reason for the modification is to allow principals that use
			new clients only to have their symmetric key transparently updated
			by the client software during the recovery phase. The kdcSalt is
			used to create the new symmetric key. As a performance optimization,
			the kdcSalt is stored in the /krb5/salt file along with the realm.
			Thus the /krb5/salt file consists of realm-salt pairs. If the file
			is missing, or the salt is not correct, the above error messages
			allow the client to find out the correct salt. New clients which
			are configured for symmetric key authentication attempt to
			preauthenticate with the salt from the /krb5/salt file as an
			input into their key, and if the file is not present, the new client
			does not use preauthentication. The error messages above return
			either the correct salt to use, or no salt at all which indicates
			that the principal is still using old clients (the client software
			should use the existing mapping from the user password to the
			symmetric key).
			In order to assure interoperability between clients from different
			vendors and organizations, a standard algorithm is needed for
			creating the symmetric key from the principal password and kdcSalt.
			The algorithm for creating the symmetric key is as follows: take the
			SHA-1 hash of the kdcSalt concatenated with the principal password
			and use the 20 byte output as the input into the existing key
			generation process (string to key function). After a compromise, the
			KDC changes the kdcSalt; thus, the recovery algorithm allows users
			to obtain a new symmetric key without actually changing their
			password.
			The response from the KDC would be identical to the response in RFC
			1510, except that instead of being encrypted in the secret key
			shared by the client and the KDC, it is encrypted in a random key
			freshly generated by the KDC (of type ENCTYPE_ENC_CBC_CRC). A
			preauthentication field (specified below) accompanies the response,
			optionally containing a certificate with the public key for the KDC
			(since we do not assume that the client knows this public key), and
			a package containing the secret key in which the rest of the
			response is encrypted, along with the same nonce used in the rest
			of the response, in order to prevent replays. This package is itself
			signed with the private key of the KDC, then encrypted with the
			symmetric key that is returned encrypted in the public key of the
			user (or for Diffie Hellman, encrypted in the shared secret Diffie
			Hellman symmetric key).
			Pictorially, in the public key encryption case we have:
			kdcCert, {[encReplyKey, nonce] Sig w/KDC
			privkey}EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
			Pictorially, in the Diffie Hellman case we have:
			kdcCert, {encReplyKey, nonce}DH shared symmetric key,
			[DH public value]Sig w/KDC privkey
	PA-PK-AS-REP ::= SEQUENCE {		PA-PK-AS-REP ::= SEQUENCE {
	kdcCert[0] SEQUENCE OF Certificate,		kdcCert[0] SEQUENCE OF Certificate,
	encryptShell[1] EncryptedData, -- EncPaPkAsRepPartShell		encryptShell[1] EncryptedData,
	-- encrypted by encReplyTmpKey		-- EncPaPkAsRepPartShell
	encryptKey[2] EncryptedData -- EncPaPkAsRepTmpKey		-- encrypted by
	-- encrypted by userPubliKey		-- encReplyTmpKey or DH
			-- shared symmetric key
			pubKeyExchange[2] PubKeyExchange OPTIONAL,
			-- a choice between
			-- a KDC signed DH
			-- value and a public
			-- key encrypted
			-- symmetric key.
			-- Not needed after
			-- recovery when
			-- DH is used.
			}
			PubKeyExchange ::= CHOICE {
			signedDHPubVal SignedDHPublicValue,
			encryptKey EncryptedData
			-- EncPaPkAsRepTmpKey
			-- encrypted by
			-- userPublicKey
			}
			SignedDHPublicValue ::= SEQUENCE {
			dhPublic[0] SubjectPublicKeyInfo,
			dhPublicSig[1] Signature
	}		}
	EncPaPkAsRepPartShell ::= SEQUENCE {		EncPaPkAsRepPartShell ::= SEQUENCE {
	encReplyPart[0] EncPaPkAsRepPart,		encReplyPart[0] EncPaPkAsRepPart,
	encReplyPartSig[1] Signature -- encReplyPart		encReplyPartSig[1] Signature OPTIONAL
	-- signed by kdcPrivateKey		-- encReplyPart
			-- signed by kdcPrivateKey
			-- except not present in
			-- DH case
	}		}
	EncPaPkAsRepPart ::= SEQUENCE {		EncPaPkAsRepPart ::= SEQUENCE {
	encReplyKey[0] EncryptionKey,		encReplyKey[0] EncryptionKey,
	nonce[1] INTEGER		nonce[1] INTEGER,
	}		}
	EncPaPkAsRepTmpKey ::= SEQUENCE {		EncPaPkAsRepTmpKey ::= SEQUENCE {
	encReplyTmpKey[0] EncryptionKey		encReplyTmpKey[0] EncryptionKey
	}		}
	Notationally, assume that encryptPack is encrypted (or signed) with
	algorithm Ak, and that encryptShell is encrypted with algorithm Au.
	Then, encryptShell is
	Au (Ak ({encReplyKey, nonce}, kdcPrivateKey), userPublicKey)
	where kdcPrivateKey is the KDC's private key, and userPublicKey is the
	user's public key.
	The kdc-cert specification is lifted, with slight modifications,		The kdc-cert specification is lifted, with slight modifications,
	from v3 of the X.509 certificate specification:		from v3 of the X.509 certificate specification:
	Certificate ::= SEQUENCE {		Certificate ::= SEQUENCE {
	version[0] Version DEFAULT v1 (1),		version[0] Version DEFAULT v1 (1),
	serialNumber[1] CertificateSerialNumber,		serialNumber[1] CertificateSerialNumber,
	signature[2] AlgorithmIdentifier,		signature[2] AlgorithmIdentifier,
	issuer[3] PrincipalName,		issuer[3] PrincipalName,
	validity[4] Validity,		validity[4] Validity,
	subjectRealm[5] Realm,		subjectRealm[5] Realm,
	subject[6] PrincipalName,		subject[6] PrincipalName,
	subjectPublicKeyInfo[7] SubjectPublicKeyInfo,		subjectPublicKeyInfo[7] SubjectPublicKeyInfo,
	issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL,		issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL,
	subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL,		subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL,
	authentSig[10] Signature		authentSig[10] Signature
	}		}
	The kdc-cert must have as its root certification one of the certifiers		The kdc-cert must have as its root certification one of the
	sent to the KDC with the original request. If the KDC has no such		certifiers sent to the KDC with the original request. If the KDC
	certification, then it will instead reply with a KRB_ERROR of type		has no such certification, then it will instead reply with a
	KDC_ERROR_PREAUTH_FAILED. If a zero-length root-cert was sent by the		KRB_ERROR of type KDC_ERROR_PREAUTH_FAILED. If a zero-length
	client as part of the PA-PK-AS-ROOT, then a correspondingly zero-length		root-cert was sent by the client as part of the PA-PK-AS-ROOT, then
	kdc-cert may be absent, in which case the client uses its copy of the		a correspondingly zero-length kdc-cert may be absent, in which case
	KDC's public key.		the client uses its copy of the KDC's public key. In the case of
			recovery, the client uses its copy of the backup KDC public key.
	Upon receipt of the response from the KDC, the client will verify the		Upon receipt of the response from the KDC, the client will verify
	public key for the KDC from PA-PK-AS-REP preauthentication data field,		the public key for the KDC from PA-PK-AS-REP preauthentication data
	The certificate must certify the key as belonging to a principal whose		field. The certificate must certify the key as belonging to a
	name can be derived from the realm name. If the certificate checks		principal whose name can be derived from the realm name. If the
	out, the client then decrypts the EncPaPkAsRepPart using the private		certificate checks out, the client then decrypts the EncPaPkAsRepPart
	key of the user, and verifies the signature of the KDC. It then uses		and verifies the signature of the KDC. It then uses the random key
	the random key contained therein to decrypt the rest of the response,		contained therein to decrypt the rest of the response, and continues
	and continues as per RFC 1510. Because there is direct trust between		as per RFC 1510. Because there is direct trust between the user and
	the user and the KDC, the transited field of the ticket returned by		the KDC, the transited field of the ticket returned by the KDC should
	the KDC should remain empty. (Cf. Section 3.3.)		remain empty. (Cf. Section 3.3.)
	3.2.2. Private key held by KDC		Examples
	Implementation of the changes in this section is OPTIONAL.		We now give several examples illustrating the protocols in this
			section. Encryption of message M with key K is denoted {M}K and
			the signature of message M with key K is denoted [M]K.
	When the user's private key is not carried with the user, the user may		Example 1: The requesting user principal needs to be recovered and
	encrypt the private key using conventional cryptography, and register		uses only new clients. The recovery algorithm is Diffie Hellman (DH).
	the encrypted private key with the KDC. The MD5 hash of the DES key		Then the exchange sequence between the user principal and the KDC is:
	used to encrypt the private key must also be registered with the KDC.
	We provide this option with the warning that storing the private key		Client --------> AS_REQ (with or without preauth) --------> KDC
	on the KDC carries the risk of exposure in case the KDC is compromised.
	If a suffiently good password is chosen to encrypt the key, then this
	password can be used for a limited time to change the private key.
	If the user wishes to authenticate himself without storing the private
	key on each local disk, then a safer, albeit possibly less practical,
	alternative is to use a smart card to store the keys.
	When the user's private key is stored on the KDC, the KDC record		Client <--- KRB_ERROR (error code KDC_RECOVERY_NEEDED) <--- KDC
	will also indicate whether preauthentication is required before		error data: [nonce, algID (DH), KDC DH public parameter,
	returning the key (we recommend that it be required). If such		KDC DH ID, KDC PublicKey Kvno and PublicKey,
	preauthentication is required, when the initial request is received,		KDC Salt]Signed with KDC PrivateKey
	the KDC will respond with a KRB_ERROR message, with msg-type set
	to KDC_ERR_PREAUTH_REQUIRED, and e-data set to:
	PA-PK-AS-INFO ::= SEQUENCE {		At this point, the client validates the KDC signature, checks to
	kdcCert[0] SEQUENCE OF Certificate		see if the nonce is the same as the one in the AS_REQ, and stores
	}		the new KDC public key and public key version number. The client
			then generates a Diffie Hellman private parameter and computes
			the corresponding Diffie Hellman public parameter; the client
			also computes the shared Diffie Hellman symmetric key using the
			KDC Diffie Hellman public parameter and its own Diffie Hellman
			private parameter. Next, the client prompts the user for his/her
			password (if it does not already have the password). The password
			is concatenated with the KDC Salt and then SHA1 hashed; the
			result is fed into the string to key function to obtain the new
			user DES key.
	The kdc-cert field is identical to that in the PA-PK-AS-REP		The new user DES key will be encrypted (along with the AS_REQ
	preauthentication data field returned with the KDC response, and must		nonce) using the Diffie Hellman symmetric key and sent to the
	be validated as belonging to the KDC in the same manner.		KDC in the new AS_REQ message:
	Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the		Client -> AS_REQ with preauth: rootCert, [PKAuthenticator with
	client will prompt the user for the password that was used to		user DH public parameter, {newUser DES key, nonce}DH
	encrypt the private key, derive the DES key from that password,		symmetric key, KDC DH ID]Signed with User PrivateKey
	and calculate the MD5 hash H1 of the DES key. The client then sends		-> KDC
	a request to the KDC, which includes a timestamp and a
	client-generated random secret key that will be used by the KDC		The KDC DH ID is copied by the client from the KDC_ERROR message
	to super-encrypt the encrypted private key before it is returned		received above. Upon receipt and validation of this message, the
	to the client. This information is sent to the KDC in a subsequent		KDC first uses the KDC DH ID as an index to locate its
	AS_REQ message in a preauthentication data field:		private Diffie Hellman parameter; it uses this parameter in
			combination with the user public Diffie Hellman parameter
			to compute the symmetric Diffie Hellman key. The KDC checks
			if the encrypted nonce is the same as the one in the
			PKAuthenticator and the AS_REQ part. The KDC then enters
			the new user DES key into the database, resets the recovery
			needed bit, and sets the valid symmetric key in database
			bit. The KDC then creates the AS_REP message:
			Client <-- AS_REP with preauth: kdcCert, {encReplyKey,
			nonce}DH symmetric key <-------------------- KDC
			The AS_REP encrypted part is encrypted with the encReplyKey
			that is generated on the KDC. The nonces are copied from the
			client AS_REQ. The kdcCert is a sequence of certificates
			that have been certified by certifiers listed in the client
			rootCert field, unless a zero length rootCert field was sent.
			In the last case, the kdcCert will also have zero length.
			3.2.2. Private key held by KDC
			Implementation of the changes in this section is RECOMMENDED.
			When the user's private key is not carried with the user, the
			user may encrypt the private key using conventional cryptography,
			and register the encrypted private key with the KDC. As
			described in the previous section, the SHA1 hash of the password
			concatenated with the kdcSalt is also stored in the KDC database
			if the user only uses new clients. We restrict users of this
			protocol to using new clients only. The reason for this restriction
			is that it is not secure to store both the user private key
			encrypted in the user's password and the user password on the KDC
			simultaneously.
			There are several options for storing private keys. If the
			user stores their private key on a removable disk, it is
			less convenient since they need to always carry the disk
			around with them; in addition, the procedures for extracting
			the key may vary between different operating systems.
			Alternatively, the user can store a private key on the hard
			disks of systems that he/she uses; besides limiting the
			systems that the user can login from there is also a
			greater security risk to the private key. If smart card
			readers or slots are deployed in an organization, then the
			user can store his/her private key on a smart card. Finally,
			the user can store his/her private key encrypted in a password
			on the KDC. This last option is probably the most practical
			option currently; it is important that a good password policy
			be used.
			When the user's private key is stored on the KDC,
			preauthentication is required. There are two cases depending on
			whether the requesting user principal needs to be recovered.
			In order to obtain its private key, a user principal includes the
			padata type PA-PK-AS-REQ in the preauthentication data
			field of the AS_REQ message. The accompanying pa-data field is:
	PA-PK-AS-REQ ::= SEQUENCE {		PA-PK-AS-REQ ::= SEQUENCE {
	encHashShell[0] EncryptedData -- EncPaPkAsReqShell		algorithmId[0] INTEGER, -- Public Key Alg.
			encClientPubVal[1] EncryptedData -- EncPaPkAsReqDH
			-- (encrypted with key
			-- K1)
	}		}
	EncPaPkAsReqShell ::= SEQUENCE {		EncPaPkAsReqDH ::= SEQUENCE {
	encHashPart[0] EncryptedData -- EncPaPkAsReqPart		clientPubValue[0] SubjectPublicKeyInfo
	}		}
	EncPaPkAsReqPart ::= SEQUENCE {		Pictorially, PA-PK-AS-REQ is algorithmID, {clientPubValue}K1.
	encHashKey[0] EncryptionKey,
	nonce[1] INTEGER
	}
	The EncPaPkAsReqPart is first encrypted with a DES key K1, derived		The user principal sends its Diffie-Hellman public value encrypted
	by string_to_key from the hash H1 (with null salt), then encrypted		in the key K1. The key K1 is derived by performing string to key on
	again with the KDC's public key from the certificate in the		the SHA1 hash of the user password concatenated with the kdcSalt
	PA-PK-AS-INFO field of the error response.		which is stored in the /krb5/salt file. If the file is absent,
			the concatenation step is skipped in the above algorithm. The
			Diffie Hellman parameters g and p are implied by the algorithmID
			field. By choosing g and p correctly, dictionary attacks against
			the key K1 can be made more difficult [Jaspan].
	Notationally, if encryption algorithm A is used for DES encryption,		If the requesting user principal needs recovery, the encrypted
	and Ak is used for the public key encryption, then enc-shell is		user private key is stored in the KDC database, and the AS_REQ
			RecoveryData field is not present in the PKAuthenticator, then
			the KDC replies with a KRB_ERROR message, with msg-type set to
			KDC_ERR_PREAUTH_REQUIRED, and e-data set to:
	Ak (A ({encHashKey, nonce}, K1), kdcPublicKey)		PA-PK-AS-INFO ::= SEQUENCE {
			signedDHErr SignedDHError, -- signed by KDC
			encUserKey OCTET STRING OPTIONAL -- encrypted by
			-- user password
			-- key; (recovery
			-- response)
	Upon receipt of the authentication request with the PA-PK-AS-REQ, the		}
	KDC verifies the hash of the user's DES encryption key by attempting
	to decrypt the EncPaPkAsReqPart of the PA-PK-AS-REQ. If decryption		The user principal should then continue with the section 3.2.1.1
	is successful, the KDC generates the AS response as defined in		protocol using the Diffie Hellman algorithm.
	RFC 1510, but additionally includes a preauthentication field of type
	PA-PK-USER-KEY. (This response will also be included in response to		We now assume that the requesting user principal does not need
	the initial request without preauthentication if preauthentication is		recovery.
	not required for the user and the user's encrypted private key is
	stored on the KDC.)		Upon receipt of the authentication request with the PA-PK-AS-REQ,
			the KDC generates the AS response as defined in RFC 1510, but
			additionally includes a preauthentication field of type
			PA-PK-USER-KEY.
	PA-PK-USER-KEY ::= SEQUENCE {		PA-PK-USER-KEY ::= SEQUENCE {
	encUserKeyPart[0] EncryptedData -- EncPaPkUserKeyPart		kdcCert SEQUENCE OF Certificate,
			encUserKeyPart EncryptedData, -- EncPaPkUserKeyPart
			kdcPrivKey KDCPrivKey,
			kdcPrivKeySig Signature
	}		}
	EncPaPkUserKeyPart ::= SEQUENCE {		The kdc-cert field is identical to that in the PA-PK-AS-REP
	encUserKey[0] OCTET STRING,		preauthentication data field returned with the KDC response, and
	nonce[1] INTEGER		must be validated as belonging to the KDC in the same manner.
			KDCPrivKey ::= SEQUENCE {
			nonce INTEGER, -- From AS_REQ
			algorithmId INTEGER, -- DH algorithm
			kdcPubValue SubjectPublicKeyInfo, -- DH algorithm
			kdcSalt OCTET STRING -- Since user
			-- uses only new
			-- clients
	}		}
	Notationally, if encryption algorithm A is used, then enc-key-part is		The KDCPrivKey field is signed using the KDC private key.
			The encrypted part of the AS_REP message is encrypted using the
			Diffie Hellman derived symmetric key, as is the EncPaPkUserKeyPart.
	A ({encUserKey, nonce}, enc-hash-key)		EncPaPkUserKeyPart ::= SEQUENCE {
			encUserKey OCTET STRING,
			nonce INTEGER -- From AS_REQ
			}
	(where A could be null encryption).		Notationally, if encryption algorithm A is used, then enc-key-part
			is
			A ({encUserKey, nonce}, Diffie-Hellman-symmetric-key).
			If the client has used an incorrect kdcSalt to compute the
			key K1, then the client needs to resubmit the above AS_REQ
			message using the correct kdcSalt field from the KDCPrivKey
			field.
	This message contains the encrypted private key that has been		This message contains the encrypted private key that has been
	registered with the KDC by the user, as encrypted by the user,		registered with the KDC by the user, as encrypted by the user,
	optionally super-encrypted with the enc-hash-key from the PA-PK-AS-REQ		super-encrypted with the Diffie Hellman derived symmetric key.
	message if preauthentication using that method was provided (otherwise,		Because there is direct trust between the user and the KDC, the
	the EncryptedData should denote null encryption). Note that since		transited field of the ticket returned by the KDC should remain
	H1 is a one-way hash, it is not possible for one to decrypt the		empty. (Cf. Section 3.3.)
	message if one possesses H1 but not the DES key that H1 is derived
	from. Because there is direct trust between the user and the		Examples
	KDC, the transited field of the ticket returned by the KDC should
	remain empty. (Cf. Section 3.3.)		We now give several examples illustrating the protocols in this
			section.
			Example 1: The requesting user principal needs to be recovered
			and stores his/her encrypted private key on the KDC. Then the
			exchange sequence between the user principal and the KDC is:
			Client --------> AS_REQ (with or without preauth) -----> KDC
			Client <--- KRB_ERROR (error code KDC_ERR_PREAUTH_REQUIRED)
			error data: [nonce, algID (DH), KDC DH public
			parameter, KDC DH ID, KDC PublicKey
			Kvno and PublicKey, KDC Salt]Signed
			with KDC PrivateKey, {user private
			key}user password <------------- KDC
			The protocol now continues with the second AS_REQ as in Example
			1 of section 3.2.1.1.
			Example 2: The requesting user principal does not need to be
			recovered and stores his/her encrypted private key on the KDC.
			Then the exchange sequence between the user principal and the KDC
			when the user principal wants to obtain his/her private key is:
			Client -> AS_REQ with preauth: algID,
			{DH public parameter}K1 -> KDC
			The key K1 is generated by using the string to key function
			on the SHA1 hash of the password concatenated with the kdcSalt
			from the /krb5/salt file. If the file is absent, then
			the concatenation step is skipped, and the client will learn
			the correct kdcSalt in the following AS_REP message from the
			KDC. The algID should indicate some type of Diffie Hellman
			algorithm.
			The KDC replies with the AS_REP message with a preauthentication
			data field:
			Client <-- AS_REP with preauth: kdcCert, {encUserKey, <-- KDC
			nonce}DH symmetric key, [nonce, algID, DH
			public parameter, kdcSalt]KDC privateKey
			The client validates the KDC's signature and checks that
			the nonce matches the nonce in its AS_REQ message.
			If the kdcSalt does not match what the client used, it
			starts the protocol over. The client then uses the KDC
			Diffie Hellman public parameter along with its own Diffie
			Hellman private parameter to compute the Diffie Hellman
			symmetric key. This key is used to decrypt the encUserKey
			field; the client checks if the nonce matches its AS_REQ
			nonce. At this point, the initial authentication protocol
			is complete.
			Example 3: The requesting user principal does not need to be
			recovered and stores his/her encrypted private key on the KDC.
			In this example, the user principal uses the conventional
			symmetric key Kerberos V5 initial authentication protocol
			exchange.
			We note that the conventional protocol exposes the user
			password to dictionary attacks; therefore, the user password
			must be changed more often. An example of when this protocol
			would be used is when new clients have been installed but an
			organization has not phased in public key authentication for
			all clients due to performance concerns.
			Client ----> AS_REQ with preauthentication: {time}K1 --> KDC
			Client <-------------------- AS_REP <------------------ KDC
			The key K1 is derived as in the preceding two examples.
	3.3. Clients with a public key certified by an outside authority		3.3. Clients with a public key certified by an outside authority
	Implementation of the changes in this section is OPTIONAL.		Implementation of the changes in this section is OPTIONAL.
	In the case where the client is not registered with the current KDC,		In the case where the client is not registered with the current
	the client is responsible for obtaining the private key on its own.		KDC, the client is responsible for obtaining the private key on
	The client will request initial tickets from the KDC using the TGS		its own. The client will request initial tickets from the KDC
	exchange, but instead of performing pre-authentication using a		using the TGS exchange, but instead of performing
	Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used		preauthentication using a Kerberos ticket granting ticket, or
	when the public key is known to the KDC, the client performs		with the PA-PK-AS-REQ that is used when the public key is known
	preauthentication using the preauthentication data field of type		to the KDC, the client performs preauthentication using the
	PA-PK-AS-EXT-CERT:		preauthentication data field of type PA-PK-AS-EXT-CERT:
	PA-PK-AS-EXT-CERT ::= SEQUENCE {		PA-PK-AS-EXT-CERT ::= SEQUENCE {
	userCert[0] SEQUENCE OF OCTET STRING,		userCert[0] SEQUENCE OF OCTET STRING,
	signedAuth[1] SignedPKAuthenticator		signedAuth[1] SignedPKAuthenticator
	}		}
	where the user-cert specification depends on the type of certificate		where the user-cert specification depends on the type of
	that the user possesses. In cases where the service has separate		certificate that the user possesses. In cases where the service
	key pairs for digital signature and for encryption, we recommend		has separate key pairs for digital signature and for encryption,
	that the signature keys be used for the purposes of sending the		we recommend that the signature keys be used for the purposes of
	preauthentication (and deciphering the response).		sending the preauthentication (and deciphering the response).
	The authenticator is the one used from the exchange in section 3.2.1,		The authenticator is the one used from the exchange in section
	except that it is signed using the private key corresponding to		3.2.1, except that it is signed using the private key corresponding
	the public key in the user-cert.		to the public key in the user-cert.
	The KDC will verify the preauthentication authenticator, and check the		The KDC will verify the preauthentication authenticator, and check the
	certification path against its own policy of legitimate certifiers.		certification path against its own policy of legitimate certifiers.
	This may be based on a certification hierarchy, or simply a list of		This may be based on a certification hierarchy, or simply a list of
	recognized certifiers in a system like PGP.		recognized certifiers in a system like PGP.
	If all checks out, the KDC will issue Kerberos credentials, as in 3.2,		If all checks out, the KDC will issue Kerberos credentials, as in 3.2,
	but with the names of all the certifiers in the certification path		but with the names of all the certifiers in the certification path
	added to the transited field of the ticket, with a principal name		added to the transited field of the ticket, with a principal name
	taken from the certificate (this might be a long path for X.509, or a		taken from the certificate (this might be a long path for X.509, or a
	skipping to change at line 504 ¶		skipping to change at line 978 ¶
	3.4. Digital Signature		3.4. Digital Signature
	Implementation of the changes in this section is OPTIONAL.		Implementation of the changes in this section is OPTIONAL.
	We offer this option with the warning that it requires the client		We offer this option with the warning that it requires the client
	process to generate a random DES key; this generation may not		process to generate a random DES key; this generation may not
	be able to guarantee the same level of randomness as the KDC.		be able to guarantee the same level of randomness as the KDC.
	If a user registered a digital signature key pair with the KDC,		If a user registered a digital signature key pair with the KDC,
	a separate exchange may be used. The client sends a KRB_AS_REQ as		a separate exchange may be used. The client sends a KRB_AS_REQ
	described in section 3.2.2. If the user's database record		as described in section 3.2.2. If the user's database record
	indicates that a digital signature key is to be used, then the		indicates that a digital signature key is to be used, then the
	KDC sends back a KRB_ERROR as in section 3.2.2.		KDC sends back a KRB_ERROR as in section 3.2.2.
	It is assumed here that the signature key is stored on local disk.		It is assumed here that the signature key is stored on local disk.
	The client generates a random key of enctype ENCTYPE_DES_CBC_CRC,		The client generates a random key of enctype ENCTYPE_DES_CBC_CRC,
	signs it using the signature key (otherwise the signature is		signs it using the signature key (otherwise the signature is
	performed as described in section 3.2.1), then encrypts the whole with		performed as described in section 3.2.1), then encrypts the whole
	the public key of the KDC. This is returned with a separate KRB_AS_REQ		with the public key of the KDC. This is returned with a separate
	in a preauthentication of type		KRB_AS_REQ in a preauthentication of type
	PA-PK-AS-SIGNED ::= SEQUENCE {		PA-PK-AS-SIGNED ::= SEQUENCE {
	signedKey[0] EncryptedData -- PaPkAsSignedData		signedKey[0] EncryptedData -- PaPkAsSignedData
	}		}
	PaPkAsSignedData ::= SEQUENCE {		PaPkAsSignedData ::= SEQUENCE {
	signedKeyPart[0] SignedKeyPart,		signedKeyPart[0] SignedKeyPart,
	signedKeyAuth[1] PKAuthenticator		signedKeyAuth[1] PKAuthenticator,
			sig[2] Signature
	}		}
	SignedKeyPart ::= SEQUENCE {		SignedKeyPart ::= SEQUENCE {
	encSignedKey[0] EncryptionKey,		encSignedKey[0] EncryptionKey,
	nonce[1] INTEGER		nonce[1] INTEGER
	}		}
	where the nonce is the one from the request. Upon receipt of the		where the nonce is the one from the request. Upon receipt of the
	request, the KDC decrypts, then verifies the random key. It then		request, the KDC decrypts, then verifies the random key. It then
	replies as per RFC 1510, except that instead of being encrypted		replies as per RFC 1510, except that instead of being encrypted
	with the password-derived DES key, the reply is encrypted using		with the password-derived DES key, the reply is encrypted using
	the randomKey sent by the client. Since the client already knows		the randomKey sent by the client. Since the client already knows
	this key, there is no need to accompany the reply with an extra		this key, there is no need to accompany the reply with an extra
	preauthentication field. Because there is direct trust between		preauthentication field. Because there is direct trust between
	the user and the KDC, the transited field of the ticket returned		the user and the KDC, the transited field of the ticket returned
	by the KDC should remain empty. (Cf. Section 3.3.)		by the KDC should remain empty. (Cf. Section 3.3.)
			In the event that the KDC database indicates that the user
			principal must be recovered, and the PKAuthenticator does not
			contain the RecoveryData field, the KDC will reply with the
			KDC_RECOVERY_NEEDED error. The user principal then sends
			another AS_REQ message that includes the RecoveryData field
			in the PKAuthenticator. The AS_REP message is the same as
			in the basic Kerberos V5 protocol.
	4. Preauthentication Data Types		4. Preauthentication Data Types
	We propose that the following preauthentication types be allocated		We propose that the following preauthentication types be allocated
	for the preauthentication data packages described in this draft:		for the preauthentication data packages described in this draft:
	#define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */		#define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */
	#define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */		#define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */
	#define KRB5_PADATA_PUBLIC_REQ 19 /* PA-PK-AS-REQ */		#define KRB5_PADATA_PUBLIC_REQ 19 /* PA-PK-AS-REQ */
	#define KRB5_PADATA_PRIVATE_REP 20 /* PA-PK-USER-KEY */		#define KRB5_PADATA_PRIVATE_REP 20 /* PA-PK-USER-KEY */
	#define KRB5_PADATA_PUBLIC_EXT 21 /* PA-PK-AS-EXT-CERT */		#define KRB5_PADATA_PUBLIC_EXT 21 /* PA-PK-AS-EXT-CERT */
	#define KRB5_PADATA_PUBLIC_SIGN 22 /* PA-PK-AS-SIGNED */		#define KRB5_PADATA_PUBLIC_SIGN 22 /* PA-PK-AS-SIGNED */
	5. Encryption Information		5. Encryption Information
	For the public key cryptography used in direct registration, we used		For the public key cryptography used in direct registration, we
	(in our implementation) the RSAREF library supplied with the PGP 2.6.2		used (in our implementation) the RSAREF library supplied with the
	release. Encryption and decryption functions were implemented directly		PGP 2.6.2 release. Encryption and decryption functions were
	on top of the primitives made available therein, rather than the		implemented directly on top of the primitives made available
	fully sealing operations in the API.		therein, rather than the fully sealing operations in the API.
	6. Compatibility with One-Time Passcodes		6. Compatibility with One-Time Passcodes
	We solicit discussion on how the use of public key cryptography for initial		We solicit discussion on how the use of public key cryptography
	authentication will interact with the proposed use of one time passwords		for initial authentication will interact with the proposed use of
	discussed in Internet Draft <draft-ietf-cat-kerberos-passwords-00.txt>.		one time passwords discussed in Internet Draft
			<draft-ietf-cat-kerberos-passwords-00.txt>.
	7. Strength of Encryption and Signature Mechanisms		7. Strength of Encryption and Signature Mechanisms
	In light of recent findings on the strengths of MD5 and various DES		In light of recent findings on the strengths of MD5 and various DES
	modes, we solicit discussion on which modes to incorporate into the		modes, we solicit discussion on which modes to incorporate into the
	protocol changes.		protocol changes.
	8. Expiration		8. Expiration
	This Internet-Draft expires on December 7, 1996.		This Internet-Draft expires on April 19, 1997.
	9. Authors' Addresses		9. Authors' Addresses
	B. Clifford Neuman		B. 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: 310-822-1511		Phone: 310-822-1511
	EMail: bcn@isi.edu		EMail: bcn@isi.edu
	skipping to change at line 601 ¶		skipping to change at line 1084 ¶
	Phone: 310-822-1511		Phone: 310-822-1511
	EMail: brian@isi.edu		EMail: brian@isi.edu
	John Wray		John Wray
	Digital Equipment Corporation		Digital Equipment Corporation
	550 King Street, LKG2-2/Z7		550 King Street, LKG2-2/Z7
	Littleton, MA 01460		Littleton, MA 01460
	Phone: 508-486-5210		Phone: 508-486-5210
	EMail: wray@tuxedo.enet.dec.com		EMail: wray@tuxedo.enet.dec.com
			Jonathan Trostle
			CyberSafe Corporation
			1605 NW Sammamish Rd., Suite 310
			Issaquah, WA 98027-5378
			Phone: 206-391-6000
			EMail: jonathan.trostle@cybersafe.com
End of changes. 69 change blocks.
	268 lines changed or deleted		751 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/