1
INTERNET-DRAFT Brian Tung
2
draft-ietf-cat-kerberos-pk-init-05.txt Clifford Neuman
4
expires May 26, 1998 John Wray
5
Digital Equipment Corporation
13
Public Key Cryptography for Initial Authentication in Kerberos
16
0. Status Of This Memo
18
This document is an Internet-Draft. Internet-Drafts are working
19
documents of the Internet Engineering Task Force (IETF), its
20
areas, and its working groups. Note that other groups may also
21
distribute working documents as Internet-Drafts.
23
Internet-Drafts are draft documents valid for a maximum of six
24
months and may be updated, replaced, or obsoleted by other
25
documents at any time. It is inappropriate to use Internet-Drafts
26
as reference material or to cite them other than as "work in
29
To learn the current status of any Internet-Draft, please check
30
the "1id-abstracts.txt" listing contained in the Internet-Drafts
31
Shadow Directories on ds.internic.net (US East Coast),
32
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
33
munnari.oz.au (Pacific Rim).
35
The distribution of this memo is unlimited. It is filed as
36
draft-ietf-cat-kerberos-pk-init-05.txt, and expires May 26, 1998.
37
Please send comments to the authors.
42
This document defines extensions (PKINIT) to the Kerberos protocol
43
specification (RFC 1510 [1]) to provide a method for using public
44
key cryptography during initial authentication. The methods
45
defined specify the ways in which preauthentication data fields and
46
error data fields in Kerberos messages are to be used to transport
52
The popularity of public key cryptography has produced a desire for
53
its support in Kerberos [2]. The advantages provided by public key
54
cryptography include simplified key management (from the Kerberos
55
perspective) and the ability to leverage existing and developing
56
public key certification infrastructures.
58
Public key cryptography can be integrated into Kerberos in a number
59
of ways. One is to associate a key pair with each realm, which can
60
then be used to facilitate cross-realm authentication; this is the
61
topic of another draft proposal. Another way is to allow users with
62
public key certificates to use them in initial authentication. This
63
is the concern of the current document.
65
One of the guiding principles in the design of PKINIT is that
66
changes should be as minimal as possible. As a result, the basic
67
mechanism of PKINIT is as follows: The user sends a request to the
68
KDC as before, except that if that user is to use public key
69
cryptography in the initial authentication step, his certificate
70
accompanies the initial request, in the preauthentication fields.
72
Upon receipt of this request, the KDC verifies the certificate and
73
issues a ticket granting ticket (TGT) as before, except that
74
the encPart from the AS-REP message carrying the TGT is now
75
encrypted in a randomly-generated key, instead of the user's
76
long-term key (which is derived from a password). This
77
random key is in turn encrypted using the public key from the
78
certificate that came with the request and signed using the KDC's
79
private key, and accompanies the reply, in the preauthentication
82
PKINIT also allows for users with only digital signature keys to
83
authenticate using those keys, and for users to store and retrieve
84
private keys on the KDC.
86
The PKINIT specification may also be used for direct peer to peer
87
authentication without contacting a central KDC. This application
88
of PKINIT is described in PKTAPP [4] and is based on concepts
89
introduced in [5, 6]. For direct client-to-server authentication,
90
the client uses PKINIT to authenticate to the end server (instead
91
of a central KDC), which then issues a ticket for itself. This
92
approach has an advantage over SSL [7] in that the server does not
93
need to save state (cache session keys). Furthermore, an
94
additional benefit is that Kerberos tickets can facilitate
98
3. Proposed Extensions
100
This section describes extensions to RFC 1510 for supporting the
101
use of public key cryptography in the initial request for a ticket
102
granting ticket (TGT).
104
In summary, the following changes to RFC 1510 are proposed:
106
* Users may authenticate using either a public key pair or a
107
conventional (symmetric) key. If public key cryptography is
108
used, public key data is transported in preauthentication
109
data fields to help establish identity.
110
* Users may store private keys on the KDC for retrieval during
111
Kerberos initial authentication.
113
This proposal addresses two ways that users may use public key
114
cryptography for initial authentication. Users may present public
115
key certificates, or they may generate their own session key,
116
signed by their digital signature key. In either case, the end
117
result is that the user obtains an ordinary TGT that may be used for
118
subsequent authentication, with such authentication using only
119
conventional cryptography.
121
Section 3.1 provides definitions to help specify message formats.
122
Section 3.2 and 3.3 describe the extensions for the two initial
123
authentication methods. Section 3.4 describes a way for the user to
124
store and retrieve his private key on the KDC, as an adjunct to the
125
initial authentication.
130
The extensions involve new encryption methods; we propose the
131
addition of the following types:
139
The proposal of these encryption types notwithstanding, we do not
140
mandate the use of any particular public key encryption method.
142
The extensions involve new preauthentication fields; we propose the
143
addition of the following types:
151
The extensions also involve new error types; we propose the addition
152
of the following types:
154
KDC_ERR_CLIENT_NOT_TRUSTED 62
155
KDC_ERR_KDC_NOT_TRUSTED 63
156
KDC_ERR_INVALID_SIG 64
157
KDC_ERR_KEY_TOO_WEAK 65
158
KDC_ERR_CERTIFICATE_MISMATCH 66
160
In many cases, PKINIT requires the encoding of an X.500 name as a
161
Realm. In these cases, the realm will be represented using a
162
different style, specified in RFC 1510 with the following example:
164
NAMETYPE:rest/of.name=without-restrictions
166
For a realm derived from an X.500 name, NAMETYPE will have the value
167
X500-RFC1779. The full realm name will appear as follows:
169
X500-RFC1779:RFC1779Encode(DistinguishedName)
171
where DistinguishedName is an X.500 name, and RFC1779Encode is a
172
readable ASCII encoding of an X.500 name, as defined by RFC 1779.
173
To ensure that this encoding is unique, we add the following rules
174
to those specified by RFC 1779:
176
* The optional spaces specified in RFC 1779 are not allowed.
177
* The character that separates relative distinguished names
178
must be ',' (i.e., it must never be ';').
179
* Attribute values must not be enclosed in double quotes.
180
* Attribute values must not be specified as hexadecimal
182
* When an attribute name is specified in the form of an OID,
183
it must start with the 'OID.' prefix, and not the 'oid.'
185
* The order in which the attributes appear in the RFC 1779
186
encoding must be the reverse of the order in the ASN.1
187
encoding of the X.500 name that appears in the public key
188
certificate, because RFC 1779 requires that the least
189
significant relative distinguished name appear first. The
190
order of the relative distinguished names, as well as the
191
order of the attributes within each relative distinguished
192
name, will be reversed.
194
Similarly, PKINIT may require the encoding of an X.500 name as a
195
PrincipalName. In these cases, the name-type of the principal name
196
shall be set to NT-X500-PRINCIPAL. This new name type is defined
198
#define CSFC5c_NT_X500_PRINCIPAL 6
200
The name-string shall be set as follows:
202
RFC1779Encode(DistinguishedName)
207
3.1.1. Encryption and Key Formats
209
In the exposition below, we use the terms public key and private
210
key generically. It should be understood that the term "public
211
key" may be used to refer to either a public encryption key or a
212
signature verification key, and that the term "private key" may be
213
used to refer to either a private decryption key or a signature
214
generation key. The fact that these are logically distinct does
215
not preclude the assignment of bitwise identical keys.
217
All additional symmetric keys specified in this draft shall use the
218
same encryption type as the session key in the response from the
219
KDC. These include the temporary keys used to encrypt the signed
220
random key encrypting the response, as well as the key derived from
221
Diffie-Hellman agreement. In the case of Diffie-Hellman, the key
222
shall be produced from the agreed bit string as follows:
224
* Truncate the bit string to the appropriate length.
225
* Rectify parity in each byte (if necessary) to obtain the key.
227
For instance, in the case of a DES key, we take the first eight
228
bytes of the bit stream, and then adjust the least significant bit
229
of each byte to ensure that each byte has odd parity.
231
RFC 1510, Section 6.1, defines EncryptedData as follows:
233
EncryptedData ::= SEQUENCE {
235
kvno [1] INTEGER OPTIONAL,
236
cipher [2] OCTET STRING
240
RFC 1510 also defines how CipherText is to be composed. It is not
241
an ASN.1 data structure, but rather an octet string which is the
242
encryption of a plaintext string. This plaintext string is in turn
243
a concatenation of the following octet strings: a confounder, a
244
checksum, the message, and padding. Details of how these components
245
are arranged can be found in RFC 1510.
247
The PKINIT protocol introduces several new types of encryption.
248
Data that is encrypted with a public key will allow only the check
249
optional field, as it is defined above. This type of the checksum
250
will be specified in the etype field, together with the encryption
253
In order to identify the checksum type, etype will have the
259
In the case that etype is set to rsa-pub, the optional 'check'
260
field will not be provided.
262
Data that is encrypted with a private key will not use any optional
263
fields. PKINIT uses private key encryption only for signatures,
264
which are encrypted checksums. Therefore, the optional check field
268
3.2. Standard Public Key Authentication
270
Implementation of the changes in this section is REQUIRED for
271
compliance with PKINIT.
273
It is assumed that all public keys are signed by some certification
274
authority (CA). The initial authentication request is sent as per
275
RFC 1510, except that a preauthentication field containing data
276
signed by the user's private key accompanies the request:
278
PA-PK-AS-REQ ::= SEQUENCE {
280
signedAuthPack [0] SignedAuthPack
281
userCert [1] SEQUENCE OF Certificate OPTIONAL,
282
-- the user's certificate chain
283
trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL,
284
-- CAs that the client trusts
285
serialNumber [3] CertificateSerialNumber OPTIONAL
286
-- specifying a particular
287
-- certificate if the client
289
-- must be accompanied by
290
-- a single trustedCertifier
293
CertificateSerialNumber ::= INTEGER
294
-- as specified by PKCS 6
296
SignedAuthPack ::= SEQUENCE {
297
authPack [0] AuthPack,
298
authPackSig [1] Signature,
300
-- using user's private key
303
AuthPack ::= SEQUENCE {
304
pkAuthenticator [0] PKAuthenticator,
305
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
306
-- if client is using Diffie-Hellman
309
PKAuthenticator ::= SEQUENCE {
310
kdcName [0] PrincipalName,
313
-- for replay prevention
314
ctime [3] KerberosTime,
315
-- for replay prevention
319
Signature ::= SEQUENCE {
320
signedHash [0] EncryptedData
324
Checksum ::= SEQUENCE {
325
cksumtype [0] INTEGER,
326
checksum [1] OCTET STRING
327
} -- as specified by RFC 1510
329
SubjectPublicKeyInfo ::= SEQUENCE {
330
algorithm [0] AlgorithmIdentifier,
331
subjectPublicKey [1] BIT STRING
333
-- public exponent (INTEGER encoded
334
-- as payload of BIT STRING)
335
} -- as specified by the X.509 recommendation [9]
337
AlgorithmIdentifier ::= SEQUENCE {
338
algorithm [0] ALGORITHM.&id,
341
-- ({iso(1) member-body(2) US(840)
342
-- rsadsi(113549) pkcs(1) pkcs-3(3)
344
parameters [1] ALGORITHM.&type
345
-- for DH, is DHParameter
346
} -- as specified by the X.509 recommendation [9]
348
DHParameter ::= SEQUENCE {
353
privateValueLength [2] INTEGER OPTIONAL
356
Certificate ::= SEQUENCE {
357
certType [0] INTEGER,
358
-- type of certificate
359
-- 1 = X.509v3 (DER encoding)
360
-- 2 = PGP (per PGP specification)
361
certData [1] OCTET STRING
362
-- actual certificate
363
-- type determined by certType
366
If the client passes a certificate serial number in the request,
367
the KDC is requested to use the referred-to certificate. If none
368
exists, then the KDC returns an error of type
369
KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
370
other hand, the client does not pass any trustedCertifiers,
371
believing that it has the KDC's certificate, but the KDC has more
372
than one certificate.
374
The PKAuthenticator carries information to foil replay attacks,
375
to bind the request and response, and to optionally pass the
376
client's Diffie-Hellman public value (i.e. for using DSA in
377
combination with Diffie-Hellman). The PKAuthenticator is signed
378
with the private key corresponding to the public key in the
379
certificate found in userCert (or cached by the KDC).
381
In the PKAuthenticator, the client may specify the KDC name in one
384
* The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
385
where <realm_name> is replaced by the applicable realm name.
386
* The name in the KDC's certificate (e.g., an X.500 name, or a
389
Note that the first case requires that the certificate name and the
390
Kerberos principal name be bound together (e.g., via an X.509v3
393
The userCert field is a sequence of certificates, the first of which
394
must be the user's public key certificate. Any subsequent
395
certificates will be certificates of the certifiers of the user's
396
certificate. These cerificates may be used by the KDC to verify the
397
user's public key. This field may be left empty if the KDC already
398
has the user's certificate.
400
The trustedCertifiers field contains a list of certification
401
authorities trusted by the client, in the case that the client does
402
not possess the KDC's public key certificate. If the KDC has no
403
certificate signed by any of the trustedCertifiers, then it returns
404
an error of type KDC_ERR_CERTIFICATE_MISMATCH.
406
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
407
type, the KDC attempts to verify the user's certificate chain
408
(userCert), if one is provided in the request. This is done by
409
verifying the certification path against the KDC's policy of
410
legitimate certifiers. This may be based on a certification
411
hierarchy, or it may be simply a list of recognized certifiers in a
414
If verification of the user's certificate fails, the KDC sends back
415
an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data
416
field contains additional information pertaining to this error, and
417
is formatted as follows:
419
METHOD-DATA ::= SEQUENCE {
420
method-type [0] INTEGER,
421
-- 1 = cannot verify public key
422
-- 2 = invalid certificate
423
-- 3 = revoked certificate
424
-- 4 = invalid KDC name
425
-- 5 = client name mismatch
426
method-data [1] OCTET STRING OPTIONAL
427
} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
429
The values for the method-type and method-data fields are described
432
If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
433
verifies that it has a certificate issued by one of the certifiers
434
trusted by the client. If it does not have a suitable certificate,
435
the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
438
If a trust relationship exists, the KDC then verifies the client's
439
signature on AuthPack. If that fails, the KDC returns an error
440
message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
441
timestamp in the PKAuthenticator to assure that the request is not a
442
replay. The KDC also verifies that its name is specified in the
445
If the clientPublicValue field is filled in, indicating that the
446
client wishes to use Diffie-Hellman key agreement, then the KDC
447
checks to see that the parameters satisfy its policy. If they do
448
not (e.g., the prime size is insufficient for the expected
449
encryption type), then the KDC sends back an error message of type
450
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
451
private values for the response.
453
The KDC also checks that the timestamp in the PKAuthenticator is
454
within the allowable window. If the local (server) time and the
455
client time in the authenticator differ by more than the allowable
456
clock skew, then the KDC returns an error message of type
459
Assuming no errors, the KDC replies as per RFC 1510, except as
460
follows: The user's name in the ticket is as represented in the
461
certificate, unless a Kerberos principal name is bound to the name
462
in the certificate (e.g., via an X.509v3 extension). The user's
463
realm in the ticket shall be the name of the Certification
464
Authority that issued the user's public key certificate.
466
The KDC encrypts the reply not with the user's long-term key, but
467
with a random key generated only for this particular response. This
468
random key is sealed in the preauthentication field:
470
PA-PK-AS-REP ::= SEQUENCE {
472
encSignedReplyKeyPack [0] EncryptedData,
473
-- of type SignedReplyKeyPack
474
-- using the temporary key
476
encTmpKeyPack [1] EncryptedData,
477
-- of type TmpKeyPack
478
-- using either the client public
479
-- key or the Diffie-Hellman key
480
-- specified by SignedDHPublicValue
481
signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL
482
-- if one was passed in the request
483
kdcCert [3] SEQUENCE OF Certificate OPTIONAL,
484
-- the KDC's certificate chain
487
SignedReplyKeyPack ::= SEQUENCE {
488
replyKeyPack [0] ReplyKeyPack,
489
replyKeyPackSig [1] Signature,
490
-- of replyEncKeyPack
491
-- using KDC's private key
494
ReplyKeyPack ::= SEQUENCE {
495
replyKey [0] EncryptionKey,
496
-- used to encrypt main reply
497
-- of same ENCTYPE as session key
499
-- binds response to the request
500
-- must be same as the nonce
501
-- passed in the PKAuthenticator
504
TmpKeyPack ::= SEQUENCE {
505
tmpKey [0] EncryptionKey,
506
-- used to encrypt the
507
-- SignedReplyKeyPack
508
-- of same ENCTYPE as session key
511
SignedKDCPublicValue ::= SEQUENCE {
512
kdcPublicValue [0] SubjectPublicKeyInfo,
513
-- as described above
514
kdcPublicValueSig [1] Signature
516
-- using KDC's private key
519
The kdcCert field is a sequence of certificates, the first of which
520
must be the KDC's public key certificate. Any subsequent
521
certificates will be certificates of the certifiers of the KDC's
522
certificate. The last of these must have as its certifier one of
523
the certifiers sent to the KDC in the PA-PK-AS-REQ. These
524
cerificates may be used by the client to verify the KDC's public
525
key. This field is empty if the client did not send to the KDC a
526
list of trusted certifiers (the trustedCertifiers field was empty).
528
Since each certifier in the certification path of a user's
529
certificate is essentially a separate realm, the name of each
530
certifier shall be added to the transited field of the ticket. The
531
format of these realm names is defined in Section 3.1 of this
532
document. If applicable, the transit-policy-checked flag should be
533
set in the issued ticket.
535
The KDC's certificate must bind the public key to a name derivable
536
from the name of the realm for that KDC. For an X.509 certificate,
537
this is done as follows. The name of the KDC will be represented
538
as an OtherName, encoded as a GeneralString:
540
GeneralName ::= CHOICE {
541
otherName [0] KDCPrincipalName,
545
KDCPrincipalNameTypes OTHER-NAME ::= {
546
{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
549
KDCPrincipalName ::= SEQUENCE {
550
nameType OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
551
name OTHER-NAME.&type ( { KDCPrincipalNameTypes }
555
PrincipalNameSrvInst ::= GeneralString
557
where (from the Kerberos specification) we have
559
krb5 OBJECT IDENTIFIER ::= { iso (1)
566
principalName OBJECT IDENTIFIER ::= { krb5 2 }
568
principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
570
The client then extracts the random key used to encrypt the main
571
reply. This random key (in encPaReply) is encrypted with either the
572
client's public key or with a key derived from the DH values
573
exchanged between the client and the KDC.
576
3.2.1. Additional Information for Errors
578
This section describes the interpretation of the method-type and
579
method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
581
If method-type=1, the client's public key certificate chain does not
582
contain a certificate that is signed by a certification authority
583
trusted by the KDC. The format of the method-data field will be an
584
ASN.1 encoding of a list of trusted certifiers, as defined above:
586
TrustedCertifiers ::= SEQUENCE OF PrincipalName
588
If method-type=2, the signature on one of the certificates in the
589
chain cannot be verified. The format of the method-data field will
590
be an ASN.1 encoding of the integer index of the certificate in
593
CertificateIndex ::= INTEGER
594
-- 0 = 1st certificate,
595
-- 1 = 2nd certificate, etc
597
If method-type=3, one of the certificates in the chain has been
598
revoked. The format of the method-data field will be an ASN.1
599
encoding of the integer index of the certificate in question:
601
CertificateIndex ::= INTEGER
602
-- 0 = 1st certificate,
603
-- 1 = 2nd certificate, etc
605
If method-type=4, the KDC name or realm in the PKAuthenticator does
606
not match the principal name of the KDC. There is no method-data
609
If method-type=5, the client name or realm in the certificate does
610
not match the principal name of the client. There is no
611
method-data field in this case.
614
3.3. Digital Signature
616
Implementation of the changes in this section are OPTIONAL for
617
compliance with PKINIT.
619
We offer this option with the warning that it requires the client to
620
generate a random key; the client may not be able to guarantee the
621
same level of randomness as the KDC.
623
If the user registered, or presents a certificate for, a digital
624
signature key with the KDC instead of an encryption key, then a
625
separate exchange must be used. The client sends a request for a
626
TGT as usual, except that it (rather than the KDC) generates the
627
random key that will be used to encrypt the KDC response. This key
628
is sent to the KDC along with the request in a preauthentication
629
field, encrypted with the KDC's public key:
631
PA-PK-AS-SIGN ::= SEQUENCE {
633
encSignedRandomKeyPack [0] EncryptedData,
634
-- of type SignedRandomKeyPack
635
-- using the key in encTmpKeyPack
636
encTmpKeyPack [1] EncryptedData,
637
-- of type TmpKeyPack
638
-- using the KDC's public key
639
userCert [2] SEQUENCE OF Certificate OPTIONAL
640
-- the user's certificate chain
643
SignedRandomKeyPack ::= SEQUENCE {
644
randomkeyPack [0] RandomKeyPack,
645
randomkeyPackSig [1] Signature
647
-- using user's private key
650
RandomKeyPack ::= SEQUENCE {
651
randomKey [0] EncryptionKey,
652
-- will be used to encrypt reply
653
randomKeyAuth [1] PKAuthenticator
654
-- nonce copied from AS-REQ
657
If the KDC does not accept client-generated random keys as a matter
658
of policy, then it sends back an error message of type
659
KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as
662
Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
663
the randomKey. It then replies as per RFC 1510, except that the
664
reply is encrypted not with a password-derived user key, but with
665
the randomKey sent in the request. Since the client already knows
666
this key, there is no need to accompany the reply with an extra
667
preauthentication field. The transited field of the ticket should
668
specify the certification path as described in Section 3.2.
671
3.4. Retrieving the User's Private Key from the KDC
673
Implementation of the changes described in this section are OPTIONAL
674
for compliance with PKINIT.
676
When the user's private key is not stored local to the user, he may
677
choose to store the private key (normally encrypted using a
678
password-derived key) on the KDC. In this case, the client makes a
679
request as described above, except that instead of preauthenticating
680
with his private key, he uses a symmetric key shared with the KDC.
682
For simplicity's sake, this shared key is derived from the password-
683
derived key used to encrypt the private key, in such a way that the
684
KDC can authenticate the user with the shared key without being able
685
to extract the private key.
687
We provide this option to present the user with an alternative to
688
storing the private key on local disk at each machine where he
689
expects to authenticate himself using PKINIT. It should be noted
690
that it replaces the added risk of long-term storage of the private
691
key on possibly many workstations with the added risk of storing the
692
private key on the KDC in a form vulnerable to brute-force attack.
694
Denote by K1 the symmetric key used to encrypt the private key.
695
Then construct symmetric key K2 as follows:
697
* Perform a hash on K1.
698
* Truncate the digest to Length(K1) bytes.
699
* Rectify parity in each byte (if necessary) to obtain K2.
701
The KDC stores K2, the public key, and the encrypted private key.
702
This key pair is designated as the "primary" key pair for that user.
703
This primary key pair is the one used to perform initial
704
authentication using the PA-PK-AS-REP preauthentication field. If
705
he desires, he may also store additional key pairs on the KDC; these
706
may be requested in addition to the primary. When the client
707
requests initial authentication using public key cryptography, it
708
must then include in its request, instead of a PA-PK-AS-REQ, the
709
following preauthentication sequence:
711
PA-PK-KEY-REQ ::= SEQUENCE {
713
signedPKAuth [0] SignedPKAuth,
714
trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
715
-- CAs that the client trusts
716
keyIDList [2] SEQUENCE OF Checksum OPTIONAL
717
-- payload is hash of public key
718
-- corresponding to desired
720
-- if absent, KDC will return all
721
-- stored private keys
724
SignedPKAuth ::= SEQUENCE {
725
pkAuth [0] PKAuthenticator,
726
pkAuthSig [1] Signature
728
-- using the symmetric key K2
731
If a keyIDList is present, the first identifier should indicate
732
the primary private key. No public key certificate is required,
733
since the KDC stores the public key along with the private key.
734
If there is no keyIDList, all the user's private keys are returned.
736
Upon receipt, the KDC verifies the signature using K2. If the
737
verification fails, the KDC sends back an error of type
738
KDC_ERR_INVALID_SIG. If the signature verifies, but the requested
739
keys are not found on the KDC, then the KDC sends back an error of
740
type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as
741
described in Section 3.2, except that in addition, the KDC appends
742
the following preauthentication sequence:
744
PA-PK-KEY-REP ::= SEQUENCE {
746
encKeyRep [0] EncryptedData
747
-- of type EncKeyReply
748
-- using the symmetric key K2
751
EncKeyReply ::= SEQUENCE {
752
keyPackList [0] SEQUENCE OF KeyPack,
753
-- the first KeyPair is
754
-- the primary key pair
756
-- binds reply to request
757
-- must be identical to the nonce
758
-- sent in the SignedAuthPack
761
KeyPack ::= SEQUENCE {
763
encPrivKey [1] OCTET STRING
766
Upon receipt of the reply, the client extracts the encrypted private
767
keys (and may store them, at the client's option). The primary
768
private key, which must be the first private key in the keyPack
769
SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
770
this key in turn is used to decrypt the main reply as described in
774
4. Logistics and Policy
776
This section describes a way to define the policy on the use of
777
PKINIT for each principal and request.
779
The KDC is not required to contain a database record for users
780
that use either the Standard Public Key Authentication or Public Key
781
Authentication with a Digital Signature. However, if these users
782
are registered with the KDC, it is recommended that the database
783
record for these users be modified to include three additional flags
784
in the attributes field.
786
The first flag, use_standard_pk_init, indicates that the user should
787
authenticate using standard PKINIT as described in Section 3.2. The
788
second flag, use_digital_signature, indicates that the user should
789
authenticate using digital signature PKINIT as described in Section
790
3.3. The third flag, store_private_key, indicates that the user
791
has stored his private key on the KDC and should retrieve it using
792
the exchange described in Section 3.4.
794
If one of the preauthentication fields defined above is included in
795
the request, then the KDC shall respond as described in Sections 3.2
796
through 3.4, ignoring the aforementioned database flags. If more
797
than one of the preauthentication fields is present, the KDC shall
798
respond with an error of type KDC_ERR_PREAUTH_FAILED.
800
In the event that none of the preauthentication fields defined above
801
are included in the request, the KDC checks to see if any of the
802
above flags are set. If the first flag is set, then it sends back
803
an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
804
preauthentication field of type PA-PK-AS-REQ must be included in the
807
Otherwise, if the first flag is clear, but the second flag is set,
808
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
809
indicating that a preauthentication field of type PA-PK-AS-SIGN must
810
be included in the request.
812
Lastly, if the first two flags are clear, but the third flag is set,
813
then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
814
indicating that a preauthentication field of type PA-PK-KEY-REQ must
815
be included in the request.
820
Certificate chains can potentially grow quite large and span several
821
UDP packets; this in turn increases the probability that a Kerberos
822
message involving PKINIT extensions will be broken in transit. In
823
light of the possibility that the Kerberos specification will
824
require KDCs to accept requests using TCP as a transport mechanism,
825
we make the same recommendation with respect to the PKINIT
831
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
832
(V5). Request for Comments 1510.
834
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
835
for Computer Networks, IEEE Communications, 32(9):33-38. September
838
[3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
839
Transport Layer Security (TLS).
840
draft-ietf-tls-kerb-cipher-suites-00.txt
842
[4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
843
Tickets for Application Servers (PKTAPP).
844
draft-ietf-cat-pktapp-00.txt
846
[5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
847
Using Public Key Cryptography. Symposium On Network and Distributed
848
System Security, 1997.
850
[6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
851
Protocol. In Proceedings of the USENIX Workshop on Electronic
854
[7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL
855
Protocol, Version 3.0 - IETF Draft.
857
[8] B.C. Neuman, Proxy-Based Authorization and Accounting for
858
Distributed Systems. In Proceedings of the 13th International
859
Conference on Distributed Computing Systems, May 1993.
861
[9] ITU-T (formerly CCITT) Information technology - Open Systems
862
Interconnection - The Directory: Authentication Framework
863
Recommendation X.509 ISO/IEC 9594-8
868
Sasha Medvinsky contributed several ideas to the protocol changes
869
and specifications in this document. His additions have been most
872
Some of the ideas on which this proposal is based arose during
873
discussions over several years between members of the SAAG, the IETF
874
CAT working group, and the PSRG, regarding integration of Kerberos
875
and SPX. Some ideas have also been drawn from the DASS system.
876
These changes are by no means endorsed by these groups. This is an
877
attempt to revive some of the goals of those groups, and this
878
proposal approaches those goals primarily from the Kerberos
879
perspective. Lastly, comments from groups working on similar ideas
880
in DCE have been invaluable.
885
This draft expires May 26, 1998.
892
USC Information Sciences Institute
893
4676 Admiralty Way Suite 1001
894
Marina del Rey CA 90292-6695
895
Phone: +1 310 822 1511
896
E-mail: {brian, bcn}@isi.edu
899
Digital Equipment Corporation
900
550 King Street, LKG2-2/Z7
902
Phone: +1 508 486 5210
903
E-mail: wray@tuxedo.enet.dec.com
907
CyberSafe Corporation
908
1605 NW Sammamish Road Suite 310
909
Issaquah WA 98027-5378
910
Phone: +1 206 391 6000
911
E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
916
E-mail: jtrostle@novell.com
added
removed
doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt
