< draft-ietf-cat-kerberos-pk-init-02.txt		draft-ietf-cat-kerberos-pk-init-03.txt >
	INTERNET-DRAFT Clifford Neuman		INTERNET-DRAFT Clifford Neuman
	draft-ietf-cat-kerberos-pk-init-02.txt Brian Tung		draft-ietf-cat-kerberos-pk-init-03.txt Brian Tung
	Updates: RFC 1510 ISI		Updates: RFC 1510 ISI
	expires April 19, 1997 John Wray		expires September 30, 1997 John Wray
	Digital Equipment Corporation		Digital Equipment Corporation
	Jonathan Trostle		Ari Medvinsky
	CyberSafe Corporation		Matthew Hur
			CyberSafe Corporation
			Jonathan Trostle
			Novell
	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
	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.
	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other docu-
	ments at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as ``work in pro-
	gress.''
	To learn the current status of any Internet-Draft, please check the
	``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
	dow Directories on ds.internic.net (US East Coast), nic.nordu.net
	(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
	Rim).
	The distribution of this memo is unlimited. It is filed as
	draft-ietf-cat-kerberos-pk-init-02.txt, and expires April 19, 1997.
	Please send comments to the authors.
	1. Abstract
	This document defines extensions to the Kerberos protocol
	specification (RFC 1510, "The Kerberos Network Authentication
	Service (V5)", September 1993) to provide a method for using public
	key cryptography during initial authentication. The method defined
	specifies the way in which preauthentication data fields and error
	data fields in Kerberos messages are to be used to transport public
	key data.
	2. Motivation
	Public key cryptography presents a means by which a principal may
	demonstrate possession of a key, without ever having divulged this
	key to anyone else. In conventional cryptography, the encryption
	key and decryption key are either identical or can easily be
	derived from one another. In public key cryptography, however,
	neither the public key nor the private key can be derived from the
	other (although the private key RECORD may include the information
	required to generate BOTH keys). Hence, a message encrypted with a
	public key is private, since only the person possessing the private
	key can decrypt it; similarly, someone possessing the private key
	can also encrypt a message, thus providing a digital signature.
	Furthermore, conventional keys are often derived from passwords, so
	messages encrypted with these keys are susceptible to dictionary
	attacks, whereas public key pairs are generated from a
	pseudo-random number sequence. While it is true that messages
	encrypted using public key cryptography are actually encrypted with
	a conventional secret key, which is in turn encrypted using the
	public key pair, the secret key is also randomly generated and is
	hence not vulnerable to a dictionary attack.
	The advantages provided by public key cryptography have produced a
	demand for its integration into the Kerberos authentication
	protocol. The public key integration into Kerberos described in
	this document has three goals.
	First, by allowing users to register public keys with the KDC, the
	KDC can be recovered much more easily in the event it is
	compromised. With Kerberos as it currently stands, compromise of
	the KDC is disastrous. All keys become known by the attacker and
	all keys must be changed. Second, we allow users that have public
	key certificates signed by outside authorities to obtain Kerberos
	credentials for access to Kerberized services. Third, we obtain the
	above benefits while maintaining the performance advantages of
	Kerberos over protocols that use only public key authentication.
	If users register public keys, compromise of the KDC does not
	divulge their private key. Compromise of security on the KDC is
	still a problem, since an attacker can impersonate any user by
	creating a ticket granting ticket for the user. When the compromise
	is detected, the KDC can be cleaned up and restored from backup
	media and loaded with a backup private/public key pair. Keys for
	application servers are conventional symmetric keys and must be
	changed.
	Note: If a user stores his private key, in an encrypted form, on
	the KDC, then it may be desirable to change the key pair, since the
	private key is encrypted using a symmetric key derived from a
	password (as described below), and can therefore be vulnerable to
	dictionary attack if a good password policy is not used.
	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
	discussions over several years between members of the SAAG, the
	IETF-CAT working group, and the PSRG, regarding integration of
	Kerberos and SPX. Some ideas are drawn from the DASS system, and
	similar extensions have been discussed for use in DCE. These
	changes are by no means endorsed by these groups. This is an
	attempt to revive some of the goals of that group, and the
	proposal approaches those goals primarily from the Kerberos
	perspective.
	3. Initial authentication of users with public keys
	This section describes the extensions to Version 5 of the Kerberos
	protocol that will support the use of public key cryptography by
	users in the initial request for a ticket granting ticket.
	Roughly speaking, the following changes to RFC 1510 are proposed:
	Users can initially authenticate using public key or conventional
	(symmetric key) cryptography. After a KDC compromise, the KDC
	replies with an error message that informs the client of the new
	KDC public backup key. Users must authenticate using public key
	cryptography in response to the error message. If applicable, the
	client generates the new user secret key at this point as well.
	Public key initial authentication is performed using either the
	RSA encryption or Diffie Hellman public key algorithms. There is
	also an option to allow the user to store his/her private key
	encrypted in the user password in the KDC database; this option
	solves the problem of transporting the user private key to
	different workstations. The combination of this option and the
	provision for conventional symmetric key authentication allows
	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
	application servers will continue to be based on conventional
	cryptography, or will be converted to use user-to-user
	authentication. There are performance issues and other reasons
	that servers may be better off using conventional cryptography.
	For this proposal, we feel that 80 percent of the benefits of
	integrating public key with Kerberos can be attained for 20 percent
	of the effort, by addressing only initial authentication. This
	proposal does not preclude separate extensions.
	With these changes, users will be able to register public keys,
	only in realms that support public key, but they will still be able
	to perform initial authentication from a client that does not
	support public key. They will be able to use services registered in
	any realm. Furthermore, users registered with conventional keys
	will be able to use any client.
	This proposal addresses three ways in which users may use public
	key cryptography for initial authentication with Kerberos, with
	minimal change to the existing protocol. Users may register keys
	directly with the KDC, or they may present certificates by outside
	certification authorities (or certifications by other users)
	attesting to the association of the public key with the named user.
	In both cases, the end result is that the user obtains a
	conventional ticket granting ticket or conventional server ticket
	that may be used for subsequent authentication, with such
	subsequent authentication using only conventional cryptography.
	Additionally, users may also register a digital signature
	verification key with the KDC. We provide this option for the
	licensing benefits, as well as a simpler variant of the initial
	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
	the KDC.
	3.1 Definitions
	Before we proceed, we will lay some groundwork definitions for
	encryption and signatures. We propose the following definitions
	of signature and encryption modes (and their corresponding values
	on the wire):
	#define ENCTYPE_SIGN_MD5_RSA 0x0011
	#define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021
	#define ENCTYPE_ENCRYPT_RSA_PUB 0x0022
	allowing further modes to be defined accordingly.
	In the exposition below, we will use the notation E (T, K) to
	denote the encryption of data T, with key (or parameters) K.
	If E is ENCTYPE_SIGN_MD5_RSA, then
	E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)}
	If E is ENCTYPE_ENCRYPT_RSA_PRIV, then
	E (T, K) = RSAEncryptPrivate (T, K)
	Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then
	E (T, K) = RSAEncryptPublic (T, K)
	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
	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 used by the KDC.
	3.2.1 User's private key is stored locally
	Implementation of the changes in this section is REQUIRED.
	In this section, we present the basic Kerberos V5 pk-init protocol
	that all conforming implementations must support. The key features
	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 {
	rootCert[0] SEQUENCE OF OCTET STRING,
	signedAuth[1] SignedPKAuthenticator
	}
	SignedPKAuthenticator ::= SEQUENCE {
	authent[0] PKAuthenticator,
	authentSig[1] Signature
	}
	PKAuthenticator ::= SEQUENCE {
	cksum[0] Checksum OPTIONAL,
	cusec[1] INTEGER,
	ctime[2] KerberosTime,
	nonce[3] INTEGER,
	kdcRealm[4] Realm,
	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 {
	sigType[0] INTEGER,
	kvno[1] INTEGER OPTIONAL,
	sigHash[2] OCTET STRING
	}
	Notationally, sigHash is then
	sigType (authent, userPrivateKey)
	where userPrivateKey is the user's private key (corresponding to the
	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
	that other types may be listed (and given on-the-wire values between
	0x0011 and 0x001f).
	The format of each certificate depends on the particular service
	used. (Alternatively, the KDC could send, with its reply, a
	sequence of certifications (see below), but since the KDC is likely
	to have more certifications than users have trusted root certifiers,
	we have chosen the first method.) In the event that the client
	believes it already possesses the current public key of the KDC, a
	zero-length root-cert field is sent.
	The fields in the signed authenticator are the same as those in the
	Kerberos authenticator; in addition, we include a client-generated
	nonce, and the name of the KDC. The structure is itself signed
	using the user's private key corresponding to the public key
	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.
	We now describe the recovery phase of the protocol. There is a bit
	associated with each principal in the database indicating whether
	recovery for that principal is necessary. After a KDC compromise,
	the KDC software is reloaded from backup media and a new backup
	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.
	After the reload of KDC software, the bits associated with
	recovery of each principal are all set. The KDC clears the bit
	for each principal that undergoes the recovery phase. In addition,
	there is a bit associated with each principal to indicate whether
	there is a valid symmetric key in the database for the principal.
	These bits are all cleared after the reload of the KDC software
	(the old symmetric keys are no longer valid). Finally, there is a
	bit associated with each principal indicating whether that
	principal still uses non-public key capable clients. If a user
	principal falls into this category, a public key capable client
	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		This document is an Internet-Draft. Internet-Drafts are working
	privkey}EncReplyTmpKey, {EncReplyTmpKey}Userpubkey		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.
	Pictorially, in the Diffie Hellman case we have:		Internet-Drafts are draft documents valid for a maximum of six
			months and may be updated, replaced, or obsoleted by other
			documents at any time. It is inappropriate to use Internet-Drafts
			as reference material or to cite them other than as "work in
			progress."
	kdcCert, {encReplyKey, nonce}DH shared symmetric key,		To learn the current status of any Internet-Draft, please check
	[DH public value]Sig w/KDC privkey		the "1id-abstracts.txt" listing contained in the Internet-Drafts
			Shadow Directories on ds.internic.net (US East Coast),
			nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
			munnari.oz.au (Pacific Rim).
	PA-PK-AS-REP ::= SEQUENCE {		The distribution of this memo is unlimited. It is filed as
	kdcCert[0] SEQUENCE OF Certificate,		draft-ietf-cat-kerberos-pk-init-03.txt, and expires September 30,
	encryptShell[1] EncryptedData,		1997. Please send comments to the authors.
	-- EncPaPkAsRepPartShell
	-- encrypted by
	-- 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 {		1. Abstract
	signedDHPubVal SignedDHPublicValue,
	encryptKey EncryptedData
	-- EncPaPkAsRepTmpKey
	-- encrypted by
	-- userPublicKey
	}
	SignedDHPublicValue ::= SEQUENCE {		This document defines extensions (PKINIT) to the Kerberos protocol
	dhPublic[0] SubjectPublicKeyInfo,		specification (RFC 1510 [1]) to provide a method for using public
	dhPublicSig[1] Signature		key cryptography during initial authentication. The methods
	}		defined specify the ways in which preauthentication data fields and
			error data fields in Kerberos messages are to be used to transport
			public key data.
	EncPaPkAsRepPartShell ::= SEQUENCE {		2. Introduction
	encReplyPart[0] EncPaPkAsRepPart,
	encReplyPartSig[1] Signature OPTIONAL
	-- encReplyPart
	-- signed by kdcPrivateKey
	-- except not present in
	-- DH case
	}
	EncPaPkAsRepPart ::= SEQUENCE {
	encReplyKey[0] EncryptionKey,
	nonce[1] INTEGER,
	}
	EncPaPkAsRepTmpKey ::= SEQUENCE {		The popularity of public key cryptography has produced a desire for
	encReplyTmpKey[0] EncryptionKey		its support in Kerberos [2]. The advantages provided by public key
	}		cryptography include simplified key management (from the Kerberos
			perspective) and the ability to leverage existing and developing
			public key certification infrastructures.
	The kdc-cert specification is lifted, with slight modifications,		Public key cryptography can be integrated into Kerberos in a number
	from v3 of the X.509 certificate specification:		of ways. One is to to associate a key pair with each realm, which
			can then be used to facilitate cross-realm authentication; this is
			the topic of another draft proposal. Another way is to allow users
			with public key certificates to use them in initial authentication.
			This is the concern of the current document.
	Certificate ::= SEQUENCE {		One of the guiding principles in the design of PKINIT is that
	version[0] Version DEFAULT v1 (1),		changes should be as minimal as possible. As a result, the basic
	serialNumber[1] CertificateSerialNumber,		mechanism of PKINIT is as follows: The user sends a request to the
	signature[2] AlgorithmIdentifier,		KDC as before, except that if that user is to use public key
	issuer[3] PrincipalName,		cryptography in the initial authentication step, his certificate
	validity[4] Validity,		accompanies the initial request, in the preauthentication fields.
	subjectRealm[5] Realm,
	subject[6] PrincipalName,
	subjectPublicKeyInfo[7] SubjectPublicKeyInfo,
	issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL,
	subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL,
	authentSig[10] Signature
	}
	The kdc-cert must have as its root certification one of the		Upon receipt of this request, the KDC verifies the certificate and
	certifiers sent to the KDC with the original request. If the KDC		issues a ticket granting ticket (TGT) as before, except that instead
	has no such certification, then it will instead reply with a		of being encrypted in the user's long-term key (which is derived
	KRB_ERROR of type KDC_ERROR_PREAUTH_FAILED. If a zero-length		from a password), it is encrypted in a randomly-generated key. This
	root-cert was sent by the client as part of the PA-PK-AS-ROOT, then		random key is in turn encrypted using the public key certificate
	a correspondingly zero-length kdc-cert may be absent, in which case		that came with the request and signed using the KDC's signature key,
	the client uses its copy of the KDC's public key. In the case of		and accompanies the reply, in the preauthentication fields.
	recovery, the client uses its copy of the backup KDC public key.
	Upon receipt of the response from the KDC, the client will verify		PKINIT also allows for users with only digital signature keys to
	the public key for the KDC from PA-PK-AS-REP preauthentication data		authenticate using those keys, and for users to store and retrieve
	field. The certificate must certify the key as belonging to a		private keys on the KDC.
	principal whose name can be derived from the realm name. If the
	certificate checks out, the client then decrypts the EncPaPkAsRepPart
	and verifies the signature of the KDC. It then uses the random key
	contained therein to decrypt the rest of the response, and continues
	as per RFC 1510. Because there is direct trust between the user and
	the KDC, the transited field of the ticket returned by the KDC should
	remain empty. (Cf. Section 3.3.)
	Examples		The PKINIT specification may also be used for direct peer to peer
			authentication without contacting a central KDC. This application
			of PKINIT is described in PKTAPP [4] and is based on concepts
			introduced in [5, 6]. For direct client-to-server authentication,
			the client uses PKINIT to authenticate to the end server (instead
			of a central KDC), which then issues a ticket for itself. This
			approach has an advantage over SSL [7] in that the server does not
			need to save state (cache session keys). Furthermore, an
			additional benefit is that Kerberos tickets can facilitate
			delegation (see [8]).
	We now give several examples illustrating the protocols in this		3. Proposed Extensions
	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.
	Example 1: The requesting user principal needs to be recovered and		This section describes extensions to RFC 1510 for supporting the
	uses only new clients. The recovery algorithm is Diffie Hellman (DH).		use of public key cryptography in the initial request for a ticket
	Then the exchange sequence between the user principal and the KDC is:		granting ticket (TGT).
	Client --------> AS_REQ (with or without preauth) --------> KDC		In summary, the following changes to RFC 1510 are proposed:
	Client <--- KRB_ERROR (error code KDC_RECOVERY_NEEDED) <--- KDC		--> Users may authenticate using either a public key pair or a
	error data: [nonce, algID (DH), KDC DH public parameter,		conventional (symmetric) key. If public key cryptography is
	KDC DH ID, KDC PublicKey Kvno and PublicKey,		used, public key data is transported in preauthentication
	KDC Salt]Signed with KDC PrivateKey		data fields to help establish identity.
			--> Users may store private keys on the KDC for retrieval during
			Kerberos initial authentication.
	At this point, the client validates the KDC signature, checks to		This proposal addresses two ways that users may use public key
	see if the nonce is the same as the one in the AS_REQ, and stores		cryptography for initial authentication. Users may present public
	the new KDC public key and public key version number. The client		key certificates, or they may generate their own session key,
	then generates a Diffie Hellman private parameter and computes		signed by their digital signature key. In either case, the end
	the corresponding Diffie Hellman public parameter; the client		result is that the user obtains an ordinary TGT that may be used for
	also computes the shared Diffie Hellman symmetric key using the		subsequent authentication, with such authentication using only
	KDC Diffie Hellman public parameter and its own Diffie Hellman		conventional cryptography.
	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 new user DES key will be encrypted (along with the AS_REQ		Section 3.1 provides definitions to help specify message formats.
	nonce) using the Diffie Hellman symmetric key and sent to the		Section 3.2 and 3.3 describe the extensions for the two initial
	KDC in the new AS_REQ message:		authentication methods. Section 3.3 describes a way for the user to
			store and retrieve his private key on the KDC.
	Client -> AS_REQ with preauth: rootCert, [PKAuthenticator with		3.1. Definitions
	user DH public parameter, {newUser DES key, nonce}DH
	symmetric key, KDC DH ID]Signed with User PrivateKey
	-> KDC
	The KDC DH ID is copied by the client from the KDC_ERROR message		Hash and encryption types will be specified using ENCTYPE tags; we
	received above. Upon receipt and validation of this message, the		propose the addition of the following types:
	KDC first uses the KDC DH ID as an index to locate its
	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,		#define ENCTYPE_SIGN_DSA_GENERATE 0x0011
	nonce}DH symmetric key <-------------------- KDC		#define ENCTYPE_SIGN_DSA_VERIFY 0x0012
			#define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021
			#define ENCTYPE_ENCRYPT_RSA_PUB 0x0022
	The AS_REP encrypted part is encrypted with the encReplyKey		allowing further signature types to be defined in the range 0x0011
	that is generated on the KDC. The nonces are copied from the		through 0x001f, and further encryption types to be defined in the
	client AS_REQ. The kdcCert is a sequence of certificates		range 0x0021 through 0x002f.
	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		The extensions involve new preauthentication fields. The
			preauthentication data types are in the range 17 through 21.
			These values are also specified along with their corresponding
			ASN.1 definition.
	Implementation of the changes in this section is RECOMMENDED.		#define PA-PK-AS-REQ 17
			#define PA-PK-AS-REP 18
			#define PA-PK-AS-SIGN 19
			#define PA-PK-KEY-REQ 20
			#define PA-PK-KEY-REP 21
	When the user's private key is not carried with the user, the		The extensions also involve new error types. The new error types
	user may encrypt the private key using conventional cryptography,		are in the range 227 through 229. They are:
	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		#define KDC_ERROR_CLIENT_NOT_TRUSTED 227
	user stores their private key on a removable disk, it is		#define KDC_ERROR_KDC_NOT_TRUSTED 228
	less convenient since they need to always carry the disk		#define KDC_ERROR_INVALID_SIG 229
	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,		In the exposition below, we use the following terms: encryption key,
	preauthentication is required. There are two cases depending on		decryption key, signature key, verification key. It should be
	whether the requesting user principal needs to be recovered.		understood that encryption and verification keys are essentially
			public keys, and decryption and signature keys are essentially
			private keys. The fact that they are logically distinct does
			not preclude the assignment of bitwise identical keys.
	In order to obtain its private key, a user principal includes the		3.2. Standard Public Key Authentication
	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 {		Implementation of the changes in this section is REQUIRED for
	algorithmId[0] INTEGER, -- Public Key Alg.		compliance with pk-init.
	encClientPubVal[1] EncryptedData -- EncPaPkAsReqDH
	-- (encrypted with key
	-- K1)
	}
	EncPaPkAsReqDH ::= SEQUENCE {		It is assumed that all public keys are signed by some certification
	clientPubValue[0] SubjectPublicKeyInfo		authority (CA). The initial authentication request is sent as per
	}		RFC 1510, except that a preauthentication field containing data
			signed by the user's signature key accompanies the request:
	Pictorially, PA-PK-AS-REQ is algorithmID, {clientPubValue}K1.		PA-PK-AS-REQ ::- SEQUENCE {
			-- PA TYPE 17
			signedPKAuth [0] SignedPKAuthenticator,
			userCert [1] SEQUENCE OF Certificate OPTIONAL,
			-- the user's certificate
			-- optionally followed by that
			-- certificate's certifier chain
			trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL
			-- CAs that the client trusts
			}
	The user principal sends its Diffie-Hellman public value encrypted		SignedPKAuthenticator ::= SEQUENCE {
	in the key K1. The key K1 is derived by performing string to key on		pkAuth [0] PKAuthenticator,
	the SHA1 hash of the user password concatenated with the kdcSalt		pkAuthSig [1] Signature,
	which is stored in the /krb5/salt file. If the file is absent,		-- of pkAuth
	the concatenation step is skipped in the above algorithm. The		-- using user's signature key
	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].
	If the requesting user principal needs recovery, the encrypted		PKAuthenticator ::= SEQUENCE {
	user private key is stored in the KDC database, and the AS_REQ		cusec [0] INTEGER,
	RecoveryData field is not present in the PKAuthenticator, then		-- for replay prevention
	the KDC replies with a KRB_ERROR message, with msg-type set to		ctime [1] KerberosTime,
	KDC_ERR_PREAUTH_REQUIRED, and e-data set to:		-- for replay prevention
			nonce [2] INTEGER,
			-- binds response to this request
			kdcName [3] PrincipalName,
			clientPubValue [4] SubjectPublicKeyInfo OPTIONAL,
			-- for Diffie-Hellman algorithm
			}
	PA-PK-AS-INFO ::= SEQUENCE {		Signature ::= SEQUENCE {
	signedDHErr SignedDHError, -- signed by KDC		signedHash [0] EncryptedData
	encUserKey OCTET STRING OPTIONAL -- encrypted by		-- of type Checksum
	-- user password		-- encrypted under signature key
	-- key; (recovery		}
	-- response)
	}		Checksum ::= SEQUENCE {
			cksumtype [0] INTEGER,
			checksum [1] OCTET STRING
			} -- as specified by RFC 1510
	The user principal should then continue with the section 3.2.1.1		SubjectPublicKeyInfo ::= SEQUENCE {
	protocol using the Diffie Hellman algorithm.		algorithm [0] algorithmIdentifier,
			subjectPublicKey [1] BIT STRING
			} -- as specified by the X.509 recommendation [9]
	We now assume that the requesting user principal does not need		Certificate ::= SEQUENCE {
	recovery.		CertType [0] INTEGER,
			-- type of certificate
			-- 1 = X.509v3 (DER encoding)
			-- 2 = PGP (per PGP draft)
			CertData [1] OCTET STRING
			-- actual certificate
			-- type determined by CertType
			}
	Upon receipt of the authentication request with the PA-PK-AS-REQ,		Note: If the signature uses RSA keys, then it is to be performed
	the KDC generates the AS response as defined in RFC 1510, but		as per PKCS #1.
	additionally includes a preauthentication field of type
	PA-PK-USER-KEY.
	PA-PK-USER-KEY ::= SEQUENCE {		The PKAuthenticator carries information to foil replay attacks,
	kdcCert SEQUENCE OF Certificate,		to bind the request and response, and to optionally pass the
	encUserKeyPart EncryptedData, -- EncPaPkUserKeyPart		client's Diffie-Hellman public value (i.e. for using DSA in
	kdcPrivKey KDCPrivKey,		combination with Diffie-Hellman). The PKAuthenticator is signed
	kdcPrivKeySig Signature		with the private key corresponding to the public key in the
	}		certificate found in userCert (or cached by the KDC).
	The kdc-cert field is identical to that in the PA-PK-AS-REP		In the PKAuthenticator, the client may specify the KDC name in one
	preauthentication data field returned with the KDC response, and		of two ways: 1) a Kerberos principal name, or 2) the name in the
	must be validated as belonging to the KDC in the same manner.		KDC's certificate (e.g., an X.500 name, or a PGP name). Note that
			case #1 requires that the certificate name and the Kerberos principal
			name be bound together (e.g., via an X.509v3 extension).
	KDCPrivKey ::= SEQUENCE {		The userCert field is a sequence of certificates, the first of which
	nonce INTEGER, -- From AS_REQ		must be the user's public key certificate. Any subsequent
	algorithmId INTEGER, -- DH algorithm		certificates will be certificates of the certifiers of the user's
	kdcPubValue SubjectPublicKeyInfo, -- DH algorithm		certificate. These cerificates may be used by the KDC to verify the
	kdcSalt OCTET STRING -- Since user		user's public key. This field is empty if the KDC already has the
	-- uses only new		user's certifcate.
	-- clients
	}
	The KDCPrivKey field is signed using the KDC private key.		The trustedCertifiers field contains a list of certification
	The encrypted part of the AS_REP message is encrypted using the		authorities trusted by the client, in the case that the client does
	Diffie Hellman derived symmetric key, as is the EncPaPkUserKeyPart.		not possess the KDC's public key certificate.
	EncPaPkUserKeyPart ::= SEQUENCE {		Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
	encUserKey OCTET STRING,		type, the KDC attempts to verify the user's certificate chain
	nonce INTEGER -- From AS_REQ		(userCert), if one is provided in the request. This is done by
	}		verifying the certification path against the KDC's policy of
			legitimate certifiers. This may be based on a certification
			hierarchy, or it may be simply a list of recognized certifiers in a
			system like PGP. If the certification path does not match one of
			the KDC's trusted certifiers, the KDC sends back an error message of
			type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data
			field a list of its own trusted certifiers, upon which the client
			resends the request.
	Notationally, if encryption algorithm A is used, then enc-key-part		If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
	is		verifies that it has a certificate issued by one of the certifiers
	A ({encUserKey, nonce}, Diffie-Hellman-symmetric-key).		trusted by the client. If it does not have a suitable certificate,
			the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
			to the client.
	If the client has used an incorrect kdcSalt to compute the		If a trust relationship exists, the KDC then verifies the client's
	key K1, then the client needs to resubmit the above AS_REQ		signature on PKAuthenticator. If that fails, the KDC returns an
	message using the correct kdcSalt field from the KDCPrivKey		error message of type KDC_ERROR_INVALID_SIG. Otherwise, the KDC
	field.		uses the timestamp in the PKAuthenticator to assure that the request
			is not a replay. The KDC also verifies that its name is specified
			in PKAuthenticator.
	This message contains the encrypted private key that has been		Assuming no errors, the KDC replies as per RFC 1510, except that it
	registered with the KDC by the user, as encrypted by the user,		encrypts the reply not with the user's key, but with a random key
	super-encrypted with the Diffie Hellman derived symmetric key.		generated only for this particular response. This random key
	Because there is direct trust between the user and the KDC, the		is sealed in the preauthentication field:
	transited field of the ticket returned by the KDC should remain
	empty. (Cf. Section 3.3.)
	Examples		PA-PK-AS-REP ::= SEQUENCE {
			-- PA TYPE 18
			kdcCert [0] SEQUENCE OF Certificate OPTIONAL,
			-- the KDC's certificate
			-- optionally followed by that
			-- certificate's certifier chain
			encPaReply [1] EncryptedData,
			-- of type PaReply
			-- using either the client public
			-- key or the Diffie-Hellman key
			-- specified by SignedDHPublicValue
			signedDHPublicValue [2] SignedDHPublicValue OPTIONAL
			}
	We now give several examples illustrating the protocols in this		PaReply ::= SEQUENCE {
	section.		replyEncKeyPack [0] ReplyEncKeyPack,
			replyEncKeyPackSig [1] Signature,
			-- of replyEncKeyPack
			-- using KDC's signature key
			}
	Example 1: The requesting user principal needs to be recovered		ReplyEncKeyPack ::= SEQUENCE {
	and stores his/her encrypted private key on the KDC. Then the		replyEncKey [0] EncryptionKey,
	exchange sequence between the user principal and the KDC is:		-- used to encrypt main reply
			nonce [1] INTEGER
			-- binds response to the request
			-- passed in the PKAuthenticator
			}
	Client --------> AS_REQ (with or without preauth) -----> KDC		SignedDHPublicValue ::= SEQUENCE {
			dhPublicValue [0] SubjectPublicKeyInfo,
			dhPublicValueSig [1] Signature
			-- of dhPublicValue
			-- using KDC's signature key
			}
	Client <--- KRB_ERROR (error code KDC_ERR_PREAUTH_REQUIRED)		The kdcCert field is a sequence of certificates, the first of which
	error data: [nonce, algID (DH), KDC DH public		must have as its root certifier one of the certifiers sent to the
	parameter, KDC DH ID, KDC PublicKey		KDC in the PA-PK-AS-REQ. Any subsequent certificates will be
	Kvno and PublicKey, KDC Salt]Signed		certificates of the certifiers of the KDC's certificate. These
	with KDC PrivateKey, {user private		cerificates may be used by the client to verify the KDC's public
	key}user password <------------- KDC		key. This field is empty if the client did not send to the KDC a
			list of trusted certifiers (the trustedCertifiers field was empty).
	The protocol now continues with the second AS_REQ as in Example		Since each certifier in the certification path of a user's
	1 of section 3.2.1.1.		certificate is essentially a separate realm, the name of each
			certifier shall be added to the transited field of the ticket. The
			format of these realm names shall follow the naming constraints set
			forth in RFC 1510 (sections 7.1 and 3.3.3.1). Note that this will
			require new nametypes to be defined for PGP certifiers and other
			types of realms as they arise.
	Example 2: The requesting user principal does not need to be		The KDC's certificate must bind the public key to a name derivable
	recovered and stores his/her encrypted private key on the KDC.		from the name of the realm for that KDC. The client then extracts
	Then the exchange sequence between the user principal and the KDC		the random key used to encrypt the main reply. This random key (in
	when the user principal wants to obtain his/her private key is:		encPaReply) is encrypted with either the client's public key or
			with a key derived from the DH values exchanged between the client
			and the KDC.
	Client -> AS_REQ with preauth: algID,		3.3. Digital Signature
	{DH public parameter}K1 -> KDC
	The key K1 is generated by using the string to key function		Implementation of the changes in this section are OPTIONAL for
	on the SHA1 hash of the password concatenated with the kdcSalt		compliance with pk-init.
	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		We offer this option with the warning that it requires the client to
	data field:		generate a random key; the client may not be able to guarantee the
			same level of randomness as the KDC.
	Client <-- AS_REP with preauth: kdcCert, {encUserKey, <-- KDC		If the user registered a digital signature key with the KDC instead
	nonce}DH symmetric key, [nonce, algID, DH		of an encryption key, then a separate exchange must be used. The
	public parameter, kdcSalt]KDC privateKey		client sends a request for a TGT as usual, except that it (rather
	The client validates the KDC's signature and checks that		than the KDC) generates the random key that will be used to encrypt
	the nonce matches the nonce in its AS_REQ message.		the KDC response. This key is sent to the KDC along with the
	If the kdcSalt does not match what the client used, it		request in a preauthentication field:
	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		PA-PK-AS-SIGN ::= SEQUENCE {
	recovered and stores his/her encrypted private key on the KDC.		-- PA TYPE 19
	In this example, the user principal uses the conventional		encSignedKeyPack [0] EncryptedData
	symmetric key Kerberos V5 initial authentication protocol		-- of SignedKeyPack
	exchange.		-- using the KDC's public key
			}
	We note that the conventional protocol exposes the user		SignedKeyPack ::= SEQUENCE {
	password to dictionary attacks; therefore, the user password		signedKey [0] KeyPack,
	must be changed more often. An example of when this protocol		signedKeyAuth [1] PKAuthenticator,
	would be used is when new clients have been installed but an		signedKeySig [2] Signature
	organization has not phased in public key authentication for		-- of signedKey.signedKeyAuth
	all clients due to performance concerns.		-- using user's signature key
			}
	Client ----> AS_REQ with preauthentication: {time}K1 --> KDC		KeyPack ::= SEQUENCE {
			randomKey [0] EncryptionKey,
			-- will be used to encrypt reply
			nonce [1] INTEGER
			}
	Client <-------------------- AS_REP <------------------ KDC		where the nonce is copied from the request.
	The key K1 is derived as in the preceding two examples.		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.3. Clients with a public key certified by an outside authority		3.4. Retrieving the Private Key From the KDC
	Implementation of the changes in this section is OPTIONAL.		Implementation of the changes in this section is RECOMMENDED for
			compliance with pk-init.
	In the case where the client is not registered with the current		When the user's private key is not stored local to the user, he may
	KDC, the client is responsible for obtaining the private key on		choose to store the private key (normally encrypted using a
	its own. The client will request initial tickets from the KDC		password-derived key) on the KDC. We provide this option to present
	using the TGS exchange, but instead of performing		the user with an alternative to storing the private key on local
	preauthentication using a Kerberos ticket granting ticket, or		disk at each machine where he expects to authenticate himself using
	with the PA-PK-AS-REQ that is used when the public key is known		pk-init. It should be noted that it replaces the added risk of
	to the KDC, the client performs preauthentication using the		long-term storage of the private key on possibly many workstations
	preauthentication data field of type PA-PK-AS-EXT-CERT:		with the added risk of storing the private key on the KDC in a
			form vulnerable to brute-force attack.
	PA-PK-AS-EXT-CERT ::= SEQUENCE {		In order to obtain a private key, the client includes a
	userCert[0] SEQUENCE OF OCTET STRING,		preauthentication field with the AS-REQ message:
	signedAuth[1] SignedPKAuthenticator
	}
	where the user-cert specification depends on the type of		PA-PK-KEY-REQ ::= SEQUENCE {
	certificate that the user possesses. In cases where the service		-- PA TYPE 20
	has separate key pairs for digital signature and for encryption,		patimestamp [0] KerberosTime OPTIONAL,
	we recommend that the signature keys be used for the purposes of		-- used to address replay attacks.
	sending the preauthentication (and deciphering the response).		pausec [1] INTEGER OPTIONAL,
			-- used to address replay attacks.
			nonce [2] INTEGER,
			-- binds the reply to this request
			privkeyID [3] SEQUENCE OF KeyID OPTIONAL
			-- constructed as a hash of
			-- public key corresponding to
			-- desired private key
			}
	The authenticator is the one used from the exchange in section		KeyID ::= SEQUENCE {
	3.2.1, except that it is signed using the private key corresponding		KeyIdentifier [0] OCTET STRING
	to the public key in the user-cert.		}
	The KDC will verify the preauthentication authenticator, and check the		The client may request a specific private key by sending the
	certification path against its own policy of legitimate certifiers.		corresponding ID. If this field is left empty, then all
	This may be based on a certification hierarchy, or simply a list of		private keys are returned.
	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 responds as described in the above
	but with the names of all the certifiers in the certification path		sections, except that an additional preauthentication field,
	added to the transited field of the ticket, with a principal name		containing the user's private key, accompanies the reply:
	taken from the certificate (this might be a long path for X.509, or a
	string like "John Q. Public <jqpublic@company.com>" if the certificate
	was a PGP certificate. The realm will identify the kind of
	certificate and the final certifier as follows:
	cert_type/final_certifier		PA-PK-KEY-REP ::= SEQUENCE {
			-- PA TYPE 21
			nonce [0] INTEGER,
			-- binds the reply to the request
			KeyData [1] SEQUENCE OF KeyPair
			}
	as in PGP/<endorser@company.com>.		KeyPair ::= SEQUENCE {
			privKeyID [0] OCTET STRING,
			-- corresponding to encPrivKey
			encPrivKey [1] OCTET STRING
			}
	3.4. Digital Signature		3.4.1. Additional Protection of Retrieved Private Keys
	Implementation of the changes in this section is OPTIONAL.		We solicit discussion on the following proposal: that the client may
			optionally include in its request additional data to encrypt the
			private key, which is currently only protected by the user's
			password. One possibility is that the client might generate a
			random string of bits, encrypt it with the public key of the KDC (as
			in the SignedKeyPack, but with an ordinary OCTET STRING in place of
			an EncryptionKey), and include this with the request. The KDC then
			XORs each returned key with this random bit string. (If the bit
			string is too short, the KDC could either return an error, or XOR
			the returned key with a repetition of the bit string.)
	We offer this option with the warning that it requires the client		In order to make this work, additional means of preauthentication
	process to generate a random DES key; this generation may not		need to be devised in order to prevent attackers from simply
	be able to guarantee the same level of randomness as the KDC.		inserting their own bit string. One way to do this is to store
			a hash of the password-derived key (the one used to encrypt the
			private key). This hash is then used in turn to derive a second
			key (called the hash-key); the hash-key is used to encrypt an ASN.1
			structure containing the generated bit string and a nonce value
			that binds it to the request.
	If a user registered a digital signature key pair with the KDC,		Since the KDC possesses the hash, it can generate the hash-key and
	a separate exchange may be used. The client sends a KRB_AS_REQ		verify this (weaker) preauthentication, and yet cannot reproduce
	as described in section 3.2.2. If the user's database record		the private key itself, since the hash is a one-way function.
	indicates that a digital signature key is to be used, then the
	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.		4. Logistics and Policy Issues
	The client generates a random key of enctype ENCTYPE_DES_CBC_CRC,
	signs it using the signature key (otherwise the signature is
	performed as described in section 3.2.1), then encrypts the whole
	with the public key of the KDC. This is returned with a separate
	KRB_AS_REQ in a preauthentication of type
	PA-PK-AS-SIGNED ::= SEQUENCE {		We solicit discussion on how clients and KDCs should be configured
	signedKey[0] EncryptedData -- PaPkAsSignedData		in order to determine which of the options described above (if any)
	}		should be used. One possibility is to set the user's database
			record to indicate that authentication is to use public key
			cryptography; this will not work, however, in the event that the
			client needs to know before making the initial request.
	PaPkAsSignedData ::= SEQUENCE {		5. Compatibility with One-Time Passcodes
	signedKeyPart[0] SignedKeyPart,
	signedKeyAuth[1] PKAuthenticator,
	sig[2] Signature
	}
	SignedKeyPart ::= SEQUENCE {		We solicit discussion on how the protocol changes proposed in this
	encSignedKey[0] EncryptionKey,		draft will interact with the proposed use of one-time passcodes
	nonce[1] INTEGER		discussed in draft-ietf-cat-kerberos-passwords-00.txt.
	}
	where the nonce is the one from the request. Upon receipt of the
	request, the KDC decrypts, then verifies the random key. It then
	replies as per RFC 1510, except that instead of being encrypted
	with the password-derived DES key, the reply is encrypted using
	the randomKey sent by the client. Since the client already knows
	this key, there is no need to accompany the reply with an extra
	preauthentication field. Because there is direct trust between
	the user and the KDC, the transited field of the ticket returned
	by the KDC should remain empty. (Cf. Section 3.3.)
	In the event that the KDC database indicates that the user		6. Strength of Cryptographic Schemes
	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		In light of recent findings on the strength of MD5 and DES,
			we solicit discussion on which encryption types to incorporate
			into the protocol changes.
	We propose that the following preauthentication types be allocated		7. Bibliography
	for the preauthentication data packages described in this draft:
	#define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */		[1] J. Kohl, C. Neuman. The Kerberos Network Authentication
	#define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */		Service (V5). Request for Comments: 1510
	#define KRB5_PADATA_PUBLIC_REQ 19 /* PA-PK-AS-REQ */
	#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_SIGN 22 /* PA-PK-AS-SIGNED */
	5. Encryption Information		[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
			for Computer Networks, IEEE Communications, 32(9):33-38.
			September 1994.
	For the public key cryptography used in direct registration, we		[3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
	used (in our implementation) the RSAREF library supplied with the		Transport Layer Security (TLS).
	PGP 2.6.2 release. Encryption and decryption functions were		draft-ietf-tls-kerb-cipher-suites-00.txt
	implemented directly on top of the primitives made available
	therein, rather than the fully sealing operations in the API.
	6. Compatibility with One-Time Passcodes		[4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
			Tickets for Application Servers (PKTAPP).
			draft-ietf-cat-pktapp-00.txt
	We solicit discussion on how the use of public key cryptography		[5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using
	for initial authentication will interact with the proposed use of		Public Key Cryptography. Symposium On Network and Distributed System
	one time passwords discussed in Internet Draft		Security, 1997.
	<draft-ietf-cat-kerberos-passwords-00.txt>.
	7. Strength of Encryption and Signature Mechanisms		[6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
			Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce,
			July 1995.
	In light of recent findings on the strengths of MD5 and various DES		[7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
	modes, we solicit discussion on which modes to incorporate into the		The SSL Protocol, Version 3.0 - IETF Draft.
	protocol changes.
	8. Expiration		[8] B.C. Neuman, Proxy-Based Authorization and Accounting for
			Distributed Systems. In Proceedings of the 13th International
			Conference on Distributed Computing Systems, May 1993
	This Internet-Draft expires on April 19, 1997.		[9] ITU-T (formerly CCITT)
			Information technology - Open Systems Interconnection -
			The Directory: Authentication Framework Recommendation X.509
			ISO/IEC 9594-8
	9. Authors' Addresses		8. Acknowledgements
	B. Clifford Neuman		Some of the ideas on which this proposal is based arose during
	USC/Information Sciences Institute		discussions over several years between members of the SAAG, the IETF
	4676 Admiralty Way Suite 1001		CAT working group, and the PSRG, regarding integration of Kerberos
	Marina del Rey, CA 90292-6695		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
			attempt to revive some of the goals of those groups, and this
			proposal approaches those goals primarily from the Kerberos
			perspective. Lastly, comments from groups working on similar ideas
			in DCE have been invaluable.
	Phone: 310-822-1511		9. Expiration Date
	EMail: bcn@isi.edu
	Brian Tung		This draft expires September 30, 1997.
	USC/Information Sciences Institute
	4676 Admiralty Way Suite 1001
	Marina del Rey, CA 90292-6695
	Phone: 310-822-1511		10. Authors
	EMail: brian@isi.edu
	John Wray		Clifford Neuman
	Digital Equipment Corporation		Brian Tung
	550 King Street, LKG2-2/Z7		USC Information Sciences Institute
	Littleton, MA 01460		4676 Admiralty Way Suite 1001
			Marina del Rey CA 90292-6695
			Phone: +1 310 822 1511
			E-mail: {bcn, brian}@isi.edu
	Phone: 508-486-5210		John Wray
	EMail: wray@tuxedo.enet.dec.com		Digital Equipment Corporation
			550 King Street, LKG2-2/Z7
			Littleton, MA 01460
			Phone: +1 508 486 5210
			E-mail: wray@tuxedo.enet.dec.com
	Jonathan Trostle		Ari Medvinsky
	CyberSafe Corporation		Matthew Hur
	1605 NW Sammamish Rd., Suite 310		CyberSafe Corporation
	Issaquah, WA 98027-5378		1605 NW Sammamish Road Suite 310
			Issaquah WA 98027-5378
			Phone: +1 206 391 6000
			E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
	Phone: 206-391-6000		Jonathan Trostle
	EMail: jonathan.trostle@cybersafe.com		Novell
			E-mail: jonathan.trostle@novell.com
End of changes. 106 change blocks.
	980 lines changed or deleted		460 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/