idnits 2.17.1 draft-ietf-mip4-rfc3012bis-00.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 abstract seems to contain references ([7], [10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document obsoletes RFC3012, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document updates RFC3344, but the header doesn't have an 'Updates:' line to match this. 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 3012 (ref. '3') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 1750 (ref. '5') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2138 (ref. '8') (Obsoleted by RFC 2865) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '9') Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 5 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 17 October 2003 Pat R. Calhoun 4 Black Storm Networks 5 Jayshree Bharatia 6 Nortel Networks 8 Mobile IPv4 Challenge/Response Extensions (revised) 9 draft-ietf-mip4-rfc3012bis-00.txt 11 Status of This Memo 13 This document is a submission by the mobile-ip Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the mobile-ip@sunroof.eng.sun.com mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Mobile IP, as originally specified, defines an authentication 38 extension (the Mobile-Foreign Authentication extension) by 39 which a mobile node can authenticate itself to a foreign agent. 40 Unfortunately, that extension does not provide the foreign agent any 41 direct guarantee that the protocol is protected from replays, and 42 does not allow for the use of existing techniques (such as CHAP [10]) 43 for authenticating portable computer devices. 45 In this specification, we define extensions for the Mobile IP Agent 46 Advertisements and the Registration Request that allow a foreign 47 agent to use a challenge/response mechanism to authenticate the 48 mobile node. 50 Furthermore, this document updates RFC 3344 [7] by including new 51 authentication extension called the Mobile-AAA Authentication 52 extension. This new extension is provided so that a mobile node 53 can supply credentials for authorization using commonly available 54 AAA infrastructure elements. This Authorization-enabling extension 55 MAY co-exist in the same Registration Request with Authentication 56 extensions defined for Mobile IP Registration by [7]. This document 57 obsoletes RFC 3012. 59 Contents 61 Status of This Memo i 63 Abstract i 65 1. Introduction 1 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 1 68 2. Mobile IP Agent Advertisement Challenge Extension 3 69 2.1. Handling of Solicited Agent Advertisements . . . . . . . 3 71 3. Operation 4 72 3.1. Mobile Node Processing for Registration Requests . . . . 4 73 3.2. Foreign Agent Processing for Registration Requests . . . 5 74 3.3. Foreign Agent Processing for Registration Replies . . . . 7 75 3.4. Home Agent Processing for the Challenge Extensions . . . 8 76 3.5. Mobile Node Processing for Registration Replies . . . . . 9 78 4. Mobile-Foreign Challenge Extension 11 80 5. Generalized Mobile IP Authentication Extension 11 82 6. Mobile-AAA Authentication subtype 12 84 7. Reserved SPIs for Mobile IP 13 86 8. SPIs for RADIUS AAA Servers 13 88 9. Configurable Parameters 15 90 10. Error Values 15 92 11. IANA Considerations 15 94 12. Security Considerations 16 96 13. Acknowledgments 16 98 A. Change History 18 100 B. Verification Infrastructure 19 102 C. Message Flow for FA Challenge Messaging with Mobile-AAA Extension 21 104 D. Message Flow for FA Challenge Messaging with MN-FA Authentication 22 105 E. Foreign Agent Algorithm for Tracking Used Challenges 23 107 Addresses 25 109 1. Introduction 111 Mobile IP defines the Mobile-Foreign Authentication extension to 112 allow a mobile node to authenticate itself to a foreign agent. Such 113 authentication mechanisms are mostly external to the principal 114 operation of Mobile IP, since the foreign agent can easily route 115 packets to and from a mobile node whether or not the mobile node is 116 reporting a legitimately owned home address to the foreign agent. 117 Unfortunately, that extension does not provide the foreign agent any 118 direct guarantee that the protocol is protected from replays, and 119 does not allow for the use of CHAP [10] for authenticating portable 120 computer devices. In this specification, we define extensions for 121 the Mobile IP Agent Advertisements and the Registration Request 122 that allow a foreign agent to a use challenge/response mechanism 123 to authenticate the mobile node. Furthermore, an additional 124 authentication extension, the Mobile-AAA authentication extension, 125 is provided so that a mobile node can supply credentials for 126 authorization using commonly available AAA infrastructure elements. 127 The foreign agent may be able to interact with an AAA infrastructure 128 (using protocols outside the scope of this document) to obtain a 129 secure indication that the mobile node is authorized to use the local 130 network resources. 132 1.1. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [1]. 138 This document uses the term Security Parameters Index (SPI) as 139 defined in the base Mobile IP protocol specification [7]. All SPI 140 values defined in this document refer to values for the SPI as 141 defined in that specification. 143 The following additional terminology is used in addition to that 144 defined in [7]: 146 previously used challenge 147 The challenge is previously used challenge if the mobile 148 node sent the same challenge to the foreign agent in 149 a previous Registration Request, and that previous 150 Registration Request passed all validity checks performed 151 by the foreign agent. The Foreign Agent may not be able 152 to keep records for all previously used challenges, but 153 see section 3.2 for minimal requirements. 155 security association 156 A "mobility security association", as defined in [7]. 158 unknown challenge 159 Any challenge from a particular mobile node that the 160 foreign agent has no record of having put either into one 161 of its recent Agent Advertisements or into a registration 162 reply message to that mobile node. 164 unused challenge 165 A challenge that has not been already accepted by the 166 Foreign Agent from the mobile node in the Registration 167 Request -- i.e., a challenge that is neither unknown nor 168 previously used. 170 2. Mobile IP Agent Advertisement Challenge Extension 172 This section defines a new extension to the Router Discovery 173 Protocol [4] for use by foreign agents that need to issue a challenge 174 for authenticating mobile nodes. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Length | Challenge ... 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 1: The Challenge Extension 184 Type 24 186 Length The length of the Challenge value in bytes; SHOULD be 187 at least 4 189 Challenge A random value that SHOULD be at least 32 bits. 191 The Challenge extension, illustrated in figure 1, is inserted in the 192 Agent Advertisements by the foreign agent, in order to communicate 193 a previously unused challenge value that can be used by the mobile 194 node to compute an authentication for its next registration request 195 message. The challenge is selected by the foreign agent to provide 196 local assurance that the mobile node is not replaying any earlier 197 registration request. Eastlake, et al. [5] provides more information 198 on generating pseudo-random numbers suitable for use as values for 199 the challenge. 201 Note that the storage of different Challenges received in Agent 202 Advertisements from multiple foreign agents is implementation 203 specific and hence, out of scope for this specification. 205 2.1. Handling of Solicited Agent Advertisements 207 When a foreign agent generates an Agent Advertisement in response 208 to a Router Solicitation [4], some additional considerations come 209 into play. According to the Mobile IP base specification [7], the 210 resulting Agent Advertisement may be either multicast or unicast. 212 If the solicited Agent Advertisement is multicast, it MUST NOT 213 generate a new Challenge value and update its window of remembered 214 advertised Challenges. It must instead re-use the most recent of the 215 CHALLENGE_WINDOW Advertisement Challenge values. 217 If the agent advertisement is unicast back to the soliciting mobile 218 node, it MUST be handled as follows: If the challenge most recently 219 unicast to the soliciting mobile node has not been previously used 220 (as defined in Section 1.1), it SHOULD be repeated in the newly 221 issued unicast agent advertisement, otherwise a new challenge MUST be 222 generated and remembered as the most recent challenge issued to the 223 mobile node. (For further discussion of this, see Section 12.) 225 3. Operation 227 This section describes modifications to the Mobile IP registration 228 process [7] which may occur after the foreign agent issues a Mobile 229 IP Agent Advertisement containing the Challenge on its local link. 230 See appendix C for a diagram showing the canonical message flow for 231 messages related to the processing of the foreign agent challenge 232 values. 234 3.1. Mobile Node Processing for Registration Requests 236 Retransmission behavior for Registration Requests is identical to 237 that specified in Mobile IP specification [7]. A retransmitted 238 Registration Request MAY use the same Challenge value as given in the 239 original Registration Request. 241 Whenever the Agent Advertisement contains the Challenge extension, if 242 the mobile node does not have a security association with the foreign 243 agent, then it MUST include the Challenge value in a Mobile-Foreign 244 Challenge extension to the Registration Request message. If, on 245 the other hand, the mobile node does have a security association 246 with the foreign agent, it SHOULD include the Challenge value in its 247 Registration Request message. 249 If the mobile node has a security association with the Foreign 250 Agent, it MUST include a Mobile-Foreign Authentication extension 251 in its Registration Request message, according to the base Mobile 252 IP specification [7]. When the Registration Request contains the 253 Mobile-Foreign Challenge extension specified in section 4, the 254 Mobile-Foreign Authentication MUST follow the Challenge extension 255 in the Registration Request. The mobile node MAY also include the 256 Mobile-AAA Authentication extension. If both, the Mobile-Foreign 257 Authentication and the Mobile-AAA Authentication extensions are 258 present, the Mobile-Foreign Challenge extension MUST precede the 259 Mobile-AAA Authentication extension and the Mobile-AAA Authentication 260 extension MUST precede the Mobile-Foreign Authentication extension. 262 If the mobile node does not have a security association with 263 the foreign agent, the mobile node MUST include the Mobile-AAA 264 Authentication extension as defined in section 6 when it includes the 265 Mobile-Foreign Challenge extension. In addition, the mobile node 266 SHOULD include the NAI extension [2], to enable the foreign agent 267 to make use of available verification infrastructure which requires 268 this. The SPI field of the Mobile-AAA Authentication extension 269 specifies the particular secret and algorithm (shared between 270 the mobile node and the verification infrastructure) that must be 271 used to perform the authentication. If the SPI value is chosen as 272 CHAP_SPI or HMAC_CHAP_SPI (see section 9), then the mobile node 273 specifies CHAP-style authentication [10] using MD5 [9] or HMAC_MD5, 274 respectively. 276 In either case, the Mobile-Foreign Challenge extension followed by 277 one of the above specified authentication extensions MUST follow the 278 Mobile-Home Authentication extension, if present. 280 A mobile node MAY include the Mobile-AAA Authentication extension in 281 the Registration Request when the mobile node registers directly with 282 its Home Agent (using a co-located care-of address). In this case, 283 if the mobile node uses an SPI value of CHAP_SPI or HMAC_CHAP_SPI 284 (section 8) in the MN-AAA Authentication extension, the mobile node 285 MUST include the Mobile-Foreign Challenge extension prior to the 286 Mobile-AAA Authentication extension. The mechanism used by the 287 mobile node to obtain the Challenge value in this case is outside the 288 scope of this document. 290 3.2. Foreign Agent Processing for Registration Requests 292 Upon receipt of the Registration Request, if the foreign agent has 293 issued a Challenge as part of its Agent Advertisements, and it 294 does not have a security association with the mobile node, then 295 the Foreign Agent SHOULD check that the Mobile-Foreign Challenge 296 extension exists, and that it contains a challenge value previously 297 unused by the Mobile Node. This ensures that the mobile node is not 298 attempting to replay a previous advertisement and authentication. In 299 this case, if the Registration Request does not include a challenge 300 extension, the Foreign Agent MUST send a Registration Reply to the 301 mobile node with the Code value MISSING_CHALLENGE. 303 A foreign agent that sends Agent Advertisements containing a 304 Challenge value MAY send a Registration Reply message with a 305 MISSING_CHALLENGE error if the mobile node sends a Registration 306 Request with a Mobile-Foreign Authentication extension without 307 including a Challenge. In other words, such a foreign agent MAY 308 refuse to process a Registration Request from the mobile node unless 309 the request contains an unused Challenge. 311 If a mobile node retransmits a Registration Request with the same 312 Challenge extension, and the foreign agent still has a pending 313 Registration Request record in effect for the mobile node, then 314 the foreign agent forwards the Registration Request to the Home 315 Agent again. The foreign agent SHOULD check that the mobile node is 316 actually performing a retransmission, by verifying that the relevant 317 fields of the retransmitted request (including, if present, the 318 mobile node NAI Extension [2]) are the same as represented in the 319 visitor list entry for the pending Registration Request (section 320 3.7.1 of [7]). This verification MUST NOT include the "remaining 321 Lifetime of the pending registration", or the Identification field 322 since those values are likely to change even for requests that are 323 merely retransmissions and not new Registration Requests. In all 324 other circumstances, if the foreign agent receives a Registration 325 Request with a Challenge extension containing a Challenge value 326 previously used by that mobile node, the Foreign Agent SHOULD send 327 a Registration Reply to the mobile node containing the Code value 328 STALE_CHALLENGE. 330 The foreign agent MUST NOT accept any Challenge in the Registration 331 Request unless it was offered in the last Registration Reply 332 or unicast Agent Advertisement sent to the mobile node, or else 333 advertised as one of the last CHALLENGE_WINDOW (see section 9) 334 Challenge values inserted into the immediately preceding Agent 335 advertisements. If the Challenge is not one of the recently 336 advertised values, the foreign Agent SHOULD send a Registration Reply 337 with Code value UNKNOWN_CHALLENGE (see section 10). The foreign 338 agent MUST maintain the last challenge used by each Mobile Node that 339 has registered using any one of the last CHALLENGE_WINDOW challenge 340 values. This last challenge value can be stored as part of the 341 mobile node's registration records. Also, see appendix E for a 342 possible algorithm that can be used to satisfy this requirement. 344 Furthermore, the foreign agent MUST check that there is either a 345 Mobile-Foreign, or a Mobile-AAA Authentication extension after 346 the Challenge extension. Any registration message containing 347 the Challenge extension without either of these authentication 348 extensions MUST be silently discarded. If the registration 349 message contains a Mobile-Foreign Authentication extension with an 350 incorrect authenticator that fails verification, the foreign agent 351 MAY send a Registration Reply to the mobile node with Code value 352 BAD_AUTHENTICATION (see Section 10). 354 If the Mobile-AAA Authentication extension (see Section 6) is present 355 in the message, or if an NAI extension is included indicating that 356 the mobile node belongs to a different administrative domain, the 357 foreign agent may take actions outside the scope of this protocol 358 specification to carry out the authentication of the mobile node. 359 If the registration message contains a Mobile-AAA Authentication 360 extension with an incorrect authenticator that fails verification, 361 the foreign agent MAY send a Registration Reply to the mobile node 362 with Code value FA_BAD_AAA_AUTH. If the Mobile-AAA Authentication 363 Extension is present in the Registration Request, the foreign agent 364 MUST NOT remove the Mobile-AAA Authentication Extension and the 365 Mobile-Foreign Challenge Extension from the Registration Request. 366 Appendix C provides an example of an action that could be taken by a 367 foreign agent. 369 In the event that the Challenge extension is authenticated through 370 the Mobile-Foreign Authentication extension and the Mobile-AAA 371 Authentication extension is not present, the foreign agent MAY 372 remove the Challenge Extension from the Registration Request without 373 disturbing the authentication value computed by the mobile node for 374 use by the AAA or the home agent. If the Mobile-AAA Authentication 375 extension is present and a security association exists between the 376 foreign agent and the home agent, the Mobile-Foreign Challenge 377 extension and the Mobile-AAA Authentication extension MUST precede 378 the Foreign-Home Authentication extension. 380 If the foreign agent does not remove the Challenge extension, then 381 the foreign agent SHOULD store the Challenge value as part of the 382 pending registration request list [7]. Also, if the Registration 383 Reply coming from the home agent does not include the Challenge 384 Extension, the foreign agent SHOULD NOT reject the Registration 385 Request message. If the Challenge Extension is present in the 386 Registration Reply, it MUST be the same Challenge value that was 387 included in the Registration Request. If the Challenge value differs 388 in the Registration Reply received from the home agent, the foreign 389 agent MUST reject the Registration Request and change the status 390 in the Registration Reply to the Code value MISSING_CHALLENGE (see 391 section 10). 393 If the foreign agent does remove the Challenge extension and 394 applicable authentication from the Registration Request message, 395 then it SHOULD insert the Identification field from the Registration 396 Request message along with its record-keeping information about the 397 particular mobile node in order to protect against replays. 399 3.3. Foreign Agent Processing for Registration Replies 401 The foreign agent SHOULD include a new Mobile-Foreign Challenge 402 Extension in any Registration Reply, successful or not. If the 403 foreign agent includes this extension in a successful Registration 404 Reply, the extension SHOULD precede a Mobile-Foreign authentication 405 extension if present. Suppose the Registration Reply includes a 406 Challenge extension from the home agent, and the foreign agent 407 wishes to include another Challenge extension with the Registration 408 Reply for use by the mobile node. In that case, the foreign agent 409 MUST delete the Challenge extension from the home agent from the 410 Registration Reply, along with any Foreign-Home authentication 411 extension, before appending the new Challenge extension to the 412 Registration Reply. 414 One example of a situation where the foreign agent MAY omit the 415 inclusion of a Mobile-Foreign Challenge Extension in the Registration 416 Reply would be when a new challenge has been multicast recently. 418 If a foreign agent has conditions in which it omits the inclusion 419 of a Mobile-Foreign Challenge Extension in the Registration Reply, 420 it still MUST respond with an agent advertisement containing a 421 previously unused challenge in response to a subsequent agent 422 solicitation from the same mobile node. Otherwise (when the said 423 conditions are not met) the foreign agent MUST include a previously 424 unused challenge in any Registration Reply, successful or not. 426 A mobile node MUST be prepared to use a challenge from a unicast 427 or multicast Agent Advertisement in lieu of one returned in a 428 Registration Reply, and MUST solicit for one if it has not already 429 received one in a Registration Reply. 431 If the foreign agent receives a Registration Reply with the Code 432 value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node. 434 3.4. Home Agent Processing for the Challenge Extensions 436 If the home agent receives a Registration Request with the 437 Mobile-Foreign Challenge extension, and recognizes the extension, the 438 home agent MUST include the Challenge extension in the Registration 439 Reply. The Challenge Extension MUST be placed after the Mobile-Home 440 authentication extension, and the extension SHOULD be authenticated 441 by a Foreign-Home Authentication extension. 443 The home agent MAY receive a Registration Request with the Mobile-AAA 444 Authentication extension. If the Mobile-AAA Authentication extension 445 is used by the home agent as an authorization-enabling extension 446 and the verification fails due to incorrect authenticator, the 447 home agent MAY reject the Registration Reply with the error code 448 HA_BAD_AAA_AUTH. 450 Since the extension type for the Challenge extension is within the 451 range 128-255, the home agent MUST process such a Registration 452 Request even if it does not recognize the Challenge extension [7]. 453 In this case, the home agent will send a Registration Reply to the 454 foreign agent that does not include the Challenge extension. 456 3.5. Mobile Node Processing for Registration Replies 458 A mobile node might receive the following error codes in the 459 Registration Reply from the foreign agent as a response to the 460 Registration Request. The error codes are defined in section 10. 462 UNKNOWN_CHALLENGE: This error code is received by the mobile node in 463 the case where the mobile node has moved to a new foreign agent that 464 cannot validate the challenge provided in the Registration Request. 465 In such instances, the mobile node MUST use a new Challenge value in 466 any new registration, obtained either from an Agent Advertisement, or 467 from a Challenge extension to the Registration Reply containing the 468 error. 470 MISSING_CHALLENGE: A mobile node that does not include a Challenge 471 when the Mobile-Foreign Authentication extension is present may 472 receive a MISSING_CHALLENGE error. In this case, the mobile node 473 SHOULD send a Challenge extension containing an unused challenge in 474 the next Registration Request. 476 BAD_AUTHENTICATION: This error is sent by the foreign agent if 477 the Registration Request contains a Mobile-Foreign Authentication 478 extension with an incorrect authenticator that fails verification. 479 A mobile node that receives a BAD_AUTHENTICATION Code value 480 SHOULD include the Mobile-AAA Authentication Extension in the next 481 Registration Request. This will make it possible for the Foreign 482 Agent to use its AAA infrastructure in order to authenticate the 483 Mobile Node. In this case, the mobile node MUST use a new Challenge 484 value in any new registration, obtained either from an Agent 485 Advertisement, or from a Challenge extension to the Registration 486 Reply containing the error. 488 FA_BAD_AAA_AUTH: This error is sent by the Foreign Agent if the 489 Registration Request contains a Mobile-AAA Authentication extension 490 with an incorrect authenticator that fails verification. A mobile 491 node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value 492 in any new registration, obtained either from an Agent Advertisement, 493 or from a Challenge extension to the Registration Reply containing 494 the error. 496 HA_BAD_AAA_AUTH: This error is sent by the Home Agent if the 497 Registration Request contains a Mobile-AAA Authentication extension 498 with an incorrect authenticator that fails verification. A mobile 499 node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value 500 in any new registration, obtained either from an Agent Advertisement, 501 or from a Challenge extension to the Registration Reply containing 502 the error. 504 STALE_CHALLENGE: If the foreign agent receives a Registration 505 Request with a Challenge extension containing a Challenge value 506 previously used by that mobile node, the mobile node MAY receive 507 a Registration Reply to the mobile node containing the Code value 508 STALE_CHALLENGE. In such instances, the mobile node MUST use a 509 new Challenge value in next Registration Request, obtained either 510 from an Agent Advertisement, or from a Challenge extension to the 511 Registration Reply containing the error. 513 4. Mobile-Foreign Challenge Extension 515 This section specifies a new Mobile IP Registration extension that is 516 used to satisfy a Challenge in an Agent Advertisement. The Challenge 517 extension to the Registration Request message is used to indicate the 518 challenge that the mobile node is attempting to satisfy. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type | Length | Challenge... 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Figure 2: The Mobile-Foreign Challenge Extension 528 Type 132 (skippable) (see [7]) 530 Length Length of the Challenge value 532 Challenge The Challenge field is copied from the Challenge field 533 found in the Agent Advertisement Challenge extension 534 (see section 2). 536 Suppose the mobile node has successfully registered using one of the 537 Challenge Values within the CHALLENGE_WINDOW values advertised by the 538 foreign agent. In that case, in any new Registration Request the 539 mobile node MUST NOT use any Challenge Value which was advertised by 540 the foreign agent before the Challenge Value in the mobile node's 541 last Registration Request. 543 5. Generalized Mobile IP Authentication Extension 545 Several new authentication extensions have been designed for 546 various control messages proposed for extensions to Mobile IP. A new 547 authentication extension is required for a mobile node to present its 548 credentials to any other entity other than the ones already defined; 549 the only entities defined in the base Mobile IP specification [7] 550 are the home agent and the foreign agent. It is the purpose of the 551 generalized authentication extension defined here to collect together 552 data for all such new authentication applications into a single 553 extension type with subtypes. 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type | Subtype | Length | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | SPI | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Authenticator ... 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Figure 3: The Generalized Mobile IP Authentication Extension 567 Type 36 (not skippable) (see [7]) 569 Subtype a number assigned to identify the kind of 570 endpoints or other characteristics of the 571 particular authentication strategy 573 Length 4 plus the number of bytes in the Authenticator; 574 MUST be at least 20. 576 SPI Security Parameters Index 578 Authenticator The variable length Authenticator field 580 In this document, only one subtype is defined: 582 1 Mobile-AAA Authentication subtype (see section 6) 584 6. Mobile-AAA Authentication subtype 586 The Generalized Authentication extension with subtype 1 will be 587 referred to as a Mobile-AAA Authentication extension. The mobile 588 node MAY include a Mobile-AAA Authentication extension in any 589 Registration Request. This extension MAY co-exist in the same 590 Registration Request with Authentication extensions defined for 591 Mobile IP Registration by [7]. If the mobile node does not include a 592 Mobile-Foreign Authentication [7] extension, then it MUST include the 593 Mobile-AAA Authentication extension whenever the Challenge extension 594 is present. If both are present, the Mobile-AAA Authentication 595 extension MUST precede the Mobile-Foreign Authentication extension. 597 If the Mobile-AAA Authentication extension is present, then the 598 Registration Message sent by the mobile node MUST contain the 599 Mobile-Home Authentication extension [7] if it shares a security 600 association with the home agent. If both are present, the 601 Mobile-Home Authentication Extension MUST appear prior to the 602 Mobile-AAA Authentication extension. The corresponding response 603 MUST include the Mobile-Home Authentication Extension, and MUST NOT 604 include the Mobile-AAA Authentication Extension. 606 The default algorithm for computation of the authenticator is 607 HMAC-MD5 [6] computed on the following data, in the order shown: 609 Preceding Mobile IP data || Type, Subtype, Length, SPI 611 where the Type, Length, Subtype, and SPI are as shown in section 5. 612 The resulting function call, as described in [6], would be: 614 hmac_md5(data, datalen, Key, KeyLength, authenticator); 616 Each mobile node MUST support the ability to produce the 617 authenticator by using HMAC-MD5 as shown. Just as with Mobile IP, 618 it must be possible to configure the use of any arbitrary 32-bit SPI 619 outside of the SPIs in the reserved range 0-255 for selection of this 620 default algorithm. 622 7. Reserved SPIs for Mobile IP 624 Mobile IP defines several authentication extensions for use in 625 Registration Requests and Replies. Each authentication extension 626 carries a Security Parameters Index (SPI) which should be used to 627 index a table of security associations. Values in the range 0 - 255 628 are reserved for special use. A list of reserved SPI numbers is to 629 be maintained by IANA at the following URL: 631 http://www.iana.org/numbers.html 633 8. SPIs for RADIUS AAA Servers 635 Some AAA servers only admit a single security association, and thus 636 do not use the SPI numbers for Mobile IP authentication extensions 637 for use when determining the security association that would be 638 necessary for verifying the authentication information included with 639 the Authentication extension. 641 SPI numbers CHAP_SPI and HMAC_CHAP_SPI (see section 9) are reserved 642 for indicating the following procedure for computing authentication 643 data (called the "authenticator"), which is used by many RADIUS 644 servers [8] today. 646 To compute the authenticator, apply MD5 [9] computed on the following 647 data, in the order shown: 649 High-order byte from Challenge || Key || 650 MD5(Preceding Mobile IP data || 651 Type, Subtype (if present), Length, SPI) || 652 Least-order 237 bytes from Challenge 654 where the Type, Length, SPI, and possibly Subtype, are the fields 655 of the authentication extension in use. For instance, all four of 656 these fields would be in use when SPI == (CHAP_SPI or HMAC_CHAP_SPI) 657 is used with the Generalized Authentication extension. The use 658 of SPI number HMAC_CHAP_SPI indicates the use of HMAC_MD5 instead 659 of MD5 in the above procedure. Since the RADIUS protocol cannot 660 carry attributes of length greater than 253, the preceding Mobile IP 661 data, type, subtype (if present), length and SPI are hashed using 662 MD5. Finally, the least significant 237 bytes of the challenge 663 are concatenated. If the challenge has fewer than 238 bytes, this 664 algorithm includes the high-order byte in the computation twice, but 665 ensures that the challenge is used exactly as is. Additional padding 666 is never used to increase the length of the challenge; the input data 667 is allowed to be shorter than 237 bytes long. 669 9. Configurable Parameters 671 Every Mobile IP agent supporting the extensions defined in this 672 document SHOULD be able to configure each parameter in the following 673 table. Each table entry contains the name of the parameter, the 674 default value, and the section of the document in which the parameter 675 first appears. 677 Parameter Name Default Value Section(s) of Document 678 -------------- ------------- ---------------------- 679 CHALLENGE_WINDOW 2 3.2 680 CHAP_SPI 2 8 681 HMAC_CHAP_SPI 3 8 683 Note that CHALLENGE_WINDOW SHOULD be at least 2. This makes it far 684 less likely that mobile nodes will register using a Challenge value 685 that is outside the set of values allowable by the foreign agent. 687 10. Error Values 689 Each entry in the following table contains the name of the Code [7] 690 to be returned in a Registration Reply, the value for the Code, 691 and the section in which the error is first mentioned in this 692 specification. 693 Error Name Value Section of Document 694 --------------------------- ------------------- 695 UNKNOWN_CHALLENGE 104 3.2 696 BAD_AUTHENTICATION67 3.2 - also see [7] 697 MISSING_CHALLENGE 105 3.1,3.2 698 STALE_CHALLENGE 106 3.2 699 FA_BAD_AAA_AUTH TBD 3.2 700 HA_BAD_AAA_AUTH TBD 3.4 702 11. IANA Considerations 704 All protocol values in this specification are to be the same as 705 defined in RFC 3012 [3]. Additionaly, new Code values are defined by 706 this document for FA_BAD_AAA_AUTH 707 and HA_BAD_AAA_AUTH. 709 12. Security Considerations 711 In the event that a malicious mobile node attempts to replay the 712 authenticator for an old Mobile-Foreign Challenge, the Foreign 713 Agent would detect it since the agent always checks whether it has 714 recently advertised the Challenge (see section 3.2). Allowing mobile 715 nodes with different IP addresses or NAIs to use the same Challenge 716 value does not represent a security vulnerability, because the 717 authentication data provided by the mobile node will be computed over 718 data that is different (at least by the bytes of the mobile nodes' IP 719 addresses). 721 If the foreign agent chooses a Challenge value (see section 2) with 722 fewer than 4 bytes, the foreign agent SHOULD include the value of 723 the Identification field in the records it maintains for the mobile 724 node. The foreign agent can then determine whether the Registration 725 messages using the short Challenge value are in fact unique, and thus 726 assuredly not replayed from any earlier registration. 728 Section 8 (SPI For RADIUS AAA Servers) defines a method of computing 729 the Generalized Mobile IP Authentication Extension's authenticator 730 field using MD5 in a manner that is consistent with RADIUS [8]. The 731 use of MD5 in the method described in Section 8 is less secure than 732 HMAC-MD5 [6], and should be avoided whenever possible. 734 Note that an active attacker may try to prevent successful 735 registrations by sending a large number of Agent Solicitations or 736 bogus Registration Requests, each of which could cause the FA to 737 respond with a fresh challenge, invalidating the challenge that the 738 MN is currently trying to use. To prevent such attacks, the FA 739 MUST NOT invalidate previously unused challenges when responding to 740 unauthenticated Registration Requests or Agent Solicitations. In 741 addition, the FA MUST NOT allocate new storage when responding to 742 such messages, because this would also create the possibility of 743 denial of service. 745 13. Acknowledgments 747 The authors would like to thank Tom Hiller, Mark Munson, the 748 TIA TR45-6 WG, Gabriel Montenegro, Vipul Gupta, Pete McCann, 749 Robert Marks, Ahmad Muhanna, and Luca Salgarelli for their useful 750 discussions. A recent draft by Mohamed Khalil, Raja Narayanan, Emad 751 Qaddoura, and Haseeb Akhtar has also suggested the definition of a 752 generalized authentication extension similar to the specification 753 contained in section 5. 755 References 757 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 758 Levels. Request for Comments (Best Current Practice) 2119, 759 Internet Engineering Task Force, March 1997. 761 [2] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier 762 Extension for IPv4. Request for Comments (Proposed Standard) 763 2794, Internet Engineering Task Force, January 2000. 765 [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 766 Challenge/Response Extension. Request for Comments (Proposed 767 Standard) 3012, Internet Engineering Task Force, December 2000. 769 [4] S. Deering. ICMP Router Discovery Messages. Request for 770 Comments (Proposed Standard) 1256, Internet Engineering Task 771 Force, September 1991. 773 [5] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 774 Recommendations for Security. Request for Comments 775 (Informational) 1750, Internet Engineering Task Force, December 776 1994. 778 [6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 779 for Message Authentication. Request for Comments 780 (Informational) 2104, Internet Engineering Task Force, 781 February 1997. 783 [7] C. Perkins. IP Mobility Support. Request for Comments 784 (Proposed Standard) 3344, Internet Engineering Task Force, 785 August 2002. 787 [8] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 788 Authentication Dial In User Service (RADIUS). Request for 789 Comments (Proposed Standard) 2138, Internet Engineering Task 790 Force, April 1997. 792 [9] R. Rivest. The MD5 Message-Digest Algorithm. Request for 793 Comments (Informational) 1321, Internet Engineering Task Force, 794 April 1992. 796 [10] W. Simpson. PPP Challenge Handshake Authentication Protocol 797 (CHAP). Request for Comments (Draft Standard) 1994, Internet 798 Engineering Task Force, August 1996. 800 All references are normative. 802 A. Change History 804 List of the important changes for version 03. 806 - Foreign agent recommended to include a Challenge in every 807 Registration Reply, so that mobile node can re-register without 808 waiting for an Advertisement. 810 - Foreign agent MUST record applicable challenge values used by 811 each mobile node 813 - Mobile node forbidden to use Challenge values which were 814 advertised previous to the last Challenge value which it had used 815 for a registration. 817 - terminology for stale challenge vs. unused challenge clarified 819 - terminology for "valid" challenge deleted in favor of "unused 820 challenge" 822 - Programming suggestion added as an appendix 824 List of the important changes for version 04. 826 - The definition of "previously used challenge" is merged with 827 "stale challenge" definition in section 1.1. 829 - Reference 7 is updated from RFC 3320 to RFC 3344 and reference 9 830 is updated from RFC 2138 to RFC 2865 in "Reference" section. 832 - Reference to RFC 3344 is added in section 3. 834 - HMAC_CHAP_SPI option is added for Generalized Mobile IP 835 Authentication extension. Upon receipt of HMAC_CHAP_SPI, 836 HMAC-MD5 is used instead of MD5 for computing the authenticator. 838 - Clarified processing of error messages at the mobile node 839 (section 3.1). 841 - Modified text of section 2.1 and 3.2 for further clarity. 843 List of the important changes for version 05. 845 - Added BAD_AAA_AUTHENTICATION_SET_BY_FA and 846 BAD_AAA_AUTHENTICATION_SET_BY_HA error codes to report 847 authentication errors caused while processing Mobile-AAA 848 Authentication extension. 850 - Processing of the Mobile-AAA Authentication extension is 851 clarified for the foreign agent and the Home Agent. 853 - Co-existence of the Mobile-AAA Authentication extension in the 854 same Registration Request is made explicit. 856 - The situation in which the foreign agent sets MISSING_CHALLENGE 857 is clarified further. 859 - The use of Mobile-AAA Authentication Extension is allowed by the 860 Mobile Node with co-located care-of-address. 862 List of the important changes for version 06. 864 - Minor editorial changes are made through out the document. 866 - Added definition of "previously used challenge" and removed 867 definition of "stale challenge" from section 1.1. 869 - Renamed BAD_AAA_AUTHENTICATION_SET_BY_FA to FA_BAD_AAA_AUTH and 870 BAD_AAA_AUTHENTICATION_SET_BY_HA to HA_BAD_AAA_AUTH. 872 - Defined an order of the Mobile-AAA Authentication extension 873 received with the authentication extension(s) defined in RFC 874 3344 [7]. 876 - Added protection against bogus Registration Reply and Agent 877 Advertisement. Also, the processing of the Challenge is 878 clarified if it is received in the multicast/unicast Agent 879 Advertisement. 881 B. Verification Infrastructure 883 The Challenge extensions in this protocol specification are expected 884 to be useful to help the foreign agent manage connectivity for 885 visiting mobile nodes, even in situations where the foreign agent 886 does not have any security association with the mobile node or the 887 mobile node's home agent. In order to carry out the necessary 888 authentication, it is expected that the foreign agent will need the 889 assistance of external administrative systems, which have come to be 890 called AAA systems. For the purposes of this document, we call the 891 external administrative support the "verification infrastructure". 892 The verification infrastructure is described to motivate the design 893 of the protocol elements defined in this document, and is not 894 strictly needed for the protocol to work. The foreign agent is free 895 to use any means at its disposal to verify the credentials of the 896 mobile node. This could, for instance, rely on a separate protocol 897 between the foreign agent and the Mobile IP home agent, and still be 898 completely invisible to the mobile node. 900 In order to verify the credentials of the mobile node, we imagine 901 that the foreign agent has access to a verification infrastructure 902 that can return a secure notification to the foreign agent that the 903 authentication has been performed, along with the results of that 904 authentication. This infrastructure may be visualized as shown in 905 figure 4. 907 +----------------------------------------------------+ 908 | | 909 | Verification and Key Management Infrastructure | 910 | | 911 +----------------------------------------------------+ 912 ^ | ^ | 913 | | | | 914 | v | v 915 +---------------+ +---------------+ 916 | | | | 917 | foreign agent | | home agent | 918 | | | | 919 +---------------+ +---------------+ 921 Figure 4: The Verification Infrastructure 923 After the foreign agent gets the Challenge authentication, it MAY 924 pass the authentication to the (here unspecified) infrastructure, 925 and await a Registration Reply. If the Reply has a positive status 926 (indicating that the registration was accepted), the foreign agent 927 accepts the registration. If the Reply contains the Code value 928 BAD_AUTHENTICATION (see Section 10), the foreign agent takes actions 929 indicated for rejected registrations. 931 Implicit in this picture, is the important observation that the 932 foreign agent and the home agent have to be equipped to make use 933 of whatever protocol is made available to them by the challenge 934 verification and key management infrastructure shown in the figure. 936 The protocol messages for handling the authentication within the 937 verification infrastructure, and identity of the agent performing the 938 verification of the foreign agent challenge, are not specified in 939 this document, because those operations do not have to be performed 940 by any Mobile IP entity. 942 C. Message Flow for FA Challenge Messaging with Mobile-AAA Extension 944 MN FA Verification home agent 945 |<-- Adv+Challenge--| Infrastructure | 946 | (if needed) | | | 947 | | | | 948 |-- RReq+Challenge->| | | 949 | + Auth.Ext. | | | 950 | | Auth. Request, incl. | | 951 | |--- RReq + Challenge --->| | 952 | | + Auth.Ext | RReq + | 953 | | |-- Challenge -->| 954 | | | | 955 | | | | 956 | | |<--- RRep ----- | 957 | | Authorization, incl. | | 958 | |<-- RRep + Auth.Ext.-----| | 959 | | | | 960 |<-- RRep+Auth.Ext--| | | 961 | + New Challenge | | | 963 Figure 5: Message Flows for FA Challenge Messaging 965 In figure 5, the following informational message flow is illustrated: 967 1. The foreign agent disseminates a Challenge Value in an Agent 968 Advertisement if needed. This advertisement MAY have been 969 produced after receiving an Agent Solicitation from the mobile 970 node (not shown in the diagram). 972 2. The mobile node creates a Registration Request including the 973 advertised Challenge Value in the Challenge Extension, along with 974 an Mobile-AAA authentication extension. 976 3. The foreign agent relays the Registration Request either to 977 the home agent specified by the mobile node, or else to its 978 locally configured Verification Infrastructure (see appendix B), 979 according to local policy. 981 4. The foreign agent receives a Registration Reply with the 982 appropriate indications for authorizing connectivity for the 983 mobile node. 985 5. The foreign agent relays the Registration Reply to the mobile 986 node, possibly along with a new Challenge Value to be used by the 987 mobile node in its next Registration Reply message. 989 D. Message Flow for FA Challenge Messaging with MN-FA Authentication 991 MN FA home agent 992 |<-- Adv+Challenge--| | 993 | (if needed) | | 994 | | | 995 |-- RReq+Challenge->| | 996 | + Auth.Ext. | | 997 | |--- RReq + Challenge --->| 998 | | + HA-FA Auth.Ext | 999 | | | 1000 | |<-- RRep + Challenge ----| 1001 | | + HA-FA Auth.Ext | 1002 | | | 1003 |<-- RRep+Auth.Ext--| | 1004 | + New Challenge | | 1006 Figure 6: Message Flows for FA Challenge Messaging 1007 with MN-FA Authentication 1009 In figure 6, the following informational message flow is illustrated: 1011 1. The foreign agent disseminates a Challenge Value in an Agent 1012 Advertisement if needed. This advertisement MAY have been 1013 produced after receiving an Agent Solicitation from the mobile 1014 node (not shown in the diagram). 1016 2. The mobile node creates a Registration Request including the 1017 advertised Challenge Value in the Challenge Extension, along with 1018 an Mobile-Foreign Authentication extension. 1020 3. The foreign agent relays the Registration Request to the home 1021 agent specified by the mobile node. 1023 4. The foreign agent receives a Registration Reply with the 1024 appropriate indications for authorizing connectivity for the 1025 mobile node. 1027 5. The foreign agent relays the Registration Reply to the mobile 1028 node, possibly along with a new Challenge Value to be used by the 1029 mobile node in its next Registration Reply message. If the Reply 1030 contains the Code value HA_BAD_AAA_AUTH (see Section 10), the 1031 foreign agent takes actions indicated for rejected registrations. 1033 E. Foreign Agent Algorithm for Tracking Used Challenges 1035 If the foreign agent maintains a large CHALLENGE_WINDOW, it becomes 1036 more important for scalability purposes to efficiently compare 1037 incoming challenges against the set of Challenge values which have 1038 been advertised recently. This can be done by keeping the Challenge 1039 values in order of advertisement, and by making use of the mandated 1040 behavior that mobile nodes MUST NOT use Challenge values which were 1041 advertised before the last advertised Challenge value that the mobile 1042 node has attempted to use. The following stylized programmatic 1043 algorithm accomplishes this objective. The maximum amount of total 1044 storage required by this algorithm is equal to Size*(CHALLENGE_WINDOW 1045 + (2*N)), where N is the current number of mobile nodes for which the 1046 foreign agent is storing challenge values. Note that, whenever the 1047 stored challenge value is no longer in the CHALLENGE_WINDOW, it can 1048 be deleted from the foreign agent's records, perhaps along with all 1049 other registration information for the mobile node if it is no longer 1050 registered. 1052 In the program fragment, it is presumed that the foreign agent 1053 keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a 1054 record of the last advertised challenge used by a mobile node, and 1055 also a record of the last challenge provided to a mobile node in a 1056 Registration Reply or unicast Agent Advertisement. 1058 To meet the security obligations outlined in Section 12, the FA 1059 SHOULD use one of the already stored, previously unused challenges 1060 when responding to an unauthenticated Registration Request or 1061 Agent Solicitation. If none of the already stored challenges are 1062 previously unused, the FA SHOULD generate a new challenge, include it 1063 in the response, and store it in the per-Mobile data structure. 1065 current_chal := RegistrationRequest.challenge_extension_value 1066 last_chal := mobile_node_record.last_used_adv_chal 1068 if (current_chal == mobile_node_record.RegReply_challenge) { 1069 update (mobile_node_record, current_chal) 1070 return (OK) 1071 } 1072 else if (current_chal "among" VALID_ADV_CHALLENGES[]{ 1073 if (last_chal "among" VALID_ADV_CHALLENGES[]) { 1074 if (current_chal is "before" last_chal) { 1075 send_error(STALE_CHALLENGE) 1076 return (FAILURE) 1077 } 1078 else { 1079 update (mobile_node_record, current_chal) 1080 return (OK) 1081 } 1083 } 1084 else { 1085 update (mobile_node_record, current_chal) 1086 return (OK) 1088 } 1089 } 1090 else { 1091 send_error(UNKNOWN_CHALLENGE); 1092 } 1094 Addresses 1096 Questions about this memo can be directed to the authors: 1098 Charles E. Perkins Pat R. Calhoun 1099 Communications Systems Lab 1100 Nokia Research Center Airespace Networks 1101 313 Fairchild Drive 110 Nortech Parkway 1102 Mountain View, California 94043 San Jose, CA 95134 1103 USA USA 1104 Phone: +1-650 625-2986 Phone: +1 408 635 2000 1105 EMail: charles.perkins@nokia.com Email: pcalhoun@diameter.org 1106 Fax: +1 650 625-2502 Fax: +1 720-293-7501 1108 Jayshree Bharatia 1109 Nortel Networks 1110 2221, Lakeside Blvd. 1111 Richardson, TX, 75082 1112 USA 1113 Phone: +1 972-684-5767 1114 Email: jayshree@nortelnetworks.com 1115 Fax: +1 972-684-3775