idnits 2.17.1 draft-ietf-mobileip-aaa-key-06.txt: 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. == 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 Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 123: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 126: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 170: '...as those listed in 2 MAY also be used....' RFC 2119 keyword, line 213: '... value, which the mobile node MUST use...' RFC 2119 keyword, line 231: '... MUST appear in the Registration Rep...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3012 (ref. '2') (Obsoleted by RFC 4721) == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-03 ** Obsolete normative reference: RFC 1750 (ref. '4') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '7') ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2002 (ref. '10') (Obsoleted by RFC 3220) -- Unexpected draft version: The latest known version of draft-ietf-mobileip-gen-key is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 10 June 2001 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 AAA Registration Keys for Mobile IP 7 draft-ietf-mobileip-aaa-key-06.txt 9 Status of This Memo 11 This document is a submission by the mobile-ip Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the mobile-ip@sunroof.eng.sun.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 AAA servers, such as RADIUS and DIAMETER, are in use within the 36 Internet today to provide authentication and authorization services 37 for dial-up computers. Mobile IP requires strong authentication 38 between the mobile node and its home agent. When the mobile node 39 shares a security association with its home AAA server, however, it 40 is possible to use that security association to create derivative 41 security associations between the mobile node and its home agent, 42 and again between the mobile node and the foreign agent currently 43 offering connectivity to the mobile node. This document specifies 44 extensions to the Mobile IP Registration Reply packet that can be 45 used to create such security information at the mobile node. 47 1. Introduction 49 AAA servers, such as RADIUS [13] and DIAMETER [3], are in use within 50 the Internet today to provide authentication and authorization 51 services for dial-up computers. Such services are likely to be 52 equally valuable for mobile nodes using Mobile IP when the nodes 53 are attempting to connect to foreign domains with AAA servers. 54 Mobile IP [10] requires strong authentication between the mobile 55 node and its home agent. When the mobile node shares a security 56 association with its home AAA server, however, it is possible to use 57 that security association to create derivative security associations 58 between the mobile node and its home agent, and again between the 59 mobile node and the foreign agent currently offering connectivity to 60 the mobile node. This document specifies extensions to the Mobile 61 IP Registration messages that can be used to create those security 62 associations at the mobile node. 64 AAA servers typically use the Network Access Identifier (NAI) [1] 65 to uniquely identify the mobile node; the mobile node's home 66 address is not always necessary to provide that function. Thus, 67 it is possible for a mobile node to authenticate itself, and be 68 authorized for connection to the foreign domain, without having any 69 home address. However, for Mobile IP to work, the mobile node is 70 required to have a security association with its home agent. When 71 the Mobile IP Registration Reply packet is authenticated by the 72 MN-AAA Authentication Extension [2], the mobile node can verify that 73 the keys contained in the extensions were produced by the AAA server, 74 and thus may be reliably used to create security associations with 75 the home agent, or alternatively with the foreign agent. 77 The protocol and messages in this document are intended to facilitate 78 the following operations which may occur between the mobile node, AAA 79 server, home agent, and foreign agent. 81 1. When a mobile node travels away from home, it may not have a 82 security association with its home agent, perhaps because it does 83 not yet have a home address. 85 2. If the mobile node does not have a Mobility Security Association 86 with the foreign agent, it includes an MN-FA Key Request 87 extension. 89 3. Similarly, if the mobile node does not have a Mobility Security 90 Association with the home agent, it adds an MN-HA Key Request 91 extension. 93 4. If one or more Key Request extensions were added, the MN-AAA 94 Authentication extension is added to the Registration Request. 96 5. At the time the information within the MN-AAA Authentication 97 extension is verified by the AAA server, the AAA server also 98 generates Key Material for the keys requested by the mobile node, 99 and causes insertion of the Key Material fields along with the 100 Registration Reply. 102 6. The respective AAA keys are distributed to the Home and Foreign 103 Agent via the AAA protocol. 105 7. If the Reply passes authentication and contains the Unsolicited 106 MN-HA Key Material From AAA extension (see section 5), the mobile 107 node generates the key using the Key Material provided, according 108 to its security association with the AAA. The resulting key is 109 used to establish the mobile node's security association with its 110 home agent, and is used to authenticate the MN-HA authentication 111 extension. 113 8. Similarly, if the Reply passes authentication and contains 114 the Unsolicited MN-FA Key Material From AAA extension (see 115 section 4), the mobile node generates the key using the Key 116 Material provided, according to its security association with the 117 AAA. The resulting key is used to establish the mobile node's 118 security association with its new foreign agent, and is used to 119 compute the authentication data used in the MN-FA authentication 120 extension. 122 Any registration reply containing the Unsolicited MN-HA Key Material 123 From AAA extension MUST also contain a subsequent Mobile Home 124 Authentication Extension, created using the generated MN-HA key. 125 Similarly, a reply containing the Unsolicited MN-FA Key Material 126 From AAA extension MUST also contain a subsequent Mobile Foreign 127 Authentication Extension, created using the the MN-FA key. 129 2. Dynamic Security Associations 131 Mobility Security Associations between Mobile IP entities 132 (mobile nodes, home agents, foreign agents) contain both the 133 necessary cryptographic key information, and a way to identify 134 the cryptographic algorithm which uses the key to produce the 135 authentication information typically included in the Mobile Home 136 Authentication extension or the Mobile Foreign Authentication 137 extension. In order for the mobile node to make use of key 138 information sent to it by the AAA server, the mobile node also has to 139 be able to select the appropriate cryptographic algorithm that uses 140 the key to produce the authentication. The following table contains 141 the supported algorithm identifiers. 143 Algorithm Identifier Name Reference 144 --------------------- ------------------ ------------ 145 1 MD5/prefix+suffix RFC 2002 [10] 146 2 HMAC MD5 RFC 2104 [5] 147 3 SHA-1 FIPS 180-1 [9] 149 New algorithms will be allocated as indicated by practical experience 150 using the extensions defined in this document. 152 Dynamic Mobility Security Associations shared between mobile nodes 153 and home agents also requires a replay protection method. The 154 following table contains the supported replay methods. 155 Replay Method Name Reference 156 -------------- ------------ -------------- 157 1 None RFC 2002 [10] 158 2 Timestamps RFC 2002 [10] 159 3 Nonces RFC 2002 [10] 161 3. Key Material Creation and Derivation 163 This section contains the procedures followed in the creation of the 164 Key Material by AAA servers, and the key derivation procedures used 165 by mobile nodes. Note that the AAA servers will also make use of the 166 derivation procedures to deliver the keys via the AAA protocol. 168 The example that follows makes use of MD5 in prefix+suffix mode, 169 whose support is mandatory in Mobile IP [10]. Other cryptographic 170 functions, such as those listed in 2 MAY also be used. 172 1. The AAA server identifies the mobile node's via a 173 ``node-address''. If the Home Address field of the 174 Registration Request is zero (0), the Mobile Node's NAI is used 175 instead. 177 2. The AAA server generates a random [4] value of at least 64 bits. 179 3. The AAA server inserts the random value into the Key extension in 180 the ``Key Material'' field. 182 4. The mobile node calculates 184 key = MD5(AAA-key | Key Material | node-address | AAA-key) 186 5. The mobile node creates the dynamic security association, using 187 the key, and the other relevant information in the Key Extension. 189 4. Unsolicited MN-FA Key Material From AAA Subtype 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Lifetime | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | AAA SPI | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | FA SPI | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Algorithm Identifier | Key Material ... 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 1: The Unsolicited MN-FA Key Material From AAA 204 Subtype-Specific Data 206 lifetime This field indicates the duration of time (in seconds) 207 for which the MN-FA key is valid. 209 AAA SPI A 32-bit opaque value, indicating the SPI that the 210 mobile node must use to determine the algorithm to use 211 for establishing the FA security information. 213 FA SPI A 32-bit opaque value, which the mobile node MUST use 214 to index all the necessary information established for 215 the FA security information after it is decoded. 217 Algorithm Identifier 218 This field indicates the algorithm to be used for 219 future computations of the MN-FA Authentication 220 Extension (see section 2) 222 Key Material 223 A random [4] value of at least 64 bits. 225 The Unsolicited MN-FA Key Material From AAA extension, shown 226 in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply 227 Extension [12]. The Key Material is added by the home domain AAA 228 server (AAAH) for use by the mobile node in creating the MN-FA key, 229 which is used to secure future Mobile IP registrations with the same 230 foreign agent. The Unsolicited MN-FA Key Material From AAA extension 231 MUST appear in the Registration Reply before the MN-FA Authentication 232 extension. 234 Once the mobile node creates the FA Security Information, by using 235 the algorithm indexed by the AAA SPI, it stores the FA Security 236 Information indexed by the FA SPI in its list of Mobile Security 237 Associations. 239 If the foreign agent receives a Registration Reply that does not have 240 a Unsolicited MN-FA Key Material From AAA extension, and thus does 241 not have a way to establish a Mobility Security Association with 242 the mobile node, the foreign agent MAY change the Code value of the 243 Registration Reply to MISSING_MN_FA (see section 8), effectively 244 causing the registration to fail. 246 5. Unsolicited MN-HA Key Material From AAA Subtype 248 The Unsolicited MN-HA Key Material From AAA is subtype 1 of the 249 Generalized MN-HA Key Reply Extension [11]. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Lifetime | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | AAA SPI | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | HA SPI | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Algorithm Identifier | Replay Method | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Key Material ... 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2: The Unsolicited MN-HA Key Material From AAA 266 Subtype-Specific Data 268 lifetime This field indicates the duration of time (in seconds) 269 for which the MN-HA key is valid. 271 AAA SPI A 32-bit opaque value, indicating the SPI that the 272 mobile node must use to determine the algorithm to use 273 for establishing the HA security information. 275 HA SPI A 32-bit opaque value, which the mobile node MUST use 276 to index all the necessary information established for 277 the HA security information after it is decoded. 279 Algorithm Identifier 280 This field indicates the algorithm to be used for 281 future computations of the MN-HA Authentication 282 Extension (see section 2) 284 Replay Method 285 This field contains the replay method to be used for 286 future Registration messages (see section 2). 288 Key Material 289 A random [4] value of at least 64 bits. 291 The Unsolicited MN-HA Material Key From AAA subtype-specific data 292 is shown in figure 2. The Mobile Node creates the MN-HA key using 293 the Key Material provided by the home domain AAA server (AAAH). The 294 key is intended for use the mobile node to secure future Mobile IP 295 registrations with its home agent. The MN-HA Key Reply MUST appear 296 in the Registration Reply before the MN-HA Authentication extension. 298 Once the mobile node creates the MN-HA Key, by using the algorithm 299 specified in the AAA SPI, it stores the HA Security Information 300 indexed by the HA SPI in its list of Mobile Security Associations. 301 The mobile node uses the Identification field data from the 302 Registration Request as its initial synchronization data with the 303 home agent. 305 6. MN-FA Key Request From AAA Subtype 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | FA SPI | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 3: The MN-FA Key Request From AAA Subtype-Specific Data 315 FA SPI A 32-bit opaque value, which the mobile node proposes 316 for use with the foreign agent to identify the security 317 association determined by the granted key, and to index 318 all the necessary information to be used as part of the 319 security association. 321 The MN-FA Key Request From AAA subtype data, shown in figure 3, uses 322 subtype 7 of the Generalized MN-FA Key Request Extension [11]. The 323 MN-FA Key Request From AAA extension MUST appear in the Registration 324 Request before the MN-AAA Authentication extension. 326 7. MN-HA Key Request From AAA Subtype 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | HA SPI | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 4: The MN-HA Key Request From AAA Subtype-Specific Data 336 HA SPI A 32-bit opaque value, which the mobile node proposes 337 for use with the home agent to identify the security 338 association determined by the granted key, and to index 339 all the necessary information to be used as part of the 340 security association. 342 The MN-HA Key Request From AAA subtype data, shown in figure 4, uses 343 subtype 7 of the Generalized MN-HA Key Request Extension [11]. The 344 MN-HA Key Request From AAA extension MUST appear in the Registration 345 Request before the MN-AAA Authentication extension. 347 8. Error Values 349 Each entry in the following table contains the name of Code [10] to 350 be returned in a Registration Reply, the value for the Code, and the 351 section in which the error is first mentioned in this specification. 353 Error Name Value Section 354 ---------------------- ----- --------- 355 MISSING_MN_FA 107 4 357 9. IANA Considerations 359 The number for the Generalized MN-HA Key Reply Extension is 360 taken from the numbering space defined for Mobile IP registration 361 extensions defined in RFC 2002 [10] as extended in RFC 2356 [7]. 363 The subtype address space for the Generalized MN-HA Key Reply 364 extension is defined in this document. From this space, subtype 365 value 1 is assigned to the Unsolicited MN-HA Key Material From AAA 366 Subtype extension. 368 The number assigned to the MN-FA Key Request From AAA Subtype 369 extension was taken from the numbering space defined for the 370 Generalized MN-FA Key Request Extension, defined in [12]. 372 The number assigned to the Unsolicited MN-FA Key Material From AAA 373 Subtype extension was taken from the numbering space defined for the 374 Generalized MN-FA Key Reply Extension, defined in [12]. 376 The number assigned to the MN-HA Key Request From AAA Subtype 377 extension was taken from the numbering space defined for the 378 Generalized MN-HA Key Request Extension, defined in [12]. 380 The Code values specified for errors, listed in section 8, MUST NOT 381 conflict with any other code values listed in RFC 2002, RFC 3024 [6], 382 or RFC 2356 [7]. They are to be taken from the space of error values 383 conventionally associated with rejection by the foreign agent (i.e., 384 64-127). 386 Section 2 introduces the Algorithm Identifier namespace that requires 387 IANA management. This specification makes use of 1-3, and all other 388 values other than zero (0) are available for assignment via Standards 389 Action [8]. 391 Section 2 introduces the Replay Method Identifier namespace that 392 requires IANA management. This specification makes use of 1-3, and 393 all other values other than zero (0) are available for assignment via 394 Standards Action [8]. 396 10. Security Considerations 398 The extensions in this document are intended to provide the 399 appropriate level of security for Mobile IP entities (mobile node, 400 foreign agent, and home agent) to operate Mobile IP registration 401 protocol. The security associations resulting from use of these 402 extensions do not offer any higher level of security than what is 403 already implicit in use of the security association between the 404 mobile node and the AAA. 406 Since the extensions defined in this specification only carries Key 407 Material, which is used to derive keys, it does not expose any data 408 that could be used in an attack aimed at recovering the key shared 409 between the mobile node and the AAA. The authors do not believe this 410 specification introduces new security risks. 412 References 414 [1] B. Aboba and M. Beadles. The Network Access Identifier. 415 Request for Comments (Proposed Standard) 2486, Internet 416 Engineering Task Force, January 1999. 418 [2] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 419 Challenge/Response Extension. Request for Comments (Proposed 420 Standard) 3012, Internet Engineering Task Force, December 2000. 422 [3] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER 423 Base Protocol (work in progress). Internet Draft, Internet 424 Engineering Task Force. 425 draft-ietf-aaa-diameter-03.txt, May 2001. 427 [4] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 428 Recommendations for Security. Request for Comments 429 (Informational) 1750, Internet Engineering Task Force, December 430 1994. 432 [5] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 433 for Message Authentication. Request for Comments 434 (Informational) 2104, Internet Engineering Task Force, 435 February 1997. 437 [6] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised. 438 Request for Comments (Proposed Standard) 3024, Internet 439 Engineering Task Force, January 2001. 441 [7] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 442 Mobile IP. Request for Comments (Informational) 2356, Internet 443 Engineering Task Force, June 1998. 445 [8] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 446 Considerations Section in RFCs. Request for Comments (Best 447 Current Practice) 2434, Internet Engineering Task Force, October 448 1998. 450 [9] National Institute of Standards and Technology. Secure Hash 451 Standard. Technical Report NIST FIPS PUB 180-1, U.S. Department 452 of Commerce, April 1995. 454 [10] C. Perkins. IP Mobility Support. Request for Comments 455 (Proposed Standard) 2002, Internet Engineering Task Force, 456 October 1996. 458 [11] C. Perkins and P. Calhoun. Generalized Key Distribution 459 Extensions for Mobile IP (work in progress). 460 draft-ietf-mobileip-gen-key-02.txt, March 2001. 462 [12] C. Perkins and D. Johnson. Registration Keys for Route 463 Optimization (work in progress). Internet Draft, Internet 464 Engineering Task Force, December 1997. 466 [13] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 467 Authentication Dial In User Service (RADIUS). Request for 468 Comments (Proposed Standard) 2865, Internet Engineering Task 469 Force, June 2000. 471 Addresses 473 The working group can be contacted via the current chairs: 475 Basavaraj Patil Phil Roberts 476 Nokia Megisto Corp. 477 6000 Connection Dr. Suite 120 478 20251 Century Blvd 479 Irving, TX. 75039 Germantown MD 20874 480 USA USA 481 Phone: +1 972-894-6709 Phone: +1 847-202-9314 482 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com 484 Questions about this memo can also be directed to the authors: 486 Charles E. Perkins Pat R. Calhoun 487 Communications Systems Lab Network & Security Center 488 Nokia Research Center Sun Microsystems Laboratories 489 313 Fairchild Drive 15 Network Circle 490 Mountain View, California 94043 Menlo Park, California 94025 491 USA USA 492 Phone: +1-650 625-2986 Phone: +1 650-786-7733 493 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 494 Fax: +1 650 625-2502 Fax: +1 650-786-6445