idnits 2.17.1 draft-giaretta-mip6-authorization-eap-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1618. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1635), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 13 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 32 longer pages, the longest (page 1) being 70 lines 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 an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2006) is 6403 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Service-Options' is mentioned on line 516, but not defined == Missing Reference: 'Home-Agent-Address' is mentioned on line 517, but not defined == Missing Reference: 'Home-Address' is mentioned on line 517, but not defined == Missing Reference: 'Interface-Identifier' is mentioned on line 518, but not defined == Missing Reference: 'IKE-Authentication-Options' is mentioned on line 519, but not defined == Unused Reference: 'EAPKEYFWK' is defined on line 1467, but no explicit reference was found in the text == Unused Reference: 'RFC3084' is defined on line 1506, but no explicit reference was found in the text == Unused Reference: 'MIPv6APP' is defined on line 1511, but no explicit reference was found in the text == Unused Reference: 'PANA' is defined on line 1515, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 1519, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) -- Unexpected draft version: The latest known version of draft-josefsson-pppext-eap-tls-eap is -10, but you're referring to -11. -- Possible downref: Normative reference to a draft: ref. 'PEAPv2' == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-14 -- Possible downref: Normative reference to a draft: ref. 'MIPv6AMSK' -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-12 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-11 == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-05 Summary: 8 errors (**), 0 flaws (~~), 18 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group G. Giaretta 3 Internet Draft I. Guardini 4 Expires: April 2007 E. Demaria 5 Telecom Italia 6 J. Bournelle 7 M. Laurent-Maknavicius 8 GET/INT 9 October 2006 11 MIPv6 Authorization and Configuration based on EAP 12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on April 27, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). All Rights 43 Reserved. 45 Abstract 47 This draft defines an architecture, and related protocols, for 48 performing dynamic Mobile IPv6 authorization and configuration 49 relying on a AAA infrastructure. The necessary interaction between 50 the AAA server of the home provider and the mobile node is 51 realized using EAP, exploiting the capability of some EAP methods 52 to convey generic information items together with authentication 53 data. This approach has the advantage that the access equipment 54 acts as a simple pass-through for EAP messages and therefore does 55 not play any active role in the Mobile IPv6 negotiation procedure, 56 which makes the solution easier to deploy and maintain. 58 Table of Contents 60 1. Introduction................................................3 61 2. Terminology.................................................4 62 3. Protocol Overview...........................................5 63 4. Requirements on EAP methods.................................9 64 5. Detailed description of the Protocol.......................11 65 5.1 Mobile node bootstrapping...............................11 66 5.2 Management of re-authentication events..................15 67 6. Home Agent considerations..................................16 68 6.1 Requirements on AAAH-HA communication...................16 69 6.2 Management of MIPv6 authorization state.................17 70 7. The MIPv6-Authorization container..........................18 71 7.1 PEAPv2..................................................18 72 7.2 EAP-FAST................................................19 73 7.3 EAP-SIM.................................................19 74 7.4 EAP-AKA.................................................19 75 7.5 EAP-TTLS................................................19 76 7.6 EAP-IKEv2...............................................20 77 8. New TLVs...................................................22 78 8.1 Service-Status-TLV......................................22 79 8.2 Service-Selection-TLV...................................22 80 8.3 Service-Options-TLV.....................................23 81 8.4 Home-Agent-Address-TLV..................................23 82 8.5 Home-Address-TLV........................................24 83 8.6 IKE-Authentication-Options-TLV..........................25 84 8.7 IKE-Bootstrap-Information-TLV...........................25 85 8.8 Negotiation-Result-TLV..................................26 86 8.9 Authorization-Lifetime-TLV..............................27 87 9. Security Considerations....................................28 88 10. References.................................................29 89 10.1 Normative References..................................29 90 10.2 Informative References................................29 91 Acknowledgments.................................................31 92 Authors� Addresses..............................................31 93 Intellectual Property Statement.................................32 94 1. Introduction 96 Mobile IPv6 [RFC3775] requires that Mobile Nodes (MNs) and Home 97 Agents (HAs) share a set of configuration parameters: the MN must 98 know its Home Address, the Home Agent Address and the 99 cryptographic material needed to protect MIPv6 signaling (e.g. 100 shared keys or certificates to setup an IPsec security 101 association). MIPv6 base protocol does not specify any method to 102 automatically acquire this information; which means that network 103 administrators are normally required to manually set configuration 104 data on MNs and HAs. 106 Manual configuration of Home Agents and Mobile Nodes also works as 107 an implicit method for Mobile IPv6 authorization, because only the 108 users that have been administratively enabled on a specific Home 109 Agent are allowed to exploit Mobile IPv6 and its features. 111 However, in a large network (e.g. the network of a mobile 112 operator), which may include millions of users and many Home 113 Agents, the operational and administrative burden of this 114 procedure may easily become overwhelming. In addition, the 115 extensive use of manual and static configurations limits the 116 flexibility and reliability of the system, in that it is not 117 possible to dynamically assign the HA when the user enters the 118 network, which would help to optimize performance and resource 119 utilization (e.g. assignment of the HA closest to the MN�s point 120 of attachment). 122 This is generally referred to as the Mobile IPv6 bootstrapping 123 problem. As discussed in [RFC4640], several bootstrapping 124 scenarios can be identified depending on the relationship between 125 the network operator providing IP services to the MN (Access 126 Service Provider, ASP) and the service provider managing the HA 127 (Mobility Service Provider, MSP). This document describes a 128 solution to the bootstrapping problem that is applicable in a 129 scenario where the ASP and the MSP are the same provider 130 (Integrated ASP, IASP). 132 The proposed solution performs dynamic Mobile IPv6 authorization 133 and configuration together with MN authentication for network 134 access. MIPv6 negotiation and bootstrapping is controlled by the 135 AAA server of the home provider (IASP), that interacts with the 136 mobile node relying on AAA routing and EAP, exploiting the 137 capability of some EAP methods (e.g. PEAPv2 [PEAPv2], EAP-FAST 138 [EAP-FAST]) to convey generic information items together with 139 authentication data. 141 2. Terminology 143 General mobility terminology can be found in [RFC3753]. The 144 following additional terms are used here: 146 ASP Access Service Provider 148 IASP Integrated Access Service Provider 150 MSP Mobility Service Provider 152 AAA Authentication Authorization Accounting 154 AAAH AAA server of the Home domain 155 3. Protocol Overview 157 The basic idea behind the solution proposed herewith is to perform 158 Mobile IPv6 bootstrapping during the authentication procedure 159 undertaken by the Mobile Node to gain network access. 160 In particular, this draft defines a method to: 162 - explicitly authorize the use of Mobile IPv6 based on the service 163 profile of the user, its position within the network, etc. 165 - dynamically allocate a Home Agent to the Mobile Node; 167 - dynamically configure Mobile IPv6 start-up parameters (i.e. 168 MIPv6 bootstrapping) on the Mobile Node. These parameters 169 include the Home Address and the cryptographic material needed 170 to set-up the IPsec Security Association used to protect Mobile 171 IPv6 signaling (i.e. Binding Updates and Binding 172 Acknowledgements). 174 Figure 1 shows the overall architecture of the solution proposed 175 in this draft. The central element of the architecture is the AAA 176 server of the Home Domain (i.e. AAAH), which interacts with both 177 the MN and the selected HA to perform service authorization and 178 configuration. 180 AAA 181 Client 182 IEEE 802.1x +------+ RADIUS 183 or PANA | | or Diameter 184 +--------+ /--------------EAP Exchange-----------------\ +------- 185 -+ 186 | Mobile |/ <------------Authentication---------------> \| AAAH 187 | 188 | Node |\ <--MIPv6 authorization and configuration--> /| Server 189 | 190 +--------+ \-------------------------------------------/ +------- 191 -+ 192 | | /\ 193 +------+ /||\ 194 Router || 195 or AP AAAH-HA || 196 (pass through) Protocol || 197 \||/ 198 \/ 199 +------- 200 -+ 201 | Home 202 | 203 | Agent 204 | 205 +------- 206 -+ 208 Figure 1 - Solution architecture 210 The solution is applicable to any access network relying on EAP 211 [RFC3748] for user authentication and works with all EAP methods 212 supporting the exchange of general purpose information elements, 213 in any form (e.g. TLVs or AVPs), between EAP peers. Exploiting 214 this capability, MN and AAAH can piggyback Mobile IPv6 negotiation 215 messages within the same EAP conversation used to carry out user 216 authentication. 218 This kind of operation is already supported by several tunneled 219 (e.g. PEAPv2 [PEAPv2]) and non tunneled (e.g. EAP-IKEv2 [EAP- 220 IKEv2]) EAP methods, that also include native support for 221 encryption, authentication and integrity protection of exchanged 222 configuration data (e.g. HA address). 224 Figure 2 shows an overview of the procedure defined to handle 225 MIPv6 bootstrap on the Mobile Node. For the sake of simplicity it 226 is assumed that the employed AAA protocol is Diameter, but 227 obviously RADIUS is suitable as well. 229 EAP over 230 IEEE 802.1x EAP over Diameter AAAH-HA 231 or PANA AAA (or RADIUS) AAAH Protocol 232 MN +---------+ Client +----------------+ Server +-------------+ 233 HA 235 1) <--Req. Id.--- 236 --Identity---> --Diameter EAP Req.--> 237 /-------------------------------------\ 238 2) / Set-up of protected channel \ 239 \ e.g. TLS Tunnel (optional) / 240 \-------------------------------------/ 241 /-------------------------------------\ 242 3) / Authentication \ 243 \ Phase / 244 \-------------------------------------/ 245 /-------------------------------------\ +-+ /--------------\ 246 +-+ 247 4) / Mobile IPv6 service \| |/ HoA selection \| 248 | 249 \ authorization and configuration /| |\ and HA config. /| 250 | 251 \-------------------------------------/ +-+ \--------------/ 252 +-+ 253 Home Agent 254 State 255 Selection 256 Set-up 258 5) <-----EAP----- <-----Diameter EAP---- 259 Success/Failure Answer (Success/Failure 260 and authorization AVPs) 262 /----------------------------------------------------------\ 263 6) / Set-up Security Association MN-HA and \ 264 \ Mobile IPv6 registration (exchange of BU and BA) / 265 \----------------------------------------------------------/ 267 Figure 2 - Overview of Mobile IPv6 bootstrap procedure 269 The whole procedure can be divided in six steps: 271 1. EAP identity exchange (i.e. exchange of EAP Request Identity and 272 EAP Response Identity messages); 274 2. set-up of a protected channel (e.g. TLS tunnel) for the delivery 275 of subsequent EAP signaling. This is an optional step that is 276 present only if the EAP method provides confidentiality support. 277 It is mandatory only if the MIPv6 negotiation procedure involves 278 the exchange of sensitive information; 280 3. authentication phase. The actual authentication procedure and 281 its security properties depend on the selected EAP method. In 282 tunneled EAP methods (e.g. PEAPv2) this step may involve one or 283 more complete EAP conversations occurring within a previously 284 negotiated TLS session. Each EAP conversation may accomplish 285 user authentication relying on any available EAP method (e.g. 286 EAP-MD5, EAP-SIM, EAP-AKA); 288 4. Mobile IPv6 service authorization and configuration. MN and AAAH 289 exchange a sequence of signaling messages to authorize and 290 configure Mobile IPv6. Those messages are encapsulated as 291 requested by the employed EAP method (e.g. TLVs or AVPs) and 292 delivered as part of the on-going EAP session. If the EAP method 293 provides confidentiality this protocol handshake is encrypted 294 using the previously negotiated ciphersuite. During this phase, 295 AAAH selects a suitable Home Agent for the MN and exchanges 296 authorization and configuration data with it using a AAAH-HA 297 protocol, whose specification is out of the scope of the present 298 document. Further analysis on the definition of such an 299 interface can be found in [AAAMIP6] and [AAAMIPFWK]. At the end 300 of this phase, the MN knows its own Home Address, the address of 301 the correspondent Home Agent, the peer authentication method 302 (i.e. certificates or pre-shared key) and the cryptographic 303 material (e.g. pre-shared key) needed to set-up an IPsec 304 security association with IKE [RFC2409]. The IKE pre-shared key 305 can be either constructed by AAAH and then delivered to MN in a 306 proper TLV (or AVP) or independently derived by MN and AAAH from 307 the EAP key hierarchy; 309 5. EAP session termination. Assuming the mobile node has been 310 successfully authenticated, the AAAH server sends a Diameter EAP 311 Answer message with Result-Code equal to SUCCESS. The AAA client 312 extracts the EAP Success message from the Diameter EAP Answer 313 and forwards it to the MN terminating the EAP session; 315 6. set-up of IPsec Security Association and MIPv6 registration. At 316 the end of the EAP communication, the MN gains network access 317 and acquires a valid Care-of Address within the visited subnet 318 (e.g. via stateless autoconfiguration); then it performs an IKE 319 exchange to establish the IPsec Security Association with the 320 HA, using the authentication method and the cryptographic 321 material negotiated during the MIPv6 service configuration phase 322 (step 4). Finally, the MN performs MIPv6 registration, sending a 323 Binding Update (protected with IPsec) to the HA. 325 This draft also defines the procedures to handle re-authentication 326 events and to manage the termination of the Mobile IPv6 session. 328 In summary, the proposed architecture has the following 329 advantages: 331 - allows the MSP to maintain a centralized management (on the AAA 332 server) of the user profiles and the authentication, 333 authorization and accounting procedures for any type of service, 334 including Mobile IPv6; 336 - improves the reliability and performance of the Mobile IPv6 337 protocol, in that the HA to be dynamically assigned to the MN 338 can be freely chosen among those that are closest to the user�s 339 point of attachment, thus optimizing network usage and reducing 340 the transfer delay for data traffic in bi-directional tunneling; 342 - can be deployed, or extended with new features, without having 343 to update the access equipment and the AAA protocols in use. 344 Only minor changes in the AAA servers, the Home Agents and the 345 mobile terminals are required, in that the AAA client does not 346 play any active role in MIPv6 negotiation (i.e. it is a pass- 347 through for EAP signaling). This reduces the deployment costs 348 and makes the solution easy to use even when a Mobile Node is 349 roaming with a provider different from its own; 351 - allows the usage of any AAA protocol supporting the transport of 352 EAP messages for the communication between the AAA client and 353 server (i.e. not just Diameter, but also RADIUS). This 354 significantly simplifies the deployment of MIPv6 in existing 355 communication networks, where support for Diameter protocol in 356 access equipment is not so extensive. 358 - allows the operator to dynamically choose the authentication 359 method for IKE bootstrapping and to automatically distribute the 360 pre-shared key eventually needed; in this way the pre-shared key 361 must not be pre-configured and can be frequently changed 362 increasing resistance to attacks. In the case of an EAP method 363 providing dynamic generation of keying material the pre-shared 364 key can be derived from EAP hierarchy avoiding the need to 365 explicitly send it to the MN [MIPv6AMSK]. 367 As a whole, the solution adds a maximum of 2 RTTs (see the 368 detailed protocol description in section 5) to the EAP 369 conversation carried out by the mobile node to authenticate itself 370 and gain network access. The number of extra RTTs can be reduced 371 if the employed EAP method has the capability of transporting 372 MIPv6 negotiation TLVs (or AVPs) together with authentication 373 data. Nonetheless, it should be noted that the full negotiation 374 procedure can be undertaken by the MN only during its initial 375 bootstrapping, and therefore the performance requirements are not 376 so strict. 378 4. Requirements on EAP methods 380 In EAP methods, the EAP peer and EAP server exchange data in order 381 to authenticate the EAP peer and eventually the EAP server (mutual 382 authentication). This draft proposes the use of these exchanges to 383 transport MIPv6 parameters, as part of an handshake that requires 384 at maximum 2 RTTs. Thus, the main requirement for the 385 applicability of the solution is: 387 - the EAP method must provide a way to carry arbitrary parameters 388 during or after the authentication phase. This implies that the 389 EAP method must provide messages and mechanisms for this 390 purpose. 392 Then, for security reasons, the EAP method must provide the 393 following properties: 395 - mutual authentication: the EAP method must provide mutual 396 authentication. The access network must authenticate users 397 before granting them Mobile IPv6 service and the EAP peer should 398 authenticate the access network before delivering sensitive 399 data; 401 - integrity: the exchanged MIPv6 parameters must be protected 402 against any alteration and thus the EAP method must provide 403 integrity protection; 405 - replay protection: the EAP messages containing MIPv6 parameters 406 must be protected against Replay Attack, so that an attacker is 407 not able to get previous given data by replaying an old request; 409 - confidentiality: depending on which data the AAA server provides 410 to the mobile node (e.g. an IKE pre-shared key), it may be 411 necessary to protect the message exchange against eavesdropping. 413 The table below checks some existing EAP methods against the 414 requirements listed above. 416 M-A: Mutual Authentication 417 R-P: Replay Protection 419 +---+----------+---+---------------+-------------+ 420 | | | | | Exchange | 421 |M-A| Integrity|R-P|Confidentiality| of arbitrary| 422 | | | | | Parameters | 423 +------------+---+----------+---+---------------+-------------+ 424 | PEAPv2 | x | x | x | x | x | 425 +------------+---+----------+---+---------------+-------------+ 426 | EAP-FAST | x | x | x | x | x | 427 +------------+---+----------+---+---------------+-------------+ 428 | EAP-TTLS | x | x | x | x | x | 429 +------------+---+----------+---+---------------+-------------+ 430 | EAP-IKEv2 | x | x | x | x | x | 431 +------------+---+----------+---+---------------+-------------+ 432 | EAP-SIM | x | x | x | x | x | 433 +------------+---+----------+---+---------------+-------------+ 434 | EAP-AKA | x | x | x | x | x | 435 +------------+---+----------+---+---------------+-------------+ 436 | EAP-TLS | x | x | x | x | | 437 +------------+---+----------+---+---------------+-------------+ 438 | EAP-MD5 | | | | | | 439 +------------+---|----------|---|---------------|-------------| 441 In summary, it is possible to note that the procedure described in 442 this draft can be successfully undertaken with several tunneled 443 (PEAPv2, EAP-FAST and EAP-TTLS) and non tunneled EAP methods (EAP- 444 IKEv2, EAP-SIM, EAP-AKA), that all support the transport of 445 arbitrary parameters. 447 5. Detailed description of the Protocol 449 This section details the procedures and message exchanges that can 450 be adopted by the network operator to explicitly authorize the 451 activation of Mobile IPv6 support for a specific user as well as 452 enable dynamic bootstrapping of MIPv6 protocol parameters (e.g. 453 Home Address, Home Agent Address). 455 5.1 Mobile node bootstrapping 457 If EAP is used for access control, when the MN enters the network 458 it is immediately polled for its identity, by means of an EAP 459 Request Identity message. This message is used to start the EAP 460 communication. The MN replies sending its identity, in the form of 461 a NAI (Network Access Identifier), within an EAP Response Identity 462 message, that is received by a AAA client (e.g. the Access Point 463 in the case of a Wireless LAN) and forwarded via AAA routing to 464 the AAAH server using the Diameter EAP Application (or the RADIUS 465 EAP extensions). Then the AAAH server selects an EAP method (e.g. 466 based on the user service profile) and proposes it to the MN in 467 subsequent EAP messages. In order to enable the Mobile IPv6 468 negotiation procedure defined in this document, the EAP method 469 chosen by the AAAH server must be an EAP method supporting the 470 transport of general purpose and variable length information 471 elements, in the form of TLVs (or AVPs), together with 472 authentication data (see section 4). 474 After this initial handshake, MN and AAAH undertake the actual 475 authentication phase, that may require the exchange of a variable 476 number of EAP Request/Response messages. In many EAP methods, like 477 PEAPv2 or EAP-IKEv2, the authentication phase is preceded by the 478 establishment of an encrypted channel between MN and AAAH that 479 provides protection capabilities (i.e. privacy, integrity 480 protection, etc.) for all the messages exchanged during the rest 481 of the EAP conversation. 483 As soon as the authentication phase is completed, the procedure 484 for MIPv6 bootstrapping may take place. For that purpose, the MN 485 and the AAAH server exploit the on-going EAP communication to 486 exchange a sequence of signaling messages transporting 487 configuration parameters. 489 All the messages used for MIPv6 bootstrapping are encoded in TLVs 490 carried by a generic MIPv6-Authorization container. This choice 491 simplifies a lot the deployment of the procedure with any EAP 492 method satisfying the requirements listed in section 4. In fact, 493 only the structure of the MIPv6-Authorization container needs to 494 be adapted to the actual message format of the employed EAP 495 method. 497 For the sake of simplicity, in this section it is assumed that the 498 EAP method used for network access authentication supports the 499 transport of arbitrary parameters in TLV format. In this case the 500 MIPv6-Authorization container becomes a MIPv6-Authorization-TLV. 501 Nonetheless, in section 7 the format of the container is defined 502 for all the EAP methods identified in section 4. 504 The whole bootstrapping procedure is depicted in Figure 3. 506 AAAH 507 MN +----------------------------+ Server +----------------+ HA 509 <--------------------- 510 MIPv6-Authorization-TLV( 511 Service-Status, 512 [Service-Options]) 514 -----------------------> 515 MIPv6-Authorization-TLV( 516 Service-Selection, [Service-Options], 517 [Home-Agent-Address], [Home-Address], 518 [Interface-Identifier], 519 [IKE-Authentication-Options]) 520 +-+ +-+ 521 | |/----------------\| | 522 | |\----------------/| | 523 +-+ +-+ 524 Home Agent HA 525 Selection 526 Conf. 528 <--------------------- 529 MIPv6-Authorization-TLV( 530 Home-Address, Home-Agent-Address, 531 IKE-Bootstrap-Information, 532 Authorization-Lifetime) 534 -----------------------> 535 MIPv6-Authorization-TLV( 536 Negotiation-Result) 538 Figure 3 - MIPv6 bootstrapping procedure 540 AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6- 541 Authorization-TLV including the following TLVs: 543 - Service-Status-TLV: used to communicate whether the home domain 544 is willing to provide Mobile IPv6 service to the MN. This might 545 depend on the user service profile or on other administrative 546 rules (e.g. service accountability); 548 - Service-Options-TLV (optional): used to specify other service 549 options the MN can ask for (e.g. allocation of a HA in the 550 visited domain). 552 MN replies to this first message confirming its intention to start 553 Mobile IPv6 and, optionally, providing a set of hints on the 554 desired service capabilities; this is achieved delivering a MIPv6- 555 Authorization-TLV including the following TLVs: 557 - Service-Selection-TLV: used by the MN to specify if it is 558 willing to activate Mobile IPv6 protocol operation; 560 - Service-Options-TLV (optional): used by the MN to communicate 561 which service options, among those previously advertised by 562 AAAH, it would like make use of; 564 - Home-Agent-Address-TLV (optional): used by the MN to suggest a 565 preferred Home Agent. This can be a HA with whom the MN has a 566 pre-configured Security Association or a HA acquired through 567 dynamic HA address discovery. The AAAH server treats this 568 indication just as a hint, which means that, for administrative 569 reasons, the MN may be assigned a Home Agent different from the 570 one previously requested; 572 - Home-Address-TLV (optional): used by the MN to suggest a 573 preferred Home Address (e.g. an address pre-configured on one of 574 its network interfaces); like the previous TLV, this indication 575 is considered only as a hint by the AAAH server; 577 - Interface-Identifier-TLV (optional): through this TLV, the MN 578 can suggest a preferred Interface Identifier (selected according 579 to [RFC3041] or following other criteria) to be used by the AAA 580 infrastructure to build the Home Address starting from the 581 selected home prefix. Also in this case, this information, if 582 present, is treated as a pure hint by the AAAH server. 584 - IKE-Authentication-Options-TLV (optional): through this TLV, the 585 MN communicates to the AAAH server in order of preference the 586 peer authentication methods it supports for IKE bootstrapping. 587 The lack of this TLV means that the MN supports only the default 588 method. 590 The solution described in this document supports the following 591 methods for peer authentication in IKE phase 1: 593 - use of a pre-shared key (PSK) derived by the AAAH server and 594 sent to the MN and the HA; in this case confidentiality must be 595 provided by both the AAAH-HA protocol and the EAP session 596 between the MN and the AAAH server. This is the default method. 598 - use of a pre-shared key independently derived by the MN and the 599 AAAH server from the keying material exported by the employed 600 EAP method. This key can be derived from an Application Master 601 Session Key (AMSK) specific to Mobile IPv6, which can be 602 constructed as explained in [MIPv6AMSK]. The PSK is then 603 delivered by the AAAH server to the HA by means of a AAAH-HA 604 protocol providing confidentiality; 606 - use of digital certificates. This solution involves the 607 employment of digital signatures and public key encryption as 608 stated in [RFC2409]. This method requires the availability of a 609 PKI. 611 If in the Service-Selection-TLV the MN has chosen not to make use 612 of Mobile IPv6, AAAH terminates the EAP communication sending an 613 EAP Success message, since the authentication procedure has been 614 accomplished successfully. 616 Otherwise, if the MN has confirmed its willingness to start MIPv6 617 service, AAAH selects a suitable Home Agent through a Home Agent 618 Selection Algorithm. Possible parameters to be taken into account 619 by this algorithm include: current load of available HAs (e.g. 620 number of active bindings), location of the MN and, eventually, 621 the preferences provided by the MN itself in the previous message 622 exchange (i.e. Service-Options-TLV, Home-Agent-Address-TLV, Home- 623 Address-TLV, IKE-Authentication-Options-TLV). For example, based 624 on the knowledge of the MN's current point of attachment (i.e. the 625 current AAA client), the AAAH server may select, among the HAs 626 available in the home domain, the one that is closest to the MN in 627 terms of IP routing hops. This approach is normally expected to 628 improve performance. However, the detailed definition of a Home 629 Agent Selection Algorithm is out of the scope of this document. 631 After a suitable HA has been identified, the AAAH server selects 632 the peer authentication method to be used in IKE phase 1. The peer 633 authentication methods supported by the MN are known from the IKE- 634 Authentication-Options-TLV received during the previous exchange. 635 If possible, the AAAH server should choose the method on top of 636 the list provided by the MN (i.e. the one with the highest 637 preference). 639 As soon as the peer authentication method has been identified, the 640 AAAH server interacts with the HA to dynamically configure the 641 state needed to enable subsequent MIPv6 protocol operations, 642 including the authorization lifetime of the MIPv6 service granted 643 to the MN and the necessary security parameters (e.g. pre-shared 644 key). Possible protocols that can be used for this purpose include 645 Diameter (through a new Diameter Application), SNMPv3 or COPS-PR. 646 Further details about this communication are provided in section 647 6. Anyway, the detailed specification of the interface between 648 AAAH and HA is out of the scope of this document. Additional 649 considerations on the nature and goals of such an interface can be 650 found in [AAAMIP6] and [AAAMIPFWK]. 652 The security parameters that the AAAH server delivers to the HA 653 may vary depending on the peer authentication method chosen for 654 IKE bootstrapping: 656 - if the AAAH server selects pre-shared key as peer authentication 657 method it needs to send the chosen PSK (randomly generated or 658 derived from the EAP key hierarchy) to the HA together with the 659 associated lifetime; 661 - if the AAAH server selects a peer authentication method based on 662 certificates it does not need to derive keys nor to send 663 security parameters to the HA. 665 After the AAAH server has configured the state on the HA, it 666 continues the EAP session communicating to the MN all the MIPv6 667 configuration data it is waiting for. This is achieved delivering 668 to the MN an EAP Request containing a MIPv6-Authorization-TLV and 669 the following sub-TLVs: Home-Address-TLV (i.e. the home address), 670 Home-Agent-Address-TLV (i.e. the address of the HA), IKE- 671 Bootstrap-Information-TLV (i.e. the peer authentication method to 672 be used in IKE phase 1 and associated cryptographic material) and 673 Authorization-Lifetime-TLV (i.e. the lifetime granted to the MN 674 for this session). 676 After the MN has received all the configuration data from the AAAH 677 server (i.e. HA address, Home Address and IKE bootstrap 678 information), it sends back an EAP Response containing a 679 Negotiation-Result-TLV, stating whether it accepts, or refuses, 680 the proposed arrangement. If the MN refuses the configuration, the 681 AAAH server should immediately release the resources previously 682 allocated on the Home Agent. 684 After the completion of the EAP session, MN holds all data needed 685 to perform Mobile IPv6 registration: the MN knows its Home 686 Address, the address of the correspondent Home Agent and all 687 cryptographic data needed to establish the IPsec security 688 association with it; furthermore, since it has been successfully 689 authenticated, the MN can acquire an IPv6 address to be used as 690 Care-of Address. 692 The first operation carried out by the MN after the acquisition of 693 the Care-of Address is the establishment of the IPsec Security 694 Association with the HA, that is mandated by [RFC3775] to protect 695 MIPv6 location update signaling. Set-up of the IPsec SA can be 696 accomplished following the procedure detailed in [RFC3776]. 698 As soon as the IPsec Security Association is established, MN can 699 send a Binding Update to the HA, thus starting up Mobile IPv6 700 service. 702 5.2 Management of re-authentication events 704 At the expiration of AAA session time-outs or after a change in 705 the point of attachment to the network (e.g. change of Access 706 Point), a re-authentication procedure is performed leading to the 707 user identity to be checked again along with its right to continue 708 exploiting network resources. To that purpose the AAAH server may 709 repeat a full authentication or, alternatively, decide to use 710 optimizations in order to make the procedure faster. Once this 711 phase is completed the AAAH server also undertakes the re- 712 negotiation of the MIPv6 service. 714 Since the MIPv6 bootstrapping procedure is assumed to be 715 completely stateless, when a re-authentication event occurs the 716 AAAH server may not know the state of the MIPv6 service on the MN. 717 For this reason the AAAH server starts the MIPv6 negotiation like 718 in the bootstrapping case: it delivers a MIPv6-Authorization-TLV 719 containing a Service-Status-TLV and optionally a Service-Options- 720 TLV. 722 If the MIPv6 service is not active on the MN the procedure 723 continues as described in section 5.1. Otherwise, the MN replies 724 with a MIPv6-Authorization-TLV containing a Service-Selection-TLV 725 indicating that the MIPv6 service is already in use. Furthermore, 726 the MN inserts the Home-Agent-Address-TLV, the Home-Address-TLV 727 and the IKE-Authentication-Options-TLV to inform the AAAH server 728 about its current state. The AAAH server can then get in touch 729 with the HA to check the integrity of the state, renew the MIPv6 730 authorization lifetime and eventually refresh the security 731 parameters. 733 If the peer authentication method used by the MN in IKE phase 1 is 734 pre-shared key, the AAAH server must derive a new PSK and send it 735 to the HA together with the associated lifetime. In case the PSK 736 is not derived from the EAP key hierarchy (i.e. it is randomly 737 generated by the AAAH server), the AAAH server must communicate it 738 also to the MN. Instead, in case of authentication based on 739 certificates, the AAAH server does not need to derive keys nor 740 deliver additional security data to the HA and the MN. 742 If the state on the HA is successfully updated, the AAAH server 743 terminates the EAP communication sending an EAP Success message. 744 Otherwise, the AAAH server should continue the EAP communication 745 renegotiating the MIPv6 service (i.e. allocation of a new HA and 746 related Home Address). 748 This solution can be easily deployed even within a network 749 including several AAA servers, each one managing a subset of the 750 available Network Access Servers (NASs). This is because the re- 751 negotiation procedure does not assume to have any long term state 752 related to Mobile IPv6 stored on the AAAH server. In this way, 753 everything works correctly even if, due to MN's movements within 754 the network, the AAAH server that handles the re-authentication is 755 not the same server that authenticated the MN for the first time 756 and performed the MIPv6 bootstrapping procedure. 758 As explained above, the re-authentication events are normally 759 triggered by the network. Nonetheless, if the EAP lower layer 760 offers a way to trigger EAP re-authentications (e.g. PANA supports 761 this feature), it may be possible for the MN to re-negotiate the 762 MIPv6 service at any time. 764 6. Home Agent considerations 766 This section provides further thoughts about the AAAH-HA 767 communication and lists specific features that have to be 768 supported by the Home Agent to allow dynamic negotiation of Mobile 769 IPv6 protocol parameters. 771 6.1 Requirements on AAAH-HA communication 773 This draft details only the message exchange between the MN and 774 the AAAH server. Obviously a complete Mobile IPv6 bootstrapping 775 solution requires also the definition of a mechanism for the 776 communication between the AAAH server and the Home Agent. Possible 777 protocols that may be used for this purpose include SNMPv3, COPS- 778 PR or Diameter but a formal definition of such a protocol is out 779 of scope of this document. 781 A detailed analysis of the goals for a generic AAAH-HA protocol 782 can be found in [AAAMIP6]; in this section some requirements, 783 specific to this scenario, are highlighted. 785 The selected protocol should allow the AAAH server to: 787 - use a Network Access Identifier (NAI) to identify the mobile 788 node in the communication with the HA; 790 - send an authorization lifetime to the HA to limit Mobile IPv6 791 session duration for the MN; 793 - send to the HA a set of hints for the construction of the Home 794 Address (e.g. a preferred Home Address or a preferred Interface 795 Identifier); 797 - poll the designated HA for the allocation of a Home Address to 798 the MN; 800 - force the HA to terminate an active Mobile IPv6 session for 801 authorization policy reasons (e.g. credit exhaustion or 802 reallocation of a new HA to the MN); 804 - enforce explicit operational limitations and authorization 805 restrictions on the HA (e.g. packet filters, QoS parameters); 807 - retrieve the Mobile IPv6 state associated to a specific MN from 808 the correspondent HA. This may be useful to periodically verify 809 the Mobile IPv6 service status; 811 - send to the HA the security data needed to setup the IPsec SA 812 with the MN. Possible security data are the authentication 813 method and the cryptographic material to be used for IKE 814 bootstrapping. 816 Moreover, the protocol selected to implement the communication 817 between the AAAH server and the HA should fulfill the following 818 general requirements: 820 - the AAAH server and the HA must be able to authenticate each 821 other (mutual authentication) in order to prevent the 822 installation of unauthorized state on the HA; 824 - the AAA-HA interface must provide integrity protection in order 825 to prevent any alteration of exchanged data (e.g. Mobile IPv6 826 configuration parameters); 827 - the AAA-HA interface must provide replay protection; 829 - the AAA-HA interface should provide confidentiality since it may 830 be used to transfer security parameters (e.g. IKE pre-shared 831 key); 833 - the AAA-HA interface should support inactive peer detection. 834 This functionality can be used by the AAAH server to maintain a 835 list of active HAs (e.g. useful for HA selection); 837 6.2 Management of MIPv6 authorization state 839 The Home Agent is required to store some authorization data for 840 each of the MNs it is serving. A new data structure may be used 841 for this purpose and it should include at least the following 842 fields: 844 - NAI of the user; 846 - Home Address assigned to the MN; 848 - Cryptographic Data: this field includes the peer authentication 849 method to be used in IKE and, if needed, the pre-shared key and 850 its lifetime; 852 - Authorization Lifetime: it is the lifetime of the Mobile IPv6 853 service granted to the MN; 855 At the expiration of the Authorization Lifetime the HA should 856 check if there is an active entry for the MN in its Binding Cache 857 in order to verify if the MN is still using Mobile IPv6. If the 858 entry is available the Home Agent should negotiate with the AAAH 859 server an extension of the Authorization Lifetime granted to the 860 MN. Otherwise, the HA should immediately release the authorization 861 state associated to that MN and eventually notify the session 862 termination to the AAAH server (e.g. by means of a Session 863 Termination Request if the employed AAAH-HA protocol is Diameter). 865 Moreover, the release of the resources previously allocated on the 866 Home Agent can be undertaken at any time by the AAAH server. 867 Typically this happens at credit exhaustion or when the MN 868 disconnects from the network. 870 The policies adopted by the AAAH server to release the resources 871 allocated to the MN may vary depending on the user service 872 profile. For instance, the AAAH server may decide to postpone the 873 release of the resources on the HA in order to allow the MN to 874 continue using the Mobile IPv6 service even if it has moved to an 875 access network for which no roaming agreements are in place (e.g. 876 a corporate network or a network providing cost-free access). In 877 that case, the MN can continue to rely on the IPsec SA previously 878 negotiated with the HA and the respective authorization is managed 879 through the Mobile IPv6 Authorization Lifetime. 881 7. The MIPv6-Authorization container 883 All the messages used for MIPv6 bootstrapping are encoded in TLVs 884 carried by a generic MIPv6-Authorization container. In this way, 885 only the structure of the container needs to be adapted to the 886 actual message format of the employed EAP method. 888 The MIPv6-Authorization container can be implemented as a TLV, as 889 an AVP or in some other way depending on the specific 890 characteristics of the EAP method used for network access 891 authentication (see Figure 4). 893 +----------------------------------------------------------+ 894 | MIPv6 bootstrapping TLVs (Sec. 8) | 895 +------+--------------+--------------+--------------+------+ 896 | | | | 897 | | | | 898 +------+-----+ +------+-----+ +------+-----+ +------+------+ 899 | MIPv6 | | MIPv6 | | MIPv6 | | MIPv6 | 900 | Auth. TLV | | Auth. TLV | | Auth. AVP | | Auth. IKEv2 | 901 | | | | | | | Payload | 902 | (Sec. 7.1) | | (Sec. 7.3) | | (Sec. 7.5) | | (sec. 7.6) | 903 +------------+ +------------+ +------------+ +-------------+ 904 | PEAPv2 | | EAP-SIM | | EAP-TTLS | | EAP-IKEv2 | 905 | EAP-FAST | | EAP-AKA | | | | | 906 +------------+ +------------+ +------------+ +-------------+ 908 Figure 4 - Transport of MIPv6 bootstrapping messages 910 In the following the format of the MIPv6-Authorization container 911 is defined for each EAP method identified in section 4. This list 912 is not exhaustive and does not prevent the use of other EAP 913 methods satisfying all the requirements listed in this document. 915 7.1 PEAPv2 917 The exchange of arbitrary information in PEAPv2 is based on EAP- 918 TLVs. In this case the MIPv6-Authorization container is encoded as 919 an EAP-TLV and has the structure depicted below: 921 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 922 1 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 924 +-+ 925 |M|R| Type | Length 926 | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 928 +-+ 929 | Value 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 931 +-+ 933 M 935 0 - Non-mandatory TLV 937 R 939 Reserved, set to zero (0) 940 Type 942 TBD - MIPv6-Authorization 944 Length 946 The length of the Value field in octets 948 Value 950 This field carries the subsequent TLVs 952 7.2 EAP-FAST 954 The format of the messages for EAP-FAST [EAP-FAST] is the same as 955 PEAPv2. 957 7.3 EAP-SIM 959 EAP-SIM [EAP-SIM] allows the transport of additional information 960 in form of TLVs. The format of the MIPv6-Authorization container 961 is depicted below: 963 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 964 1 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 966 +-+ 967 | Type | Length | Value 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 969 +-+ 971 Type 973 TBD � MIPv6-Authorization 975 Length 977 Indicates the length of this attribute in multiples of four 978 bytes. The maximum length of an attribute is 1024 bytes. The 979 length includes the Type and Length bytes. 981 Value 983 This field carries the subsequent TLVs 985 7.4 EAP-AKA 987 The format of the messages for EAP-AKA [EAP-AKA] is the same as 988 EAP-SIM. 990 7.5 EAP-TTLS 992 EAP-TTLS messages [EAP-TTLS] allow the exchange of arbitrary data 993 in the form of AVPs encapsulated in the TLS record. The MIPv6- 994 Authorization container is encoded as depicted below: 996 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 997 1 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 999 +-+ 1000 | AVP Code 1001 | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1003 +-+ 1004 |V M r r r r r r| AVP Length 1005 | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1007 +-+ 1008 | Vendor ID (opt) 1009 | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1011 +-+ 1012 | Data 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1014 +-+ 1016 AVP Code 1018 TBD - MIPv6-Authorization 1020 Flag 'V' (Vendor-Specific) 1022 0 1024 Flag 'M' (Mandatory) 1026 0 1028 Flag 'r' (reserved) 1030 must be set to 0 1032 AVP Length 1034 the length of this AVP including the AVP Code, AVP 1035 Length, flags, Vendor-ID (if present) and Data. 1037 Data 1039 this field carries subsequent TLVs 1041 7.6 EAP-IKEv2 1043 EAP-IKEv2 [EAP-IKEv2] allows the transport of generic data in the 1044 form of IKEv2 payloads. The MIPv6-Authorization container is 1045 encoded as depicted below: 1047 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 1048 1 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1050 +-+ 1051 | Next Payload |C| RESERVED | Payload Length 1052 | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1054 +-+ 1055 | Data 1056 ~ 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1058 +-+ 1060 Next Payload (1 octet) 1062 TBD - MIPv6-Authorization 1064 Critical (1 bit) 1066 must be set to zero 1068 RESERVED (7 bits) 1070 must be sent as zero; must be ignored on receipt. 1072 Payload Length (2 octets) 1074 Length in octets of the current payload, including the 1075 generic 1076 payload header 1078 Data 1080 It contains subsequent TLVs 1081 8. New TLVs 1083 Independently from the EAP method used for network access 1084 authentication, the MIPv6-Authorization container enables to 1085 transport a series of TLVs. This gives more flexibility to the 1086 whole solution and permits the definition of new TLVs that do not 1087 need to be bound to a specific EAP method. 1089 The following TLVs have been defined so far: 1091 Service-Status-TLV 1092 Service-Selection-TLV 1093 Service-Options-TLV 1094 Home-Agent-Address-TLV 1095 Home-Address-TLV 1096 IKE-Authentication-Options-TLV 1097 IKE-Bootstrap-Information-TLV 1098 Negotiation-Result-TLV 1100 8.1 Service-Status-TLV 1102 This TLV is sent by the AAAH to inform the MN about the status of 1103 Mobile IPv6 service. It is defined as follows: 1105 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 1106 1 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1108 +-+ 1109 | Type=Service-Status | Length 1110 | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1112 +-+ 1113 | Code | 1114 +-+-+-+-+-+-+-+-+ 1116 Type 1118 TBD - Service-Status 1120 Length 1122 1 1124 Code 1126 0 = MIPv6 service is available 1127 1 = MIPv6 service is not available 1129 8.2 Service-Selection-TLV 1131 This TLV is sent by the MN to inform the AAAH whether it wants to 1132 activate MIPv6 service or whether the service is already active. 1134 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 1135 1 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1137 +-+ 1138 | Type=Service-Selection | Length 1139 | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1141 +-+ 1142 | Code | 1143 +-+-+-+-+-+-+-+-+ 1145 Type 1147 TBD - Service-Selection 1149 Length 1151 1 1153 Code 1155 0 = activate MIPv6 service 1156 1 = MIPv6 service already active 1157 2 = do not activate MIPv6 service 1159 8.3 Service-Options-TLV 1161 This TLV is used by the AAAH server to advertise the service 1162 options the MN can ask for. It is also used by the MN to 1163 communicate its selection to the AAAH. So far only the HA in 1164 visited domain option has been defined. The TLV has the following 1165 format: 1167 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 1168 1 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1170 +-+ 1171 | Type=Service-Options | Length 1172 | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1174 +-+ 1175 |V| Reserved | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 Type 1180 TBD - Service-Options 1182 Length 1184 2 1186 V 1187 from AAAH to MN: 1188 0 = AAAH cannot provide a HA in the visited domain 1189 1 = AAAH can provide a HA in the visited domain 1191 from MN to AAAH: 1192 0 = MN does not specify any preference on HA location 1193 1 = MN is requesting a HA in the visited domain 1195 Reserved 1197 15 bit reserved set to 0 1199 8.4 Home-Agent-Address-TLV 1201 This TLV carries the Home Agent�s address and it�s defined as 1202 follows: 1204 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 1205 1 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1207 +-+ 1208 | Type=HA-Address | Length 1209 | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1211 +-+ 1212 | 1213 | 1214 | Home Agent Address 1215 | 1216 | 1217 | 1218 | 1219 | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1221 +-+ 1223 Type 1225 TBD - Home-Agent-Address 1227 Length 1229 16 1231 Value 1233 Home Agent Address 1235 8.5 Home-Address-TLV 1237 This TLV carries the Home Address assigned to the MN. It is 1238 defined as follows: 1240 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 1241 1 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1243 +-+ 1244 | Type=Home-Address | Length 1245 | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1247 +-+ 1248 | 1249 | 1250 | Home Address 1251 | 1252 | 1253 | 1254 | 1255 | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1257 +-+ 1259 Type 1261 TBD - Home-Address 1263 Length 1265 16 1266 Value 1268 Home Address 1270 8.6 IKE-Authentication-Options-TLV 1272 This TLV carries data related to IKE bootstrapping. If used during 1273 the initial MIPv6 bootstrapping procedure, the value field 1274 contains the list of peer authentication methods supported by the 1275 MN. Otherwise, if used during re-authentication events, the value 1276 field contains only the peer authentication method currently in 1277 use. 1279 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 1280 1 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1282 +-+ 1283 |Type=IKE-Authentication-Options| Length 1284 | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1286 +-+ 1287 | AuthMethod-1 | AuthMethod-2 | ... 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1289 +-+ 1291 Type 1293 TBD - IKE-Authentication-Options 1295 Length 1297 Length of this TLV. 1299 Value 1301 AuthMethod � code corresponding to the authentication method 1302 supported for IKE phase 1. All the methods 1303 supported by the MN are inserted in order of 1304 preference. The following values are defined: 1306 Authentication Method AuthMethod 1308 PSK (pre-shared key generated by AAAH) 0 1309 AMSK (pre-shared key derived from EAP) 1 1310 CERT (use of certificates) 2 1312 8.7 IKE-Bootstrap-Information-TLV 1314 This TLV carries data related to the set-up of an IPsec Security 1315 Association with the Home Agent. It contains the peer 1316 authentication method to be used for IKE phase 1 and, eventually, 1317 the related cryptographic material (e.g. pre-shared key). 1319 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 1320 1 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1322 +-+ 1323 |Type= IKE-Bootstrap-Information| Length 1324 | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1326 +-+ 1327 | AuthMethod | key Length 1328 | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1330 +-+ 1331 | Key Lifetime 1332 | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1334 +-+ 1335 | Key Value 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1337 +-+ 1339 Type 1341 TBD - IKE-Bootstrap-Information 1343 Length 1345 Length of this TLV. 1347 Value 1349 AuthMethod � the authentication method to be used in IKE 1350 phase 1. This field can assume a value among 1351 those defined in section 8.6 (i.e. PSK, AMSK 1352 or CERT). 1354 Key Length � the length of the key to be used as pre-shared 1355 key 1356 for IKE phase 1 authentication. This field must 1357 be 1358 present if AuthMethod is set to PSK and may be 1359 present if AuthMethod is set to AMSK. 1361 Key Lifetime - the lifetime of the key in seconds. A value 1362 of 1363 all ones means infinite. This field is 1364 present 1365 only if the AuthMethod field is set to PSK or 1366 AMSK. 1368 Key Value � the value of the key. This field is present only 1369 if 1370 the AuthMethod field is set to PSK. 1372 8.8 Negotiation-Result-TLV 1374 It is defined as follows: 1376 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 1377 1 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1379 +-+ 1380 | Type=Negotiation-Result | Length 1381 | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1383 +-+ 1384 | Result-Code | 1385 +-+-+-+-+-+-+-+-+ 1387 Type 1389 TBD - Result 1391 Length 1393 1 1395 Value 1397 0 = Success 1398 128 = Failure 1400 8.9 Authorization-Lifetime-TLV 1402 It is defined as follows: 1404 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 1405 1 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1407 +-+ 1408 | Type= Authorization-Lifetime | Length 1409 | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1411 +-+ 1412 | Authorization-Lifetime | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 Type 1417 TBD - Authorization-Lifetime 1419 Length 1421 2 1423 Value 1425 The lifetime granted to the MN (in seconds) 1426 9. Security Considerations 1428 The Mobile IPv6 bootstrapping procedure described in this document 1429 assumes the MN and the AAA server of the home domain exchange the 1430 necessary parameters exploiting the EAP communication established 1431 for network access authentication. Therefore, to secure the 1432 bootstrapping procedure, the employed EAP method must support 1433 mutual authentication as well as integrity and replay protection. 1435 Moreover, if the pre-shared key needed to bootstrap the IPsec SA 1436 with the Home Agent is not derived from the EAP key hierarchy but 1437 explicitly delivered to the MN by the AAAH server, the EAP method 1438 must also provide confidentiality. Several tunneled and non 1439 tunneled EAP methods, like PEAPv2 and EAP-IKEv2, fulfill all of 1440 these security requirements. 1442 10. References 1444 10.1 Normative References 1446 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility 1447 Support 1448 in IPv6�, RFC 3775, June 2004. 1450 [RFC3776] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec 1451 to 1452 Protect Mobile IPv6 Signaling between Mobile Nodes and 1453 Home Agents", RFC 3776, June 2004. 1455 [RFC3748] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. 1456 Levkowetz, "Extensible Authentication Protocol (EAP)", 1457 RFC 3748, June 2004. 1459 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 1460 (IKE)", RFC 2409, November 1998. 1462 [PEAPv2] Palekar, A. et al., "Protected EAP Protocol (PEAP) 1463 Version 2", draft-josefsson-pppext-eap-tls-eap-11 1464 (work 1465 in progress), September 2005. 1467 [EAPKEYFWK] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., 1468 "Extensible Authentication Protocol (EAP) Key 1469 Management 1470 Framework", draft-ietf-eap-keying-14 (work in 1471 progress), 1472 June 2006. 1474 [MIPv6AMSK] Giaretta, G., Guardini, I., Demaria, E., Bournelle, 1475 J., Laurent-Maknavicius, M., "Application Master 1476 Session 1477 Key (AMSK) for Mobile IPv6", draft-giaretta-mip6-amsk- 1478 02 1479 (work in progress), October 2006 1481 10.2 Informative References 1483 [RFC4640] Patel, A., Giaretta, G., "Problem Statement for 1484 bootstrapping Mobile IPv6 (MIPv6)�, RFC 4640, 1485 September 2006. 1487 [RFC3753] Manner, J., Kojo, M. "Mobility Related Terminology�, 1488 RFC 1489 3753, June 2004. 1491 [RFC3041] Narten, T., Draves, R., "Privacy Extensions for 1492 Stateless 1493 Address Autoconfiguration in IPv6", RFC 3041, January 1494 2001. 1496 [AAAMIP6] Giaretta, G., Guardini, I., Demaria, E., Bournelle, 1497 J., 1498 Lopez, R., "AAA Goals for Mobile IPv6", draft-ietf- 1499 mip6-aaa-ha-goals-03 (work in progress), September 1500 2006 1502 [AAAMIPFWK] Yegin, A., "AAA Mobile IPv6 Application Framework", 1503 draft-yegin-mip6-aaa-fwk-01 (expired), February 1504 2005 1506 [RFC3084] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, 1507 F. 1508 Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS 1509 Usage for Policy Provisioning,", RFC 3084, March 2001. 1511 [MIPv6APP] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter 1512 Mobile IPv6 Application", draft-le-aaa-diameter- 1513 mobileipv6-04 (expired), November 2004. 1515 [PANA] Forsberg, D. et al., "Protocol for Carrying 1516 Authentication for Network Access (PANA)", draft-ietf- 1517 pana-pana-12 (work in progress), August 2006. 1519 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1520 "Introduction and Applicability Statements for 1521 Internet- 1522 Standard Management Framework", RFC 3410, December 1523 2002. 1525 [EAP-TTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS 1526 Authentication Protocol (EAP-TTLS)", draft-ietf- 1527 pppext- 1528 eap-ttls-05 (expired), July 2004. 1530 [EAP-IKEv2] Tschofenig, H., Kroeselberg, D., Ohba, Y., "EAP 1531 IKEv2 Method", draft-tschofenig-eap-ikev2-11 (work in 1532 progress), June 2006. 1534 [EAP-SIM] Haverinen, H. and J. Salowey, "Extensible 1535 Authentication 1536 Protocol Method for GSM Subscriber Identity Modules 1537 (EAP- 1538 SIM)", RFC 4186, January 2006. 1540 [EAP-AKA] Arkko, J. and H. Haverinen, "EAP-AKA Authentication", 1541 RFC 4187, January 2006. 1543 [EAP-FAST] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "The 1544 Flexible Authentication via Secure Tunneling 1545 Extensible 1546 Authentication Protocol Method (EAP-FAST)", draft-cam- 1547 winget-eap-fast-05.txt (work in progress), October 1548 2006. 1550 Acknowledgments 1552 The authors would like to thank Simone Ruffino, Tom Hiller, Hannes 1553 Tschofening, Rafael Marin Lopez, Hiroyuki Ohnishi, Mayumi 1554 Yanagiya, James Kempf and Yoshihiro Ohba for their valuable 1555 comments. 1557 Authors� Addresses 1559 Gerardo Giaretta 1560 Telecom Italia Lab 1561 via G. Reiss Romoli, 274 1562 10148 TORINO 1563 Italy 1564 Phone: +39 011 2286904 1565 Email: gerardo.giaretta@telecomitalia.it 1567 Ivano Guardini 1568 Telecom Italia Lab 1569 via G. Reiss Romoli, 274 1570 10148 TORINO 1571 Italy 1572 Phone: +39 011 2285424 1573 Email: ivano.guardini@telecomitalia.it 1575 Elena Demaria 1576 Telecom Italia Lab 1577 via G. Reiss Romoli, 274 1578 10148 TORINO 1579 Italy 1580 Phone: +39 011 2285403 1581 Email: elena.demaria@telecomitalia.it 1583 Julien Bournelle 1584 GET/INT 1585 9 rue Charles Fourier 1586 Evry 91011 1587 France 1588 Email: julien.bournelle@int-evry.fr 1590 Maryline Laurent-Maknavicius 1591 GET/INT 1592 9 rue Charles Fourier 1593 Evry 91011 1594 France 1595 Email: maryline.maknavicius@int-evry.fr 1596 Intellectual Property Statement 1598 The IETF takes no position regarding the validity or scope of any 1599 Intellectual Property Rights or other rights that might be claimed 1600 to pertain to the implementation or use of the technology described 1601 in this document or the extent to which any license under such 1602 rights might or might not be available; nor does it represent that 1603 it has made any independent effort to identify any such rights. 1604 Information on the procedures with respect to rights in RFC 1605 documents can be found in BCP 78 and BCP 79. 1607 Copies of IPR disclosures made to the IETF Secretariat and any 1608 assurances of licenses to be made available, or the result of an 1609 attempt made to obtain a general license or permission for the use 1610 of such proprietary rights by implementers or users of this 1611 specification can be obtained from the IETF on-line IPR repository 1612 at http://www.ietf.org/ipr. 1614 The IETF invites any interested party to bring to its attention any 1615 copyrights, patents or patent applications, or other proprietary 1616 rights that may cover technology that may be required to implement 1617 this standard. Please address the information to the IETF at 1618 ietf-ipr@ietf.org. 1620 Disclaimer of Validity 1622 This document and the information contained herein are provided on 1623 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1624 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1625 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1626 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1627 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1628 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1629 PARTICULAR PURPOSE. 1631 Copyright Statement 1633 Copyright (C) The Internet Society (2006). This document is subject 1634 to the rights, licenses and restrictions contained in BCP 78, and 1635 except as set forth therein, the authors retain all their rights. 1637 Acknowledgement 1639 Funding for the RFC Editor function is currently provided by the 1640 Internet Society.