idnits 2.17.1 draft-le-aaa-mipv6-requirements-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 0) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 30 has weird spacing: '... It is inapp...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Since Mobile IPv6 does not have a Foreign Agent and mobility support in the protocol is different (i.e. MN directly sends Binding Updates directly to the home agent and correspondent nodes), these requirements do not apply for MIPv6 and SHOULD not be considered. -- 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) == Unused Reference: '4' is defined on line 537, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 552, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 565, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 569, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2486 (ref. '7') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Stefano M. Faccin 3 INTERNET-DRAFT Franck Le 4 Date: November 2002 Basavaraj Patil 5 Expires: May 2002 Charles E. Perkins 6 Nokia Research Center 8 Francis Dupont 9 ENST Bretagne 11 Maryline Laurent-Maknavicius 12 Julien Bournelle 13 INT Evry 15 Mobile IPv6 Authentication, Authorization, and Accounting Requirements 16 18 Status of This Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document describes the motivation why Diameter support for 42 Mobile IPv6 is required and needs to be developped. It analyses the 43 requirements expressed in RFC 2977 which was written both for MIPv4 44 and MIPv6; and it finally updates the IPv6 requirements for the AAA 45 support for Mobile IPv6 to reflect the latest modifications and 46 evolution of the Mobile IP, AAA and other relevant working groups. 48 Table of Contents 50 Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i 52 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Basic model . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Modifications to basic model . . . . . . . . . . . . . . . . 5 60 3.2. AAA Protocol Roaming Requirements . . . . . . . . . . . . . 6 62 4. Requirements related to basic IP connectivity . . . . . . . . . . 6 64 5. AAA for Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Attendant functionnality . . . . . . . . . . . . . . . . . . 7 66 5.2. Security associations . . . . . . . . . . . . . . . . . . . 8 67 5.3. Authentication and key distribution mechanisms. . . . . . . 8 68 5.4. Integration of Mobile IP and AAA procedures . . . . . . . . 9 69 5.5. Home agent allocation . . . . . . . . . . . . . . . . . . . 10 71 6. Security considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 Mobile IP defines a method that allows a Mobile Node to change its 79 point of attachment to the Internet with minimal service disruption. 80 But Mobile IP in itself does not provide any specific support for 81 mobility across different administrative domains, which limits the 82 applicability of Mobile IP in a large-scale commercial deployment. 84 AAA protocols such as Diameter precisely enable mobile users to roam 85 and obtain service in networks that may not necessarily be owned by 86 their home service provider. For Mobile IP to be deployed in 87 commercial networks, there therefore has to be AAA support for the 88 protocol. 90 RFC 2977 [1] describes the requirements that have to be supported by 91 a AAA service to aid in Mobile IP services; and Diameter extensions 92 for Mobile IPv4 [2] have already been specified allowing a MIPv4 node 93 to receive services from service providers (home and foreign) and 94 allowing the Diameter servers to authenticate, authorize and collect 95 accounting information for those MIPv4 nodes. 97 Even though MIPv4 and MIPv6 are similar when observed at high level, 98 the two protocols are actually quite different when considering the 99 support for Inter Domain deployment. Mobile IPv6 e.g. does not have 100 the equivalent of a Foreign Agent as defined in Mobile IPv4, and as a 101 result does not offer any mechanism by which the visited network can 102 authenticate and authorize access to the network. In addition, 103 extending the Diameter Mobile IPv4 Application to support Mobile IPv6 104 will reduce the flexibility and result in some AAA capability 105 exchange issues: it will be difficult to differentiate which AAA 106 nodes support only Mobile IPv4, which ones support only Mobile IPv6 107 and which ones support both. 109 Some Diameter Mobile IPv6 Application will have to be specified to 110 allow Mobile IPv6 nodes to receive services from foreign domains. 111 Such application will allow: 113 * local network access control: cf section 3 115 * remote network access control: cf section 3 117 * credentials/trusted third party: the AAA server act as trusted 118 third party allowing user authentication and key distribution. 120 * MN-Attendant LSA establishment: cf section 3.1 122 * home address allocation 123 * home agent allocation (cf. 4.5): eventhough Mobile IPv6 124 specifies a dynamic home agent assignement procedure, the AAA 125 servers allow a secure and efficient alternative method. 127 * transport of messages for MN-HA SA establishment by AAA 129 * key distribution for MN-HA SA establishment (need a higher 130 level of trust than for the previous) 132 * transport of MN-HA mobility signaling messages (need the two 133 previous items) 135 But before designing the solution, this document describes the Mobile 136 IPv6 AAA requirements: RFC 2977 [1] describes the requirements for 137 both Mobile IPv4 and Mobile IPv6 and this document will therefore be 138 taken as the base. But since that time, many changes have happened in 139 the IETF, different mechanisms have been defined and many 140 modifications have ocurred in the Mobile IP and AAA working Groups; 141 this draft will thus update the requirements to reflect those latest 142 modifications for the Mobile IPv6/AAA requirements. 144 In RFC 2977 [1], after a description of the model, the requirements 145 were presented in a progressive fashion: 147 - Requirements based on the general model 149 - Requirements based on providing IP service for mobile nodes 151 - Requirements derived from specific Mobile IP needs 153 This document will take the same structure, updating the requirements 154 for the IPv6 specific case, and taking into account the latest 155 amendments of the working groups. 157 Finally, it has to be noted that even though Mobile IPv6 is not an 158 RFC yet and still has some open issues, such issues (Mobile node- 159 Correspondent nodes security association establishment, use of home 160 address option, etc.) do no affect the need for Mobile IPv6 support 161 by AAA and do not impact the ability for AAA to support Mobile IPv6. 162 The Mobile IPv6 security issues are related to the MN-CN security 163 association whereas the AAA support for MIPv6 solves all the MN-HA 164 security issues. The AAA/Mobile IPv6 requirements and solution 165 specification can therefore proceed in parallel, while the last 166 Mobile IPv6 issues are being solved. 168 2. Terminology 170 This document frequently uses the following terms in addition to 171 those defined in RFC 2977: 173 Home Domain 174 A Home Domain is the administrative domain with whom the user 175 maintains an account relationship. 177 Foreign Domain 178 An administrative domain, visited by a Mobile IP client, and 179 containing the AAA infrastructure needed to carry out the 180 necessary operations enabling network access and Mobile IP 181 registrations. 183 Attendant 184 The attendant is the entity that extracts identification and 185 authorization data sent by the client and forwards them to AAAL 186 for verification. 188 AAAL 189 The AAA server in the foreign domain that mediates local access 190 to the AAA infrastructure. 192 AAAH 193 The AAA server in the home domain which is able to authorize 194 each of its clients. 196 Credential 197 Data provided by a client to the AAA server in a message 198 authentication code constructed using a secret shared between 199 the client and AAAH. 201 Local Security Association 202 Security association shared between the client and the foreign 203 domain. The sharing of such SA gives the foreign domain 204 significant local control over the authentication of a roaming 205 client: Local Security Association e.g. allows the foreign 206 domain to authenticate the user and perform key distribution 207 without involvement of any external authority such as the 208 client's home domain. LSA can thus allow optimizations in terms 209 of signaling load towards the external authorities and delay 210 involved in the security procedures. 212 Key distribution 213 Process or protocol whereby a shared secret becomes available 214 to two or more parties for subsequent crytographic use. 216 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 217 recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 218 described in RFC 2119 [11]. 220 3. Basic model 222 The Basic Model described in RFC 2977 [1] still applies: 224 When a client belonging to one administrative domain (called the 225 home domain) roams to another administrative domain (called the 226 foreign domain) and needs to use the local network resources, an 227 attendant in the foreign domain is likely to require that the 228 client provides some credentials that can be authenticated before 229 access to the resources is permitted. These credentials may be 230 something the foreign domain understands, but in most cases they 231 are assigned by, and understood only by the home domain, and may 232 be used for setting up secure channels with the mobile node. 234 The attendant which often does not have direct access to the data 235 needed to complete the transaction will forward the request to the 236 local AAA server. 238 The local AAAL itself may not have enough information stored 239 locally to carry out the verification for the credentials of the 240 client. In such cases, the AAAL has to contact other external 241 authorities such as the AAAH to verify the client's credentials. 243 In many typical cases, the authorization depends only upon secure 244 authentication of the client's credentials. And once the 245 authorization has been obtained by the local authority, and the 246 authority has notified the attendant about the successful 247 negotiation, the attendant can provide the requested resources to 248 the client. 250 Local Domain Home Domain 251 +--------------+ +----------------------+ 252 | +------+ | | +------+ | 253 | | | | | | | | 254 | | AAAL | | | | AAAH | | 255 | | +-------------------+ | | 256 | +---+--+ | | +------+ | 257 | | | | | 258 | | | +----------------------+ 259 +------+ | +---+--+ | 260 | | | | | | C = client 261 | C |- -|- -| A | | A = attendant 262 | | | | | | AAAL = local authority 263 +------+ | +------+ | AAAH = home authority 264 | | 265 +--------------+ 267 Figure 1: AAA Servers in Home and Local Domains 269 Therefore, the Security Association Model and the requirements 270 deduced from this model (RFC 2977 [1] section 3) are still valid for 271 IPv6. 273 +------+ +------+ 274 | | | | 275 | AAAL +--------------+ AAAH | 276 | | | | 277 +---+--+ +--+---+ 278 | | 279 | | 280 +---+--+ +--+---+ 281 C = client | | | | 282 A = attendant | A | | C | 283 AAAL = local authority | | | | 284 AAAH = home authority +------+ +------+ 286 Figure 2: Security Associations 288 3.1. Modifications to basic model 290 A modification to the basic model that is required is the need to 291 support and utilize Local Security Associations. LSAs have been 292 recently introduced in IETF ([3], [5]). After an initial successful 293 authentication of the user through the home domain, LSAs allow the 294 local domain to authenticate the user and perform key distribution 295 without involvement of any external authority such as the client's 296 home domain. LSA can thus allow optimizations in terms of signaling 297 load between network domains and delay caused by security procedures 298 between network domains: the requests can be processed locally and 299 the latency due to the time taken to traverse the wide-area Internet 300 that is likely to separate the AAAL and the AAAH can thus be avoided. 302 Thus, the following requirement is formulated: 304 - LSA ([3], [5]) SHOULD be supported and utilized by AAA in order to 305 support, e.g., user re-registration, user re-authentication, key 306 distribution/refreshment, etc. 308 3.2. AAA Protocol Roaming Requirements 310 The Diameter Mobile IPv6 Application is a new application extension 311 to the Diameter Base Protocol [6]: the retransmission algorithms of 312 the transport mechanism will therefore rely on the already defined 313 ones. 315 Except this remark, all the other requirements described in section 316 3.1 of RFC 2977 [1] are still valid. 318 4. Requirements related to basic IP connectivity 320 Since the usages scenarios described in section 4 of RFC 2977 [1] are 321 still valid, the two main requirements on AAA for IP connectivity are 322 still applicable: 324 - Either AAA server MUST be able to obtain, or to coordinate the 325 allocation of, a suitable IP address for the customer, upon 326 request by the customer 328 - AAA servers MUST be able to identify the client by some means 329 other than its IP address 331 And so are the derived ones such as: 333 - Policy in the home domain may dictate that the home agent instead 334 of the AAAH manages the allocation of the home IP address for the 335 mobile node. AAA servers MUST be able to coordinate the allocation 336 of an IP address for the mobile node at least in this way. 338 In the Diameter Mobile IPv4 Application, clients use the Network 339 Access Identifier (NAI) [7] to identify themselves. In the same way, 340 in MIPv6, Mobiles nodes should use the NAI: AAA servers today 341 identify clients using NAI, and in addition using NAI allows AAAL to 342 easily determine the home domain ("realm") for the client. 344 From these reasons, derives the following requirement: 346 - In the Diameter support for MIPv6, mobiles nodes SHOULD use the 347 NAI 349 5. AAA for Mobile IP 351 Since RFC 2977 [1] was written for both MIPv4 and MIPv6 and the 352 previous sections mainly describe the general, AAA and functional 353 requirements, most of them are still valid for MIPv6. 355 This section analyzes the Mobile IPv6 specific requirements and, as 356 MIPv6 and MIPv4 are quite different when looking at the architectural 357 model(MIPv6 does not e.g. have the equivalent of a Foreign Agent), 358 the main differences are described in this section. 360 5.1. Attendant functionnality 362 As defined in the basic model (section 2), the attendant is 363 responsible for authorization and authentication of the user before 364 giving him access to the local resources. The attendant receives the 365 user's credentials and is in charge of performing the necessary 366 functions to verify it (e.g. translating to the appropriate 367 protocols) but the attendant is not responsible for the address 368 allocation. 370 The attendant MAY interact with a DHCP Server, but instead of the 371 attendant functionality being the address allocation entity as 372 suggested in RFC 2977 [1], it is suggested that the attendant SHOULD 373 be some other agent in the network. Since RFC 2977 [1] was written, 374 several new mechanisms have evolved and new ones have been introduced 375 in IETF, e.g. new working Groups have been created such as PANA. 377 This draft suggest the following requirement for support of Mobile 378 IPv6 by AAA: 380 - AAA SHOULD support different network access protocols (e.g. PANA). 381 The location of the attendant depends on the specific protocol. 382 E.g. in the specific case of PANA, the attendant SHOULD be located 383 in the PANA Agent defined in [3] if such agent is present in the 384 network. 386 5.2. Security associations 388 RFC 2977 [1] requires the AAA servers to be able to perform key 389 distributions, and in particular requires supports for key 390 distribution for the security associations between the Home Agent and 391 the Foreign Agent, and the SA between the Mobile Node and the Foreign 392 Agent. 394 Since Mobile IPv6 does not have a Foreign Agent and mobility support 395 in the protocol is different (i.e. MN directly sends Binding Updates 396 directly to the home agent and correspondent nodes), these 397 requirements do not apply for MIPv6 and SHOULD not be considered. 399 The remaining requirements about key distribution are still valid 400 (support of mobile node-home agent security association, certificate 401 validation, SA distribution, etc.) and SHOULD be supported for Mobile 402 IPv6. 404 In the same way that in MIPv4, a security association is established 405 between the mobile node and the attendant; for MIPv6, it is still 406 relevant to set up a SA between the mobile node and the attendant, 407 more particularly for Local Security Association. 409 5.3. Authentication and key distribution mechanisms. 411 When RFC 2977 [1] was written, the requirements did not specify any 412 particular authentication and key distribution mechanisms. 413 However,the Diameter Mobile IPv4 Application defines a very specific 414 mechanism. 416 In order to make Mobile IPv6 support in AAA flexible and future 417 proof, the following requirement is considered: 419 - for authentication and key distribution, support for Mobile IPv6 420 in AAA SHOULD allow different mechanisms to be supported. 422 EAP provides a more generic mechanism for authentication and the 423 advantages of EAP are explained in RFC2284. Each authentication 424 method (such as CHAP [9], AKA [10], etc.) has its own properties, and 425 different users belonging to different home domains may have 426 different requirements. The adoption of EAP as one of the mechanisms 427 supported by AAA for Mobile IPv6 would provide a wider choice for the 428 AAAH and MN of which authentication method to adopt based on their 429 policies and requirements. 431 As for the key distribution, the Mobile IPv6 support in AAA should 432 also allow different possible protocols and more flexible behavior. 434 For this reason, the following requirement is expressed: 436 - for authentication and key distribution, support for Mobile IPv6 437 in AAA SHOULD allow for AAA to act only as trusted third party. 439 This would allow the MN and the home agent to authenticate each other 440 and perform key distribution with other mechanisms (e.g. IKE) without 441 directly involving AAA. 443 If no SA is shared by MN and HA, an SA MAY be negotiated through AAA 444 exchanges with AAA acting as trusted third party 446 5.4. Integration of Mobile IP and AAA procedures 448 The following requirement is already present in RFC 2977 [1] and 449 still applies to Mobile IPv6: 451 - After the initial registration, the mobile node is authorized to 452 continue using Mobile IP at the foreign domain without requiring 453 further involvement by the AAA servers. 455 This implies that at the initial registration the mobile node needs 456 to be authenticated and authorized, and mobility procedures need to 457 be performed (e.g. between the foreign agent and the home agent) to 458 guarantee the mobile node can use Mobile IP. 460 Initial registration may take a long time, e.g. if the foreign and 461 the home domains are far away from each other. In order to reduce 462 latency in the initial registration, it is important to reduce the 463 time taken for communications between the AAA servers to traverse the 464 wide-area Internet that is likely to separate the AAAL and the AAAH. 466 In the AAA support for Mobile IPv4, in order to reduce the number of 467 messages between domains that traverse the network for initial 468 registration of a Mobile Node and the resulting latency, the initial 469 registration message between the foreign agent and the home agent is 470 carried by AAA through the AAA functions in the visited network 471 (AAAL) and the home network (AAAH). As a result, latency is reduced 472 by handling the initial registration in conjunction with AAA and the 473 mobile IP mobility agents. 475 A similar solution should be adopted also for the support of Mobile 476 IPv6, and the following requirement is formulated: 478 - it SHOULD be possible to combine authorization and authentication 479 of a mobile node through AAA with Mobile IPv6 mobility procedures 480 (e.g. Binding Update). 482 Moreover, subsequent registrations, and authentication could be 483 optimized thanks to LSA. 485 Thanks to this requirement, unless the authentication mechanism 486 adopted requires several round trips, all needed AAA and Mobile IP 487 functions can be processed during a single exchange of messages 488 between the foreign domain and the home domain. 490 5.5. Home agent allocation 492 Another important requirement that needs to receive special attention 493 when defining the IPv6 solution is the Home agent allocation. 494 Scenarios for home agent allocation have already been described in 495 RFC 2977 [1] and still apply. 497 The Diameter Mobile IPv4 Application defines the procedure to assign 498 the Home agent in the visited domain. The ability to support this not 499 only provides more flexibility, but also allows more business 500 scenarios and reduces delays for the Mobile IP signaling procedures. 501 Thanks to the application, the Home Agent allocated to the MN needs 502 not be part of the MN home domain. E.g. this situation can occur if 503 the home address of the mobile node is provided by one domain (e.g. 504 an ISP that the mobile user uses while at home), and the 505 authorization and accounting by another (specialized) domain, e.g., a 506 credit card company. Another example is that the MN may want to get 507 connectivity and the ability to be mobile in a foreign domain and by 508 using the subscription with a home ISP (home domain), but the MN does 509 not desire to be reachable for packets destined to the MN home 510 address given by the home ISP. 512 Such functionality SHOULD also be considered when designing the AAA 513 support for MIPv6 solution. 515 6. Security considerations 517 This document does not specify a solution but describes the 518 requirements that need to be considered when developing a solution 519 for Mobile IPv6 and AAA. The security requirements have been listed 520 and explained in the previous sections. Different solutions MAY 521 fulfill the functional requirements expressed in this document. For 522 each of these, the security implications need to be analyzed 524 7. References 526 [1] Glass, et al.; Mobile IP Authentication, Authorization and 527 Accounting Requirements, RFC 2977, Internet Engineering 528 Task Force, October 2000. 530 [2] Pat R. Calhoun, Charles E. Perkins; Diameter Mobile IPv4 531 Application, Internet draft, Internet Engineering Task 532 Force, November 2001. 534 [3] Protocol Carrying Authentication for Network Access WG 535 (pana) http://www.ietf.org/html.charters/pana-charter.html. 537 [4] Yoshihiro Ohba, James Kempf, Phil Roberts, Barani Subbiah, 538 Basavaraj Patil, Henry Haverinen, Hesham Soliman; Usage 539 Scenarios of a User Registration Protocol (URP), Internet 540 draft, Internet Engineering Task Force, November 2001. 542 [5] Stefano M. Faccin, Franck Le; AAA Local Security 543 Association (LSA): The Temporary Shared Key (TSK), Internet 544 draft, Internet Engineering Task Force, July 2001. 546 [6] Pat R. Calhoun, et al.; Diameter Base Protocol, Internet 547 draft, Internet Engineering Task Force, November 2001. 549 [7] B. Aboba et M. Beadles, The Network Access Identifier, RFC 550 2486, Internet Engineering Task Force, January 1999. 552 [8] Charles E. Perkins et al., AAA for IPv6 Network Access, 553 Internet draft, Internet Engineering Task Force, July 2001 555 [9] W. Simpson, PPP Challenge Handshake Authentication Protocol 556 (CHAP), RFC 1994, Internet Engineering Task Force, August 557 1996 559 [10] J. Arkko et H. Haverinen, EAP AKA Authentication, Internet 560 draft, Internet Engineering Task Force, November 2001 562 [11] S. Bradner, "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 [12] Stefano M. Faccin, Franck Le; Diameter Mobile IPv6 566 Application, Internet draft, Internet Engineering Task 567 Force, November 2001. 569 [13] Francis Dupont, Maryline Laurent-Maknavicius et Julien 570 Bournelle; AAA for mobile IPv6; Internet draft, Internet 571 Engineering Task Force, November 2001. 573 8. Authors' Addresses 574 Stefano M. Faccin 575 Nokia Research Center 576 6000 Connection Drive 577 Irving, TX 75039 578 USA 580 Phone: +1 972 894-4994 581 E-mail: stefano.faccin@nokia.com 583 Franck Le 584 Nokia Research Center 585 6000 Connection Drive 586 Irving, TX 75039 587 USA 589 Phone: +1 972 374-1256 590 E-mail: franck.le@nokia.com 592 Basavaraj Patil 593 Nokia Corporation 594 6000 Connection Drive 595 Irving, TX 75039 596 USA 598 Phone: +1 972-894-6709 599 E-Mail: Raj.Patil@nokia.com 601 Charles E. Perkins 602 Nokia Research Center 603 313 Fairchild Drive 604 Mountain View, California 94043 605 USA 607 Phone: +1 650-625-2986 608 E-Mail: charliep@iprg.nokia.com 610 Francis Dupont 611 ENST Bretagne 612 Campus de Rennes 613 2, rue de la Chataigneraie 614 BP 78 615 35512 Cesson-Sevigne Cedex 616 FRANCE 617 Fax: +33 2 99 12 70 30 618 EMail: Francis.Dupont@enst-bretagne.fr 620 Maryline Laurent-Maknavicius 621 INT Evry 622 9, rue Charles Fourier 623 91011 Evry Cedex 624 FRANCE 625 Fax: +33 1 60 76 47 11 626 EMail: Maryline.Maknavicius@int-evry.fr 628 Julien Bournelle 629 INT Evry 630 9, rue Charles Fourier 631 91011 Evry Cedex 632 FRANCE 633 Fax: +33 1 60 76 47 11 634 EMail: Julien.Bournelle@int-evry.fr