1
INTERNET-DRAFT Brian Tung
2
draft-ietf-cat-kerberos-pk-init-21.txt Clifford Neuman
3
expires April 25, 2005 USC/ISI
8
Public Key Cryptography for Initial Authentication in Kerberos
11
0. Status Of This Memo
13
By submitting this Internet-Draft, I certify that any applicable
14
patent or other IPR claims of which I am aware have been disclosed,
15
or will be disclosed, and any of which I become aware will be
16
disclosed, in accordance with RFC 3668.
18
Internet-Drafts are working documents of the Internet Engineering
19
Task Force (IETF), its areas, and its working groups. Note that
20
other groups may also distribute working documents as
23
Internet-Drafts are draft documents valid for a maximum of six
24
months and may be updated, replaced, or obsoleted by other documents
25
at any time. It is inappropriate to use Internet-Drafts as
26
reference material or to cite them other than as "work in progress."
28
The list of current Internet-Drafts can be accessed at
29
http://www.ietf.org/ietf/1id-abstracts.txt
31
The list of Internet-Draft Shadow Directories can be accessed at
32
http://www.ietf.org/shadow.html
34
The distribution of this memo is unlimited. It is filed as
35
draft-ietf-cat-kerberos-pk-init-21.txt and expires April 25, 2005.
36
Please send comments to the authors.
41
This document describes protocol extensions (hereafter called
42
PKINIT) to the Kerberos protocol specification [1]. These
43
extensions provide a method for integrating public key cryptography
44
into the initial authentication exchange, by passing digital
45
certificates and associated authenticators in preauthentication data
51
A client typically authenticates itself to a service in Kerberos
52
using three distinct though related exchanges. First, the client
53
requests a ticket-granting ticket (TGT) from the Kerberos
54
authentication server (AS). Then, it uses the TGT to request a
55
service ticket from the Kerberos ticket-granting server (TGS).
56
Usually, the AS and TGS are integrated in a single device known as
57
a Kerberos Key Distribution Center, or KDC. (In this document, we
58
will refer to both the AS and the TGS as the KDC.) Finally, the
59
client uses the service ticket to authenticate itself to the
62
The advantage afforded by the TGT is that the client need explicitly
63
request a ticket and expose his credentials only once. The TGT and
64
its associated session key can then be used for any subsequent
65
requests. One result of this is that all further authentication is
66
independent of the method by which the initial authentication was
67
performed. Consequently, initial authentication provides a
68
convenient place to integrate public-key cryptography into Kerberos
71
As defined, Kerberos authentication exchanges use symmetric-key
72
cryptography, in part for performance. One cost of using
73
symmetric-key cryptography is that the keys must be shared, so that
74
before a client can authenticate itself, he must already be
75
registered with the KDC.
77
Conversely, public-key cryptography (in conjunction with an
78
established Public Key Infrastructure) permits authentication
79
without prior registration with a KDC. Adding it to Kerberos allows
80
the widespread use of Kerberized applications by clients without
81
requiring them to register first with a KDC--a requirement that has
82
no inherent security benefit.
84
As noted above, a convenient and efficient place to introduce
85
public-key cryptography into Kerberos is in the initial
86
authentication exchange. This document describes the methods and
87
data formats for integrating public-key cryptography into Kerberos
88
initial authentication.
93
This section describes extensions to [1] for supporting the use of
94
public-key cryptography in the initial request for a ticket.
96
Briefly, this document defines the following extensions to [1]:
98
1. The client indicates the use of public-key authentication by
99
including a special preauthenticator in the initial request.
100
This preauthenticator contains the client's public-key data
103
2. The KDC tests the client's request against its policy and
104
trusted Certification Authorities (CAs).
106
3. If the request passes the verification tests, the KDC
107
replies as usual, but the reply is encrypted using either:
109
a. a symmetric encryption key, signed using the KDC's
110
signature key and encrypted using the client's encryption
113
b. a key generated through a Diffie-Hellman exchange with
114
the client, signed using the KDC's signature key.
116
Any keying material required by the client to obtain the
117
Encryption key is returned in a preauthentication field
118
accompanying the usual reply.
120
4. The client obtains the encryption key, decrypts the reply,
121
and then proceeds as usual.
123
Section 3.1 of this document defines the necessary message formats.
124
Section 3.2 describes their syntax and use in greater detail.
127
3.1. Definitions, Requirements, and Constants
130
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
131
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
132
document are to be interpreted as described in RFC 2119 [12].
135
3.1.1. Required Algorithms
137
All PKINIT implementations MUST support the following algorithms:
139
- Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.
141
- Signature algorithm: SHA-1 digest and RSA.
143
- Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
144
with a non-zero nonce.
146
- Unkeyed checksum type for the paChecksum member of
147
PKAuthenticator: SHA1 (unkeyed), Kerberos checksum type 14
151
3.1.2. Defined Message and Encryption Types
153
PKINIT makes use of the following new preauthentication types:
158
PKINIT also makes use of the following new authorization data type:
160
AD-INITIAL-VERIFIED-CAS TBD
162
PKINIT introduces the following new error codes:
164
KDC_ERR_CLIENT_NOT_TRUSTED 62
165
KDC_ERR_KDC_NOT_TRUSTED 63
166
KDC_ERR_INVALID_SIG 64
168
KDC_ERR_CERTIFICATE_MISMATCH 66
169
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
170
KDC_ERR_INVALID_CERTIFICATE 71
171
KDC_ERR_REVOKED_CERTIFICATE 72
172
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
173
KDC_ERR_CLIENT_NAME_MISMATCH 75
175
PKINIT uses the following typed data types for errors:
178
TD-TRUSTED-CERTIFIERS 104
179
TD-CERTIFICATE-INDEX 105
180
TD-UNKEYED-CHECKSUM-INFO 109
182
PKINIT defines the following encryption types, for use in the AS-REQ
183
message (to indicate acceptance of the corresponding encryption OIDs
187
md5WithRSAEncryption-CmsOID 10
188
sha1WithRSAEncryption-CmsOID 11
190
rsaEncryption-EnvOID (PKCS1 v1.5) 13
191
rsaES-OAEP-EnvOID (PKCS1 v2.0) 14
192
des-ede3-cbc-EnvOID 15
194
The above encryption types are used by the client only within the
195
KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their
196
use within Kerberos EncryptedData structures is not specified by this
199
The ASN.1 module for all structures defined in this document (plus
200
IMPORT statements for all imported structures) are given in Appendix
201
A. In the event of a discrepancy between Appendix A and the portions
202
of ASN.1 in the main text, the appendix is normative.
204
All structures defined in this document MUST be encoded using
205
Distinguished Encoding Rules (DER). All imported data structures
206
must be encoded according to the rules specified in Kerberos [1] or
207
CMS [2] as appropriate.
209
Interoperability note: Some implementations may not be able to
210
decode CMS objects encoded with BER but not DER; specifically, they
211
may not be able to decode infinite length encodings. To maximize
212
interoperability, implementers SHOULD encode CMS objects used in
216
3.1.3. Algorithm Identifiers
218
PKINIT does not define, but does make use of, the following
219
algorithm identifiers.
221
PKINIT uses the following algorithm identifier for Diffie-Hellman
226
PKINIT uses the following signature algorithm identifiers [8, 12]:
228
sha-1WithRSAEncryption (RSA with SHA1)
229
md5WithRSAEncryption (RSA with MD5)
230
id-dsa-with-sha1 (DSA with SHA1)
232
PKINIT uses the following encryption algorithm identifiers [5] for
233
encrypting the temporary key with a public key:
235
rsaEncryption (PKCS1 v1.5)
236
id-RSAES-OAEP (PKCS1 v2.0)
238
PKINIT uses the following algorithm identifiers [2] for encrypting
239
the reply key with the temporary key:
241
des-ede3-cbc (three-key 3DES, CBC mode)
242
rc2-cbc (RC2, CBC mode)
243
aes256_CBC (AES-256, CBC mode)
246
3.2. PKINIT Preauthentication Syntax and Use
248
This section defines the syntax and use of the various
249
preauthentication fields employed by PKINIT.
252
3.2.1. Client Request
254
The initial authentication request (AS-REQ) is sent as per [1]; in
255
addition, a preauthentication field contains data signed by the
256
client's private signature key, as follows:
258
WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
259
-- Contains a BER encoding of
263
WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
264
-- Contains a BER encoding of
265
-- IssuerAndSerialNumber
268
PA-PK-AS-REQ ::= SEQUENCE {
269
signedAuthPack [0] IMPLICIT WrapContentInfo,
270
-- Type is SignedData.
271
-- Content is AuthPack
273
trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
274
-- A list of CAs, trusted by
275
-- the client, used to certify
277
kdcCert [2] IMPLICIT WrapIssuerAndSerial
279
-- Identifies a particular KDC
280
-- certificate, if the client
285
TrustedCA ::= CHOICE {
287
-- Fully qualified X.500 name
288
-- as defined in RFC 3280 [4].
289
issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial,
290
-- Identifies a specific CA
295
AuthPack ::= SEQUENCE {
296
pkAuthenticator [0] PKAuthenticator,
297
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
298
-- Defined in RFC 3280 [4].
299
-- Present only if the client
300
-- is using ephemeral-ephemeral
302
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
304
-- List of CMS encryption types
305
-- supported by client in order
306
-- of (decreasing) preference.
310
PKAuthenticator ::= SEQUENCE {
311
cusec [0] INTEGER (0..999999),
312
ctime [1] KerberosTime,
313
-- cusec and ctime are used as
314
-- in [1], for replay
316
nonce [2] INTEGER (0..4294967295),
317
-- Binds reply to request,
318
-- MUST be zero when client
319
-- will accept cached
320
-- Diffie-Hellman parameters
321
-- from KDC. MUST NOT be
323
paChecksum [3] Checksum,
325
-- Performed over KDC-REQ-BODY,
330
The ContentInfo in the signedAuthPack is filled out as follows:
332
1. The eContent field contains data of type AuthPack. It MUST
333
contain the pkAuthenticator, and MAY also contain the
334
client's Diffie-Hellman public value (clientPublicValue).
336
2. The eContentType field MUST contain the OID value for
337
id-pkauthdata: { iso(1) org(3) dod(6) internet(1)
338
security(5) kerberosv5(2) pkinit(3) pkauthdata(1)}
340
3. The signerInfos field MUST contain the signature over the
343
4. The certificates field MUST contain at least a signature
344
verification certificate chain that the KDC can use to
345
verify the signature over the AuthPack. The certificate
346
chain(s) MUST NOT contain the root CA certificate.
348
5. If a Diffie-Hellman key is being used, the parameters MUST
349
be chosen from Oakley Group 2 or 14. Implementations MUST
350
support Group 2; they are RECOMMENDED to support Group 14.
353
6. The KDC may wish to use cached Diffie-Hellman parameters.
354
To indicate acceptance of caching, the client sends zero in
355
the nonce field of the pkAuthenticator. Zero is not a valid
356
value for this field under any other circumstances. Since
357
zero is used to indicate acceptance of cached parameters,
358
message binding in this case is performed using only the
359
nonce in the main request.
362
3.2.2. Validation of Client Request
364
Upon receiving the client's request, the KDC validates it. This
365
section describes the steps that the KDC MUST (unless otherwise
366
noted) take in validating the request.
368
The KDC must look for a client certificate in the signedAuthPack.
369
If it cannot find one signed by a CA it trusts, it sends back an
370
error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying
371
e-data for this error is a TYPED-DATA (as defined in [1]). For this
372
error, the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is
375
TrustedCertifiers ::= SEQUENCE OF Name
377
If, while verifying the certificate chain, the KDC determines that
378
the signature on one of the certificates in the signedAuthPack is
379
invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
380
The accompanying e-data for this error is a TYPED-DATA, whose
381
data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
382
encoding of the index into the CertificateSet field, ordered as sent
385
CertificateIndex ::= IssuerAndSerialNumber
386
-- IssuerAndSerialNumber of
387
-- certificate with invalid signature
389
If more than one certificate signature is invalid, the KDC MAY send
390
one TYPED-DATA per invalid signature.
392
The KDC MAY also check whether any certificates in the client's
393
chain have been revoked. If any of them have been revoked, the KDC
394
MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
395
attempts to determine the revocation status but is unable to do so,
396
it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
397
The certificate or certificates affected are identified exactly as
398
for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
400
In addition to validating the certificate chain, the KDC MUST also
401
check that the certificate properly maps to the client's principal name
402
as specified in the AS-REQ as follows:
404
1. If the KDC has its own mapping from the name in the
405
certificate to a Kerberos name, it uses that Kerberos
408
2. Otherwise, if the certificate contains a SubjectAltName
409
extension with a Kerberos name in the otherName field,
410
it uses that name. The otherName field (of type AnotherName)
411
in the SubjectAltName extension MUST contain the following:
415
krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
416
internet (1) security (5) kerberosv5 (2) 2 }
420
KRB5PrincipalName ::= SEQUENCE {
422
principalName [1] PrincipalName
425
If the KDC does not have its own mapping and there is no Kerberos
426
name present in the certificate, or if the name in the request does
427
not match the name in the certificate (including the realm name), or
428
if there is no name in the request, the KDC MUST return error code
429
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
432
Even if the chain is validated, and the names in the certificate and
433
the request match, the KDC may decide not to trust the client. For
434
example, the certificate may include an Extended Key Usage (EKU) OID
435
in the extensions field. As a matter of local policy, the KDC may
436
decide to reject requests on the basis of the absence or presence of
437
specific EKU OIDs. In this case, the KDC MUST return error code
438
KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
440
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
441
pkinit(3) pkekuoid(4) }
443
If the client's signature on the signedAuthPack fails to verify, the KDC
444
MUST return error KDC_ERR_INVALID_SIG. There is no accompanying
445
e-data for this error.
447
The KDC MUST check the timestamp to ensure that the request is not
448
a replay, and that the time skew falls within acceptable limits.
449
The recommendations clock skew times in [1] apply here. If the
450
check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT or
451
KRB_AP_ERR_SKEW, respectively.
453
If the clientPublicValue is filled in, indicating that the client
454
wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
455
see if the parameters satisfy its policy. If they do not, it MUST
456
return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a
457
TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose
458
data-value is the DER encoding of a DomainParameters (see [3]),
459
including appropriate Diffie-Hellman parameters with which to retry
462
The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
463
client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
464
not have the corresponding certificate.
466
The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
467
did not include a kdcCert field, but did include a trustedCertifiers
468
field, and the KDC does not possesses a certificate issued by one of
469
the listed certifiers.
471
If there is a supportedCMSTypes field in the AuthPack, the KDC must
472
check to see if it supports any of the listed types. If it supports
473
more than one of the types, the KDC SHOULD use the one listed first.
474
If it does not support any of them, it MUST return an error of type
475
KRB5KDC_ERR_ETYPE_NOSUPP.
480
Assuming that the client's request has been properly validated, the
481
KDC proceeds as per [1], except as follows.
483
The KDC MUST set the initial flag and include an authorization data
484
of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is
485
an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
487
InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
489
Validated [1] BOOLEAN,
493
The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
494
containers if the list of CAs satisfies the KDC's realm's policy.
495
(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
496
Furthermore, any TGS must copy such authorization data from tickets
497
used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
498
including the AD-IF-RELEVANT container, if present.
500
Application servers that understand this authorization data type
501
SHOULD apply local policy to determine whether a given ticket
502
bearing such a type *not* contained within an AD-IF-RELEVANT
503
container is acceptable. (This corresponds to the AP server
504
checking the transited field when the TRANSITED-POLICY-CHECKED flag
505
has not been set.) If such a data type is contained within an
506
AD-IF-RELEVANT container, AP servers MAY apply local policy to
507
determine whether the authorization data is acceptable.
509
The AS-REP is otherwise unchanged from [1]. The KDC encrypts the
510
reply as usual, but not with the client's long-term key. Instead,
511
it encrypts it with either a generated encryption key, or a key
512
derived from a Diffie-Hellman exchange. The contents of the
513
PA-PK-AS-REP indicate the type of encryption key that was used:
515
PA-PK-AS-REP ::= CHOICE {
516
dhSignedData [0] IMPLICIT WrapContentInfo,
517
-- Type is SignedData.
518
-- Content is KDCDHKeyInfo
520
encKeyPack [1] IMPLICIT WrapContentInfo,
521
-- Type is EnvelopedData.
522
-- Content is SignedData over
523
-- ReplyKeyPack (defined below).
527
KDCDHKeyInfo ::= SEQUENCE {
528
subjectPublicKey [0] BIT STRING,
529
-- Equals public exponent
531
-- INTEGER encoded as payload
533
nonce [1] INTEGER (0..4294967295),
534
-- Binds reply to request.
535
-- Exception: A value of zero
536
-- indicates that the KDC is
537
-- using cached values.
538
dhKeyExpiration [2] KerberosTime OPTIONAL,
539
-- Expiration time for KDC's
544
The fields of the ContentInfo for dhSignedData are to be filled in
547
1. The eContent field contains data of type KDCDHKeyInfo.
549
2. The eContentType field contains the OID value for
550
id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
551
security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }
553
3. The signerInfos field contains a single signerInfo, which is
554
the signature of the KDCDHKeyInfo.
556
4. The certificates field contains a signature verification
557
certificate chain that the client will use to verify the
558
KDC's signature over the KDCDHKeyInfo. This field may only
559
be left empty if the client did include a kdcCert field in
560
the PA-PK-AS-REQ, indicating that it has the KDC's
561
certificate. The certificate chain MUST NOT contain the
564
5. If the client and KDC agree to use cached parameters, the
565
KDC MUST return a zero in the nonce field and include the
566
expiration time of the cached values in the dhKeyExpiration
567
field. If this time is exceeded, the client MUST NOT use
568
the reply. If the time is absent, the client MUST NOT use
569
the reply and MAY resubmit a request with a non-zero nonce,
570
thus indicating non-acceptance of the cached parameters.
572
The KDC reply key is derived as follows:
574
1. Both the KDC and the client calculate the shared secret
579
where a and b are the client's and KDC's private exponents,
580
respectively. DHKey, padded first with leading zeros as
581
needed to make it as long as the modulus p, is represented
582
as a string of octets in big-endian order (such that the
583
size of DHKey in octets is the size of the modulus p).
585
2. Let K be the key-generation seed length [6] of the reply key
586
whose enctype is selected according to [1].
588
3. Define the function octetstring2key() as follows:
590
octetstring2key(h, x) == random-to-key(K-truncate(
597
where x is an octet string; h:octet string -> octet string
598
is a cryptographically strong hash function; | is the
599
concatenation operator; 0x00, 0x01, 0x02, etc. are each
600
represented as a single octet; random-to-key() is an
601
operation that generates a protocolkey from a bitstring of
602
length K; and K-truncate truncates its input to K bits.
603
Both K and random-to-key() are defined in the kcrypto
604
profile [6] for the enctype of the reply key.
606
A good example of h() is SHA1.
608
4. Define H to be a hash function based on operations of a
609
given checksum type [6], as follows:
611
H(x) = get_mic(dummy-key, x)
613
where x is an octet string.
615
H() MUST be a cryptographically strong hash, in order to be
616
suitable for use in the octetstring2key() operation above.
618
5. The client specifies a checksum type to use in the
619
paChecksum of the PKAuthenticator. If the H() operation
620
based on this checksum is not suitable for use in
621
octetstring2key(), or this checksum type is too weak or not
622
supported by the KDC, the KDC MUST return an error of type
623
KDC_ERR_PA_CKSUMTYPE_NOT_SUPPORTED. The accompanying e-data
624
for this error is a TYPED-DATA: the data-type is
625
TD-UNKEYED-CHECKSUM-INFO, and the data-value is the DER
628
UNKEYED-CHECKSUM-INFO ::= SEQUENCE OF SEQUENCE {
633
This list is in the preference order (best choice first) of
634
the KDC, and the client SHOULD retry with the first
635
available checksum type.
637
6. When cached DH parameters are used, let n_c be the
638
clientDHNonce, and n_k be the serverDHNonce; otherwise, let
639
both n_c and n_k be empty octet strings. The reply key k is
641
k = octetstring2key(H, DHKey | n_c | n_k)
643
where H() is the hash function based on the checksum type
644
used in the paChecksum of the PKAuthenticator (as defined in
647
Both the KDC and the client calculate
648
the value g^(ab) mod p, where a and b are the client's and KDC's
649
private exponents, respectively. They both take the first k bits of
650
this secret value as a key generation seed, where the parameter k
651
(the size of the seed) is dependent on the selected key type, as
652
specified in [6]. The seed is then converted into a protocol key by
653
applying to it a random-to-key function, which is also dependent on
656
If the KDC and client are not using Diffie-Hellman, the KDC encrypts
657
the reply with an encryption key, packed in the encKeyPack, which
658
contains data of type ReplyKeyPack:
660
ReplyKeyPack ::= SEQUENCE {
661
replyKey [0] EncryptionKey,
663
-- Used to encrypt main reply.
664
-- MUST be at least as strong
665
-- as session key. (Using the
666
-- same enctype and a strong
667
-- prng should suffice, if no
668
-- stronger encryption system
670
nonce [1] INTEGER (0..4294967295),
671
-- Binds reply to request.
675
The fields of the ContentInfo for encKeyPack MUST be filled in as
678
1. The content is of type SignedData. The eContent for
679
the SignedData is of type ReplyKeyPack.
681
2. The eContentType for the SignedData contains the OID value
682
for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1)
683
security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }
685
3. The signerInfos field contains a single signerInfo, which is
686
the signature of the ReplyKeyPack.
688
4. The certificates field contains a signature verification
689
certificate chain that the client will use to verify the
690
KDC's signature over the ReplyKeyPack. This field may only
691
be left empty if the client included a kdcCert field in the
692
PA-PK-AS-REQ, indicating that it has the KDC's certificate.
693
The certificate chain MUST NOT contain the root CA
696
5. The contentType for the EnvelopedData contains the OID value
697
for id-signedData: { iso (1) member-body (2) us (840) rsadsi
698
(113549) pkcs (1) pkcs7 (7) signedData (2) }
700
6. The recipientInfos field is a SET which MUST contain exactly
701
one member of type KeyTransRecipientInfo. The encryptedKey
702
for this member contains the temporary key which is
703
encrypted using the client's public key.
705
7. The unprotectedAttrs or originatorInfo fields MAY be
709
3.2.4. Validation of KDC Reply
711
Upon receipt of the KDC's reply, the client proceeds as follows. If
712
the PA-PK-AS-REP contains a dhSignedData, the client obtains and
713
verifies the Diffie-Hellman parameters, and obtains the shared key
714
as described above. Otherwise, the message contains an encKeyPack,
715
and the client decrypts and verifies the temporary encryption key.
717
In either case, the client MUST check to see if the included
718
certificate contains a subjectAltName extension of type dNSName or
719
iPAddress (if the KDC is specified by IP address instead of name).
720
If it does, it MUST check to see if that extension matches the KDC
721
it believes it is communicating with, with matching rules specified
722
in RFC 2459. Exception: If the client has some external information
723
as to the identity of the KDC, this check MAY be omitted.
725
The client also MUST check that the KDC's certificate contains an
726
extendedKeyUsage OID of id-pkkdcekuoid:
728
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
729
pkinit(3) pkkdcekuoid(5) }
731
If all applicable checks are satisfied, the client then decrypts the
732
main reply with the resulting key, and then proceeds as described in
736
4. Security Considerations
738
PKINIT raises certain security considerations beyond those that can
739
be regulated strictly in protocol definitions. We will address them
742
PKINIT extends the cross-realm model to the public-key
743
infrastructure. Users of PKINIT must understand security policies
744
and procedures appropriate to the use of Public Key Infrastructures.
746
Standard Kerberos allows the possibility of interactions between
747
cryptosystems of varying strengths; this document adds interactions
748
with public-key cryptosystems to Kerberos. Some administrative
749
policies may allow the use of relatively weak public keys. Using
750
such keys to wrap data encrypted under stronger conventional
751
cryptosystems may be inappropriate.
753
PKINIT requires keys for symmetric cryptosystems to be generated.
754
Some such systems contain "weak" keys. For recommendations regarding
755
these weak keys, see [1].
757
PKINIT allows the use of a zero nonce in the PKAuthenticator when
758
cached Diffie-Hellman keys are used. In this case, message binding
759
is performed using the nonce in the main request in the same way as
760
it is done for ordinary AS-REQs (without the PKINIT
761
pre-authenticator). The nonce field in the KDC request body is
762
signed through the checksum in the PKAuthenticator, which
763
cryptographically binds the PKINIT pre-authenticator to the main
764
body of the AS Request and also provides message integrity for the
767
However, when a PKINIT pre-authenticator in the AS-REP has a
768
zero-nonce, and an attacker has somehow recorded this
769
pre-authenticator and discovered the corresponding Diffie-Hellman
770
private key (e.g., with a brute-force attack), the attacker will be
771
able to fabricate his own AS-REP messages that impersonate the KDC
772
with this same pre-authenticator. This compromised pre-authenticator
773
will remain valid as long as its expiration time has not been reached
774
and it is therefore important for clients to check this expiration
775
time and for the expiration time to be reasonably short, which
776
depends on the size of the Diffie-Hellman group.
778
If a client also caches its Diffie-Hellman keys, then the session key
779
could remain the same during multiple AS-REQ/AS-REP exchanges and an
780
attacker which compromised the session key could fabricate his own
781
AS-REP messages with a pre-recorded pre-authenticator until the
782
client starts using a new Diffie-Hellman key pair and while the KDC
783
pre-authenticator has not yet expired. It is therefore not
784
recommended for KDC clients to also cache their Diffie-Hellman keys.
786
Care should be taken in how certificates are chosen for the purposes
787
of authentication using PKINIT. Some local policies may require
788
that key escrow be used for certain certificate types. Deployers of
789
PKINIT should be aware of the implications of using certificates that
790
have escrowed keys for the purposes of authentication.
792
PKINIT does not provide for a "return routability" test to prevent
793
attackers from mounting a denial-of-service attack on the KDC by
794
causing it to perform unnecessary and expensive public-key
795
operations. Strictly speaking, this is also true of standard
796
Kerberos, although the potential cost is not as great, because
797
standard Kerberos does not make use of public-key cryptography.
799
The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
800
permit empty SEQUENCEs to be encoded. Such empty sequences may only
801
be used if the KDC itself vouches for the user's certificate. [This
802
seems to reflect the consensus of the Kerberos working group.]
807
The following people have made significant contributions to this
808
draft: Ari Medvinsky, Matt Hur, John Wray, Jonathan Trostle, Nicolas
809
Williams, Tom Yu, Sam Hartman, and Jeff Hutzelman.
811
Some of the ideas on which this document is based arose during
812
discussions over several years between members of the SAAG, the IETF
813
CAT working group, and the PSRG, regarding integration of Kerberos
814
and SPX. Some ideas have also been drawn from the DASS system.
815
These changes are by no means endorsed by these groups. This is an
816
attempt to revive some of the goals of those groups, and this
817
document approaches those goals primarily from the Kerberos
818
perspective. Lastly, comments from groups working on similar ideas
819
in DCE have been invaluable.
824
This draft expires January 25, 2004.
829
[1] RFC-Editor: To be replaced by RFC number for
830
draft-ietf-krb-wg-kerberos-clarifications.
832
[2] R. Housley. Cryptographic Message Syntax. April 1999. Request
835
[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers
836
for the Internet X.509 Public Key Infrastructure Certificate and
837
Certificate Revocation List (CRL) Profile, April 2002. Request For
840
[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
841
Key Infrastructure Certificate and Certificate Revocation List
842
(CRL) Profile, April 2002. Request for Comments 3280.
844
[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
845
Specifications, October 1998. Request for Comments 2437.
847
[6] RFC-Editor: To be replaced by RFC number for
848
draft-ietf-krb-wg-crypto.
850
[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
851
T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
852
Request for Comments 3546.
854
[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
855
Internet X.509 Public Key Infrastructure: Online Certificate Status
856
Protocol - OCSP, June 1999. Request for Comments 2560.
858
[9] NIST, Guidelines for Implementing and Using the NBS Encryption
859
Standard, April 1981. FIPS PUB 74.
861
[10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE),
862
November 1998. Request for Comments 2409.
864
[11] K. Raeburn. Unkeyed SHA-1 Checksum Specification for Kerberos
865
5. Internet-Draft, draft-ietf-krb-wg-sha1-00.txt.
867
[12] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
868
Levels. March 1997. Request for Comments 2119 (BCP 14).
875
USC Information Sciences Institute
876
4676 Admiralty Way Suite 1001
877
Marina del Rey CA 90292-6695
878
Phone: +1 310 822 1511
879
E-mail: {brian,bcn}@isi.edu
883
Microsoft Corporation
886
Phone: +1 425 707 3336
887
E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
894
E-mail: smedvinsky@motorola.com
897
Iris Associates, Inc.
898
5 Technology Park Dr.
900
E-mail: John_Wray@iris.com
903
E-mail: jtrostle@world.std.com
906
Appendix A. PKINIT ASN.1 Module
908
KerberosV5-PK-INIT-SPEC {
909
iso(1) identified-organization(3) dod(6) internet(1)
910
security(5) kerberosV5(2) modules(4) pkinit(TBD)
911
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
914
SubjectPublicKeyInfo, AlgorithmIdentifier, Name
915
FROM PKIX1Explicit88 { iso (1) identified-organization (3)
916
dod (6) internet (1) security (5) mechanisms (5)
917
pkix (7) id-mod (0) id-pkix1-explicit (18) }
919
ContentInfo, IssuerAndSerialNumber
920
FROM CryptographicMessageSyntax { iso(1) member-body(2)
921
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
924
KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
925
FROM KerberosV5Spec2 { iso(1) identified-organization(3)
926
dod(6) internet(1) security(5) kerberosV5(2) modules(4)
929
id-pkinit OBJECT IDENTIFIER ::=
930
{ iso (1) org (3) dod (6) internet (1) security (5)
931
kerberosv5 (2) pkinit (3) }
933
id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 }
934
id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
935
id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
936
id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
937
id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
939
pa-pk-as-req INTEGER ::= TBD
940
pa-pk-as-rep INTEGER ::= TBD
941
pa-pk-ocsp-req INTEGER ::= TBD
942
pa-pk-ocsp-rep INTEGER ::= TBD
944
ad-initial-verified-cas INTEGER ::= TBD
946
td-dh-parameters INTEGER ::= TBD
947
td-trusted-certifiers INTEGER ::= 104
948
td-certificate-index INTEGER ::= 105
950
WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
951
-- Contains a BER encoding of
955
WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
956
-- Contains a BER encoding of
957
-- IssuerAndSerialNumber
960
PA-PK-AS-REQ ::= SEQUENCE {
961
signedAuthPack [0] IMPLICIT WrapContentInfo,
962
trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,
963
kdcCert [2] IMPLICIT WrapIssuerAndSerial
968
TrustedCA ::= CHOICE {
970
issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial,
974
AuthPack ::= SEQUENCE {
975
pkAuthenticator [0] PKAuthenticator,
976
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
977
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
982
PKAuthenticator ::= SEQUENCE {
983
cusec [0] INTEGER (0..999999),
984
ctime [1] KerberosTime,
985
nonce [2] INTEGER (0..4294967295),
986
paChecksum [3] Checksum,
990
TrustedCertifiers ::= SEQUENCE OF Name
992
CertificateIndex ::= IssuerAndSerialNumber
994
KRB5PrincipalName ::= SEQUENCE {
996
principalName [1] PrincipalName
999
InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
1001
validated [1] BOOLEAN,
1005
PA-PK-AS-REP ::= CHOICE {
1006
dhSignedData [0] IMPLICIT WrapContentInfo,
1007
encKeyPack [1] IMPLICIT WrapContentInfo,
1011
KDCDHKeyInfo ::= SEQUENCE {
1012
subjectPublicKey [0] BIT STRING,
1013
nonce [1] INTEGER (0..4294967295),
1014
dhKeyExpiration [2] KerberosTime OPTIONAL,
1018
ReplyKeyPack ::= SEQUENCE {
1019
replyKey [0] EncryptionKey,
1020
nonce [1] INTEGER (0..4294967295),
1026
Copyright (C) The Internet Society 2004. This document is subject
1027
to the rights, licenses and restrictions contained in BCP 78, and
1028
except as set forth therein, the authors retain all their rights.
1030
This document and the information contained herein are provided on
1031
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
1032
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
1033
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
1034
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1035
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1036
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
added
removed
doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
