idnits 2.17.1 draft-giaretta-mip6-authorization-eap-03.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 1475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1465. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1481), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (March 2006) is 6616 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 486, but not defined == Missing Reference: 'Home-Agent-Address' is mentioned on line 487, but not defined == Missing Reference: 'Home-Address' is mentioned on line 487, but not defined == Missing Reference: 'Interface-Identifier' is mentioned on line 488, but not defined == Missing Reference: 'IKE-Authentication-Options' is mentioned on line 489, but not defined == Unused Reference: 'EAPKEYFWK' is defined on line 1331, but no explicit reference was found in the text == Unused Reference: 'RFC3084' is defined on line 1361, but no explicit reference was found in the text == Unused Reference: 'MIPv6APP' is defined on line 1365, but no explicit reference was found in the text == Unused Reference: 'PANA' is defined on line 1369, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 1373, 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-09 == Outdated reference: A later version (-02) exists of draft-giaretta-mip6-amsk-01 -- Possible downref: Normative reference to a draft: ref. 'MIPv6AMSK' == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-04 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-01 == Outdated reference: A later version (-01) exists of draft-yegin-mip6-aaa-fwk-00 == Outdated reference: A later version (-04) exists of draft-le-aaa-diameter-mobileipv6-03 == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-11 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-10 == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-03 Summary: 7 errors (**), 0 flaws (~~), 21 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: September 2006 E. Demaria 5 Telecom Italia 6 J. Bournelle 7 M. Laurent-Maknavicius 8 GET/INT 9 March 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 months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on September 7, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). All Rights Reserved. 43 Abstract 45 This draft defines an architecture, and related protocols, for 46 performing dynamic Mobile IPv6 authorization and configuration 47 relying on a AAA infrastructure. The necessary interaction between 48 the AAA server of the home provider and the mobile node is realized 49 using EAP, exploiting the capability of some EAP methods to convey 50 generic information items together with authentication data. This 51 approach has the advantage that the access equipment acts as a simple 52 pass-through for EAP messages and therefore does not play any active 53 role in the Mobile IPv6 negotiation procedure, which makes the 54 solution easier to deploy and maintain. 55 Table of Contents 57 1. Introduction................................................3 58 2. Terminology.................................................4 59 3. Protocol Overview...........................................5 60 4. Requirements on EAP methods................................10 61 5. Detailed description of the Protocol.......................12 62 5.1 Mobile node bootstrapping...............................12 63 5.2 Management of re-authentication events..................17 64 6. Home Agent considerations..................................19 65 6.1 Requirements on AAAH-HA communication...................19 66 6.2 Management of MIPv6 authorization state.................20 67 7. The MIPv6-Authorization container..........................22 68 7.1 PEAPv2..................................................22 69 7.2 EAP-FAST................................................23 70 7.3 EAP-SIM.................................................23 71 7.4 EAP-AKA.................................................24 72 7.5 EAP-TTLS................................................24 73 7.6 EAP-IKEv2...............................................25 74 8. New TLVs...................................................26 75 8.1 Service-Status-TLV......................................26 76 8.2 Service-Selection-TLV...................................27 77 8.3 Service-Options-TLV.....................................27 78 8.4 Home-Agent-Address-TLV..................................28 79 8.5 Home-Address-TLV........................................28 80 8.6 IKE-Authentication-Options-TLV..........................29 81 8.7 IKE-Bootstrap-Information-TLV...........................30 82 8.8 Negotiation-Result-TLV..................................31 83 8.9 Authorization-Lifetime-TLV..............................32 84 9. Security Considerations....................................33 85 10. References.................................................34 86 10.1 Normative References..................................34 87 10.2 Informative References................................34 88 Acknowledgments.................................................36 89 Authors' Addresses..............................................36 90 Intellectual Property Statement.................................38 91 1. Introduction 93 Mobile IPv6 [RFC3775] requires that Mobile Nodes (MNs) and Home 94 Agents (HAs) share a set of configuration parameters: the MN must 95 know its Home Address, the Home Agent Address and the cryptographic 96 material needed to protect MIPv6 signaling (e.g. shared keys or 97 certificates to setup an IPsec security association). MIPv6 base 98 protocol does not specify any method to automatically acquire this 99 information; which means that network administrators are normally 100 required to manually set configuration data on MNs and HAs. 102 Manual configuration of Home Agents and Mobile Nodes also works as an 103 implicit method for Mobile IPv6 authorization, because only the users 104 that have been administratively enabled on a specific Home Agent are 105 allowed to exploit Mobile IPv6 and its features. 107 However, in a large network (e.g. the network of a mobile operator), 108 which may include millions of users and many Home Agents, the 109 operational and administrative burden of this procedure may easily 110 become overwhelming. In addition, the extensive use of manual and 111 static configurations limits the flexibility and reliability of the 112 system, in that it is not possible to dynamically assign the HA when 113 the user enters the network, which would help to optimize performance 114 and resource utilization (e.g. assignment of the HA closest to the 115 MN's point of attachment). 117 This is generally referred to as the Mobile IPv6 bootstrapping 118 problem. As discussed in [MIPv6PS], several bootstrapping scenarios 119 can be identified depending on the relationship between the network 120 operator providing IP services to the MN (Access Service Provider, 121 ASP) and the service provider managing the HA (Mobility Service 122 Provider, MSP). This document describes a solution to the 123 bootstrapping problem that is applicable in a scenario where the ASP 124 and the MSP are the same provider (Integrated ASP, IASP). 126 The proposed solution performs dynamic Mobile IPv6 authorization and 127 configuration together with MN authentication for network access. 128 MIPv6 negotiation and bootstrapping is controlled by the AAA server 129 of the home provider (IASP), that interacts with the mobile node 130 relying on AAA routing and EAP, exploiting the capability of some EAP 131 methods (e.g. PEAPv2 [PEAPv2], EAP-FAST [EAP-FAST]) to convey generic 132 information items together with authentication data. 134 2. Terminology 136 General mobility terminology can be found in [RFC3753]. The following 137 additional terms are used here: 139 ASP Access Service Provider 141 IASP Integrated Access Service Provider 143 MSP Mobility Service Provider 145 AAA Authentication Authorization Accounting 147 AAAH AAA server of the Home domain 148 3. Protocol Overview 150 The basic idea behind the solution proposed herewith is to perform 151 Mobile IPv6 bootstrapping during the authentication procedure 152 undertaken by the Mobile Node to gain network access. 153 In particular, this draft defines a method to: 155 - explicitly authorize the use of Mobile IPv6 based on the service 156 profile of the user, its position within the network, etc. 158 - dynamically allocate a Home Agent to the Mobile Node; 160 - dynamically configure Mobile IPv6 start-up parameters (i.e. MIPv6 161 bootstrapping) on the Mobile Node. These parameters include the 162 Home Address and the cryptographic material needed to set-up the 163 IPsec Security Association used to protect Mobile IPv6 signaling 164 (i.e. Binding Updates and Binding Acknowledgements). 166 Figure 1 shows the overall architecture of the solution proposed in 167 this draft. The central element of the architecture is the AAA server 168 of the Home Domain (i.e. AAAH), which interacts with both the MN and 169 the selected HA to perform service authorization and configuration. 171 AAA 172 Client 173 IEEE 802.1x +------+ RADIUS 174 or PANA | | or Diameter 175 +--------+ /--------------EAP Exchange-----------------\ +--------+ 176 | Mobile |/ <------------Authentication---------------> \| AAAH | 177 | Node |\ <--MIPv6 authorization and configuration--> /| Server | 178 +--------+ \-------------------------------------------/ +--------+ 179 | | /\ 180 +------+ /||\ 181 Router || 182 or AP AAAH-HA || 183 (pass through) Protocol || 184 \||/ 185 \/ 186 +--------+ 187 | Home | 188 | Agent | 189 +--------+ 191 Figure 1 - Solution architecture 193 The solution is applicable to any access network relying on EAP 194 [RFC3748] for user authentication and works with all EAP methods 195 supporting the exchange of general purpose information elements, in 196 any form (e.g. TLVs or AVPs), between EAP peers. Exploiting this 197 capability, MN and AAAH can piggyback Mobile IPv6 negotiation 198 messages within the same EAP conversation used to carry out user 199 authentication. 201 This kind of operation is already supported by several tunneled (e.g. 202 PEAPv2 [PEAPv2]) and non tunneled (e.g. EAP-IKEv2 [EAP-IKEv2]) EAP 203 methods, that also include native support for encryption, 204 authentication and integrity protection of exchanged configuration 205 data (e.g. HA address). 207 Figure 2 shows an overview of the procedure defined to handle MIPv6 208 bootstrap on the Mobile Node. For the sake of simplicity it is 209 assumed that the employed AAA protocol is Diameter, but obviously 210 RADIUS is suitable as well. 212 EAP over 213 IEEE 802.1x EAP over Diameter AAAH-HA 214 or PANA AAA (or RADIUS) AAAH Protocol 215 MN +---------+ Client +----------------+ Server +-------------+ HA 217 1) <--Req. Id.--- 218 --Identity---> --Diameter EAP Req.--> 219 /-------------------------------------\ 220 2) / Set-up of protected channel \ 221 \ e.g. TLS Tunnel (optional) / 222 \-------------------------------------/ 223 /-------------------------------------\ 224 3) / Authentication \ 225 \ Phase / 226 \-------------------------------------/ 227 /-------------------------------------\ +-+ /--------------\ +-+ 228 4) / Mobile IPv6 service \| |/ HoA selection \| | 229 \ authorization and configuration /| |\ and HA config. /| | 230 \-------------------------------------/ +-+ \--------------/ +-+ 231 Home Agent State 232 Selection Set-up 234 5) <-----EAP----- <-----Diameter EAP---- 235 Success/Failure Answer (Success/Failure 236 and authorization AVPs) 238 /----------------------------------------------------------\ 239 6) / Set-up Security Association MN-HA and \ 240 \ Mobile IPv6 registration (exchange of BU and BA) / 241 \----------------------------------------------------------/ 243 Figure 2 - Overview of Mobile IPv6 bootstrap procedure 244 The whole procedure can be divided in six steps: 246 1. EAP identity exchange (i.e. exchange of EAP Request Identity and 247 EAP Response Identity messages); 249 2. set-up of a protected channel (e.g. TLS tunnel) for the delivery 250 of subsequent EAP signaling. This is an optional step that is 251 present only if the EAP method provides confidentiality support. 252 It is mandatory only if the MIPv6 negotiation procedure involves 253 the exchange of sensitive information; 255 3. authentication phase. The actual authentication procedure and its 256 security properties depend on the selected EAP method. In tunneled 257 EAP methods (e.g. PEAPv2) this step may involve one or more 258 complete EAP conversations occurring within a previously 259 negotiated TLS session. Each EAP conversation may accomplish user 260 authentication relying on any available EAP method (e.g. EAP-MD5, 261 EAP-SIM, EAP-AKA); 263 4. Mobile IPv6 service authorization and configuration. MN and AAAH 264 exchange a sequence of signaling messages to authorize and 265 configure Mobile IPv6. Those messages are encapsulated as 266 requested by the employed EAP method (e.g. TLVs or AVPs) and 267 delivered as part of the on-going EAP session. If the EAP method 268 provides confidentiality this protocol handshake is encrypted 269 using the previously negotiated ciphersuite. During this phase, 270 AAAH selects a suitable Home Agent for the MN and exchanges 271 authorization and configuration data with it using a AAAH-HA 272 protocol, whose specification is out of the scope of the present 273 document. Further analysis on the definition of such an interface 274 can be found in [AAAH-HA] and [AAAMIPFWK]. At the end of this 275 phase, the MN knows its own Home Address, the address of the 276 correspondent Home Agent, the peer authentication method (i.e. 277 certificates or pre-shared key) and the cryptographic material 278 (e.g. pre-shared key) needed to set-up an IPsec security 279 association with IKE [RFC2409]. The IKE pre-shared key can be 280 either constructed by AAAH and then delivered to MN in a proper 281 TLV (or AVP) or independently derived by MN and AAAH from the EAP 282 key hierarchy; 284 5. EAP session termination. Assuming the mobile node has been 285 successfully authenticated, the AAAH server sends a Diameter EAP 286 Answer message with Result-Code equal to SUCCESS. The AAA client 287 extracts the EAP Success message from the Diameter EAP Answer and 288 forwards it to the MN terminating the EAP session; 290 6. set-up of IPsec Security Association and MIPv6 registration. At 291 the end of the EAP communication, the MN gains network access and 292 acquires a valid Care-of Address within the visited subnet (e.g. 294 via stateless autoconfiguration); then it performs an IKE exchange 295 to establish the IPsec Security Association with the HA, using the 296 authentication method and the cryptographic material negotiated 297 during the MIPv6 service configuration phase (step 4). Finally, 298 the MN performs MIPv6 registration, sending a Binding Update 299 (protected with IPsec) to the HA. 301 This draft also defines the procedures to handle re-authentication 302 events and to manage the termination of the Mobile IPv6 session. 304 In summary, the proposed architecture has the following advantages: 306 - allows the MSP to maintain a centralized management (on the AAA 307 server) of the user profiles and the authentication, authorization 308 and accounting procedures for any type of service, including 309 Mobile IPv6; 311 - improves the reliability and performance of the Mobile IPv6 312 protocol, in that the HA to be dynamically assigned to the MN can 313 be freely chosen among those that are closest to the user's point 314 of attachment, thus optimizing network usage and reducing the 315 transfer delay for data traffic in bi-directional tunneling; 317 - can be deployed, or extended with new features, without having to 318 update the access equipment and the AAA protocols in use. Only 319 minor changes in the AAA servers, the Home Agents and the mobile 320 terminals are required, in that the AAA client does not play any 321 active role in MIPv6 negotiation (i.e. it is a pass-through for 322 EAP signaling). This reduces the deployment costs and makes the 323 solution easy to use even when a Mobile Node is roaming with a 324 provider different from its own; 326 - allows the usage of any AAA protocol supporting the transport of 327 EAP messages for the communication between the AAA client and 328 server (i.e. not just Diameter, but also RADIUS). This 329 significantly simplifies the deployment of MIPv6 in existing 330 communication networks, where support for Diameter protocol in 331 access equipment is not so extensive. 333 - allows the operator to dynamically choose the authentication 334 method for IKE bootstrapping and to automatically distribute the 335 pre-shared key eventually needed; in this way the pre-shared key 336 must not be pre-configured and can be frequently changed 337 increasing resistance to attacks. In the case of an EAP method 338 providing dynamic generation of keying material the pre-shared key 339 can be derived from EAP hierarchy avoiding the need to explicitly 340 send it to the MN [MIPv6AMSK]. 342 As a whole, the solution adds a maximum of 2 RTTs (see the detailed 343 protocol description in section 5) to the EAP conversation carried 344 out by the mobile node to authenticate itself and gain network 345 access. The number of extra RTTs can be reduced if the employed EAP 346 method has the capability of transporting MIPv6 negotiation TLVs (or 347 AVPs) together with authentication data. Nonetheless, it should be 348 noted that the full negotiation procedure can be undertaken by the MN 349 only during its initial bootstrapping, and therefore the performance 350 requirements are not so strict. 352 4. Requirements on EAP methods 354 In EAP methods, the EAP peer and EAP server exchange data in order to 355 authenticate the EAP peer and eventually the EAP server (mutual 356 authentication). This draft proposes the use of these exchanges to 357 transport MIPv6 parameters, as part of an handshake that requires at 358 maximum 2 RTTs. Thus, the main requirement for the applicability of 359 the solution is: 361 - the EAP method must provide a way to carry arbitrary parameters 362 during or after the authentication phase. This implies that the 363 EAP method must provide messages and mechanisms for this purpose. 365 Then, for security reasons, the EAP method must provide the following 366 properties: 368 - mutual authentication: the EAP method must provide mutual 369 authentication. The access network must authenticate users 370 before granting them Mobile IPv6 service and the EAP peer should 371 authenticate the access network before delivering sensitive 372 data; 374 - integrity: the exchanged MIPv6 parameters must be protected 375 against any alteration and thus the EAP method must provide 376 integrity protection; 378 - replay protection: the EAP messages containing MIPv6 parameters 379 must be protected against Replay Attack, so that an attacker is 380 not able to get previous given data by replaying an old request; 382 - confidentiality: depending on which data the AAA server provides 383 to the mobile node (e.g. an IKE pre-shared key), it may be 384 necessary to protect the message exchange against eavesdropping. 386 The table below checks some existing EAP methods against the 387 requirements listed above. 389 M-A: Mutual Authentication 390 R-P: Replay Protection 392 +---+----------+---+---------------+-------------+ 393 | | | | | Exchange | 394 |M-A| Integrity|R-P|Confidentiality| of arbitrary| 395 | | | | | Parameters | 396 +------------+---+----------+---+---------------+-------------+ 397 | PEAPv2 | x | x | x | x | x | 398 +------------+---+----------+---+---------------+-------------+ 399 | EAP-FAST | x | x | x | x | x | 400 +------------+---+----------+---+---------------+-------------+ 401 | EAP-TTLS | x | x | x | x | x | 402 +------------+---+----------+---+---------------+-------------+ 403 | EAP-IKEv2 | x | x | x | x | x | 404 +------------+---+----------+---+---------------+-------------+ 405 | EAP-SIM | x | x | x | x | x | 406 +------------+---+----------+---+---------------+-------------+ 407 | EAP-AKA | x | x | x | x | x | 408 +------------+---+----------+---+---------------+-------------+ 409 | EAP-TLS | x | x | x | x | | 410 +------------+---+----------+---+---------------+-------------+ 411 | EAP-MD5 | | | | | | 412 +------------+---|----------|---|---------------|-------------| 414 In summary, it is possible to note that the procedure described in 415 this draft can be successfully undertaken with several tunneled 416 (PEAPv2, EAP-FAST and EAP-TTLS) and non tunneled EAP methods (EAP- 417 IKEv2, EAP-SIM, EAP-AKA), that all support the transport of arbitrary 418 parameters. 420 5. Detailed description of the Protocol 422 This section details the procedures and message exchanges that can be 423 adopted by the network operator to explicitly authorize the 424 activation of Mobile IPv6 support for a specific user as well as 425 enable dynamic bootstrapping of MIPv6 protocol parameters (e.g. Home 426 Address, Home Agent Address). 428 5.1 Mobile node bootstrapping 430 If EAP is used for access control, when the MN enters the network it 431 is immediately polled for its identity, by means of an EAP Request 432 Identity message. This message is used to start the EAP 433 communication. The MN replies sending its identity, in the form of a 434 NAI (Network Access Identifier), within an EAP Response Identity 435 message, that is received by a AAA client (e.g. the Access Point in 436 the case of a Wireless LAN) and forwarded via AAA routing to the AAAH 437 server using the Diameter EAP Application (or the RADIUS EAP 438 extensions). Then the AAAH server selects an EAP method (e.g. based 439 on the user service profile) and proposes it to the MN in subsequent 440 EAP messages. In order to enable the Mobile IPv6 negotiation 441 procedure defined in this document, the EAP method chosen by the AAAH 442 server must be an EAP method supporting the transport of general 443 purpose and variable length information elements, in the form of TLVs 444 (or AVPs), together with authentication data (see section 4). 446 After this initial handshake, MN and AAAH undertake the actual 447 authentication phase, that may require the exchange of a variable 448 number of EAP Request/Response messages. In many EAP methods, like 449 PEAPv2 or EAP-IKEv2, the authentication phase is preceded by the 450 establishment of an encrypted channel between MN and AAAH that 451 provides protection capabilities (i.e. privacy, integrity protection, 452 etc.) for all the messages exchanged during the rest of the EAP 453 conversation. 455 As soon as the authentication phase is completed, the procedure for 456 MIPv6 bootstrapping may take place. For that purpose, the MN and the 457 AAAH server exploit the on-going EAP communication to exchange a 458 sequence of signaling messages transporting configuration parameters. 460 All the messages used for MIPv6 bootstrapping are encoded in TLVs 461 carried by a generic MIPv6-Authorization container. This choice 462 simplifies a lot the deployment of the procedure with any EAP method 463 satisfying the requirements listed in section 4. In fact, only the 464 structure of the MIPv6-Authorization container needs to be adapted to 465 the actual message format of the employed EAP method. 467 For the sake of simplicity, in this section it is assumed that the 468 EAP method used for network access authentication supports the 469 transport of arbitrary parameters in TLV format. In this case the 470 MIPv6-Authorization container becomes a MIPv6-Authorization-TLV. 471 Nonetheless, in section 7 the format of the container is defined for 472 all the EAP methods identified in section 4. 474 The whole bootstrapping procedure is depicted in Figure 3. 476 AAAH 477 MN +----------------------------+ Server +----------------+ HA 479 <--------------------- 480 MIPv6-Authorization-TLV( 481 Service-Status, 482 [Service-Options]) 484 -----------------------> 485 MIPv6-Authorization-TLV( 486 Service-Selection, [Service-Options], 487 [Home-Agent-Address], [Home-Address], 488 [Interface-Identifier], 489 [IKE-Authentication-Options]) 490 +-+ +-+ 491 | |/----------------\| | 492 | |\----------------/| | 493 +-+ +-+ 494 Home Agent HA 495 Selection Conf. 497 <--------------------- 498 MIPv6-Authorization-TLV( 499 Home-Address, Home-Agent-Address, 500 IKE-Bootstrap-Information, 501 Authorization-Lifetime) 503 -----------------------> 504 MIPv6-Authorization-TLV( 505 Negotiation-Result) 507 Figure 3 - MIPv6 bootstrapping procedure 509 AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6- 510 Authorization-TLV including the following TLVs: 512 - Service-Status-TLV: used to communicate whether the home domain is 513 willing to provide Mobile IPv6 service to the MN. This might 514 depend on the user service profile or on other administrative 515 rules (e.g. service accountability); 516 - Service-Options-TLV (optional): used to specify other service 517 options the MN can ask for (e.g. allocation of a HA in the visited 518 domain). 520 MN replies to this first message confirming its intention to start 521 Mobile IPv6 and, optionally, providing a set of hints on the desired 522 service capabilities; this is achieved delivering a MIPv6- 523 Authorization-TLV including the following TLVs: 525 - Service-Selection-TLV: used by the MN to specify if it is willing 526 to activate Mobile IPv6 protocol operation; 528 - Service-Options-TLV (optional): used by the MN to communicate 529 which service options, among those previously advertised by AAAH, 530 it would like make use of; 532 - Home-Agent-Address-TLV (optional): used by the MN to suggest a 533 preferred Home Agent. This can be a HA with whom the MN has a pre- 534 configured Security Association or a HA acquired through dynamic 535 HA address discovery. The AAAH server treats this indication just 536 as a hint, which means that, for administrative reasons, the MN 537 may be assigned a Home Agent different from the one previously 538 requested; 540 - Home-Address-TLV (optional): used by the MN to suggest a preferred 541 Home Address (e.g. an address pre-configured on one of its network 542 interfaces); like the previous TLV, this indication is considered 543 only as a hint by the AAAH server; 545 - Interface-Identifier-TLV (optional): through this TLV, the MN can 546 suggest a preferred Interface Identifier (selected according to 547 [RFC3041] or following other criteria) to be used by the AAA 548 infrastructure to build the Home Address starting from the 549 selected home prefix. Also in this case, this information, if 550 present, is treated as a pure hint by the AAAH server. 552 - IKE-Authentication-Options-TLV (optional): through this TLV, the 553 MN communicates to the AAAH server in order of preference the peer 554 authentication methods it supports for IKE bootstrapping. The lack 555 of this TLV means that the MN supports only the default method. 557 The solution described in this document supports the following 558 methods for peer authentication in IKE phase 1: 560 - use of a pre-shared key (PSK) derived by the AAAH server and sent 561 to the MN and the HA; in this case confidentiality must be 562 provided by both the AAAH-HA protocol and the EAP session between 563 the MN and the AAAH server. This is the default method. 565 - use of a pre-shared key independently derived by the MN and the 566 AAAH server from the keying material exported by the employed EAP 567 method. This key can be derived from an Application Master Session 568 Key (AMSK) specific to Mobile IPv6, which can be constructed as 569 explained in [MIPv6AMSK]. The PSK is then delivered by the AAAH 570 server to the HA by means of a AAAH-HA protocol providing 571 confidentiality; 573 - use of digital certificates. This solution involves the employment 574 of digital signatures and public key encryption as stated in 575 [RFC2409]. This method requires the availability of a PKI. 577 If in the Service-Selection-TLV the MN has chosen not to make use of 578 Mobile IPv6, AAAH terminates the EAP communication sending an EAP 579 Success message, since the authentication procedure has been 580 accomplished successfully. 582 Otherwise, if the MN has confirmed its willingness to start MIPv6 583 service, AAAH selects a suitable Home Agent through a Home Agent 584 Selection Algorithm. Possible parameters to be taken into account by 585 this algorithm include: current load of available HAs (e.g. number of 586 active bindings), location of the MN and, eventually, the preferences 587 provided by the MN itself in the previous message exchange (i.e. 588 Service-Options-TLV, Home-Agent-Address-TLV, Home-Address-TLV, IKE- 589 Authentication-Options-TLV). For example, based on the knowledge of 590 the MN's current point of attachment (i.e. the current AAA client), 591 the AAAH server may select, among the HAs available in the home 592 domain, the one that is closest to the MN in terms of IP routing 593 hops. This approach is normally expected to improve performance. 594 However, the detailed definition of a Home Agent Selection Algorithm 595 is out of the scope of this document. 597 After a suitable HA has been identified, the AAAH server selects the 598 peer authentication method to be used in IKE phase 1. The peer 599 authentication methods supported by the MN are known from the IKE- 600 Authentication-Options-TLV received during the previous exchange. If 601 possible, the AAAH server should choose the method on top of the list 602 provided by the MN (i.e. the one with the highest preference). 604 As soon as the peer authentication method has been identified, the 605 AAAH server interacts with the HA to dynamically configure the state 606 needed to enable subsequent MIPv6 protocol operations, including the 607 authorization lifetime of the MIPv6 service granted to the MN and the 608 necessary security parameters (e.g. pre-shared key). Possible 609 protocols that can be used for this purpose include Diameter (through 610 a new Diameter Application), SNMPv3 or COPS-PR. Further details about 611 this communication are provided in section 6. Anyway, the detailed 612 specification of the interface between AAAH and HA is out of the 613 scope of this document. Additional considerations on the nature and 614 goals of such an interface can be found in [AAAH-HA] and [AAAMIPFWK]. 616 The security parameters that the AAAH server delivers to the HA may 617 vary depending on the peer authentication method chosen for IKE 618 bootstrapping: 620 - if the AAAH server selects pre-shared key as peer authentication 621 method it needs to send the chosen PSK (randomly generated or 622 derived from the EAP key hierarchy) to the HA together with the 623 associated lifetime; 625 - if the AAAH server selects a peer authentication method based on 626 certificates it does not need to derive keys nor to send security 627 parameters to the HA. 629 After the AAAH server has configured the state on the HA, it 630 continues the EAP session communicating to the MN all the MIPv6 631 configuration data it is waiting for. This is achieved delivering to 632 the MN an EAP Request containing a MIPv6-Authorization-TLV and the 633 following sub-TLVs: Home-Address-TLV (i.e. the home address), Home- 634 Agent-Address-TLV (i.e. the address of the HA), IKE-Bootstrap- 635 Information-TLV (i.e. the peer authentication method to be used in 636 IKE phase 1 and associated cryptographic material) and Authorization- 637 Lifetime-TLV (i.e. the lifetime granted to the MN for this session). 639 After the MN has received all the configuration data from the AAAH 640 server (i.e. HA address, Home Address and IKE bootstrap information), 641 it sends back an EAP Response containing a Negotiation-Result-TLV, 642 stating whether it accepts, or refuses, the proposed arrangement. If 643 the MN refuses the configuration, the AAAH server should immediately 644 release the resources previously allocated on the Home Agent. 646 After the completion of the EAP session, MN holds all data needed to 647 perform Mobile IPv6 registration: the MN knows its Home Address, the 648 address of the correspondent Home Agent and all cryptographic data 649 needed to establish the IPsec security association with it; 650 furthermore, since it has been successfully authenticated, the MN can 651 acquire an IPv6 address to be used as Care-of Address. 653 The first operation carried out by the MN after the acquisition of 654 the Care-of Address is the establishment of the IPsec Security 655 Association with the HA, that is mandated by [RFC3775] to protect 656 MIPv6 location update signaling. Set-up of the IPsec SA can be 657 accomplished following the procedure detailed in [RFC3776]. 659 As soon as the IPsec Security Association is established, MN can send 660 a Binding Update to the HA, thus starting up Mobile IPv6 service. 662 5.2 Management of re-authentication events 664 At the expiration of AAA session time-outs or after a change in the 665 point of attachment to the network (e.g. change of Access Point), a 666 re-authentication procedure is performed leading to the user identity 667 to be checked again along with its right to continue exploiting 668 network resources. To that purpose the AAAH server may repeat a full 669 authentication or, alternatively, decide to use optimizations in 670 order to make the procedure faster. Once this phase is completed the 671 AAAH server also undertakes the re-negotiation of the MIPv6 service. 673 Since the MIPv6 bootstrapping procedure is assumed to be completely 674 stateless, when a re-authentication event occurs the AAAH server may 675 not know the state of the MIPv6 service on the MN. For this reason 676 the AAAH server starts the MIPv6 negotiation like in the 677 bootstrapping case: it delivers a MIPv6-Authorization-TLV containing 678 a Service-Status-TLV and optionally a Service-Options-TLV. 680 If the MIPv6 service is not active on the MN the procedure continues 681 as described in section 5.1. Otherwise, the MN replies with a MIPv6- 682 Authorization-TLV containing a Service-Selection-TLV indicating that 683 the MIPv6 service is already in use. Furthermore, the MN inserts the 684 Home-Agent-Address-TLV, the Home-Address-TLV and the IKE- 685 Authentication-Options-TLV to inform the AAAH server about its 686 current state. The AAAH server can then get in touch with the HA to 687 check the integrity of the state, renew the MIPv6 authorization 688 lifetime and eventually refresh the security parameters. 690 If the peer authentication method used by the MN in IKE phase 1 is 691 pre-shared key, the AAAH server must derive a new PSK and send it to 692 the HA together with the associated lifetime. In case the PSK is not 693 derived from the EAP key hierarchy (i.e. it is randomly generated by 694 the AAAH server), the AAAH server must communicate it also to the MN. 695 Instead, in case of authentication based on certificates, the AAAH 696 server does not need to derive keys nor deliver additional security 697 data to the HA and the MN. 699 If the state on the HA is successfully updated, the AAAH server 700 terminates the EAP communication sending an EAP Success message. 701 Otherwise, the AAAH server should continue the EAP communication 702 renegotiating the MIPv6 service (i.e. allocation of a new HA and 703 related Home Address). 705 This solution can be easily deployed even within a network including 706 several AAA servers, each one managing a subset of the available 707 Network Access Servers (NASs). This is because the re-negotiation 708 procedure does not assume to have any long term state related to 709 Mobile IPv6 stored on the AAAH server. In this way, everything works 710 correctly even if, due to MN's movements within the network, the AAAH 711 server that handles the re-authentication is not the same server that 712 authenticated the MN for the first time and performed the MIPv6 713 bootstrapping procedure. 715 As explained above, the re-authentication events are normally 716 triggered by the network. Nonetheless, if the EAP lower layer offers 717 a way to trigger EAP re-authentications (e.g. PANA supports this 718 feature), it may be possible for the MN to re-negotiate the MIPv6 719 service at any time. 721 6. Home Agent considerations 723 This section provides further thoughts about the AAAH-HA 724 communication and lists specific features that have to be supported 725 by the Home Agent to allow dynamic negotiation of Mobile IPv6 726 protocol parameters. 728 6.1 Requirements on AAAH-HA communication 730 This draft details only the message exchange between the MN and the 731 AAAH server. Obviously a complete Mobile IPv6 bootstrapping solution 732 requires also the definition of a mechanism for the communication 733 between the AAAH server and the Home Agent. Possible protocols that 734 may be used for this purpose include SNMPv3, COPS-PR or Diameter but 735 a formal definition of such a protocol is out of scope of this 736 document. 738 A detailed analysis of the goals for a generic AAAH-HA protocol can 739 be found in [AAAH-HA]; in this section some requirements, specific to 740 this scenario, are highlighted. 742 The selected protocol should allow the AAAH server to: 744 - use a Network Access Identifier (NAI) to identify the mobile node 745 in the communication with the HA; 747 - send an authorization lifetime to the HA to limit Mobile IPv6 748 session duration for the MN; 750 - send to the HA a set of hints for the construction of the Home 751 Address (e.g. a preferred Home Address or a preferred Interface 752 Identifier); 754 - poll the designated HA for the allocation of a Home Address to the 755 MN; 757 - force the HA to terminate an active Mobile IPv6 session for 758 authorization policy reasons (e.g. credit exhaustion or 759 reallocation of a new HA to the MN); 761 - enforce explicit operational limitations and authorization 762 restrictions on the HA (e.g. packet filters, QoS parameters); 764 - retrieve the Mobile IPv6 state associated to a specific MN from 765 the correspondent HA. This may be useful to periodically verify 766 the Mobile IPv6 service status; 767 - send to the HA the security data needed to setup the IPsec SA with 768 the MN. Possible security data are the authentication method and 769 the cryptographic material to be used for IKE bootstrapping. 771 Moreover, the protocol selected to implement the communication 772 between the AAAH server and the HA should fulfill the following 773 general requirements: 775 - the AAAH server and the HA must be able to authenticate each other 776 (mutual authentication) in order to prevent the installation of 777 unauthorized state on the HA; 779 - the AAA-HA interface must provide integrity protection in order to 780 prevent any alteration of exchanged data (e.g. Mobile IPv6 781 configuration parameters); 783 - the AAA-HA interface must provide replay protection; 785 - the AAA-HA interface should provide confidentiality since it may 786 be used to transfer security parameters (e.g. IKE pre-shared key); 788 - the AAA-HA interface should support inactive peer detection. This 789 functionality can be used by the AAAH server to maintain a list of 790 active HAs (e.g. useful for HA selection); 792 6.2 Management of MIPv6 authorization state 794 The Home Agent is required to store some authorization data for each 795 of the MNs it is serving. A new data structure may be used for this 796 purpose and it should include at least the following fields: 798 - NAI of the user; 800 - Home Address assigned to the MN; 802 - Cryptographic Data: this field includes the peer authentication 803 method to be used in IKE and, if needed, the pre-shared key and 804 its lifetime; 806 - Authorization Lifetime: it is the lifetime of the Mobile IPv6 807 service granted to the MN; 809 At the expiration of the Authorization Lifetime the HA should check 810 if there is an active entry for the MN in its Binding Cache in order 811 to verify if the MN is still using Mobile IPv6. If the entry is 812 available the Home Agent should negotiate with the AAAH server an 813 extension of the Authorization Lifetime granted to the MN. Otherwise, 814 the HA should immediately release the authorization state associated 815 to that MN and eventually notify the session termination to the AAAH 816 server (e.g. by means of a Session Termination Request if the 817 employed AAAH-HA protocol is Diameter). 819 Moreover, the release of the resources previously allocated on the 820 Home Agent can be undertaken at any time by the AAAH server. 821 Typically this happens at credit exhaustion or when the MN 822 disconnects from the network. 824 The policies adopted by the AAAH server to release the resources 825 allocated to the MN may vary depending on the user service profile. 826 For instance, the AAAH server may decide to postpone the release of 827 the resources on the HA in order to allow the MN to continue using 828 the Mobile IPv6 service even if it has moved to an access network for 829 which no roaming agreements are in place (e.g. a corporate network or 830 a network providing cost-free access). In that case, the MN can 831 continue to rely on the IPsec SA previously negotiated with the HA 832 and the respective authorization is managed through the Mobile IPv6 833 Authorization Lifetime. 835 7. The MIPv6-Authorization container 837 All the messages used for MIPv6 bootstrapping are encoded in TLVs 838 carried by a generic MIPv6-Authorization container. In this way, only 839 the structure of the container needs to be adapted to the actual 840 message format of the employed EAP method. 842 The MIPv6-Authorization container can be implemented as a TLV, as an 843 AVP or in some other way depending on the specific characteristics of 844 the EAP method used for network access authentication (see Figure 4). 846 +----------------------------------------------------------+ 847 | MIPv6 bootstrapping TLVs (Sec. 8) | 848 +------+--------------+--------------+--------------+------+ 849 | | | | 850 | | | | 851 +------+-----+ +------+-----+ +------+-----+ +------+------+ 852 | MIPv6 | | MIPv6 | | MIPv6 | | MIPv6 | 853 | Auth. TLV | | Auth. TLV | | Auth. AVP | | Auth. IKEv2 | 854 | | | | | | | Payload | 855 | (Sec. 7.1) | | (Sec. 7.3) | | (Sec. 7.5) | | (sec. 7.6) | 856 +------------+ +------------+ +------------+ +-------------+ 857 | PEAPv2 | | EAP-SIM | | EAP-TTLS | | EAP-IKEv2 | 858 | EAP-FAST | | EAP-AKA | | | | | 859 +------------+ +------------+ +------------+ +-------------+ 861 Figure 4 - Transport of MIPv6 bootstrapping messages 863 In the following the format of the MIPv6-Authorization container is 864 defined for each EAP method identified in section 4. This list is not 865 exhaustive and does not prevent the use of other EAP methods 866 satisfying all the requirements listed in this document. 868 7.1 PEAPv2 870 The exchange of arbitrary information in PEAPv2 is based on EAP-TLVs. 871 In this case the MIPv6-Authorization container is encoded as an EAP- 872 TLV and has the structure depicted below: 874 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 |M|R| Type | Length | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Value 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 M 882 0 - Non-mandatory TLV 884 R 886 Reserved, set to zero (0) 888 Type 890 TBD - MIPv6-Authorization 892 Length 894 The length of the Value field in octets 896 Value 898 This field carries the subsequent TLVs 900 7.2 EAP-FAST 902 The format of the messages for EAP-FAST [EAP-FAST] is the same as 903 PEAPv2. 905 7.3 EAP-SIM 907 EAP-SIM [EAP-SIM] allows the transport of additional information in 908 form of TLVs. The format of the MIPv6-Authorization container is 909 depicted below: 911 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type | Length | Value 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 Type 918 TBD - MIPv6-Authorization 920 Length 922 Indicates the length of this attribute in multiples of four 923 bytes. The maximum length of an attribute is 1024 bytes. The 924 length includes the Type and Length bytes. 926 Value 928 This field carries the subsequent TLVs 930 7.4 EAP-AKA 932 The format of the messages for EAP-AKA [EAP-AKA] is the same as EAP- 933 SIM. 935 7.5 EAP-TTLS 937 EAP-TTLS messages [EAP-TTLS] allow the exchange of arbitrary data in 938 the form of AVPs encapsulated in the TLS record. The MIPv6- 939 Authorization container is encoded as depicted below: 941 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | AVP Code | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 |V M r r r r r r| AVP Length | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Vendor ID (opt) | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Data 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 AVP Code 954 TBD - MIPv6-Authorization 956 Flag 'V' (Vendor-Specific) 958 0 960 Flag 'M' (Mandatory) 962 0 964 Flag 'r' (reserved) 966 must be set to 0 967 AVP Length 969 the length of this AVP including the AVP Code, AVP 970 Length, flags, Vendor-ID (if present) and Data. 972 Data 974 this field carries subsequent TLVs 976 7.6 EAP-IKEv2 978 EAP-IKEv2 [EAP-IKEv2] allows the transport of generic data in the 979 form of IKEv2 payloads. The MIPv6-Authorization container is encoded 980 as depicted below: 982 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Next Payload |C| RESERVED | Payload Length | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Data ~ 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Next Payload (1 octet) 991 TBD - MIPv6-Authorization 993 Critical (1 bit) 995 must be set to zero 997 RESERVED (7 bits) 999 must be sent as zero; must be ignored on receipt. 1001 Payload Length (2 octets) 1003 Length in octets of the current payload, including the generic 1004 payload header 1006 Data 1008 It contains subsequent TLVs 1009 8. New TLVs 1011 Independently from the EAP method used for network access 1012 authentication, the MIPv6-Authorization container enables to 1013 transport a series of TLVs. This gives more flexibility to the whole 1014 solution and permits the definition of new TLVs that do not need to 1015 be bound to a specific EAP method. 1017 The following TLVs have been defined so far: 1019 Service-Status-TLV 1020 Service-Selection-TLV 1021 Service-Options-TLV 1022 Home-Agent-Address-TLV 1023 Home-Address-TLV 1024 IKE-Authentication-Options-TLV 1025 IKE-Bootstrap-Information-TLV 1026 Negotiation-Result-TLV 1028 8.1 Service-Status-TLV 1030 This TLV is sent by the AAAH to inform the MN about the status of 1031 Mobile IPv6 service. It is defined as follows: 1033 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Type=Service-Status | Length | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Code | 1038 +-+-+-+-+-+-+-+-+ 1040 Type 1042 TBD - Service-Status 1044 Length 1046 1 1048 Code 1050 0 = MIPv6 service is available 1051 1 = MIPv6 service is not available 1052 8.2 Service-Selection-TLV 1054 This TLV is sent by the MN to inform the AAAH whether it wants to 1055 activate MIPv6 service or whether the service is already active. 1057 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Type=Service-Selection | Length | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Code | 1062 +-+-+-+-+-+-+-+-+ 1064 Type 1066 TBD - Service-Selection 1068 Length 1070 1 1072 Code 1074 0 = activate MIPv6 service 1075 1 = MIPv6 service already active 1076 2 = do not activate MIPv6 service 1078 8.3 Service-Options-TLV 1080 This TLV is used by the AAAH server to advertise the service options 1081 the MN can ask for. It is also used by the MN to communicate its 1082 selection to the AAAH. So far only the HA in visited domain option 1083 has been defined. The TLV has the following format: 1085 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Type=Service-Options | Length | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 |V| Reserved | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 Type 1094 TBD - Service-Options 1096 Length 1098 2 1099 V 1100 from AAAH to MN: 1101 0 = AAAH cannot provide a HA in the visited domain 1102 1 = AAAH can provide a HA in the visited domain 1104 from MN to AAAH: 1105 0 = MN does not specify any preference on HA location 1106 1 = MN is requesting a HA in the visited domain 1108 Reserved 1110 15 bit reserved set to 0 1112 8.4 Home-Agent-Address-TLV 1114 This TLV carries the Home Agent's address and it's defined as 1115 follows: 1117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Type=HA-Address | Length | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | | 1122 | Home Agent Address | 1123 | | 1124 | | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Type 1129 TBD - Home-Agent-Address 1131 Length 1133 16 1135 Value 1137 Home Agent Address 1139 8.5 Home-Address-TLV 1141 This TLV carries the Home Address assigned to the MN. It is defined 1142 as follows: 1144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Type=Home-Address | Length | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | | 1149 | Home Address | 1150 | | 1151 | | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 Type 1156 TBD - Home-Address 1158 Length 1160 16 1162 Value 1164 Home Address 1166 8.6 IKE-Authentication-Options-TLV 1168 This TLV carries data related to IKE bootstrapping. If used during 1169 the initial MIPv6 bootstrapping procedure, the value field contains 1170 the list of peer authentication methods supported by the MN. 1171 Otherwise, if used during re-authentication events, the value field 1172 contains only the peer authentication method currently in use. 1174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 |Type=IKE-Authentication-Options| Length | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | AuthMethod-1 | AuthMethod-2 | ... 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 Type 1183 TBD - IKE-Authentication-Options 1185 Length 1187 Length of this TLV. 1189 Value 1191 AuthMethod - code corresponding to the authentication method 1192 supported for IKE phase 1. All the methods 1193 supported by the MN are inserted in order of 1194 preference. The following values are defined: 1196 Authentication Method AuthMethod 1198 PSK (pre-shared key generated by AAAH) 0 1199 AMSK (pre-shared key derived from EAP) 1 1200 CERT (use of certificates) 2 1202 8.7 IKE-Bootstrap-Information-TLV 1204 This TLV carries data related to the set-up of an IPsec Security 1205 Association with the Home Agent. It contains the peer authentication 1206 method to be used for IKE phase 1 and, eventually, the related 1207 cryptographic material (e.g. pre-shared key). 1209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 |Type= IKE-Bootstrap-Information| Length | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | AuthMethod | key Length | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Key Lifetime | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Key Value 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 Type 1222 TBD - IKE-Bootstrap-Information 1224 Length 1226 Length of this TLV. 1228 Value 1230 AuthMethod - the authentication method to be used in IKE 1231 phase 1. This field can assume a value among 1232 those defined in section 8.6 (i.e. PSK, AMSK 1233 or CERT). 1235 Key Length - the length of the key to be used as pre-shared key 1236 for IKE phase 1 authentication. This field must be 1237 present if AuthMethod is set to PSK and may be 1238 present if AuthMethod is set to AMSK. 1240 Key Lifetime - the lifetime of the key in seconds. A value of 1241 all ones means infinite. This field is present 1242 only if the AuthMethod field is set to PSK or 1243 AMSK. 1245 Key Value - the value of the key. This field is present only if 1246 the AuthMethod field is set to PSK. 1248 8.8 Negotiation-Result-TLV 1250 It is defined as follows: 1252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Type=Negotiation-Result | Length | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Result-Code | 1257 +-+-+-+-+-+-+-+-+ 1259 Type 1261 TBD - Result 1263 Length 1265 1 1267 Value 1269 0 = Success 1270 128 = Failure 1271 8.9 Authorization-Lifetime-TLV 1273 It is defined as follows: 1275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Type= Authorization-Lifetime | Length | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Authorization-Lifetime | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 Type 1284 TBD - Authorization-Lifetime 1286 Length 1288 2 1290 Value 1292 The lifetime granted to the MN (in seconds) 1293 9. Security Considerations 1295 The Mobile IPv6 bootstrapping procedure described in this document 1296 assumes the MN and the AAA server of the home domain exchange the 1297 necessary parameters exploiting the EAP communication established for 1298 network access authentication. Therefore, to secure the bootstrapping 1299 procedure, the employed EAP method must support mutual authentication 1300 as well as integrity and replay protection. 1302 Moreover, if the pre-shared key needed to bootstrap the IPsec SA with 1303 the Home Agent is not derived from the EAP key hierarchy but 1304 explicitly delivered to the MN by the AAAH server, the EAP method 1305 must also provide confidentiality. Several tunneled and non tunneled 1306 EAP methods, like PEAPv2 and EAP-IKEv2, fulfill all of these security 1307 requirements. 1309 10. References 1311 10.1 Normative References 1313 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 1314 in IPv6", RFC 3775, June 2004. 1316 [RFC3776] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to 1317 Protect Mobile IPv6 Signaling between Mobile Nodes and 1318 Home Agents", RFC 3776, June 2004. 1320 [RFC3748] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. 1321 Levkowetz, "Extensible Authentication Protocol (EAP)", 1322 RFC 3748, June 2004. 1324 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 1325 (IKE)", RFC 2409, November 1998. 1327 [PEAPv2] Palekar, A. et al., "Protected EAP Protocol (PEAP) 1328 Version 2", draft-josefsson-pppext-eap-tls-eap-11 (work 1329 in progress), September 2005. 1331 [EAPKEYFWK] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., "EAP 1332 Key Management Framework", draft-ietf-eap-keying-09 (work 1333 in progress), January 2006. 1335 [MIPv6AMSK] Giaretta, G., Guardini, I., Demaria, E., Bournelle, 1336 J., Laurent-Maknavicius, M., "Application Master Session 1337 Key (AMSK) for Mobile IPv6", draft-giaretta-mip6-amsk-01 1338 (work in progress), March 2006 1340 10.2 Informative References 1342 [MIPv6PS] Patel, A., Giaretta, G., "Problem Statement for 1343 bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps- 1344 04 (work in progress), February 2005. 1346 [RFC3753] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 1347 3753, June 2004. 1349 [RFC3041] Narten, T., Draves, R., "Privacy Extensions for Stateless 1350 Address Autoconfiguration in IPv6", RFC 3041, January 1351 2001. 1353 [AAAH-HA] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., 1354 Lopez, R., "Goals for AAA-HA interface", draft-ietf- 1355 mip6-aaa-ha-goals-01 (work in progress), February 2005 1357 [AAAMIPFWK] Yegin, A., "AAA Mobile IPv6 Application Framework", 1358 draft-yegin-mip6-aaa-fwk-00 (expired), August 1359 2004 1361 [RFC3084] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. 1362 Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS 1363 Usage for Policy Provisioning,", RFC 3084, March 2001. 1365 [MIPv6APP] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter 1366 Mobile IPv6 Application", draft-le-aaa-diameter- 1367 mobileipv6-03 (expired), April 2003. 1369 [PANA] Forsberg, D. et al., "Protocol for Carrying 1370 Authentication for Network Access (PANA)", draft-ietf- 1371 pana-pana-11 (work in progress), March 2006. 1373 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1374 "Introduction and Applicability Statements for Internet- 1375 Standard Management Framework", RFC 3410, December 2002. 1377 [EAP-TTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS 1378 Authentication Protocol (EAP-TTLS)", draft-ietf-pppext- 1379 eap-ttls-05 (expired), July 2004. 1381 [EAP-IKEv2] Tschofenig, H., Kroeselberg, D., Ohba, Y., "EAP 1382 IKEv2 Method", draft-tschofenig-eap-ikev2-10, February 1383 2006. 1385 [EAP-SIM] Haverinen, H. and J. Salowey, "Extensible Authentication 1386 Protocol Method for GSM Subscriber Identity Modules (EAP- 1387 SIM)", RFC 4186, January 2006. 1389 [EAP-AKA] Arkko, J. and H. Haverinen, "EAP-AKA Authentication", 1390 RFC 4187, January 2006. 1392 [EAP-FAST] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "EAP 1393 Flexible Authentication via Secure Tunneling (EAP-FAST)", 1394 draft-cam-winget-eap-fast-03.txt, October 2005. 1396 Acknowledgments 1398 The authors would like to thank Simone Ruffino, Tom Hiller, Hannes 1399 Tschofening, Rafael Marin Lopez, Hiroyuki Ohnishi, Mayumi Yanagiya, 1400 James Kempf, Yoshihiro Ohba for their valuable comments and the 1401 European Commission support in the co-funding of the ENABLE project, 1402 where this work is partly being developed. 1404 Authors' Addresses 1406 Gerardo Giaretta 1407 Telecom Italia Lab 1408 via G. Reiss Romoli, 274 1409 10148 TORINO 1410 Italy 1411 Phone: +39 011 2286904 1412 Email: gerardo.giaretta@telecomitalia.it 1414 Ivano Guardini 1415 Telecom Italia Lab 1416 via G. Reiss Romoli, 274 1417 10148 TORINO 1418 Italy 1419 Phone: +39 011 2285424 1420 Email: ivano.guardini@telecomitalia.it 1422 Elena Demaria 1423 Telecom Italia Lab 1424 via G. Reiss Romoli, 274 1425 10148 TORINO 1426 Italy 1427 Phone: +39 011 2285403 1428 Email: elena.demaria@telecomitalia.it 1430 Julien Bournelle 1431 GET/INT 1432 9 rue Charles Fourier 1433 Evry 91011 1434 France 1435 Email: julien.bournelle@int-evry.fr 1437 Maryline Laurent-Maknavicius 1438 GET/INT 1439 9 rue Charles Fourier 1440 Evry 91011 1441 France 1442 Email: maryline.maknavicius@int-evry.fr 1443 Intellectual Property Statement 1445 The IETF takes no position regarding the validity or scope of any 1446 Intellectual Property Rights or other rights that might be claimed to 1447 pertain to the implementation or use of the technology described in 1448 this document or the extent to which any license under such rights 1449 might or might not be available; nor does it represent that it has 1450 made any independent effort to identify any such rights. Information 1451 on the procedures with respect to rights in RFC documents can be 1452 found in BCP 78 and BCP 79. 1454 Copies of IPR disclosures made to the IETF Secretariat and any 1455 assurances of licenses to be made available, or the result of an 1456 attempt made to obtain a general license or permission for the use of 1457 such proprietary rights by implementers or users of this 1458 specification can be obtained from the IETF on-line IPR repository at 1459 http://www.ietf.org/ipr. 1461 The IETF invites any interested party to bring to its attention any 1462 copyrights, patents or patent applications, or other proprietary 1463 rights that may cover technology that may be required to implement 1464 this standard. Please address the information to the IETF at 1465 ietf-ipr@ietf.org. 1467 Disclaimer of Validity 1469 This document and the information contained herein are provided on an 1470 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1471 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1472 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1473 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1474 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1475 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1477 Copyright Statement 1479 Copyright (C) The Internet Society (2004). This document is subject 1480 to the rights, licenses and restrictions contained in BCP 78, and 1481 except as set forth therein, the authors retain all their rights. 1483 Acknowledgement 1485 Funding for the RFC Editor function is currently provided by the 1486 Internet Society.