draft-ietf-cat-kerberos-pk-recovery-00.txt   draft-ietf-cat-kerberos-pk-recovery-01.txt 
INTERNET-DRAFT Jonathan Trostle INTERNET-DRAFT Jonathan Trostle
draft-ietf-cat-kerberos-pk-recovery-00.txt draft-ietf-cat-kerberos-pk-recovery-01.txt Cisco Systems
Updates: RFC 1510 Updates: RFC 1510
expires August 2, 1998 expires May 23, 1999
Public Key Cryptography for KDC Recovery in Kerberos V5 Public Key Cryptography for KDC Recovery in Kerberos V5
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 29 skipping to change at line 28
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-recovery-00.txt, and expires August 2, draft-ietf-cat-kerberos-pk-recovery-01.txt, and expires May 23,
1998. Please send comments to the authors. 1999. Please send comments to the authors.
1. Abstract 1. Abstract
This document defines extensions to the Kerberos protocol This document defines extensions to the Kerberos protocol
specification (RFC 1510, ''The Kerberos Network Authentication specification (RFC 1510, "The Kerberos Network Authentication
Service (V5)'', September 1993) to enable the recovery of a Service (V5)", September 1993) to enable the recovery of a
compromised Kerberos V5 KDC using public key cryptography. compromised Kerberos V5 KDC using public key cryptography.
The document specifies the recovery protocol which uses The document specifies the recovery protocol which uses
preauthentication data fields and error data fields in Kerberos preauthentication data fields and error data fields in Kerberos
messages to transport recovery data. messages to transport recovery data.
2. Motivation 2. Motivation
For both secret key based systems and public key based systems, For both secret key based systems and public key based systems,
compromise of the security server (KDC in the secret key system and compromise of the security server (KDC in the secret key system and
CA or certificate authority in the public key system) leads to a CA or certificate authority in the public key system) leads to a
skipping to change at line 59 skipping to change at line 58
Assuming that a root key is intact in the public key system, new Assuming that a root key is intact in the public key system, new
high-level certificates can be signed, any suspicious certificates high-level certificates can be signed, any suspicious certificates
can be revoked, and the system can eventually return to normal can be revoked, and the system can eventually return to normal
operation without excessive administrator involvement. For a pure operation without excessive administrator involvement. For a pure
secret key based system such as Kerberos V5, the recovery secret key based system such as Kerberos V5, the recovery
operation is very difficult from an administrative point of view, operation is very difficult from an administrative point of view,
since all users must receive new passwords out of band. since all users must receive new passwords out of band.
This document describes an extension to Kerberos V5 that can be This document describes an extension to Kerberos V5 that can be
used in conjunction with the protocol in [2] used in conjunction with the protocol in [2]
(draft-ietf-cat-kerberos-pkinit-05.txt) to allow a KDC to be (draft-ietf-cat-kerberos-pkinit-07.txt) to allow a KDC to be
automatically recovered once the administrator has reinstalled automatically recovered once the administrator has reinstalled
the operating system and loaded (and certified) the new KDC public the operating system and loaded (and certified) the new KDC public
key. Although the protocols in [2] are a step towards making the KDC key. Although the protocols in [2] are a step towards making the KDC
recovery problem easier, they do not go far enough since there are recovery problem easier, there are still potentially many secret keys
still potentially many secret keys stored on the KDC. For example, stored on the KDC. For example, when the user private key is stored
when the user private key is stored on the KDC, the user and the on the KDC, the user and the KDC share a secret key that is used for
KDC share a secret key that is used for authentication. The two main authentication. The two main issues for recovery are updating the KDC
issues for recovery are updating the KDC public key with all clients public key with all clients, which will happen automatically since we
(which will happen automatically if the KDC public keys are signed assume the KDC public keys are signed as part of a public key
as part of a public key infrastructure with a revocation infrastructure with a revocation capability, and updating the shared
capability), and updating the shared secret keys that are stored on secret keys that are stored on the KDC.
the KDC.
We now describe the requirements for the recovery extension: We now describe the requirements for the recovery extension:
(1) Users that use password based keys to authenticate to the KDC (1) Users that use password based keys to authenticate to the KDC
(as in section 3.4 of [2] will have those keys automatically changed (as in section 3.4 of [2] will have those keys automatically changed
by the recovery protocol; the users will not have to change their by the recovery protocol; the users will not have to change their
passwords. We will satisfy this requirement by obtaining the secret passwords. We will satisfy this requirement by obtaining the secret
key K2 of section 3.4 of [2] by hashing the key K1 with a salt value key K2 of section 3.4 of [2] by hashing the key K1 with a salt value
supplied by the KDC. The update operation during recovery consists supplied by the KDC. The update operation during recovery consists
of changing the salt value. of changing the salt value. Optionally, the KDC can ask users to
(2) The recovery extension should work either in the case where change their passwords in order to support recovery in an environment
the KDC public keys are signed as keys in a public key infrastructure where users use both recovery capable and non-recovery capable clients.
or in the case where the KDC public keys are self-signed (i.e., root (2) The recovery extension requires the KDC public keys to be signed
keys). The second case will be satisfied by downloading multiple in certificates as part of a public key infrastructure that includes
KDC public keys into clients and keeping the later version KDC a revocation capability.
private keys offline. The second case is useful in an environment (3) Recovery capable clients must be pkinit [2] capable.
without a deployed public key infrastructure that includes a
revocation mechanism.
We will use the definitions and ASN.1 structures from [2]; we assume We will use the definitions and ASN.1 structures from [2]; we assume
familiarity on the part of the reader. familiarity on the part of the reader.
3. The Recovery Extension Protocol 3. The Recovery Extension Protocol
We now briefly overview the proposed recovery extension. When the We now briefly overview the proposed recovery extension. When the
recovery operation is launched, the KDC host operating system along recovery operation is launched, the KDC host operating system(s) for
with the database is reloaded from backup media. The new KDC public the realm along with the KDC database is reloaded from backup media.
key certificate is placed into the appropriate certificate database The new KDC public key certificate is placed into the appropriate
(if needed), and the old certificate is revoked if the the KDC certificate database (if needed), and the old certificate is revoked
certificate was signed by another authority. In the case the KDC by administrator action. For all principals that have symmetric keys
certificate is self-signed, the KDC contacts the clients that need in the database, the keys are zeroized.
to receive the new certificate (using the
KDC_ERR_RECOVERY_HOST_NEEDED error code in a KRB_ERROR message).
This message allows the new self-signed certificates to be
downloaded. Also, any secret keys will be updated. The
sequence of messages between the KDC and the client is as follows:
KDC <-------- AS_REQ (optional) -------- client
KDC -------- KRB_ERROR message -------> client
(error code KDC_ERR_RECOVERY_HOST_NEEDED)
error data: KDC DH parameters, optional self-signed
certs, all signed with new KDC private key
KDC <-------- AS_REQ message ---------- client
(with PA-PK-AS-REQ and PA-PK-RECOVERY-DATA
preauthentication fields)
KDC -------- AS_REP message ---------> client
(with PA-PK-AS-REP preauthentication field)
After these exchanges, the recovery operation is complete except for To complete recovery, the newly created kdcSalt value (a randomly
the updating of the kdcSalt value to clients and the creation of new generated 16 byte string) will be sent to user principals to allow
user shared secrets in the KDC database. This last task is completed them to update their shared secrets in the KDC database. This exchange
allows users to maintain the same passwords. This task is completed
by the following sequence of messages: by the following sequence of messages:
KDC <-------- AS_REQ message ----------- client KDC <-------- AS_REQ message ----------- client
KDC -------- KRB_ERROR message -------> client KDC -------- KRB_ERROR message -------> client
(error code KDC_ERR_RECOVERY_USER_NEEDED) (error code KDC_ERR_RECOVERY_USER_NEEDED)
error data: KDC DH parameters, kdcSalt value, error data: KDC DH parameters, kdcSalt value,
optional PA-PK-KEY-REP (encrypted user private keys)) optional PA-PK-KEY-REP (encrypted user private keys),
optional change password flag
KDC <-------- AS_REQ message ---------- client KDC <-------- AS_REQ message ---------- client
(with PA-PK-AS-REQ and PA-PK-RECOVERY-DATA (with new user (with PA-PK-AS-REQ and PA-PK-RECOVERY-DATA (with new user
secret key K2 encrypted in Diffie-Hellman shared secret secret key K2 encrypted in Diffie-Hellman shared secret
key) preauthentication fields) key) preauthentication fields)
KDC -------- AS_REP message ---------> client KDC -------- AS_REP message ---------> client
(with PA-PK-AS-REP preauthentication field) (with PA-PK-AS-REP preauthentication field)
This exchange of messages is only necessary between the KDC and each This exchange of messages is only necessary between the KDC and each
user principal that has a shared secret key stored in the KDC user principal that has a shared secret key stored in the KDC
database. database.
A recovery capable principal that receives a ticket with an encrypted
part using a key with an unexpected kvno, should perform a pkinit [2]
AS exchange with the KDC, including the
PA-PK-RECOVERY-SET-PRINCKEY-TO-SKEY padata-type to obtain a TGT
with a ticket session key that will be used as the new principal
secret key. In this case, the KDC would have previously generated
the secret key to encrypt the ticket, based on the TGS_REQ from the
client, and the database bits indicating that the server principal
should have a valid symmetric key but one does not exist in the
database. The KDC will always use the symmetric key with the
appropriate keytype from the database as the ticket session key
when receiving a pkinit request with the
PA-PK-RECOVERY-SET-PRINCKEY-TO-SKEY padata-type. The padata-value
for this padata-type is an empty octet string.
3.1 Definitions 3.1 Definitions
The proposed extension includes a new algorithm for computing the The proposed extension includes a new algorithm for computing the
shared key between a user and the KDC. The new algorithm involves shared key between a user and the KDC. The new algorithm involves
computing the SHA1 hash of a string (kdcSalt) supplied by the KDC computing the SHA1 hash of a string (kdcSalt) supplied by the KDC
concatenated with the RFC 1510 shared key (the key K1 from section concatenated with the RFC 1510 shared key (the key K1 from section
3.4 of [2]) to obtain a new DES key K2 that is shared between the 3.4 of [2]) to obtain a new DES key K2 that is shared between the
user and the KDC. We propose etype and keytype 16 for this user and the KDC. We propose etype and keytype 16 for this
algorithm: algorithm:
DES-recoverable-key 16 DES-recoverable-key 16
Similarly, we propose the same definition for 3DES where the key
K2 or RFC 1510 shared key is a 3DES key:
3DES-recoverable-key 17
If the KDC expects the client to preauthenticate using the key K2 If the KDC expects the client to preauthenticate using the key K2
with keytype DES-recoverable-key, and the client does not with a recoverable key keytype, and the client does not
preauthenticate, then the e-data for the error preauthenticate, then the e-data for the error
KDC_ERR_PREAUTH_REQUIRED will be present containing the kdcSalt KDC_ERR_PREAUTH_REQUIRED will be present containing the kdcSalt
value encoded as an OCTET STRING. If the client preauthenticates value encoded as an OCTET STRING. If the client preauthenticates
with the key K2 having keytype DES-recoverable-key, the with the key K2 having keytype DES-recoverable-key, the
preauthentication fails, and the KDC has a key of the same keytype preauthentication fails, and the KDC has a key of the same keytype
in the database, then the e-data for the error KDC_ERR_PREAUTH_FAILED in the database, then the e-data for the error KDC_ERR_PREAUTH_FAILED
will be present containing the kdcSalt value encoded as an OCTET will be present containing the kdcSalt value encoded as an OCTET
STRING. STRING.
As a performance optimization, the kdcSalt is stored in the As a performance optimization, the kdcSalt can be locally stored on
/krb5/salt file along with the realm. Thus the /krb5/salt file the workstation along with the corresponding realm. If the local
consists of realm-salt pairs. If the file is missing, or the salt is configuration is missing, or incorrect, the above error messages
not correct, the above error messages allow the client to find out allow the client to find out the correct salt. Clients which are
the correct salt. Clients which are configured for symmetric key configured for symmetric key with a recoverable key keytype,
authentication with the keytype DES-recoverable-key attempt to attempt to preauthenticate with the salt from the local configuration
preauthenticate with the salt from the /krb5/salt file as an input as an input into their key, and if the local configuration is not
into their key, and if the file is not present, the client does not present, the client does not use preauthentication.
use preauthentication.
The following new preauthentication types are proposed: The following new preauthentication types are proposed:
PA-PK-RECOVERY-SUPPORTED 19 PA-PK-RECOVERY-USER-SUPPORTED 19
PA-PK-RECOVERY-DATA 20 PA-PK-RECOVERY-DATA 20
PA-PK-RECOVERY-SET-SKEY-TO-PRINCKEY 21
The following new error codes are proposed: The following new error code is proposed:
KDC_ERR_RECOVER_HOST_NEEDED 67 KDC_ERR_RECOVER_USER_NEEDED 67
KDC_ERR_RECOVER_USER_NEEDED 68
We propose the following additional KDC database bits. The first new We propose the following additional KDC database bits. The first
KDC database bit applies to all clients (non-human principals) and database bit applies to all principals to indicate whether a principal
indicates whether a client supports recovery. The second database bit should have a valid symmetric key in the database. The second bit
applies to all principals to indicate whether a principal should have applies to all principals that should have a valid symmetric key
a valid symmetric key in the database. The third bit applies to all to indicate if the principal symmetric key is valid.
principals to indicate if the principal symmetric key in the KDC
database is valid. The fourth bit applies to all clients and
indicates whether the recovery capable client (this bit is only set
if the client is recovery capable) needs to receive self-signed KDC
certificates from the KDC. The fifth bit applies to all clients and
tells whether the recovery capable client that needs self-signed KDC
certificates has received them as part of the most recent recovery
operation.
The third and fifth database bits are cleared when the KDC undergoes The second database bit is cleared when the KDC undergoes a recovery
a recovery operation. operation, and all principal secret keys are zeroized as well. The
non-human principal keys are then regenerated when a request comes
in, and the corresponding validity bits are set.
3.2 Protocol Specification 3.2 Protocol Specification
We now describe the recovery protocol. The recovery operation can be We now describe the recovery protocol. The recovery operation can be
set into motion either because a compromise is detected, or as part of set into motion either because a compromise is detected, or as part of
a periodic preventative operation. The KDC host operating system and a periodic preventative operation. The KDC host operating system and
KDC executable is restored from backup media, and the KDC is loaded KDC executable is restored from backup media, and the KDC is loaded
with a backup private/public key pair. The KDC database is also with a backup private/public key pair. The KDC database is also
reloaded, and any secret keys are zeroized. The clients already have reloaded, and any secret keys are zeroized. The new KDC public key is
the public half of this backup key pair in the form of a self-signed signed by the appropriate authority and placed in the appropriate
certificate, or the new KDC public key is signed by the appropriate location and any necessary revocation steps are taken for the old
authority and placed in the appropriate location and any necessary certificate.
revocation steps are taken for the old certificate.
Any clients that hold the KDC public keys in the form of self-signed
certificates must be notified by the KDC and sent any new self-signed
certificates. These clients can now discard the current KDC self
-signed certificate (if it has not already been discarded due to an
expired validity date). We propose ports 10001/TCP and 10001/UDP as
the ports for these clients to listen on.
The KDC will notify the clients that need new self-signed certificates
and/or to update their secret keys with a KRB_ERROR message with error
code KDC_ERR_RECOVERY_HOST_NEEDED. The following ASN.1 structure is
encoded and placed into the error message e-data field (an OCTET
STRING):
HostRecoveryError ::= SEQUENCE {
kdcPublicValue [0] SubjectPublicKeyInfo,
-- DH algorithm
kdcPubValueId [1] INTEGER, -- DH algorithm
-- index for KDC
nonce [2] INTEGER OPTIONAL, -- Only if in
-- response to AS_REQ
-- (copy nonce)
newKDCPubKey [3] KDCPubKey OPTIONAL
-- only if KDC sends
-- new self-signed
-- certs or kdcCert
}
KDCPubKey ::= CHOICE {
kdcCert [0] SEQUENCE OF Certificates
-- KDC cert chain
-- from [2]
newKDCCertInfo [1] KDCCertInfo
}
KDCCertInfo ::= SEQUENCE {
kdcPublicKeys [0] SEQUENCE OF Certificate
-- New KDC self-signed
-- certificates
kdcPublicKeyKvno [1] INTEGER -- New KDC public
-- key kvno
}
The e-cksum field of the error message is not optional for this error
code; it will contain the signature of the entire error message (as
described in [1]: the signature is computed over the ASN.1 encoded
error message without the e-cksum field, and then the signature is
placed into the e-cksum field and the message is re-encoded.) The KDC
will sign using the private half of its new active key pair. The key
version number for the signing key must correspond to the new
KDC certificate.
The purpose of the kdcPubValueId identifier in the error message is
to enable the KDC to offload state to the client; 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 newKDCCertInfo field is only present if the KDC sends new self
-signed certificates to the client.
Note: The non-PKI protocol for recovery depends on the downloading of
new public key certificates into the client as a notification mechanism
that the old KDC public key certificate is revoked. In the case where
some clients are intermitently connected to the network (e.g., laptops
and dial-in clients), then the non-PKI protocol for recovery may leave
these intermitently connected clients open to server spoofing attacks.
One way to solve this problem is to shorten the validity period of the
KDC public key certificates. Another solution to the problem is to
integrate PKI functionality (a revocation mechanism) into the
Kerberos V5 public key clients.
If the KRB_ERROR message passes the security checks (the nonce should
match the client AS_REQ nonce if the error message is a reply, the KDC
signature validates and the signing key has the proper key version
number (kvno), and the KDC self-signed certificates are valid), the
client replies to the KDC with an AS_REQ message containing the
PA-PK-RECOVERY-DATA padata-type preauthentication field along with a
PA-PK-AS-REQ preauthentication field (see [2]):
PA-PK-RECOVERY-DATA ::= SEQUENCE {
kdcPubValueId [0] INTEGER, -- Copied from error
-- message
kdcPublicKeyKvno [1] INTEGER OPTIONAL -- New KDC public
-- key kvno if
-- KDCCertInfo was
-- present in error
-- (copied)
newUserKey [2] EncryptedData -- only present in
OPTIONAL -- reply to
-- KDC_ERR_RECOVERY_
-- USER_NEEDED error;
-- uses DH shared
-- key to encrypt the
-- new key K2.
sigAll [3] Signature -- uses shared DH key
-- computed over
-- entire encoded
-- AS_REQ without
-- this field, then
-- re-encode message
-- with this field
}
The clientPublicValue field in the AuthPack structure must be filled
in by the client (in the PA-PK-AS-REQ preauthentication field, since
Diffie-Hellman is required).
Upon receiving this message from the client, the KDC then makes the
normal PA-PK-AS-REQ validation and also checks that the sigAll seal
is valid after computing the shared Diffie-Hellman key. We note that
the KDC should use the ctime and cusec fields in the PA-PK-AS-REQ
message to ensure that the client AS_REQ message is not a replay.
(The KDC also checks that the kdcPublicKeyKvno is correct (that it
is the current version), and uses the kdcPubValueId to look up its
own Diffie-Hellman parameters).
The KDC now sends an AS_REP message with the PA-PK-AS-REP
preauthentication fields.
The client should validate this message (including the normal
PA-PK-AS-REP checks) before updating any secret keys or KDC
self-signed certificates.
To complete the recovery process, the KDC will also notify users To complete the recovery process, the KDC will also notify users
that need to update any shared secrets that are stored in the KDC that need to update any shared secrets that are stored in the KDC
database; a KRB_ERROR message with the error code database: a KRB_ERROR message with the error code
KDC_ERR_RECOVERY_USER_NEEDED is sent in response to these user's KDC_ERR_RECOVERY_USER_NEEDED is sent in response to these user's
AS_REQ messages that do not contain the PA-PK-RECOVERY-DATA AS_REQ messages that do not contain the PA-PK-RECOVERY-DATA
preauthentication types. The following ASN.1 structure is encoded preauthentication type, contain the PA-PK-RECOVERY-USER-SUPPORTED
preauthentication type, when there is no valid symmetric key in
the KDC database, but there needs to be one.
The following ASN.1 structure is encoded
and placed into the error message e-data field (an OCTET STRING): and placed into the error message e-data field (an OCTET STRING):
UserRecoveryError ::= SEQUENCE { UserRecoveryError ::= SEQUENCE {
kdcSalt [0] OCTET STRING, -- to be hashed kdcSalt [0] OCTET STRING, -- to be hashed
-- with password -- with password
-- key K1 -- key K1
kdcPublicValue [1] SubjectPublicKeyInfo, kdcPublicValue [1] SubjectPublicKeyInfo,
-- DH algorithm -- DH algorithm
kdcPubValueId [2] INTEGER, -- DH algorithm kdcPubValueId [2] INTEGER, -- DH algorithm
nonce [3] INTEGER OPTIONAL, -- copy nonce nonce [3] INTEGER OPTIONAL, -- copy nonce
skipping to change at line 373 skipping to change at line 243
paPkKeyRep [4] OCTET STRING OPTIONAL paPkKeyRep [4] OCTET STRING OPTIONAL
-- ASN.1 encoded -- ASN.1 encoded
-- PA-PK-KEY-REP -- PA-PK-KEY-REP
-- from section -- from section
-- 3.4 of [2] -- 3.4 of [2]
-- (encrypted -- (encrypted
-- user private -- user private
-- keys) -- keys)
kdcCert [5] SEQUENCE OF Certificate, OPTIONAL kdcCert [5] SEQUENCE OF Certificate, OPTIONAL
-- cert chain -- cert chain
changePassword [6] BOOLEAN OPTIONAL, -- user client
-- should use
-- change password
-- protocol if
-- present
} }
The purpose of the kdcPubValueId identifier in the error message is
to enable the KDC to offload state to the client; 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 one
and several dozen of these identifiers and their parameters.
The e-cksum field of the error message is not optional for this error The e-cksum field of the error message is not optional for this error
code; it will contain the signature of the entire error message (as code; it will contain the signature of the entire error message (as
described in [1]: the signature is computed over the ASN.1 encoded described in [1]: the signature is computed over the ASN.1 encoded
error message without the e-cksum field, and then the signature is error message without the e-cksum field, and then the signature is
placed into the e-cksum field and the message is re-encoded.) The placed into the e-cksum field and the message is re-encoded.) The
KDC will sign using the private half of its new active key pair. KDC will sign using the private half of its new active key pair.
Upon checking the KRB_ERROR message, the client obtains the user Upon checking the KRB_ERROR message, the client obtains the user
password and uses the kdcSalt to compute the new key K2 which is password and uses the kdcSalt to compute the new key K2 which is
computed by SHA1 hashing the concatenation of the kdcSalt and the computed by SHA1 hashing the concatenation of the kdcSalt and the
key K1 obtained from the user password. The result of the hash is key K1 obtained from the user password. The result of the hash is
converted into a DES key by truncating the last 12 bytes and fixing converted into a DES key by truncating the last 12 bytes and fixing
the parity on each of the first 8 bytes. The client then responds the parity on each of the first 8 bytes. The client then responds
with a new AS_REQ message that includes both a PA-PK-RECOVERY-DATA with a new AS_REQ message that includes both a PA-PK-RECOVERY-DATA
padata-type preauthentication field along with a PA-PK-AS-REQ padata-type preauthentication field along with a PA-PK-AS-REQ
preauthentication field (see [2]). The PA-PK-RECOVERY-DATA must preauthentication field (see [2]). The PA-PK-RECOVERY-DATA must
contain the newUserKey field. If the user's AS_REQ message passes contain the newUserKey field. If the user's AS_REQ message passes
the security checks, the KDC will reply with an AS_REP message the security checks, the KDC will reply with an AS_REP message
that contains a PA-PK-AS-REP preauthentication field. The client that contains a PA-PK-AS-REP preauthentication field. The client
will validate this message as described in [2]. will validate this message as described in [2]. (The procedure
for 3DES needs to be defined).
We also define the PA-PK-RECOVERY-SUPPORTED preauthentication We also define the PA-PK-RECOVERY-USER-SUPPORTED preauthentication
field; it will accompany all AS_REQ messages from clients that field; it will accompany all AS_REQ messages from clients that
support the recovery protocol. It serves as an optimization to support the recovery protocol that originate from user principals.
allow the KDC to quickly identify whether the requesting client The padata-value for this padata-type is an empty octet string.
supports recovery. The padata-value for this padata-type is an
empty octet string.
4. Encryption of User Private Key on KDC If the KRB_ERROR message passes the security checks (the nonce should
match the client AS_REQ nonce if the error message is a reply, and
the KDC signature validates), the client replies to the KDC with an
AS_REQ message containing the PA-PK-RECOVERY-DATA padata-type
preauthentication field along with a PA-PK-AS-REQ preauthentication
field (see [2]):
We now discuss recovery issues that arise when the user stores his PA-PK-RECOVERY-DATA ::= SEQUENCE {
private key on the KDC in a key derived from a password. As in kdcPubValueId [0] INTEGER, -- Copied from error
conventional Kerberos V5, it is important that a good password -- message
policy be used. This password policy will prevent dictionary newUserKey [2] EncryptedData -- only present in
attacks against the user private key by an attacker that OPTIONAL -- reply to
compromises the KDC. -- KDC_ERR_RECOVERY_
-- USER_NEEDED error;
-- uses DH shared
-- key to encrypt the
-- new key K2.
sigAll [3] Signature -- uses shared DH key
-- computed over
-- entire encoded
-- AS_REQ without
-- this field, then
-- re-encode message
-- with this field
}
A weakness of using the DES algorithm to encrypt the user private The clientPublicValue field in the AuthPack structure must be filled
key is that the keyspace is only 56 bits. Thus the attacker that in by the client (in the PA-PK-AS-REQ preauthentication field, since
compromises the KDC can perform an offline brute force attack Diffie-Hellman is required).
against the encrypted user private key. We list three approaches
to improving security with respect to such attacks; we solicit
input on these and other approaches.
(1) Use a new encryption algorithm for encrypting private keys: a Upon receiving this message from the client, the KDC then makes the
strawman is the following DESX-like algorithm. The password is normal PA-PK-AS-REQ validation and also checks that the sigAll seal
required to be at least 10 characters and the first 64 bits of it is valid after computing the shared Diffie-Hellman key. We note that
are used as a pre-xor key and as a post-xor key before and after the KDC should use the ctime and cusec fields in the PA-PK-AS-REQ
the normal DES encryption step is completed. Perhaps another message to ensure that the client AS_REQ message is not a replay.
variable length cipher would be appropriate here. (The KDC also checks that the kdcPublicKeyKvno is correct (that it
is the current version), and uses the kdcPubValueId to look up its
own Diffie-Hellman parameters).
(2) Change the recovery protocol to allow the password derived key The KDC now sends an AS_REP message with the PA-PK-AS-REP
K1 that encrypts the user private key to be automatically changed preauthentication fields. The client should validate this message
(by hashing it with a KDC supplied value) after a compromise. (including the normal PA-PK-AS-REP checks).
(3) Force users to change their passwords and private keys after a If the changePassword flag was present in the KDC error message, the
compromise, or just change passwords and private keys for users that client should immediately obtain a change password service ticket
have a lot of access rights. Perhaps an extra bit in the database and use the protocol in [3] to change the user password. This option
could be used to indicate which users need to change their password is useful to support an environment where both non-recovery capable
as part of the recovery operation. and recovery capable clients exist. Since multiple keytypes will
exist on the KDC for a given user, the change password protocol
password field is the raw user inputted password; the KDC is
responsible for deriving the appropriate keys from this password.
In particular, any change password requests should result in
the recoverable keytypes being derived by the RFC 1510 string
to key transformation with salt and then hashing as described
above using the kdcSalt value.
5. Acknowledgement 4. Acknowledgement
This work was previously published as part of draft-ietf-cat- This work was previously published as part of draft-ietf-cat-
kerberos-pkinit-02.txt while the author was employed at Cybersafe kerberos-pkinit-02.txt while the author was employed at Cybersafe
Corporation, 1605 NW Sammamish Rd., Suite 310, Issaquah, WA 98027. Corporation, 1605 NW Sammamish Rd., Suite 310, Issaquah, WA 98027.
Thanks to John Wray, Mark Davis, and the CAT working group for
some valuable suggestions on how to improve the draft.
6. Bibliography 5. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5). Request for Comments 1510. Service (V5). Request for Comments 1510.
[2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle. [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, S. Medvinsky, M. Hur,
Public Key Cryptography for Initial Authentication in Kerberos. J. Trostle. Public Key Cryptography for Initial Authentication
in Kerberos. ftp://ds.internic.net/internet-drafts/
draft-ietf-cat-kerberos-pkinit-07.txt
[3] M. Horowitz. Kerberos Change Password Protocol.
ftp://ds.internic.net/internet-drafts/ ftp://ds.internic.net/internet-drafts/
draft-ietf-cat-kerberos-pkinit-05.txt draft-ietf-cat-kerb-chg-password-02.txt
7. Expiration Date 6. Expiration Date
This draft expires on August 2, 1998. This draft expires on May 23, 1999.
8. Authors' Addresses 7. Authors' Addresses
Jonathan Trostle Jonathan Trostle
150 Woodside Dr. Cisco Systems
Provo, UT 84604 170 W. Tasman Dr.
San Jose, CA 95134
Email: jtrostle@world.std.com, jtt@aa.net Email: jtrostle@cisco.com, jtrostle@world.std.com
 End of changes. 45 change blocks. 
259 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/