oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

original from Brian Tung

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@19623 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Love Hörnquist Åstrand
2007-01-03 00:06:49 +00:00
parent 7b7419e387
commit 51f78097a6
29 changed files with 18294 additions and 2607 deletions
Download Patch File Download Diff File Expand all files Collapse all files

373
doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt Normal file
View File

@@ -0,0 +1,373 @@
INTERNET-DRAFT Clifford Neuman
draft-ietf-cat-kerberos-pk-init-00.txt Brian Tung
Updates: RFC 1510 ISI
expires September 3, 1995 John Wray
Digital Equipment Corporation
Public Key Cryptography for Initial Authentication in Kerberos
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-00.txt, and expires August 6, 1995.
Please send comments to the authors.
1. Abstract
This document defines extensions to the Kerberos protocol specifi-
cation (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 provides 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
each other. In public key cryptography, however, neither key can be
derived easily from the other; hence, the ability to encrypt a message
does not imply the ability to decrypt it in turn. Additionally, each
key is a full inverse of the other, so that either key can be used
for encryption or decryption.
The advantages provided by public key cryptography have produced a
demand for its integration into the Kerberos authentication protocol.
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.
This proposal will allow users with keys already registered for use
with X.509, PEM, or PGP, to use those keys to obtain Kerberos
credentials which can then be used for authentication with application
servers supporting Kerberos.
Use of public-key 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 public keys instead of the current secret key.
The application request and response, between Kerberos clients and
application servers, will continue to be based on conventional
cryptography, and the application servers will continue to be
registered with conventional keys.
3. Initial authentication of users with public keys
This section proposes 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.
The advantage of registering public keys with the KDC lies in the
ease of recovery in case the KDC is compromised. With Kerberos as it
currently stands, compromise of the security KDC is disastrous. All
keys become known by the attacker and all keys must be changed.
If users register public keys, compromise of the KDC does not divulge
their private key. Compromise of security on the KDC is still
disastrous, since the attacker can impersonate any user. An
attacker with the private key of the KDC can use it to certify a
bogus nonce key, and impersonate a user. Changing this key
invalidates all bogus certifications. Legitimate users must
re-certify their keys with the new KDC key, but users' public
keys do not have to be changed. (Users who store their private
keys in an encrypted form on the KDC do have to change their
keys, since the encryption key is a symmetric key derived from
a password (as described below) and hence vulnerable to dictionary
attacks. The difference is that, assuming good password policy,
site policy may allow the use of the old password only for the
purpose of key change for a time after the compromise, which means
that users can change their own passwords, rather than forcing the
administrator to re-key everyone.)
In the event of compromise of the KDC, recovery is simple since only
the KDC's key, keys for application servers, and users' private keys
stored in the KDC (as described above) must be changed.
Since there are usually fewer servers than users, and since an
organization usually has better procedures for updating servers,
changing these keys is much easier than having to individually
contact every user.
This proposed extension will not require users to register with
public keys. It is intended to allow them to do so, but we recognize
that there are many reasons, including licensing terms, that users or
an organization as a whole will choose not to use the public key
option. Users registered will public keys will only be able to
perform initial authentication from a client that support public key,
and must be registered in a realm that supports public key. But they
will be able to use services registered in realms that support only
conventional Kerberos. Further, users registered with conventional
Kerberos keys will be able to use all clients.
This proposal specifically does not address the registration of
public keys for services. The application request and response,
between Kerberos clients and application servers, will continue to be
based on conventional cryptography, and the application servers will
continue to be registered with conventional keys. There are
performance issues and other reasons that servers may be better off
using conventional cryptography. There are also reasons that they
may want to use public key. For this proposal, however, 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.
This proposal address two ways in which users may use public key
cryptography for initial authentication with Kerberos. 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.
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. We first consider the case where the user's key is
registered with the KDC.
3.1 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 known to the user, or
may be stored on the KDC, encrypted so that it can not be used by the KDC.
We consider first the case where the user knows the private key, then
add support for retrieving the private key from the KDC.
The initial request to the KDC for a ticket granting ticket proceeds
according to RFC 1510. Typically, preauthentication using a secret
key would not be included, but if included it may be ignored by the
KDC. (This may introduce a problem: even if the KDC should ignore
the preauthentication, an attacker may not, and use an
intercepted message to guess the password off-line.)
If the private key is known to the client in advance, the
response from the KDC would be identical to the response in RFC1510,
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. A preauthentication field (specified below)
accompanies the response, containing a certificate with the public
key for the KDC, and a package containing the secret key in which the
rest of the response is encrypted, itself encrypted in the private key
of the KDC, and the public key of the user. This package also contains
the same nonce used in the rest of the response, in order to prevent
replays of this part of the message, accompanied by a reconstructed
response.
PA-PK-AS-REP ::= SEQUENCE {
kdc-cert SEQUENCE OF OCTET STRING,
encryptPack EncryptedData -- EncPaPkAsRepPart
}
EncPaPkAsRepPart ::= SEQUENCE {
enc-sess-key INTEGER,
nonce INTEGER
}
Upon receipt of the response from the KDC, the client will verify the
public key for the KDC from PA-PK-AS-REP preauthentication data field,
The certificate must certify the key as belonging to a principal whose
name can be derived from the realm name. We solicit discussion on the
form of the kdc-cert. If client systems are expected to know (by
being hard-coded, for example) at least one public key, and to verify
certificates from that key, then there should be at least some policy
about which key that is, or alternatively some way to inform the KDC
which key the client possesses.
If the certificate checks
out, the client then extracts the message key for the rest of the
response by decrypting the field in the PA-PK-AS-REP with the public
key of the KDC and the private key of the user. The client then uses
the message key to decrypt the rest of the response, and continues as
per RFC1510[1].
3.1.1. Private key held by KDC
When the user's private key is not carried with the user, the user may
encrypt the private key using conventional cryptography, and register
the encrypted private key with the KDC.
When the user's private key is registered with the KDC, the KDC record
will also indicate whether preauthentication is required before
returning the record (we recommend that it be required). If such
preauthentication is required, when the initial request is received
the KDC will respond with a KRB_ERROR message of type
KDC_ERR_PREAUTH_REQUIRED and with an error data field set to:
PA-PK-AS-INFO ::= SEQUENCE {
kdc-cert OCTET STRING}
}
The kdc-cert field is identical to that in the PA-PK-AS-REP
preauthentication data field returned with the KDC response, and must
be validated as belonging to the KDC in the same manner.
Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the
client will prompt the user for the password that will be used to
decrypt the private key when returned, calculate a one way hash H1 of the
key, and send a request to the KDC, including a timestamp and a
client-generated nonce secret key that will be used to super-encrypt
the encrypted private key before it is returned to the client. This
information is sent to the KDC in a subsequent AS_REQ message in a
preauthentication data field:
PA-PK-AS-REQ ::= SEQUENCE {
enc-part EncryptedData -- EncPaPkAsReqPart
}
EncPaPkAsReqPart ::= SEQUENCE {
tstamp KerberosTime,
noncekey INTEGER
}
encrypted first with the hash H1, then the public key of the KDC from
the certificate in the PA-PK-AS-INFO field of the error response.
Upon receipt of the authentication request with the PA-PK-AS-REQ the
KDC verifies the hash of the user's DES encryption key by comparing it
to the hash stored in the users database record. If valid, it
generates the AS response as defined in RFC1510, but additionally
includes a preauthentication field of type PA-PK-USER KEY. This
response will also be included in response to the initial request
without preauthentication if preauthentication is not required for the
user and the user's encrypted private key is stored on the KDC. The
KDC generates a preauthentication data field of type PA-PK-USER-KEY
which will be returned with the KDC reply (together with the
PA-PK-AS-REP that is already returned).
PA-PK-USER-KEY ::= SEQUENCE {
enc-priv-key OCTET STRING OPTIONAL
}
This message contains the encrypted private key that has been
registered with the KDC by the user, as encrypted by the user,
super-encrypted with the noncekey from the PA-PK-AS-REQ message if
preauthentication using that method was provided. Note that since
H1 is a one-way hash, it is not possible for one to decrypt the
message if one possesses H1 but not the noncekey that H1 is derived
from.
3.2. Clients with a public key certified by an outside authority
In the case where the client is not registered with the current KDC,
the client is responsible for obtaining the private key on its own.
The client will request initial tickets from the KDC using the TGS
exchange, but instead of performing pre-authentication using a
Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used
when the public key is known to the KDC, the client performs
preauthentication using the preauthentication data field of type
PA-PK-AS-EXT-CERT:
PA-PK-AS-EXT-CERT ::= SEQUENCE {
user-cert SEQUENCE OF OCTET STRING,
authent EncryptedData -- PKAuthenticator
}
PKAuthenticator ::= SEQUENCE {
cksum Checksum OPTIONAL,
cusec INTEGER,
ctime KerberosTime,
}
The fields in the encrypted authenticator are the same as those
in the Kerberos authenticator. The structure is itself signed using
the user's private key corresponding to the public key in the
certificate.
The KDC will verify the preauthentication authenticator, and check the
certification path against its own policy of legitimate certifiers.
This may be based on a certification hierarchy, or simply a list of
recognized certifiers in a system like PGP.
If all checks out, the KDC will issue Kerberos credentials, as in 3.1,
but with the names of all the certifiers in the certification path
added to the transited field of the ticket, with a principal name
taken from the certificate (this might be a long path for X.509, or a
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 (e.g. PGP:<endorser@company.com>)[2].
4. Compatibility with One-Time Passcodes
We solicit discussion on how the use of public key crytpgraphy for
intial authentication will interact with the proposed use of one time
passwords discussed in Internet Draft
draft-ietf-cat-kerberos-passwords-00.txt
5. Expiration
This Internet-Draft expires on August 6, 1995.
6. Authors' Addresses
B. Clifford Neuman
USC/Information Sciences Institute
4676 Admiralty Way #1001
Marina del Rey, CA 90292-6695
Phone: 310-822-1511
EMail: bcn@isi.edu
Brian Tung
USC/Information Sciences Institute
4676 Admiralty Way #1001
Marina del Rey, CA 90292-6695
Phone: 310-822-1511
EMail: brian@isi.edu
John Wray
Digital Equipment Corporation
550 King Street, LKG2-2/Z7
Littleton, MA 01460
Phone: 508-486-5210
EMail: wray@tuxedo.enet.dec.com
[1] Note: We have not yet defined the public key encryption method for
encrypting the enc-sess-key field in the PA-PK-AS-REP.
[2] Note: We are soliciting input on the form of the name. We believe the
name part must be taken without modification from the certificate, but the
realm part is open for discussion.

614
doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt Normal file
View File

@@ -0,0 +1,614 @@
INTERNET-DRAFT Clifford Neuman
draft-ietf-cat-kerberos-pk-init-01.txt Brian Tung
Updates: RFC 1510 ISI
expires December 7, 1996 John Wray
Digital Equipment Corporation
Public Key Cryptography for Initial Authentication in Kerberos
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-01.txt, and expires December 7, 1996.
Please send comments to the authors.
1. Abstract
This document defines extensions to the Kerberos protocol specifi-
cation (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 primary advantage of registering public keys with the KDC lies in
the ease of recovery in case the KDC 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.
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 certifying a
bogus key with the KDC's private key. However, all bogus
certificates can be invalidated by revoking and changing the
KDC's public key. Legitimate users have to re-certify their public
keys with the new KDC key, but the users's keys themselves do not
need to be changed. 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 he does have to change the key pair, since the private key
is encrypted using a symmetric key derived from a password (as
described below), and is therefore vulnerable to dictionary attack.
Assuming good password policy, however, legitimate users may be
allowed to use the old password for a limited time, solely for the
purpose of changing the key pair. The realm administrator is then
not forced to re-key all users.
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. This
proposal is based on the implementation already made available;
nevertheless, we solicit any comments on modifications or additions
to the protocol description below.
Roughly speaking, the following changes to RFC 1510 are proposed:
a. The KDC's response is encrypted using a random nonce key,
rather than the user's secret key.
b. This random key accompanies the response in a
preauthentication field, encrypted and signed using the
public key pairs of the user and the KDC.
Certificate and message formats are also defined in this section.
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 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, and they will then only be able
to perform initial authentication from a client that supports public key,
although 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 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
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
}
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.
Typically, preauthentication using a secret key would not be included,
but if included it may be ignored by the KDC. (We recommend that it
not be included: even if the KDC should ignore the preauthentication,
an attacker may not, and use an intercepted message to guess the
password off-line.)
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 encrypted with the private key of the
KDC, then encrypted with the public key of the user.
PA-PK-AS-REP ::= SEQUENCE {
kdcCert[0] SEQUENCE OF Certificate,
encryptShell[1] EncryptedData, -- EncPaPkAsRepPartShell
-- encrypted by encReplyTmpKey
encryptKey[2] EncryptedData -- EncPaPkAsRepTmpKey
-- encrypted by userPubliKey
}
EncPaPkAsRepPartShell ::= SEQUENCE {
encReplyPart[0] EncPaPkAsRepPart,
encReplyPartSig[1] Signature -- encReplyPart
-- signed by kdcPrivateKey
}
EncPaPkAsRepPart ::= SEQUENCE {
encReplyKey[0] EncryptionKey,
nonce[1] INTEGER
}
EncPaPkAsRepTmpKey ::= SEQUENCE {
encReplyTmpKey[0] EncryptionKey
}
Notationally, assume that encryptPack is encrypted (or signed) with
algorithm Ak, and that encryptShell is encrypted with algorithm Au.
Then, encryptShell is
Au (Ak ({encReplyKey, nonce}, kdcPrivateKey), userPublicKey)
where kdcPrivateKey is the KDC's private key, and userPublicKey is the
user's public key.
The kdc-cert specification is lifted, with slight modifications,
from v3 of the X.509 certificate specification:
Certificate ::= SEQUENCE {
version[0] Version DEFAULT v1 (1),
serialNumber[1] CertificateSerialNumber,
signature[2] AlgorithmIdentifier,
issuer[3] PrincipalName,
validity[4] Validity,
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 certifiers
sent to the KDC with the original request. If the KDC has no such
certification, then it will instead reply with a KRB_ERROR of type
KDC_ERROR_PREAUTH_FAILED. If a zero-length root-cert was sent by the
client as part of the PA-PK-AS-ROOT, then a correspondingly zero-length
kdc-cert may be absent, in which case the client uses its copy of the
KDC's public key.
Upon receipt of the response from the KDC, the client will verify the
public key for the KDC from PA-PK-AS-REP preauthentication data field,
The certificate must certify the key as belonging to a principal whose
name can be derived from the realm name. If the certificate checks
out, the client then decrypts the EncPaPkAsRepPart using the private
key of the user, 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.)
3.2.2. Private key held by KDC
Implementation of the changes in this section is OPTIONAL.
When the user's private key is not carried with the user, the user may
encrypt the private key using conventional cryptography, and register
the encrypted private key with the KDC. The MD5 hash of the DES key
used to encrypt the private key must also be registered with the KDC.
We provide this option with the warning that storing the private key
on the KDC carries the risk of exposure in case the KDC is compromised.
If a suffiently good password is chosen to encrypt the key, then this
password can be used for a limited time to change the private key.
If the user wishes to authenticate himself without storing the private
key on each local disk, then a safer, albeit possibly less practical,
alternative is to use a smart card to store the keys.
When the user's private key is stored on the KDC, the KDC record
will also indicate whether preauthentication is required before
returning the key (we recommend that it be required). If such
preauthentication is required, when the initial request is received,
the KDC will respond with a KRB_ERROR message, with msg-type set
to KDC_ERR_PREAUTH_REQUIRED, and e-data set to:
PA-PK-AS-INFO ::= SEQUENCE {
kdcCert[0] SEQUENCE OF Certificate
}
The kdc-cert field is identical to that in the PA-PK-AS-REP
preauthentication data field returned with the KDC response, and must
be validated as belonging to the KDC in the same manner.
Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the
client will prompt the user for the password that was used to
encrypt the private key, derive the DES key from that password,
and calculate the MD5 hash H1 of the DES key. The client then sends
a request to the KDC, which includes a timestamp and a
client-generated random secret key that will be used by the KDC
to super-encrypt the encrypted private key before it is returned
to the client. This information is sent to the KDC in a subsequent
AS_REQ message in a preauthentication data field:
PA-PK-AS-REQ ::= SEQUENCE {
encHashShell[0] EncryptedData -- EncPaPkAsReqShell
}
EncPaPkAsReqShell ::= SEQUENCE {
encHashPart[0] EncryptedData -- EncPaPkAsReqPart
}
EncPaPkAsReqPart ::= SEQUENCE {
encHashKey[0] EncryptionKey,
nonce[1] INTEGER
}
The EncPaPkAsReqPart is first encrypted with a DES key K1, derived
by string_to_key from the hash H1 (with null salt), then encrypted
again with the KDC's public key from the certificate in the
PA-PK-AS-INFO field of the error response.
Notationally, if encryption algorithm A is used for DES encryption,
and Ak is used for the public key encryption, then enc-shell is
Ak (A ({encHashKey, nonce}, K1), kdcPublicKey)
Upon receipt of the authentication request with the PA-PK-AS-REQ, the
KDC verifies the hash of the user's DES encryption key by attempting
to decrypt the EncPaPkAsReqPart of the PA-PK-AS-REQ. If decryption
is successful, the KDC generates the AS response as defined in
RFC 1510, but additionally includes a preauthentication field of type
PA-PK-USER-KEY. (This response will also be included in response to
the initial request without preauthentication if preauthentication is
not required for the user and the user's encrypted private key is
stored on the KDC.)
PA-PK-USER-KEY ::= SEQUENCE {
encUserKeyPart[0] EncryptedData -- EncPaPkUserKeyPart
}
EncPaPkUserKeyPart ::= SEQUENCE {
encUserKey[0] OCTET STRING,
nonce[1] INTEGER
}
Notationally, if encryption algorithm A is used, then enc-key-part is
A ({encUserKey, nonce}, enc-hash-key)
(where A could be null encryption).
This message contains the encrypted private key that has been
registered with the KDC by the user, as encrypted by the user,
optionally super-encrypted with the enc-hash-key from the PA-PK-AS-REQ
message if preauthentication using that method was provided (otherwise,
the EncryptedData should denote null encryption). Note that since
H1 is a one-way hash, it is not possible for one to decrypt the
message if one possesses H1 but not the DES key that H1 is derived
from. Because there is direct trust between the user and the
KDC, the transited field of the ticket returned by the KDC should
remain empty. (Cf. Section 3.3.)
3.3. Clients with a public key certified by an outside authority
Implementation of the changes in this section is OPTIONAL.
In the case where the client is not registered with the current KDC,
the client is responsible for obtaining the private key on its own.
The client will request initial tickets from the KDC using the TGS
exchange, but instead of performing pre-authentication using a
Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used
when the public key is known to the KDC, the client performs
preauthentication using the preauthentication data field of type
PA-PK-AS-EXT-CERT:
PA-PK-AS-EXT-CERT ::= SEQUENCE {
userCert[0] SEQUENCE OF OCTET STRING,
signedAuth[1] SignedPKAuthenticator
}
where the user-cert specification depends on the type of certificate
that the user possesses. In cases where the service has separate
key pairs for digital signature and for encryption, we recommend
that the signature keys be used for the purposes of sending the
preauthentication (and deciphering the response).
The authenticator is the one used from the exchange in section 3.2.1,
except that it is signed using the private key corresponding to
the public key in the user-cert.
The KDC will verify the preauthentication authenticator, and check the
certification path against its own policy of legitimate certifiers.
This may be based on a certification hierarchy, or simply a list of
recognized certifiers in a system like PGP.
If all checks out, the KDC will issue Kerberos credentials, as in 3.2,
but with the names of all the certifiers in the certification path
added to the transited field of the ticket, with a principal name
taken from the certificate (this might be a long path for X.509, or a
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
as in PGP/<endorser@company.com>.
3.4. Digital Signature
Implementation of the changes in this section is OPTIONAL.
We offer this option with the warning that it requires the client
process to generate a random DES key; this generation may not
be able to guarantee the same level of randomness as the KDC.
If a user registered a digital signature key pair with the KDC,
a separate exchange may be used. The client sends a KRB_AS_REQ as
described in section 3.2.2. If the user's database record
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.
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 {
signedKey[0] EncryptedData -- PaPkAsSignedData
}
PaPkAsSignedData ::= SEQUENCE {
signedKeyPart[0] SignedKeyPart,
signedKeyAuth[1] PKAuthenticator
}
SignedKeyPart ::= SEQUENCE {
encSignedKey[0] EncryptionKey,
nonce[1] INTEGER
}
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.)
4. Preauthentication Data Types
We propose that the following preauthentication types be allocated
for the preauthentication data packages described in this draft:
#define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */
#define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */
#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
For the public key cryptography used in direct registration, we used
(in our implementation) the RSAREF library supplied with the PGP 2.6.2
release. Encryption and decryption functions were 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
We solicit discussion on how the use of public key cryptography for initial
authentication will interact with the proposed use of one time passwords
discussed in Internet Draft <draft-ietf-cat-kerberos-passwords-00.txt>.
7. Strength of Encryption and Signature Mechanisms
In light of recent findings on the strengths of MD5 and various DES
modes, we solicit discussion on which modes to incorporate into the
protocol changes.
8. Expiration
This Internet-Draft expires on December 7, 1996.
9. Authors' Addresses
B. Clifford Neuman
USC/Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey, CA 90292-6695
Phone: 310-822-1511
EMail: bcn@isi.edu
Brian Tung
USC/Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey, CA 90292-6695
Phone: 310-822-1511
EMail: brian@isi.edu
John Wray
Digital Equipment Corporation
550 King Street, LKG2-2/Z7
Littleton, MA 01460
Phone: 508-486-5210
EMail: wray@tuxedo.enet.dec.com

1120
doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt Normal file
View File

File diff suppressed because it is too large Load Diff

588
doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt Normal file
View File

@@ -0,0 +1,588 @@
INTERNET-DRAFT Clifford Neuman
draft-ietf-cat-kerberos-pk-init-03.txt Brian Tung
Updates: RFC 1510 ISI
expires September 30, 1997 John Wray
Digital Equipment Corporation
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
Jonathan Trostle
Novell
Public Key Cryptography for Initial Authentication in Kerberos
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
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check
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).
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-03.txt, and expires September 30,
1997. Please send comments to the authors.
1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
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.
2. Introduction
The popularity of public key cryptography has produced a desire for
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.
Public key cryptography can be integrated into Kerberos in a number
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.
One of the guiding principles in the design of PKINIT is that
changes should be as minimal as possible. As a result, the basic
mechanism of PKINIT is as follows: The user sends a request to the
KDC as before, except that if that user is to use public key
cryptography in the initial authentication step, his certificate
accompanies the initial request, in the preauthentication fields.
Upon receipt of this request, the KDC verifies the certificate and
issues a ticket granting ticket (TGT) as before, except that instead
of being encrypted in the user's long-term key (which is derived
from a password), it is encrypted in a randomly-generated key. This
random key is in turn encrypted using the public key certificate
that came with the request and signed using the KDC's signature key,
and accompanies the reply, in the preauthentication fields.
PKINIT also allows for users with only digital signature keys to
authenticate using those keys, and for users to store and retrieve
private keys on the KDC.
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]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following changes to RFC 1510 are proposed:
--> Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity.
--> Users may store private keys on the KDC for retrieval during
Kerberos initial authentication.
This proposal addresses two ways that users may use public key
cryptography for initial authentication. Users may present public
key certificates, or they may generate their own session key,
signed by their digital signature key. In either case, the end
result is that the user obtains an ordinary TGT that may be used for
subsequent authentication, with such authentication using only
conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 and 3.3 describe the extensions for the two initial
authentication methods. Section 3.3 describes a way for the user to
store and retrieve his private key on the KDC.
3.1. Definitions
Hash and encryption types will be specified using ENCTYPE tags; we
propose the addition of the following types:
#define ENCTYPE_SIGN_DSA_GENERATE 0x0011
#define ENCTYPE_SIGN_DSA_VERIFY 0x0012
#define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021
#define ENCTYPE_ENCRYPT_RSA_PUB 0x0022
allowing further signature types to be defined in the range 0x0011
through 0x001f, and further encryption types to be defined in the
range 0x0021 through 0x002f.
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.
#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
The extensions also involve new error types. The new error types
are in the range 227 through 229. They are:
#define KDC_ERROR_CLIENT_NOT_TRUSTED 227
#define KDC_ERROR_KDC_NOT_TRUSTED 228
#define KDC_ERROR_INVALID_SIG 229
In the exposition below, we use the following terms: encryption key,
decryption key, signature key, verification key. It should be
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.
3.2. Standard Public Key Authentication
Implementation of the changes in this section is REQUIRED for
compliance with pk-init.
It is assumed that all public keys are signed by some certification
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:
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
}
SignedPKAuthenticator ::= SEQUENCE {
pkAuth [0] PKAuthenticator,
pkAuthSig [1] Signature,
-- of pkAuth
-- using user's signature key
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER,
-- for replay prevention
ctime [1] KerberosTime,
-- for replay prevention
nonce [2] INTEGER,
-- binds response to this request
kdcName [3] PrincipalName,
clientPubValue [4] SubjectPublicKeyInfo OPTIONAL,
-- for Diffie-Hellman algorithm
}
Signature ::= SEQUENCE {
signedHash [0] EncryptedData
-- of type Checksum
-- encrypted under signature key
}
Checksum ::= SEQUENCE {
cksumtype [0] INTEGER,
checksum [1] OCTET STRING
} -- as specified by RFC 1510
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm [0] algorithmIdentifier,
subjectPublicKey [1] BIT STRING
} -- as specified by the X.509 recommendation [9]
Certificate ::= SEQUENCE {
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
}
Note: If the signature uses RSA keys, then it is to be performed
as per PKCS #1.
The PKAuthenticator carries information to foil replay attacks,
to bind the request and response, and to optionally pass the
client's Diffie-Hellman public value (i.e. for using DSA in
combination with Diffie-Hellman). The PKAuthenticator is signed
with the private key corresponding to the public key in the
certificate found in userCert (or cached by the KDC).
In the PKAuthenticator, the client may specify the KDC name in one
of two ways: 1) a Kerberos principal name, or 2) the name in the
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).
The userCert field is a sequence of certificates, the first of which
must be the user's public key certificate. Any subsequent
certificates will be certificates of the certifiers of the user's
certificate. These cerificates may be used by the KDC to verify the
user's public key. This field is empty if the KDC already has the
user's certifcate.
The trustedCertifiers field contains a list of certification
authorities trusted by the client, in the case that the client does
not possess the KDC's public key certificate.
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type, the KDC attempts to verify the user's certificate chain
(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.
If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
verifies that it has a certificate issued by one of the certifiers
trusted by the client. If it does not have a suitable certificate,
the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
to the client.
If a trust relationship exists, the KDC then verifies the client's
signature on PKAuthenticator. If that fails, the KDC returns an
error message of type KDC_ERROR_INVALID_SIG. Otherwise, the KDC
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.
Assuming no errors, the KDC replies as per RFC 1510, except that it
encrypts the reply not with the user's key, but with a random key
generated only for this particular response. This random key
is sealed in the preauthentication field:
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
}
PaReply ::= SEQUENCE {
replyEncKeyPack [0] ReplyEncKeyPack,
replyEncKeyPackSig [1] Signature,
-- of replyEncKeyPack
-- using KDC's signature key
}
ReplyEncKeyPack ::= SEQUENCE {
replyEncKey [0] EncryptionKey,
-- used to encrypt main reply
nonce [1] INTEGER
-- binds response to the request
-- passed in the PKAuthenticator
}
SignedDHPublicValue ::= SEQUENCE {
dhPublicValue [0] SubjectPublicKeyInfo,
dhPublicValueSig [1] Signature
-- of dhPublicValue
-- using KDC's signature key
}
The kdcCert field is a sequence of certificates, the first of which
must have as its root certifier one of the certifiers sent to the
KDC in the PA-PK-AS-REQ. Any subsequent certificates will be
certificates of the certifiers of the KDC's certificate. These
cerificates may be used by the client to verify the KDC's public
key. This field is empty if the client did not send to the KDC a
list of trusted certifiers (the trustedCertifiers field was empty).
Since each certifier in the certification path of a user's
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.
The KDC's certificate must bind the public key to a name derivable
from the name of the realm for that KDC. The client then extracts
the random key used to encrypt the main reply. This random key (in
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.
3.3. Digital Signature
Implementation of the changes in this section are OPTIONAL for
compliance with pk-init.
We offer this option with the warning that it requires the client to
generate a random key; the client may not be able to guarantee the
same level of randomness as the KDC.
If the user registered a digital signature key with the KDC instead
of an encryption key, then a separate exchange must be used. The
client sends a request for a TGT as usual, except that it (rather
than the KDC) generates the random key that will be used to encrypt
the KDC response. This key is sent to the KDC along with the
request in a preauthentication field:
PA-PK-AS-SIGN ::= SEQUENCE {
-- PA TYPE 19
encSignedKeyPack [0] EncryptedData
-- of SignedKeyPack
-- using the KDC's public key
}
SignedKeyPack ::= SEQUENCE {
signedKey [0] KeyPack,
signedKeyAuth [1] PKAuthenticator,
signedKeySig [2] Signature
-- of signedKey.signedKeyAuth
-- using user's signature key
}
KeyPack ::= SEQUENCE {
randomKey [0] EncryptionKey,
-- will be used to encrypt reply
nonce [1] INTEGER
}
where the nonce is copied from the request.
Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
the randomKey. It then replies as per RFC 1510, except that the
reply is encrypted not with a password-derived user key, but with
the randomKey sent in the request. Since the client already knows
this key, there is no need to accompany the reply with an extra
preauthentication field. The transited field of the ticket should
specify the certification path as described in Section 3.2.
3.4. Retrieving the Private Key From the KDC
Implementation of the changes in this section is RECOMMENDED for
compliance with pk-init.
When the user's private key is not stored local to the user, he may
choose to store the private key (normally encrypted using a
password-derived key) on the KDC. We provide this option to present
the user with an alternative to storing the private key on local
disk at each machine where he expects to authenticate himself using
pk-init. It should be noted that it replaces the added risk of
long-term storage of the private key on possibly many workstations
with the added risk of storing the private key on the KDC in a
form vulnerable to brute-force attack.
In order to obtain a private key, the client includes a
preauthentication field with the AS-REQ message:
PA-PK-KEY-REQ ::= SEQUENCE {
-- PA TYPE 20
patimestamp [0] KerberosTime OPTIONAL,
-- used to address replay attacks.
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
}
KeyID ::= SEQUENCE {
KeyIdentifier [0] OCTET STRING
}
The client may request a specific private key by sending the
corresponding ID. If this field is left empty, then all
private keys are returned.
If all checks out, the KDC responds as described in the above
sections, except that an additional preauthentication field,
containing the user's private key, accompanies the reply:
PA-PK-KEY-REP ::= SEQUENCE {
-- PA TYPE 21
nonce [0] INTEGER,
-- binds the reply to the request
KeyData [1] SEQUENCE OF KeyPair
}
KeyPair ::= SEQUENCE {
privKeyID [0] OCTET STRING,
-- corresponding to encPrivKey
encPrivKey [1] OCTET STRING
}
3.4.1. Additional Protection of Retrieved Private Keys
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.)
In order to make this work, additional means of preauthentication
need to be devised in order to prevent attackers from simply
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.
Since the KDC possesses the hash, it can generate the hash-key and
verify this (weaker) preauthentication, and yet cannot reproduce
the private key itself, since the hash is a one-way function.
4. Logistics and Policy Issues
We solicit discussion on how clients and KDCs should be configured
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.
5. Compatibility with One-Time Passcodes
We solicit discussion on how the protocol changes proposed in this
draft will interact with the proposed use of one-time passcodes
discussed in draft-ietf-cat-kerberos-passwords-00.txt.
6. Strength of Cryptographic Schemes
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.
7. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5). Request for Comments: 1510
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38.
September 1994.
[3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
Transport Layer Security (TLS).
draft-ietf-tls-kerb-cipher-suites-00.txt
[4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt
[5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using
Public Key Cryptography. Symposium On Network and Distributed System
Security, 1997.
[6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce,
July 1995.
[7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
The SSL Protocol, Version 3.0 - IETF Draft.
[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
[9] ITU-T (formerly CCITT)
Information technology - Open Systems Interconnection -
The Directory: Authentication Framework Recommendation X.509
ISO/IEC 9594-8
8. Acknowledgements
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 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.
9. Expiration Date
This draft expires September 30, 1997.
10. Authors
Clifford Neuman
Brian Tung
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {bcn, brian}@isi.edu
John Wray
Digital Equipment Corporation
550 King Street, LKG2-2/Z7
Littleton, MA 01460
Phone: +1 508 486 5210
E-mail: wray@tuxedo.enet.dec.com
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road Suite 310
Issaquah WA 98027-5378
Phone: +1 206 391 6000
E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
Jonathan Trostle
Novell
E-mail: jonathan.trostle@novell.com

868
doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt Normal file
View File

@@ -0,0 +1,868 @@
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-04.txt Clifford Neuman
Updates: RFC 1510 ISI
expires January 31, 1998 John Wray
Digital Equipment Corporation
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
Jonathan Trostle
Novell
Public Key Cryptography for Initial Authentication in Kerberos
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
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check
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).
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-04.txt, and expires January 31,
1998. Please send comments to the authors.
1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
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.
2. Introduction
The popularity of public key cryptography has produced a desire for
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.
Public key cryptography can be integrated into Kerberos in a number
of ways. One is to associate a key pair with each realm, which can
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.
One of the guiding principles in the design of PKINIT is that
changes should be as minimal as possible. As a result, the basic
mechanism of PKINIT is as follows: The user sends a request to the
KDC as before, except that if that user is to use public key
cryptography in the initial authentication step, his certificate
accompanies the initial request, in the preauthentication fields.
Upon receipt of this request, the KDC verifies the certificate and
issues a ticket granting ticket (TGT) as before, except that instead
of being encrypted in the user's long-term key (which is derived
from a password), it is encrypted in a randomly-generated key. This
random key is in turn encrypted using the public key from the
certificate that came with the request and signed using the KDC's
private key, and accompanies the reply, in the preauthentication
fields.
PKINIT also allows for users with only digital signature keys to
authenticate using those keys, and for users to store and retrieve
private keys on the KDC.
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]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following changes to RFC 1510 are proposed:
--> Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity.
--> Users may store private keys on the KDC for retrieval during
Kerberos initial authentication.
This proposal addresses two ways that users may use public key
cryptography for initial authentication. Users may present public
key certificates, or they may generate their own session key,
signed by their digital signature key. In either case, the end
result is that the user obtains an ordinary TGT that may be used for
subsequent authentication, with such authentication using only
conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 and 3.3 describe the extensions for the two initial
authentication methods. Section 3.4 describes a way for the user to
store and retrieve his private key on the KDC, as an adjunct to the
initial authentication.
3.1. Definitions
The extensions involve new encryption methods; we propose the
addition of the following types:
dsa-sign 8
rsa-priv 9
rsa-pub 10
rsa-pub-md5 11
rsa-pub-sha1 12
The proposal of these encryption types notwithstanding, we do not
mandate the use of any particular public key encryption method.
The extensions involve new preauthentication fields; we propose the
addition of the following types:
PA-PK-AS-REQ 14
PA-PK-AS-REP 15
PA-PK-AS-SIGN 16
PA-PK-KEY-REQ 17
PA-PK-KEY-REP 18
The extensions also involve new error types; we propose the addition
of the following types:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_TOO_WEAK 65
In many cases, PKINIT requires the encoding of an X.500 name as a
Realm. In these cases, the realm will be represented using a
different style, specified in RFC 1510 with the following example:
NAMETYPE:rest/of.name=without-restrictions
For a realm derived from an X.500 name, NAMETYPE will have the value
X500-ASN1-BASE64. The full realm name will appear as follows:
X500-ASN1-BASE64:Base64Encode(DistinguishedName)
where Base64 is an ASCII encoding of binary data as per RFC 1521,
and DistinguishedName is the ASN.1 encoding of the X.500
Distinguished Name from the X.509 certificate.
Similarly, PKINIT may require the encoding of an X.500 name as a
PrincipalName. In these cases, the name-type of the principal name
shall be set to NT-X500-PRINCIPAL, and the name-string shall be set
as follows:
Base64Encode(DistinguishedName)
as described above.
[Similar description needed on how realm names and principal names
are to be derived from PGP names.]
3.1.1. Encryption and Key Formats
In the exposition below, we use the terms public key and private
key generically. It should be understood that the term "public
key" may be used to refer to either a public encryption key or a
signature verification key, and that the term "private key" may be
used to refer to either a private decryption key or a signature
generation key. The fact that these are logically distinct does
not preclude the assignment of bitwise identical keys.
All additional symmetric keys specified in this draft shall use the
same encryption type as the session key in the response from the
KDC. These include the temporary keys used to encrypt the signed
random key encrypting the response, as well as the key derived from
Diffie-Hellman agreement. In the case of Diffie-Hellman, the key
shall be produced from the agreed bit string as follows:
* Truncate the bit string to the appropriate length.
* Rectify parity in each byte (if necessary) to obtain the key.
For instance, in the case of a DES key, we take the first eight
bytes of the bit stream, and then adjust the least significant bit
of each byte to ensure that each byte has odd parity.
RFC 1510, Section 6.1, defines EncryptedData as follows:
EncryptedData ::= SEQUENCE {
etype [0] INTEGER,
kvno [1] INTEGER OPTIONAL,
cipher [2] OCTET STRING
-- is CipherText
}
RFC 1510 suggests that ciphertext is coded as follows:
CipherText ::= ENCRYPTED SEQUENCE {
confounder [0] UNTAGGED OCTET STRING(conf_length)
OPTIONAL,
check [1] UNTAGGED OCTET STRING(checksum_length)
OPTIONAL,
msg-seq [2] MsgSequence,
pad [3] UNTAGGED OCTET STRING(pad_length)
OPTIONAL
}
The PKINIT protocol introduces several new types of encryption.
Data that is encrypted with a public key will allow only the check
optional field, as it is defined above. This type of the checksum
will be specified in the etype field, together with the encryption
type.
In order to identify the checksum type, etype will have the
following values:
rsa-pub-MD5
rsa-pub-SHA1
In the case that etype is set to rsa-pub, the optional 'check'
field will not be provided.
Data that is encrypted with a private key will not use any optional
fields. PKINIT uses private key encryption only for signatures,
which are encrypted checksums. Therefore, the optional check field
is not needed.
3.2. Standard Public Key Authentication
Implementation of the changes in this section is REQUIRED for
compliance with PKINIT.
It is assumed that all public keys are signed by some certification
authority (CA). The initial authentication request is sent as per
RFC 1510, except that a preauthentication field containing data
signed by the user's private key accompanies the request:
PA-PK-AS-REQ ::= SEQUENCE {
-- PA TYPE 14
signedAuthPack [0] SignedAuthPack
userCert [1] SEQUENCE OF Certificate OPTIONAL,
-- the user's certificate chain
trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL
-- CAs that the client trusts
}
SignedAuthPack ::= SEQUENCE {
authPack [0] AuthPack,
authPackSig [1] Signature,
-- of authPack
-- using user's private key
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- if client is using Diffie-Hellman
}
PKAuthenticator ::= SEQUENCE {
kdcName [0] PrincipalName,
kdcRealm [1] Realm,
cusec [2] INTEGER,
-- for replay prevention
ctime [3] KerberosTime,
-- for replay prevention
nonce [4] INTEGER
}
Signature ::= SEQUENCE {
signedHash [0] EncryptedData
-- of type Checksum
}
Checksum ::= SEQUENCE {
cksumtype [0] INTEGER,
checksum [1] OCTET STRING
} -- as specified by RFC 1510
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm [0] AlgorithmIdentifier,
subjectPublicKey [1] BIT STRING
-- for DH, equals
-- public exponent (INTEGER encoded
-- as payload of BIT STRING)
} -- as specified by the X.509 recommendation [9]
AlgorithmIdentifier ::= SEQUENCE {
algorithm [0] ALGORITHM.&id,
-- for DH, equals
-- dhKeyAgreement
-- ({iso(1) member-body(2) US(840)
-- rsadsi(113549) pkcs(1) pkcs-3(3)
-- 1})
parameters [1] ALGORITHM.&type
-- for DH, is DHParameter
} -- as specified by the X.509 recommendation [9]
DHParameter ::= SEQUENCE {
prime [0] INTEGER,
-- p
base [1] INTEGER,
-- g
privateValueLength [2] INTEGER OPTIONAL
}
Certificate ::= SEQUENCE {
certType [0] INTEGER,
-- type of certificate
-- 1 = X.509v3 (DER encoding)
-- 2 = PGP (per PGP specification)
certData [1] OCTET STRING
-- actual certificate
-- type determined by certType
}
The PKAuthenticator carries information to foil replay attacks,
to bind the request and response, and to optionally pass the
client's Diffie-Hellman public value (i.e. for using DSA in
combination with Diffie-Hellman). The PKAuthenticator is signed
with the private key corresponding to the public key in the
certificate found in userCert (or cached by the KDC).
In the PKAuthenticator, the client may specify the KDC name in one
of two ways:
* The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
where <realm_name> is replaced by the applicable realm name.
* The name in the KDC's certificate (e.g., an X.500 name, or a
PGP name).
Note that the first case requires that the certificate name and the
Kerberos principal name be bound together (e.g., via an X.509v3
extension).
The userCert field is a sequence of certificates, the first of which
must be the user's public key certificate. Any subsequent
certificates will be certificates of the certifiers of the user's
certificate. These cerificates may be used by the KDC to verify the
user's public key. This field may be left empty if the KDC already
has the user's certificate.
The trustedCertifiers field contains a list of certification
authorities trusted by the client, in the case that the client does
not possess the KDC's public key certificate.
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type, the KDC attempts to verify the user's certificate chain
(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 verification of the user's certificate fails, the KDC sends back
an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data
field contains additional information pertaining to this error, and
is formatted as follows:
METHOD-DATA ::= SEQUENCE {
method-type [0] INTEGER,
-- 1 = cannot verify public key
-- 2 = invalid certificate
-- 3 = revoked certificate
-- 4 = invalid KDC name
method-data [1] OCTET STRING OPTIONAL
} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
The values for the method-type and method-data fields are described
in Section 3.2.1.
If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
verifies that it has a certificate issued by one of the certifiers
trusted by the client. If it does not have a suitable certificate,
the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
the client.
If a trust relationship exists, the KDC then verifies the client's
signature on PKAuthenticator. If that fails, the KDC returns an
error message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC 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
the PKAuthenticator.
If the clientPublicValue field is filled in, indicating that the
client wishes to use Diffie-Hellman key agreement, then the KDC
checks to see that the parameters satisfy its policy. If they do
not (e.g., the prime size is insufficient for the expected
encryption type), then the KDC sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
private values for the response.
The KDC also checks that the timestamp in the PKAuthenticator is
within the allowable window. If the local (server) time and the
client time in the authenticator differ by more than the allowable
clock skew, then the KDC returns an error message of type
KRB_AP_ERR_SKEW.
Assuming no errors, the KDC replies as per RFC 1510, except as
follows: The user's name in the ticket is as represented in the
certificate, unless a Kerberos principal name is bound to the name
in the certificate (e.g., via an X.509v3 extension). The user's
realm in the ticket shall be the name of the Certification
Authority that issued the user's public key certificate.
The KDC encrypts the reply not with the user's long-term key, but
with a random key generated only for this particular response. This
random key is sealed in the preauthentication field:
PA-PK-AS-REP ::= SEQUENCE {
-- PA TYPE 15
encSignedReplyKeyPack [0] EncryptedData,
-- of type SignedReplyKeyPack
-- using the temporary key
-- in encTmpKey
encTmpKeyPack [1] EncryptedData,
-- of type TmpKeyPack
-- using either the client public
-- key or the Diffie-Hellman key
-- specified by SignedDHPublicValue
signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL
-- if one was passed in the request
kdcCert [3] SEQUENCE OF Certificate OPTIONAL,
-- the KDC's certificate chain
}
SignedReplyKeyPack ::= SEQUENCE {
replyKeyPack [0] ReplyKeyPack,
replyKeyPackSig [1] Signature,
-- of replyEncKeyPack
-- using KDC's private key
}
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- used to encrypt main reply
nonce [1] INTEGER
-- binds response to the request
-- must be same as the nonce
-- passed in the PKAuthenticator
}
TmpKeyPack ::= SEQUENCE {
tmpKey [0] EncryptionKey,
-- used to encrypt the
-- SignedReplyKeyPack
}
SignedKDCPublicValue ::= SEQUENCE {
kdcPublicValue [0] SubjectPublicKeyInfo,
-- as described above
kdcPublicValueSig [1] Signature
-- of kdcPublicValue
-- using KDC's private key
}
The kdcCert field is a sequence of certificates, the first of which
must be the KDC's public key certificate. Any subsequent
certificates will be certificates of the certifiers of the KDC's
certificate. The last of these must have as its certifier one of
the certifiers sent to the KDC in the PA-PK-AS-REQ. These
cerificates may be used by the client to verify the KDC's public
key. This field is empty if the client did not send to the KDC a
list of trusted certifiers (the trustedCertifiers field was empty).
Since each certifier in the certification path of a user's
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 is defined in Section 3.1 of this
document. If applicable, the transit-policy-checked flag should be
set in the issued ticket.
The KDC's certificate must bind the public key to a name derivable
from the name of the realm for that KDC. For an X.509 certificate,
this is done as follows. The certificate will contain a
distinguished X.500 name contains, in addition to other attributes,
an extended attribute, called principalName, with the KDC's
principal name as its value (as the text string
krbtgt/<realm_name>@<realm_name>, where <realm_name> is the realm
name of the KDC):
principalName ATTRIBUTE ::= {
WITH SYNTAX PrintableString(SIZE(1..ub-prinicipalName))
EQUALITY MATCHING RULE caseExactMatch
ORDERING MATCHING RULE caseExactOrderingMatch
SINGLE VALUE TRUE
ID id-at-principalName
}
ub-principalName INTEGER ::= 1024
id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}
id-at-principalName OBJECT IDENTIFIER ::= {id-at 60}
where ATTRIBUTE is as defined in X.501, and the matching rules are
as defined in X.520.
[Still need to register principalName.]
[Still need to discuss what is done for a PGP certificate.]
The client then extracts the random key used to encrypt the main
reply. This random key (in 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.
3.2.1. Additional Information for Errors
This section describes the interpretation of the method-type and
method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
If method-type=1, the client's public key certificate chain does not
contain a certificate that is signed by a certification authority
trusted by the KDC. The format of the method-data field will be an
ASN.1 encoding of a list of trusted certifiers, as defined above:
TrustedCertifiers ::= SEQUENCE OF PrincipalName
If method-type=2, the signature on one of the certificates in the
chain cannot be verified. The format of the method-data field will
be an ASN.1 encoding of the integer index of the certificate in
question:
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- 1 = 2nd certificate, etc
If method-type=3, one of the certificates in the chain has been
revoked. The format of the method-data field will be an ASN.1
encoding of the integer index of the certificate in question:
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- 1 = 2nd certificate, etc
If method-type=4, the KDC name or realm in the PKAuthenticator does
not match the principal name of the KDC. There is no method-data
field in this case.
3.3. Digital Signature
Implementation of the changes in this section are OPTIONAL for
compliance with PKINIT.
We offer this option with the warning that it requires the client to
generate a random key; the client may not be able to guarantee the
same level of randomness as the KDC.
If the user registered, or presents a certificate for, a digital
signature key with the KDC instead of an encryption key, then a
separate exchange must be used. The client sends a request for a
TGT as usual, except that it (rather than the KDC) generates the
random key that will be used to encrypt the KDC response. This key
is sent to the KDC along with the request in a preauthentication
field, encrypted with the KDC's public key:
PA-PK-AS-SIGN ::= SEQUENCE {
-- PA TYPE 16
encSignedRandomKeyPack [0] EncryptedData,
-- of type SignedRandomKeyPack
-- using the key in encTmpKeyPack
encTmpKeyPack [1] EncryptedData,
-- of type TmpKeyPack
-- using the KDC's public key
userCert [2] SEQUENCE OF Certificate OPTIONAL
-- the user's certificate chain
}
SignedRandomKeyPack ::= SEQUENCE {
randomkeyPack [0] RandomKeyPack,
randomkeyPackSig [1] Signature
-- of keyPack
-- using user's private key
}
RandomKeyPack ::= SEQUENCE {
randomKey [0] EncryptionKey,
-- will be used to encrypt reply
randomKeyAuth [1] PKAuthenticator
-- nonce copied from AS-REQ
}
If the KDC does not accept client-generated random keys as a matter
of policy, then it sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as
follows.
Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
the randomKey. It then replies as per RFC 1510, except that the
reply is encrypted not with a password-derived user key, but with
the randomKey sent in the request. Since the client already knows
this key, there is no need to accompany the reply with an extra
preauthentication field. The transited field of the ticket should
specify the certification path as described in Section 3.2.
3.4. Retrieving the User's Private Key from the KDC
Implementation of the changes described in this section are OPTIONAL
for compliance with PKINIT.
When the user's private key is not stored local to the user, he may
choose to store the private key (normally encrypted using a
password-derived key) on the KDC. In this case, the client makes a
request as described above, except that instead of preauthenticating
with his private key, he uses a symmetric key shared with the KDC.
For simplicity's sake, this shared key is derived from the password-
derived key used to encrypt the private key, in such a way that the
KDC can authenticate the user with the shared key without being able
to extract the private key.
We provide this option to present the user with an alternative to
storing the private key on local disk at each machine where he
expects to authenticate himself using PKINIT. It should be noted
that it replaces the added risk of long-term storage of the private
key on possibly many workstations with the added risk of storing the
private key on the KDC in a form vulnerable to brute-force attack.
Denote by K1 the symmetric key used to encrypt the private key.
Then construct symmetric key K2 as follows:
* Perform a hash on K1.
* Truncate the digest to Length(K1) bytes.
* Rectify parity in each byte (if necessary) to obtain K2.
The KDC stores K2, the public key, and the encrypted private key.
This key pair is designated as the "primary" key pair for that user.
This primary key pair is the one used to perform initial
authentication using the PA-PK-AS-REP preauthentication field. If
he desires, he may also store additional key pairs on the KDC; these
may be requested in addition to the primary. When the client
requests initial authentication using public key cryptography, it
must then include in its request, instead of a PA-PK-AS-REQ, the
following preauthentication sequence:
PA-PK-KEY-REQ ::= SEQUENCE {
-- PA TYPE 17
signedPKAuth [0] SignedPKAuth,
trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
-- CAs that the client trusts
keyIDList [2] SEQUENCE OF Checksum OPTIONAL
-- payload is hash of public key
-- corresponding to desired
-- private key
-- if absent, KDC will return all
-- stored private keys
}
SignedPKAuth ::= SEQUENCE {
pkAuth [0] PKAuthenticator,
pkAuthSig [1] Signature
-- of pkAuth
-- using the symmetric key K2
}
If a keyIDList is present, the first identifier should indicate
the primary private key. No public key certificate is required,
since the KDC stores the public key along with the private key.
If there is no keyIDList, all the user's private keys are returned.
Upon receipt, the KDC verifies the signature using K2. If the
verification fails, the KDC sends back an error of type
KDC_ERR_INVALID_SIG. If the signature verifies, but the requested
keys are not found on the KDC, then the KDC sends back an error of
type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as
described in Section 3.2, except that in addition, the KDC appends
the following preauthentication sequence:
PA-PK-KEY-REP ::= SEQUENCE {
-- PA TYPE 18
encKeyRep [0] EncryptedData
-- of type EncKeyReply
-- using the symmetric key K2
}
EncKeyReply ::= SEQUENCE {
keyPackList [0] SEQUENCE OF KeyPack,
-- the first KeyPair is
-- the primary key pair
nonce [1] INTEGER
-- binds reply to request
-- must be identical to the nonce
-- sent in the SignedAuthPack
}
KeyPack ::= SEQUENCE {
keyID [0] Checksum,
encPrivKey [1] OCTET STRING
}
Upon receipt of the reply, the client extracts the encrypted private
keys (and may store them, at the client's option). The primary
private key, which must be the first private key in the keyPack
SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
this key in turn is used to decrypt the main reply as described in
Section 3.2.
4. Logistics and Policy
This section describes a way to define the policy on the use of
PKINIT for each principal and request.
The KDC is not required to contain a database record for users
that use either the Standard Public Key Authentication or Public Key
Authentication with a Digital Signature. However, if these users
are registered with the KDC, it is recommended that the database
record for these users be modified to include three additional flags
in the attributes field.
The first flag, use_standard_pk_init, indicates that the user should
authenticate using standard PKINIT as described in Section 3.2. The
second flag, use_digital_signature, indicates that the user should
authenticate using digital signature PKINIT as described in Section
3.3. The third flag, store_private_key, indicates that the user
has stored his private key on the KDC and should retrieve it using
the exchange described in Section 3.4.
If one of the preauthentication fields defined above is included in
the request, then the KDC shall respond as described in Sections 3.2
through 3.4, ignoring the aforementioned database flags. If more
than one of the preauthentication fields is present, the KDC shall
respond with an error of type KDC_ERR_PREAUTH_FAILED.
In the event that none of the preauthentication fields defined above
are included in the request, the KDC checks to see if any of the
above flags are set. If the first flag is set, then it sends back
an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
preauthentication field of type PA-PK-AS-REQ must be included in the
request.
Otherwise, if the first flag is clear, but the second flag is set,
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
indicating that a preauthentication field of type PA-PK-AS-SIGN must
be included in the request.
Lastly, if the first two flags are clear, but the third flag is set,
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
indicating that a preauthentication field of type PA-PK-KEY-REQ must
be included in the request.
5. Dependence on Transport Mechanisms
Certificate chains can potentially grow quite large and span several
UDP packets; this in turn increases the probability that a Kerberos
message involving PKINIT extensions will be broken in transit. In
light of the possibility that the Kerberos specification will
allow TCP as a transport mechanism, we solicit discussion on whether
using PKINIT should encourage the use of TCP.
6. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
Transport Layer Security (TLS).
draft-ietf-tls-kerb-cipher-suites-00.txt
[4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt
[5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed
System Security, 1997.
[6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic
Commerce, July 1995.
[7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL
Protocol, Version 3.0 - IETF Draft.
[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.
[9] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
7. Acknowledgements
Sasha Medvinsky contributed several ideas to the protocol changes
and specifications in this document. His additions have been most
appreciated.
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 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.
8. Expiration Date
This draft expires January 31, 1997.
9. Authors
Brian Tung
Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {brian, bcn}@isi.edu
John Wray
Digital Equipment Corporation
550 King Street, LKG2-2/Z7
Littleton, MA 01460
Phone: +1 508 486 5210
E-mail: wray@tuxedo.enet.dec.com
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road Suite 310
Issaquah WA 98027-5378
Phone: +1 206 391 6000
E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
Jonathan Trostle
Novell Corporation
Provo UT
E-mail: jtrostle@novell.com

916
doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt Normal file
View File

@@ -0,0 +1,916 @@
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-05.txt Clifford Neuman
Updates: RFC 1510 ISI
expires May 26, 1998 John Wray
Digital Equipment Corporation
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
Jonathan Trostle
Novell
Public Key Cryptography for Initial Authentication in Kerberos
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
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check
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).
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-05.txt, and expires May 26, 1998.
Please send comments to the authors.
1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
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.
2. Introduction
The popularity of public key cryptography has produced a desire for
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.
Public key cryptography can be integrated into Kerberos in a number
of ways. One is to associate a key pair with each realm, which can
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.
One of the guiding principles in the design of PKINIT is that
changes should be as minimal as possible. As a result, the basic
mechanism of PKINIT is as follows: The user sends a request to the
KDC as before, except that if that user is to use public key
cryptography in the initial authentication step, his certificate
accompanies the initial request, in the preauthentication fields.
Upon receipt of this request, the KDC verifies the certificate and
issues a ticket granting ticket (TGT) as before, except that
the encPart from the AS-REP message carrying the TGT is now
encrypted in a randomly-generated key, instead of the user's
long-term key (which is derived from a password). This
random key is in turn encrypted using the public key from the
certificate that came with the request and signed using the KDC's
private key, and accompanies the reply, in the preauthentication
fields.
PKINIT also allows for users with only digital signature keys to
authenticate using those keys, and for users to store and retrieve
private keys on the KDC.
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]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following changes to RFC 1510 are proposed:
* Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity.
* Users may store private keys on the KDC for retrieval during
Kerberos initial authentication.
This proposal addresses two ways that users may use public key
cryptography for initial authentication. Users may present public
key certificates, or they may generate their own session key,
signed by their digital signature key. In either case, the end
result is that the user obtains an ordinary TGT that may be used for
subsequent authentication, with such authentication using only
conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 and 3.3 describe the extensions for the two initial
authentication methods. Section 3.4 describes a way for the user to
store and retrieve his private key on the KDC, as an adjunct to the
initial authentication.
3.1. Definitions
The extensions involve new encryption methods; we propose the
addition of the following types:
dsa-sign 8
rsa-priv 9
rsa-pub 10
rsa-pub-md5 11
rsa-pub-sha1 12
The proposal of these encryption types notwithstanding, we do not
mandate the use of any particular public key encryption method.
The extensions involve new preauthentication fields; we propose the
addition of the following types:
PA-PK-AS-REQ 14
PA-PK-AS-REP 15
PA-PK-AS-SIGN 16
PA-PK-KEY-REQ 17
PA-PK-KEY-REP 18
The extensions also involve new error types; we propose the addition
of the following types:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_TOO_WEAK 65
KDC_ERR_CERTIFICATE_MISMATCH 66
In many cases, PKINIT requires the encoding of an X.500 name as a
Realm. In these cases, the realm will be represented using a
different style, specified in RFC 1510 with the following example:
NAMETYPE:rest/of.name=without-restrictions
For a realm derived from an X.500 name, NAMETYPE will have the value
X500-RFC1779. The full realm name will appear as follows:
X500-RFC1779:RFC1779Encode(DistinguishedName)
where DistinguishedName is an X.500 name, and RFC1779Encode is a
readable ASCII encoding of an X.500 name, as defined by RFC 1779.
To ensure that this encoding is unique, we add the following rules
to those specified by RFC 1779:
* The optional spaces specified in RFC 1779 are not allowed.
* The character that separates relative distinguished names
must be ',' (i.e., it must never be ';').
* Attribute values must not be enclosed in double quotes.
* Attribute values must not be specified as hexadecimal
numbers.
* When an attribute name is specified in the form of an OID,
it must start with the 'OID.' prefix, and not the 'oid.'
prefix.
* The order in which the attributes appear in the RFC 1779
encoding must be the reverse of the order in the ASN.1
encoding of the X.500 name that appears in the public key
certificate, because RFC 1779 requires that the least
significant relative distinguished name appear first. The
order of the relative distinguished names, as well as the
order of the attributes within each relative distinguished
name, will be reversed.
Similarly, PKINIT may require the encoding of an X.500 name as a
PrincipalName. In these cases, the name-type of the principal name
shall be set to NT-X500-PRINCIPAL. This new name type is defined
as:
#define CSFC5c_NT_X500_PRINCIPAL 6
The name-string shall be set as follows:
RFC1779Encode(DistinguishedName)
as described above.
3.1.1. Encryption and Key Formats
In the exposition below, we use the terms public key and private
key generically. It should be understood that the term "public
key" may be used to refer to either a public encryption key or a
signature verification key, and that the term "private key" may be
used to refer to either a private decryption key or a signature
generation key. The fact that these are logically distinct does
not preclude the assignment of bitwise identical keys.
All additional symmetric keys specified in this draft shall use the
same encryption type as the session key in the response from the
KDC. These include the temporary keys used to encrypt the signed
random key encrypting the response, as well as the key derived from
Diffie-Hellman agreement. In the case of Diffie-Hellman, the key
shall be produced from the agreed bit string as follows:
* Truncate the bit string to the appropriate length.
* Rectify parity in each byte (if necessary) to obtain the key.
For instance, in the case of a DES key, we take the first eight
bytes of the bit stream, and then adjust the least significant bit
of each byte to ensure that each byte has odd parity.
RFC 1510, Section 6.1, defines EncryptedData as follows:
EncryptedData ::= SEQUENCE {
etype [0] INTEGER,
kvno [1] INTEGER OPTIONAL,
cipher [2] OCTET STRING
-- is CipherText
}
RFC 1510 also defines how CipherText is to be composed. It is not
an ASN.1 data structure, but rather an octet string which is the
encryption of a plaintext string. This plaintext string is in turn
a concatenation of the following octet strings: a confounder, a
checksum, the message, and padding. Details of how these components
are arranged can be found in RFC 1510.
The PKINIT protocol introduces several new types of encryption.
Data that is encrypted with a public key will allow only the check
optional field, as it is defined above. This type of the checksum
will be specified in the etype field, together with the encryption
type.
In order to identify the checksum type, etype will have the
following values:
rsa-pub-MD5
rsa-pub-SHA1
In the case that etype is set to rsa-pub, the optional 'check'
field will not be provided.
Data that is encrypted with a private key will not use any optional
fields. PKINIT uses private key encryption only for signatures,
which are encrypted checksums. Therefore, the optional check field
is not needed.
3.2. Standard Public Key Authentication
Implementation of the changes in this section is REQUIRED for
compliance with PKINIT.
It is assumed that all public keys are signed by some certification
authority (CA). The initial authentication request is sent as per
RFC 1510, except that a preauthentication field containing data
signed by the user's private key accompanies the request:
PA-PK-AS-REQ ::= SEQUENCE {
-- PA TYPE 14
signedAuthPack [0] SignedAuthPack
userCert [1] SEQUENCE OF Certificate OPTIONAL,
-- the user's certificate chain
trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL,
-- CAs that the client trusts
serialNumber [3] CertificateSerialNumber OPTIONAL
-- specifying a particular
-- certificate if the client
-- already has it;
-- must be accompanied by
-- a single trustedCertifier
}
CertificateSerialNumber ::= INTEGER
-- as specified by PKCS 6
SignedAuthPack ::= SEQUENCE {
authPack [0] AuthPack,
authPackSig [1] Signature,
-- of authPack
-- using user's private key
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- if client is using Diffie-Hellman
}
PKAuthenticator ::= SEQUENCE {
kdcName [0] PrincipalName,
kdcRealm [1] Realm,
cusec [2] INTEGER,
-- for replay prevention
ctime [3] KerberosTime,
-- for replay prevention
nonce [4] INTEGER
}
Signature ::= SEQUENCE {
signedHash [0] EncryptedData
-- of type Checksum
}
Checksum ::= SEQUENCE {
cksumtype [0] INTEGER,
checksum [1] OCTET STRING
} -- as specified by RFC 1510
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm [0] AlgorithmIdentifier,
subjectPublicKey [1] BIT STRING
-- for DH, equals
-- public exponent (INTEGER encoded
-- as payload of BIT STRING)
} -- as specified by the X.509 recommendation [9]
AlgorithmIdentifier ::= SEQUENCE {
algorithm [0] ALGORITHM.&id,
-- for DH, equals
-- dhKeyAgreement
-- ({iso(1) member-body(2) US(840)
-- rsadsi(113549) pkcs(1) pkcs-3(3)
-- 1})
parameters [1] ALGORITHM.&type
-- for DH, is DHParameter
} -- as specified by the X.509 recommendation [9]
DHParameter ::= SEQUENCE {
prime [0] INTEGER,
-- p
base [1] INTEGER,
-- g
privateValueLength [2] INTEGER OPTIONAL
}
Certificate ::= SEQUENCE {
certType [0] INTEGER,
-- type of certificate
-- 1 = X.509v3 (DER encoding)
-- 2 = PGP (per PGP specification)
certData [1] OCTET STRING
-- actual certificate
-- type determined by certType
}
If the client passes a certificate serial number in the request,
the KDC is requested to use the referred-to certificate. If none
exists, then the KDC returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
other hand, the client does not pass any trustedCertifiers,
believing that it has the KDC's certificate, but the KDC has more
than one certificate.
The PKAuthenticator carries information to foil replay attacks,
to bind the request and response, and to optionally pass the
client's Diffie-Hellman public value (i.e. for using DSA in
combination with Diffie-Hellman). The PKAuthenticator is signed
with the private key corresponding to the public key in the
certificate found in userCert (or cached by the KDC).
In the PKAuthenticator, the client may specify the KDC name in one
of two ways:
* The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
where <realm_name> is replaced by the applicable realm name.
* The name in the KDC's certificate (e.g., an X.500 name, or a
PGP name).
Note that the first case requires that the certificate name and the
Kerberos principal name be bound together (e.g., via an X.509v3
extension).
The userCert field is a sequence of certificates, the first of which
must be the user's public key certificate. Any subsequent
certificates will be certificates of the certifiers of the user's
certificate. These cerificates may be used by the KDC to verify the
user's public key. This field may be left empty if the KDC already
has the user's certificate.
The trustedCertifiers field contains a list of certification
authorities trusted by the client, in the case that the client does
not possess the KDC's public key certificate. If the KDC has no
certificate signed by any of the trustedCertifiers, then it returns
an error of type KDC_ERR_CERTIFICATE_MISMATCH.
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type, the KDC attempts to verify the user's certificate chain
(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 verification of the user's certificate fails, the KDC sends back
an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data
field contains additional information pertaining to this error, and
is formatted as follows:
METHOD-DATA ::= SEQUENCE {
method-type [0] INTEGER,
-- 1 = cannot verify public key
-- 2 = invalid certificate
-- 3 = revoked certificate
-- 4 = invalid KDC name
-- 5 = client name mismatch
method-data [1] OCTET STRING OPTIONAL
} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
The values for the method-type and method-data fields are described
in Section 3.2.1.
If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
verifies that it has a certificate issued by one of the certifiers
trusted by the client. If it does not have a suitable certificate,
the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
the client.
If a trust relationship exists, the KDC then verifies the client's
signature on AuthPack. If that fails, the KDC returns an error
message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC 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 the
PKAuthenticator.
If the clientPublicValue field is filled in, indicating that the
client wishes to use Diffie-Hellman key agreement, then the KDC
checks to see that the parameters satisfy its policy. If they do
not (e.g., the prime size is insufficient for the expected
encryption type), then the KDC sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
private values for the response.
The KDC also checks that the timestamp in the PKAuthenticator is
within the allowable window. If the local (server) time and the
client time in the authenticator differ by more than the allowable
clock skew, then the KDC returns an error message of type
KRB_AP_ERR_SKEW.
Assuming no errors, the KDC replies as per RFC 1510, except as
follows: The user's name in the ticket is as represented in the
certificate, unless a Kerberos principal name is bound to the name
in the certificate (e.g., via an X.509v3 extension). The user's
realm in the ticket shall be the name of the Certification
Authority that issued the user's public key certificate.
The KDC encrypts the reply not with the user's long-term key, but
with a random key generated only for this particular response. This
random key is sealed in the preauthentication field:
PA-PK-AS-REP ::= SEQUENCE {
-- PA TYPE 15
encSignedReplyKeyPack [0] EncryptedData,
-- of type SignedReplyKeyPack
-- using the temporary key
-- in encTmpKey
encTmpKeyPack [1] EncryptedData,
-- of type TmpKeyPack
-- using either the client public
-- key or the Diffie-Hellman key
-- specified by SignedDHPublicValue
signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL
-- if one was passed in the request
kdcCert [3] SEQUENCE OF Certificate OPTIONAL,
-- the KDC's certificate chain
}
SignedReplyKeyPack ::= SEQUENCE {
replyKeyPack [0] ReplyKeyPack,
replyKeyPackSig [1] Signature,
-- of replyEncKeyPack
-- using KDC's private key
}
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- used to encrypt main reply
-- of same ENCTYPE as session key
nonce [1] INTEGER
-- binds response to the request
-- must be same as the nonce
-- passed in the PKAuthenticator
}
TmpKeyPack ::= SEQUENCE {
tmpKey [0] EncryptionKey,
-- used to encrypt the
-- SignedReplyKeyPack
-- of same ENCTYPE as session key
}
SignedKDCPublicValue ::= SEQUENCE {
kdcPublicValue [0] SubjectPublicKeyInfo,
-- as described above
kdcPublicValueSig [1] Signature
-- of kdcPublicValue
-- using KDC's private key
}
The kdcCert field is a sequence of certificates, the first of which
must be the KDC's public key certificate. Any subsequent
certificates will be certificates of the certifiers of the KDC's
certificate. The last of these must have as its certifier one of
the certifiers sent to the KDC in the PA-PK-AS-REQ. These
cerificates may be used by the client to verify the KDC's public
key. This field is empty if the client did not send to the KDC a
list of trusted certifiers (the trustedCertifiers field was empty).
Since each certifier in the certification path of a user's
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 is defined in Section 3.1 of this
document. If applicable, the transit-policy-checked flag should be
set in the issued ticket.
The KDC's certificate must bind the public key to a name derivable
from the name of the realm for that KDC. For an X.509 certificate,
this is done as follows. The name of the KDC will be represented
as an OtherName, encoded as a GeneralString:
GeneralName ::= CHOICE {
otherName [0] KDCPrincipalName,
...
}
KDCPrincipalNameTypes OTHER-NAME ::= {
{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
}
KDCPrincipalName ::= SEQUENCE {
nameType OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
name OTHER-NAME.&type ( { KDCPrincipalNameTypes }
{ @nameType } )
}
PrincipalNameSrvInst ::= GeneralString
where (from the Kerberos specification) we have
krb5 OBJECT IDENTIFIER ::= { iso (1)
org (3)
dod (6)
internet (1)
security (5)
kerberosv5 (2) }
principalName OBJECT IDENTIFIER ::= { krb5 2 }
principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
The client then extracts the random key used to encrypt the main
reply. This random key (in 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.
3.2.1. Additional Information for Errors
This section describes the interpretation of the method-type and
method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
If method-type=1, the client's public key certificate chain does not
contain a certificate that is signed by a certification authority
trusted by the KDC. The format of the method-data field will be an
ASN.1 encoding of a list of trusted certifiers, as defined above:
TrustedCertifiers ::= SEQUENCE OF PrincipalName
If method-type=2, the signature on one of the certificates in the
chain cannot be verified. The format of the method-data field will
be an ASN.1 encoding of the integer index of the certificate in
question:
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- 1 = 2nd certificate, etc
If method-type=3, one of the certificates in the chain has been
revoked. The format of the method-data field will be an ASN.1
encoding of the integer index of the certificate in question:
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- 1 = 2nd certificate, etc
If method-type=4, the KDC name or realm in the PKAuthenticator does
not match the principal name of the KDC. There is no method-data
field in this case.
If method-type=5, the client name or realm in the certificate does
not match the principal name of the client. There is no
method-data field in this case.
3.3. Digital Signature
Implementation of the changes in this section are OPTIONAL for
compliance with PKINIT.
We offer this option with the warning that it requires the client to
generate a random key; the client may not be able to guarantee the
same level of randomness as the KDC.
If the user registered, or presents a certificate for, a digital
signature key with the KDC instead of an encryption key, then a
separate exchange must be used. The client sends a request for a
TGT as usual, except that it (rather than the KDC) generates the
random key that will be used to encrypt the KDC response. This key
is sent to the KDC along with the request in a preauthentication
field, encrypted with the KDC's public key:
PA-PK-AS-SIGN ::= SEQUENCE {
-- PA TYPE 16
encSignedRandomKeyPack [0] EncryptedData,
-- of type SignedRandomKeyPack
-- using the key in encTmpKeyPack
encTmpKeyPack [1] EncryptedData,
-- of type TmpKeyPack
-- using the KDC's public key
userCert [2] SEQUENCE OF Certificate OPTIONAL
-- the user's certificate chain
}
SignedRandomKeyPack ::= SEQUENCE {
randomkeyPack [0] RandomKeyPack,
randomkeyPackSig [1] Signature
-- of keyPack
-- using user's private key
}
RandomKeyPack ::= SEQUENCE {
randomKey [0] EncryptionKey,
-- will be used to encrypt reply
randomKeyAuth [1] PKAuthenticator
-- nonce copied from AS-REQ
}
If the KDC does not accept client-generated random keys as a matter
of policy, then it sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as
follows.
Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
the randomKey. It then replies as per RFC 1510, except that the
reply is encrypted not with a password-derived user key, but with
the randomKey sent in the request. Since the client already knows
this key, there is no need to accompany the reply with an extra
preauthentication field. The transited field of the ticket should
specify the certification path as described in Section 3.2.
3.4. Retrieving the User's Private Key from the KDC
Implementation of the changes described in this section are OPTIONAL
for compliance with PKINIT.
When the user's private key is not stored local to the user, he may
choose to store the private key (normally encrypted using a
password-derived key) on the KDC. In this case, the client makes a
request as described above, except that instead of preauthenticating
with his private key, he uses a symmetric key shared with the KDC.
For simplicity's sake, this shared key is derived from the password-
derived key used to encrypt the private key, in such a way that the
KDC can authenticate the user with the shared key without being able
to extract the private key.
We provide this option to present the user with an alternative to
storing the private key on local disk at each machine where he
expects to authenticate himself using PKINIT. It should be noted
that it replaces the added risk of long-term storage of the private
key on possibly many workstations with the added risk of storing the
private key on the KDC in a form vulnerable to brute-force attack.
Denote by K1 the symmetric key used to encrypt the private key.
Then construct symmetric key K2 as follows:
* Perform a hash on K1.
* Truncate the digest to Length(K1) bytes.
* Rectify parity in each byte (if necessary) to obtain K2.
The KDC stores K2, the public key, and the encrypted private key.
This key pair is designated as the "primary" key pair for that user.
This primary key pair is the one used to perform initial
authentication using the PA-PK-AS-REP preauthentication field. If
he desires, he may also store additional key pairs on the KDC; these
may be requested in addition to the primary. When the client
requests initial authentication using public key cryptography, it
must then include in its request, instead of a PA-PK-AS-REQ, the
following preauthentication sequence:
PA-PK-KEY-REQ ::= SEQUENCE {
-- PA TYPE 17
signedPKAuth [0] SignedPKAuth,
trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
-- CAs that the client trusts
keyIDList [2] SEQUENCE OF Checksum OPTIONAL
-- payload is hash of public key
-- corresponding to desired
-- private key
-- if absent, KDC will return all
-- stored private keys
}
SignedPKAuth ::= SEQUENCE {
pkAuth [0] PKAuthenticator,
pkAuthSig [1] Signature
-- of pkAuth
-- using the symmetric key K2
}
If a keyIDList is present, the first identifier should indicate
the primary private key. No public key certificate is required,
since the KDC stores the public key along with the private key.
If there is no keyIDList, all the user's private keys are returned.
Upon receipt, the KDC verifies the signature using K2. If the
verification fails, the KDC sends back an error of type
KDC_ERR_INVALID_SIG. If the signature verifies, but the requested
keys are not found on the KDC, then the KDC sends back an error of
type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as
described in Section 3.2, except that in addition, the KDC appends
the following preauthentication sequence:
PA-PK-KEY-REP ::= SEQUENCE {
-- PA TYPE 18
encKeyRep [0] EncryptedData
-- of type EncKeyReply
-- using the symmetric key K2
}
EncKeyReply ::= SEQUENCE {
keyPackList [0] SEQUENCE OF KeyPack,
-- the first KeyPair is
-- the primary key pair
nonce [1] INTEGER
-- binds reply to request
-- must be identical to the nonce
-- sent in the SignedAuthPack
}
KeyPack ::= SEQUENCE {
keyID [0] Checksum,
encPrivKey [1] OCTET STRING
}
Upon receipt of the reply, the client extracts the encrypted private
keys (and may store them, at the client's option). The primary
private key, which must be the first private key in the keyPack
SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
this key in turn is used to decrypt the main reply as described in
Section 3.2.
4. Logistics and Policy
This section describes a way to define the policy on the use of
PKINIT for each principal and request.
The KDC is not required to contain a database record for users
that use either the Standard Public Key Authentication or Public Key
Authentication with a Digital Signature. However, if these users
are registered with the KDC, it is recommended that the database
record for these users be modified to include three additional flags
in the attributes field.
The first flag, use_standard_pk_init, indicates that the user should
authenticate using standard PKINIT as described in Section 3.2. The
second flag, use_digital_signature, indicates that the user should
authenticate using digital signature PKINIT as described in Section
3.3. The third flag, store_private_key, indicates that the user
has stored his private key on the KDC and should retrieve it using
the exchange described in Section 3.4.
If one of the preauthentication fields defined above is included in
the request, then the KDC shall respond as described in Sections 3.2
through 3.4, ignoring the aforementioned database flags. If more
than one of the preauthentication fields is present, the KDC shall
respond with an error of type KDC_ERR_PREAUTH_FAILED.
In the event that none of the preauthentication fields defined above
are included in the request, the KDC checks to see if any of the
above flags are set. If the first flag is set, then it sends back
an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
preauthentication field of type PA-PK-AS-REQ must be included in the
request.
Otherwise, if the first flag is clear, but the second flag is set,
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
indicating that a preauthentication field of type PA-PK-AS-SIGN must
be included in the request.
Lastly, if the first two flags are clear, but the third flag is set,
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
indicating that a preauthentication field of type PA-PK-KEY-REQ must
be included in the request.
5. Transport Issues
Certificate chains can potentially grow quite large and span several
UDP packets; this in turn increases the probability that a Kerberos
message involving PKINIT extensions will be broken in transit. In
light of the possibility that the Kerberos specification will
require KDCs to accept requests using TCP as a transport mechanism,
we make the same recommendation with respect to the PKINIT
extensions as well.
6. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
Transport Layer Security (TLS).
draft-ietf-tls-kerb-cipher-suites-00.txt
[4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt
[5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed
System Security, 1997.
[6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic
Commerce, July 1995.
[7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL
Protocol, Version 3.0 - IETF Draft.
[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.
[9] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
7. Acknowledgements
Sasha Medvinsky contributed several ideas to the protocol changes
and specifications in this document. His additions have been most
appreciated.
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 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.
8. Expiration Date
This draft expires May 26, 1998.
9. Authors
Brian Tung
Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {brian, bcn}@isi.edu
John Wray
Digital Equipment Corporation
550 King Street, LKG2-2/Z7
Littleton, MA 01460
Phone: +1 508 486 5210
E-mail: wray@tuxedo.enet.dec.com
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road Suite 310
Issaquah WA 98027-5378
Phone: +1 206 391 6000
E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
Jonathan Trostle
Novell Corporation
Provo UT
E-mail: jtrostle@novell.com

959
doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt Normal file
View File

@@ -0,0 +1,959 @@
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-06.txt Clifford Neuman
Updates: RFC 1510 ISI
expires September 15, 1998 John Wray
Digital Equipment Corporation
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
Jonathan Trostle
Novell
Public Key Cryptography for Initial Authentication in Kerberos
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
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check
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).
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-05.txt, and expires September 15,
1998. Please send comments to the authors.
1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
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.
2. Introduction
The popularity of public key cryptography has produced a desire for
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.
Public key cryptography can be integrated into Kerberos in a number
of ways. One is to associate a key pair with each realm, which can
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.
One of the guiding principles in the design of PKINIT is that
changes should be as minimal as possible. As a result, the basic
mechanism of PKINIT is as follows: The user sends a request to the
KDC as before, except that if that user is to use public key
cryptography in the initial authentication step, his certificate
accompanies the initial request, in the preauthentication fields.
Upon receipt of this request, the KDC verifies the certificate and
issues a ticket granting ticket (TGT) as before, except that
the encPart from the AS-REP message carrying the TGT is now
encrypted in a randomly-generated key, instead of the user's
long-term key (which is derived from a password). This
random key is in turn encrypted using the public key from the
certificate that came with the request and signed using the KDC's
private key, and accompanies the reply, in the preauthentication
fields.
PKINIT also allows for users with only digital signature keys to
authenticate using those keys, and for users to store and retrieve
private keys on the KDC.
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]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following changes to RFC 1510 are proposed:
* Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity.
* Users may store private keys on the KDC for retrieval during
Kerberos initial authentication.
This proposal addresses two ways that users may use public key
cryptography for initial authentication. Users may present public
key certificates, or they may generate their own session key,
signed by their digital signature key. In either case, the end
result is that the user obtains an ordinary TGT that may be used for
subsequent authentication, with such authentication using only
conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 and 3.3 describe the extensions for the two initial
authentication methods. Section 3.4 describes a way for the user to
store and retrieve his private key on the KDC, as an adjunct to the
initial authentication.
3.1. Definitions
The extensions involve new encryption methods; we propose the
addition of the following types:
dsa-sign 8
rsa-priv 9
rsa-pub 10
rsa-pub-md5 11
rsa-pub-sha1 12
The proposal of these encryption types notwithstanding, we do not
mandate the use of any particular public key encryption method.
The extensions involve new preauthentication fields; we propose the
addition of the following types:
PA-PK-AS-REQ 14
PA-PK-AS-REP 15
PA-PK-AS-SIGN 16
PA-PK-KEY-REQ 17
PA-PK-KEY-REP 18
The extensions also involve new error types; we propose the addition
of the following types:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_TOO_WEAK 65
KDC_ERR_CERTIFICATE_MISMATCH 66
In addition, PKINIT does not define, but does permit, the following
algorithm identifiers for use with the Signature data structure:
md4WithRSAEncryption (as defined in PKCS 1)
md5WithRSAEncryption (as defined in PKCS 1)
sha-1WithRSAEncryption ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
dsaWithSHA1 ::= { OIW oIWSecSig(3) oIWSecAlgorithm(2)
dsaWithSHA1(27) }
where
OIW ::= iso(1) identifiedOrganization(3) oIW(14)
In many cases, PKINIT requires the encoding of an X.500 name as a
Realm. In these cases, the realm will be represented using a
different style, specified in RFC 1510 with the following example:
NAMETYPE:rest/of.name=without-restrictions
For a realm derived from an X.500 name, NAMETYPE will have the value
X500-RFC1779. The full realm name will appear as follows:
X500-RFC1779:RFC1779Encode(DistinguishedName)
where DistinguishedName is an X.500 name, and RFC1779Encode is a
readable ASCII encoding of an X.500 name, as defined by RFC 1779.
To ensure that this encoding is unique, we add the following rules
to those specified by RFC 1779:
* The optional spaces specified in RFC 1779 are not allowed.
* The character that separates relative distinguished names
must be ',' (i.e., it must never be ';').
* Attribute values must not be enclosed in double quotes.
* Attribute values must not be specified as hexadecimal
numbers.
* When an attribute name is specified in the form of an OID,
it must start with the 'OID.' prefix, and not the 'oid.'
prefix.
* The order in which the attributes appear in the RFC 1779
encoding must be the reverse of the order in the ASN.1
encoding of the X.500 name that appears in the public key
certificate, because RFC 1779 requires that the least
significant relative distinguished name appear first. The
order of the relative distinguished names, as well as the
order of the attributes within each relative distinguished
name, will be reversed.
Similarly, PKINIT may require the encoding of an X.500 name as a
PrincipalName. In these cases, the name-type of the principal name
shall be set to NT-X500-PRINCIPAL. This new name type is defined
as:
#define CSFC5c_NT_X500_PRINCIPAL 6
The name-string shall be set as follows:
RFC1779Encode(DistinguishedName)
as described above.
3.1.1. Encryption and Key Formats
In the exposition below, we use the terms public key and private
key generically. It should be understood that the term "public
key" may be used to refer to either a public encryption key or a
signature verification key, and that the term "private key" may be
used to refer to either a private decryption key or a signature
generation key. The fact that these are logically distinct does
not preclude the assignment of bitwise identical keys.
All additional symmetric keys specified in this draft shall use the
same encryption type as the session key in the response from the
KDC. These include the temporary keys used to encrypt the signed
random key encrypting the response, as well as the key derived from
Diffie-Hellman agreement. In the case of Diffie-Hellman, the key
shall be produced from the agreed bit string as follows:
* Truncate the bit string to the appropriate length.
* Rectify parity in each byte (if necessary) to obtain the key.
For instance, in the case of a DES key, we take the first eight
bytes of the bit stream, and then adjust the least significant bit
of each byte to ensure that each byte has odd parity.
RFC 1510, Section 6.1, defines EncryptedData as follows:
EncryptedData ::= SEQUENCE {
etype [0] INTEGER,
kvno [1] INTEGER OPTIONAL,
cipher [2] OCTET STRING
-- is CipherText
}
RFC 1510 also defines how CipherText is to be composed. It is not
an ASN.1 data structure, but rather an octet string which is the
encryption of a plaintext string. This plaintext string is in turn
a concatenation of the following octet strings: a confounder, a
checksum, the message, and padding. Details of how these components
are arranged can be found in RFC 1510.
The PKINIT protocol introduces several new types of encryption.
Data that is encrypted with a public key will allow only the check
optional field, as it is defined above. This type of the checksum
will be specified in the etype field, together with the encryption
type.
In order to identify the checksum type, etype will have the
following values:
rsa-pub-MD5
rsa-pub-SHA1
In the case that etype is set to rsa-pub, the optional 'check'
field will not be provided.
Data that is encrypted with a private key will not use any optional
fields. PKINIT uses private key encryption only for signatures,
which are encrypted checksums. Therefore, the optional check field
is not needed.
3.2. Standard Public Key Authentication
Implementation of the changes in this section is REQUIRED for
compliance with PKINIT.
It is assumed that all public keys are signed by some certification
authority (CA). The initial authentication request is sent as per
RFC 1510, except that a preauthentication field containing data
signed by the user's private key accompanies the request:
PA-PK-AS-REQ ::= SEQUENCE {
-- PA TYPE 14
signedAuthPack [0] SignedAuthPack
userCert [1] SEQUENCE OF Certificate OPTIONAL,
-- the user's certificate chain
trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL,
-- CAs that the client trusts
serialNumber [3] CertificateSerialNumber OPTIONAL
-- specifying a particular
-- certificate if the client
-- already has it;
-- must be accompanied by
-- a single trustedCertifier
}
CertificateSerialNumber ::= INTEGER
-- as specified by PKCS 6
SignedAuthPack ::= SEQUENCE {
authPack [0] AuthPack,
authPackSig [1] Signature,
-- of authPack
-- using user's private key
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- if client is using Diffie-Hellman
}
PKAuthenticator ::= SEQUENCE {
kdcName [0] PrincipalName,
kdcRealm [1] Realm,
cusec [2] INTEGER,
-- for replay prevention
ctime [3] KerberosTime,
-- for replay prevention
nonce [4] INTEGER
}
Signature ::= SEQUENCE {
signatureAlgorithm [0] SignatureAlgorithmIdentifier,
pkcsSignature [1] BIT STRING
-- octet-aligned big-endian bit
-- string (encrypted with signer's
-- private key)
}
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
AlgorithmIdentifier ::= SEQUENCE {
algorithm ALGORITHM.&id,
-- for DH, equals
-- dhKeyAgreement
-- ({iso(1) member-body(2) US(840)
-- rsadsi(113549) pkcs(1) pkcs-3(3)
-- 1})
parameters ALGORITHM.&type
-- for DH, is DHParameter
} -- as specified by the X.509 recommendation [9]
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
-- for DH, equals
-- public exponent (INTEGER encoded
-- as payload of BIT STRING)
} -- as specified by the X.509 recommendation [9]
DHParameter ::= SEQUENCE {
prime INTEGER,
-- p
base INTEGER,
-- g
privateValueLength INTEGER OPTIONAL
} -- as specified by the X.509 recommendation [9]
Certificate ::= SEQUENCE {
certType [0] INTEGER,
-- type of certificate
-- 1 = X.509v3 (DER encoding)
-- 2 = PGP (per PGP specification)
certData [1] OCTET STRING
-- actual certificate
-- type determined by certType
}
If the client passes a certificate serial number in the request,
the KDC is requested to use the referred-to certificate. If none
exists, then the KDC returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
other hand, the client does not pass any trustedCertifiers,
believing that it has the KDC's certificate, but the KDC has more
than one certificate.
The PKAuthenticator carries information to foil replay attacks,
to bind the request and response, and to optionally pass the
client's Diffie-Hellman public value (i.e. for using DSA in
combination with Diffie-Hellman). The PKAuthenticator is signed
with the private key corresponding to the public key in the
certificate found in userCert (or cached by the KDC).
In the PKAuthenticator, the client may specify the KDC name in one
of two ways:
* The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
where <realm_name> is replaced by the applicable realm name.
* The name in the KDC's certificate (e.g., an X.500 name, or a
PGP name).
Note that the first case requires that the certificate name and the
Kerberos principal name be bound together (e.g., via an X.509v3
extension).
The userCert field is a sequence of certificates, the first of which
must be the user's public key certificate. Any subsequent
certificates will be certificates of the certifiers of the user's
certificate. These cerificates may be used by the KDC to verify the
user's public key. This field may be left empty if the KDC already
has the user's certificate.
The trustedCertifiers field contains a list of certification
authorities trusted by the client, in the case that the client does
not possess the KDC's public key certificate. If the KDC has no
certificate signed by any of the trustedCertifiers, then it returns
an error of type KDC_ERR_CERTIFICATE_MISMATCH.
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type, the KDC attempts to verify the user's certificate chain
(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 verification of the user's certificate fails, the KDC sends back
an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data
field contains additional information pertaining to this error, and
is formatted as follows:
METHOD-DATA ::= SEQUENCE {
method-type [0] INTEGER,
-- 1 = cannot verify public key
-- 2 = invalid certificate
-- 3 = revoked certificate
-- 4 = invalid KDC name
-- 5 = client name mismatch
method-data [1] OCTET STRING OPTIONAL
} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
The values for the method-type and method-data fields are described
in Section 3.2.1.
If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
verifies that it has a certificate issued by one of the certifiers
trusted by the client. If it does not have a suitable certificate,
the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
the client.
If a trust relationship exists, the KDC then verifies the client's
signature on AuthPack. If that fails, the KDC returns an error
message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC 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 the
PKAuthenticator.
If the clientPublicValue field is filled in, indicating that the
client wishes to use Diffie-Hellman key agreement, then the KDC
checks to see that the parameters satisfy its policy. If they do
not (e.g., the prime size is insufficient for the expected
encryption type), then the KDC sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
private values for the response.
The KDC also checks that the timestamp in the PKAuthenticator is
within the allowable window. If the local (server) time and the
client time in the authenticator differ by more than the allowable
clock skew, then the KDC returns an error message of type
KRB_AP_ERR_SKEW.
Assuming no errors, the KDC replies as per RFC 1510, except as
follows: The user's name in the ticket is as represented in the
certificate, unless a Kerberos principal name is bound to the name
in the certificate (e.g., via an X.509v3 extension). The user's
realm in the ticket shall be the name of the Certification
Authority that issued the user's public key certificate.
The KDC encrypts the reply not with the user's long-term key, but
with a random key generated only for this particular response. This
random key is sealed in the preauthentication field:
PA-PK-AS-REP ::= SEQUENCE {
-- PA TYPE 15
encSignedReplyKeyPack [0] EncryptedData,
-- of type SignedReplyKeyPack
-- using the temporary key
-- in encTmpKey
encTmpKeyPack [1] EncryptedData,
-- of type TmpKeyPack
-- using either the client public
-- key or the Diffie-Hellman key
-- specified by SignedDHPublicValue
signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL
-- if one was passed in the request
kdcCert [3] SEQUENCE OF Certificate OPTIONAL,
-- the KDC's certificate chain
}
SignedReplyKeyPack ::= SEQUENCE {
replyKeyPack [0] ReplyKeyPack,
replyKeyPackSig [1] Signature,
-- of replyEncKeyPack
-- using KDC's private key
}
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- used to encrypt main reply
-- of same ENCTYPE as session key
nonce [1] INTEGER
-- binds response to the request
-- must be same as the nonce
-- passed in the PKAuthenticator
}
TmpKeyPack ::= SEQUENCE {
tmpKey [0] EncryptionKey,
-- used to encrypt the
-- SignedReplyKeyPack
-- of same ENCTYPE as session key
}
SignedKDCPublicValue ::= SEQUENCE {
kdcPublicValue [0] SubjectPublicKeyInfo,
-- as described above
kdcPublicValueSig [1] Signature
-- of kdcPublicValue
-- using KDC's private key
}
The kdcCert field is a sequence of certificates, the first of which
must be the KDC's public key certificate. Any subsequent
certificates will be certificates of the certifiers of the KDC's
certificate. The last of these must have as its certifier one of
the certifiers sent to the KDC in the PA-PK-AS-REQ. These
cerificates may be used by the client to verify the KDC's public
key. This field is empty if the client did not send to the KDC a
list of trusted certifiers (the trustedCertifiers field was empty).
Since each certifier in the certification path of a user's
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 is defined in Section 3.1 of this
document. If applicable, the transit-policy-checked flag should be
set in the issued ticket.
The KDC's certificate must bind the public key to a name derivable
from the name of the realm for that KDC. For an X.509 certificate,
this is done as follows. The name of the KDC will be represented
as an OtherName, encoded as a GeneralString:
GeneralName ::= CHOICE {
otherName [0] KDCPrincipalName,
...
}
KDCPrincipalNameTypes OTHER-NAME ::= {
{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
}
KDCPrincipalName ::= SEQUENCE {
nameType [0] OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
name [1] OTHER-NAME.&type ( { KDCPrincipalNameTypes }
{ @nameType } )
}
PrincipalNameSrvInst ::= GeneralString
where (from the Kerberos specification) we have
krb5 OBJECT IDENTIFIER ::= { iso (1)
org (3)
dod (6)
internet (1)
security (5)
kerberosv5 (2) }
principalName OBJECT IDENTIFIER ::= { krb5 2 }
principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
The client then extracts the random key used to encrypt the main
reply. This random key (in 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.
3.2.1. Additional Information for Errors
This section describes the interpretation of the method-type and
method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
If method-type=1, the client's public key certificate chain does not
contain a certificate that is signed by a certification authority
trusted by the KDC. The format of the method-data field will be an
ASN.1 encoding of a list of trusted certifiers, as defined above:
TrustedCertifiers ::= SEQUENCE OF PrincipalName
If method-type=2, the signature on one of the certificates in the
chain cannot be verified. The format of the method-data field will
be an ASN.1 encoding of the integer index of the certificate in
question:
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- 1 = 2nd certificate, etc
If method-type=3, one of the certificates in the chain has been
revoked. The format of the method-data field will be an ASN.1
encoding of the integer index of the certificate in question:
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- 1 = 2nd certificate, etc
If method-type=4, the KDC name or realm in the PKAuthenticator does
not match the principal name of the KDC. There is no method-data
field in this case.
If method-type=5, the client name or realm in the certificate does
not match the principal name of the client. There is no
method-data field in this case.
3.3. Digital Signature
Implementation of the changes in this section are OPTIONAL for
compliance with PKINIT.
We offer this option with the warning that it requires the client to
generate a random key; the client may not be able to guarantee the
same level of randomness as the KDC.
If the user registered, or presents a certificate for, a digital
signature key with the KDC instead of an encryption key, then a
separate exchange must be used. The client sends a request for a
TGT as usual, except that it (rather than the KDC) generates the
random key that will be used to encrypt the KDC response. This key
is sent to the KDC along with the request in a preauthentication
field, encrypted with the KDC's public key:
PA-PK-AS-SIGN ::= SEQUENCE {
-- PA TYPE 16
encSignedRandomKeyPack [0] EncryptedData,
-- of type SignedRandomKeyPack
-- using the key in encTmpKeyPack
encTmpKeyPack [1] EncryptedData,
-- of type TmpKeyPack
-- using the KDC's public key
userCert [2] SEQUENCE OF Certificate OPTIONAL
-- the user's certificate chain
}
SignedRandomKeyPack ::= SEQUENCE {
randomkeyPack [0] RandomKeyPack,
randomkeyPackSig [1] Signature
-- of keyPack
-- using user's private key
}
RandomKeyPack ::= SEQUENCE {
randomKey [0] EncryptionKey,
-- will be used to encrypt reply
randomKeyAuth [1] PKAuthenticator
-- nonce copied from AS-REQ
}
If the KDC does not accept client-generated random keys as a matter
of policy, then it sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as
follows.
Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
the randomKey. It then replies as per RFC 1510, except that the
reply is encrypted not with a password-derived user key, but with
the randomKey sent in the request. Since the client already knows
this key, there is no need to accompany the reply with an extra
preauthentication field. The transited field of the ticket should
specify the certification path as described in Section 3.2.
3.4. Retrieving the User's Private Key from the KDC
Implementation of the changes described in this section are OPTIONAL
for compliance with PKINIT.
When the user's private key is not stored local to the user, he may
choose to store the private key (normally encrypted using a
password-derived key) on the KDC. In this case, the client makes a
request as described above, except that instead of preauthenticating
with his private key, he uses a symmetric key shared with the KDC.
For simplicity's sake, this shared key is derived from the password-
derived key used to encrypt the private key, in such a way that the
KDC can authenticate the user with the shared key without being able
to extract the private key.
We provide this option to present the user with an alternative to
storing the private key on local disk at each machine where he
expects to authenticate himself using PKINIT. It should be noted
that it replaces the added risk of long-term storage of the private
key on possibly many workstations with the added risk of storing the
private key on the KDC in a form vulnerable to brute-force attack.
Denote by K1 the symmetric key used to encrypt the private key.
Then construct symmetric key K2 as follows:
* Perform a hash on K1.
* Truncate the digest to Length(K1) bytes.
* Rectify parity in each byte (if necessary) to obtain K2.
The KDC stores K2, the public key, and the encrypted private key.
This key pair is designated as the "primary" key pair for that user.
This primary key pair is the one used to perform initial
authentication using the PA-PK-AS-REP preauthentication field. If
he desires, he may also store additional key pairs on the KDC; these
may be requested in addition to the primary. When the client
requests initial authentication using public key cryptography, it
must then include in its request, instead of a PA-PK-AS-REQ, the
following preauthentication sequence:
PA-PK-KEY-REQ ::= SEQUENCE {
-- PA TYPE 17
signedPKAuth [0] SignedPKAuth,
trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
-- CAs that the client trusts
keyIDList [2] SEQUENCE OF Checksum OPTIONAL
-- payload is hash of public key
-- corresponding to desired
-- private key
-- if absent, KDC will return all
-- stored private keys
}
Checksum ::= SEQUENCE {
cksumtype [0] INTEGER,
checksum [1] OCTET STRING
} -- as specified by RFC 1510
SignedPKAuth ::= SEQUENCE {
pkAuth [0] PKAuthenticator,
pkAuthSig [1] Signature
-- of pkAuth
-- using the symmetric key K2
}
If a keyIDList is present, the first identifier should indicate
the primary private key. No public key certificate is required,
since the KDC stores the public key along with the private key.
If there is no keyIDList, all the user's private keys are returned.
Upon receipt, the KDC verifies the signature using K2. If the
verification fails, the KDC sends back an error of type
KDC_ERR_INVALID_SIG. If the signature verifies, but the requested
keys are not found on the KDC, then the KDC sends back an error of
type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as
described in Section 3.2, except that in addition, the KDC appends
the following preauthentication sequence:
PA-PK-KEY-REP ::= SEQUENCE {
-- PA TYPE 18
encKeyRep [0] EncryptedData
-- of type EncKeyReply
-- using the symmetric key K2
}
EncKeyReply ::= SEQUENCE {
keyPackList [0] SEQUENCE OF KeyPack,
-- the first KeyPair is
-- the primary key pair
nonce [1] INTEGER
-- binds reply to request
-- must be identical to the nonce
-- sent in the SignedAuthPack
}
KeyPack ::= SEQUENCE {
keyID [0] Checksum,
encPrivKey [1] OCTET STRING
}
Upon receipt of the reply, the client extracts the encrypted private
keys (and may store them, at the client's option). The primary
private key, which must be the first private key in the keyPack
SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
this key in turn is used to decrypt the main reply as described in
Section 3.2.
4. Logistics and Policy
This section describes a way to define the policy on the use of
PKINIT for each principal and request.
The KDC is not required to contain a database record for users
that use either the Standard Public Key Authentication or Public Key
Authentication with a Digital Signature. However, if these users
are registered with the KDC, it is recommended that the database
record for these users be modified to include three additional flags
in the attributes field.
The first flag, use_standard_pk_init, indicates that the user should
authenticate using standard PKINIT as described in Section 3.2. The
second flag, use_digital_signature, indicates that the user should
authenticate using digital signature PKINIT as described in Section
3.3. The third flag, store_private_key, indicates that the user
has stored his private key on the KDC and should retrieve it using
the exchange described in Section 3.4.
If one of the preauthentication fields defined above is included in
the request, then the KDC shall respond as described in Sections 3.2
through 3.4, ignoring the aforementioned database flags. If more
than one of the preauthentication fields is present, the KDC shall
respond with an error of type KDC_ERR_PREAUTH_FAILED.
In the event that none of the preauthentication fields defined above
are included in the request, the KDC checks to see if any of the
above flags are set. If the first flag is set, then it sends back
an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
preauthentication field of type PA-PK-AS-REQ must be included in the
request.
Otherwise, if the first flag is clear, but the second flag is set,
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
indicating that a preauthentication field of type PA-PK-AS-SIGN must
be included in the request.
Lastly, if the first two flags are clear, but the third flag is set,
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
indicating that a preauthentication field of type PA-PK-KEY-REQ must
be included in the request.
5. Security Considerations
PKINIT raises a few security considerations, which we will address
in this section.
First of all, PKINIT introduces a new trust model, where KDCs do not
(necessarily) certify the identity of those for whom they issue
tickets. PKINIT does allow KDCs to act as their own CAs, in order
to simplify key management, but one of the additional benefits is to
align Kerberos authentication with a global public key
infrastructure. Anyone using PKINIT in this way must be aware of
how the certification infrastructure they are linking to works.
Secondly, PKINIT also introduces the possibility of interactions
between different cryptosystems, which may be of widely varying
strengths. Many systems, for instance, allow the use of 512-bit
public keys. Using such keys to wrap data encrypted under strong
conventional cryptosystems, such as triple-DES, is inappropriate;
it adds a weak link to a strong one at extra cost. Implementors
and administrators should take care to avoid such wasteful and
deceptive interactions.
5. Transport Issues
Certificate chains can potentially grow quite large and span several
UDP packets; this in turn increases the probability that a Kerberos
message involving PKINIT extensions will be broken in transit. In
light of the possibility that the Kerberos specification will
require KDCs to accept requests using TCP as a transport mechanism,
we make the same recommendation with respect to the PKINIT
extensions as well.
6. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
Transport Layer Security (TLS).
draft-ietf-tls-kerb-cipher-suites-00.txt
[4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt
[5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed
System Security, 1997.
[6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic
Commerce, July 1995.
[7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL
Protocol, Version 3.0 - IETF Draft.
[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.
[9] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
7. Acknowledgements
Sasha Medvinsky contributed several ideas to the protocol changes
and specifications in this document. His additions have been most
appreciated.
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 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.
8. Expiration Date
This draft expires September 15, 1998.
9. Authors
Brian Tung
Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {brian, bcn}@isi.edu
John Wray
Digital Equipment Corporation
550 King Street, LKG2-2/Z7
Littleton, MA 01460
Phone: +1 508 486 5210
E-mail: wray@tuxedo.enet.dec.com
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road Suite 310
Issaquah WA 98027-5378
Phone: +1 206 391 6000
E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
Jonathan Trostle
Novell Corporation
Provo UT
E-mail: jtrostle@novell.com

1181
doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt Normal file
View File

File diff suppressed because it is too large Load Diff

944
doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt Normal file
View File

@@ -0,0 +1,944 @@
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-08.txt Clifford Neuman
Updates: RFC 1510 ISI
expires November 12, 1999 Matthew Hur
CyberSafe Corporation
Ari Medvinsky
Excite
Sasha Medvinsky
General Instrument
John Wray
Iris Associates, Inc.
Jonathan Trostle
Cisco
Public Key Cryptography for Initial Authentication in Kerberos
0. Status Of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.ietf.org (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-09.txt, and expires November 12,
1999. Please send comments to the authors.
1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
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.
2. Introduction
The popularity of public key cryptography has produced a desire for
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.
Public key cryptography can be integrated into Kerberos in a number
of ways. One is to associate a key pair with each realm, which can
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.
PKINIT utilizes Diffie-Hellman keys in combination with digital
signature keys as the primary, required mechanism. It also allows
for the use of RSA keys. Note that PKINIT supports the use of
separate signature and encryption keys.
PKINIT enables access to Kerberos-secured services based on initial
authentication utilizing public key cryptography. PKINIT utilizes
standard public key signature and encryption data formats within the
standard Kerberos messages. The basic mechanism is as follows: The
user sends a request to the KDC as before, except that if that user
is to use public key cryptography in the initial authentication
step, his certificate and a signature accompany the initial request
in the preauthentication fields. Upon receipt of this request, the
KDC verifies the certificate and issues a ticket granting ticket
(TGT) as before, except that the encPart from the AS-REP message
carrying the TGT is now encrypted utilizing either a Diffie-Hellman
derived key or the user's public key. This message is authenticated
utilizing the public key signature of the KDC.
The PKINIT specification may also be used as a building block for
other specifications. PKCROSS [3] utilizes PKINIT for establishing
the inter-realm key and associated inter-realm policy to be applied
in issuing cross realm service tickets. As specified in [4],
anonymous Kerberos tickets can be issued by applying a NULL
signature in combination with Diffie-Hellman in the PKINIT exchange.
Additionally, the PKINIT specification may be used for direct peer
to peer authentication without contacting a central KDC. This
application of PKINIT is described in PKTAPP [5] and is based on
concepts introduced in [6, 7]. 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 TLS [8] 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 [9]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following change to RFC 1510 is proposed:
* Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity. The user presents
a public key certificate and obtains an ordinary TGT that may
be used for subsequent authentication, with such
authentication using only conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 describes the extensions for the initial authentication
method.
3.1. Definitions
The extensions involve new preauthentication fields; we introduce
the following preauthentication types:
PA-PK-AS-REQ 14
PA-PK-AS-REP 15
PA-PK-KEY-REQ 18
PA-PK-KEY-REP 19
The extensions also involve new error types; we introduce the
following types:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_TOO_WEAK 65
KDC_ERR_CERTIFICATE_MISMATCH 66
We utilize the following typed data for errors:
ETD-PKINIT-CMS-CERTIFICATES 101
ETD-KRB-PRINCIPAL 102
ETD-KRB-REALM 103
We utilize the following encryption types (which map directly to
OIDs):
sha1WithRSAEncryption-CmsOID 8
dsaWithSHA1-CmsOID 9
md4WithRsaEncryption-CmsOID 10
md5WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rc4-EnvOID 13
In many cases, PKINIT requires the encoding of an X.500 name as a
Realm. In these cases, the realm will be represented using a
different style, specified in RFC 1510 with the following example:
NAMETYPE:rest/of.name=without-restrictions
For a realm derived from an X.500 name, NAMETYPE will have the value
X500-RFC2253. The full realm name will appear as follows:
X500-RFC2253:RFC2253Encode(DistinguishedName)
where DistinguishedName is an X.500 name, and RFC2253Encode is a
readable ASCII encoding of an X.500 name, as defined by
RFC 2253 [14] (part of LDAPv3).
To ensure that this encoding is unique, we add the following rule
to those specified by RFC 2253:
The order in which the attributes appear in the RFC 2253
encoding must be the reverse of the order in the ASN.1
encoding of the X.500 name that appears in the public key
certificate. The order of the relative distinguished names
(RDNs), as well as the order of the AttributeTypeAndValues
within each RDN, will be reversed. (This is despite the fact
that an RDN is defined as a SET of AttributeTypeAndValues, where
an order is normally not important.)
Similarly, PKINIT may require the encoding of an X.500 name as a
PrincipalName. In these cases, the name-type of the principal name
shall be set to KRB_NT-X500-PRINCIPAL. This new name type is
defined as:
KRB_NT_X500_PRINCIPAL 6
The name-string shall be set as follows:
RFC2253Encode(DistinguishedName)
as described above.
Note that name mapping may be required or optional based on policy.
3.1.1. Encryption and Key Formats
In the exposition below, we use the terms public key and private
key generically. It should be understood that the term "public
key" may be used to refer to either a public encryption key or a
signature verification key, and that the term "private key" may be
used to refer to either a private decryption key or a signature
generation key. The fact that these are logically distinct does
not preclude the assignment of bitwise identical keys.
In the case of Diffie-Hellman, the key shall be produced from the
agreed bit string as follows:
* Truncate the bit string to the appropriate length.
* Rectify parity in each byte (if necessary) to obtain the key.
For instance, in the case of a DES key, we take the first eight
bytes of the bit stream, and then adjust the least significant bit
of each byte to ensure that each byte has odd parity.
3.1.2. Algorithm Identifiers
PKINIT does not define, but does permit, the algorithm identifiers
listed below.
3.1.2.1. Signature Algorithm Identifiers
These are the algorithm identifiers for use in the Signature data
structure as specified in CMS [11]:
sha-1WithRSAEncryption ALGORITHM PARAMETER NULL
::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 5 }
dsaWithSHA1 ALGORITHM PARAMETER NULL
::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
oIWSecAlgorithm(2) dsaWithSHA1(27) }
md4WithRsaEncryption ALGORITHM PARAMETER NULL
::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
oIWSecAlgorithm(2) md4WithRSAEncryption(4) }
md5WithRSAEncryption ALGORITHM PARAMETER NULL
::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) md5WithRSAEncryption(4) }
3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
This algorithm identifier is used inside the SubjectPublicKeyInfo
data structure:
dhKeyAgreement ALGORITHM PARAMETER DHParameters
::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-3(3) dhKeyAgreement(1) }
DHParameters ::= SEQUENCE {
prime INTEGER,
-- p
base INTEGER,
-- g
privateValueLength INTEGER OPTIONAL
} -- as specified by the X.509 recommendation [9]
3.1.2.3. Algorithm Identifiers for RSA Encryption
These algorithm identifiers are used inside the EnvelopedData data
structure, for encrypting the temporary key with a public key:
id-RSAES-OAEP OBJECT IDENTIFIER
::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 7 }
3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
These algorithm identifiers are used inside the EnvelopedData data
structure, for encrypting the temporary key with a Diffie-Hellman-
derived key, or for encrypting the reply key:
desCBC ALGORITHM PARAMETER IV8
::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
oIWSecAlgorithm(2) desCBC(7) }
DES-EDE3-CBC ALGORITHM PARAMETER IV8
::= { iso(1) member-body(2) US(840) rsadsi(113549)
encryptionAlgorithm(3) desEDE3(7) }
IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector
rc2CBC ALGORITHM PARAMETER RC2-CBCParameter
::= { iso(1) member-body(2) US(840) rsadsi(113549)
encryptionAlgorithm(3) rc2CBC(2) }
The rc2CBC algorithm parameters (RC2-CBCParameter) are defined
in the following section.
rc4 ALGORITHM PARAMETER NULL
::= { iso(1) member-body(2) US(840) rsadsi(113549)
encryptionAlgorithm(3) rc4(4) }
The rc4 algorithm cannot be used with the Diffie-Hellman-derived
keys, because its parameters do not specify the size of the key.
3.1.2.5. rc2CBC Algorithm Parameters
This definition of the RC2 parameters is taken from a paper by
Ron Rivest [13]. Refer to [13] for the complete description of the
RC2 algorithm.
RC2-CBCParameter ::= CHOICE {
iv IV,
params SEQUENCE {
version RC2Version,
iv IV
}
}
where
IV ::= OCTET STRING -- 8 octets
RC2Version ::= INTEGER -- 1-1024
RC2 in CBC mode has two parameters: an 8-byte initialization
vector (IV) and a version number in the range 1-1024 which
specifies in a roundabout manner the number of effective key bits
to be used for the RC2 encryption/decryption.
The correspondence between effective key bits and version number
is as follows:
1. If the number EKB of effective key bits is in the range 1-255,
then the version number is given by Table[EKB], where the
256-byte translation table is specified below. It specifies a
permutation on the numbers 0-255.
2. If the number EKB of effective key bits is in the range
256-1024, then the version number is simply EKB.
The default number of effective key bits for RC2 is 32.
If RC2-CBC is being performed with 32 effective key bits, the
parameters should be supplied as a simple IV, rather than as a
SEQUENCE containing a version and an IV.
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0
10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a
20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36
30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c
40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60
50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa
60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e
70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf
80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6
90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3
a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c
b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2
c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5
d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5
e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f
f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab
3.2. Public Key Authentication
Implementation of the changes in this section is REQUIRED for
compliance with PKINIT.
It is assumed that all public keys are signed by some certification
authority (CA). The initial authentication request is sent as per
RFC 1510, except that a preauthentication field containing data
signed by the user's private key accompanies the request:
PA-PK-AS-REQ ::= SEQUENCE {
-- PA TYPE 14
signedAuthPack [0] SignedData
-- defined in CMS [11]
-- AuthPack (below) defines the data
-- that is signed
trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
-- CAs that the client trusts
kdcCert [2] IssuerAndSerialNumber OPTIONAL
-- as defined in CMS [11]
-- specifies a particular KDC
-- certificate if the client
-- already has it;
-- must be accompanied by
-- a single trustedCertifier
}
Usage of SignedData:
The SignedData data type is specified in the Cryptographic
Message Syntax, a product of the S/MIME working group of the IETF.
- The encapContentInfo field must contain the PKAuthenticator
and, optionally, the client's Diffie Hellman public value.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1)
- The eContent field is data of the type AuthPack (below).
- The signerInfos field is a SET of SignerInfo that is required by
CMS; however, the set may contain zero elements. When non-empty,
this field contains the client's certificate chain. If present,
the KDC uses the public key from the client's certificate to
verify the signature in the request. Note that the client may
pass different certificates that are used for signing or for
encrypting. Thus, the KDC may utilize a different client
certificate for signature verification than the one it uses to
encrypt the reply to the client.
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- if client is using Diffie-Hellman
}
PKAuthenticator ::= SEQUENCE {
kdcName [0] PrincipalName,
kdcRealm [1] Realm,
cusec [2] INTEGER,
-- for replay prevention
ctime [3] KerberosTime,
-- for replay prevention
nonce [4] INTEGER
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
-- dhKeyAgreement
subjectPublicKey BIT STRING
-- for DH, equals
-- public exponent (INTEGER encoded
-- as payload of BIT STRING)
} -- as specified by the X.509 recommendation [9]
AlgorithmIdentifier ::= SEQUENCE {
algorithm ALGORITHM.&id,
parameters ALGORITHM.&type
} -- as specified by the X.509 recommendation [10]
If the client passes an issuer and serial number in the request,
the KDC is requested to use the referred-to certificate. If none
exists, then the KDC returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
other hand, the client does not pass any trustedCertifiers,
believing that it has the KDC's certificate, but the KDC has more
than one certificate. The KDC should include information in the
KRB-ERROR message that indicates the KDC certificate(s) that a
client may utilize. This data is specified in the e-typed-data
type as follows:
ETypedData ::= SEQUENCE {
e-data-type [1] INTEGER,
e-data-value [2] OCTET STRING,
} -- per Kerberos RFC 1510 revisions
where:
e-data-type = ETD-PKINIT-CMS-CERTIFICATES = 101
e-data-value = CertificateSet // as specified by CMS [11]
The PKAuthenticator carries information to foil replay attacks,
to bind the request and response. The PKAuthenticator is signed
with the private key corresponding to the public key in the
certificate found in userCert (or cached by the KDC).
The trustedCertifiers field contains a list of certification
authorities trusted by the client, in the case that the client does
not possess the KDC's public key certificate. If the KDC has no
certificate signed by any of the trustedCertifiers, then it returns
an error of type KDC_ERR_KDC_NOT_TRUSTED.
KDCs should try to (in order of preference):
1. Use the KDC certificate identified by the serialNumber included
in the client's request.
2. Use a certificate issued to the KDC by the client's CA (if in the
middle of a CA key roll-over, use the KDC cert issued under same
CA key as user cert used to verify request).
3. Use a certificate issued to the KDC by one of the client's
trustedCertifier(s);
If the KDC is unable to comply with any of these options, then the
KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
client.
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type, the KDC attempts to verify the user's certificate chain
(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 verification of the user's certificate fails, the KDC sends back
an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data
field contains additional information pertaining to this error, and
is formatted as follows:
METHOD-DATA ::= SEQUENCE {
method-type [0] INTEGER,
-- 0 = not specified
-- 1 = cannot verify public key
-- 2 = invalid certificate
-- 3 = revoked certificate
-- 4 = invalid KDC name
-- 5 = client name mismatch
method-data [1] OCTET STRING OPTIONAL
} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
The values for the method-type and method-data fields are described
in Section 3.2.1.
If a trust relationship exists, the KDC then verifies the client's
signature on AuthPack. If that fails, the KDC returns an error
message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
timestamp (ctime and cusec) in the PKAuthenticator to assure that
the request is not a replay. The KDC also verifies that its name
is specified in the PKAuthenticator.
If the clientPublicValue field is filled in, indicating that the
client wishes to use Diffie-Hellman key agreement, then the KDC
checks to see that the parameters satisfy its policy. If they do
not (e.g., the prime size is insufficient for the expected
encryption type), then the KDC sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
private values for the response.
The KDC also checks that the timestamp in the PKAuthenticator is
within the allowable window and that the principal name and realm
are correct. If the local (server) time and the client time in the
authenticator differ by more than the allowable clock skew, then the
KDC returns an error message of type KRB_AP_ERR_SKEW. If the
principal name or realm do not match the KDC, then the KDC returns
an error message of type KDC_ERR_NAME_MISMATCH for which the
e-typed-data may contain the correct name to use
(EDT-KRB-PRINCIPAL=102 or EDT-KRB-REALM=103 where
e-data-value = PrincipalName or Realm as defined by RFC 1510).
Assuming no errors, the KDC replies as per RFC 1510, except as
follows. The user's name in the ticket is determined by the
following decision algorithm:
1. If the KDC has a mapping from the name in the certificate
to a Kerberos name, then use that name.
Else
2. If the certificate contains a Kerberos name in an extension
field, and local KDC policy allows, then use that name.
Else
3. Use the name as represented in the certificate, mapping
as necessary (e.g., as per RFC 2253 for X.500 names). In
this case the realm in the ticket shall be the name of the
certification authority that issued the user's certificate.
The KDC encrypts the reply not with the user's long-term key, but
with a random key generated only for this particular response. This
random key is sealed in the preauthentication field:
PA-PK-AS-REP ::= CHOICE {
-- PA TYPE 15
dhSignedData [0] SignedData,
-- Defined in CMS and used only with
-- Diffie-Helman key exchange
encKeyPack [1] EnvelopedData,
-- Defined in CMS
-- The temporary key is encrypted
-- using the client public key
-- key
-- SignedReplyKeyPack, encrypted
-- with the temporary key, is also
-- included.
}
Usage of SignedData:
If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
provides authenticated Diffie-Hellman parameters of the KDC. The
reply key used to encrypt part of the KDC reply message is derived
from the Diffie-Hellman exchange:
- Both the KDC and the client calculate a secret value (g^ab mod p),
where a is the client's private exponent and b is the KDC's
private exponent.
- Both the KDC and the client take the first N bits of this secret
value and convert it into a reply key. N depends on the reply key
type.
- If the reply key is DES, N=64 bits, where some of the bits are
replaced with parity bits, according to FIPS PUB 74.
- If the reply key is (3-key) 3-DES, N=192 bits, where some of the
bits are replaced with parity bits, according to FIPS PUB 74.
- The encapContentInfo field must contain the KdcDHKeyInfo as
defined below.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1)
- The certificates field must contain the certificates necessary
for the client to establish trust in the KDC's certificate
based on the list of trusted certifiers sent by the client in
the PA-PK-AS-REQ. This field may be empty if the client did
not send to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the client
already possesses the KDC's certificate).
- The signerInfos field is a SET that must contain at least one
member, since it contains the actual signature.
Usage of EnvelopedData:
The EnvelopedData data type is specified in the Cryptographic
Message Syntax, a product of the S/MIME working group of the IETF.
It contains an temporary key encrypted with the PKINIT
client's public key. It also contains a signed and encrypted
reply key.
- The originatorInfo field is not required, since that information
may be presented in the signedData structure that is encrypted
within the encryptedContentInfo field.
- The optional unprotectedAttrs field is not required for PKINIT.
- The recipientInfos field is a SET which must contain exactly one
member of the KeyTransRecipientInfo type for encryption
with an RSA public key.
- The encryptedKey field (in KeyTransRecipientInfo) contains
the temporary key which is encrypted with the PKINIT client's
public key.
- The encryptedContentInfo field contains the signed and encrypted
reply key.
- The contentType field shall contain the OID value for
id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) signedData(2)
- The encryptedContent field is encrypted data of the CMS type
signedData as specified below.
- The encapContentInfo field must contains the ReplyKeyPack.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1)
- The eContent field is data of the type ReplyKeyPack (below).
- The certificates field must contain the certificates necessary
for the client to establish trust in the KDC's certificate
based on the list of trusted certifiers sent by the client in
the PA-PK-AS-REQ. This field may be empty if the client did
not send to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the client
already possesses the KDC's certificate).
- The signerInfos field is a SET that must contain at least one
member, since it contains the actual signature.
KdcDHKeyInfo ::= SEQUENCE {
-- used only when utilizing Diffie-Hellman
nonce [0] INTEGER,
-- binds responce to the request
subjectPublicKey [2] BIT STRING
-- Equals public exponent (g^a mod p)
-- INTEGER encoded as payload of
-- BIT STRING
}
ReplyKeyPack ::= SEQUENCE {
-- not used for Diffie-Hellman
replyKey [0] EncryptionKey,
-- used to encrypt main reply
-- ENCTYPE is at least as strong as
-- ENCTYPE of session key
nonce [1] INTEGER,
-- binds response to the request
-- must be same as the nonce
-- passed in the PKAuthenticator
}
Since each certifier in the certification path of a user's
certificate is essentially a separate realm, the name of each
certifier must be added to the transited field of the ticket. The
format of these realm names is defined in Section 3.1 of this
document. If applicable, the transit-policy-checked flag should be
set in the issued ticket.
The KDC's certificate must bind the public key to a name derivable
from the name of the realm for that KDC. X.509 certificates shall
contain the principal name of the KDC as the SubjectAltName version
3 extension. Below is the definition of this version 3 extension, as
specified by the X.509 standard:
subjectAltName EXTENSION ::= {
SYNTAX GeneralNames
IDENTIFIED BY id-ce-subjectAltName
}
GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
...
}
OTHER-NAME ::= TYPE-IDENTIFIER
In this definition, otherName is a name of any form defined as an
instance of the OTHER-NAME information object class. For the purpose
of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
be replaced by the type KerberosPrincipalName:
KerberosPrincipalName ::= SEQUENCE {
nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ),
name [1] OTHER-NAME.&type ( { PrincipalNameTypes }
{ @nameType } )
}
PrincipalNameTypes OTHER-NAME ::= {
{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
}
PrincipalNameSrvInst ::= GeneralString
where (from the Kerberos specification) we have
krb5 OBJECT IDENTIFIER ::= { iso (1)
org (3)
dod (6)
internet (1)
security (5)
kerberosv5 (2) }
principalName OBJECT IDENTIFIER ::= { krb5 2 }
principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
(This specification can also be used to specify a Kerberos name
within the user's certificate.)
The client then extracts the random key used to encrypt the main
reply. This random key (in 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.
3.2.1. Additional Information for Errors
This section describes the interpretation of the method-type and
method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
If method-type=1, the client's public key certificate chain does not
contain a certificate that is signed by a certification authority
trusted by the KDC. The format of the method-data field will be an
ASN.1 encoding of a list of trusted certifiers, as defined above:
TrustedCertifiers ::= SEQUENCE OF PrincipalName
If method-type=2, the signature on one of the certificates in the
chain cannot be verified. The format of the method-data field will
be an ASN.1 encoding of the integer index of the certificate in
question:
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- 1 = 2nd certificate, etc
If method-type=3, one of the certificates in the chain has been
revoked. The format of the method-data field will be an ASN.1
encoding of the integer index of the certificate in question:
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- 1 = 2nd certificate, etc
If method-type=4, the KDC name or realm in the PKAuthenticator does
not match the principal name of the KDC. There is no method-data
field in this case.
If method-type=5, the client name or realm in the certificate does
not match the principal name of the client. There is no
method-data field in this case.
3.2.2. Required Algorithms
Not all of the algorithms in the PKINIT protocol specification have
to be implemented in order to comply with the proposed standard.
Below is a list of the required algorithms:
- Diffie-Hellman public/private key pairs
- SHA1 digest and DSA for signatures
- 3-key triple DES keys derived from the Diffie-Hellman Exchange
- 3-key triple DES Temporary and Reply keys
4. Logistics and Policy
This section describes a way to define the policy on the use of
PKINIT for each principal and request.
The KDC is not required to contain a database record for users
that use either the Standard Public Key Authentication. However,
if these users are registered with the KDC, it is recommended that
the database record for these users be modified to an additional
flag in the attributes field to indicate that the user should
authenticate using PKINIT. If this flag is set and a request
message does not contain the PKINIT preauthentication field, then
the KDC sends back as error of type KDC_ERR_PREAUTH_REQUIRED
indicating that a preauthentication field of type PA-PK-AS-REQ must
be included in the request.
5. Security Considerations
PKINIT raises a few security considerations, which we will address
in this section.
First of all, PKINIT introduces a new trust model, where KDCs do not
(necessarily) certify the identity of those for whom they issue
tickets. PKINIT does allow KDCs to act as their own CAs, in order
to simplify key management, but one of the additional benefits is to
align Kerberos authentication with a global public key
infrastructure. Anyone using PKINIT in this way must be aware of
how the certification infrastructure they are linking to works.
Secondly, PKINIT also introduces the possibility of interactions
between different cryptosystems, which may be of widely varying
strengths. Many systems, for instance, allow the use of 512-bit
public keys. Using such keys to wrap data encrypted under strong
conventional cryptosystems, such as triple-DES, is inappropriate;
it adds a weak link to a strong one at extra cost. Implementors
and administrators should take care to avoid such wasteful and
deceptive interactions.
Lastly, PKINIT calls for randomly generated keys for conventional
cryptosystems. Many such systems contain systematically "weak"
keys. PKINIT implementations MUST avoid use of these keys, either
by discarding those keys when they are generated, or by fixing them
in some way (e.g., by XORing them with a given mask). These
precautions vary from system to system; it is not our intention to
give an explicit recipe for them here.
6. Transport Issues
Certificate chains can potentially grow quite large and span several
UDP packets; this in turn increases the probability that a Kerberos
message involving PKINIT extensions will be broken in transit. In
light of the possibility that the Kerberos specification will
require KDCs to accept requests using TCP as a transport mechanism,
we make the same recommendation with respect to the PKINIT
extensions as well.
7. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
Authentication in Kerberos.
draft-ietf-cat-kerberos-pk-cross-04.txt
[4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
Kerberos.
draft-ietf-cat-kerberos-anoncred-00.txt
[5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt
[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed
System Security, 1997.
[7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic
Commerce, July 1995.
[8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
Request for Comments 2246, January 1999.
[9] B.C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems. In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993.
[10] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
[11] R. Housley. Cryptographic Message Syntax.
draft-ietf-smime-cms-10.txt, December 1998.
[12] PKCS #7: Cryptographic Message Syntax Standard,
An RSA Laboratories Technical Note Version 1.5
Revised November 1, 1993
[13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
Security, Inc. A Description of the RC2(r) Encryption Algorithm
March 1998.
Request for Comments 2268.
[14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names.
Request for Comments 2253.
8. Acknowledgements
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 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.
9. Expiration Date
This draft expires November 12, 1999.
10. Authors
Brian Tung
Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {brian, bcn}@isi.edu
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road
Issaquah WA 98027-5378
Phone: +1 425 391 6000
E-mail: matt.hur@cybersafe.com
Ari Medvinsky
Excite
555 Broadway
Redwood City, CA 94063
Phone +1 650 569 2119
E-mail: amedvins@excitecorp.com
Sasha Medvinsky
General Instrument
6450 Sequence Drive
San Diego, CA 92121
Phone +1 619 404 2825
E-mail: smedvinsky@gi.com
John Wray
Iris Associates, Inc.
5 Technology Park Dr.
Westford, MA 01886
E-mail: John_Wray@iris.com
Jonathan Trostle
170 W. Tasman Dr.
San Jose, CA 95134
E-mail: jtrostle@cisco.com

908
doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt Normal file
View File

@@ -0,0 +1,908 @@
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-09.txt Clifford Neuman
Updates: RFC 1510 ISI
expires December 1, 1999 Matthew Hur
CyberSafe Corporation
Ari Medvinsky
Excite
Sasha Medvinsky
General Instrument
John Wray
Iris Associates, Inc.
Jonathan Trostle
Cisco
Public Key Cryptography for Initial Authentication in Kerberos
0. Status Of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.ietf.org (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-09.txt, and expires December 1,
1999. Please send comments to the authors.
1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
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.
2. Introduction
The popularity of public key cryptography has produced a desire for
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.
Public key cryptography can be integrated into Kerberos in a number
of ways. One is to associate a key pair with each realm, which can
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.
PKINIT utilizes Diffie-Hellman keys in combination with digital
signature keys as the primary, required mechanism. It also allows
for the use of RSA keys. Note that PKINIT supports the use of
separate signature and encryption keys.
PKINIT enables access to Kerberos-secured services based on initial
authentication utilizing public key cryptography. PKINIT utilizes
standard public key signature and encryption data formats within the
standard Kerberos messages. The basic mechanism is as follows: The
user sends a request to the KDC as before, except that if that user
is to use public key cryptography in the initial authentication
step, his certificate and a signature accompany the initial request
in the preauthentication fields. Upon receipt of this request, the
KDC verifies the certificate and issues a ticket granting ticket
(TGT) as before, except that the encPart from the AS-REP message
carrying the TGT is now encrypted utilizing either a Diffie-Hellman
derived key or the user's public key. This message is authenticated
utilizing the public key signature of the KDC.
The PKINIT specification may also be used as a building block for
other specifications. PKCROSS [3] utilizes PKINIT for establishing
the inter-realm key and associated inter-realm policy to be applied
in issuing cross realm service tickets. As specified in [4],
anonymous Kerberos tickets can be issued by applying a NULL
signature in combination with Diffie-Hellman in the PKINIT exchange.
Additionally, the PKINIT specification may be used for direct peer
to peer authentication without contacting a central KDC. This
application of PKINIT is described in PKTAPP [5] and is based on
concepts introduced in [6, 7]. 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 TLS [8] 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 [9]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following change to RFC 1510 is proposed:
* Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity. The user presents
a public key certificate and obtains an ordinary TGT that may
be used for subsequent authentication, with such
authentication using only conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 describes the extensions for the initial authentication
method.
3.1. Definitions
The extensions involve new preauthentication fields; we introduce
the following preauthentication types:
PA-PK-AS-REQ 14
PA-PK-AS-REP 15
The extensions also involve new error types; we introduce the
following types:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_TOO_WEAK 65
KDC_ERR_CERTIFICATE_MISMATCH 66
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74
KDC_ERR_CLIENT_NAME_MISMATCH 75
KDC_ERR_KDC_NAME_MISMATCH 76
We utilize the following typed data for errors:
TD-PKINIT-CMS-CERTIFICATES 101
TD-KRB-PRINCIPAL 102
TD-KRB-REALM 103
TD-TRUSTED-CERTIFIERS 104
TD-CERTIFICATE-INDEX 105
We utilize the following encryption types (which map directly to
OIDs):
dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID (PKCS#1 v1.5) 13
rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14
des-ede3-cbc-Env-OID 15
These mappings are provided so that a client may send the
appropriate enctypes in the AS-REQ message in order to indicate
support for the corresponding OIDs (for performing PKINIT).
In many cases, PKINIT requires the encoding of an X.500 name as a
Realm. In these cases, the realm will be represented using a
different style, specified in RFC 1510 with the following example:
NAMETYPE:rest/of.name=without-restrictions
For a realm derived from an X.500 name, NAMETYPE will have the value
X500-RFC2253. The full realm name will appear as follows:
X500-RFC2253:RFC2253Encode(DistinguishedName)
where DistinguishedName is an X.500 name, and RFC2253Encode is a
readable UTF encoding of an X.500 name, as defined by
RFC 2253 [14] (part of LDAPv3).
To ensure that this encoding is unique, we add the following rule
to those specified by RFC 2253:
The order in which the attributes appear in the RFC 2253
encoding must be the reverse of the order in the ASN.1
encoding of the X.500 name that appears in the public key
certificate. The order of the relative distinguished names
(RDNs), as well as the order of the AttributeTypeAndValues
within each RDN, will be reversed. (This is despite the fact
that an RDN is defined as a SET of AttributeTypeAndValues, where
an order is normally not important.)
Similarly, PKINIT may require the encoding of an X.500 name as a
PrincipalName. In these cases, the name-type of the principal name
shall be set to KRB_NT-X500-PRINCIPAL. This new name type is
defined as:
KRB_NT_X500_PRINCIPAL 6
The name-string shall be set as follows:
RFC2253Encode(DistinguishedName)
as described above.
RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
PrincipalName ::= SEQUENCE {
name-type[0] INTEGER,
name-string[1] SEQUENCE OF GeneralString
}
For the purposes of encoding an X.500 name within this structure,
the name-string shall be encoded as a single GeneralString.
Note that name mapping may be required or optional based on
policy.
3.1.1. Encryption and Key Formats
In the exposition below, we use the terms public key and private
key generically. It should be understood that the term "public
key" may be used to refer to either a public encryption key or a
signature verification key, and that the term "private key" may be
used to refer to either a private decryption key or a signature
generation key. The fact that these are logically distinct does
not preclude the assignment of bitwise identical keys.
In the case of Diffie-Hellman, the key shall be produced from the
agreed bit string as follows:
* Truncate the bit string to the appropriate length.
* Rectify parity in each byte (if necessary) to obtain the key.
For instance, in the case of a DES key, we take the first eight
bytes of the bit stream, and then adjust the least significant bit
of each byte to ensure that each byte has odd parity.
3.1.2. Algorithm Identifiers
PKINIT does not define, but does permit, the algorithm identifiers
listed below.
3.1.2.1. Signature Algorithm Identifiers
The following signature algorithm identifiers specified in [11] and
in [15] shall be used with PKINIT:
id-dsa-with-sha1 (DSA with SHA1)
md5WithRSAEncryption (RSA with MD5)
sha-1WithRSAEncryption (RSA with SHA1)
3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
The following algorithm identifier shall be used within the
SubjectPublicKeyInfo data structure: dhpublicnumber
This identifier and the associated algorithm parameters are
specified in RFC 2459 [15].
3.1.2.3. Algorithm Identifiers for RSA Encryption
These algorithm identifiers are used inside the EnvelopedData data
structure, for encrypting the temporary key with a public key:
rsaEncryption (RSA encryption, PKCS#1 v1.5)
id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
Both of the above RSA encryption schemes are specified in [16].
Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
CMS specification says that it will likely include PKCS#1 v2.0 in
the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext
vulnerability discovered in PKCS#1 v1.5.)
3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
These algorithm identifiers are used inside the EnvelopedData data
structure in the PKINIT Reply, for encrypting the reply key with the
temporary key:
des-ede3-cbc (3-key 3-DES, CBC mode)
rc2-cbc (RC2, CBC mode)
The full definition of the above algorithm identifiers and their
corresponding parameters (an IV for block chaining) is provided in
the CMS specification [11].
3.2. Public Key Authentication
Implementation of the changes in this section is REQUIRED for
compliance with PKINIT.
It is assumed that all public keys are signed by some certification
authority (CA). The initial authentication request is sent as per
RFC 1510, except that a preauthentication field containing data
signed by the user's private key accompanies the request:
PA-PK-AS-REQ ::= SEQUENCE {
-- PA TYPE 14
signedAuthPack [0] SignedData
-- defined in CMS [11]
-- AuthPack (below) defines the data
-- that is signed
trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
-- CAs that the client trusts
kdcCert [2] IssuerAndSerialNumber OPTIONAL
-- as defined in CMS [11]
-- specifies a particular KDC
-- certificate if the client
-- already has it;
-- must be accompanied by
-- a single trustedCertifier
encryptionCert [3] IssuerAndSerialNumber OPTIONAL
-- For example, this may be the
-- client's Diffie-Hellman
-- certificate, or it may be the
-- client's RSA encryption
-- certificate.
}
TrustedCas ::= CHOICE {
principalName [0] KerberosName,
-- as defined below
caName [1] Name
-- fully qualified X.500 name
-- as defined by X.509
issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL
-- Since a CA may have a number of
-- certificates, only one of which
-- a client trusts
}
Usage of SignedData:
The SignedData data type is specified in the Cryptographic
Message Syntax, a product of the S/MIME working group of the IETF.
- The encapContentInfo field must contain the PKAuthenticator
and, optionally, the client's Diffie Hellman public value.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1)
- The eContent field is data of the type AuthPack (below).
- The signerInfos field contains the signature of AuthPack.
- The Certificates field, when non-empty, contains the client's
certificate chain. If present, the KDC uses the public key from
the client's certificate to verify the signature in the request.
Note that the client may pass different certificates that are used
for signing or for encrypting. Thus, the KDC may utilize a
different client certificate for signature verification than the
one it uses to encrypt the reply to the client. For example, the
client may place a Diffie-Hellman certificate in this field in
order to convey its static Diffie Hellman certificate to the KDC
enable static-ephemeral Diffie-Hellman mode for the reply. As
another example, the client may place an RSA encryption
certificate in this field.
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- if client is using Diffie-Hellman
}
PKAuthenticator ::= SEQUENCE {
kdcName [0] PrincipalName,
kdcRealm [1] Realm,
cusec [2] INTEGER,
-- for replay prevention
ctime [3] KerberosTime,
-- for replay prevention
nonce [4] INTEGER
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
-- dhKeyAgreement
subjectPublicKey BIT STRING
-- for DH, equals
-- public exponent (INTEGER encoded
-- as payload of BIT STRING)
} -- as specified by the X.509 recommendation [10]
AlgorithmIdentifier ::= SEQUENCE {
algorithm ALGORITHM.&id,
parameters ALGORITHM.&type
} -- as specified by the X.509 recommendation [10]
If the client passes an issuer and serial number in the request,
the KDC is requested to use the referred-to certificate. If none
exists, then the KDC returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
other hand, the client does not pass any trustedCertifiers,
believing that it has the KDC's certificate, but the KDC has more
than one certificate. The KDC should include information in the
KRB-ERROR message that indicates the KDC certificate(s) that a
client may utilize. This data is specified in the e-data, which
is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
TypedData ::= SEQUENCE {
data-type [0] INTEGER,
data-value [1] OCTET STRING,
} -- per Kerberos RFC 1510 revisions
where:
data-type = TD-PKINIT-CMS-CERTIFICATES = 101
data-value = CertificateSet // as specified by CMS [11]
The PKAuthenticator carries information to foil replay attacks,
to bind the request and response. The PKAuthenticator is signed
with the private key corresponding to the public key in the
certificate found in userCert (or cached by the KDC).
The trustedCertifiers field contains a list of certification
authorities trusted by the client, in the case that the client does
not possess the KDC's public key certificate. If the KDC has no
certificate signed by any of the trustedCertifiers, then it returns
an error of type KDC_ERR_KDC_NOT_TRUSTED.
KDCs should try to (in order of preference):
1. Use the KDC certificate identified by the serialNumber included
in the client's request.
2. Use a certificate issued to the KDC by the client's CA (if in the
middle of a CA key roll-over, use the KDC cert issued under same
CA key as user cert used to verify request).
3. Use a certificate issued to the KDC by one of the client's
trustedCertifier(s);
If the KDC is unable to comply with any of these options, then the
KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
client.
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type, the KDC attempts to verify the user's certificate chain
(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 client's certificate chain contains no certificate signed by
a CA trusted by the KDC, then the KDC sends back an error message
of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data
is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
whose data-value is an OCTET STRING which is the DER encoding of
TrustedCertifiers ::= SEQUENCE OF PrincipalName
-- X.500 name encoded as a principal name
-- see Section 3.1
If the signature on one of the certificates in the client's chain
fails verification, then the KDC returns an error of type
KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE
of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose
data-value is an OCTET STRING which is the DER encoding of
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- (in order of encoding)
-- 1 = 2nd certificate, etc
The KDC may also check whether any of the certificates in the
client's chain has been revoked. If one of the certificates has
been revoked, then the KDC returns an error of type
KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the
certificate's revocation status is unknown, the KDC returns an
error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation
status is unavailable, the KDC returns an error of type
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
cases, the affected certificate is identified by the accompanying
e-data, which contains a CertificateIndex as described for
KDC_ERR_INVALID_CERTIFICATE.
If the certificate chain can be verified, but the name of the
client in the certificate does not match the client's name in the
request, then the KDC returns an error of type
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
field in this case.
Finally, if the certificate chain is verified, but the KDC's name
or realm as given in the PKAuthenticator does not match the KDC's
actual principal name, then the KDC returns an error of type
KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again
a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
STRING whose data-value is the DER encoding of a PrincipalName or
Realm as defined in RFC 1510 revisions.
Even if all succeeds, the KDC may--for policy reasons--decide not
to trust the client. In this case, the KDC returns an error message
of type KDC_ERR_CLIENT_NOT_TRUSTED.
If a trust relationship exists, the KDC then verifies the client's
signature on AuthPack. If that fails, the KDC returns an error
message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
timestamp (ctime and cusec) in the PKAuthenticator to assure that
the request is not a replay. The KDC also verifies that its name
is specified in the PKAuthenticator.
If the clientPublicValue field is filled in, indicating that the
client wishes to use Diffie-Hellman key agreement, then the KDC
checks to see that the parameters satisfy its policy. If they do
not (e.g., the prime size is insufficient for the expected
encryption type), then the KDC sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
private values for the response.
The KDC also checks that the timestamp in the PKAuthenticator is
within the allowable window and that the principal name and realm
are correct. If the local (server) time and the client time in the
authenticator differ by more than the allowable clock skew, then the
KDC returns an error message of type KRB_AP_ERR_SKEW.
Assuming no errors, the KDC replies as per RFC 1510, except as
follows. The user's name in the ticket is determined by the
following decision algorithm:
1. If the KDC has a mapping from the name in the certificate
to a Kerberos name, then use that name.
Else
2. If the certificate contains a Kerberos name in an extension
field, and local KDC policy allows, then use that name.
Else
3. Use the name as represented in the certificate, mapping
as necessary (e.g., as per RFC 2253 for X.500 names). In
this case the realm in the ticket shall be the name of the
certification authority that issued the user's certificate.
The KDC encrypts the reply not with the user's long-term key, but
with a random key generated only for this particular response. This
random key is sealed in the preauthentication field:
PA-PK-AS-REP ::= CHOICE {
-- PA TYPE 15
dhSignedData [0] SignedData,
-- Defined in CMS and used only with
-- Diffie-Helman key exchange
-- This choice MUST be supported
-- by compliant implementations.
encKeyPack [1] EnvelopedData,
-- Defined in CMS
-- The temporary key is encrypted
-- using the client public key
-- key
-- SignedReplyKeyPack, encrypted
-- with the temporary key, is also
-- included.
}
Usage of SignedData:
If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
provides authenticated Diffie-Hellman parameters of the KDC. The
reply key used to encrypt part of the KDC reply message is derived
from the Diffie-Hellman exchange:
- Both the KDC and the client calculate a secret value (g^ab mod p),
where a is the client's private exponent and b is the KDC's
private exponent.
- Both the KDC and the client take the first N bits of this secret
value and convert it into a reply key. N depends on the reply key
type.
- If the reply key is DES, N=64 bits, where some of the bits are
replaced with parity bits, according to FIPS PUB 74.
- If the reply key is (3-key) 3-DES, N=192 bits, where some of the
bits are replaced with parity bits, according to FIPS PUB 74.
- The encapContentInfo field must contain the KdcDHKeyInfo as
defined below.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1)
- The certificates field must contain the certificates necessary
for the client to establish trust in the KDC's certificate
based on the list of trusted certifiers sent by the client in
the PA-PK-AS-REQ. This field may be empty if the client did
not send to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the client
already possesses the KDC's certificate).
- The signerInfos field is a SET that must contain at least one
member, since it contains the actual signature.
Usage of EnvelopedData:
The EnvelopedData data type is specified in the Cryptographic
Message Syntax, a product of the S/MIME working group of the IETF.
It contains an temporary key encrypted with the PKINIT
client's public key. It also contains a signed and encrypted
reply key.
- The originatorInfo field is not required, since that information
may be presented in the signedData structure that is encrypted
within the encryptedContentInfo field.
- The optional unprotectedAttrs field is not required for PKINIT.
- The recipientInfos field is a SET which must contain exactly one
member of the KeyTransRecipientInfo type for encryption
with an RSA public key.
- The encryptedKey field (in KeyTransRecipientInfo) contains
the temporary key which is encrypted with the PKINIT client's
public key.
- The encryptedContentInfo field contains the signed and encrypted
reply key.
- The contentType field shall contain the OID value for
id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) signedData(2)
- The encryptedContent field is encrypted data of the CMS type
signedData as specified below.
- The encapContentInfo field must contains the ReplyKeyPack.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1)
- The eContent field is data of the type ReplyKeyPack (below).
- The certificates field must contain the certificates necessary
for the client to establish trust in the KDC's certificate
based on the list of trusted certifiers sent by the client in
the PA-PK-AS-REQ. This field may be empty if the client did
not send to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the client
already possesses the KDC's certificate).
- The signerInfos field is a SET that must contain at least one
member, since it contains the actual signature.
KdcDHKeyInfo ::= SEQUENCE {
-- used only when utilizing Diffie-Hellman
nonce [0] INTEGER,
-- binds responce to the request
subjectPublicKey [2] BIT STRING
-- Equals public exponent (g^a mod p)
-- INTEGER encoded as payload of
-- BIT STRING
}
ReplyKeyPack ::= SEQUENCE {
-- not used for Diffie-Hellman
replyKey [0] EncryptionKey,
-- used to encrypt main reply
-- ENCTYPE is at least as strong as
-- ENCTYPE of session key
nonce [1] INTEGER,
-- binds response to the request
-- must be same as the nonce
-- passed in the PKAuthenticator
}
Since each certifier in the certification path of a user's
certificate is essentially a separate realm, the name of each
certifier must be added to the transited field of the ticket. The
format of these realm names is defined in Section 3.1 of this
document. If applicable, the transit-policy-checked flag should be
set in the issued ticket.
The KDC's certificate must bind the public key to a name derivable
from the name of the realm for that KDC. X.509 certificates shall
contain the principal name of the KDC as the SubjectAltName version
3 extension. Below is the definition of this version 3 extension, as
specified by the X.509 standard:
subjectAltName EXTENSION ::= {
SYNTAX GeneralNames
IDENTIFIED BY id-ce-subjectAltName
}
GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
...
}
OTHER-NAME ::= TYPE-IDENTIFIER
In this definition, otherName is a name of any form defined as an
instance of the OTHER-NAME information object class. For the purpose
of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
be chosen and replaced by the type KerberosName:
KerberosName ::= SEQUENCE {
realm [0] Realm,
-- as define in RFC 1510
principalName [1] PrincipalName,
-- as define in RFC 1510
}
This specific syntax is identified within subjectAltName by setting
the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
Kerberos specification) we have
krb5 OBJECT IDENTIFIER ::= { iso (1)
org (3)
dod (6)
internet (1)
security (5)
kerberosv5 (2) }
krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
This specification may also be used to specify a Kerberos name
within the user's certificate.
If a non-KDC X.509 certificate contains the principal name within
the subjectAltName version 3 extension , that name may utilize
KerberosName as defined below, or, in the case of an S/MIME
certificate [17], may utilize the email address. If the KDC
is presented with as S/MIME certificate, then the email address
within subjectAltName will be interpreted as a principal and realm
separated by the "@" sign, or as a name that needs to be
canonicalized. If the resulting name does not correspond to a
registered principal name, then the principal name is formed as
defined in section 3.1.
The client then extracts the random key used to encrypt the main
reply. This random key (in 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.
3.2.2. Required Algorithms
Not all of the algorithms in the PKINIT protocol specification have
to be implemented in order to comply with the proposed standard.
Below is a list of the required algorithms:
- Diffie-Hellman public/private key pairs
- utilizing Diffie-Hellman ephemeral-ephemeral mode
- SHA1 digest and DSA for signatures
- 3-key triple DES keys derived from the Diffie-Hellman Exchange
- 3-key triple DES Temporary and Reply keys
4. Logistics and Policy
This section describes a way to define the policy on the use of
PKINIT for each principal and request.
The KDC is not required to contain a database record for users
who use public key authentication. However, if these users are
registered with the KDC, it is recommended that the database record
for these users be modified to an additional flag in the attributes
field to indicate that the user should authenticate using PKINIT.
If this flag is set and a request message does not contain the
PKINIT preauthentication field, then the KDC sends back as error of
type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
field of type PA-PK-AS-REQ must be included in the request.
5. Security Considerations
PKINIT raises a few security considerations, which we will address
in this section.
First of all, PKINIT introduces a new trust model, where KDCs do not
(necessarily) certify the identity of those for whom they issue
tickets. PKINIT does allow KDCs to act as their own CAs, in order
to simplify key management, but one of the additional benefits is to
align Kerberos authentication with a global public key
infrastructure. Anyone using PKINIT in this way must be aware of
how the certification infrastructure they are linking to works.
Secondly, PKINIT also introduces the possibility of interactions
between different cryptosystems, which may be of widely varying
strengths. Many systems, for instance, allow the use of 512-bit
public keys. Using such keys to wrap data encrypted under strong
conventional cryptosystems, such as triple-DES, is inappropriate;
it adds a weak link to a strong one at extra cost. Implementors
and administrators should take care to avoid such wasteful and
deceptive interactions.
Lastly, PKINIT calls for randomly generated keys for conventional
cryptosystems. Many such systems contain systematically "weak"
keys. PKINIT implementations MUST avoid use of these keys, either
by discarding those keys when they are generated, or by fixing them
in some way (e.g., by XORing them with a given mask). These
precautions vary from system to system; it is not our intention to
give an explicit recipe for them here.
6. Transport Issues
Certificate chains can potentially grow quite large and span several
UDP packets; this in turn increases the probability that a Kerberos
message involving PKINIT extensions will be broken in transit. In
light of the possibility that the Kerberos specification will
require KDCs to accept requests using TCP as a transport mechanism,
we make the same recommendation with respect to the PKINIT
extensions as well.
7. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
Authentication in Kerberos.
draft-ietf-cat-kerberos-pk-cross-04.txt
[4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
Kerberos.
draft-ietf-cat-kerberos-anoncred-00.txt
[5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt
[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed
System Security, 1997.
[7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic
Commerce, July 1995.
[8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
Request for Comments 2246, January 1999.
[9] B.C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems. In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993.
[10] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
[11] R. Housley. Cryptographic Message Syntax.
draft-ietf-smime-cms-13.txt, April 1999.
[12] PKCS #7: Cryptographic Message Syntax Standard,
An RSA Laboratories Technical Note Version 1.5
Revised November 1, 1993
[13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
Security, Inc. A Description of the RC2(r) Encryption Algorithm
March 1998.
Request for Comments 2268.
[14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names.
Request for Comments 2253.
[15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
Key Infrastructure, Certificate and CRL Profile, January 1999.
Request for Comments 2459.
[16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
Specifications, October 1998.
Request for Comments 2437.
[17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.
S/MIME Version 2 Certificate Handling, March 1998.
Request for Comments 2312
8. Acknowledgements
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 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.
9. Expiration Date
This draft expires December 1, 1999.
10. Authors
Brian Tung
Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {brian, bcn}@isi.edu
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road
Issaquah WA 98027-5378
Phone: +1 425 391 6000
E-mail: matt.hur@cybersafe.com
Ari Medvinsky
Excite
555 Broadway
Redwood City, CA 94063
Phone +1 650 569 2119
E-mail: amedvins@excitecorp.com
Sasha Medvinsky
General Instrument
6450 Sequence Drive
San Diego, CA 92121
Phone +1 619 404 2825
E-mail: smedvinsky@gi.com
John Wray
Iris Associates, Inc.
5 Technology Park Dr.
Westford, MA 01886
E-mail: John_Wray@iris.com
Jonathan Trostle
170 W. Tasman Dr.
San Jose, CA 95134
E-mail: jtrostle@cisco.com

957
doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt Normal file
View File

@@ -0,0 +1,957 @@
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-10.txt Clifford Neuman
Updates: RFC 1510 ISI
expires April 30, 2000 Matthew Hur
CyberSafe Corporation
Ari Medvinsky
Excite
Sasha Medvinsky
General Instrument
John Wray
Iris Associates, Inc.
Jonathan Trostle
Cisco
Public Key Cryptography for Initial Authentication in Kerberos
0. Status Of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.ietf.org (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-10.txt, and expires April 30,
2000. Please send comments to the authors.
1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
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.
2. Introduction
The popularity of public key cryptography has produced a desire for
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.
Public key cryptography can be integrated into Kerberos in a number
of ways. One is to associate a key pair with each realm, which can
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.
PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
combination with digital signature keys as the primary, required
mechanism. It also allows for the use of RSA keys and/or (static)
Diffie-Hellman certificates. Note in particular that PKINIT supports
the use of separate signature and encryption keys.
PKINIT enables access to Kerberos-secured services based on initial
authentication utilizing public key cryptography. PKINIT utilizes
standard public key signature and encryption data formats within the
standard Kerberos messages. The basic mechanism is as follows: The
user sends an AS-REQ message to the KDC as before, except that if that
user is to use public key cryptography in the initial authentication
step, his certificate and a signature accompany the initial request
in the preauthentication fields. Upon receipt of this request, the
KDC verifies the certificate and issues a ticket granting ticket
(TGT) as before, except that the encPart from the AS-REP message
carrying the TGT is now encrypted utilizing either a Diffie-Hellman
derived key or the user's public key. This message is authenticated
utilizing the public key signature of the KDC.
Note that PKINIT does not require the use of certificates. A KDC
may store the public key of a principal as part of that principal's
record. In this scenario, the KDC is the trusted party that vouches
for the principal (as in a standard, non-cross realm, Kerberos
environment). Thus, for any principal, the KDC may maintain a
secret key, a public key, or both.
The PKINIT specification may also be used as a building block for
other specifications. PKCROSS [3] utilizes PKINIT for establishing
the inter-realm key and associated inter-realm policy to be applied
in issuing cross realm service tickets. As specified in [4],
anonymous Kerberos tickets can be issued by applying a NULL
signature in combination with Diffie-Hellman in the PKINIT exchange.
Additionally, the PKINIT specification may be used for direct peer
to peer authentication without contacting a central KDC. This
application of PKINIT is described in PKTAPP [5] and is based on
concepts introduced in [6, 7]. 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 TLS [8] 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 [9]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following change to RFC 1510 is proposed:
* Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity. The user presents
a public key certificate and obtains an ordinary TGT that may
be used for subsequent authentication, with such
authentication using only conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 describes the extensions for the initial authentication
method.
3.1. Definitions
The extensions involve new preauthentication fields; we introduce
the following preauthentication types:
PA-PK-AS-REQ 14
PA-PK-AS-REP 15
The extensions also involve new error types; we introduce the
following types:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_TOO_WEAK 65
KDC_ERR_CERTIFICATE_MISMATCH 66
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74
KDC_ERR_CLIENT_NAME_MISMATCH 75
KDC_ERR_KDC_NAME_MISMATCH 76
We utilize the following typed data for errors:
TD-PKINIT-CMS-CERTIFICATES 101
TD-KRB-PRINCIPAL 102
TD-KRB-REALM 103
TD-TRUSTED-CERTIFIERS 104
TD-CERTIFICATE-INDEX 105
We utilize the following encryption types (which map directly to
OIDs):
dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID (PKCS#1 v1.5) 13
rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14
des-ede3-cbc-Env-OID 15
These mappings are provided so that a client may send the
appropriate enctypes in the AS-REQ message in order to indicate
support for the corresponding OIDs (for performing PKINIT).
In many cases, PKINIT requires the encoding of the X.500 name of a
certificate authority as a Realm. When such a name appears as
a ream it will be represented using the "other" form of the realm
name as specified in the naming constraints section of RFC1510.
For a realm derived from an X.500 name, NAMETYPE will have the value
X500-RFC2253. The full realm name will appear as follows:
<nametype> + ":" + <string>
where nametype is "X500-RFC2253" and string is the result of doing
an RFC2253 encoding of the distinguished name, i.e.
"X500-RFC2253:" + RFC2253Encode(DistinguishedName)
where DistinguishedName is an X.500 name, and RFC2253Encode is a
function returing a readable UTF encoding of an X.500 name, as
defined by RFC 2253 [14] (part of LDAPv3 [18]).
To ensure that this encoding is unique, we add the following rule
to those specified by RFC 2253:
The order in which the attributes appear in the RFC 2253
encoding must be the reverse of the order in the ASN.1
encoding of the X.500 name that appears in the public key
certificate. The order of the relative distinguished names
(RDNs), as well as the order of the AttributeTypeAndValues
within each RDN, will be reversed. (This is despite the fact
that an RDN is defined as a SET of AttributeTypeAndValues, where
an order is normally not important.)
Similarly, in cases where the KDC does not provide a specific
policy based mapping from the X.500 name or X.509 Version 3
SubjectAltName extension in the user's certificate to a Kerberos
principal name, PKINIT requires the direct encoding of the X.500
name as a PrincipalName. In this case, the name-type of the
principal name shall be set to KRB_NT-X500-PRINCIPAL. This new
name type is defined in RFC 1510 as:
KRB_NT_X500_PRINCIPAL 6
The name-string shall be set as follows:
RFC2253Encode(DistinguishedName)
as described above. When this name type is used, the principal's
realm shall be set to the certificate authority's distinguished
name using the X500-RFC2253 realm name format described earlier in
this section
RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
PrincipalName ::= SEQUENCE {
name-type[0] INTEGER,
name-string[1] SEQUENCE OF GeneralString
}
For the purposes of encoding an X.500 name within this structure,
the name-string shall be encoded as a single GeneralString.
Note that name mapping may be required or optional based on
policy. All names must conform to validity requirements as given
in RFC 1510.
3.1.1. Encryption and Key Formats
In the exposition below, we use the terms public key and private
key generically. It should be understood that the term "public
key" may be used to refer to either a public encryption key or a
signature verification key, and that the term "private key" may be
used to refer to either a private decryption key or a signature
generation key. The fact that these are logically distinct does
not preclude the assignment of bitwise identical keys for RSA
keys.
In the case of Diffie-Hellman, the key shall be produced from the
agreed bit string as follows:
* Truncate the bit string to the appropriate length.
* Rectify parity in each byte (if necessary) to obtain the key.
For instance, in the case of a DES key, we take the first eight
bytes of the bit stream, and then adjust the least significant bit
of each byte to ensure that each byte has odd parity.
3.1.2. Algorithm Identifiers
PKINIT does not define, but does permit, the algorithm identifiers
listed below.
3.1.2.1. Signature Algorithm Identifiers
The following signature algorithm identifiers specified in [11] and
in [15] shall be used with PKINIT:
id-dsa-with-sha1 (DSA with SHA1)
md5WithRSAEncryption (RSA with MD5)
sha-1WithRSAEncryption (RSA with SHA1)
3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
The following algorithm identifier shall be used within the
SubjectPublicKeyInfo data structure: dhpublicnumber
This identifier and the associated algorithm parameters are
specified in RFC 2459 [15].
3.1.2.3. Algorithm Identifiers for RSA Encryption
These algorithm identifiers are used inside the EnvelopedData data
structure, for encrypting the temporary key with a public key:
rsaEncryption (RSA encryption, PKCS#1 v1.5)
id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
Both of the above RSA encryption schemes are specified in [16].
Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
CMS specification says that it will likely include PKCS#1 v2.0 in
the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext
vulnerability discovered in PKCS#1 v1.5.)
3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
These algorithm identifiers are used inside the EnvelopedData data
structure in the PKINIT Reply, for encrypting the reply key with the
temporary key:
des-ede3-cbc (3-key 3-DES, CBC mode)
rc2-cbc (RC2, CBC mode)
The full definition of the above algorithm identifiers and their
corresponding parameters (an IV for block chaining) is provided in
the CMS specification [11].
3.2. Public Key Authentication
Implementation of the changes in this section is REQUIRED for
compliance with PKINIT.
3.2.1. Client Request
Public keys may be signed by some certification authority (CA), or
they may be maintained by the KDC in which case the KDC is the
trusted authority. Note that the latter mode does not require the
use of certificates.
The initial authentication request is sent as per RFC 1510, except
that a preauthentication field containing data signed by the user's
private key accompanies the request:
PA-PK-AS-REQ ::= SEQUENCE {
-- PA TYPE 14
signedAuthPack [0] SignedData
-- defined in CMS [11]
-- AuthPack (below) defines the data
-- that is signed
trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
-- CAs that the client trusts
kdcCert [2] IssuerAndSerialNumber OPTIONAL
-- as defined in CMS [11]
-- specifies a particular KDC
-- certificate if the client
-- already has it;
encryptionCert [3] IssuerAndSerialNumber OPTIONAL
-- For example, this may be the
-- client's Diffie-Hellman
-- certificate, or it may be the
-- client's RSA encryption
-- certificate.
}
TrustedCas ::= CHOICE {
principalName [0] KerberosName,
-- as defined below
caName [1] Name
-- fully qualified X.500 name
-- as defined by X.509
issuerAndSerial [2] IssuerAndSerialNumber
-- Since a CA may have a number of
-- certificates, only one of which
-- a client trusts
}
Usage of SignedData:
The SignedData data type is specified in the Cryptographic
Message Syntax, a product of the S/MIME working group of the IETF.
- The encapContentInfo field must contain the PKAuthenticator
and, optionally, the client's Diffie Hellman public value.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1)
- The eContent field is data of the type AuthPack (below).
- The signerInfos field contains the signature of AuthPack.
- The Certificates field, when non-empty, contains the client's
certificate chain. If present, the KDC uses the public key from
the client's certificate to verify the signature in the request.
Note that the client may pass different certificates that are used
for signing or for encrypting. Thus, the KDC may utilize a
different client certificate for signature verification than the
one it uses to encrypt the reply to the client. For example, the
client may place a Diffie-Hellman certificate in this field in
order to convey its static Diffie Hellman certificate to the KDC to
enable static-ephemeral Diffie-Hellman mode for the reply; in this
case, the client does NOT place its public value in the AuthPack
(defined below). As another example, the client may place an RSA
encryption certificate in this field. However, there must always
be (at least) a signature certificate.
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- if client is using Diffie-Hellman
-- (ephemeral-ephemeral only)
}
PKAuthenticator ::= SEQUENCE {
kdcName [0] PrincipalName,
kdcRealm [1] Realm,
cusec [2] INTEGER,
-- for replay prevention as in RFC1510
ctime [3] KerberosTime,
-- for replay prevention as in RFC1510
nonce [4] INTEGER
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
-- dhKeyAgreement
subjectPublicKey BIT STRING
-- for DH, equals
-- public exponent (INTEGER encoded
-- as payload of BIT STRING)
} -- as specified by the X.509 recommendation [10]
AlgorithmIdentifier ::= SEQUENCE {
algorithm ALGORITHM.&id,
parameters ALGORITHM.&type
} -- as specified by the X.509 recommendation [10]
If the client passes an issuer and serial number in the request,
the KDC is requested to use the referred-to certificate. If none
exists, then the KDC returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
other hand, the client does not pass any trustedCertifiers,
believing that it has the KDC's certificate, but the KDC has more
than one certificate. The KDC should include information in the
KRB-ERROR message that indicates the KDC certificate(s) that a
client may utilize. This data is specified in the e-data, which
is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
TypedData ::= SEQUENCE {
data-type [0] INTEGER,
data-value [1] OCTET STRING,
} -- per Kerberos RFC 1510 revisions
where:
data-type = TD-PKINIT-CMS-CERTIFICATES = 101
data-value = CertificateSet // as specified by CMS [11]
The PKAuthenticator carries information to foil replay attacks, and
to bind the request and response. The PKAuthenticator is signed
with the client's signature key.
3.2.2. KDC Response
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type, the KDC attempts to verify the user's certificate chain
(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 client's certificate chain contains no certificate signed by
a CA trusted by the KDC, then the KDC sends back an error message
of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data
is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
whose data-value is an OCTET STRING which is the DER encoding of
TrustedCertifiers ::= SEQUENCE OF PrincipalName
-- X.500 name encoded as a principal name
-- see Section 3.1
If while verifying a certificate chain the KDC determines that the
signature on one of the certificates in the CertificateSet from
the signedAuthPack fails verification, then the KDC returns an
error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying
e-data is a SEQUENCE of one TypedData (with type
TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
which is the DER encoding of the index into the CertificateSet
ordered as sent by the client.
CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- (in order of encoding)
-- 1 = 2nd certificate, etc
The KDC may also check whether any of the certificates in the
client's chain has been revoked. If one of the certificates has
been revoked, then the KDC returns an error of type
KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
the certificate's revocation status is unknown or not
available, then if required by policy, the KDC returns the
appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
cases, the affected certificate is identified by the accompanying
e-data, which contains a CertificateIndex as described for
KDC_ERR_INVALID_CERTIFICATE.
If the certificate chain can be verified, but the name of the
client in the certificate does not match the client's name in the
request, then the KDC returns an error of type
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
field in this case.
Finally, if the certificate chain is verified, but the KDC's name
or realm as given in the PKAuthenticator does not match the KDC's
actual principal name, then the KDC returns an error of type
KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again
a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
STRING whose data-value is the DER encoding of a PrincipalName or
Realm as defined in RFC 1510 revisions.
Even if all succeeds, the KDC may--for policy reasons--decide not
to trust the client. In this case, the KDC returns an error message
of type KDC_ERR_CLIENT_NOT_TRUSTED.
If a trust relationship exists, the KDC then verifies the client's
signature on AuthPack. If that fails, the KDC returns an error
message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
timestamp (ctime and cusec) in the PKAuthenticator to assure that
the request is not a replay. The KDC also verifies that its name
is specified in the PKAuthenticator.
If the clientPublicValue field is filled in, indicating that the
client wishes to use Diffie-Hellman key agreement, then the KDC
checks to see that the parameters satisfy its policy. If they do
not (e.g., the prime size is insufficient for the expected
encryption type), then the KDC sends back an error message of type
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
private values for the response.
The KDC also checks that the timestamp in the PKAuthenticator is
within the allowable window and that the principal name and realm
are correct. If the local (server) time and the client time in the
authenticator differ by more than the allowable clock skew, then the
KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
Assuming no errors, the KDC replies as per RFC 1510, except as
follows. The user's name in the ticket is determined by the
following decision algorithm:
1. If the KDC has a mapping from the name in the certificate
to a Kerberos name, then use that name.
Else
2. If the certificate contains the SubjectAltName extention
and the local KDC policy defines a mapping from the
SubjectAltName to a Kerberos name, then use that name.
Else
3. Use the name as represented in the certificate, mapping
mapping as necessary (e.g., as per RFC 2253 for X.500
names). In this case the realm in the ticket shall be the
name of the certifier that issued the user's certificate.
Note that a principal name may be carried in the subject alt name
field of a certificate. This name may be mapped to a principal
record in a security database based on local policy, for example
the subject alt name may be kerberos/principal@realm format. In
this case the realm name is not that of the CA but that of the
local realm doing the mapping (or some realm name chosen by that
realm).
If a non-KDC X.509 certificate contains the principal name within
the subjectAltName version 3 extension , that name may utilize
KerberosName as defined below, or, in the case of an S/MIME
certificate [17], may utilize the email address. If the KDC
is presented with as S/MIME certificate, then the email address
within subjectAltName will be interpreted as a principal and realm
separated by the "@" sign, or as a name that needs to be
canonicalized. If the resulting name does not correspond to a
registered principal name, then the principal name is formed as
defined in section 3.1.
The trustedCertifiers field contains a list of certification
authorities trusted by the client, in the case that the client does
not possess the KDC's public key certificate. If the KDC has no
certificate signed by any of the trustedCertifiers, then it returns
an error of type KDC_ERR_KDC_NOT_TRUSTED.
KDCs should try to (in order of preference):
1. Use the KDC certificate identified by the serialNumber included
in the client's request.
2. Use a certificate issued to the KDC by the client's CA (if in the
middle of a CA key roll-over, use the KDC cert issued under same
CA key as user cert used to verify request).
3. Use a certificate issued to the KDC by one of the client's
trustedCertifier(s);
If the KDC is unable to comply with any of these options, then the
KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
client.
The KDC encrypts the reply not with the user's long-term key, but
with the Diffie Hellman derived key or a random key generated
for this particular response which is carried in the padata field of
the TGS-REP message.
PA-PK-AS-REP ::= CHOICE {
-- PA TYPE 15
dhSignedData [0] SignedData,
-- Defined in CMS and used only with
-- Diffie-Hellman key exchange (if the
-- client public value was present in the
-- request).
-- This choice MUST be supported
-- by compliant implementations.
encKeyPack [1] EnvelopedData,
-- Defined in CMS
-- The temporary key is encrypted
-- using the client public key
-- key
-- SignedReplyKeyPack, encrypted
-- with the temporary key, is also
-- included.
}
Usage of SignedData:
If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
provides authenticated Diffie-Hellman parameters of the KDC. The
reply key used to encrypt part of the KDC reply message is derived
from the Diffie-Hellman exchange:
- Both the KDC and the client calculate a secret value (g^ab mod p),
where a is the client's private exponent and b is the KDC's
private exponent.
- Both the KDC and the client take the first N bits of this secret
value and convert it into a reply key. N depends on the reply key
type.
- If the reply key is DES, N=64 bits, where some of the bits are
replaced with parity bits, according to FIPS PUB 74.
- If the reply key is (3-key) 3-DES, N=192 bits, where some of the
bits are replaced with parity bits, according to FIPS PUB 74.
- The encapContentInfo field must contain the KdcDHKeyInfo as
defined below.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1)
- The certificates field must contain the certificates necessary
for the client to establish trust in the KDC's certificate
based on the list of trusted certifiers sent by the client in
the PA-PK-AS-REQ. This field may be empty if the client did
not send to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the client
already possesses the KDC's certificate).
- The signerInfos field is a SET that must contain at least one
member, since it contains the actual signature.
KdcDHKeyInfo ::= SEQUENCE {
-- used only when utilizing Diffie-Hellman
nonce [0] INTEGER,
-- binds responce to the request
subjectPublicKey [2] BIT STRING
-- Equals public exponent (g^a mod p)
-- INTEGER encoded as payload of
-- BIT STRING
}
Usage of EnvelopedData:
The EnvelopedData data type is specified in the Cryptographic
Message Syntax, a product of the S/MIME working group of the IETF.
It contains an temporary key encrypted with the PKINIT
client's public key. It also contains a signed and encrypted
reply key.
- The originatorInfo field is not required, since that information
may be presented in the signedData structure that is encrypted
within the encryptedContentInfo field.
- The optional unprotectedAttrs field is not required for PKINIT.
- The recipientInfos field is a SET which must contain exactly one
member of the KeyTransRecipientInfo type for encryption
with an RSA public key.
- The encryptedKey field (in KeyTransRecipientInfo) contains
the temporary key which is encrypted with the PKINIT client's
public key.
- The encryptedContentInfo field contains the signed and encrypted
reply key.
- The contentType field shall contain the OID value for
id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) signedData(2)
- The encryptedContent field is encrypted data of the CMS type
signedData as specified below.
- The encapContentInfo field must contains the ReplyKeyPack.
- The eContentType field shall contain the OID value for
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs7(7) data(1)
- The eContent field is data of the type ReplyKeyPack (below).
- The certificates field must contain the certificates necessary
for the client to establish trust in the KDC's certificate
based on the list of trusted certifiers sent by the client in
the PA-PK-AS-REQ. This field may be empty if the client did
not send to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the client
already possesses the KDC's certificate).
- The signerInfos field is a SET that must contain at least one
member, since it contains the actual signature.
ReplyKeyPack ::= SEQUENCE {
-- not used for Diffie-Hellman
replyKey [0] EncryptionKey,
-- used to encrypt main reply
-- ENCTYPE is at least as strong as
-- ENCTYPE of session key
nonce [1] INTEGER,
-- binds response to the request
-- must be same as the nonce
-- passed in the PKAuthenticator
}
Since each certifier in the certification path of a user's
certificate is equivalent to a separate Kerberos realm, the name
of each certifier in the certificate chain must be added to the
transited field of the ticket. The format of these realm names is
defined in Section 3.1 of this document. If applicable, the
transit-policy-checked flag should be set in the issued ticket.
The KDC's certificate(s) must bind the public key(s) of the KDC to
a name derivable from the name of the realm for that KDC. X.509
certificates shall contain the principal name of the KDC
(defined in section 8.2 of RFC 1510) as the SubjectAltName version
3 extension. Below is the definition of this version 3 extension,
as specified by the X.509 standard:
subjectAltName EXTENSION ::= {
SYNTAX GeneralNames
IDENTIFIED BY id-ce-subjectAltName
}
GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
...
}
OTHER-NAME ::= TYPE-IDENTIFIER
In this definition, otherName is a name of any form defined as an
instance of the OTHER-NAME information object class. For the purpose
of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
be chosen and replaced by the type KerberosName:
KerberosName ::= SEQUENCE {
realm [0] Realm,
-- as defined in RFC 1510
principalName [1] PrincipalName,
-- as defined in RFC 1510
}
This specific syntax is identified within subjectAltName by setting
the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
Kerberos specification) we have
krb5 OBJECT IDENTIFIER ::= { iso (1)
org (3)
dod (6)
internet (1)
security (5)
kerberosv5 (2) }
krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
(This specification may also be used to specify a Kerberos name
within the user's certificate.) The KDC's certificate may be signed
directly by a CA, or there may be intermediaries if the server resides
within a large organization, or it may be unsigned if the client
indicates possession (and trust) of the KDC's certificate.
The client then extracts the random key used to encrypt the main
reply. This random key (in 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. The client uses this
random key to decrypt the main reply, and subsequently proceeds as
described in RFC 1510.
3.2.3. Required Algorithms
Not all of the algorithms in the PKINIT protocol specification have
to be implemented in order to comply with the proposed standard.
Below is a list of the required algorithms:
- Diffie-Hellman public/private key pairs
- utilizing Diffie-Hellman ephemeral-ephemeral mode
- SHA1 digest and DSA for signatures
- 3-key triple DES keys derived from the Diffie-Hellman Exchange
- 3-key triple DES Temporary and Reply keys
4. Logistics and Policy
This section describes a way to define the policy on the use of
PKINIT for each principal and request.
The KDC is not required to contain a database record for users
who use public key authentication. However, if these users are
registered with the KDC, it is recommended that the database record
for these users be modified to an additional flag in the attributes
field to indicate that the user should authenticate using PKINIT.
If this flag is set and a request message does not contain the
PKINIT preauthentication field, then the KDC sends back as error of
type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
field of type PA-PK-AS-REQ must be included in the request.
5. Security Considerations
PKINIT raises a few security considerations, which we will address
in this section.
First of all, PKINIT introduces a new trust model, where KDCs do not
(necessarily) certify the identity of those for whom they issue
tickets. PKINIT does allow KDCs to act as their own CAs, in order
to simplify key management, but one of the additional benefits is to
align Kerberos authentication with a global public key
infrastructure. Anyone using PKINIT in this way must be aware of
how the certification infrastructure they are linking to works.
Secondly, PKINIT also introduces the possibility of interactions
between different cryptosystems, which may be of widely varying
strengths. Many systems, for instance, allow the use of 512-bit
public keys. Using such keys to wrap data encrypted under strong
conventional cryptosystems, such as triple-DES, is inappropriate;
it adds a weak link to a strong one at extra cost. Implementors
and administrators should take care to avoid such wasteful and
deceptive interactions.
Lastly, PKINIT calls for randomly generated keys for conventional
cryptosystems. Many such systems contain systematically "weak"
keys. PKINIT implementations MUST avoid use of these keys, either
by discarding those keys when they are generated, or by fixing them
in some way (e.g., by XORing them with a given mask). These
precautions vary from system to system; it is not our intention to
give an explicit recipe for them here.
6. Transport Issues
Certificate chains can potentially grow quite large and span several
UDP packets; this in turn increases the probability that a Kerberos
message involving PKINIT extensions will be broken in transit. In
light of the possibility that the Kerberos specification will
require KDCs to accept requests using TCP as a transport mechanism,
we make the same recommendation with respect to the PKINIT
extensions as well.
7. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
Authentication in Kerberos.
draft-ietf-cat-kerberos-pk-cross-04.txt
[4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
Kerberos.
draft-ietf-cat-kerberos-anoncred-00.txt
[5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt
[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed
System Security, 1997.
[7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic
Commerce, July 1995.
[8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
Request for Comments 2246, January 1999.
[9] B.C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems. In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993.
[10] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
[11] R. Housley. Cryptographic Message Syntax.
draft-ietf-smime-cms-13.txt, April 1999, approved for publication
as RFC.
[12] PKCS #7: Cryptographic Message Syntax Standard,
An RSA Laboratories Technical Note Version 1.5
Revised November 1, 1993
[13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
Security, Inc. A Description of the RC2(r) Encryption Algorithm
March 1998.
Request for Comments 2268.
[14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names.
Request for Comments 2253.
[15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
Key Infrastructure, Certificate and CRL Profile, January 1999.
Request for Comments 2459.
[16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
Specifications, October 1998. Request for Comments 2437.
[17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME
Version 2 Certificate Handling, March 1998. Request for
Comments 2312.
[18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access
Protocol (v3), December 1997. Request for Comments 2251.
8. Acknowledgements
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 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.
9. Expiration Date
This draft expires April 30, 2000.
10. Authors
Brian Tung
Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {brian, bcn}@isi.edu
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road
Issaquah WA 98027-5378
Phone: +1 425 391 6000
E-mail: matt.hur@cybersafe.com
Ari Medvinsky
Excite
555 Broadway
Redwood City, CA 94063
Phone +1 650 569 2119
E-mail: amedvins@excitecorp.com
Sasha Medvinsky
General Instrument
6450 Sequence Drive
San Diego, CA 92121
Phone +1 619 404 2825
E-mail: smedvinsky@gi.com
John Wray
Iris Associates, Inc.
5 Technology Park Dr.
Westford, MA 01886
E-mail: John_Wray@iris.com
Jonathan Trostle
170 W. Tasman Dr.
San Jose, CA 95134
E-mail: jtrostle@cisco.com

1062
doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1104
doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1116
doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt Normal file
View File

File diff suppressed because it is too large Load Diff

2
doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt
View File

@@ -1,4 +1,3 @@
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-17.txt Clifford Neuman
Updates: RFC 1510bis USC/ISI
@@ -804,4 +803,3 @@ E-mail: John_Wray@iris.com
Jonathan Trostle
E-mail: jtrostle@world.std.com

202
doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt
View File

@@ -11,50 +11,35 @@ expires January 25, 2005 Matthew Hur
Jonathan Trostle
Public Key Cryptography for Initial Authentication in Kerberos
0. Status Of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
all provision of Section 10 of RFC 2026. 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 documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-20.txt and expires January 25, 2005.
Please send comments to the authors.
1. Abstract
This document describes protocol extensions (hereafter called
PKINIT) to the Kerberos protocol specification ([1], hereafter
called CLARIFICATIONS). These extensions provide a method for
@@ -63,10 +48,8 @@ exchange, by passing digital certificates and associated
authenticators in preauthentication data fields.
2. Introduction
A client typically authenticates itself to a service in Kerberos
using three distinct though related exchanges. First, the client
requests a ticket-granting ticket (TGT) from the Kerberos
@@ -78,7 +61,6 @@ will refer to both the AS and the TGS as the KDC.) Finally, the
client uses the service ticket to authenticate itself to the
service.
The advantage afforded by the TGT is that the client need explicitly
request a ticket and expose his credentials only once. The TGT and
its associated session key can then be used for any subsequent
@@ -88,14 +70,12 @@ performed. Consequently, initial authentication provides a
convenient place to integrate public-key cryptography into Kerberos
authentication.
As defined, Kerberos authentication exchanges use symmetric-key
cryptography, in part for performance. One cost of using
symmetric-key cryptography is that the keys must be shared, so that
before a client can authenticate itself, he must already be
registered with the KDC.
Conversely, public-key cryptography (in conjunction with an
established Public Key Infrastructure) permits authentication
without prior registration with a KDC. Adding it to Kerberos allows
@@ -103,7 +83,6 @@ the widespread use of Kerberized applications by clients without
requiring them to register first with a KDC--a requirement that has
no inherent security benefit.
As noted above, a convenient and efficient place to introduce
public-key cryptography into Kerberos is in the initial
authentication exchange. This document describes the methods and
@@ -111,100 +90,75 @@ data formats for integrating public-key cryptography into Kerberos
initial authentication.
3. Extensions
This section describes extensions to CLARIFICATIONS for supporting
the use of public-key cryptography in the initial request for a
ticket.
Briefly, this document defines the following extensions to
CLARIFICATIONS:
1. The client indicates the use of public-key authentication by
including a special preauthenticator in the initial request.
This preauthenticator contains the client's public-key data
and a signature.
2. The KDC tests the client's request against its policy and
trusted Certification Authorities (CAs).
3. If the request passes the verification tests, the KDC
replies as usual, but the reply is encrypted using either:
a. a symmetric encryption key, signed using the KDC's
signature key and encrypted using the client's encryption
key; or
b. a key generated through a Diffie-Hellman exchange with
the client, signed using the KDC's signature key.
Any keying material required by the client to obtain the
Encryption key is returned in a preauthentication field
accompanying the usual reply.
4. The client obtains the encryption key, decrypts the reply,
and then proceeds as usual.
Section 3.1 of this document defines the necessary message formats.
Section 3.2 describes their syntax and use in greater detail.
3.1. Definitions
3.1.1. Required Algorithms
All PKINIT implementations MUST support the following algorithms:
- Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.
- Signature algorithm: SHA-1 digest and RSA.
- Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
with a non-zero nonce.
- Unkeyed checksum type for the paChecksum member of
PKAuthenticator: SHA1 (unkeyed).
3.1.2. Defined Message and Encryption Types
PKINIT makes use of the following new preauthentication types:
PA-PK-AS-REQ TBD
PA-PK-AS-REP TBD
PKINIT also makes use of the following new authorization data type:
AD-INITIAL-VERIFIED-CAS TBD
PKINIT introduces the following new error codes:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
@@ -216,20 +170,16 @@ PKINIT introduces the following new error codes:
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_CLIENT_NAME_MISMATCH 75
PKINIT uses the following typed data types for errors:
TD-DH-PARAMETERS TBD
TD-TRUSTED-CERTIFIERS 104
TD-CERTIFICATE-INDEX 105
PKINIT defines the following encryption types, for use in the AS-REQ
message (to indicate acceptance of the corresponding encryption OIDs
in PKINIT):
dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
@@ -238,81 +188,63 @@ in PKINIT):
rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
des-ede3-cbc-EnvOID 15
The above encryption types are used by the client only within the
KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their
use within Kerberos EncryptedData structures is not specified by this
document.
The ASN.1 module for all structures defined in this document (plus
IMPORT statements for all imported structures) are given in Appendix
A. All structures MUST be encoded using Distinguished Encoding
Rules (DER).
3.1.3. Algorithm Identifiers
PKINIT does not define, but does make use of, the following
algorithm identifiers.
PKINIT uses the following algorithm identifier for Diffie-Hellman
key agreement [9]:
dhpublicnumber
PKINIT uses the following signature algorithm identifiers [8, 12]:
sha-1WithRSAEncryption (RSA with SHA1)
md5WithRSAEncryption (RSA with MD5)
id-dsa-with-sha1 (DSA with SHA1)
PKINIT uses the following encryption algorithm identifiers [5] for
encrypting the temporary key with a public key:
rsaEncryption (PKCS1 v1.5)
id-RSAES-OAEP (PKCS1 v2.0)
PKINIT uses the following algorithm identifiers [2] for encrypting
the reply key with the temporary key:
des-ede3-cbc (three-key 3DES, CBC mode)
rc2-cbc (RC2, CBC mode)
Kerberos data structures require the use of integer etypes, while CMS
objects use OIDs. Therefore, each cryptographic algorithm supported
by PKINIT is identified both by a CMS OID and by an equivalent
Kerberos etype (defined in section 3.1.2).
3.2. PKINIT Preauthentication Syntax and Use
This section defines the syntax and use of the various
preauthentication fields employed by PKINIT.
3.2.1. Client Request
The initial authentication request (AS-REQ) is sent as per RFC
1510bis; in addition, a preauthentication field contains data signed
by the client's private signature key, as follows:
PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] ContentInfo,
-- Defined in CMS [2].
@@ -331,7 +263,6 @@ by the client's private signature key, as follows:
...
}
TrustedCA ::= CHOICE {
caName [0] Name,
-- Fully qualified X.500 name
@@ -342,7 +273,6 @@ by the client's private signature key, as follows:
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
@@ -358,7 +288,6 @@ by the client's private signature key, as follows:
...
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER,
ctime [1] KerberosTime,
@@ -379,24 +308,19 @@ by the client's private signature key, as follows:
...
}
The ContentInfo in the signedAuthPack is filled out as follows:
1. The eContent field contains data of type AuthPack. It MUST
contain the pkAuthenticator, and MAY also contain the
client's Diffie-Hellman public value (clientPublicValue).
2. The eContentType field MUST contain the OID value for
id-pkauthdata: { iso(1) org(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit(3) pkauthdata(1)}
3. The signerInfos field MUST contain the signature over the
AuthPack.
4. The certificates field MUST contain at least a signature
verification certificate chain that the KDC can use to
verify the signature over the AuthPack. Additionally, the
@@ -404,12 +328,10 @@ The ContentInfo in the signedAuthPack is filled out as follows:
(for example) the client is not using ephemeral-ephemeral
Diffie-Hellman.
5. If a Diffie-Hellman key is being used, the parameters SHOULD
be chosen from the First or Second defined Oakley Groups.
(See RFC 2409 [10].)
6. The KDC may wish to use cached Diffie-Hellman parameters.
To indicate acceptance of caching, the client sends zero in
the nonce field of the pkAuthenticator. Zero is not a valid
@@ -419,15 +341,12 @@ The ContentInfo in the signedAuthPack is filled out as follows:
nonce in the main request.
3.2.2. Validation of Client Request
Upon receiving the client's request, the KDC validates it. This
section describes the steps that the KDC MUST (unless otherwise
noted) take in validating the request.
The KDC must look for a client certificate in the signedAuthPack.
If it cannot find one signed by a CA it trusts, it sends back an
error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying
@@ -435,10 +354,8 @@ e-data for this error is a SEQUENCE OF TYPED-DATA (as defined in RFC
1510bis). For this error, the data-type is TD-TRUSTED-CERTIFIERS,
and the data-value is an OCTET STRING containing the DER encoding of
TrustedCertifiers ::= SEQUENCE OF Name
If, while verifying the certificate chain, the KDC determines that
the signature on one of the certificates in the signedAuthPack is
invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
@@ -447,16 +364,13 @@ whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
OCTET STRING containing the DER encoding of the index into the
CertificateSet field, ordered as sent by the client:
CertificateIndex ::= IssuerAndSerialNumber
-- IssuerAndSerialNumber of
-- certificate with invalid signature
If more than one certificate signature is invalid, the KDC MAY send
one TYPED-DATA per invalid signature.
The KDC MAY also check whether any certificates in the client's
chain have been revoked. If any of them have been revoked, the KDC
MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
@@ -465,39 +379,31 @@ it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
The certificate or certificates affected are identified exactly as
for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
In addition to validating the certificate chain, the KDC MUST also
check that the certificate properly maps to the client's principal name
as specified in the AS-REQ as follows:
1. If the KDC has its own mapping from the name in the
certificate to a Kerberos name, it uses that Kerberos
name.
2. Otherwise, if the certificate contains a SubjectAltName
extension with a Kerberos name in the otherName field,
it uses that name. The otherName field (of type AnotherName)
in the SubjectAltName extension MUST contain the following:
The type-id is:
krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
internet (1) security (5) kerberosv5 (2) 2 }
The value is:
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
If the KDC does not have its own mapping and there is no Kerberos
name present in the certificate, or if the name in the request does
not match the name in the certificate (including the realm name), or
@@ -505,7 +411,6 @@ if there is no name in the request, the KDC MUST return error code
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
for this error.
Even if the chain is validated, and the names in the certificate and
the request match, the KDC may decide not to trust the client. For
example, the certificate may include an Enxtended Key Usage (EKU) OID
@@ -514,23 +419,19 @@ decide to reject requests on the basis of the absence or presence of
specific EKU OIDs. In this case, the KDC MUST return error code
KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) pkekuoid(4) }
If the client's signature on the signedAuthPack fails to verify, the KDC
MUST return error KDC_ERR_INVALID_SIG. There is no accompanying
e-data for this error.
The KDC MUST check the timestamp to ensure that the request is not
a replay, and that the time skew falls within acceptable limits.
The recommendations clock skew times in CLARIFICATIONS apply here.
If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT
or KRB_AP_ERR_SKEW, respectively.
If the clientPublicValue is filled in, indicating that the client
wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
see if the parameters satisfy its policy. If they do not, it MUST
@@ -540,18 +441,15 @@ whose data-value is an OCTET STRING containing the DER encoding of a
DomainParameters (see [3]), including appropriate Diffie-Hellman
parameters with which to retry the request.
The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
not have the corresponding certificate.
The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
did not include a kdcCert field, but did include a trustedCertifiers
field, and the KDC does not possesses a certificate issued by one of
the listed certifiers.
If there is a supportedCMSTypes field in the AuthPack, the KDC must
check to see if it supports any of the listed types. If it supports
more than one of the types, the KDC SHOULD use the one listed first.
@@ -559,26 +457,21 @@ If it does not support any of them, it MUST return an error of type
KRB5KDC_ERR_ETYPE_NOSUPP.
3.2.3. KDC Reply
Assuming that the client's request has been properly validated, the
KDC proceeds as per CLARIFICATIONS, except as follows.
The KDC MUST set the initial flag and include an authorization data
of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is
an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
ca [0] Name,
Validated [1] BOOLEAN,
...
}
The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
containers if the list of CAs satisfies the KDC's realm's policy.
(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
@@ -586,7 +479,6 @@ Furthermore, any TGS must copy such authorization data from tickets
used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
including the AD-IF-RELEVANT container, if present.
Application servers that understand this authorization data type
SHOULD apply local policy to determine whether a given ticket
bearing such a type *not* contained within an AD-IF-RELEVANT
@@ -596,7 +488,6 @@ has not been set.) If such a data type is contained within an
AD-IF-RELEVANT container, AP servers MAY apply local policy to
determine whether the authorization data is acceptable.
The AS-REP is otherwise unchanged from CLARIFICATIONS. The KDC
encrypts the reply as usual, but not with the client's long-term
key. Instead, it encrypts it with either a generated encryption
@@ -604,7 +495,6 @@ key, or a key derived from a Diffie-Hellman exchange. The contents
of the PA-PK-AS-REP indicate the type of encryption key that was
used:
PA-PK-AS-REP ::= CHOICE {
dhSignedData [0] ContentInfo,
-- Type is SignedData.
@@ -617,7 +507,6 @@ used:
...
}
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- Equals public exponent
@@ -635,23 +524,18 @@ used:
...
}
The fields of the ContentInfo for dhSignedData are to be filled in
as follows:
1. The eContent field contains data of type KDCDHKeyInfo.
2. The eContentType field contains the OID value for
id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }
3. The signerInfos field contains a single signerInfo, which is
the signature of the KDCDHKeyInfo.
4. The certificates field contains a signature verification
certificate chain that the client will use to verify the
KDC's signature over the KDCDHKeyInfo. This field may only
@@ -659,7 +543,6 @@ as follows:
the PA-PK-AS-REQ, indicating that it has the KDC's
certificate.
5. If the client and KDC agree to use cached parameters, the
KDC MUST return a zero in the nonce field and include the
expiration time of the cached values in the dhKeyExpiration
@@ -668,7 +551,6 @@ as follows:
the reply and MAY resubmit a request with a non-zero nonce,
thus indicating non-acceptance of the cached parameters.
The key is derived as follows: Both the KDC and the client calculate
the value g^(ab) mod p, where a and b are the client's and KDC's
private exponents, respectively. They both take the first k bits of
@@ -678,12 +560,10 @@ specified in [6]. The seed is then converted into a protocol key by
applying to it a random-to-key function, which is also dependent on
key type.
If the KDC and client are not using Diffie-Hellman, the KDC encrypts
the reply with an encryption key, packed in the encKeyPack, which
contains data of type ReplyKeyPack:
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- Defined in CLARIFICATIONS.
@@ -699,57 +579,46 @@ contains data of type ReplyKeyPack:
...
}
The fields of the ContentInfo for encKeyPack MUST be filled in as
follows:
1. The content is of type SignedData. The eContent for
the SignedData is of type ReplyKeyPack.
2. The eContentType for the SignedData contains the OID value
for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }
3. The signerInfos field contains a single signerInfo, which is
the signature of the ReplyKeyPack.
4. The certificates field contains a signature verification
certificate chain that the client will use to verify the
KDC's signature over the ReplyKeyPack. This field may only
be left empty if the client included a kdcCert field in the
PA-PK-AS-REQ, indicating that it has the KDC's certificate.
5. The contentType for the EnvelopedData contains the OID value
for id-signedData: { iso (1) member-body (2) us (840) rsadsi
(113549) pkcs (1) pkcs7 (7) signedData (2) }
6. The recipientInfos field is a SET which MUST contain exactly
one member of type KeyTransRecipientInfo. The encryptedKey
for this member contains the temporary key which is
encrypted using the client's public key.
7. The unprotectedAttrs or originatorInfo fields MAY be
present.
3.2.4. Validation of KDC Reply
Upon receipt of the KDC's reply, the client proceeds as follows. If
the PA-PK-AS-REP contains a dhSignedData, the client obtains and
verifies the Diffie-Hellman parameters, and obtains the shared key
as described above. Otherwise, the message contains an encKeyPack,
and the client decrypts and verifies the temporary encryption key.
In either case, the client MUST check to see if the included
certificate contains a subjectAltName extension of type dNSName or
iPAddress (if the KDC is specified by IP address instead of name).
@@ -758,34 +627,27 @@ it believes it is communicating with, with matching rules specified
in RFC 2459. Exception: If the client has some external information
as to the identity of the KDC, this check MAY be omitted.
The client also MUST check that the KDC's certificate contains an
extendedKeyUsage OID of id-pkkdcekuoid:
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) pkkdcekuoid(5) }
If all applicable checks are satisfied, the client then decrypts the
main reply with the resulting key, and then proceeds as described in
CLARIFICATIONS.
4. Security Considerations
PKINIT raises certain security considerations beyond those that can
be regulated strictly in protocol definitions. We will address them
in this section.
PKINIT extends the cross-realm model to the public-key
infrastructure. Users of PKINIT must understand security policies
and procedures appropriate to the use of Public Key Infrastructures.
Standard Kerberos allows the possibility of interactions between
cryptosystems of varying strengths; this document adds interactions
with public-key cryptosystems to Kerberos. Some administrative
@@ -793,12 +655,10 @@ policies may allow the use of relatively weak public keys. Using
such keys to wrap data encrypted under stronger conventional
cryptosystems may be inappropriate.
PKINIT requires keys for symmetric cryptosystems to be generated.
Some such systems contain "weak" keys. For recommendations regarding
these weak keys, see CLARIFICATIONS.
PKINIT allows the use of a zero nonce in the PKAuthenticator when
cached Diffie-Hellman keys are used. In this case, message binding
is performed using the nonce in the main request in the same way as
@@ -809,7 +669,6 @@ cryptographically binds the PKINIT pre-authenticator to the main
body of the AS Request and also provides message integrity for the
full AS Request.
However, when a PKINIT pre-authenticator in the AS-REP has a
zero-nonce, and an attacker has somehow recorded this
pre-authenticator and discovered the corresponding Diffie-Hellman
@@ -821,7 +680,6 @@ and it is therefore important for clients to check this expiration
time and for the expiration time to be reasonably short, which
depends on the size of the Diffie-Hellman group.
If a client also caches its Diffie-Hellman keys, then the session key
could remain the same during multiple AS-REQ/AS-REP exchanges and an
attacker which compromised the session key could fabricate his own
@@ -830,14 +688,12 @@ client starts using a new Diffie-Hellman key pair and while the KDC
pre-authenticator has not yet expired. It is therefore not
recommended for KDC clients to also cache their Diffie-Hellman keys.
Care should be taken in how certificates are chosen for the purposes
of authentication using PKINIT. Some local policies may require
that key escrow be used for certain certificate types. Deployers of
PKINIT should be aware of the implications of using certificates that
have escrowed keys for the purposes of authentication.
PKINIT does not provide for a "return routability" test to prevent
attackers from mounting a denial-of-service attack on the KDC by
causing it to perform unnecessary and expensive public-key
@@ -845,17 +701,14 @@ operations. Strictly speaking, this is also true of standard
Kerberos, although the potential cost is not as great, because
standard Kerberos does not make use of public-key cryptography.
The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
permit empty SEQUENCEs to be encoded. Such empty sequences may only
be used if the KDC itself vouches for the user's certificate. [This
seems to reflect the consensus of the Kerberos working group.]
5. Acknowledgements
Some of the ideas on which this document 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
@@ -867,66 +720,51 @@ perspective. Lastly, comments from groups working on similar ideas
in DCE have been invaluable.
6. Expiration Date
This draft expires January 25, 2004.
7. Bibliography
[1] RFC-Editor: To be replaced by RFC number for
draft-ietf-krb-wg-kerberos-clarifications.
[2] R. Housley. Cryptographic Message Syntax., April 1999.
Request For Comments 2630.
[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers
for the Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile, April 2002. Request For
Comments 3279.
[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile, April 2002. Request for Comments 3280.
[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
Specifications, October 1998. Request for Comments 2437.
[6] RFC-Editor: To be replaced by RFC number for
draft-ietf-krb-wg-crypto.
[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
Request for Comments 3546.
[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
Internet X.509 Public Key Infrastructure: Online Certificate Status
Protocol - OCSP, June 1999. Request for Comments 2560.
[9] NIST, Guidelines for Implementing and Using the NBS Encryption
Standard, April 1981. FIPS PUB 74.
[10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE),
November 1998. Request for Comments 2409.
8. Authors
Brian Tung
Clifford Neuman
USC Information Sciences Institute
@@ -935,7 +773,6 @@ Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {brian,bcn}@isi.edu
Matthew Hur
Ari Medvinsky
Microsoft Corporation
@@ -944,7 +781,6 @@ Redmond WA 98052
Phone: +1 425 707 3336
E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
Sasha Medvinsky
Motorola, Inc.
6450 Sequence Drive
@@ -952,73 +788,60 @@ San Diego, CA 92121
+1 858 404 2367
E-mail: smedvinsky@motorola.com
John Wray
Iris Associates, Inc.
5 Technology Park Dr.
Westford, MA 01886
E-mail: John_Wray@iris.com
Jonathan Trostle
E-mail: jtrostle@world.std.com
Appendix A. PKINIT ASN.1 Module
KerberosV5-PK-INIT-SPEC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(TBD)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS
SubjectPublicKeyInfo, AlgorithmIdentifier, Name
FROM PKIX1Explicit88 { iso (1) identified-organization (3)
dod (6) internet (1) security (5) mechanisms (5)
pkix (7) id-mod (0) id-pkix1-explicit (18) }
ContentInfo, IssuerAndSerialNumber
FROM CryptographicMessageSyntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms(1) }
KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
FROM KerberosV5Spec2 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) kerberosV5(2) modules(4)
krb5spec2(2) } ;
id-pkinit OBJECT IDENTIFIER ::=
{ iso (1) org (3) dod (6) internet (1) security (5)
kerberosv5 (2) pkinit (3) }
id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 }
id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
pa-pk-as-req INTEGER ::= TBD
pa-pk-as-rep INTEGER ::= TBD
pa-pk-ocsp-req INTEGER ::= TBD
pa-pk-ocsp-rep INTEGER ::= TBD
ad-initial-verified-cas INTEGER ::= TBD
td-dh-parameters INTEGER ::= TBD
td-trusted-certifiers INTEGER ::= 104
td-certificate-index INTEGER ::= 105
PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] ContentInfo,
trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
@@ -1026,14 +849,12 @@ KerberosV5-PK-INIT-SPEC {
...
}
TrustedCA ::= CHOICE {
caName [0] Name,
issuerAndSerial [2] IssuerAndSerialNumber,
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
@@ -1042,7 +863,6 @@ KerberosV5-PK-INIT-SPEC {
...
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER,
ctime [1] KerberosTime,
@@ -1051,33 +871,27 @@ KerberosV5-PK-INIT-SPEC {
...
}
TrustedCertifiers ::= SEQUENCE OF Name
CertificateIndex ::= IssuerAndSerialNumber
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
ca [0] Name,
validated [1] BOOLEAN,
...
}
PA-PK-AS-REP ::= CHOICE {
dhSignedData [0] ContentInfo,
encKeyPack [1] ContentInfo,
...
}
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
nonce [1] INTEGER,
@@ -1085,26 +899,10 @@ KerberosV5-PK-INIT-SPEC {
...
}
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
nonce [1] INTEGER (0..4294967295),
...
}
END
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

215
doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
View File

File diff suppressed because it is too large Load Diff

2403
doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt
View File

File diff suppressed because it is too large Load Diff

3
doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt
View File

@@ -1,5 +1,6 @@
NETWORK WORKING GROUP B. Tung
Internet-Draft USC Information Sciences Institute
Expires: August 4, 2005 L. Zhu
@@ -8,7 +9,7 @@ Expires: August 4, 2005 L. Zhu
Public Key Cryptography for Initial Authentication in Kerberos
draft-ietf-cat-kerberos-pk-init-23
draft-ietf-cat-kerberos-pk-init
Status of this Memo

640
doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt
View File

File diff suppressed because it is too large Load Diff

5
doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt
View File

@@ -1,6 +1,3 @@
NETWORK WORKING GROUP B. Tung
Internet-Draft USC Information Sciences Institute
Expires: November 24, 2005 L. Zhu
@@ -9,7 +6,7 @@ Expires: November 24, 2005 L. Zhu
Public Key Cryptography for Initial Authentication in Kerberos
draft-ietf-cat-kerberos-pk-init-26
draft-ietf-cat-kerberos-pk-init
Status of this Memo

3
doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt
View File

@@ -1,6 +1,3 @@
NETWORK WORKING GROUP B. Tung
Internet-Draft USC Information Sciences Institute
Expires: January 20, 2006 L. Zhu

1897
doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt Normal file
View File

File diff suppressed because it is too large Load Diff

3
doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt
View File

@@ -1,6 +1,3 @@
NETWORK WORKING GROUP B. Tung
Internet-Draft USC Information Sciences Institute
Expires: April 22, 2006 L. Zhu

2183
doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt Normal file
View File

File diff suppressed because it is too large Load Diff

614
doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt
View File

File diff suppressed because it is too large Load Diff

5
doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt
View File

@@ -1,6 +1,3 @@
NETWORK WORKING GROUP L. Zhu
Internet-Draft Microsoft Corporation
Expires: July 15, 2006 B. Tung
@@ -2289,5 +2286,3 @@ Acknowledgment
Zhu & Tung Expires July 15, 2006 [Page 41]

11
doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt
View File

@@ -1,6 +1,3 @@
NETWORK WORKING GROUP L. Zhu
Internet-Draft Microsoft Corporation
Expires: July 28, 2006 B. Tung
@@ -426,7 +423,7 @@ Internet-Draft PKINIT January 2006
Kerberos Encryption Type Name Num Corresponding Algorithm OID
============================== === ===============================
id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3279]
id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3279]
md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3279]
sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3279]
rc2-cbc-EnvOID 12 rc2-cbc [RFC3370]
@@ -455,8 +452,8 @@ Internet-Draft PKINIT January 2006
For maximum interoperability, however, PKINIT clients wishing to
indicate to the KDC the support for one or more of the algorithms
listed above SHOULD include the corresponding encryption type
number(s) in the etype field of the AS-REQ.
listed above SHOULD include the corresponding encryption type numbers
in the etype field of the AS-REQ.
3.2. PKINIT Pre-authentication Syntax and Use
@@ -2336,5 +2333,3 @@ Acknowledgment
Zhu & Tung Expires July 28, 2006 [Page 42]

5
doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt
View File

@@ -1,6 +1,3 @@
NETWORK WORKING GROUP L. Zhu
Internet-Draft Microsoft Corporation
Expires: August 11, 2006 B. Tung
@@ -2347,5 +2344,3 @@ Acknowledgment
Zhu & Tung Expires August 11, 2006 [Page 42]