idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-03.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-03-28) 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. == 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 589 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 160: '...hanges in this section is REQUIRED for...' RFC 2119 keyword, line 171: '... userCert [1] SEQUENCE OF Certificate OPTIONAL,...' RFC 2119 keyword, line 175: '... trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL...' RFC 2119 keyword, line 194: '... clientPubValue [4] SubjectPublicKeyInfo OPTIONAL,...' RFC 2119 keyword, line 283: '... kdcCert [0] SEQUENCE OF Certificate OPTIONAL,...' (6 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: ---------------------------------------------------------------------------- == Line 263 has weird spacing: '... If truste...' (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 493 looks like a reference -- Missing reference section? '2' on line 496 looks like a reference -- Missing reference section? '4' on line 504 looks like a reference -- Missing reference section? '5' on line 508 looks like a reference -- Missing reference section? '6' on line 512 looks like a reference -- Missing reference section? '7' on line 516 looks like a reference -- Missing reference section? '8' on line 519 looks like a reference -- Missing reference section? '0' on line 439 looks like a reference -- Missing reference section? '3' on line 500 looks like a reference -- Missing reference section? '9' on line 523 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Clifford Neuman 2 draft-ietf-cat-kerberos-pk-init-03.txt Brian Tung 3 Updates: RFC 1510 ISI 4 expires September 30, 1997 John Wray 5 Digital Equipment Corporation 6 Ari Medvinsky 7 Matthew Hur 8 CyberSafe Corporation 9 Jonathan Trostle 10 Novell 12 Public Key Cryptography for Initial Authentication in Kerberos 14 0. Status Of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 To learn the current status of any Internet-Draft, please check 28 the "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ds.internic.net (US East Coast), 30 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 31 munnari.oz.au (Pacific Rim). 33 The distribution of this memo is unlimited. It is filed as 34 draft-ietf-cat-kerberos-pk-init-03.txt, and expires September 30, 35 1997. Please send comments to the authors. 37 1. Abstract 39 This document defines extensions (PKINIT) to the Kerberos protocol 40 specification (RFC 1510 [1]) to provide a method for using public 41 key cryptography during initial authentication. The methods 42 defined specify the ways in which preauthentication data fields and 43 error data fields in Kerberos messages are to be used to transport 44 public key data. 46 2. Introduction 48 The popularity of public key cryptography has produced a desire for 49 its support in Kerberos [2]. The advantages provided by public key 50 cryptography include simplified key management (from the Kerberos 51 perspective) and the ability to leverage existing and developing 52 public key certification infrastructures. 54 Public key cryptography can be integrated into Kerberos in a number 55 of ways. One is to to associate a key pair with each realm, which 56 can then be used to facilitate cross-realm authentication; this is 57 the topic of another draft proposal. Another way is to allow users 58 with public key certificates to use them in initial authentication. 59 This is the concern of the current document. 61 One of the guiding principles in the design of PKINIT is that 62 changes should be as minimal as possible. As a result, the basic 63 mechanism of PKINIT is as follows: The user sends a request to the 64 KDC as before, except that if that user is to use public key 65 cryptography in the initial authentication step, his certificate 66 accompanies the initial request, in the preauthentication fields. 68 Upon receipt of this request, the KDC verifies the certificate and 69 issues a ticket granting ticket (TGT) as before, except that instead 70 of being encrypted in the user's long-term key (which is derived 71 from a password), it is encrypted in a randomly-generated key. This 72 random key is in turn encrypted using the public key certificate 73 that came with the request and signed using the KDC's signature key, 74 and accompanies the reply, in the preauthentication fields. 76 PKINIT also allows for users with only digital signature keys to 77 authenticate using those keys, and for users to store and retrieve 78 private keys on the KDC. 80 The PKINIT specification may also be used for direct peer to peer 81 authentication without contacting a central KDC. This application 82 of PKINIT is described in PKTAPP [4] and is based on concepts 83 introduced in [5, 6]. For direct client-to-server authentication, 84 the client uses PKINIT to authenticate to the end server (instead 85 of a central KDC), which then issues a ticket for itself. This 86 approach has an advantage over SSL [7] in that the server does not 87 need to save state (cache session keys). Furthermore, an 88 additional benefit is that Kerberos tickets can facilitate 89 delegation (see [8]). 91 3. Proposed Extensions 93 This section describes extensions to RFC 1510 for supporting the 94 use of public key cryptography in the initial request for a ticket 95 granting ticket (TGT). 97 In summary, the following changes to RFC 1510 are proposed: 99 --> Users may authenticate using either a public key pair or a 100 conventional (symmetric) key. If public key cryptography is 101 used, public key data is transported in preauthentication 102 data fields to help establish identity. 103 --> Users may store private keys on the KDC for retrieval during 104 Kerberos initial authentication. 106 This proposal addresses two ways that users may use public key 107 cryptography for initial authentication. Users may present public 108 key certificates, or they may generate their own session key, 109 signed by their digital signature key. In either case, the end 110 result is that the user obtains an ordinary TGT that may be used for 111 subsequent authentication, with such authentication using only 112 conventional cryptography. 114 Section 3.1 provides definitions to help specify message formats. 115 Section 3.2 and 3.3 describe the extensions for the two initial 116 authentication methods. Section 3.3 describes a way for the user to 117 store and retrieve his private key on the KDC. 119 3.1. Definitions 121 Hash and encryption types will be specified using ENCTYPE tags; we 122 propose the addition of the following types: 124 #define ENCTYPE_SIGN_DSA_GENERATE 0x0011 125 #define ENCTYPE_SIGN_DSA_VERIFY 0x0012 126 #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021 127 #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022 129 allowing further signature types to be defined in the range 0x0011 130 through 0x001f, and further encryption types to be defined in the 131 range 0x0021 through 0x002f. 133 The extensions involve new preauthentication fields. The 134 preauthentication data types are in the range 17 through 21. 135 These values are also specified along with their corresponding 136 ASN.1 definition. 138 #define PA-PK-AS-REQ 17 139 #define PA-PK-AS-REP 18 140 #define PA-PK-AS-SIGN 19 141 #define PA-PK-KEY-REQ 20 142 #define PA-PK-KEY-REP 21 144 The extensions also involve new error types. The new error types 145 are in the range 227 through 229. They are: 147 #define KDC_ERROR_CLIENT_NOT_TRUSTED 227 148 #define KDC_ERROR_KDC_NOT_TRUSTED 228 149 #define KDC_ERROR_INVALID_SIG 229 151 In the exposition below, we use the following terms: encryption key, 152 decryption key, signature key, verification key. It should be 153 understood that encryption and verification keys are essentially 154 public keys, and decryption and signature keys are essentially 155 private keys. The fact that they are logically distinct does 156 not preclude the assignment of bitwise identical keys. 158 3.2. Standard Public Key Authentication 160 Implementation of the changes in this section is REQUIRED for 161 compliance with pk-init. 163 It is assumed that all public keys are signed by some certification 164 authority (CA). The initial authentication request is sent as per 165 RFC 1510, except that a preauthentication field containing data 166 signed by the user's signature key accompanies the request: 168 PA-PK-AS-REQ ::- SEQUENCE { 169 -- PA TYPE 17 170 signedPKAuth [0] SignedPKAuthenticator, 171 userCert [1] SEQUENCE OF Certificate OPTIONAL, 172 -- the user's certificate 173 -- optionally followed by that 174 -- certificate's certifier chain 175 trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL 176 -- CAs that the client trusts 177 } 179 SignedPKAuthenticator ::= SEQUENCE { 180 pkAuth [0] PKAuthenticator, 181 pkAuthSig [1] Signature, 182 -- of pkAuth 183 -- using user's signature key 184 } 186 PKAuthenticator ::= SEQUENCE { 187 cusec [0] INTEGER, 188 -- for replay prevention 189 ctime [1] KerberosTime, 190 -- for replay prevention 191 nonce [2] INTEGER, 192 -- binds response to this request 193 kdcName [3] PrincipalName, 194 clientPubValue [4] SubjectPublicKeyInfo OPTIONAL, 195 -- for Diffie-Hellman algorithm 196 } 198 Signature ::= SEQUENCE { 199 signedHash [0] EncryptedData 200 -- of type Checksum 201 -- encrypted under signature key 202 } 204 Checksum ::= SEQUENCE { 205 cksumtype [0] INTEGER, 206 checksum [1] OCTET STRING 207 } -- as specified by RFC 1510 209 SubjectPublicKeyInfo ::= SEQUENCE { 210 algorithm [0] algorithmIdentifier, 211 subjectPublicKey [1] BIT STRING 212 } -- as specified by the X.509 recommendation [9] 214 Certificate ::= SEQUENCE { 215 CertType [0] INTEGER, 216 -- type of certificate 217 -- 1 = X.509v3 (DER encoding) 218 -- 2 = PGP (per PGP draft) 219 CertData [1] OCTET STRING 220 -- actual certificate 221 -- type determined by CertType 222 } 224 Note: If the signature uses RSA keys, then it is to be performed 225 as per PKCS #1. 227 The PKAuthenticator carries information to foil replay attacks, 228 to bind the request and response, and to optionally pass the 229 client's Diffie-Hellman public value (i.e. for using DSA in 230 combination with Diffie-Hellman). The PKAuthenticator is signed 231 with the private key corresponding to the public key in the 232 certificate found in userCert (or cached by the KDC). 234 In the PKAuthenticator, the client may specify the KDC name in one 235 of two ways: 1) a Kerberos principal name, or 2) the name in the 236 KDC's certificate (e.g., an X.500 name, or a PGP name). Note that 237 case #1 requires that the certificate name and the Kerberos principal 238 name be bound together (e.g., via an X.509v3 extension). 240 The userCert field is a sequence of certificates, the first of which 241 must be the user's public key certificate. Any subsequent 242 certificates will be certificates of the certifiers of the user's 243 certificate. These cerificates may be used by the KDC to verify the 244 user's public key. This field is empty if the KDC already has the 245 user's certifcate. 247 The trustedCertifiers field contains a list of certification 248 authorities trusted by the client, in the case that the client does 249 not possess the KDC's public key certificate. 251 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 252 type, the KDC attempts to verify the user's certificate chain 253 (userCert), if one is provided in the request. This is done by 254 verifying the certification path against the KDC's policy of 255 legitimate certifiers. This may be based on a certification 256 hierarchy, or it may be simply a list of recognized certifiers in a 257 system like PGP. If the certification path does not match one of 258 the KDC's trusted certifiers, the KDC sends back an error message of 259 type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data 260 field a list of its own trusted certifiers, upon which the client 261 resends the request. 263 If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC 264 verifies that it has a certificate issued by one of the certifiers 265 trusted by the client. If it does not have a suitable certificate, 266 the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED 267 to the client. 269 If a trust relationship exists, the KDC then verifies the client's 270 signature on PKAuthenticator. If that fails, the KDC returns an 271 error message of type KDC_ERROR_INVALID_SIG. Otherwise, the KDC 272 uses the timestamp in the PKAuthenticator to assure that the request 273 is not a replay. The KDC also verifies that its name is specified 274 in PKAuthenticator. 276 Assuming no errors, the KDC replies as per RFC 1510, except that it 277 encrypts the reply not with the user's key, but with a random key 278 generated only for this particular response. This random key 279 is sealed in the preauthentication field: 281 PA-PK-AS-REP ::= SEQUENCE { 282 -- PA TYPE 18 283 kdcCert [0] SEQUENCE OF Certificate OPTIONAL, 284 -- the KDC's certificate 285 -- optionally followed by that 286 -- certificate's certifier chain 287 encPaReply [1] EncryptedData, 288 -- of type PaReply 289 -- using either the client public 290 -- key or the Diffie-Hellman key 291 -- specified by SignedDHPublicValue 292 signedDHPublicValue [2] SignedDHPublicValue OPTIONAL 293 } 295 PaReply ::= SEQUENCE { 296 replyEncKeyPack [0] ReplyEncKeyPack, 297 replyEncKeyPackSig [1] Signature, 298 -- of replyEncKeyPack 299 -- using KDC's signature key 300 } 302 ReplyEncKeyPack ::= SEQUENCE { 303 replyEncKey [0] EncryptionKey, 304 -- used to encrypt main reply 305 nonce [1] INTEGER 306 -- binds response to the request 307 -- passed in the PKAuthenticator 308 } 310 SignedDHPublicValue ::= SEQUENCE { 311 dhPublicValue [0] SubjectPublicKeyInfo, 312 dhPublicValueSig [1] Signature 313 -- of dhPublicValue 314 -- using KDC's signature key 315 } 317 The kdcCert field is a sequence of certificates, the first of which 318 must have as its root certifier one of the certifiers sent to the 319 KDC in the PA-PK-AS-REQ. Any subsequent certificates will be 320 certificates of the certifiers of the KDC's certificate. These 321 cerificates may be used by the client to verify the KDC's public 322 key. This field is empty if the client did not send to the KDC a 323 list of trusted certifiers (the trustedCertifiers field was empty). 325 Since each certifier in the certification path of a user's 326 certificate is essentially a separate realm, the name of each 327 certifier shall be added to the transited field of the ticket. The 328 format of these realm names shall follow the naming constraints set 329 forth in RFC 1510 (sections 7.1 and 3.3.3.1). Note that this will 330 require new nametypes to be defined for PGP certifiers and other 331 types of realms as they arise. 333 The KDC's certificate must bind the public key to a name derivable 334 from the name of the realm for that KDC. The client then extracts 335 the random key used to encrypt the main reply. This random key (in 336 encPaReply) is encrypted with either the client's public key or 337 with a key derived from the DH values exchanged between the client 338 and the KDC. 340 3.3. Digital Signature 342 Implementation of the changes in this section are OPTIONAL for 343 compliance with pk-init. 345 We offer this option with the warning that it requires the client to 346 generate a random key; the client may not be able to guarantee the 347 same level of randomness as the KDC. 349 If the user registered a digital signature key with the KDC instead 350 of an encryption key, then a separate exchange must be used. The 351 client sends a request for a TGT as usual, except that it (rather 352 than the KDC) generates the random key that will be used to encrypt 353 the KDC response. This key is sent to the KDC along with the 354 request in a preauthentication field: 356 PA-PK-AS-SIGN ::= SEQUENCE { 357 -- PA TYPE 19 358 encSignedKeyPack [0] EncryptedData 359 -- of SignedKeyPack 360 -- using the KDC's public key 361 } 363 SignedKeyPack ::= SEQUENCE { 364 signedKey [0] KeyPack, 365 signedKeyAuth [1] PKAuthenticator, 366 signedKeySig [2] Signature 367 -- of signedKey.signedKeyAuth 368 -- using user's signature key 369 } 371 KeyPack ::= SEQUENCE { 372 randomKey [0] EncryptionKey, 373 -- will be used to encrypt reply 374 nonce [1] INTEGER 375 } 377 where the nonce is copied from the request. 379 Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies 380 the randomKey. It then replies as per RFC 1510, except that the 381 reply is encrypted not with a password-derived user key, but with 382 the randomKey sent in the request. Since the client already knows 383 this key, there is no need to accompany the reply with an extra 384 preauthentication field. The transited field of the ticket should 385 specify the certification path as described in Section 3.2. 387 3.4. Retrieving the Private Key From the KDC 389 Implementation of the changes in this section is RECOMMENDED for 390 compliance with pk-init. 392 When the user's private key is not stored local to the user, he may 393 choose to store the private key (normally encrypted using a 394 password-derived key) on the KDC. We provide this option to present 395 the user with an alternative to storing the private key on local 396 disk at each machine where he expects to authenticate himself using 397 pk-init. It should be noted that it replaces the added risk of 398 long-term storage of the private key on possibly many workstations 399 with the added risk of storing the private key on the KDC in a 400 form vulnerable to brute-force attack. 402 In order to obtain a private key, the client includes a 403 preauthentication field with the AS-REQ message: 405 PA-PK-KEY-REQ ::= SEQUENCE { 406 -- PA TYPE 20 407 patimestamp [0] KerberosTime OPTIONAL, 408 -- used to address replay attacks. 409 pausec [1] INTEGER OPTIONAL, 410 -- used to address replay attacks. 411 nonce [2] INTEGER, 412 -- binds the reply to this request 413 privkeyID [3] SEQUENCE OF KeyID OPTIONAL 414 -- constructed as a hash of 415 -- public key corresponding to 416 -- desired private key 417 } 419 KeyID ::= SEQUENCE { 420 KeyIdentifier [0] OCTET STRING 421 } 423 The client may request a specific private key by sending the 424 corresponding ID. If this field is left empty, then all 425 private keys are returned. 427 If all checks out, the KDC responds as described in the above 428 sections, except that an additional preauthentication field, 429 containing the user's private key, accompanies the reply: 431 PA-PK-KEY-REP ::= SEQUENCE { 432 -- PA TYPE 21 433 nonce [0] INTEGER, 434 -- binds the reply to the request 435 KeyData [1] SEQUENCE OF KeyPair 436 } 438 KeyPair ::= SEQUENCE { 439 privKeyID [0] OCTET STRING, 440 -- corresponding to encPrivKey 441 encPrivKey [1] OCTET STRING 442 } 444 3.4.1. Additional Protection of Retrieved Private Keys 446 We solicit discussion on the following proposal: that the client may 447 optionally include in its request additional data to encrypt the 448 private key, which is currently only protected by the user's 449 password. One possibility is that the client might generate a 450 random string of bits, encrypt it with the public key of the KDC (as 451 in the SignedKeyPack, but with an ordinary OCTET STRING in place of 452 an EncryptionKey), and include this with the request. The KDC then 453 XORs each returned key with this random bit string. (If the bit 454 string is too short, the KDC could either return an error, or XOR 455 the returned key with a repetition of the bit string.) 457 In order to make this work, additional means of preauthentication 458 need to be devised in order to prevent attackers from simply 459 inserting their own bit string. One way to do this is to store 460 a hash of the password-derived key (the one used to encrypt the 461 private key). This hash is then used in turn to derive a second 462 key (called the hash-key); the hash-key is used to encrypt an ASN.1 463 structure containing the generated bit string and a nonce value 464 that binds it to the request. 466 Since the KDC possesses the hash, it can generate the hash-key and 467 verify this (weaker) preauthentication, and yet cannot reproduce 468 the private key itself, since the hash is a one-way function. 470 4. Logistics and Policy Issues 472 We solicit discussion on how clients and KDCs should be configured 473 in order to determine which of the options described above (if any) 474 should be used. One possibility is to set the user's database 475 record to indicate that authentication is to use public key 476 cryptography; this will not work, however, in the event that the 477 client needs to know before making the initial request. 479 5. Compatibility with One-Time Passcodes 481 We solicit discussion on how the protocol changes proposed in this 482 draft will interact with the proposed use of one-time passcodes 483 discussed in draft-ietf-cat-kerberos-passwords-00.txt. 485 6. Strength of Cryptographic Schemes 487 In light of recent findings on the strength of MD5 and DES, 488 we solicit discussion on which encryption types to incorporate 489 into the protocol changes. 491 7. Bibliography 493 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 494 Service (V5). Request for Comments: 1510 496 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 497 for Computer Networks, IEEE Communications, 32(9):33-38. 498 September 1994. 500 [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to 501 Transport Layer Security (TLS). 502 draft-ietf-tls-kerb-cipher-suites-00.txt 504 [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 505 Tickets for Application Servers (PKTAPP). 506 draft-ietf-cat-pktapp-00.txt 508 [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using 509 Public Key Cryptography. Symposium On Network and Distributed System 510 Security, 1997. 512 [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 513 Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce, 514 July 1995. 516 [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. 517 The SSL Protocol, Version 3.0 - IETF Draft. 519 [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 520 Distributed Systems. In Proceedings of the 13th International 521 Conference on Distributed Computing Systems, May 1993 523 [9] ITU-T (formerly CCITT) 524 Information technology - Open Systems Interconnection - 525 The Directory: Authentication Framework Recommendation X.509 526 ISO/IEC 9594-8 528 8. Acknowledgements 530 Some of the ideas on which this proposal is based arose during 531 discussions over several years between members of the SAAG, the IETF 532 CAT working group, and the PSRG, regarding integration of Kerberos 533 and SPX. Some ideas have also been drawn from the DASS system. 534 These changes are by no means endorsed by these groups. This is an 535 attempt to revive some of the goals of those groups, and this 536 proposal approaches those goals primarily from the Kerberos 537 perspective. Lastly, comments from groups working on similar ideas 538 in DCE have been invaluable. 540 9. Expiration Date 542 This draft expires September 30, 1997. 544 10. Authors 546 Clifford Neuman 547 Brian Tung 548 USC Information Sciences Institute 549 4676 Admiralty Way Suite 1001 550 Marina del Rey CA 90292-6695 551 Phone: +1 310 822 1511 552 E-mail: {bcn, brian}@isi.edu 554 John Wray 555 Digital Equipment Corporation 556 550 King Street, LKG2-2/Z7 557 Littleton, MA 01460 558 Phone: +1 508 486 5210 559 E-mail: wray@tuxedo.enet.dec.com 561 Ari Medvinsky 562 Matthew Hur 563 CyberSafe Corporation 564 1605 NW Sammamish Road Suite 310 565 Issaquah WA 98027-5378 566 Phone: +1 206 391 6000 567 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com 569 Jonathan Trostle 570 Novell 571 E-mail: jonathan.trostle@novell.com