1
INTERNET-DRAFT Brian Tung
2
draft-ietf-cat-kerberos-pk-init-17.txt Clifford Neuman
3
Updates: RFC 1510bis USC/ISI
4
expires May 31, 2004 Matthew Hur
13
Public Key Cryptography for Initial Authentication in Kerberos
15
0. Status Of This Memo
17
This document is an Internet-Draft and is in full conformance with
18
all provision of Section 10 of RFC 2026. Internet-Drafts are
19
working 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 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-17.txt and expires May 31, 2004.
36
Please send comments to the authors.
41
This draft describes protocol extensions (hereafter called PKINIT)
42
to the Kerberos protocol specification (RFC 1510bis [1]). These
43
extensions provide a method for integrating public key cryptography
44
into the initial authentication exchange, by passing cryptographic
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 draft, we will
58
refer to both the AS and the TGS as the KDC.) Finally, the client
59
uses the service ticket to authenticate itself to the service.
61
The advantage afforded by the TGT is that the user need only
62
explicitly request a ticket and expose his credentials once. The
63
TGT and its associated session key can then be used for any
64
subsequent requests. One implication of this is that all further
65
authentication is independent of the method by which the initial
66
authentication was performed. Consequently, initial authentication
67
provides a convenient place to integrate public-key cryptography
68
into Kerberos authentication.
70
As defined, Kerberos authentication exchanges use symmetric-key
71
cryptography, in part for performance. (Symmetric-key cryptography
72
is typically 10-100 times faster than public-key cryptography,
73
depending on the public-key operations. [c]) One cost of using
74
symmetric-key cryptography is that the keys must be shared, so that
75
before a user can authentication himself, he must already be
76
registered with the KDC.
78
Conversely, public-key cryptography--in conjunction with an
79
established certification infrastructure--permits authentication
80
without prior registration. Adding it to Kerberos allows the
81
widespread use of Kerberized applications by users without requiring
82
them to register first--a requirement that has no inherent security
85
As noted above, a convenient and efficient place to introduce
86
public-key cryptography into Kerberos is in the initial
87
authentication exchange. This document describes the methods and
88
data formats for integrating public-key cryptography into Kerberos
89
initial authentication. Another document (PKCROSS) describes a
90
similar protocol for Kerberos cross-realm authentication.
95
This section describes extensions to RFC 1510bis for supporting the
96
use of public-key cryptography in the initial request for a ticket
97
granting ticket (TGT).
99
Briefly, the following changes to RFC 1510bis are proposed:
101
1. If public-key authentication is indicated, the client sends
102
the user's public-key data and an authenticator in a
103
preauthentication field accompanying the usual request.
104
This authenticator is signed by the user's private
107
2. The KDC verifies the client's request against its own
108
policy and certification authorities.
110
3. If the request passes the verification tests, the KDC
111
replies as usual, but the reply is encrypted using either:
113
a. a randomly generated key, signed using the KDC's
114
signature key and encrypted using the user's encryption
117
b. a key generated through a Diffie-Hellman exchange with
118
the client, signed using the KDC's signature key.
120
Any key data required by the client to obtain the encryption
121
key is returned in a preauthentication field accompanying
124
4. The client obtains the encryption key, decrypts the reply,
125
and then proceeds as usual.
127
Section 3.1 of this document defines the necessary message formats.
128
Section 3.2 describes their syntax and use in greater detail.
129
Implementation of all specified formats and uses in these sections
130
is REQUIRED for compliance with PKINIT.
136
3.1.1. Required Algorithms
138
[What is the current list of required algorithm? --brian]
141
3.1.2. Defined Message and Encryption Types
143
PKINIT makes use of the following new preauthentication types:
148
PKINIT introduces the following new error types:
150
KDC_ERR_CLIENT_NOT_TRUSTED 62
151
KDC_ERR_KDC_NOT_TRUSTED 63
152
KDC_ERR_INVALID_SIG 64
153
KDC_ERR_KEY_TOO_WEAK 65
154
KDC_ERR_CERTIFICATE_MISMATCH 66
155
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
156
KDC_ERR_INVALID_CERTIFICATE 71
157
KDC_ERR_REVOKED_CERTIFICATE 72
158
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
159
KDC_ERR_CLIENT_NAME_MISMATCH 75
161
PKINIT uses the following typed data types for errors:
164
TD-TRUSTED-CERTIFIERS 104
165
TD-CERTIFICATE-INDEX 105
167
PKINIT defines the following encryption types, for use in the AS-REQ
168
message (to indicate acceptance of the corresponding encryption OIDs
172
md5WithRSAEncryption-CmsOID 10
173
sha1WithRSAEncryption-CmsOID 11
175
rsaEncryption-EnvOID (PKCS1 v1.5) 13
176
rsaES-OAEP-ENV-OID (PKCS1 v2.0) 14
177
des-ede3-cbc-Env-OID 15
179
The above encryption types are used (in PKINIT) only within CMS [8]
180
structures within the PKINIT preauthentication fields. Their use
181
within Kerberos EncryptedData structures is unspecified.
184
3.1.3. Algorithm Identifiers
186
PKINIT does not define, but does make use of, the following
187
algorithm identifiers.
189
PKINIT uses the following algorithm identifier for Diffie-Hellman
194
PKINIT uses the following signature algorithm identifiers [8, 12]:
196
sha-1WithRSAEncryption (RSA with SHA1)
197
md5WithRSAEncryption (RSA with MD5)
198
id-dsa-with-sha1 (DSA with SHA1)
200
PKINIT uses the following encryption algorithm identifiers [12] for
201
encrypting the temporary key with a public key:
203
rsaEncryption (PKCS1 v1.5)
204
id-RSAES-OAEP (PKCS1 v2.0)
206
These OIDs are not to be confused with the encryption types listed
209
PKINIT uses the following algorithm identifiers [8] for encrypting
210
the reply key with the temporary key:
212
des-ede3-cbc (three-key 3DES, CBC mode)
213
rc2-cbc (RC2, CBC mode)
215
Again, these OIDs are not to be confused with the encryption types
219
3.2. PKINIT Preauthentication Syntax and Use
221
In this section, we describe the syntax and use of the various
222
preauthentication fields employed to implement PKINIT.
225
3.2.1. Client Request
227
The initial authentication request (AS-REQ) is sent as per RFC
228
1510bis, except that a preauthentication field containing data
229
signed by the user's private signature key accompanies the request,
232
PA-PK-AS-REQ ::= SEQUENCE {
234
signedAuthPack [0] ContentInfo,
236
-- Type is SignedData.
237
-- Content is AuthPack
239
trustedCertifiers [1] SEQUENCE OF TrustedCAs OPTIONAL,
240
-- A list of CAs, trusted by
241
-- the client, used to certify
243
kdcCert [2] IssuerAndSerialNumber OPTIONAL,
245
-- Identifies a particular KDC
246
-- certificate, if the client
248
encryptionCert [3] IssuerAndSerialNumber OPTIONAL,
249
-- May identify the user's
250
-- Diffie-Hellman certificate,
251
-- or an RSA encryption key
256
TrustedCAs ::= CHOICE {
258
-- Fully qualified X.500 name
259
-- as defined in X.509 [11].
260
issuerAndSerial [1] IssuerAndSerialNumber,
261
-- Identifies a specific CA
262
-- certificate, if the client
267
[Should we even allow principalName as a choice? --brian]
269
AuthPack ::= SEQUENCE {
270
pkAuthenticator [0] PKAuthenticator,
271
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
274
-- Present only if the client
275
-- is using ephemeral-ephemeral
279
PKAuthenticator ::= SEQUENCE {
281
ctime [1] KerberosTime,
282
-- cusec and ctime are used as
283
-- in RFC 1510bis, for replay
286
-- Binds reply to request,
287
-- except is zero when client
288
-- will accept cached
289
-- Diffie-Hellman parameters
290
-- from KDC and MUST NOT be
292
paChecksum [3] Checksum,
293
-- Defined in RFC 1510bis.
294
-- Performed over KDC-REQ-BODY,
299
SubjectPublicKeyInfo ::= SEQUENCE {
300
-- As defined in X.509.
301
algorithm AlgorithmIdentifier,
302
-- Equals dhpublicnumber (see
303
-- AlgorithmIdentifier, below)
305
subjectPublicKey BIT STRING
306
-- Equals public exponent
307
-- (INTEGER encoded as payload
308
-- of BIT STRING) for PKINIT.
311
AlgorithmIdentifier ::= SEQUENCE {
312
-- As defined in X.509.
313
algorithm OBJECT IDENTIFIER,
315
-- { iso (1) member-body (2)
316
-- US (840) ansi-x942 (10046)
317
-- number-type (2) 1 }
318
-- From RFC 2459 [11].
319
parameters ANY DEFINED BY algorithm OPTIONAL
320
-- Content is DomainParameters
321
-- (see below) for PKINIT.
324
DomainParameters ::= SEQUENCE {
325
-- As defined in RFC 2459.
327
-- p is the odd prime, equals
335
validationParms ValidationParms OPTIONAL
338
ValidationParms ::= SEQUENCE {
339
-- As defined in RFC 2459.
341
-- Seed for the system parameter
342
-- generation process.
344
-- Integer value output as part
345
-- of the system parameter
346
-- generation process.
349
The ContentInfo in the signedAuthPack is filled out as follows:
351
1. The eContent field contains data of type AuthPack. It MUST
352
contain the pkAuthenticator, and MAY also contain the
353
user's Diffie-Hellman public value (clientPublicValue).
355
2. The eContentType field MUST contain the OID value for
356
pkauthdata: { iso (1) org (3) dod (6) internet (1)
357
security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}
359
3. The signerInfos field MUST contain the signature of the
362
4. The certificates field MUST contain at least a signature
363
verification certificate chain that the KDC can use to
364
verify the signature on the AuthPack. Additionally, the
365
client may also insert an encryption certificate chain, if
366
(for example) the client is not using ephemeral-ephemeral
369
5. If a Diffie-Hellman key is being used, the parameters SHOULD
370
be chosen from the First or Second defined Oakley Groups.
373
6. The KDC may wish to use cached Diffie-Hellman parameters.
374
To indicate acceptance of caching, the client sends zero in
375
the nonce field of the pkAuthenticator. Zero is not a valid
376
value for this field under any other circumstances. Since
377
zero is used to indicate acceptance of cached parameters,
378
message binding in this case is performed instead using the
379
nonce in the main request.
382
3.2.2. Validation of Client Request
384
Upon receiving the client's request, the KDC validates it. This
385
section describes the steps that the KDC MUST (unless otherwise
386
noted) take in validating the request.
388
The KDC must look for a user certificate in the signedAuthPack.
389
If it cannot find one signed by a CA it trusts, it sends back an
390
error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying
391
e-data for this error is a SEQUENCE OF TypedData:
393
TypedData ::= SEQUENCE {
394
-- As defined in RFC 1510bis.
395
data-type [0] INTEGER,
396
data-value [1] OCTET STRING
399
For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
400
data-value is an OCTET STRING containing the DER encoding of
402
TrustedCertifiers ::= SEQUENCE OF Name
404
If, while verifying the certificate chain, the KDC determines that
405
the signature on one of the certificates in the signedAuthPack is
406
invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
407
The accompanying e-data for this error is a SEQUENCE OF TypedData,
408
whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
409
OCTET STRING containing the DER encoding of the index into the
410
CertificateSet field, ordered as sent by the client:
412
CertificateIndex ::= INTEGER
413
-- 0 = first certificate (in
414
-- order of encoding),
415
-- 1 = second certificate, etc.
417
If more than one signature is invalid, the KDC sends one TypedData
418
per invalid signature.
420
The KDC MAY also check whether any of the certificates in the user's
421
chain have been revoked. If any of them have been revoked, the KDC
422
returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
423
attempts to determine the revocation status but is unable to do so,
424
it returns an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. In
425
either case, the certificate or certificates affected are identified
426
exactly as for an error of type KDC_ERR_INVALID_CERTIFICATE (see
429
If the certificate chain is successfully validated, but the name in
430
the user's certificate does not match the name given in the request,
431
the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH. There
432
is no accompanying e-data for this error.
434
Even if the chain is validated, and the names in the certificate and
435
the request match, the KDC may decide not to trust the client. For
436
example, the certificate may include (or not include) an Enhanced
437
Key Usage (EKU) OID in the extensions field. As a matter of local
438
policy, the KDC may decide to reject requests on the basis of the
439
absence or presence of specific EKU OIDs. In this case, the KDC
440
returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED. For the
441
benefit of implementors, we define a PKINIT EKU OID as follows:
442
{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
443
pkinit (3) pkekuoid (2) }.
445
If the certificate chain and usage check out, but the client's
446
signature on the signedAuthPack fails to verify, the KDC returns an
447
error of type KDC_ERR_INVALID_SIG. There is no accompanying e-data
450
[What about the case when all this checks out but one or more
451
certificates is rejected for other reasons? For example, perhaps
452
the key is too short for local policy. --DRE]
454
The KDC must check the timestamp to ensure that the request is not
455
a replay, and that the time skew falls within acceptable limits. If
456
the check fails, the KDC returns an error of type KRB_AP_ERR_REPEAT
457
or KRB_AP_ERR_SKEW, respectively.
459
Finally, if the clientPublicValue is filled in, indicating that the
460
client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
461
checks to see if the parameters satisfy its policy. If they do not,
462
it returns an error of type KDC_ERR_KEY_TOO_WEAK. The accompanying
463
e-data is a SEQUENCE OF TypedData, whose data-type is
464
TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing
465
the DER encoding of a DomainParameters (see above), including
466
appropriate Diffie-Hellman parameters with which to retry the
469
[This makes no sense. For example, maybe the key is too strong for
472
In order to establish authenticity of the reply, the KDC will sign
473
some key data (either the random key used to encrypt the reply in
474
the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to
475
generate the reply-encrypting key in the case of a ReplyKeyPack).
476
The signature certificate to be used is to be selected as follows:
478
1. If the client included a kdcCert field in the PA-PK-AS-REQ,
479
use the referred-to certificate, if the KDC has it. If it
480
does not, the KDC returns an error of type
481
KDC_ERR_CERTIFICATE_MISMATCH.
483
2. Otherwise, if the client did not include a kdcCert field,
484
but did include a trustedCertifiers field, and the KDC
485
possesses a certificate issued by one of the listed
486
certifiers, use that certificate. if it does not possess
487
one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED.
489
3. Otherwise, if the client included neither a kdcCert field
490
nor a trustedCertifiers field, and the KDC has only one
491
signature certificate, use that certificate. If it has
492
more than one certificate, it returns an error of type
493
KDC_ERR_CERTIFICATE_MISMATCH.
498
Assuming that the client's request has been properly validated, the
499
KDC proceeds as per RFC 1510bis, except as follows.
501
The user's name as represented in the AS-REP must be derived from
502
the certificate provided in the client's request. If the KDC has
503
its own mapping from the name in the certificate to a Kerberos name,
504
it uses that Kerberos name.
506
Otherwise, if the certificate contains a subjectAltName extension
507
with PrincipalName, it uses that name. In this case, the realm in
508
the ticket is that of the local realm (or some other realm name
509
chosen by that realm). (OID and syntax for this extension to be
510
specified here.) Otherwise, the KDC returns an error of type
511
KDC_ERR_CLIENT_NAME_MISMATCH.
513
In addition, the certifiers in the certification path of the user's
514
certificate MUST be added to an authdata (to be specified at a later
517
The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then
518
encrypts the reply as usual, but not with the user's long-term key.
519
Instead, it encrypts it with either a random encryption key, or a
520
key derived through a Diffie-Hellman exchange. Which is the case is
521
indicated by the contents of the PA-PK-AS-REP (note tags):
523
PA-PK-AS-REP ::= CHOICE {
525
dhSignedData [0] ContentInfo,
526
-- Type is SignedData.
527
-- Content is KDCDHKeyInfo
529
encKeyPack [1] ContentInfo,
530
-- Type is EnvelopedData.
531
-- Content is ReplyKeyPack
536
Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an
537
encKeyPack, but not both. The former contains data of type
538
KDCDHKeyInfo, and is used only when the reply is encrypted using a
539
Diffie-Hellman derived key:
541
KDCDHKeyInfo ::= SEQUENCE {
542
subjectPublicKey [0] BIT STRING,
543
-- Equals public exponent
545
-- INTEGER encoded as payload
548
-- Binds reply to request.
549
-- Exception: A value of zero
550
-- indicates that the KDC is
551
-- using cached values.
552
dhKeyExpiration [2] KerberosTime OPTIONAL,
553
-- Expiration time for KDC's
558
The fields of the ContentInfo for dhSignedData are to be filled in
561
1. The eContent field contains data of type KDCDHKeyInfo.
563
2. The eContentType field contains the OID value for
564
pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
565
security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }
567
3. The signerInfos field contains a single signerInfo, which is
568
the signature of the KDCDHKeyInfo.
570
4. The certificates field contains a signature verification
571
certificate chain that the client may use to verify the
572
KDC's signature over the KDCDHKeyInfo.) It may only be left
573
empty if the client did not include a trustedCertifiers
574
field in the PA-PK-AS-REQ, indicating that it has the KDC's
577
5. If the client and KDC agree to use cached parameters, the
578
KDC SHOULD return a zero in the nonce field and include the
579
expiration time of the cached values in the dhKeyExpiration
580
field. If this time is exceeded, the client SHOULD NOT use
581
the reply. If the time is absent, the client SHOULD NOT use
582
the reply and MAY resubmit a request with a non-zero nonce,
583
thus indicating non-acceptance of the cached parameters.
585
The key is derived as follows: Both the KDC and the client calculate
586
the value g^(ab) mod p, where a and b are the client and KDC's
587
private exponents, respectively. They both take the first N bits of
588
this secret value and convert it into a reply key, where N depends
591
1. For example, if the key type is DES, N = 64 bits, where some
592
of the bits are replaced with parity bits, according to FIPS
595
2. If the key type is (three-key) 3DES, N = 192 bits, where
596
some of the bits are replaced with parity bits, again
597
according to FIPS PUB 74.
599
If the KDC and client are not using Diffie-Hellman, the KDC encrypts
600
the reply with an encryption key, packed in the encKeyPack, which
601
contains data of type ReplyKeyPack:
603
ReplyKeyPack ::= SEQUENCE {
604
replyKey [0] EncryptionKey,
605
-- Defined in RFC 1510bis.
606
-- Used to encrypt main reply.
607
-- MUST be at least as strong as
608
-- enctype of session key.
610
-- Binds reply to request.
614
[What exactly does "at least as strong" mean? --DRE]
616
The fields of the ContentInfo for encKeyPack MUST be filled in as
619
1. The innermost data is of type SignedData. The eContent for
620
this data is of type ReplyKeyPack.
622
2. The eContentType for this data contains the OID value for
623
pkrkeydata: { iso (1) org (3) dod (6) internet (1)
624
security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }
626
3. The signerInfos field contains a single signerInfo, which is
627
the signature of the ReplyKeyPack.
629
4. The certificates field contains a signature verification
630
certificate chain, which the client may use to verify the
631
KDC's signature over the ReplyKeyPack.) It may only be left
632
empty if the client did not include a trustedCertifiers
633
field in the PA-PK-AS-REQ, indicating that it has the KDC's
636
5. The outer data is of type EnvelopedData. The
637
encryptedContent for this data is the SignedData described
638
in items 1 through 4, above.
640
6. The encryptedContentType for this data contains the OID
641
value for id-signedData: { iso (1) member-body (2) us (840)
642
rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
644
7. The recipientInfos field is a SET which MUST contain exactly
645
one member of type KeyTransRecipientInfo. The encryptedKey
646
for this member contains the temporary key which is
647
encrypted using the client's public key.
649
8. Neither the unprotectedAttrs field nor the originatorInfo
650
field is required for PKINIT.
653
3.2.4. Validation of KDC Reply
655
Upon receipt of the KDC's reply, the client proceeds as follows. If
656
the PA-PK-AS-REP contains a dhSignedData, the client obtains and
657
verifies the Diffie-Hellman parameters, and obtains the shared key
658
as described above. Otherwise, the message contains an encKeyPack,
659
and the client decrypts and verifies the temporary encryption key.
660
In either case, the client then decrypts the main reply with the
661
resulting key, and then proceeds as described in RFC 1510bis.
664
4. Security Considerations
666
PKINIT raises certain security considerations beyond those that can
667
be regulated strictly in protocol definitions. We will address them
670
PKINIT extends the cross-realm model to the public-key
671
infrastructure. Anyone using PKINIT must be aware of how the
672
certification infrastructure they are linking to works.
674
Also, as in standard Kerberos, PKINIT presents the possibility of
675
interactions between cryptosystems of varying strengths, and this
676
now includes public-key cryptosystems. Many systems, for example,
677
allow the use of 512-bit public keys. Using such keys to wrap data
678
encrypted under strong conventional cryptosystems, such as 3DES, may
681
PKINIT calls for randomly generated keys for conventional
682
cryptosystems. Many such systems contain systematically "weak"
683
keys. For recommendations regarding these weak keys, see RFC
686
Care should be taken in how certificates are chosen for the purposes
687
of authentication using PKINIT. Some local policies may require
688
that key escrow be applied for certain certificate types. People
689
deploying PKINIT should be aware of the implications of using
690
certificates that have escrowed keys for the purposes of
693
PKINIT does not provide for a "return routability" test to prevent
694
attackers from mounting a denial-of-service attack on the KDC by
695
causing it to perform unnecessary and expensive public-key
696
operations. Strictly speaking, this is also true of standard
697
Kerberos, although the potential cost is not as great, because
698
standard Kerberos does not make use of public-key cryptography.
703
Some of the ideas on which this proposal is based arose during
704
discussions over several years between members of the SAAG, the IETF
705
CAT working group, and the PSRG, regarding integration of Kerberos
706
and SPX. Some ideas have also been drawn from the DASS system.
707
These changes are by no means endorsed by these groups. This is an
708
attempt to revive some of the goals of those groups, and this
709
proposal approaches those goals primarily from the Kerberos
710
perspective. Lastly, comments from groups working on similar ideas
711
in DCE have been invaluable.
716
This draft expires May 31, 2004.
721
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
722
(V5). Request for Comments 1510.
724
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
725
for Computer Networks, IEEE Communications, 32(9):33-38. September
728
[3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
729
Using Public Key Cryptography. Symposium On Network and Distributed
730
System Security, 1997.
732
[4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
733
Protocol. In Proceedings of the USENIX Workshop on Electronic
736
[5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0. Request
737
for Comments 2246, January 1999.
739
[6] B.C. Neuman, Proxy-Based Authorization and Accounting for
740
Distributed Systems. In Proceedings of the 13th International
741
Conference on Distributed Computing Systems, May 1993.
743
[7] ITU-T (formerly CCITT) Information technology - Open Systems
744
Interconnection - The Directory: Authentication Framework
745
Recommendation X.509 ISO/IEC 9594-8
747
[8] R. Housley. Cryptographic Message Syntax.
748
draft-ietf-smime-cms-13.txt, April 1999, approved for publication as
751
[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA
752
Laboratories Technical Note Version 1.5. Revised November 1, 1993
754
[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
755
Security, Inc. A Description of the RC2(r) Encryption Algorithm.
756
March 1998. Request for Comments 2268.
758
[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
759
Key Infrastructure, Certificate and CRL Profile, January 1999.
760
Request for Comments 2459.
762
[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
763
Specifications, October 1998. Request for Comments 2437.
765
[13] ITU-T (formerly CCITT) Information Processing Systems - Open
766
Systems Interconnection - Specification of Abstract Syntax Notation
767
One (ASN.1) Rec. X.680 ISO/IEC 8824-1
769
[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
770
Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
777
USC Information Sciences Institute
778
4676 Admiralty Way Suite 1001
779
Marina del Rey CA 90292-6695
780
Phone: +1 310 822 1511
781
E-mail: {brian,bcn}@isi.edu
785
Microsoft Corporation
788
Phone: +1 425 707 3336
789
E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
796
E-mail: smedvinsky@motorola.com
799
Iris Associates, Inc.
800
5 Technology Park Dr.
802
E-mail: John_Wray@iris.com
805
E-mail: jtrostle@world.std.com
added
removed
doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt
