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

upgrade

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@7969 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Assar Westerlund
2000-02-20 22:20:31 +00:00
parent 6f041e55db
commit 1ca3f99bad
2 changed files with 958 additions and 589 deletions
Download Patch File Download Diff File Expand all files Collapse all files

589
doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
View File

@@ -1,589 +0,0 @@
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

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

@@ -0,0 +1,958 @@
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