idnits 2.17.1 draft-ietf-ipsec-cdp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) 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. ** 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 20 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 147: '.... The Responder MUST process any cert...' RFC 2119 keyword, line 191: '...e, the Responder SHOULD send a message...' RFC 2119 keyword, line 195: '...responder MUST send this cookie back t...' RFC 2119 keyword, line 199: '...Responder is feeling clogged it SHOULD...' RFC 2119 keyword, line 253: '...e, the responder MUST set the P bit to...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 183 has weird spacing: '...pensive publi...' -- 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 (December 21, 1995) is 10347 days in the past. Is this intentional? -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-09) exists of draft-ietf-dnssec-secext-04 -- No information found for draft-atkins-pgpformats - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-skip-udh-00 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addr-arch is -02, but you're referring to -03. (However, the state information for draft-atkins-pgpformats is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-addr-arch (ref. '6') ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) -- No information found for draft-ietf-ipsec-photuris - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC Working Group Ashar Aziz 2 INTERNET-DRAFT Tom Markson 3 Hemma Prafullchandra 4 Sun Microsystems, Inc. 6 Expires in six months December 21, 1995 8 Certificate Discovery Protocol 9 11 Status of this Memo 13 This document is a submission to the IETF Internet Protocol Security 14 (IPSEC) Working Group. Comments are solicited and should be addressed to 15 to the working group mailing list (ipsec@ans.net) or to the authors. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working Groups. Note that other groups may also distribute working 20 documents as Internet Drafts. 22 Internet-Drafts draft documents are valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Distribution of this memo is unlimited. 35 Abstract 37 Use of Public key cryptography is becoming widespread on the Internet in 38 such applications as electronic mail and IP Security (IPSEC). 39 Currently, however, a common public key certificate infrastructure does 40 not exist which is interoperable with other systems and ubiquitous. In 41 light of this, we describe a protocol which may be used to exchange or 42 retrieve certificates (essentially signed public keys) with or from 43 another entity. The protocol may be used to request certificates from a 44 directory/name server or from the entity who owns the certificate. 46 CONTENTS 48 Status of this Memo................................. 1 50 Abstract............................................ 2 52 1. Overview............................................ 3 54 2. The Certificate Discovery Protocol.................. 4 56 2.1 Clogging Defense............................... 5 58 2.1.1 Cookie Generation 5 60 3. Certificate Discovery Packet........................ 6 62 3.1 Certificate Discovery Header................... 6 64 3.2 Name Record.................................... 8 66 3.3 Certificate Record............................. 9 68 4. Assigned Numbers.................................... 10 70 4.1 Port Number Assignments........................ 10 72 4.2 Name Type Assignments.......................... 10 74 4.3 Certificate Type Assignments................... 10 76 5. Security Considerations............................. 11 78 Acknowledgements.................................... 11 80 References.......................................... 11 82 Author's Address(es)................................ 12 84 - i - 85 1. Overview 87 The distribution of authenticated public keys is a fundamental problem 88 which needs to be resolved with use of public key cryptography. Many 89 solutions exist for distributing authenticated public keys. Two of the 90 more common distribution methods are the X.500 directory service [1] and 91 Secure Domain Name System (Secure-DNS) [2]. Each method has a different 92 encoding format for the entity identity and the public key that belongs 93 to it. It is expected that many distribution mechanisms will co-exist on 94 the Internet and hence many "certificate" formats. 96 We describe a protocol which may be used to exchange certificates on the 97 Internet. The protocol has the advantage that it does not require 98 changes to existing services or deployment of large directory services 99 in order to be used. The Certificate Discovery Protocol allows 100 certificate requests to be made to any arbitrary IP-node. This feature 101 allows the initiator to send requests to, say, an IP-node which is 102 acting as a certificate server (and hence would have many certificates 103 stored in its local certificate database) or to a single IP-node which 104 only has it's own certificate. 106 As noted earlier, there are several different types of certificates in 107 existence: X.509 certificates [11], PGP certificates [3], Secure DNS 108 resource records and hashed public keys [4]. This protocol is designed 109 to support all of these and new ones as they emerge. 111 All certificates have at least two properties: 113 (1) it provides for a cryptographic binding to a name/identity of an 114 entity, and 115 (2) it provides integrity protection of a public key. 117 The name may be encoded in the certificate (for example, as in X.509 and 118 PGP certificates) or it may be implicit in the public key itself (i.e., 119 the cryptographic hash of the public key). 121 As with various certificate types, numerous naming conventions exist on 122 the Internet, for example, IP addresses [5],[6], RFC 822 addresses [7], 123 DNS names and PGP user names. This protocol attempts to support all of 124 these and allows for other syntaxes. 126 Note, that a particular entity may have more than one certificate. An 127 entity may have the same public value in different certificate formats, 128 or have multiple public values each in a separate certificate or have 129 the same public value certified by different Certifying Authorities, and 130 so on. In all these possible certificates the identity of the entity 131 remains constant. 133 2. The Certificate Discovery Protocol 135 The Initiator is the entity which initiates Certificate Discovery. The 136 Responder is defined as the entity which receives the Certificate 137 Discovery initiate message and (optionally) responds with certificates. 139 The Initiator requests certificates by Name. A Name is defined as a Name 140 Record consisting of a Name Type, a Name Length and the actual Name of 141 the entity who the certificate belongs to. The Name Type specifies the 142 type of name, for example, a PGP printable string or a SKIP [12] name. 143 In the case where the Name Type is SKIP, the actual name consists of a 144 Name Space Identifier (NSID) followed by the Master KeyID (MKID). 146 The Initiator may optionally include certificates in an initiate 147 message. The Responder MUST process any certificate(s) the Initiator 148 has sent and respond with the requested certificates or an error (for 149 example, if the requested certificate does not exist or it had problems 150 processing the certificates it has received). 152 Note that this protocol allows the initiator to not only request for all 153 certificates for a particular "Name" but also send in the same message 154 all the certificates of the Initiator. 156 Also, in a request, the initiator may simply give the responder 157 certificates without asking for any in return. If the responder accepts 158 these certificates, the response message will return a status of 'OK'. 159 If the responder does not accept all of these certificates, a bit will 160 be set indicating this error and an appropriate error status will be 161 returned. 163 All certificate discovery protocol communication uses the User Datagram 164 Protocol (UDP) [8]. The client binds to port cert-initiator and sends a 165 certificate request to port cert-responder. Port number assignments are 166 described later. The responder binds to port cert-responder and sends 167 the response to port cert-initiator. 169 Two separate ports are used to allow for multiple certificate requests 170 to be made without waiting for the response to be received, (that means, 171 one port is used to simply send requests out and the other port is used 172 to receive responses). 174 2.1 Clogging Defense 176 The Certificate Discovery Protocol allows an Initiator to both make 177 certificate discovery requests (i.e. fetch), as well present 178 certificates (i.e. push). This could lead to a situation where an 179 Initiator may attempt to clog a certificate server by flooding it with 180 bogus certificate pushes. The server, when presented with a set of 181 certificates would at a minimum parse the request and check if it 182 already has the presented certificates in its local database. It may 183 also have to verify a signature using a (possibly) expensive public key 184 operation. Rather than discarding certificate pushes when it feels 185 clogged, the server may request that the Initiator use the optional 186 cookie exchange mechanism. With this approach, the server may continue 187 to serve legitimate requests. 189 If the Responder requires a cookie, it will expect the Initiator to send 190 the cookie with the expected value. If the Initiator does not send this 191 cookie, the Responder SHOULD send a message with the "Cookie Required" 192 status and the desired cookie in the cookie field. 194 The protocol also supports a cookie the initiator may set. The 195 responder MUST send this cookie back to the initiator in a response. 196 This cookie may be used for replay protection, clogging defense or as a 197 means for the client to associate responses with requests. 199 If either the Initiator or the Responder is feeling clogged it SHOULD 200 give preference in calculating the shared secrets (i.e. g^ij) 201 computations to certificates sent to it with magic cookies. (For 202 example, it could precompute g^ij immediately upon receiving the 203 certificate and after verifying it.) 205 2.1.1 Cookie Generation 207 The cookie generation method is as recommended in the Photuris Internet 208 Draft [9], i.e., an MD5 [10] hash is applied over the IP Source and IP 209 Destination Addresses, the UDP source and destination ports, and a 210 locally generated secret random value. A subset of this hash is then 211 used as a cookie. 213 Note that this is an implementation detail in that the mechanism 214 employed is purely a local matter, two communicating entities do not 215 have to use the same mechanism. 217 3. Certificate Discovery Packet 219 The Certificate Discovery Protocol message consists of three parts: 221 1) the certificate discovery header, 222 2) zero or more name record(s), and 223 3) zero or more certificate record(s). 225 3.1 Certificate Discovery Header 227 The following describes a certificate discovery header. All values 228 are in network order. 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | VERS |I|R|ACT|P| STATUS |#-OF-NAME-RECS |#-OF-CERT-RECS | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Initiator Cookie (if I bit is set) | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Responder Cookie (if R bit is set) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 VERS indicates protocol version number, VERS = 1 for this protocol. 242 I bit indicates if a 32 bit Initiator Cookie is present (I=1) or not (I=0). 243 R bit indicates if a 32 bit Responder Cookie is present (R=1) or not (R=0). 245 ACT indicates the type of message. Possible values are: 246 1 (Initiate) - initiate either a request for certificate(s) or simply 247 send certificates. 248 2 (Response) - response to a certificate Initiate. 250 P bit in a response indicates whether the responder has rejected 251 certificates presented in the initiate message. If the responder has 252 accepted the certificates or if no certificates were present in the 253 initiate message, the responder MUST set the P bit to 0. If the responder has 254 NOT accepted ALL of the certificates present in the initiate message, the P bit 255 is set to 1 and the status field should indicate the reason for failure. 256 If the responder has rejected certificates in the initiator's request, 257 no certificates should be returned to the initiator and #-OF-CERT-RECS 258 MUST be set to 0. 260 STATUS is used only in responses (i.e. ACTION = 2). It MUST be ignored 261 by the responder. Possible values are: 263 0 (OK) - The responder has processed the certificates sent 264 or has returned the requested certificates. 265 1 (Unknown Error) - An error has occurred. 266 2 (Unknown Name) - No certificates for the requested "Name" can 267 be found in the local certificate database or 268 the local domain name server. 269 3 (Unsupported Name Type) - Name Type in the certificate request is 270 unsupported. 271 4 (Unsupported CERT-Type) - CERT-Type in the certificate request is 272 unsupported. 273 5 (Cookie Required) - Responder requires the initiator to resend this 274 request with a non-zero cookie included. 275 6 (Request Too Large) - Request cannot be satisfied in one UDP packet 276 (64K). This may occur, for example, if the 277 initiator has too many names listed in the 278 certificate initiate message. If the initiator 279 receives this response then it SHOULD resend 280 the request with fewer names. The responder, 281 however, SHOULD send as many certificates as 282 it can in the response. 284 #-OF-NAME-RECS - The number of Name Records present in the 285 initiate message. This field is only meaningful 286 in an initiate message. If the field is set to 287 0 in an initiation, the protocol functions 288 as a way of "pushing" certificates to a 289 remote host. A response should not have 290 any explicit Name Records, they should be a 291 part of the Certificate Record(s) and hence 292 #-OF-NAME-RECS should be set to 0. 294 #-OF-CERT-RECS - The number of Certificate Records present in the 295 initiate or response. If this value is 0 then no 296 Certificate Records are present in the message. 297 If this field is zero in an initiate message, the 298 initiator is requesting certificates without 299 presenting any. If the field is zero in a 300 response, the R bit and the STATUS field 301 indicate the status of the previous request. 303 Initiator Cookie - This is an optional field and is not present 304 when the 'I' bit is set to zero. 306 In an initiate message, this contains the 307 value that the Responder should send back in 308 the response. 310 In a response message, this field contains the 311 value that was sent by the initiator in this 312 field in the initiate message. This field 313 should be present in a response message 314 (and the I bit set) if the initiate message 315 has the 'I' bit set to 1. 317 Responder Cookie - This is an optional field and is not present 318 when the 'R' bit set to zero. 320 In an initiate message, this contains the value 321 that the Responder previously indicated should 322 be sent in the request. In a response message, 323 if the "Cookie Required" status is set, this 324 contains the value that should be sent in a 325 new request. If the response message does 326 not have the "Cookie Required" status, this 327 value SHOULD be not be present and the 'R' 328 bit should be set to 0. 330 3.2 Name Record 332 Following the Certificate Discovery header is one Name record for each 333 name included in the initiate message. A correctly formed Certificate 334 Discovery message MUST contain as many name records as the #-OF-NAME- 335 RECS field in the Certificate Discovery header field specifies. 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Name Type | Name Length | Name ~ 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Name Type - Identifies the type of the Name. The values of this 344 field will be assigned by the Internet Assigned Numbers 345 Authority (IANA). 347 Name Length - The length of the name in bytes. 349 Name - The name of the entity who owns the certificate for 350 which the request is being made. 352 3.3 Certificate Record 354 Following the Name Record(s) is one certificate record for each 355 certificate included in the protocol. A correctly formed Certificate 356 Discovery message MUST contain as many certificate records as the #-OF- 357 CERT-RECS field in the Certificate Discovery header field specifies. 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Name Type | Name Length | Name ~ 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | CERT-Type | CERT-Length | Certificate ~ 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Name Type, Name Length and Name are the same as in a name record. 369 CERT-Type - specifies the certificate type of the certificate that 370 is to follow. These values will be assigned by IANA. 372 CERT-Length - specifies the length of the certificate in bytes. 374 Certificate - the actual certificate. 376 4. Assigned Numbers 378 4.1 Port Number Assignments 380 IANA has assigned UDP port 1639 to "cert-initiator". UDP port 1640 has 381 been assigned to "cert-responder". 383 4.2 Name Type Assignments 385 Name Type Value Name Type 387 1 SKIP 388 2 PGP Printable String 389 3 PGP KeyID 390 4 DNS name 391 5 RFC 822 name 392 6 X.509 Distinguished Name 394 Name Type values 1 through 6 are assigned as is described above. Name 395 Type values 7 through 249 inclusive are reserved to IANA for future 396 allocation as Assigned Numbers. Such future allocation by IANA will 397 normally require that a public specification exist for the Name Type 398 obtaining such allocation. Name Types in the range 250 through 255 399 inclusive are reserved for private use among consenting parties. Name 400 Types in the range 250 through 255 inclusive will hence only have local 401 uniqueness properties. 403 4.3 Certificate Type Assignments 405 CERT-Type Value Certificate Type 407 1 X.509 [1] 408 2 PGP [3] 409 3 Secure DNS [2] 410 4 MD5 of Unsigned DH Public Value [4] 411 5 MD5 of Unsigned Elliptic Curve Public Value 412 6 MD5 of Unsigned RSA Public Value 414 CERT-Type values 1 through 6 are assigned as is described above. CERT- 415 Type values 7 through 249 inclusive are reserved to IANA for future 416 allocation as Assigned Numbers. Such future allocation by IANA will 417 normally require that a public specification exist for the Certificate 418 Type obtaining such allocation. CERT-Types in the range 250 through 255 419 inclusive are reserved for private use among consenting parties. CERT- 420 Types in the range 250 through 255 inclusive will hence only have local 421 uniqueness properties. 423 The Certificate Discovery Protocol uses two UDP ports to exchange 424 certificates. A request has been submitted to IANA for these port 425 assignments. 427 5. Security Considerations 429 A responder should use the cookie exchange mechanism when it feels 430 clogged. The Certificate Discovery Protocol uses two ports, we suggest 431 that these ports be treated as a "by-pass" channel for encryption (i.e. 432 non encrypted traffic is permitted to be sent on these ports). As only 433 certificates fetches/pushes are satisfied on these ports the window for 434 vulnerability is limited. 436 Acknowledgements 438 We would like to thank all of the people who helped make this draft 439 possible. 441 Ran Atkinson suggested that this protocol should be independent of other 442 IPSEC drafts. 444 Phil Karn and Bill Simpson for their work on the Cookie Exchange scheme 445 for the Photuris Session Key Management Protocol which influenced the 446 addition of the Cookie field to this protocol. 448 Bill Danielson, Marc Dye, Colin Plumb, Rich Skrenta and Ben Stoltz for 449 reviewing this draft and providing constructive suggestions. 451 References 453 [1] CCITT Recommendation X.500 (1988), "The Directory" 455 [2] Eastlake, D., Kaufman, C., "Domain Name Security Extensions", (I-D 456 draft-ietf-dnssec-secext-04.txt), Work In Progress 458 [3] Atkins, D., Stallings, W., Zimmerman, P., "PGP Message Exchange 459 Formats", (I-D draft-atkins-pgpformats-01.txt), Work In Progress 461 [4] Aziz, A., Markson, T., Prafullchandra, H., "Encoding of an Unsigned 462 Diffie-Hellman Public Value", (I-D draft-ietf-ipsec-skip-udh- 463 00.txt), Work In Progress 465 [5] Postel, J., "Address Mappings", IEN 115, USC/Information Sciences 466 Institute, August 1979 468 [6] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 469 (I-D draft-ietf-ipngwg-addr-arch-03.txt), Work In Progress 471 [7] Crocker, D., "Standard for the format of ARPA Internet text 472 messages", RFC 822 474 [8] Postel, J., "User Datagram Protocol", RFC 768 476 [9] Karn, P., Simpson, W. A., "The Photuris Session Key Management 477 Protocol", (I-D draft-ietf-ipsec-photuris-08.txt), Work In Progress 479 [10] R. Rivest, "The MD5 Message Digest Algorithm", RFC 1321, April 1992 481 [11] CCITT Recommendation X.509 (1988), "The Directory - Authentication 482 Framework" 484 [12] Aziz, A., Markson, T., Prafullchandra, H., "Simple Key-Management 485 for Internet Protocols", (I-D draft-ietf-ipsec-skip-06.txt), Work In 486 Progress 488 Author's Address(es) 489 Ashar Aziz 490 Sun Microsystems, Inc. 491 M/S PAL1-550 492 2550 Garcia Avenue 493 Mountain View, CA 94043 495 Email: ashar.aziz@eng.sun.com 496 Alternate email address: ashar@incog.com 498 Tom Markson 499 Sun Microsystems, Inc. 500 M/S PAL1-550 501 2550 Garcia Avenue 502 Mountain View, CA 94043 504 Email: markson@incog.com 505 Alternate email address: markson@eng.sun.com 507 Hemma Prafullchandra 508 Sun Microsystems, Inc. 509 M/S PAL1-550 510 2550 Garcia Avenue 511 Mountain View, CA 94043 513 Email: hemma@eng.sun.com 514 Alternate email address: hemma@incog.com