idnits 2.17.1 draft-ietf-cat-kerberos-pk-cross-08.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 543 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 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([KERB]), 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 155: '... data-value[1] OCTET STRING OPTIONAL...' RFC 2119 keyword, line 287: '... that the AS-REQ MUST have the PKCROSS...' RFC 2119 keyword, line 304: '...r the XTKT_(l,r) MAY be of greater str...' RFC 2119 keyword, line 305: '...NIT reply, since the XTKT_(l,r) SHOULD...' RFC 2119 keyword, line 308: '..., the remote KDC SHOULD include policy...' (7 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 mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 331 has weird spacing: '...ta-type equa...' == Line 332 has weird spacing: '...a-value is AS...' == Line 385 has weird spacing: '...ta-type equa...' == Line 386 has weird spacing: '...a-value is AS...' == Line 395 has weird spacing: '... value inte...' (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. 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? 'KERB' on line 452 looks like a reference -- Missing reference section? 'KERBTLS' on line 448 looks like a reference -- Missing reference section? 'KERB94' on line 476 looks like a reference -- Missing reference section? 'TLS' on line 455 looks like a reference -- Missing reference section? 'PKINIT' on line 458 looks like a reference -- Missing reference section? 'PKTAPP' on line 463 looks like a reference -- Missing reference section? 'X509' on line 467 looks like a reference -- Missing reference section? 'NEUMAN' on line 471 looks like a reference -- Missing reference section? 'KERB-REV' on line 480 looks like a reference -- Missing reference section? '0' on line 154 looks like a reference -- Missing reference section? '1' on line 155 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Matthew Hur 2 draft-ietf-cat-kerberos-pk-cross-08.txt Cisco Systems 3 Updates: RFC 1510 Brian Tung 4 November 8, 2001 (Expires May 8, 2001) Tatyana Ryutov 5 Clifford Neuman 6 ISI 7 Ari Medvinsky 8 Liberate 9 Gene Tsudik 10 UC Irvine 11 Bill Sommerfeld 12 Sun Microsystems 14 Public Key Cryptography for Cross-Realm Authentication in Kerberos 16 0. Status Of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), 21 its areas, and its working groups. Note that other groups may 22 also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as ``work in 28 progress.'' 30 To learn the current status of any Internet-Draft, please check 31 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 32 Shadow Directories on ftp.ietf.org (US East Coast), 33 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 34 munnari.oz.au (Pacific Rim). 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 The distribution of this memo is unlimited. It is filed as 43 draft-ietf-cat-kerberos-pk-cross-07.txt, and expires May 15, 2001. 44 Please send comments to the authors. 46 1. Abstract 48 This document defines extensions to the Kerberos protocol 49 specification [KERB] to provide a method for using public key 50 cryptography to enable cross-realm authentication. The methods 51 defined here specify the way in which message exchanges are to be 52 used to transport cross-realm secret keys protected by encryption 53 under public keys certified as belonging to KDCs. 55 2. Introduction 57 Symmetric and asymmetric key systems may co-exist within hybrid 58 architectures in order to leverage the advantages and mitigiate 59 issues within the respective systems. An example of a hybrid 60 solution that may employ both symmetric and asymmetric technologies 61 is Kerberos ciphersuires in TLS [KERBTLS] which utilizes the 62 Kerberos protocol [KERB] [KERB94] in conjunction with TLS [TLS] 63 which has commonly been thought of as a public key protocol. 65 The Kerberos can leverage the advantages provided by public key 66 cryptography. PKINIT [PKINIT] describes the use of public key 67 cryptography in the initial authentication exchange in Kerberos. 68 PKTAPP [PKTAPP] describes how an application service can essentially 69 issue a kerberos ticket to itself after utilizing public key 70 cryptography for authentication. This specification describes the 71 use of public key crpytography in cross-realm authentication. 73 Without the use of public key cryptography, administrators must 74 maintain separate keys for every realm which wishes to exchange 75 authentication information with another realm (which implies n(n-1) 76 keys), or they must utilize a hierachichal arrangement of realms, 77 which may increase network traffic and complicate the trust model by 78 requiring evaluation of transited realms. 80 Even with the multi-hop cross-realm authentication, there must be 81 some way to locate the path by which separate realms are to be 82 transited. The current method, which makes use of the DNS-like 83 realm names typical to Kerberos, requires trust of the intermediate 84 KDCs. 86 PKCROSS utilizes a public key infrastructure (PKI) [X509] to 87 simplify the administrative burden of maintaining cross-realm keys. 88 Such usage leverages a PKI for a non-centrally-administratable 89 environment (namely, inter-realm). Thus, a shared key for cross- 90 realm authentication can be established for a set period of time, 91 and a remote realm is able to issue policy information that is 92 returned to itself when a client requests cross-realm 93 authentication. Such policy information may be in the form of 94 restrictions [NEUMAN]. Furthermore, these methods are transparent 95 to the client; therefore, only the KDCs need to be modified to use 96 them. In this way, we take advantage of the the distributed trust 97 management capabilities of public key crypography while maintaining 98 the advantages of localized trust management provided by Kerberos. 100 Although this specification utilizes the protocol specfied in the 101 PKINIT specification, it is not necessary to implement client 102 changes in order to make use of the changes in this document. 104 3. Objectives 106 The objectives of this specification are as follows: 108 1. Simplify the administration required to establish Kerberos 109 cross-realm keys. 111 2. Avoid modification of clients and application servers. 113 3. Allow remote KDC to control its policy on cross-realm 114 keys shared between KDCs, and on cross-realm tickets 115 presented by clients. 117 4. Remove any need for KDCs to maintain state about keys 118 shared with other KDCs. 120 5. Leverage the work done for PKINIT to provide the public key 121 protocol for establishing symmetric cross realm keys. 123 4. Definitions 125 The following notation is used throughout this specification: 126 KDC_l ........... local KDC 127 KDC_r ........... remote KDC 128 XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the 129 local KDC 130 TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the 131 client for presentation to the remote KDC 133 This specification defines the following new types to be added to 134 the Kerberos specification: 135 PKCROSS kdc-options field in the AS_REQ is bit 9 136 TE-TYPE-PKCROSS-KDC 2 137 TE-TYPE-PKCROSS-CLIENT 3 139 This specification defines the following ASN.1 type for conveying 140 policy information: 141 CrossRealmTktData ::= SEQUENCE OF TypedData 143 This specification defines the following types for policy 144 information conveyed in CrossRealmTktData: 145 PLC_LIFETIME 1 146 PLC_SET_TKT_FLAGS 2 147 PLC_NOSET_TKT_FLAGS 3 149 TicketExtensions are defined per the Kerberos specification 150 [KERB-REV]: 151 TicketExtensions ::= SEQUENCE OF TypedData 152 Where 153 TypedData ::= SEQUENCE { 154 data-type[0] INTEGER, 155 data-value[1] OCTET STRING OPTIONAL 156 } 158 5. Protocol Specification 160 We assume that the client has already obtained a TGT. To perform 161 cross-realm authentication, the client does exactly what it does 162 with ordinary (i.e. non-public-key-enabled) Kerberos; the only 163 changes are in the KDC; although the ticket which the client 164 forwards to the remote realm may be changed. This is acceptable 165 since the client treats the ticket as opaque. 167 5.1. Overview of Protocol 169 The basic operation of the PKCROSS protocol is as follows: 171 1. The client submits a request to the local KDC for 172 credentials for the remote realm. This is just a typical 173 cross realm request that may occur with or without PKCROSS. 175 2. The local KDC submits a PKINIT request to the remote KDC to 176 obtain a "special" PKCROSS ticket. This is a standard 177 PKINIT request, except that PKCROSS flag (bit 9) is set in 178 the kdc-options field in the AS_REQ. Note that the service 179 name in the request is for pkcross/realm@REALM instead of 180 krbtgt/realm@REALM. 182 3. The remote KDC responds as per PKINIT, except that 183 the ticket contains a TicketExtension, which contains 184 policy information such as lifetime of cross realm tickets 185 issued by KDC_l to a client. The local KDC must reflect 186 this policy information in the credentials it forwards to 187 the client. Call this ticket XTKT_(l,r) to indicate that 188 this ticket is used to authenticate the local KDC to the 189 remote KDC. 191 4. The local KDC passes a ticket, TGT_(c,r) (the cross realm 192 TGT between the client and remote KDC), to the client. 193 This ticket contains in its TicketExtension field the 194 ticket, XTKT_(l,r), which contains the cross-realm key. 195 The TGT_(c,r) ticket is encrypted using the key sealed in 196 XTKT_(l,r). (The TicketExtension field is not encrypted.) 197 The local KDC may optionally include another TicketExtension 198 type that indicates the hostname and/or IP address for the 199 remote KDC. 201 5. The client submits the request directly to the remote 202 KDC, as before. 204 6. The remote KDC extracts XTKT_(l,r) from the TicketExtension 205 in order to decrypt the encrypted part of TGT_(c,r). 207 -------------------------------------------------------------------- 209 Client Local KDC (KDC_l) Remote KDC (KDC_r) 210 ------ ----------------- ------------------ 211 Normal Kerberos 212 request for 213 cross-realm 214 ticket for KDC_r 215 ----------------------> 217 PKINIT request for 218 XTKT(l,r) - PKCROSS flag 219 set in the AS-REQ 220 * -------------------------> 222 PKINIT reply with 223 XTKT_(l,r) and 224 policy info in 225 ticket extension 226 <-------------------------- * 228 Normal Kerberos reply 229 with TGT_(c,r) and 230 XTKT(l,r) in ticket 231 extension 232 <--------------------------------- 234 Normal Kerberos 235 cross-realm TGS-REQ 236 for remote 237 application 238 service with 239 TGT_(c,r) and 240 XTKT(l,r) in ticket 241 extension 242 -------------------------------------------------> 244 Normal Kerberos 245 cross-realm 246 TGS-REP 247 <--------------------------------------------------------------- 249 * Note that the KDC to KDC messages occur only periodically, since 250 the local KDC caches the XTKT_(l,r). 251 -------------------------------------------------------------------- 253 Sections 5.2 through 5.4 describe in detail steps 2 through 4 254 above. Section 5.6 describes the conditions under which steps 255 2 and 3 may be skipped. 257 Note that the mechanism presented above requires infrequent KDC to 258 KDC communication (as dictated by policy - this is discussed 259 later). Without such an exchange, there are the following issues: 260 1) KDC_l would have to issue a ticket with the expectation that 261 KDC_r will accept it. 262 2) In the message that the client sends to KDC_r, KDC_l would have 263 to authenticate KDC_r with credentials that KDC_r trusts. 264 3) There is no way for KDC_r to convey policy information to KDC_l. 265 4) If, based on local policy, KDC_r does not accept a ticket from 266 KDC_l, then the client gets stuck in the middle. To address such 267 an issue would require modifications to standard client 268 processing behavior. 269 Therefore, the infreqeunt use of KDC to KDC communication assures 270 that inter-realm KDC keys may be established in accordance with local 271 policies and that clients may continue to operate without 272 modification. 274 5.2. Local KDC's Request to Remote KDC 276 When the local KDC receives a request for cross-realm 277 authentication, it first checks its ticket cache to see if it has a 278 valid PKCROSS ticket, XTKT_(l,r). If it has a valid XTKT_(l,r), 279 then it does not need to send a request to the remote KDC (see 280 section 5.5). 282 If the local KDC does not have a valid XTKT_(l,r), it sends a 283 request to the remote KDC (for pkcross/realm@REALM) in order to 284 establish a cross realm key and obtain the XTKT_(l,r). This request 285 is in fact a PKINIT request as described in the PKINIT specification; 286 i.e., it consists of an AS-REQ with a PA-PK-AS-REQ included as a 287 preauthentication field. Note, that the AS-REQ MUST have the PKCROSS 288 flag (bit 9) set in the kdc_options field of the AS-REQ. Otherwise, 289 this exchange exactly follows the description given in the PKINIT 290 specification. 292 5.3. Remote KDC's Response to Local KDC 294 When the remote KDC receives the PKINIT/PKCROSS request from the 295 local KDC, it sends back a PKINIT response as described in 296 the PKINIT specification with the following exception: the encrypted 297 part of the Kerberos ticket is not encrypted with the krbtgt key; 298 instead, it is encrypted with the ticket granting server's PKCROSS 299 key. This key, rather than the krbtgt key, is used because it 300 encrypts a ticket used for verifying a cross realm request rather 301 than for issuing an application service ticket. This is the reason 302 that the name pkcross/realm@REALM is used instead of 303 krbtgt/realm@REALM. Note that, as a matter of policy, the session 304 key for the XTKT_(l,r) MAY be of greater strength than that of a 305 session key for a normal PKINIT reply, since the XTKT_(l,r) SHOULD 306 be much longer lived than a normal application service ticket. 308 In addition, the remote KDC SHOULD include policy information in the 309 XTKT_(l,r). This policy information would then be reflected in the 310 cross-realm TGT, TGT_(c,r). Otherwise, the policy for TGT_(c,r) 311 would be dictated by KDC_l rather than by KDC_r. The local KDC MAY 312 enforce a more restrictive local policy when creating a cross-realm 313 ticket, TGT_(c,r). For example, KDC_r may dictate a lifetime 314 policy of eight hours, but KDC_l may create TKT_(c,r) with a 315 lifetime of four hours, as dictated by local policy. Also, the 316 remote KDC MAY include other information about itself along with the 317 PKCROSS ticket. These items are further discussed in section 6 318 below. 320 5.4. Local KDC's Response to Client 322 Upon receipt of the PKINIT/CROSS response from the remote KDC, 323 the local KDC formulates a response to the client. This reply 324 is constructed exactly as in the Kerberos specification, except 325 for the following: 327 A) The local KDC places XTKT_(l,r) in the TicketExtension field of 328 the client's cross-realm, ticket, TGT_(c,r), for the remote 329 realm. 330 Where 331 data-type equals 3 for TE-TYPE-PKCROSS-CLIENT 332 data-value is ASN.1 encoding of XTKT_(l,r) 334 B) The local KDC adds the name of its CA to the transited field of 335 TGT_(c,r). 337 5.5 Remote KDC's Processing of Client Request 339 When the remote KDC, KDC_r, receives a cross-realm ticket, 340 TGT_(c,r), and it detects that the ticket contains a ticket 341 extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt 342 the ticket, XTKT_(l,r), that is encoded in the ticket extension. 343 KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r). KDC_r 344 then uses the key obtained from XTKT_(l,r) in order to decrypt the 345 cross-realm ticket, TGT_(c,r). 347 KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in 348 compliance with any policy information contained in XTKT_(l,r) (see 349 section 6). If the TGT_(c,r) is not in compliance with policy, then 350 the KDC_r responds to the client with a KRB-ERROR message of type 351 KDC_ERR_POLICY. 353 5.6. Short-Circuiting the KDC-to-KDC Exchange 355 As we described earlier, the KDC to KDC exchange is required only 356 for establishing a symmetric, inter-realm key. Once this key is 357 established (via the PKINIT exchange), no KDC to KDC communication 358 is required until that key needs to be renewed. This section 359 describes the circumstances under which the KDC to KDC exchange 360 described in Sections 5.2 and 5.3 may be skipped. 362 The local KDC has a known lifetime for TGT_(c,r). This lifetime may 363 be determined by policy information included in XTKT_(l,r), and/or 364 it may be determined by local KDC policy. If the local KDC already 365 has a ticket XTKT(l,r), and the start time plus the lifetime for 366 TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then 367 the local KDC may skip the exchange with the remote KDC, and issue a 368 cross-realm ticket to the client as described in Section 5.4. 370 Since the remote KDC may change its PKCROSS key (referred to in 371 Section 5.2) while there are PKCROSS tickets still active, it SHOULD 372 cache the old PKCROSS keys until the last issued PKCROSS ticket 373 expires. Otherwise, the remote KDC will respond to a client with a 374 KRB-ERROR message of type KDC_ERR_TGT_REVOKED. 376 6. Extensions for the PKCROSS Ticket 378 As stated in section 5.3, the remote KDC SHOULD include policy 379 information in XTKT_(l,r). This policy information is contained in 380 a TicketExtension, as defined by the Kerberos specification, and the 381 authorization data of the ticket will contain an authorization 382 record of type AD-IN-Ticket-Extensions. The TicketExtension defined 383 for use by PKCROSS is TE-TYPE-PKCROSS-KDC. 384 Where 385 data-type equals 2 for TE-TYPE-PKCROSS-KDC 386 data-value is ASN.1 encoding of CrossRealmTktData 388 CrossRealmTktData ::= SEQUENCE OF TypedData 390 ------------------------------------------------------------------ 391 CrossRealmTktData types and the corresponding data are interpreted 392 as follows: 394 ASN.1 data 395 type value interpretation encoding 396 ---------------- ----- -------------- ---------- 397 PLC_LIFETIME 1 lifetime (in seconds) INTEGER 398 for TGT_(c,r) 399 - cross-realm tickets 400 issued for clients by 401 TGT_l 403 PLC_SET_TKT_FLAGS 2 TicketFlags that must BITSTRING 404 be set 405 - format defined by 406 Kerberos specification 408 PLC_NOSET_TKT_FLAGS 3 TicketFlags that must BITSTRING 409 not be set 410 - format defined by 411 Kerberos specification 413 Further types may be added to this table. 414 ------------------------------------------------------------------ 416 7. Usage of Certificates 418 In the cases of PKINIT and PKCROSS, the trust in a certification 419 authority is equivalent to Kerberos cross realm trust. For this 420 reason, an implementation MAY choose to use the same KDC certificate 421 when the KDC is acting in any of the following three roles: 422 1) KDC is authenticating clients via PKINIT 423 2) KDC is authenticating another KDC for PKCROSS 424 3) KDC is the client in a PKCROSS exchange with another KDC 426 Note that per PKINIT, the KDC X.509 certificate (the server in a 427 PKINIT exchange) MUST contain the principal name of the KDC in the 428 subjectAltName field. 430 8. Transport Issues 432 Because the messages between the KDCs involve PKINIT exchanges, and 433 PKINIT recommends TCP as a transport mechanism (due to the length of 434 the messages and the likelihood that they will fragment), the same 435 recommendation for TCP applies to PKCROSS as well. 437 9. Security Considerations 439 Since PKCROSS utilizes PKINIT, it is subject to the same security 440 considerations as PKINIT. Administrators should assure adherence 441 to security policy - for example, this affects the PKCROSS policies 442 for cross realm key lifetime and for policy propogation from the 443 PKCROSS ticket, issued from a remote KDC to a local KDC, to 444 cross realm tickets that are issued by a local KDC to a client. 446 10. Bibliography 448 [KERBTLS] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher 449 Suites to Transport Layer Security (TLS)", RFC 2712, 450 October 1999. 452 [KERB] J. Kohl and C. Neuman, "The Kerberos Network 453 Authentication Service (V5)", RFC 1510, September 1993. 455 [TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0", 456 RFC 2246, January 1999. 458 [PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, 459 J. Wray, J. Trostle. Public Key Cryptography for Initial 460 Authentication in Kerberos. 461 draft-ietf-cat-kerberos-pk-init-14.txt 463 [PKTAPP] A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman. 464 Public Key Utilizing Tickets for Application 465 Servers (PKTAPP). draft-ietf-cat-kerberos-pk-tapp-03.txt 467 [X509] ITU-T (formerly CCITT) Information technology - Open 468 Systems Interconnection - The Directory: Authentication 469 Framework Recommendation X.509 ISO/IEC 9594-8 471 [NEUMAN] B.C. Neuman, "Proxy-Based Authorization and Accounting for 472 Distributed Systems". Proceedings of the 13th 473 International Conference on Distributed Computing Systems, 474 May 1993 476 [KERB94] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication 477 Service for Computer Networks, IEEE Communications, 478 32(9):33-38. September 1994. 480 [KERB-REV] C.Neuman, J. Kohl, T. Ts'o. The Kerberos Network 481 Authentication Service (V5). 482 draft-ietf-cat-kerberos-revisions-08.txt 484 11. Authors' Addresses 486 Matthew Hur 487 Cisco Systems 488 2901 Third Avenue 489 Seattle, WA 98121 490 Phone: +1 206 256 3197 491 E-Mail: mhur@cisco.com 493 Brian Tung 494 Tatyana Ryutov 495 Clifford Neuman 496 USC/Information Sciences Institute 497 4676 Admiralty Way Suite 1001 498 Marina del Rey, CA 90292-6695 499 Phone: +1 310 822 1511 500 E-Mail: {brian, tryutov, bcn}@isi.edu 502 Ari Medvinsky 503 Liberate 504 2 Circle Star Way 505 San Carlos, CA 94070-6200 506 Phone: +1 650 701 4000 507 EMail: ari@liberate.com 509 Gene Tsudik 510 ICS Dept, 458 CS Building 511 Irvine CA 92697-3425 512 Phone: +1 310 448 9329 513 E-Mail: gts@ics.uci.edu 515 Bill Sommerfeld 516 Sun Microsystems 517 E-Mail: sommerfeld@east.sun.com