idnits 2.17.1 draft-ietf-roamops-roamsec-02.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-29) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 162 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 247 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... its worki...' == Line 18 has weird spacing: '... and may ...' == Line 19 has weird spacing: '...afts as refer...' == Line 22 has weird spacing: '... To learn...' == (157 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (20 July 1998) is 9384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 451, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '1') -- No information found for draft-ietf-roamops-romreq - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '5') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-hmac-md5 is -00, but you're referring to -01. (However, the state information for draft-ietf-roamops-romreq is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. '6') == Outdated reference: A later version (-10) exists of draft-ietf-roamops-auth-05 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-auth (ref. '8') Summary: 18 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROAMOPS Working Group Pat Calhoun 3 INTERNET-DRAFT Sun Microsystems 4 Category: Standards Track Bernard Aboba 5 Microsoft 6 20 July 1998 8 End-to-End Security in Roaming 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as , and expires January 15, 1999. Please 29 send comments to the authors. 31 2. Abstract 33 As noted in Roaming Requirements, there is a need for end-to-end secu- 34 rity in roaming, including end-to-end integrity protection, and confi- 35 dentiality. In roaming implementations based on proxy chaining, pack- 36 ets are routed between the NAS and home server through a series of 37 proxies. Current roaming implementations provide only hop-by-hop 38 security, guarding only against modification of packets in transit 39 between hops. This makes it possible for untrusted proxies to modify 40 packets sent between a NAS and a home server without detection, as 41 well as to decrypt PAP passwords, Tunnel passwords, and other hidden 42 attributes which are available to it in cleartext. 44 This document provides a framework for end-to-end security in roaming, 45 making it possible to provide end-to-end message integrity and 46 attribute hiding through addition of three new attributes. 48 3. Introduction 50 As noted in [2], there is a need for end-to-end security in roaming, 51 including end-to-end integrity protection, and confidentiality. In 52 roaming implementations based on proxy chaining, packets are routed 53 between the NAS and home server through a series of proxies. Current 54 roaming implementations, as described in [1] provide only hop-by-hop 55 security, guarding only against modification of packets in transit 56 between hops. This makes it possible for untrusted proxies to modify 57 packets sent between a NAS and a home server without detection, as 58 well as to decrypt PAP passwords, Tunnel passwords, and other hidden 59 attributes which are available to proxies in cleartext. 61 This document provides a framework for end-to-end security in roaming, 62 making it possible to provide end-to-end message integrity and 63 attribute hiding through addition of three new attributes, Security- 64 Parameter-Index, Hidden and End-to-End-Signature. In this document, 65 it is assumed that a key has previously been established between the 66 two endpoints. It is this key which is used in calculation of the mes- 67 sage integrity check, as well as in end-to-end encryption of 68 attributes. Future documents will discuss key exchange issues. 70 The Security-Parameters-Index attribute is used to identify the secu- 71 rity association within which the End-to-End-Signature and Hidden 72 attributes are to be evaluated. Note that in the case where an inter- 73 mediate proxy implements policy, it is possible for a security associ- 74 ation to be established between the intermediate proxy and the home 75 server, NAS, or local proxy. For example, an intermediate proxy may 76 immediately send an Access-Reject to the NAS in response to an Access- 77 Request, without having first forwarded it to the home server. In this 78 case, the intermediate proxy and NAS would need to establish a secu- 79 rity association in order to permit verification of the authenticity 80 of the Access-Reject. 82 Using the Hidden attribute, it is possible for the client or server to 83 protect an attribute end-to-end. This is accomplished by encapsulating 84 and then encrypting another attribute within the Hidden attribute. 86 Using the End-to-End-Signature attribute, it is possible for a client 87 or server to provide a keyed MAC which will allow end-to-end integrity 88 protection. The keyed MAC is calculated over the immutable portions of 89 the packet header, as well as all of the attributes preceeding the 90 End-to-End-Signature attribute. This makes it possible for some or all 91 of the attributes in the packet to be protected, at the sender's dis- 92 cretion. 94 While a proxy may add, delete or modify unprotected attributes, it 95 MUST NOT add, delete or modify protected attributes so that the valid- 96 ity of the keyed MAC can be maintained. A proxy also MUST NOT modify 97 an End-to-End-Signature or Hidden attribute. On receiving a packet 98 including an End-to-End-Signature attribute, an end system implement- 99 ing end-to-end security MUST check the validity of the message 100 integrity check and MUST silently discard the packet if the message 101 integrity check cannot be verified. 103 By allowing the message integrity check to be applied to a subset of 104 attributes selected by the sender, and by allowing attributes to be 105 hidden individually, these extensions enable end-to-end security 106 functionality while at the same time enabling proxies to continue to 107 implement policy. As described in [8], policy function is a central 108 part of the roaming architecture since roaming is inherently an inter- 109 domain activity. 111 4. Requirements language 113 In this document, the key words "MAY", "MUST, "MUST NOT", 114 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 115 interpreted as described in [7]. 117 5. Transition 119 Since NAS devices will not initially implement the End-to-End-Signa- 120 ture and Hidden attributes, it is envisaged that these attributes will 121 initially be deployed on local proxies and home servers. In this sce- 122 nario, the local proxy will be configured to employ end-to-end secu- 123 rity for those NAS devices that do not support this. In this case, the 124 local proxy would add End-to-End security attributes to Access- 125 Requests destined for the home server and would process End-to-End 126 security attributes in an Access-Accept, Access-Reject or Access-Chal- 127 lenge originated by the home server. 129 Note that if a NAS is end-to-end security enabled, then the local 130 proxy will receive an Access-Request from the NAS with an End-to-End- 131 Signature and will not need to add its own. As a result, a packet 132 should include at most one End-to-End-Signature attribute. A packet 133 may contain more than one Hidden attribute. 135 6. Proposed attributes 137 6.1. Security-Parameter-Index 139 Description 141 The purpose of the Security-Parameter-Index attribute is to iden- 142 tify the security association within which the End-to-End-Signature 143 and Hidden attributes should be evaluated. 145 A summary of the Security-Parameter-Index attribute is shown below. 146 The fields are transmitted from left to right. 148 0 1 2 3 149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Type | Length | Value 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Value (cont'd) | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Type 157 ? for Security-Parameter-Index 159 Length 161 6 163 Value 165 The Value field is four octets. This serves as an index identifying 166 the security association established between the two end-points. 168 6.2. End-to-End-Signature 170 Description 172 This attribute provides for the use of a keyed-MAC to be verified 173 end-to-end. 175 A summary of the End-to-End Signature attribute is shown below. 176 The fields are transmitted from left to right. 178 0 1 2 3 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type | Length | Protocol | String 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | String... 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Type 188 ? for End-to-End-Signature 190 Length 192 19 (protocol 1) 194 Protocol 196 The protocol field specifies the authentication algorithm to be 197 used in computing the message authentication code (MAC) which is 198 placed in the string field. 200 If the protocol field is 1, the HMAC protocol, described in [6] 201 is used, along with the MD5 algorithm described in [5]. All 202 implementations MUST support HMAC-MD5. No other protocol values 203 are defined. 205 String 207 The End-to-End-Signature is an calculated using the algorithm 208 specified in the protocol field. The MAC is computed over the 209 portion of the RADIUS packet from the beginning until the end of 210 the End-to-End-Signature attribute, including Type, ID, Length 211 and authenticator. In calculating the End-to-End-Signature, the 212 authenticator should be considered to be filled with zeroes, and 213 the End-to-End-Signature string should be considered to be six- 214 teen octets of zero. 216 The portion of the RADIUS packet after the End-to-End-Signature 217 attribute is not included in the calculation of the MAC. This 218 makes it possible for a proxy to add, modify, or delete 219 attributes placed after the End-to-End-Signature attribute. As a 220 result, attributes placed prior to the End-to-End-Signature 221 attribute can be considered "protected" and those placed after 222 the attribute can be considered to be "unprotected." Note that 223 in order for the End-to-End-Signature to be verified, the proxy 224 MUST maintain attribute order. 226 6.3. Hidden 228 Description 230 The purpose of the Hidden attribute is to make possible end-to-end 231 encryption of individual attributes. This would make it possible 232 for attributes such as User-Password or Tunnel-Password to be sent 233 securely between a RADIUS client and a server, without risk of com- 234 promise by an untrusted proxy. 236 A summary of the Hidden attribute is shown below. The fields are 237 transmitted from left to right. 239 0 1 2 3 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | String 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | String... 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Type 249 ? for Hidden 251 Length 253 >=4 255 String 257 The String field includes the encapsulated ciphertext of the 258 attribute which is to be hidden end-to-end. The hidden attribute 259 is encrypted using a key and encryption algorithm which had pre- 260 viously been established between the two endstations. Note that 261 due to the 253 octet limitation on the size of RADIUS 262 attributes, the encapsulated attribute may be a maximum of 251 263 octets in length. 265 7. Table of Attributes 267 The following table provides a guide to which attributes may be found 268 in which kind of packets. 270 Request Accept Reject Challenge # Attribute 271 0-1 0-1 0-1 0-1 ? End-to-End-Signature 272 0+ 0+ 0 0+ ? Hidden 273 0-1 0-1 0-1 0-1 ? SPI 275 8. Security issues 277 The following security threats have been identified in roaming sys- 278 tems: 280 Rogue proxies 281 Theft of passwords 282 Theft of accounting data 283 Replay attacks 284 Connection hijacking 285 Fraudulent accounting 287 8.1. Rogue proxies 289 In conventional ISP application, the NAS, proxy, and home server exist 290 within a single administrative entity. As a result, the proxy may be 291 considered a trusted component. 293 However, in a roaming system implemented with proxy chaining, the NAS, 294 proxies, and home server may be managed by different administrative 295 entities. Through the use of shared secrets it is possible for proxies 296 operating in different domains to establish a trust relationship. How- 297 ever, if packets are only authenticated on a hop-by-hop basis, then 298 untrusted proxies are capable of perpetrating a number of man-in-the- 299 middle attacks. 301 These attacks typically involve the editing of attributes, or the mod- 302 ification or insertion of messages, such as the substitution of an 303 Access-Accept for an Access-Reject. For example, a proxy may modify 304 an Access-Accept sent by the home server so as to lessen the security 305 obtained by the client. For example, EAP attributes might be removed 306 or modified so as to cause a client to authenticate with EAP MD5 or 307 PAP, instead of a stronger authentication method. Alternatively, tun- 308 nel attributes might be removed or modified so as to remove encryp- 309 tion, redirect the tunnel to a rogue tunnel server, or otherwise 310 lessen the security provided to the client. 312 Through implementation of the End-to-End-Signature attribute, it is 313 possible to detect unauthorized addition, deletion, or modification of 314 protected attributes. Note that it is still possible for a rogue proxy 315 to add, delete, or modify unprotected attributes. 317 While a proxy MUST NOT send an Access-Accept to the NAS after receiv- 318 ing an Access-Reject from the home server, a proxy MAY send an Access- 319 Reject to the NAS after receiving an Access-Accept from the home 320 server. Note that in the latter case, a Security-Parameter-Index 321 attribute should be used denoting the security association between the 322 proxy and the NAS, rather than that between the home server and the 323 NAS, since the proxy has originated the packet. This will allow the 324 NAS to verify the End-to-End-Signature attribute within the packet, 325 and decide whether to silently discard the packet. As noted earlier, 326 an Access-Accept originated by a proxy MUST be silently discarded by 327 the NAS, even if the End-to-End-Signature attribute can be verified. 329 The determination of whether end-to-end security is to be used in a 330 conversation is made using out-of-band mechanisms. Typically this is 331 based either on static configuration or on the outcome of a key 332 exchange conversation between the two endpoints. However, once it is 333 determined that the end systems wish to use end-to-end security, all 334 packets sent MUST include an End-to-End-Signature attribute and pack- 335 ets received without an End-to-End-Signature attribute MUST be 336 silently discarded. Note that policy determination using an out-of- 337 band mechanism rather than a proxied conversation limits the ability 338 of a rogue proxy to interfere with the security negotiation between 339 the two end systems. 341 8.2. Theft of passwords or keys 343 Unless the Hidden attribute is used, where clients authenticate using 344 PAP, or where the Tunnel-Password attribute is included with the 345 Access-Accept, each proxy along the path between the local NAS and the 346 home server will have access to the cleartext password or key. In many 347 circumstances, this represents an unacceptable security risk. As a 348 result, the Hidden attribute SHOULD be used to provide end-to-end con- 349 fidentiality for User-Password or Tunnel-Password attributes. 351 8.3. Integrity and confidentiality of accounting data 353 Typically in roaming systems, accounting packets are provided to all 354 the participants along the roaming relationship path, in order to 355 allow them to audit subsequent invoices. In order to prevent modifica- 356 tion of accounting packets by untrusted proxies, the End-to-End-Signa- 357 ture attribute MAY be used. If it is desired that accounting data be 358 kept confidential from a proxy, the Hidden attribute MAY be used. If 359 the objective is to prevent snooping of accounting data on the wire, 360 then IPSEC ESP MAY be used. 362 8.4. Replay attacks 364 In this attack, a man in the middle or rogue proxy collects CHAP-Chal- 365 lenge and CHAP-Response attributes, and later replays them. If this 366 attack is performed in collaboration with an unscrupulous ISP, it can 367 be used to subsequently submit fraudulent accounting records to the 368 accounting agent for payment. The system performing the replay need 369 not necessarily be the one that initially captured the CHAP Chal- 370 lenge/Response pair. 372 While such an attack has always been possible, without roaming the 373 threat is restricted to proxies operating in the home server's domain. 374 With roaming, such an attack can be mounted by any proxy capable of 375 reaching the home server. 377 In order to protect against replay attacks, CHAP-Challenge and CHAP- 378 Response attributes MAY be protected using the Hidden attribute. CHAP 379 replay attacks can also be defeated by means of an end-to-end chal- 380 lenge-response exchange. For example, if the home server returns an 381 Access-Challenge packet containing a CHAP-Challenge attribute and 382 maintains state with respect to outstanding challenges, replay attacks 383 cannot succeed. 385 However, it should also be noted that end-to-end challenges (as prac- 386 ticed within the EAP MD5 authentication method, or in the CHAP-Chal- 387 lenge method described above) are also subject to attacks by rogue 388 proxies. In such an attack a proxy substitutes a static challenge for 389 the challenge sent by the home server, and on receiving the response, 390 checks it against a databases of hashes applied against a dictionary. 391 This attack may be prevented through use of the End-to-End-Signature 392 attribute. 394 8.5. Connection hijacking 396 In this form of attack, the attacker attempts to inject packets into 397 the conversation between the NAS and the home server. RADIUS as 398 described in [3] is vulnerable to such attacks since only Access-Reply 399 and Access-Challenge packets are authenticated. This attack may be 400 defeated via use of an End-to-End-Signature attribute. 402 8.6. Fraudulent accounting 404 In this form of attack, a local proxy transmits fraudulent accounting 405 packets or session records in an effort to collect fees to which they 406 are not entitled. This includes submission of packets or session 407 records for non-existent sessions, or submission of exaggerated ses- 408 sion times for actual sessions. 410 Such behavior will only be easily detectable in the event that roaming 411 users are making use of voluntary or compulsory tunneling, in which 412 case the tunnel server will generate its own accounting record, which 413 may be compared to that generated by the local ISP. However, tunneling 414 is expected to represent only a small percentage of roaming use. 416 In order to detect submisson of fraudulent accounting packets or ses- 417 sion records, the the accounting gateway SHOULD send copies of session 418 records to all parties with a financial interest in the session. Par- 419 ties receiving copies of these session records SHOULD reconcile them 420 with logs of proxied authentications. 422 In order to make it easier to match authentication logs with account- 423 ing records, home servers involved in roaming SHOULD include a Class 424 attribute in the Access-Accept. The Class attribute should uniquely 425 identify a session, so as to allow an authentication log entry to be 426 matched with a corresponding accounting log. 428 In order to be able to match accounting logs with logs of proxied 429 authentications, accounting agents SHOULD require that they act as an 430 authentication proxy for all sessions for which an accounting record 431 will subsequently be submitted. 433 9. Acknowledgments 435 Thanks to Glen Zorn of Microsoft for useful discussions of this prob- 436 lem space. 438 10. References 440 [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming 441 Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asi- 442 ainfo, Merit, September 1997. 444 [2] B. Aboba, G. Zorn. "Roaming Requirements." Internet-Draft (work 445 in progress) draft-ietf-roamops-romreq-09.txt, Microsoft, April 1998. 447 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 448 cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, 449 Daydreamer, April 1997. 451 [4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 452 1997. 454 [5] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 455 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., 456 April 1992. 458 [6] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for 459 Message Authentication," Internet Draft (work in progress), draft- 460 ietf-ipsec-hmac-md5-01.txt, August 1996. 462 [7] S. Bradner. "Key words for use in RFCs to Indicate Requirement 463 Levels." RFC 2119, Harvard University, March, 1997. 465 [8] B. Aboba, J.R. Vollbrecht, "Proxy Chaining and Policy 466 Implementation in Roaming," Internet Draft (work in progress), draft- 467 ietf-roamops-auth-05.txt, Microsoft, MERIT, July 1998. 469 11. Authors' Addresses 471 Pat R. Calhoun 472 Technology Development 473 Sun Microsystems, Inc. 474 15 Network Circle 475 Menlo Park, CA 94025 477 Phone: 650-786-7733 478 Fax: 650-786-6445 479 EMail: pcalhoun@eng.sun.com 481 Bernard Aboba 482 Microsoft Corporation 483 One Microsoft Way 484 Redmond, WA 98052 486 Phone: 206-936-6605 487 EMail: bernarda@microsoft.com