1
INTERNET-DRAFT Brian Tung
2
draft-ietf-cat-kerberos-pk-init-09.txt Clifford Neuman
4
expires December 1, 1999 Matthew Hur
15
Public Key Cryptography for Initial Authentication in Kerberos
17
0. Status Of This Memo
19
This document is an Internet-Draft and is in full conformance with
20
all provisions of Section 10 of RFC 2026. Internet-Drafts are
21
working documents of the Internet Engineering Task Force (IETF),
22
its areas, and its working groups. Note that other groups may also
23
distribute working documents as Internet-Drafts.
25
Internet-Drafts are draft documents valid for a maximum of six
26
months and may be updated, replaced, or obsoleted by other
27
documents at any time. It is inappropriate to use Internet-Drafts
28
as reference material or to cite them other than as "work in
32
The list of current Internet-Drafts can be accessed at
33
http://www.ietf.org/ietf/1id-abstracts.txt
35
The list of Internet-Draft Shadow Directories can be accessed at
36
http://www.ietf.org/shadow.html.
38
To learn the current status of any Internet-Draft, please check
39
the "1id-abstracts.txt" listing contained in the Internet-Drafts
40
Shadow Directories on ftp.ietf.org (US East Coast),
41
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
42
munnari.oz.au (Pacific Rim).
44
The distribution of this memo is unlimited. It is filed as
45
draft-ietf-cat-kerberos-pk-init-09.txt, and expires December 1,
46
1999. Please send comments to the authors.
50
This document defines extensions (PKINIT) to the Kerberos protocol
51
specification (RFC 1510 [1]) to provide a method for using public
52
key cryptography during initial authentication. The methods
53
defined specify the ways in which preauthentication data fields and
54
error data fields in Kerberos messages are to be used to transport
59
The popularity of public key cryptography has produced a desire for
60
its support in Kerberos [2]. The advantages provided by public key
61
cryptography include simplified key management (from the Kerberos
62
perspective) and the ability to leverage existing and developing
63
public key certification infrastructures.
65
Public key cryptography can be integrated into Kerberos in a number
66
of ways. One is to associate a key pair with each realm, which can
67
then be used to facilitate cross-realm authentication; this is the
68
topic of another draft proposal. Another way is to allow users with
69
public key certificates to use them in initial authentication. This
70
is the concern of the current document.
72
PKINIT utilizes Diffie-Hellman keys in combination with digital
73
signature keys as the primary, required mechanism. It also allows
74
for the use of RSA keys. Note that PKINIT supports the use of
75
separate signature and encryption keys.
77
PKINIT enables access to Kerberos-secured services based on initial
78
authentication utilizing public key cryptography. PKINIT utilizes
79
standard public key signature and encryption data formats within the
80
standard Kerberos messages. The basic mechanism is as follows: The
81
user sends a request to the KDC as before, except that if that user
82
is to use public key cryptography in the initial authentication
83
step, his certificate and a signature accompany the initial request
84
in the preauthentication fields. Upon receipt of this request, the
85
KDC verifies the certificate and issues a ticket granting ticket
86
(TGT) as before, except that the encPart from the AS-REP message
87
carrying the TGT is now encrypted utilizing either a Diffie-Hellman
88
derived key or the user's public key. This message is authenticated
89
utilizing the public key signature of the KDC.
91
The PKINIT specification may also be used as a building block for
92
other specifications. PKCROSS [3] utilizes PKINIT for establishing
93
the inter-realm key and associated inter-realm policy to be applied
94
in issuing cross realm service tickets. As specified in [4],
95
anonymous Kerberos tickets can be issued by applying a NULL
96
signature in combination with Diffie-Hellman in the PKINIT exchange.
97
Additionally, the PKINIT specification may be used for direct peer
98
to peer authentication without contacting a central KDC. This
99
application of PKINIT is described in PKTAPP [5] and is based on
100
concepts introduced in [6, 7]. For direct client-to-server
101
authentication, the client uses PKINIT to authenticate to the end
102
server (instead of a central KDC), which then issues a ticket for
103
itself. This approach has an advantage over TLS [8] in that the
104
server does not need to save state (cache session keys).
105
Furthermore, an additional benefit is that Kerberos tickets can
106
facilitate delegation (see [9]).
108
3. Proposed Extensions
110
This section describes extensions to RFC 1510 for supporting the
111
use of public key cryptography in the initial request for a ticket
112
granting ticket (TGT).
114
In summary, the following change to RFC 1510 is proposed:
116
* Users may authenticate using either a public key pair or a
117
conventional (symmetric) key. If public key cryptography is
118
used, public key data is transported in preauthentication
119
data fields to help establish identity. The user presents
120
a public key certificate and obtains an ordinary TGT that may
121
be used for subsequent authentication, with such
122
authentication using only conventional cryptography.
124
Section 3.1 provides definitions to help specify message formats.
125
Section 3.2 describes the extensions for the initial authentication
130
The extensions involve new preauthentication fields; we introduce
131
the following preauthentication types:
136
The extensions also involve new error types; we introduce the
139
KDC_ERR_CLIENT_NOT_TRUSTED 62
140
KDC_ERR_KDC_NOT_TRUSTED 63
141
KDC_ERR_INVALID_SIG 64
142
KDC_ERR_KEY_TOO_WEAK 65
143
KDC_ERR_CERTIFICATE_MISMATCH 66
144
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
145
KDC_ERR_INVALID_CERTIFICATE 71
146
KDC_ERR_REVOKED_CERTIFICATE 72
147
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
148
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74
149
KDC_ERR_CLIENT_NAME_MISMATCH 75
150
KDC_ERR_KDC_NAME_MISMATCH 76
152
We utilize the following typed data for errors:
154
TD-PKINIT-CMS-CERTIFICATES 101
157
TD-TRUSTED-CERTIFIERS 104
158
TD-CERTIFICATE-INDEX 105
160
We utilize the following encryption types (which map directly to
164
md5WithRSAEncryption-CmsOID 10
165
sha1WithRSAEncryption-CmsOID 11
167
rsaEncryption-EnvOID (PKCS#1 v1.5) 13
168
rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14
169
des-ede3-cbc-Env-OID 15
171
These mappings are provided so that a client may send the
172
appropriate enctypes in the AS-REQ message in order to indicate
173
support for the corresponding OIDs (for performing PKINIT).
175
In many cases, PKINIT requires the encoding of an X.500 name as a
176
Realm. In these cases, the realm will be represented using a
177
different style, specified in RFC 1510 with the following example:
179
NAMETYPE:rest/of.name=without-restrictions
181
For a realm derived from an X.500 name, NAMETYPE will have the value
182
X500-RFC2253. The full realm name will appear as follows:
184
X500-RFC2253:RFC2253Encode(DistinguishedName)
186
where DistinguishedName is an X.500 name, and RFC2253Encode is a
187
readable UTF encoding of an X.500 name, as defined by
188
RFC 2253 [14] (part of LDAPv3).
190
To ensure that this encoding is unique, we add the following rule
191
to those specified by RFC 2253:
193
The order in which the attributes appear in the RFC 2253
194
encoding must be the reverse of the order in the ASN.1
195
encoding of the X.500 name that appears in the public key
196
certificate. The order of the relative distinguished names
197
(RDNs), as well as the order of the AttributeTypeAndValues
198
within each RDN, will be reversed. (This is despite the fact
199
that an RDN is defined as a SET of AttributeTypeAndValues, where
200
an order is normally not important.)
202
Similarly, PKINIT may require the encoding of an X.500 name as a
203
PrincipalName. In these cases, the name-type of the principal name
204
shall be set to KRB_NT-X500-PRINCIPAL. This new name type is
207
KRB_NT_X500_PRINCIPAL 6
209
The name-string shall be set as follows:
211
RFC2253Encode(DistinguishedName)
215
RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
217
PrincipalName ::= SEQUENCE {
218
name-type[0] INTEGER,
219
name-string[1] SEQUENCE OF GeneralString
222
For the purposes of encoding an X.500 name within this structure,
223
the name-string shall be encoded as a single GeneralString.
225
Note that name mapping may be required or optional based on
228
3.1.1. Encryption and Key Formats
230
In the exposition below, we use the terms public key and private
231
key generically. It should be understood that the term "public
232
key" may be used to refer to either a public encryption key or a
233
signature verification key, and that the term "private key" may be
234
used to refer to either a private decryption key or a signature
235
generation key. The fact that these are logically distinct does
236
not preclude the assignment of bitwise identical keys.
238
In the case of Diffie-Hellman, the key shall be produced from the
239
agreed bit string as follows:
241
* Truncate the bit string to the appropriate length.
242
* Rectify parity in each byte (if necessary) to obtain the key.
244
For instance, in the case of a DES key, we take the first eight
245
bytes of the bit stream, and then adjust the least significant bit
246
of each byte to ensure that each byte has odd parity.
248
3.1.2. Algorithm Identifiers
250
PKINIT does not define, but does permit, the algorithm identifiers
253
3.1.2.1. Signature Algorithm Identifiers
255
The following signature algorithm identifiers specified in [11] and
256
in [15] shall be used with PKINIT:
258
id-dsa-with-sha1 (DSA with SHA1)
259
md5WithRSAEncryption (RSA with MD5)
260
sha-1WithRSAEncryption (RSA with SHA1)
262
3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
264
The following algorithm identifier shall be used within the
265
SubjectPublicKeyInfo data structure: dhpublicnumber
267
This identifier and the associated algorithm parameters are
268
specified in RFC 2459 [15].
270
3.1.2.3. Algorithm Identifiers for RSA Encryption
272
These algorithm identifiers are used inside the EnvelopedData data
273
structure, for encrypting the temporary key with a public key:
275
rsaEncryption (RSA encryption, PKCS#1 v1.5)
276
id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
278
Both of the above RSA encryption schemes are specified in [16].
279
Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
280
CMS specification says that it will likely include PKCS#1 v2.0 in
281
the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext
282
vulnerability discovered in PKCS#1 v1.5.)
284
3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
286
These algorithm identifiers are used inside the EnvelopedData data
287
structure in the PKINIT Reply, for encrypting the reply key with the
289
des-ede3-cbc (3-key 3-DES, CBC mode)
290
rc2-cbc (RC2, CBC mode)
292
The full definition of the above algorithm identifiers and their
293
corresponding parameters (an IV for block chaining) is provided in
294
the CMS specification [11].
296
3.2. Public Key Authentication
298
Implementation of the changes in this section is REQUIRED for
299
compliance with PKINIT.
301
It is assumed that all public keys are signed by some certification
302
authority (CA). The initial authentication request is sent as per
303
RFC 1510, except that a preauthentication field containing data
304
signed by the user's private key accompanies the request:
306
PA-PK-AS-REQ ::= SEQUENCE {
308
signedAuthPack [0] SignedData
309
-- defined in CMS [11]
310
-- AuthPack (below) defines the data
312
trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
313
-- CAs that the client trusts
314
kdcCert [2] IssuerAndSerialNumber OPTIONAL
315
-- as defined in CMS [11]
316
-- specifies a particular KDC
317
-- certificate if the client
319
-- must be accompanied by
320
-- a single trustedCertifier
321
encryptionCert [3] IssuerAndSerialNumber OPTIONAL
322
-- For example, this may be the
323
-- client's Diffie-Hellman
324
-- certificate, or it may be the
325
-- client's RSA encryption
329
TrustedCas ::= CHOICE {
330
principalName [0] KerberosName,
333
-- fully qualified X.500 name
334
-- as defined by X.509
335
issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL
336
-- Since a CA may have a number of
337
-- certificates, only one of which
342
The SignedData data type is specified in the Cryptographic
343
Message Syntax, a product of the S/MIME working group of the IETF.
344
- The encapContentInfo field must contain the PKAuthenticator
345
and, optionally, the client's Diffie Hellman public value.
346
- The eContentType field shall contain the OID value for
347
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
348
pkcs(1) pkcs7(7) data(1)
349
- The eContent field is data of the type AuthPack (below).
350
- The signerInfos field contains the signature of AuthPack.
351
- The Certificates field, when non-empty, contains the client's
352
certificate chain. If present, the KDC uses the public key from
353
the client's certificate to verify the signature in the request.
354
Note that the client may pass different certificates that are used
355
for signing or for encrypting. Thus, the KDC may utilize a
356
different client certificate for signature verification than the
357
one it uses to encrypt the reply to the client. For example, the
358
client may place a Diffie-Hellman certificate in this field in
359
order to convey its static Diffie Hellman certificate to the KDC
360
enable static-ephemeral Diffie-Hellman mode for the reply. As
361
another example, the client may place an RSA encryption
362
certificate in this field.
364
AuthPack ::= SEQUENCE {
365
pkAuthenticator [0] PKAuthenticator,
366
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
367
-- if client is using Diffie-Hellman
370
PKAuthenticator ::= SEQUENCE {
371
kdcName [0] PrincipalName,
374
-- for replay prevention
375
ctime [3] KerberosTime,
376
-- for replay prevention
380
SubjectPublicKeyInfo ::= SEQUENCE {
381
algorithm AlgorithmIdentifier,
383
subjectPublicKey BIT STRING
385
-- public exponent (INTEGER encoded
386
-- as payload of BIT STRING)
387
} -- as specified by the X.509 recommendation [10]
389
AlgorithmIdentifier ::= SEQUENCE {
390
algorithm ALGORITHM.&id,
391
parameters ALGORITHM.&type
392
} -- as specified by the X.509 recommendation [10]
394
If the client passes an issuer and serial number in the request,
395
the KDC is requested to use the referred-to certificate. If none
396
exists, then the KDC returns an error of type
397
KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
398
other hand, the client does not pass any trustedCertifiers,
399
believing that it has the KDC's certificate, but the KDC has more
400
than one certificate. The KDC should include information in the
401
KRB-ERROR message that indicates the KDC certificate(s) that a
402
client may utilize. This data is specified in the e-data, which
403
is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
405
TypedData ::= SEQUENCE {
406
data-type [0] INTEGER,
407
data-value [1] OCTET STRING,
408
} -- per Kerberos RFC 1510 revisions
411
data-type = TD-PKINIT-CMS-CERTIFICATES = 101
412
data-value = CertificateSet // as specified by CMS [11]
414
The PKAuthenticator carries information to foil replay attacks,
415
to bind the request and response. The PKAuthenticator is signed
416
with the private key corresponding to the public key in the
417
certificate found in userCert (or cached by the KDC).
419
The trustedCertifiers field contains a list of certification
420
authorities trusted by the client, in the case that the client does
421
not possess the KDC's public key certificate. If the KDC has no
422
certificate signed by any of the trustedCertifiers, then it returns
423
an error of type KDC_ERR_KDC_NOT_TRUSTED.
425
KDCs should try to (in order of preference):
426
1. Use the KDC certificate identified by the serialNumber included
427
in the client's request.
428
2. Use a certificate issued to the KDC by the client's CA (if in the
429
middle of a CA key roll-over, use the KDC cert issued under same
430
CA key as user cert used to verify request).
431
3. Use a certificate issued to the KDC by one of the client's
433
If the KDC is unable to comply with any of these options, then the
434
KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
437
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
438
type, the KDC attempts to verify the user's certificate chain
439
(userCert), if one is provided in the request. This is done by
440
verifying the certification path against the KDC's policy of
441
legitimate certifiers. This may be based on a certification
442
hierarchy, or it may be simply a list of recognized certifiers in a
445
If the client's certificate chain contains no certificate signed by
446
a CA trusted by the KDC, then the KDC sends back an error message
447
of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data
448
is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
449
whose data-value is an OCTET STRING which is the DER encoding of
451
TrustedCertifiers ::= SEQUENCE OF PrincipalName
452
-- X.500 name encoded as a principal name
455
If the signature on one of the certificates in the client's chain
456
fails verification, then the KDC returns an error of type
457
KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE
458
of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose
459
data-value is an OCTET STRING which is the DER encoding of
461
CertificateIndex ::= INTEGER
462
-- 0 = 1st certificate,
463
-- (in order of encoding)
464
-- 1 = 2nd certificate, etc
466
The KDC may also check whether any of the certificates in the
467
client's chain has been revoked. If one of the certificates has
468
been revoked, then the KDC returns an error of type
469
KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the
470
certificate's revocation status is unknown, the KDC returns an
471
error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation
472
status is unavailable, the KDC returns an error of type
473
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
474
cases, the affected certificate is identified by the accompanying
475
e-data, which contains a CertificateIndex as described for
476
KDC_ERR_INVALID_CERTIFICATE.
478
If the certificate chain can be verified, but the name of the
479
client in the certificate does not match the client's name in the
480
request, then the KDC returns an error of type
481
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
484
Finally, if the certificate chain is verified, but the KDC's name
485
or realm as given in the PKAuthenticator does not match the KDC's
486
actual principal name, then the KDC returns an error of type
487
KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again
488
a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
489
TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
490
STRING whose data-value is the DER encoding of a PrincipalName or
491
Realm as defined in RFC 1510 revisions.
493
Even if all succeeds, the KDC may--for policy reasons--decide not
494
to trust the client. In this case, the KDC returns an error message
495
of type KDC_ERR_CLIENT_NOT_TRUSTED.
497
If a trust relationship exists, the KDC then verifies the client's
498
signature on AuthPack. If that fails, the KDC returns an error
499
message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
500
timestamp (ctime and cusec) in the PKAuthenticator to assure that
501
the request is not a replay. The KDC also verifies that its name
502
is specified in the PKAuthenticator.
504
If the clientPublicValue field is filled in, indicating that the
505
client wishes to use Diffie-Hellman key agreement, then the KDC
506
checks to see that the parameters satisfy its policy. If they do
507
not (e.g., the prime size is insufficient for the expected
508
encryption type), then the KDC sends back an error message of type
509
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
510
private values for the response.
512
The KDC also checks that the timestamp in the PKAuthenticator is
513
within the allowable window and that the principal name and realm
514
are correct. If the local (server) time and the client time in the
515
authenticator differ by more than the allowable clock skew, then the
516
KDC returns an error message of type KRB_AP_ERR_SKEW.
518
Assuming no errors, the KDC replies as per RFC 1510, except as
519
follows. The user's name in the ticket is determined by the
520
following decision algorithm:
522
1. If the KDC has a mapping from the name in the certificate
523
to a Kerberos name, then use that name.
525
2. If the certificate contains a Kerberos name in an extension
526
field, and local KDC policy allows, then use that name.
528
3. Use the name as represented in the certificate, mapping
529
as necessary (e.g., as per RFC 2253 for X.500 names). In
530
this case the realm in the ticket shall be the name of the
531
certification authority that issued the user's certificate.
533
The KDC encrypts the reply not with the user's long-term key, but
534
with a random key generated only for this particular response. This
535
random key is sealed in the preauthentication field:
537
PA-PK-AS-REP ::= CHOICE {
539
dhSignedData [0] SignedData,
540
-- Defined in CMS and used only with
541
-- Diffie-Helman key exchange
542
-- This choice MUST be supported
543
-- by compliant implementations.
544
encKeyPack [1] EnvelopedData,
546
-- The temporary key is encrypted
547
-- using the client public key
549
-- SignedReplyKeyPack, encrypted
550
-- with the temporary key, is also
555
If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
556
provides authenticated Diffie-Hellman parameters of the KDC. The
557
reply key used to encrypt part of the KDC reply message is derived
558
from the Diffie-Hellman exchange:
559
- Both the KDC and the client calculate a secret value (g^ab mod p),
560
where a is the client's private exponent and b is the KDC's
562
- Both the KDC and the client take the first N bits of this secret
563
value and convert it into a reply key. N depends on the reply key
565
- If the reply key is DES, N=64 bits, where some of the bits are
566
replaced with parity bits, according to FIPS PUB 74.
567
- If the reply key is (3-key) 3-DES, N=192 bits, where some of the
568
bits are replaced with parity bits, according to FIPS PUB 74.
569
- The encapContentInfo field must contain the KdcDHKeyInfo as
571
- The eContentType field shall contain the OID value for
572
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
573
pkcs(1) pkcs7(7) data(1)
574
- The certificates field must contain the certificates necessary
575
for the client to establish trust in the KDC's certificate
576
based on the list of trusted certifiers sent by the client in
577
the PA-PK-AS-REQ. This field may be empty if the client did
578
not send to the KDC a list of trusted certifiers (the
579
trustedCertifiers field was empty, meaning that the client
580
already possesses the KDC's certificate).
581
- The signerInfos field is a SET that must contain at least one
582
member, since it contains the actual signature.
584
Usage of EnvelopedData:
585
The EnvelopedData data type is specified in the Cryptographic
586
Message Syntax, a product of the S/MIME working group of the IETF.
587
It contains an temporary key encrypted with the PKINIT
588
client's public key. It also contains a signed and encrypted
590
- The originatorInfo field is not required, since that information
591
may be presented in the signedData structure that is encrypted
592
within the encryptedContentInfo field.
593
- The optional unprotectedAttrs field is not required for PKINIT.
594
- The recipientInfos field is a SET which must contain exactly one
595
member of the KeyTransRecipientInfo type for encryption
596
with an RSA public key.
597
- The encryptedKey field (in KeyTransRecipientInfo) contains
598
the temporary key which is encrypted with the PKINIT client's
600
- The encryptedContentInfo field contains the signed and encrypted
602
- The contentType field shall contain the OID value for
603
id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
604
pkcs(1) pkcs7(7) signedData(2)
605
- The encryptedContent field is encrypted data of the CMS type
606
signedData as specified below.
607
- The encapContentInfo field must contains the ReplyKeyPack.
608
- The eContentType field shall contain the OID value for
609
id-data: iso(1) member-body(2) us(840) rsadsi(113549)
610
pkcs(1) pkcs7(7) data(1)
611
- The eContent field is data of the type ReplyKeyPack (below).
612
- The certificates field must contain the certificates necessary
613
for the client to establish trust in the KDC's certificate
614
based on the list of trusted certifiers sent by the client in
615
the PA-PK-AS-REQ. This field may be empty if the client did
616
not send to the KDC a list of trusted certifiers (the
617
trustedCertifiers field was empty, meaning that the client
618
already possesses the KDC's certificate).
619
- The signerInfos field is a SET that must contain at least one
620
member, since it contains the actual signature.
622
KdcDHKeyInfo ::= SEQUENCE {
623
-- used only when utilizing Diffie-Hellman
625
-- binds responce to the request
626
subjectPublicKey [2] BIT STRING
627
-- Equals public exponent (g^a mod p)
628
-- INTEGER encoded as payload of
632
ReplyKeyPack ::= SEQUENCE {
633
-- not used for Diffie-Hellman
634
replyKey [0] EncryptionKey,
635
-- used to encrypt main reply
636
-- ENCTYPE is at least as strong as
637
-- ENCTYPE of session key
639
-- binds response to the request
640
-- must be same as the nonce
641
-- passed in the PKAuthenticator
645
Since each certifier in the certification path of a user's
646
certificate is essentially a separate realm, the name of each
647
certifier must be added to the transited field of the ticket. The
648
format of these realm names is defined in Section 3.1 of this
649
document. If applicable, the transit-policy-checked flag should be
650
set in the issued ticket.
652
The KDC's certificate must bind the public key to a name derivable
653
from the name of the realm for that KDC. X.509 certificates shall
654
contain the principal name of the KDC as the SubjectAltName version
655
3 extension. Below is the definition of this version 3 extension, as
656
specified by the X.509 standard:
658
subjectAltName EXTENSION ::= {
660
IDENTIFIED BY id-ce-subjectAltName
663
GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
665
GeneralName ::= CHOICE {
666
otherName [0] INSTANCE OF OTHER-NAME,
670
OTHER-NAME ::= TYPE-IDENTIFIER
672
In this definition, otherName is a name of any form defined as an
673
instance of the OTHER-NAME information object class. For the purpose
674
of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
675
be chosen and replaced by the type KerberosName:
677
KerberosName ::= SEQUENCE {
679
-- as define in RFC 1510
680
principalName [1] PrincipalName,
681
-- as define in RFC 1510
684
This specific syntax is identified within subjectAltName by setting
685
the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
686
Kerberos specification) we have
688
krb5 OBJECT IDENTIFIER ::= { iso (1)
695
krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
697
This specification may also be used to specify a Kerberos name
698
within the user's certificate.
700
If a non-KDC X.509 certificate contains the principal name within
701
the subjectAltName version 3 extension , that name may utilize
702
KerberosName as defined below, or, in the case of an S/MIME
703
certificate [17], may utilize the email address. If the KDC
704
is presented with as S/MIME certificate, then the email address
705
within subjectAltName will be interpreted as a principal and realm
706
separated by the "@" sign, or as a name that needs to be
707
canonicalized. If the resulting name does not correspond to a
708
registered principal name, then the principal name is formed as
709
defined in section 3.1.
711
The client then extracts the random key used to encrypt the main
712
reply. This random key (in encPaReply) is encrypted with either the
713
client's public key or with a key derived from the DH values
714
exchanged between the client and the KDC.
716
3.2.2. Required Algorithms
718
Not all of the algorithms in the PKINIT protocol specification have
719
to be implemented in order to comply with the proposed standard.
720
Below is a list of the required algorithms:
722
- Diffie-Hellman public/private key pairs
723
- utilizing Diffie-Hellman ephemeral-ephemeral mode
724
- SHA1 digest and DSA for signatures
725
- 3-key triple DES keys derived from the Diffie-Hellman Exchange
726
- 3-key triple DES Temporary and Reply keys
728
4. Logistics and Policy
730
This section describes a way to define the policy on the use of
731
PKINIT for each principal and request.
733
The KDC is not required to contain a database record for users
734
who use public key authentication. However, if these users are
735
registered with the KDC, it is recommended that the database record
736
for these users be modified to an additional flag in the attributes
737
field to indicate that the user should authenticate using PKINIT.
738
If this flag is set and a request message does not contain the
739
PKINIT preauthentication field, then the KDC sends back as error of
740
type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
741
field of type PA-PK-AS-REQ must be included in the request.
743
5. Security Considerations
745
PKINIT raises a few security considerations, which we will address
748
First of all, PKINIT introduces a new trust model, where KDCs do not
749
(necessarily) certify the identity of those for whom they issue
750
tickets. PKINIT does allow KDCs to act as their own CAs, in order
751
to simplify key management, but one of the additional benefits is to
752
align Kerberos authentication with a global public key
753
infrastructure. Anyone using PKINIT in this way must be aware of
754
how the certification infrastructure they are linking to works.
756
Secondly, PKINIT also introduces the possibility of interactions
757
between different cryptosystems, which may be of widely varying
758
strengths. Many systems, for instance, allow the use of 512-bit
759
public keys. Using such keys to wrap data encrypted under strong
760
conventional cryptosystems, such as triple-DES, is inappropriate;
761
it adds a weak link to a strong one at extra cost. Implementors
762
and administrators should take care to avoid such wasteful and
763
deceptive interactions.
765
Lastly, PKINIT calls for randomly generated keys for conventional
766
cryptosystems. Many such systems contain systematically "weak"
767
keys. PKINIT implementations MUST avoid use of these keys, either
768
by discarding those keys when they are generated, or by fixing them
769
in some way (e.g., by XORing them with a given mask). These
770
precautions vary from system to system; it is not our intention to
771
give an explicit recipe for them here.
775
Certificate chains can potentially grow quite large and span several
776
UDP packets; this in turn increases the probability that a Kerberos
777
message involving PKINIT extensions will be broken in transit. In
778
light of the possibility that the Kerberos specification will
779
require KDCs to accept requests using TCP as a transport mechanism,
780
we make the same recommendation with respect to the PKINIT
785
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
786
(V5). Request for Comments 1510.
788
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
789
for Computer Networks, IEEE Communications, 32(9):33-38. September
792
[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
793
A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
794
Authentication in Kerberos.
795
draft-ietf-cat-kerberos-pk-cross-04.txt
797
[4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
799
draft-ietf-cat-kerberos-anoncred-00.txt
801
[5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
802
Tickets for Application Servers (PKTAPP).
803
draft-ietf-cat-pktapp-00.txt
805
[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
806
Using Public Key Cryptography. Symposium On Network and Distributed
807
System Security, 1997.
809
[7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
810
Protocol. In Proceedings of the USENIX Workshop on Electronic
813
[8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
814
Request for Comments 2246, January 1999.
816
[9] B.C. Neuman, Proxy-Based Authorization and Accounting for
817
Distributed Systems. In Proceedings of the 13th International
818
Conference on Distributed Computing Systems, May 1993.
820
[10] ITU-T (formerly CCITT) Information technology - Open Systems
821
Interconnection - The Directory: Authentication Framework
822
Recommendation X.509 ISO/IEC 9594-8
824
[11] R. Housley. Cryptographic Message Syntax.
825
draft-ietf-smime-cms-13.txt, April 1999.
827
[12] PKCS #7: Cryptographic Message Syntax Standard,
828
An RSA Laboratories Technical Note Version 1.5
829
Revised November 1, 1993
831
[13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
832
Security, Inc. A Description of the RC2(r) Encryption Algorithm
834
Request for Comments 2268.
836
[14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
837
Protocol (v3): UTF-8 String Representation of Distinguished Names.
838
Request for Comments 2253.
840
[15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
841
Key Infrastructure, Certificate and CRL Profile, January 1999.
842
Request for Comments 2459.
844
[16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
845
Specifications, October 1998.
846
Request for Comments 2437.
848
[17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.
849
S/MIME Version 2 Certificate Handling, March 1998.
850
Request for Comments 2312
854
Some of the ideas on which this proposal is based arose during
855
discussions over several years between members of the SAAG, the IETF
856
CAT working group, and the PSRG, regarding integration of Kerberos
857
and SPX. Some ideas have also been drawn from the DASS system.
858
These changes are by no means endorsed by these groups. This is an
859
attempt to revive some of the goals of those groups, and this
860
proposal approaches those goals primarily from the Kerberos
861
perspective. Lastly, comments from groups working on similar ideas
862
in DCE have been invaluable.
866
This draft expires December 1, 1999.
872
USC Information Sciences Institute
873
4676 Admiralty Way Suite 1001
874
Marina del Rey CA 90292-6695
875
Phone: +1 310 822 1511
876
E-mail: {brian, bcn}@isi.edu
879
CyberSafe Corporation
880
1605 NW Sammamish Road
881
Issaquah WA 98027-5378
882
Phone: +1 425 391 6000
883
E-mail: matt.hur@cybersafe.com
888
Redwood City, CA 94063
889
Phone +1 650 569 2119
890
E-mail: amedvins@excitecorp.com
896
Phone +1 619 404 2825
897
E-mail: smedvinsky@gi.com
900
Iris Associates, Inc.
901
5 Technology Park Dr.
903
E-mail: John_Wray@iris.com
908
E-mail: jtrostle@cisco.com
added
removed
doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt
