1INTERNET-DRAFT Clifford Neuman 2draft-ietf-cat-kerberos-pk-init-01.txt Brian Tung 3Updates: RFC 1510 ISI 4expires December 7, 1996 John Wray 5 Digital Equipment Corporation 6 7 8 Public Key Cryptography for Initial Authentication in Kerberos 9 10 110. Status Of this Memo 12 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 17 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other docu- 20 ments at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as ``work in pro- 22 gress.'' 23 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- 26 dow Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). 29 30 The distribution of this memo is unlimited. It is filed as 31 draft-ietf-cat-kerberos-pk-init-01.txt, and expires December 7, 1996. 32 Please send comments to the authors. 33 34 351. Abstract 36 37 This document defines extensions to the Kerberos protocol specifi- 38 cation (RFC 1510, "The Kerberos Network Authentication Service 39 (V5)", September 1993) to provide a method for using public key 40 cryptography during initial authentication. The method defined 41 specifies the way in which preauthentication data fields and error 42 data fields in Kerberos messages are to be used to transport public 43 key data. 44 452. Motivation 46 47 Public key cryptography presents a means by which a principal may 48 demonstrate possession of a key, without ever having divulged this 49 key to anyone else. In conventional cryptography, the encryption key 50 and decryption key are either identical or can easily be derived from 51 one another. In public key cryptography, however, neither the public 52 key nor the private key can be derived from the other (although the 53 private key RECORD may include the information required to generate 54 BOTH keys). Hence, a message encrypted with a public key is private, 55 since only the person possessing the private key can decrypt it; 56 similarly, someone possessing the private key can also encrypt a 57 message, thus providing a digital signature. 58 59 Furthermore, conventional keys are often derived from passwords, so 60 messages encrypted with these keys are susceptible to dictionary 61 attacks, whereas public key pairs are generated from a pseudo-random 62 number sequence. While it is true that messages encrypted using 63 public key cryptography are actually encrypted with a conventional 64 secret key, which is in turn encrypted using the public key pair, 65 the secret key is also randomly generated and is hence not vulnerable 66 to a dictionary attack. 67 68 The advantages provided by public key cryptography have produced a 69 demand for its integration into the Kerberos authentication protocol. 70 The primary advantage of registering public keys with the KDC lies in 71 the ease of recovery in case the KDC is compromised. With Kerberos as 72 it currently stands, compromise of the KDC is disastrous. All 73 keys become known by the attacker and all keys must be changed. 74 75 If users register public keys, compromise of the KDC does not divulge 76 their private key. Compromise of security on the KDC is still a 77 problem, since an attacker can impersonate any user by certifying a 78 bogus key with the KDC's private key. However, all bogus 79 certificates can be invalidated by revoking and changing the 80 KDC's public key. Legitimate users have to re-certify their public 81 keys with the new KDC key, but the users's keys themselves do not 82 need to be changed. Keys for application servers are conventional 83 symmetric keys and must be changed. 84 85 Note: If a user stores his private key, in an encrypted form, on the 86 KDC, then he does have to change the key pair, since the private key 87 is encrypted using a symmetric key derived from a password (as 88 described below), and is therefore vulnerable to dictionary attack. 89 Assuming good password policy, however, legitimate users may be 90 allowed to use the old password for a limited time, solely for the 91 purpose of changing the key pair. The realm administrator is then 92 not forced to re-key all users. 93 94 There are two important areas where public key cryptography will have 95 immediate use: in the initial authentication of users registered with 96 the KDC or using public key certificates from outside authorities, 97 and to establish inter-realm keys for cross-realm authentication. 98 This memo describes a method by which the first of these can be done. 99 The second case will be the topic for a separate proposal. 100 101 Some of the ideas on which this proposal is based arose during 102 discussions over several years between members of the SAAG, the 103 IETF-CAT working group, and the PSRG, regarding integration of 104 Kerberos and SPX. Some ideas are drawn from the DASS system, and 105 similar extensions have been discussed for use in DCE. These changes 106 are by no means endorsed by these groups. This is an attempt to 107 revive some of the goals of that group, and the proposal approaches 108 those goals primarily from the Kerberos perspective. 109 110 1113. Initial authentication of users with public keys 112 113 This section describes the extensions to Version 5 of the Kerberos 114 protocol that will support the use of public key cryptography by 115 users in the initial request for a ticket granting ticket. This 116 proposal is based on the implementation already made available; 117 nevertheless, we solicit any comments on modifications or additions 118 to the protocol description below. 119 120 Roughly speaking, the following changes to RFC 1510 are proposed: 121 a. The KDC's response is encrypted using a random nonce key, 122 rather than the user's secret key. 123 b. This random key accompanies the response in a 124 preauthentication field, encrypted and signed using the 125 public key pairs of the user and the KDC. 126 Certificate and message formats are also defined in this section. 127 128 This proposal will allow users either to use keys registered directly 129 with the KDC, or to use keys already registered for use with X.509, 130 PEM, or PGP, to obtain Kerberos credentials. These credentials can 131 then be used, as before, with application servers supporting Kerberos. 132 Use of public key cryptography will not be a requirement for Kerberos, 133 but if one's organization runs a KDC supporting public key, then users 134 may choose to be registered with a public key pair, instead of the 135 current secret key. 136 137 The application request and response between Kerberos clients and 138 application servers will continue to be based on conventional 139 cryptography, or will be converted to use user-to-user 140 authentication. There are performance issues and other reasons 141 that servers may be better off using conventional cryptography. 142 For this proposal, we feel that 80 percent of the benefits of 143 integrating public key with Kerberos can be attained for 20 percent 144 of the effort, by addressing only initial authentication. This 145 proposal does not preclude separate extensions. 146 147 With these changes, users will be able to register public keys, only 148 in realms that support public key, and they will then only be able 149 to perform initial authentication from a client that supports public key, 150 although they will be able to use services registered in any realm. 151 Furthermore, users registered with conventional keys will be able 152 to use any client. 153 154 This proposal addresses three ways in which users may use public key 155 cryptography for initial authentication with Kerberos, with minimal 156 change to the existing protocol. Users may register keys directly 157 with the KDC, or they may present certificates by outside certification 158 authorities (or certifications by other users) attesting to the 159 association of the public key with the named user. In both cases, 160 the end result is that the user obtains a conventional ticket 161 granting ticket or conventional server ticket that may be used for 162 subsequent authentication, with such subsequent authentication using 163 only conventional cryptography. 164 165 Additionally, users may also register a digital signature key with 166 the KDC. We provide this option for the licensing benefits, as well 167 as a simpler variant of the initial authentication exchange. However, 168 this option relies on the client to generate random keys. 169 170 We first consider the case where the user's key is registered with 171 the KDC. 172 173 1743.1 Definitions 175 176 Before we proceed, we will lay some groundwork definitions for 177 encryption and signatures. We propose the following definitions 178 of signature and encryption modes (and their corresponding values 179 on the wire): 180 181 #define ENCTYPE_SIGN_MD5_RSA 0x0011 182 183 #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021 184 #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022 185 186 allowing further modes to be defined accordingly. 187 188 In the exposition below, we will use the notation E (T, K) to denote 189 the encryption of data T, with key (or parameters) K. 190 191 If E is ENCTYPE_SIGN_MD5_RSA, then 192 193 E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)} 194 195 If E is ENCTYPE_ENCRYPT_RSA_PRIV, then 196 197 E (T, K) = RSAEncryptPrivate (T, K) 198 199 Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then 200 201 E (T, K) = RSAEncryptPublic (T, K) 202 203 2043.2 Initial request for user registered with public key on KDC 205 206 In this scenario it is assumed that the user is registered with a 207 public key on the KDC. The user's private key may be held by the 208 user, or it may be stored on the KDC, encrypted so that it cannot be 209 used by the KDC. 210 2113.2.1 User's private key is stored locally 212 213 If the user stores his private key locally, the initial request to 214 the KDC for a ticket granting ticket proceeds according to RFC 1510, 215 except that a preauthentication field containing a nonce signed by 216 the user's private key is included. The preauthentication field 217 may also include a list of the root certifiers trusted by the user. 218 219 PA-PK-AS-ROOT ::= SEQUENCE { 220 rootCert[0] SEQUENCE OF OCTET STRING, 221 signedAuth[1] SignedPKAuthenticator 222 } 223 224 SignedPKAuthenticator ::= SEQUENCE { 225 authent[0] PKAuthenticator, 226 authentSig[1] Signature 227 } 228 229 PKAuthenticator ::= SEQUENCE { 230 cksum[0] Checksum OPTIONAL, 231 cusec[1] INTEGER, 232 ctime[2] KerberosTime, 233 nonce[3] INTEGER, 234 kdcRealm[4] Realm, 235 kdcName[5] PrincipalName 236 } 237 238 Signature ::= SEQUENCE { 239 sigType[0] INTEGER, 240 kvno[1] INTEGER OPTIONAL, 241 sigHash[2] OCTET STRING 242 } 243 244 Notationally, sigHash is then 245 246 sigType (authent, userPrivateKey) 247 248 where userPrivateKey is the user's private key (corresponding to the 249 public key held in the user's database record). Valid sigTypes are 250 thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect 251 that other types may be listed (and given on-the-wire values between 252 0x0011 and 0x001f). 253 254 The format of each certificate depends on the particular 255 service used. (Alternatively, the KDC could send, with its reply, 256 a sequence of certifications (see below), but since the KDC is likely 257 to have more certifications than users have trusted root certifiers, 258 we have chosen the first method.) In the event that the client 259 believes it already possesses the current public key of the KDC, 260 a zero-length root-cert field is sent. 261 262 The fields in the signed authenticator are the same as those 263 in the Kerberos authenticator; in addition, we include a client- 264 generated nonce, and the name of the KDC. The structure is itself 265 signed using the user's private key corresponding to the public key 266 registered with the KDC. 267 268 Typically, preauthentication using a secret key would not be included, 269 but if included it may be ignored by the KDC. (We recommend that it 270 not be included: even if the KDC should ignore the preauthentication, 271 an attacker may not, and use an intercepted message to guess the 272 password off-line.) 273 274 The response from the KDC would be identical to the response in RFC 1510, 275 except that instead of being encrypted in the secret key shared by the 276 client and the KDC, it is encrypted in a random key freshly generated 277 by the KDC (of type ENCTYPE_ENC_CBC_CRC). A preauthentication field 278 (specified below) accompanies the response, optionally containing a 279 certificate with the public key for the KDC (since we do not assume 280 that the client knows this public key), and a package containing the 281 secret key in which the rest of the response is encrypted, along with 282 the same nonce used in the rest of the response, in order to prevent 283 replays. This package is itself encrypted with the private key of the 284 KDC, then encrypted with the public key of the user. 285 286 PA-PK-AS-REP ::= SEQUENCE { 287 kdcCert[0] SEQUENCE OF Certificate, 288 encryptShell[1] EncryptedData, -- EncPaPkAsRepPartShell 289 -- encrypted by encReplyTmpKey 290 encryptKey[2] EncryptedData -- EncPaPkAsRepTmpKey 291 -- encrypted by userPubliKey 292 } 293 294 EncPaPkAsRepPartShell ::= SEQUENCE { 295 encReplyPart[0] EncPaPkAsRepPart, 296 encReplyPartSig[1] Signature -- encReplyPart 297 -- signed by kdcPrivateKey 298 } 299 300 EncPaPkAsRepPart ::= SEQUENCE { 301 encReplyKey[0] EncryptionKey, 302 nonce[1] INTEGER 303 } 304 305 EncPaPkAsRepTmpKey ::= SEQUENCE { 306 encReplyTmpKey[0] EncryptionKey 307 } 308 309 Notationally, assume that encryptPack is encrypted (or signed) with 310 algorithm Ak, and that encryptShell is encrypted with algorithm Au. 311 Then, encryptShell is 312 313 Au (Ak ({encReplyKey, nonce}, kdcPrivateKey), userPublicKey) 314 315 where kdcPrivateKey is the KDC's private key, and userPublicKey is the 316 user's public key. 317 318 The kdc-cert specification is lifted, with slight modifications, 319 from v3 of the X.509 certificate specification: 320 321 Certificate ::= SEQUENCE { 322 version[0] Version DEFAULT v1 (1), 323 serialNumber[1] CertificateSerialNumber, 324 signature[2] AlgorithmIdentifier, 325 issuer[3] PrincipalName, 326 validity[4] Validity, 327 subjectRealm[5] Realm, 328 subject[6] PrincipalName, 329 subjectPublicKeyInfo[7] SubjectPublicKeyInfo, 330 issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL, 331 subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL, 332 authentSig[10] Signature 333 } 334 335 The kdc-cert must have as its root certification one of the certifiers 336 sent to the KDC with the original request. If the KDC has no such 337 certification, then it will instead reply with a KRB_ERROR of type 338 KDC_ERROR_PREAUTH_FAILED. If a zero-length root-cert was sent by the 339 client as part of the PA-PK-AS-ROOT, then a correspondingly zero-length 340 kdc-cert may be absent, in which case the client uses its copy of the 341 KDC's public key. 342 343 Upon receipt of the response from the KDC, the client will verify the 344 public key for the KDC from PA-PK-AS-REP preauthentication data field, 345 The certificate must certify the key as belonging to a principal whose 346 name can be derived from the realm name. If the certificate checks 347 out, the client then decrypts the EncPaPkAsRepPart using the private 348 key of the user, and verifies the signature of the KDC. It then uses 349 the random key contained therein to decrypt the rest of the response, 350 and continues as per RFC 1510. Because there is direct trust between 351 the user and the KDC, the transited field of the ticket returned by 352 the KDC should remain empty. (Cf. Section 3.3.) 353 354 3553.2.2. Private key held by KDC 356 357 Implementation of the changes in this section is OPTIONAL. 358 359 When the user's private key is not carried with the user, the user may 360 encrypt the private key using conventional cryptography, and register 361 the encrypted private key with the KDC. The MD5 hash of the DES key 362 used to encrypt the private key must also be registered with the KDC. 363 364 We provide this option with the warning that storing the private key 365 on the KDC carries the risk of exposure in case the KDC is compromised. 366 If a suffiently good password is chosen to encrypt the key, then this 367 password can be used for a limited time to change the private key. 368 If the user wishes to authenticate himself without storing the private 369 key on each local disk, then a safer, albeit possibly less practical, 370 alternative is to use a smart card to store the keys. 371 372 When the user's private key is stored on the KDC, the KDC record 373 will also indicate whether preauthentication is required before 374 returning the key (we recommend that it be required). If such 375 preauthentication is required, when the initial request is received, 376 the KDC will respond with a KRB_ERROR message, with msg-type set 377 to KDC_ERR_PREAUTH_REQUIRED, and e-data set to: 378 379 PA-PK-AS-INFO ::= SEQUENCE { 380 kdcCert[0] SEQUENCE OF Certificate 381 } 382 383 The kdc-cert field is identical to that in the PA-PK-AS-REP 384 preauthentication data field returned with the KDC response, and must 385 be validated as belonging to the KDC in the same manner. 386 387 Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the 388 client will prompt the user for the password that was used to 389 encrypt the private key, derive the DES key from that password, 390 and calculate the MD5 hash H1 of the DES key. The client then sends 391 a request to the KDC, which includes a timestamp and a 392 client-generated random secret key that will be used by the KDC 393 to super-encrypt the encrypted private key before it is returned 394 to the client. This information is sent to the KDC in a subsequent 395 AS_REQ message in a preauthentication data field: 396 397 PA-PK-AS-REQ ::= SEQUENCE { 398 encHashShell[0] EncryptedData -- EncPaPkAsReqShell 399 } 400 401 EncPaPkAsReqShell ::= SEQUENCE { 402 encHashPart[0] EncryptedData -- EncPaPkAsReqPart 403 } 404 405 EncPaPkAsReqPart ::= SEQUENCE { 406 encHashKey[0] EncryptionKey, 407 nonce[1] INTEGER 408 } 409 410 The EncPaPkAsReqPart is first encrypted with a DES key K1, derived 411 by string_to_key from the hash H1 (with null salt), then encrypted 412 again with the KDC's public key from the certificate in the 413 PA-PK-AS-INFO field of the error response. 414 415 Notationally, if encryption algorithm A is used for DES encryption, 416 and Ak is used for the public key encryption, then enc-shell is 417 418 Ak (A ({encHashKey, nonce}, K1), kdcPublicKey) 419 420 Upon receipt of the authentication request with the PA-PK-AS-REQ, the 421 KDC verifies the hash of the user's DES encryption key by attempting 422 to decrypt the EncPaPkAsReqPart of the PA-PK-AS-REQ. If decryption 423 is successful, the KDC generates the AS response as defined in 424 RFC 1510, but additionally includes a preauthentication field of type 425 PA-PK-USER-KEY. (This response will also be included in response to 426 the initial request without preauthentication if preauthentication is 427 not required for the user and the user's encrypted private key is 428 stored on the KDC.) 429 430 PA-PK-USER-KEY ::= SEQUENCE { 431 encUserKeyPart[0] EncryptedData -- EncPaPkUserKeyPart 432 } 433 434 EncPaPkUserKeyPart ::= SEQUENCE { 435 encUserKey[0] OCTET STRING, 436 nonce[1] INTEGER 437 } 438 439 Notationally, if encryption algorithm A is used, then enc-key-part is 440 441 A ({encUserKey, nonce}, enc-hash-key) 442 443 (where A could be null encryption). 444 445 This message contains the encrypted private key that has been 446 registered with the KDC by the user, as encrypted by the user, 447 optionally super-encrypted with the enc-hash-key from the PA-PK-AS-REQ 448 message if preauthentication using that method was provided (otherwise, 449 the EncryptedData should denote null encryption). Note that since 450 H1 is a one-way hash, it is not possible for one to decrypt the 451 message if one possesses H1 but not the DES key that H1 is derived 452 from. Because there is direct trust between the user and the 453 KDC, the transited field of the ticket returned by the KDC should 454 remain empty. (Cf. Section 3.3.) 455 456 4573.3. Clients with a public key certified by an outside authority 458 459 Implementation of the changes in this section is OPTIONAL. 460 461 In the case where the client is not registered with the current KDC, 462 the client is responsible for obtaining the private key on its own. 463 The client will request initial tickets from the KDC using the TGS 464 exchange, but instead of performing pre-authentication using a 465 Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used 466 when the public key is known to the KDC, the client performs 467 preauthentication using the preauthentication data field of type 468 PA-PK-AS-EXT-CERT: 469 470 PA-PK-AS-EXT-CERT ::= SEQUENCE { 471 userCert[0] SEQUENCE OF OCTET STRING, 472 signedAuth[1] SignedPKAuthenticator 473 } 474 475 where the user-cert specification depends on the type of certificate 476 that the user possesses. In cases where the service has separate 477 key pairs for digital signature and for encryption, we recommend 478 that the signature keys be used for the purposes of sending the 479 preauthentication (and deciphering the response). 480 481 The authenticator is the one used from the exchange in section 3.2.1, 482 except that it is signed using the private key corresponding to 483 the public key in the user-cert. 484 485 The KDC will verify the preauthentication authenticator, and check the 486 certification path against its own policy of legitimate certifiers. 487 This may be based on a certification hierarchy, or simply a list of 488 recognized certifiers in a system like PGP. 489 490 If all checks out, the KDC will issue Kerberos credentials, as in 3.2, 491 but with the names of all the certifiers in the certification path 492 added to the transited field of the ticket, with a principal name 493 taken from the certificate (this might be a long path for X.509, or a 494 string like "John Q. Public <jqpublic@company.com>" if the certificate 495 was a PGP certificate. The realm will identify the kind of 496 certificate and the final certifier as follows: 497 498 cert_type/final_certifier 499 500 as in PGP/<endorser@company.com>. 501 502 5033.4. Digital Signature 504 505 Implementation of the changes in this section is OPTIONAL. 506 507 We offer this option with the warning that it requires the client 508 process to generate a random DES key; this generation may not 509 be able to guarantee the same level of randomness as the KDC. 510 511 If a user registered a digital signature key pair with the KDC, 512 a separate exchange may be used. The client sends a KRB_AS_REQ as 513 described in section 3.2.2. If the user's database record 514 indicates that a digital signature key is to be used, then the 515 KDC sends back a KRB_ERROR as in section 3.2.2. 516 517 It is assumed here that the signature key is stored on local disk. 518 The client generates a random key of enctype ENCTYPE_DES_CBC_CRC, 519 signs it using the signature key (otherwise the signature is 520 performed as described in section 3.2.1), then encrypts the whole with 521 the public key of the KDC. This is returned with a separate KRB_AS_REQ 522 in a preauthentication of type 523 524 PA-PK-AS-SIGNED ::= SEQUENCE { 525 signedKey[0] EncryptedData -- PaPkAsSignedData 526 } 527 528 PaPkAsSignedData ::= SEQUENCE { 529 signedKeyPart[0] SignedKeyPart, 530 signedKeyAuth[1] PKAuthenticator 531 } 532 533 SignedKeyPart ::= SEQUENCE { 534 encSignedKey[0] EncryptionKey, 535 nonce[1] INTEGER 536 } 537 538 where the nonce is the one from the request. Upon receipt of the 539 request, the KDC decrypts, then verifies the random key. It then 540 replies as per RFC 1510, except that instead of being encrypted 541 with the password-derived DES key, the reply is encrypted using 542 the randomKey sent by the client. Since the client already knows 543 this key, there is no need to accompany the reply with an extra 544 preauthentication field. Because there is direct trust between 545 the user and the KDC, the transited field of the ticket returned 546 by the KDC should remain empty. (Cf. Section 3.3.) 547 548 5494. Preauthentication Data Types 550 551 We propose that the following preauthentication types be allocated 552 for the preauthentication data packages described in this draft: 553 554 #define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */ 555 #define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */ 556 #define KRB5_PADATA_PUBLIC_REQ 19 /* PA-PK-AS-REQ */ 557 #define KRB5_PADATA_PRIVATE_REP 20 /* PA-PK-USER-KEY */ 558 #define KRB5_PADATA_PUBLIC_EXT 21 /* PA-PK-AS-EXT-CERT */ 559 #define KRB5_PADATA_PUBLIC_SIGN 22 /* PA-PK-AS-SIGNED */ 560 561 5625. Encryption Information 563 564 For the public key cryptography used in direct registration, we used 565 (in our implementation) the RSAREF library supplied with the PGP 2.6.2 566 release. Encryption and decryption functions were implemented directly 567 on top of the primitives made available therein, rather than the 568 fully sealing operations in the API. 569 570 5716. Compatibility with One-Time Passcodes 572 573 We solicit discussion on how the use of public key cryptography for initial 574 authentication will interact with the proposed use of one time passwords 575 discussed in Internet Draft <draft-ietf-cat-kerberos-passwords-00.txt>. 576 577 5787. Strength of Encryption and Signature Mechanisms 579 580 In light of recent findings on the strengths of MD5 and various DES 581 modes, we solicit discussion on which modes to incorporate into the 582 protocol changes. 583 584 5858. Expiration 586 587 This Internet-Draft expires on December 7, 1996. 588 589 5909. Authors' Addresses 591 592 B. Clifford Neuman 593 USC/Information Sciences Institute 594 4676 Admiralty Way Suite 1001 595 Marina del Rey, CA 90292-6695 596 597 Phone: 310-822-1511 598 EMail: bcn@isi.edu 599 600 Brian Tung 601 USC/Information Sciences Institute 602 4676 Admiralty Way Suite 1001 603 Marina del Rey, CA 90292-6695 604 605 Phone: 310-822-1511 606 EMail: brian@isi.edu 607 608 John Wray 609 Digital Equipment Corporation 610 550 King Street, LKG2-2/Z7 611 Littleton, MA 01460 612 613 Phone: 508-486-5210 614 EMail: wray@tuxedo.enet.dec.com 615