idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-07.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1182 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 52 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 254: '...eValueLength INTEGER OPTIONAL...' RFC 2119 keyword, line 357: '...hanges in this section is REQUIRED for...' RFC 2119 keyword, line 368: '... userCert [1] SEQUENCE OF Certificate OPTIONAL,...' RFC 2119 keyword, line 375: '... trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL,...' RFC 2119 keyword, line 377: '... serialNumber [3] CertificateSerialNumber OPTIONAL...' (10 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1510, but the abstract doesn't seem to directly say this. It does mention RFC1510 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC1510, updated by this document, for RFC5378 checks: 1993-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1042 looks like a reference -- Missing reference section? '2' on line 1045 looks like a reference -- Missing reference section? '3' on line 1049 looks like a reference -- Missing reference section? '4' on line 1054 looks like a reference -- Missing reference section? '5' on line 1058 looks like a reference -- Missing reference section? '6' on line 1062 looks like a reference -- Missing reference section? '7' on line 1066 looks like a reference -- Missing reference section? '8' on line 1070 looks like a reference -- Missing reference section? '9' on line 1073 looks like a reference -- Missing reference section? '14' on line 1092 looks like a reference -- Missing reference section? '13' on line 1088 looks like a reference -- Missing reference section? 'EKB' on line 324 looks like a reference -- Missing reference section? '0' on line 946 looks like a reference -- Missing reference section? '15' on line 1096 looks like a reference -- Missing reference section? '10' on line 1077 looks like a reference -- Missing reference section? '11' on line 1081 looks like a reference -- Missing reference section? '12' on line 1084 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Brian Tung 2 draft-ietf-cat-kerberos-pk-init-07.txt Clifford Neuman 3 Updates: RFC 1510 ISI 4 expires May 15, 1999 John Wray 5 Digital Equipment Corporation 6 Ari Medvinsky 7 Matthew Hur 8 Sasha Medvinsky 9 CyberSafe Corporation 10 Jonathan Trostle 11 Cisco 13 Public Key Cryptography for Initial Authentication in Kerberos 15 0. Status Of This Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 To learn the current status of any Internet-Draft, please check 29 the "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ftp.ietf.org (US East Coast), 31 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 32 munnari.oz.au (Pacific Rim). 34 The distribution of this memo is unlimited. It is filed as 35 draft-ietf-cat-kerberos-pk-init-07.txt, and expires May 15, 1999. 36 Please send comments to the authors. 38 1. Abstract 40 This document defines extensions (PKINIT) to the Kerberos protocol 41 specification (RFC 1510 [1]) to provide a method for using public 42 key cryptography during initial authentication. The methods 43 defined specify the ways in which preauthentication data fields and 44 error data fields in Kerberos messages are to be used to transport 45 public key data. 47 2. Introduction 49 The popularity of public key cryptography has produced a desire for 50 its support in Kerberos [2]. The advantages provided by public key 51 cryptography include simplified key management (from the Kerberos 52 perspective) and the ability to leverage existing and developing 53 public key certification infrastructures. 55 Public key cryptography can be integrated into Kerberos in a number 56 of ways. One is to associate a key pair with each realm, which can 57 then be used to facilitate cross-realm authentication; this is the 58 topic of another draft proposal. Another way is to allow users with 59 public key certificates to use them in initial authentication. This 60 is the concern of the current document. 62 One of the guiding principles in the design of PKINIT is that 63 changes should be as minimal as possible. As a result, the basic 64 mechanism of PKINIT is as follows: The user sends a request to the 65 KDC as before, except that if that user is to use public key 66 cryptography in the initial authentication step, his certificate 67 accompanies the initial request, in the preauthentication fields. 69 Upon receipt of this request, the KDC verifies the certificate and 70 issues a ticket granting ticket (TGT) as before, except that 71 the encPart from the AS-REP message carrying the TGT is now 72 encrypted in a randomly-generated key, instead of the user's 73 long-term key (which is derived from a password). This 74 random key is in turn encrypted using the public key from the 75 certificate that came with the request and signed using the KDC's 76 private key, and accompanies the reply, in the preauthentication 77 fields. 79 PKINIT also allows for users with only digital signature keys to 80 authenticate using those keys, and for users to store and retrieve 81 private keys on the KDC. 83 The PKINIT specification may also be used as a building block for 84 other specifications. PKCROSS [3] utilizes PKINIT for establishing 85 the inter-realm key and associated inter-realm policy to be applied 86 in issuing cross realm service tickets. As specified in [4], anonymous 87 Kerberos tickets can be issued by applying a NULL signature in 88 combination with Diffie-Hellman in the PKINIT exchange. Additionally, 89 The PKINIT specification may be used for direct peer to peer 90 authentication without contacting a central KDC. This application 91 of PKINIT is described in PKTAPP [5] and is based on concepts 92 introduced in [6, 7]. For direct client-to-server authentication, 93 the client uses PKINIT to authenticate to the end server (instead 94 of a central KDC), which then issues a ticket for itself. This 95 approach has an advantage over SSL [8] in that the server does not 96 need to save state (cache session keys). Furthermore, an 97 additional benefit is that Kerberos tickets can facilitate 98 delegation (see [9]). 100 3. Proposed Extensions 102 This section describes extensions to RFC 1510 for supporting the 103 use of public key cryptography in the initial request for a ticket 104 granting ticket (TGT). 106 In summary, the following changes to RFC 1510 are proposed: 108 * Users may authenticate using either a public key pair or a 109 conventional (symmetric) key. If public key cryptography is 110 used, public key data is transported in preauthentication 111 data fields to help establish identity. 112 * Users may store private keys on the KDC for retrieval during 113 Kerberos initial authentication. 115 This proposal addresses two ways that users may use public key 116 cryptography for initial authentication. Users may present public 117 key certificates, or they may generate their own session key, 118 signed by their digital signature key. In either case, the end 119 result is that the user obtains an ordinary TGT that may be used for 120 subsequent authentication, with such authentication using only 121 conventional cryptography. 123 Section 3.1 provides definitions to help specify message formats. 124 Section 3.2 and 3.3 describe the extensions for the two initial 125 authentication methods. Section 3.4 describes a way for the user to 126 store and retrieve his private key on the KDC, as an adjunct to the 127 initial authentication. 129 3.1. Definitions 131 The extensions involve new preauthentication fields; we propose the 132 addition of the following types: 134 PA-PK-AS-REQ 14 135 PA-PK-AS-REP 15 136 PA-PK-AS-SIGN 16 137 PA-PK-KEY-REQ 17 138 PA-PK-KEY-REP 18 140 The extensions also involve new error types; we propose the addition 141 of the following types: 143 KDC_ERR_CLIENT_NOT_TRUSTED 62 144 KDC_ERR_KDC_NOT_TRUSTED 63 145 KDC_ERR_INVALID_SIG 64 146 KDC_ERR_KEY_TOO_WEAK 65 147 KDC_ERR_CERTIFICATE_MISMATCH 66 149 In many cases, PKINIT requires the encoding of an X.500 name as a 150 Realm. In these cases, the realm will be represented using a 151 different style, specified in RFC 1510 with the following example: 153 NAMETYPE:rest/of.name=without-restrictions 155 For a realm derived from an X.500 name, NAMETYPE will have the value 156 X500-RFC2253. The full realm name will appear as follows: 158 X500-RFC2253:RFC2253Encode(DistinguishedName) 160 where DistinguishedName is an X.500 name, and RFC2253Encode is a 161 readable ASCII encoding of an X.500 name, as defined by 162 RFC 2253 [14] (part of LDAPv3). (RFC 2253 obsoleted RFC 1779, which 163 is not supported by this version of PKINIT.) 165 To ensure that this encoding is unique, we add the following rule 166 to those specified by RFC 2253: 168 The order in which the attributes appear in the RFC 2253 169 encoding must be the reverse of the order in the ASN.1 170 encoding of the X.500 name that appears in the public key 171 certificate. The order of the relative distinguished names 172 (RDNs), as well as the order of the AttributeTypeAndValues 173 within each RDN, will be reversed. (This is despite the fact 174 that an RDN is defined as a SET of AttributeTypeAndValues, where 175 an order is normally not important.) 177 Similarly, PKINIT may require the encoding of an X.500 name as a 178 PrincipalName. In these cases, the name-type of the principal name 179 shall be set to NT-X500-PRINCIPAL. This new name type is defined 180 as: 182 #define CSFC5c_NT_X500_PRINCIPAL 6 184 The name-string shall be set as follows: 186 RFC2253Encode(DistinguishedName) 188 as described above. 190 3.1.1. Encryption and Key Formats 192 In the exposition below, we use the terms public key and private 193 key generically. It should be understood that the term "public 194 key" may be used to refer to either a public encryption key or a 195 signature verification key, and that the term "private key" may be 196 used to refer to either a private decryption key or a signature 197 generation key. The fact that these are logically distinct does 198 not preclude the assignment of bitwise identical keys. 200 All additional symmetric keys specified in this draft shall use the 201 same encryption type as the session key in the response from the 202 KDC. These include the temporary keys used to encrypt the signed 203 random key encrypting the response, as well as the key derived from 204 Diffie-Hellman agreement. In the case of Diffie-Hellman, the key 205 shall be produced from the agreed bit string as follows: 207 * Truncate the bit string to the appropriate length. 208 * Rectify parity in each byte (if necessary) to obtain the key. 210 For instance, in the case of a DES key, we take the first eight 211 bytes of the bit stream, and then adjust the least significant bit 212 of each byte to ensure that each byte has odd parity. 214 3.1.2. Algorithm Identifiers 216 PKINIT does not define, but does permit, the algorithm identifiers 217 listed below. 219 3.1.2.1. Signature Algorithm Identifiers 221 These are the algorithm identifiers for use in the Signature data 222 structure: 224 sha-1WithRSAEncryption ALGORITHM PARAMETER NULL 225 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 226 pkcs-1(1) 5 } 228 dsaWithSHA1 ALGORITHM PARAMETER NULL 229 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 230 oIWSecAlgorithm(2) dsaWithSHA1(27) } 232 md4WithRsaEncryption ALGORITHM PARAMETER NULL 233 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 234 oIWSecAlgorithm(2) md4WithRSAEncryption(4) } 236 md5WithRSAEncryption ALGORITHM PARAMETER NULL 237 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 238 pkcs-1(1) md5WithRSAEncryption(4) } 240 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier 242 This algorithm identifier is used inside the SubjectPublicKeyInfo 243 data structure: 245 dhKeyAgreement ALGORITHM PARAMETER DHParameters 246 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 247 pkcs-3(3) dhKeyAgreement(1) } 249 DHParameters ::= SEQUENCE { 250 prime INTEGER, 251 -- p 252 base INTEGER, 253 -- g 254 privateValueLength INTEGER OPTIONAL 255 } -- as specified by the X.509 recommendation [9] 257 3.1.2.3. Algorithm Identifiers for RSA Encryption 259 These algorithm identifiers are used inside the EnvelopedData data 260 structure, for encrypting the temporary key with a public key: 262 rsaEncryption ALGORITHM PARAMETER NULL 263 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 264 pkcs-1(1) rsaEncryption(1) 266 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys 268 These algorithm identifiers are used inside the EnvelopedData data 269 structure, for encrypting the temporary key with a Diffie-Hellman- 270 derived key, or for encrypting the reply key: 272 desCBC ALGORITHM PARAMETER IV8 273 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 274 oIWSecAlgorithm(2) desCBC(7) } 276 DES-EDE3-CBC ALGORITHM PARAMETER IV8 277 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 278 encryptionAlgorithm(3) desEDE3(7) } 280 IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector 282 rc2CBC ALGORITHM PARAMETER RC2-CBCParameter 283 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 284 encryptionAlgorithm(3) rc2CBC(2) } 286 The rc2CBC algorithm parameters (RC2-CBCParameter) are defined 287 in the following section. 289 rc4 ALGORITHM PARAMETER NULL 290 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 291 encryptionAlgorithm(3) rc4(4) } 293 The rc4 algorithm cannot be used with the Diffie-Hellman-derived 294 keys, because its parameters do not specify the size of the key. 296 3.1.2.5. rc2CBC Algorithm Parameters 298 This definition of the RC2 parameters is taken from a paper by 299 Ron Rivest [13]. Refer to [13] for the complete description of the 300 RC2 algorithm. 302 RC2-CBCParameter ::= CHOICE { 303 iv IV, 304 params SEQUENCE { 305 version RC2Version, 306 iv IV 307 } 308 } 310 where 312 IV ::= OCTET STRING -- 8 octets 313 RC2Version ::= INTEGER -- 1-1024 315 RC2 in CBC mode has two parameters: an 8-byte initialization 316 vector (IV) and a version number in the range 1-1024 which 317 specifies in a roundabout manner the number of effective key bits 318 to be used for the RC2 encryption/decryption. 320 The correspondence between effective key bits and version number 321 is as follows: 323 1. If the number EKB of effective key bits is in the range 1-255, 324 then the version number is given by Table[EKB], where the 325 256-byte translation table is specified below. It specifies a 326 permutation on the numbers 0-255. 328 2. If the number EKB of effective key bits is in the range 329 256-1024, then the version number is simply EKB. 331 The default number of effective key bits for RC2 is 32. 332 If RC2-CBC is being performed with 32 effective key bits, the 333 parameters should be supplied as a simple IV, rather than as a 334 SEQUENCE containing a version and an IV. 336 0 1 2 3 4 5 6 7 8 9 a b c d e f 338 00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0 339 10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a 340 20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36 341 30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c 342 40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60 343 50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa 344 60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e 345 70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf 346 80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6 347 90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3 348 a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c 349 b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2 350 c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5 351 d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5 352 e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f 353 f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab 355 3.2. Standard Public Key Authentication 357 Implementation of the changes in this section is REQUIRED for 358 compliance with PKINIT. 360 It is assumed that all public keys are signed by some certification 361 authority (CA). The initial authentication request is sent as per 362 RFC 1510, except that a preauthentication field containing data 363 signed by the user's private key accompanies the request: 365 PA-PK-AS-REQ ::= SEQUENCE { 366 -- PA TYPE 14 367 signedAuthPack [0] SignedAuthPack 368 userCert [1] SEQUENCE OF Certificate OPTIONAL, 369 -- the user's certificate chain; 370 -- if present, the KDC must use 371 -- the public key from this 372 -- particular certificate chain to 373 -- verify the signature in the 374 -- request 375 trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL, 376 -- CAs that the client trusts 377 serialNumber [3] CertificateSerialNumber OPTIONAL 378 -- specifying a particular KDC 379 -- certificate if the client 380 -- already has it; 381 -- must be accompanied by 382 -- a single trustedCertifier 383 } 385 CertificateSerialNumber ::= INTEGER 386 -- as specified by PKCS #6 [15] 388 SignedAuthPack ::= SEQUENCE { 389 authPack [0] AuthPack, 390 authPackSig [1] Signature, 391 -- of authPack 392 -- using user's private key 393 } 395 AuthPack ::= SEQUENCE { 396 pkAuthenticator [0] PKAuthenticator, 397 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 398 -- if client is using Diffie-Hellman 399 } 401 PKAuthenticator ::= SEQUENCE { 402 kdcName [0] PrincipalName, 403 kdcRealm [1] Realm, 404 cusec [2] INTEGER, 405 -- for replay prevention 406 ctime [3] KerberosTime, 407 -- for replay prevention 408 nonce [4] INTEGER 409 } 411 Signature ::= SEQUENCE { 412 signatureAlgorithm [0] SignatureAlgorithmIdentifier, 413 pkcsSignature [1] BIT STRING 414 -- octet-aligned big-endian bit 415 -- string (encrypted with signer's 416 -- private key) 417 } 419 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 421 AlgorithmIdentifier ::= SEQUENCE { 422 algorithm ALGORITHM.&id, 423 parameters ALGORITHM.&type 424 } -- as specified by the X.509 recommendation [10] 426 SubjectPublicKeyInfo ::= SEQUENCE { 427 algorithm AlgorithmIdentifier, 428 -- dhKeyAgreement 429 subjectPublicKey BIT STRING 430 -- for DH, equals 431 -- public exponent (INTEGER encoded 432 -- as payload of BIT STRING) 433 } -- as specified by the X.509 recommendation [9] 435 Certificate ::= SEQUENCE { 436 certType [0] INTEGER, 437 -- type of certificate 438 -- 1 = X.509v3 (DER encoding) 439 -- 2 = PGP (per PGP specification) 440 -- 3 = PKIX (per PKCS #6 [15]) 441 certData [1] OCTET STRING 442 -- actual certificate 443 -- type determined by certType 444 } 446 If the client passes a certificate serial number in the request, 447 the KDC is requested to use the referred-to certificate. If none 448 exists, then the KDC returns an error of type 449 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 450 other hand, the client does not pass any trustedCertifiers, 451 believing that it has the KDC's certificate, but the KDC has more 452 than one certificate. 454 The PKAuthenticator carries information to foil replay attacks, 455 to bind the request and response, and to optionally pass the 456 client's Diffie-Hellman public value (i.e. for using DSA in 457 combination with Diffie-Hellman). The PKAuthenticator is signed 458 with the private key corresponding to the public key in the 459 certificate found in userCert (or cached by the KDC). 461 The userCert field is a sequence of certificates, the first of which 462 must be the user's public key certificate. Any subsequent 463 certificates will be certificates of the certifiers of the user's 464 certificate. These cerificates may be used by the KDC to verify the 465 user's public key. This field may be left empty if the KDC already 466 has the user's certificate. 468 The trustedCertifiers field contains a list of certification 469 authorities trusted by the client, in the case that the client does 470 not possess the KDC's public key certificate. If the KDC has no 471 certificate signed by any of the trustedCertifiers, then it returns 472 an error of type KDC_ERR_CERTIFICATE_MISMATCH. 474 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 475 type, the KDC attempts to verify the user's certificate chain 476 (userCert), if one is provided in the request. This is done by 477 verifying the certification path against the KDC's policy of 478 legitimate certifiers. This may be based on a certification 479 hierarchy, or it may be simply a list of recognized certifiers in a 480 system like PGP. 482 If verification of the user's certificate fails, the KDC sends back 483 an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data 484 field contains additional information pertaining to this error, and 485 is formatted as follows: 487 METHOD-DATA ::= SEQUENCE { 488 method-type [0] INTEGER, 489 -- 1 = cannot verify public key 490 -- 2 = invalid certificate 491 -- 3 = revoked certificate 492 -- 4 = invalid KDC name 493 -- 5 = client name mismatch 494 method-data [1] OCTET STRING OPTIONAL 495 } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) 497 The values for the method-type and method-data fields are described 498 in Section 3.2.1. 500 If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC 501 verifies that it has a certificate issued by one of the certifiers 502 trusted by the client. If it does not have a suitable certificate, 503 the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to 504 the client. 506 If a trust relationship exists, the KDC then verifies the client's 507 signature on AuthPack. If that fails, the KDC returns an error 508 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 509 timestamp in the PKAuthenticator to assure that the request is not a 510 replay. The KDC also verifies that its name is specified in the 511 PKAuthenticator. 513 If the clientPublicValue field is filled in, indicating that the 514 client wishes to use Diffie-Hellman key agreement, then the KDC 515 checks to see that the parameters satisfy its policy. If they do 516 not (e.g., the prime size is insufficient for the expected 517 encryption type), then the KDC sends back an error message of type 518 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and 519 private values for the response. 521 The KDC also checks that the timestamp in the PKAuthenticator is 522 within the allowable window. If the local (server) time and the 523 client time in the authenticator differ by more than the allowable 524 clock skew, then the KDC returns an error message of type 525 KRB_AP_ERR_SKEW. 527 Assuming no errors, the KDC replies as per RFC 1510, except as 528 follows. The user's name in the ticket is determined by the 529 following decision algorithm: 531 1. If the KDC has a mapping from the name in the certificate 532 to a Kerberos name, then use that name. Else 533 2. If the certificate contains a Kerberos name in an extension 534 field, and local KDC policy allows, then use that name. 535 Else 536 3. Use the name as represented in the certificate, mapping 537 as necessary (e.g., as per RFC 2253 for X.500 names). In 538 this case the realm in the ticket shall be the name of the 539 certification authority that issued the user's certificate. 541 The KDC encrypts the reply not with the user's long-term key, but 542 with a random key generated only for this particular response. This 543 random key is sealed in the preauthentication field: 545 PA-PK-AS-REP ::= SEQUENCE { 546 -- PA TYPE 15 547 encKeyPack [1] EnvelopedKeyPack, 548 -- temporary key is encrypted 549 -- using either the client public 550 -- key or the Diffie-Hellman key 551 -- specified by SignedKDCPublicValue. 552 -- SignedReplyKeyPack, encrypted 553 -- with the temporary key, is also 554 -- included. 555 signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL, 556 -- if one was passed in the request 557 kdcCert [3] SEQUENCE OF Certificate OPTIONAL 558 -- the KDC's certificate chain 559 } 561 The EnvelopedKeyPack data type below contains an encrypted 562 temporary key (either with the PKINIT client's public key or with a 563 symmetric key, resulting from the Diffie-Hellman exchange). It also 564 contains a signed and encrypted reply key. This data structure is 565 similar to EnvelopedData, defined in CMS [11] and PKCS #7 [12]. 567 EnvelopedKeyPack ::= SEQUENCE { 568 version Version, 569 -- Always set to 0. 570 recipientInfos RecipientInfos, 571 -- This is a SET, which must contain 572 -- exactly one member. Contains a 573 -- temporary key, encrypted with the 574 -- client's public key. This 575 -- temporary key is used to encrypt 576 -- the reply key. 577 encryptedContentInfo EncryptedContentInfo 578 -- contains the signed and encrypted 579 -- reply key 580 } 582 Version ::= INTEGER 584 RecipientInfos ::= SET OF RecipientInfo 586 RecipientInfo ::= SEQUENCE { 587 version Version, 588 -- shall be 0 589 rid RecipientIdentifier, 590 -- Since this is an optional field, 591 -- it supports both CMS and PKCS #7 592 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 593 EncryptedKey OCTET STRING 594 -- the temporary key, encrypted with 595 -- the PKINIT client's public key 596 } 598 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 600 RecipientIdentifier ::= IssuerAndSerialNumber 601 -- Corresponds to the X.509 V3 extension 602 -- SubjectKeyIdentifier. 604 IssuerAndSerialNumber ::= SEQUENCE { 605 issuer Name, 606 -- a distinguished name, as defined 607 -- by X.509 608 serialNumber CertificateSerialNumber 609 } 611 CertificateSerialNumber ::= INTEGER 613 EncryptedContentInfo ::= SEQUENCE { 614 contentType ContentType, 615 -- shall be: 616 -- iso(1) member-body(2) us(840) 617 -- rsadsi(113549) pkcs(1) pkcs7(7) 618 -- EnvelopedData(3) 619 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier 620 -- Algorithm used to encrypt the 621 -- SignedReplyKeyPack. 622 encryptedContent OCTET STRING 623 -- The encrypted data is of the type 624 -- SignedReplyKeyPack. 625 } 627 ContentType ::= OBJECT IDENTIFIER 629 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 631 SignedReplyKeyPack ::= SEQUENCE { 632 replyKeyPack [0] ReplyKeyPack, 633 replyKeyPackSig [1] Signature, 634 -- of replyKeyPack 635 -- using KDC's private key 636 } 638 ReplyKeyPack ::= SEQUENCE { 639 replyKey [0] EncryptionKey, 640 -- used to encrypt main reply 641 -- of same ENCTYPE as session key 642 nonce [1] INTEGER 643 -- binds response to the request 644 -- must be same as the nonce 645 -- passed in the PKAuthenticator 646 } 648 SignedKDCPublicValue ::= SEQUENCE { 649 kdcPublicValue [0] SubjectPublicKeyInfo, 650 -- as described above 651 kdcPublicValueSig [1] Signature 652 -- of kdcPublicValue 653 -- using KDC's private key 654 } 656 The kdcCert field is a sequence of certificates, the first of which 657 must be the KDC's public key certificate. Any subsequent 658 certificates will be certificates of the certifiers of the KDC's 659 certificate. The last of these must have as its certifier one of 660 the certifiers sent to the KDC in the PA-PK-AS-REQ. These 661 cerificates may be used by the client to verify the KDC's public 662 key. This field is empty if the client did not send to the KDC a 663 list of trusted certifiers (the trustedCertifiers field was empty). 665 Since each certifier in the certification path of a user's 666 certificate is essentially a separate realm, the name of each 667 certifier shall be added to the transited field of the ticket. The 668 format of these realm names is defined in Section 3.1 of this 669 document. If applicable, the transit-policy-checked flag should be 670 set in the issued ticket. 672 The KDC's certificate must bind the public key to a name derivable 673 from the name of the realm for that KDC. X.509 certificates shall 674 contain the principal name of the KDC as the SubjectAltName version 675 3 extension. Below is the definition of this version 3 extension, as 676 specified by the X.509 standard: 678 subjectAltName EXTENSION ::= { 679 SYNTAX GeneralNames 680 IDENTIFIED BY id-ce-subjectAltName 681 } 683 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName 685 GeneralName ::= CHOICE { 686 otherName [0] INSTANCE OF OTHER-NAME, 687 ... 688 } 690 OTHER-NAME ::= TYPE-IDENTIFIER 692 In this definition, otherName is a name of any form defined as an 693 instance of the OTHER-NAME information object class. For the purpose 694 of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will 695 be replaced by the type KerberosPrincipalName: 697 KerberosPrincipalName ::= SEQUENCE { 698 nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ), 699 name [1] OTHER-NAME.&type ( { PrincipalNameTypes } 700 { @nameType } ) 701 } 703 PrincipalNameTypes OTHER-NAME ::= { 704 { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } 705 } 707 PrincipalNameSrvInst ::= GeneralString 709 where (from the Kerberos specification) we have 711 krb5 OBJECT IDENTIFIER ::= { iso (1) 712 org (3) 713 dod (6) 714 internet (1) 715 security (5) 716 kerberosv5 (2) } 718 principalName OBJECT IDENTIFIER ::= { krb5 2 } 720 principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } 722 (This specification can also be used to specify a Kerberos name 723 within the user's certificate.) 725 The client then extracts the random key used to encrypt the main 726 reply. This random key (in encPaReply) is encrypted with either the 727 client's public key or with a key derived from the DH values 728 exchanged between the client and the KDC. 730 3.2.1. Additional Information for Errors 732 This section describes the interpretation of the method-type and 733 method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. 735 If method-type=1, the client's public key certificate chain does not 736 contain a certificate that is signed by a certification authority 737 trusted by the KDC. The format of the method-data field will be an 738 ASN.1 encoding of a list of trusted certifiers, as defined above: 740 TrustedCertifiers ::= SEQUENCE OF PrincipalName 742 If method-type=2, the signature on one of the certificates in the 743 chain cannot be verified. The format of the method-data field will 744 be an ASN.1 encoding of the integer index of the certificate in 745 question: 747 CertificateIndex ::= INTEGER 748 -- 0 = 1st certificate, 749 -- 1 = 2nd certificate, etc 751 If method-type=3, one of the certificates in the chain has been 752 revoked. The format of the method-data field will be an ASN.1 753 encoding of the integer index of the certificate in question: 755 CertificateIndex ::= INTEGER 756 -- 0 = 1st certificate, 757 -- 1 = 2nd certificate, etc 759 If method-type=4, the KDC name or realm in the PKAuthenticator does 760 not match the principal name of the KDC. There is no method-data 761 field in this case. 763 If method-type=5, the client name or realm in the certificate does 764 not match the principal name of the client. There is no 765 method-data field in this case. 767 3.2.2. Required Algorithms and Data Formats 769 Not all of the algorithms in the PKINIT protocol specification have 770 to be implemented in order to comply with the proposed standard. 771 Below is a list of the required algorithms and data formats: 773 - Diffie-Hellman public/private key pairs 774 - SHA1 digest and DSA for signatures 775 - X.509 version 3 certificates 776 - 3-key triple DES keys derived from the Diffie-Hellman Exchange 777 - 3-key triple DES Temporary and Reply keys 779 3.3. Digital Signature 781 Implementation of the changes in this section are OPTIONAL for 782 compliance with PKINIT. 784 We offer this option with the warning that it requires the client to 785 generate a random key; the client may not be able to guarantee the 786 same level of randomness as the KDC. 788 If the user registered, or presents a certificate for, a digital 789 signature key with the KDC instead of an encryption key, then a 790 separate exchange must be used. The client sends a request for a 791 TGT as usual, except that it (rather than the KDC) generates the 792 random key that will be used to encrypt the KDC response. This key 793 is sent to the KDC along with the request in a preauthentication 794 field, encrypted with the KDC's public key: 796 PA-PK-AS-SIGN ::= SEQUENCE { 797 -- PA TYPE 16 798 encKeyPack [1] EnvelopedKeyPack, 799 -- temporary key is encrypted 800 -- using the KDC public 801 -- key. 802 -- SignedRandomKeyPack, encrypted 803 -- with the temporary key, is also 804 -- included. 805 userCert [2] SEQUENCE OF Certificate OPTIONAL 806 -- the user's certificate chain; 807 -- if present, the KDC must use 808 -- the public key from this 809 -- particular certificate chain to 810 -- verify the signature in the 811 -- request 812 } 814 In the above message, the content of the encKeyPack is similar to 815 the content of the encKeyPack field in the PA-PK-AS-REP message, 816 except that it is the KDC's public key and not the client's public 817 key that is used to encrypt the temporary key. And, the 818 encryptedContentInfo field inside the EnvelopedKeyPack contains 819 encrypted data of the type SignedRandomKeyPack instead of the 820 SignedReplyKeyPack. 822 SignedRandomKeyPack ::= SEQUENCE { 823 randomkeyPack [0] RandomKeyPack, 824 randomkeyPackSig [1] Signature 825 -- of keyPack 826 -- using user's private key 827 } 829 RandomKeyPack ::= SEQUENCE { 830 randomKey [0] EncryptionKey, 831 -- will be used to encrypt reply 832 randomKeyAuth [1] PKAuthenticator 833 } 835 If the KDC does not accept client-generated random keys as a matter 836 of policy, then it sends back an error message of type 837 KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as 838 follows. 840 Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies 841 the randomKey. It then replies as per RFC 1510, except that the 842 reply is encrypted not with a password-derived user key, but with 843 the randomKey sent in the request. Since the client already knows 844 this key, there is no need to accompany the reply with an extra 845 preauthentication field. The transited field of the ticket should 846 specify the certification path as described in Section 3.2. 848 3.4. Retrieving the User's Private Key from the KDC 850 Implementation of the changes described in this section are OPTIONAL 851 for compliance with PKINIT. (This section may or may not fall under 852 the purview of a patent for private key storage; please see Section 853 8 for more information.) 855 When the user's private key is not stored local to the user, he may 856 choose to store the private key (normally encrypted using a 857 password-derived key) on the KDC. In this case, the client makes a 858 request as described above, except that instead of preauthenticating 859 with his private key, he uses a symmetric key shared with the KDC. 861 For simplicity's sake, this shared key is derived from the password- 862 derived key used to encrypt the private key, in such a way that the 863 KDC can authenticate the user with the shared key without being able 864 to extract the private key. 866 We provide this option to present the user with an alternative to 867 storing the private key on local disk at each machine where he 868 expects to authenticate himself using PKINIT. It should be noted 869 that it replaces the added risk of long-term storage of the private 870 key on possibly many workstations with the added risk of storing the 871 private key on the KDC in a form vulnerable to brute-force attack. 873 Denote by K1 the symmetric key used to encrypt the private key. 874 Then construct symmetric key K2 as follows: 876 * Perform a hash on K1. 877 * Truncate the digest to Length(K1) bytes. 878 * Rectify parity in each byte (if necessary) to obtain K2. 880 The KDC stores K2, the public key, and the encrypted private key. 881 This key pair is designated as the "primary" key pair for that user. 882 This primary key pair is the one used to perform initial 883 authentication using the PA-PK-AS-REP preauthentication field. If 884 he desires, he may also store additional key pairs on the KDC; these 885 may be requested in addition to the primary. When the client 886 requests initial authentication using public key cryptography, it 887 must then include in its request, instead of a PA-PK-AS-REQ, the 888 following preauthentication sequence: 890 PA-PK-KEY-REQ ::= SEQUENCE { 891 -- PA TYPE 17 892 signedPKAuth [0] SignedPKAuth, 893 trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, 894 -- CAs that the client trusts 895 keyIDList [2] SEQUENCE OF Checksum OPTIONAL 896 -- payload is hash of public key 897 -- corresponding to desired 898 -- private key 899 -- if absent, KDC will return all 900 -- stored private keys 901 } 903 Checksum ::= SEQUENCE { 904 cksumtype [0] INTEGER, 905 checksum [1] OCTET STRING 906 } -- as specified by RFC 1510 908 SignedPKAuth ::= SEQUENCE { 909 pkAuth [0] PKAuthenticator, 910 pkAuthSig [1] Signature 911 -- of pkAuth 912 -- using the symmetric key K2 913 } 915 If a keyIDList is present, the first identifier should indicate 916 the primary private key. No public key certificate is required, 917 since the KDC stores the public key along with the private key. 918 If there is no keyIDList, all the user's private keys are returned. 920 Upon receipt, the KDC verifies the signature using K2. If the 921 verification fails, the KDC sends back an error of type 922 KDC_ERR_INVALID_SIG. If the signature verifies, but the requested 923 keys are not found on the KDC, then the KDC sends back an error of 924 type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as 925 described in Section 3.2, except that in addition, the KDC appends 926 the following preauthentication sequence: 928 PA-PK-KEY-REP ::= SEQUENCE { 929 -- PA TYPE 18 930 encKeyRep [0] EncryptedData 931 -- of type EncKeyReply 932 -- using the symmetric key K2 933 } 935 EncKeyReply ::= SEQUENCE { 936 keyPackList [0] SEQUENCE OF KeyPack, 937 -- the first KeyPair is 938 -- the primary key pair 939 nonce [1] INTEGER 940 -- binds reply to request 941 -- must be identical to the nonce 942 -- sent in the SignedAuthPack 943 } 945 KeyPack ::= SEQUENCE { 946 keyID [0] Checksum, 947 encPrivKey [1] OCTET STRING 948 } 950 Upon receipt of the reply, the client extracts the encrypted private 951 keys (and may store them, at the client's option). The primary 952 private key, which must be the first private key in the keyPack 953 SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP; 954 this key in turn is used to decrypt the main reply as described in 955 Section 3.2. 957 4. Logistics and Policy 959 This section describes a way to define the policy on the use of 960 PKINIT for each principal and request. 962 The KDC is not required to contain a database record for users 963 that use either the Standard Public Key Authentication or Public Key 964 Authentication with a Digital Signature. However, if these users 965 are registered with the KDC, it is recommended that the database 966 record for these users be modified to include three additional flags 967 in the attributes field. 969 The first flag, use_standard_pk_init, indicates that the user should 970 authenticate using standard PKINIT as described in Section 3.2. The 971 second flag, use_digital_signature, indicates that the user should 972 authenticate using digital signature PKINIT as described in Section 973 3.3. The third flag, store_private_key, indicates that the user 974 has stored his private key on the KDC and should retrieve it using 975 the exchange described in Section 3.4. 977 If one of the preauthentication fields defined above is included in 978 the request, then the KDC shall respond as described in Sections 3.2 979 through 3.4, ignoring the aforementioned database flags. If more 980 than one of the preauthentication fields is present, the KDC shall 981 respond with an error of type KDC_ERR_PREAUTH_FAILED. 983 In the event that none of the preauthentication fields defined above 984 are included in the request, the KDC checks to see if any of the 985 above flags are set. If the first flag is set, then it sends back 986 an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a 987 preauthentication field of type PA-PK-AS-REQ must be included in the 988 request. 990 Otherwise, if the first flag is clear, but the second flag is set, 991 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED 992 indicating that a preauthentication field of type PA-PK-AS-SIGN must 993 be included in the request. 995 Lastly, if the first two flags are clear, but the third flag is set, 996 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED 997 indicating that a preauthentication field of type PA-PK-KEY-REQ must 998 be included in the request. 1000 5. Security Considerations 1002 PKINIT raises a few security considerations, which we will address 1003 in this section. 1005 First of all, PKINIT introduces a new trust model, where KDCs do not 1006 (necessarily) certify the identity of those for whom they issue 1007 tickets. PKINIT does allow KDCs to act as their own CAs, in order 1008 to simplify key management, but one of the additional benefits is to 1009 align Kerberos authentication with a global public key 1010 infrastructure. Anyone using PKINIT in this way must be aware of 1011 how the certification infrastructure they are linking to works. 1013 Secondly, PKINIT also introduces the possibility of interactions 1014 between different cryptosystems, which may be of widely varying 1015 strengths. Many systems, for instance, allow the use of 512-bit 1016 public keys. Using such keys to wrap data encrypted under strong 1017 conventional cryptosystems, such as triple-DES, is inappropriate; 1018 it adds a weak link to a strong one at extra cost. Implementors 1019 and administrators should take care to avoid such wasteful and 1020 deceptive interactions. 1022 Lastly, PKINIT calls for randomly generated keys for conventional 1023 cryptosystems. Many such systems contain systematically "weak" 1024 keys. PKINIT implementations MUST avoid use of these keys, either 1025 by discarding those keys when they are generated, or by fixing them 1026 in some way (e.g., by XORing them with a given mask). These 1027 precautions vary from system to system; it is not our intention to 1028 give an explicit recipe for them here. 1030 5. Transport Issues 1032 Certificate chains can potentially grow quite large and span several 1033 UDP packets; this in turn increases the probability that a Kerberos 1034 message involving PKINIT extensions will be broken in transit. In 1035 light of the possibility that the Kerberos specification will 1036 require KDCs to accept requests using TCP as a transport mechanism, 1037 we make the same recommendation with respect to the PKINIT 1038 extensions as well. 1040 6. Bibliography 1042 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 1043 (V5). Request for Comments 1510. 1045 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 1046 for Computer Networks, IEEE Communications, 32(9):33-38. September 1047 1994. 1049 [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, 1050 A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm 1051 Authentication in Kerberos. 1052 draft-ietf-cat-kerberos-pk-cross-04.txt 1054 [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in 1055 Kerberos. 1056 draft-ietf-cat-kerberos-anoncred-00.txt 1058 [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 1059 Tickets for Application Servers (PKTAPP). 1060 draft-ietf-cat-pktapp-00.txt 1062 [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 1063 Using Public Key Cryptography. Symposium On Network and Distributed 1064 System Security, 1997. 1066 [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 1067 Protocol. In Proceedings of the USENIX Workshop on Electronic 1068 Commerce, July 1995. 1070 [8] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL 1071 Protocol, Version 3.0 - IETF Draft. 1073 [9] B.C. Neuman, Proxy-Based Authorization and Accounting for 1074 Distributed Systems. In Proceedings of the 13th International 1075 Conference on Distributed Computing Systems, May 1993. 1077 [10] ITU-T (formerly CCITT) Information technology - Open Systems 1078 Interconnection - The Directory: Authentication Framework 1079 Recommendation X.509 ISO/IEC 9594-8 1081 [11] R. Hously. Cryptographic Message Syntax. 1082 draft-ietf-smime-cms-04.txt, March 1998. 1084 [12] PKCS #7: Cryptographic Message Syntax Standard, 1085 An RSA Laboratories Technical Note Version 1.5 1086 Revised November 1, 1993 1088 [13] Ron Rivest, MIT Laboratory for Computer Science and 1089 RSA Data Security, Inc. A Description of the RC2(r) Encryption 1090 Algorithm, November 1997. 1092 [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access 1093 Protocol (v3): UTF-8 String Representation of Distinguished Names. 1094 Request for Comments 2253. 1096 [15] PKCS #6: Cryptographic Message Syntax Standard, 1097 An RSA Laboratories Technical Note Version 1.5 1098 Revised November 1, 1993 1100 7. Patent Issues 1102 The private key storage and retrieval process described in Section 1103 3.4 may be covered by U.S. Patent 5,418,854 (Charles Kaufman, Morrie 1104 Gasser, Butler Lampson, Joseph Tardo, Kannan Alagappan, all then of 1105 Digital Corporation). At this time, inquiries into this patent are 1106 inconclusive. We solicit discussion from any party who can illuminate 1107 the coverage of this particular patent. 1109 8. Acknowledgements 1111 Some of the ideas on which this proposal is based arose during 1112 discussions over several years between members of the SAAG, the IETF 1113 CAT working group, and the PSRG, regarding integration of Kerberos 1114 and SPX. Some ideas have also been drawn from the DASS system. 1115 These changes are by no means endorsed by these groups. This is an 1116 attempt to revive some of the goals of those groups, and this 1117 proposal approaches those goals primarily from the Kerberos 1118 perspective. Lastly, comments from groups working on similar ideas 1119 in DCE have been invaluable. 1121 9. Expiration Date 1123 This draft expires May 15, 1999. 1125 10. Authors 1127 Brian Tung 1128 Clifford Neuman 1129 USC Information Sciences Institute 1130 4676 Admiralty Way Suite 1001 1131 Marina del Rey CA 90292-6695 1132 Phone: +1 310 822 1511 1133 E-mail: {brian, bcn}@isi.edu 1135 John Wray 1136 Digital Equipment Corporation 1137 550 King Street, LKG2-2/Z7 1138 Littleton, MA 01460 1139 Phone: +1 508 486 5210 1140 E-mail: wray@tuxedo.enet.dec.com 1142 Ari Medvinsky 1143 Matthew Hur 1144 Sasha Medvinsky 1145 CyberSafe Corporation 1146 1605 NW Sammamish Road Suite 310 1147 Issaquah WA 98027-5378 1148 Phone: +1 206 391 6000 1149 E-mail: {ari.medvinsky, matt.hur, sasha.medvinsky}@cybersafe.com 1151 Jonathan Trostle 1152 170 W. Tasman Dr. 1153 San Jose, CA 95134 1154 E-mail: jtrostle@cisco.com