idnits 2.17.1 draft-giaretta-mip6-authorization-eap-02.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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1462. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (October 2004) is 7130 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 483, but not defined == Missing Reference: 'Home-Agent-Address' is mentioned on line 484, but not defined == Missing Reference: 'Home-Address' is mentioned on line 484, but not defined == Missing Reference: 'Interface-Identifier' is mentioned on line 485, but not defined == Missing Reference: 'IKE-Authentication-Options' is mentioned on line 486, but not defined == Unused Reference: 'EAPKEYFWK' is defined on line 1328, but no explicit reference was found in the text == Unused Reference: 'RFC3084' is defined on line 1358, but no explicit reference was found in the text == Unused Reference: 'MIPv6APP' is defined on line 1362, but no explicit reference was found in the text == Unused Reference: 'PANA' is defined on line 1366, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 1370, 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) == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-08 -- Possible downref: Normative reference to a draft: ref. 'PEAPv2' == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-03 == Outdated reference: A later version (-02) exists of draft-giaretta-mip6-amsk-00 -- Possible downref: Normative reference to a draft: ref. 'MIPv6AMSK' == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-00 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) == 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-04 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-03 == Outdated reference: A later version (-16) exists of draft-haverinen-pppext-eap-sim-13 == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-12 == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-00 Summary: 8 errors (**), 0 flaws (~~), 23 warnings (==), 10 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 2005 E. Demaria 5 TILab 6 J. Bournelle 7 M. Laurent-Maknavicius 8 GET/INT 9 October 2004 11 MIPv6 Authorization and Configuration based on EAP 12 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, I 18 certify that any applicable patent or other IPR claims of which I am 19 aware have been disclosed, and any of which I become aware will be 20 disclosed, in accordance with RFC 3668. 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. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This draft defines an architecture, and related protocols, for 42 performing dynamic Mobile IPv6 authorization and configuration 43 relying on a AAA infrastructure. The necessary interaction between 44 the AAA server of the home provider and the mobile node is realized 45 using EAP, exploiting the capability of some EAP methods to convey 46 generic information items together with authentication data. This 47 approach has the advantage that the access equipment acts as a simple 48 pass-through for EAP messages and therefore does not play any active 49 role in the Mobile IPv6 negotiation procedure, which makes the 50 solution easier to deploy and maintain. 52 Table of Contents 54 1. Introduction................................................3 55 2. Terminology.................................................4 56 3. Protocol Overview...........................................5 57 4. Requirements on EAP methods................................10 58 5. Detailed description of the Protocol.......................12 59 5.1 Mobile node bootstrapping...............................12 60 5.2 Management of re-authentication events..................17 61 6. Home Agent considerations..................................19 62 6.1 Requirements on AAAH-HA communication...................19 63 6.2 Management of MIPv6 authorization state.................20 64 7. The MIPv6-Authorization container..........................22 65 7.1 PEAPv2..................................................22 66 7.2 EAP-FAST................................................23 67 7.3 EAP-SIM.................................................23 68 7.4 EAP-AKA.................................................24 69 7.5 EAP-TTLS................................................24 70 7.6 EAP-IKEv2...............................................25 71 8. New TLVs...................................................26 72 8.1 Service-Status-TLV......................................26 73 8.2 Service-Selection-TLV...................................27 74 8.3 Service-Options-TLV.....................................27 75 8.4 Home-Agent-Address-TLV..................................28 76 8.5 Home-Address-TLV........................................28 77 8.6 IKE-Authentication-Options-TLV..........................29 78 8.7 IKE-Bootstrap-Information-TLV...........................30 79 8.8 Negotiation-Result-TLV..................................31 80 8.9 Authorization-Lifetime-TLV..............................32 81 9. Security Considerations....................................33 82 10. References.................................................34 83 10.1 Normative References..................................34 84 10.2 Informative References................................34 85 Acknowledgments.................................................36 86 Authors' Addresses..............................................36 87 Intellectual Property Statement.................................37 88 1. Introduction 90 Mobile IPv6 [RFC3775] requires that Mobile Nodes (MNs) and Home 91 Agents (HAs) share a set of configuration parameters: the MN must 92 know its Home Address, the Home Agent Address and the cryptographic 93 material needed to protect MIPv6 signaling (e.g. shared keys or 94 certificates to setup an IPsec security association). MIPv6 base 95 protocol does not specify any method to automatically acquire this 96 information; which means that network administrators are normally 97 required to manually set configuration data on MNs and HAs. 99 Manual configuration of Home Agents and Mobile Nodes also works as an 100 implicit method for Mobile IPv6 authorization, because only the users 101 that have been administratively enabled on a specific Home Agent are 102 allowed to exploit Mobile IPv6 and its features. 104 However, in a large network (e.g. the network of a mobile operator), 105 which may include millions of users and many Home Agents, the 106 operational and administrative burden of this procedure may easily 107 become overwhelming. In addition, the extensive use of manual and 108 static configurations limits the flexibility and reliability of the 109 system, in that it is not possible to dynamically assign the HA when 110 the user enters the network, which would help to optimize performance 111 and resource utilization (e.g. assignment of the HA closest to the 112 MN's point of attachment). 114 This is generally referred to as the Mobile IPv6 bootstrapping 115 problem. As discussed in [MIPv6PS], several bootstrapping scenarios 116 can be identified depending on the relationship between the network 117 operator providing IP services to the MN (Access Service Provider, 118 ASP) and the service provider managing the HA (Mobility Service 119 Provider, MSP). This document describes a solution to the 120 bootstrapping problem that is applicable in a scenario where the ASP 121 and the MSP are the same provider (Integrated ASP, IASP). 123 The proposed solution performs dynamic Mobile IPv6 authorization and 124 configuration together with MN authentication for network access. 125 MIPv6 negotiation and bootstrapping is controlled by the AAA server 126 of the home provider (IASP), that interacts with the mobile node 127 relying on AAA routing and EAP, exploiting the capability of some EAP 128 methods (e.g. PEAPv2 [PEAPv2], EAP-FAST [EAP-FAST]) to convey generic 129 information items together with authentication data. 131 2. Terminology 133 General mobility terminology can be found in [RFC3753]. The following 134 additional terms are used here: 136 ASP Access Service Provider 138 IASP Integrated Access Service Provider 140 MSP Mobility Service Provider 142 AAA Authentication Authorization Accounting 144 AAAH AAA server of the Home domain 145 3. Protocol Overview 147 The basic idea behind the solution proposed herewith is to perform 148 Mobile IPv6 bootstrapping during the authentication procedure 149 undertaken by the Mobile Node to gain network access. 150 In particular, this draft defines a method to: 152 - explicitly authorize the use of Mobile IPv6 based on the service 153 profile of the user, its position within the network, etc. 155 - dynamically allocate a Home Agent to the Mobile Node; 157 - dynamically configure Mobile IPv6 start-up parameters (i.e. MIPv6 158 bootstrapping) on the Mobile Node. These parameters include the 159 Home Address and the cryptographic material needed to set-up the 160 IPsec Security Association used to protect Mobile IPv6 signaling 161 (i.e. Binding Updates and Binding Acknowledgements). 163 Figure 1 shows the overall architecture of the solution proposed in 164 this draft. The central element of the architecture is the AAA server 165 of the Home Domain (i.e. AAAH), which interacts with both the MN and 166 the selected HA to perform service authorization and configuration. 168 AAA 169 Client 170 IEEE 802.1x +------+ RADIUS 171 or PANA | | or Diameter 172 +--------+ /--------------EAP Exchange-----------------\ +--------+ 173 | Mobile |/ <------------Authentication---------------> \| AAAH | 174 | Node |\ <--MIPv6 authorization and configuration--> /| Server | 175 +--------+ \-------------------------------------------/ +--------+ 176 | | /\ 177 +------+ /||\ 178 Router || 179 or AP AAAH-HA || 180 (pass through) Protocol || 181 \||/ 182 \/ 183 +--------+ 184 | Home | 185 | Agent | 186 +--------+ 188 Figure 1 - Solution architecture 190 The solution is applicable to any access network relying on EAP 191 [RFC3748] for user authentication and works with all EAP methods 192 supporting the exchange of general purpose information elements, in 193 any form (e.g. TLVs or AVPs), between EAP peers. Exploiting this 194 capability, MN and AAAH can piggyback Mobile IPv6 negotiation 195 messages within the same EAP conversation used to carry out user 196 authentication. 198 This kind of operation is already supported by several tunneled (e.g. 199 PEAPv2 [PEAPv2]) and non tunneled (e.g. EAP-IKEv2 [EAP-IKEv2]) EAP 200 methods, that also include native support for encryption, 201 authentication and integrity protection of exchanged configuration 202 data (e.g. HA address). 204 Figure 2 shows an overview of the procedure defined to handle MIPv6 205 bootstrap on the Mobile Node. For the sake of simplicity it is 206 assumed that the employed AAA protocol is Diameter, but obviously 207 RADIUS is suitable as well. 209 EAP over 210 IEEE 802.1x EAP over Diameter AAAH-HA 211 or PANA AAA (or RADIUS) AAAH Protocol 212 MN +---------+ Client +----------------+ Server +-------------+ HA 214 1) <--Req. Id.--- 215 --Identity---> --Diameter EAP Req.--> 216 /-------------------------------------\ 217 2) / Set-up of protected channel \ 218 \ e.g. TLS Tunnel (optional) / 219 \-------------------------------------/ 220 /-------------------------------------\ 221 3) / Authentication \ 222 \ Phase / 223 \-------------------------------------/ 224 /-------------------------------------\ +-+ /--------------\ +-+ 225 4) / Mobile IPv6 service \| |/ HoA selection \| | 226 \ authorization and configuration /| |\ and HA config. /| | 227 \-------------------------------------/ +-+ \--------------/ +-+ 228 Home Agent State 229 Selection Set-up 231 5) <-----EAP----- <-----Diameter EAP---- 232 Success/Failure Answer (Success/Failure 233 and authorization AVPs) 235 /----------------------------------------------------------\ 236 6) / Set-up Security Association MN-HA and \ 237 \ Mobile IPv6 registration (exchange of BU and BA) / 238 \----------------------------------------------------------/ 240 Figure 2 - Overview of Mobile IPv6 bootstrap procedure 241 The whole procedure can be divided in six steps: 243 1. EAP identity exchange (i.e. exchange of EAP Request Identity and 244 EAP Response Identity messages); 246 2. set-up of a protected channel (e.g. TLS tunnel) for the delivery 247 of subsequent EAP signaling. This is an optional step that is 248 present only if the EAP method provides confidentiality support. 249 It is mandatory only if the MIPv6 negotiation procedure involves 250 the exchange of sensitive information; 252 3. authentication phase. The actual authentication procedure and its 253 security properties depend on the selected EAP method. In tunneled 254 EAP methods (e.g. PEAPv2) this step may involve one or more 255 complete EAP conversations occurring within a previously 256 negotiated TLS session. Each EAP conversation may accomplish user 257 authentication relying on any available EAP method (e.g. EAP-MD5, 258 EAP-SIM, EAP-AKA); 260 4. Mobile IPv6 service authorization and configuration. MN and AAAH 261 exchange a sequence of signaling messages to authorize and 262 configure Mobile IPv6. Those messages are encapsulated as 263 requested by the employed EAP method (e.g. TLVs or AVPs) and 264 delivered as part of the on-going EAP session. If the EAP method 265 provides confidentiality this protocol handshake is encrypted 266 using the previously negotiated ciphersuite. During this phase, 267 AAAH selects a suitable Home Agent for the MN and exchanges 268 authorization and configuration data with it using a AAAH-HA 269 protocol, whose specification is out of the scope of the present 270 document. Further analysis on the definition of such an interface 271 can be found in [AAAH-HA] and [AAAMIPFWK]. At the end of this 272 phase, the MN knows its own Home Address, the address of the 273 correspondent Home Agent, the peer authentication method (i.e. 274 certificates or pre-shared key) and the cryptographic material 275 (e.g. pre-shared key) needed to set-up an IPsec security 276 association with IKE [RFC2409]. The IKE pre-shared key can be 277 either constructed by AAAH and then delivered to MN in a proper 278 TLV (or AVP) or independently derived by MN and AAAH from the EAP 279 key hierarchy; 281 5. EAP session termination. Assuming the mobile node has been 282 successfully authenticated, the AAAH server sends a Diameter EAP 283 Answer message with Result-Code equal to SUCCESS. The AAA client 284 extracts the EAP Success message from the Diameter EAP Answer and 285 forwards it to the MN terminating the EAP session; 287 6. set-up of IPsec Security Association and MIPv6 registration. At 288 the end of the EAP communication, the MN gains network access and 289 acquires a valid Care-of Address within the visited subnet (e.g. 291 via stateless autoconfiguration); then it performs an IKE exchange 292 to establish the IPsec Security Association with the HA, using the 293 authentication method and the cryptographic material negotiated 294 during the MIPv6 service configuration phase (step 4). Finally, 295 the MN performs MIPv6 registration, sending a Binding Update 296 (protected with IPsec) to the HA. 298 This draft also defines the procedures to handle re-authentication 299 events and to manage the termination of the Mobile IPv6 session. 301 In summary, the proposed architecture has the following advantages: 303 - allows the MSP to maintain a centralized management (on the AAA 304 server) of the user profiles and the authentication, authorization 305 and accounting procedures for any type of service, including 306 Mobile IPv6; 308 - improves the reliability and performance of the Mobile IPv6 309 protocol, in that the HA to be dynamically assigned to the MN can 310 be freely chosen among those that are closest to the user's point 311 of attachment, thus optimizing network usage and reducing the 312 transfer delay for data traffic in bi-directional tunneling; 314 - can be deployed, or extended with new features, without having to 315 update the access equipment and the AAA protocols in use. Only 316 minor changes in the AAA servers, the Home Agents and the mobile 317 terminals are required, in that the AAA client does not play any 318 active role in MIPv6 negotiation (i.e. it is a pass-through for 319 EAP signaling). This reduces the deployment costs and makes the 320 solution easy to use even when a Mobile Node is roaming with a 321 provider different from its own; 323 - allows the usage of any AAA protocol supporting the transport of 324 EAP messages for the communication between the AAA client and 325 server (i.e. not just Diameter, but also RADIUS). This 326 significantly simplifies the deployment of MIPv6 in existing 327 communication networks, where support for Diameter protocol in 328 access equipment is not so extensive. 330 - allows the operator to dynamically choose the authentication 331 method for IKE bootstrapping and to automatically distribute the 332 pre-shared key eventually needed; in this way the pre-shared key 333 must not be pre-configured and can be frequently changed 334 increasing resistance to attacks. In the case of an EAP method 335 providing dynamic generation of keying material the pre-shared key 336 can be derived from EAP hierarchy avoiding the need to explicitly 337 send it to the MN [MIPv6AMSK]. 339 As a whole, the solution adds a maximum of 2 RTTs (see the detailed 340 protocol description in section 5) to the EAP conversation carried 341 out by the mobile node to authenticate itself and gain network 342 access. The number of extra RTTs can be reduced if the employed EAP 343 method has the capability of transporting MIPv6 negotiation TLVs (or 344 AVPs) together with authentication data. Nonetheless, it should be 345 noted that the full negotiation procedure can be undertaken by the MN 346 only during its initial bootstrapping, and therefore the performance 347 requirements are not so strict. 349 4. Requirements on EAP methods 351 In EAP methods, the EAP peer and EAP server exchange data in order to 352 authenticate the EAP peer and eventually the EAP server (mutual 353 authentication). This draft proposes the use of these exchanges to 354 transport MIPv6 parameters, as part of an handshake that requires at 355 maximum 2 RTTs. Thus, the main requirement for the applicability of 356 the solution is: 358 - the EAP method must provide a way to carry arbitrary parameters 359 during or after the authentication phase. This implies that the 360 EAP method must provide messages and mechanisms for this purpose. 362 Then, for security reasons, the EAP method must provide the following 363 properties: 365 - mutual authentication: the EAP method must provide mutual 366 authentication. The access network must authenticate users 367 before granting them Mobile IPv6 service and the EAP peer should 368 authenticate the access network before delivering sensitive 369 data; 371 - integrity: the exchanged MIPv6 parameters must be protected 372 against any alteration and thus the EAP method must provide 373 integrity protection; 375 - replay protection: the EAP messages containing MIPv6 parameters 376 must be protected against Replay Attack, so that an attacker is 377 not able to get previous given data by replaying an old request; 379 - confidentiality: depending on which data the AAA server provides 380 to the mobile node (e.g. an IKE pre-shared key), it may be 381 necessary to protect the message exchange against eavesdropping. 383 The table below checks some existing EAP methods against the 384 requirements listed above. 386 M-A: Mutual Authentication 387 R-P: Replay Protection 389 +---+----------+---+---------------+-------------+ 390 | | | | | Exchange | 391 |M-A| Integrity|R-P|Confidentiality| of arbitrary| 392 | | | | | Parameters | 393 +------------+---+----------+---+---------------+-------------+ 394 | PEAPv2 | x | x | x | x | x | 395 +------------+---+----------+---+---------------+-------------+ 396 | EAP-FAST | x | x | x | x | x | 397 +------------+---+----------+---+---------------+-------------+ 398 | EAP-TTLS | x | x | x | x | x | 399 +------------+---+----------+---+---------------+-------------+ 400 | EAP-IKEv2 | x | x | x | x | x | 401 +------------+---+----------+---+---------------+-------------+ 402 | EAP-SIM | x | x | x | x | x | 403 +------------+---+----------+---+---------------+-------------+ 404 | EAP-AKA | x | x | x | x | x | 405 +------------+---+----------+---+---------------+-------------+ 406 | EAP-TLS | x | x | x | x | | 407 +------------+---+----------+---+---------------+-------------+ 408 | EAP-MD5 | | | | | | 409 +------------+---|----------|---|---------------|-------------| 411 In summary, it is possible to note that the procedure described in 412 this draft can be successfully undertaken with several tunneled 413 (PEAPv2, EAP-FAST and EAP-TTLS) and non tunneled EAP methods (EAP- 414 IKEv2, EAP-SIM, EAP-AKA), that all support the transport of arbitrary 415 parameters. 417 5. Detailed description of the Protocol 419 This section details the procedures and message exchanges that can be 420 adopted by the network operator to explicitly authorize the 421 activation of Mobile IPv6 support for a specific user as well as 422 enable dynamic bootstrapping of MIPv6 protocol parameters (e.g. Home 423 Address, Home Agent Address). 425 5.1 Mobile node bootstrapping 427 If EAP is used for access control, when the MN enters the network it 428 is immediately polled for its identity, by means of an EAP Request 429 Identity message. This message is used to start the EAP 430 communication. The MN replies sending its identity, in the form of a 431 NAI (Network Access Identifier), within an EAP Response Identity 432 message, that is received by a AAA client (e.g. the Access Point in 433 the case of a Wireless LAN) and forwarded via AAA routing to the AAAH 434 server using the Diameter EAP Application (or the RADIUS EAP 435 extensions). Then the AAAH server selects an EAP method (e.g. based 436 on the user service profile) and proposes it to the MN in subsequent 437 EAP messages. In order to enable the Mobile IPv6 negotiation 438 procedure defined in this document, the EAP method chosen by the AAAH 439 server must be an EAP method supporting the transport of general 440 purpose and variable length information elements, in the form of TLVs 441 (or AVPs), together with authentication data (see section 4). 443 After this initial handshake, MN and AAAH undertake the actual 444 authentication phase, that may require the exchange of a variable 445 number of EAP Request/Response messages. In many EAP methods, like 446 PEAPv2 or EAP-IKEv2, the authentication phase is preceded by the 447 establishment of an encrypted channel between MN and AAAH that 448 provides protection capabilities (i.e. privacy, integrity protection, 449 etc.) for all the messages exchanged during the rest of the EAP 450 conversation. 452 As soon as the authentication phase is completed, the procedure for 453 MIPv6 bootstrapping may take place. For that purpose, the MN and the 454 AAAH server exploit the on-going EAP communication to exchange a 455 sequence of signaling messages transporting configuration parameters. 457 All the messages used for MIPv6 bootstrapping are encoded in TLVs 458 carried by a generic MIPv6-Authorization container. This choice 459 simplifies a lot the deployment of the procedure with any EAP method 460 satisfying the requirements listed in section 4. In fact, only the 461 structure of the MIPv6-Authorization container needs to be adapted to 462 the actual message format of the employed EAP method. 464 For the sake of simplicity, in this section it is assumed that the 465 EAP method used for network access authentication supports the 466 transport of arbitrary parameters in TLV format. In this case the 467 MIPv6-Authorization container becomes a MIPv6-Authorization-TLV. 468 Nonetheless, in section 7 the format of the container is defined for 469 all the EAP methods identified in section 4. 471 The whole bootstrapping procedure is depicted in Figure 3. 473 AAAH 474 MN +----------------------------+ Server +----------------+ HA 476 <--------------------- 477 MIPv6-Authorization-TLV( 478 Service-Status, 479 [Service-Options]) 481 -----------------------> 482 MIPv6-Authorization-TLV( 483 Service-Selection, [Service-Options], 484 [Home-Agent-Address], [Home-Address], 485 [Interface-Identifier], 486 [IKE-Authentication-Options]) 487 +-+ +-+ 488 | |/----------------\| | 489 | |\----------------/| | 490 +-+ +-+ 491 Home Agent HA 492 Selection Conf. 494 <--------------------- 495 MIPv6-Authorization-TLV( 496 Home-Address, Home-Agent-Address, 497 IKE-Bootstrap-Information, 498 Authorization-Lifetime) 500 -----------------------> 501 MIPv6-Authorization-TLV( 502 Negotiation-Result) 504 Figure 3 - MIPv6 bootstrapping procedure 506 AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6- 507 Authorization-TLV including the following TLVs: 509 - Service-Status-TLV: used to communicate whether the home domain is 510 willing to provide Mobile IPv6 service to the MN. This might 511 depend on the user service profile or on other administrative 512 rules (e.g. service accountability); 513 - Service-Options-TLV (optional): used to specify other service 514 options the MN can ask for (e.g. allocation of a HA in the visited 515 domain). 517 MN replies to this first message confirming its intention to start 518 Mobile IPv6 and, optionally, providing a set of hints on the desired 519 service capabilities; this is achieved delivering a MIPv6- 520 Authorization-TLV including the following TLVs: 522 - Service-Selection-TLV: used by the MN to specify if it is willing 523 to activate Mobile IPv6 protocol operation; 525 - Service-Options-TLV (optional): used by the MN to communicate 526 which service options, among those previously advertised by AAAH, 527 it would like make use of; 529 - Home-Agent-Address-TLV (optional): used by the MN to suggest a 530 preferred Home Agent. This can be a HA with whom the MN has a pre- 531 configured Security Association or a HA acquired through dynamic 532 HA address discovery. The AAAH server treats this indication just 533 as a hint, which means that, for administrative reasons, the MN 534 may be assigned a Home Agent different from the one previously 535 requested; 537 - Home-Address-TLV (optional): used by the MN to suggest a preferred 538 Home Address (e.g. an address pre-configured on one of its network 539 interfaces); like the previous TLV, this indication is considered 540 only as a hint by the AAAH server; 542 - Interface-Identifier-TLV (optional): through this TLV, the MN can 543 suggest a preferred Interface Identifier (selected according to 544 [RFC3041] or following other criteria) to be used by the AAA 545 infrastructure to build the Home Address starting from the 546 selected home prefix. Also in this case, this information, if 547 present, is treated as a pure hint by the AAAH server. 549 - IKE-Authentication-Options-TLV (optional): through this TLV, the 550 MN communicates to the AAAH server in order of preference the peer 551 authentication methods it supports for IKE bootstrapping. The lack 552 of this TLV means that the MN supports only the default method. 554 The solution described in this document supports the following 555 methods for peer authentication in IKE phase 1: 557 - use of a pre-shared key (PSK) derived by the AAAH server and sent 558 to the MN and the HA; in this case confidentiality must be 559 provided by both the AAAH-HA protocol and the EAP session between 560 the MN and the AAAH server. This is the default method. 562 - use of a pre-shared key independently derived by the MN and the 563 AAAH server from the keying material exported by the employed EAP 564 method. This key can be derived from an Application Master Session 565 Key (AMSK) specific to Mobile IPv6, which can be constructed as 566 explained in [MIPv6AMSK]. The PSK is then delivered by the AAAH 567 server to the HA by means of a AAAH-HA protocol providing 568 confidentiality; 570 - use of digital certificates. This solution involves the employment 571 of digital signatures and public key encryption as stated in 572 [RFC2409]. This method requires the availability of a PKI. 574 If in the Service-Selection-TLV the MN has chosen not to make use of 575 Mobile IPv6, AAAH terminates the EAP communication sending an EAP 576 Success message, since the authentication procedure has been 577 accomplished successfully. 579 Otherwise, if the MN has confirmed its willingness to start MIPv6 580 service, AAAH selects a suitable Home Agent through a Home Agent 581 Selection Algorithm. Possible parameters to be taken into account by 582 this algorithm include: current load of available HAs (e.g. number of 583 active bindings), location of the MN and, eventually, the preferences 584 provided by the MN itself in the previous message exchange (i.e. 585 Service-Options-TLV, Home-Agent-Address-TLV, Home-Address-TLV, IKE- 586 Authentication-Options-TLV). For example, based on the knowledge of 587 the MN's current point of attachment (i.e. the current AAA client), 588 the AAAH server may select, among the HAs available in the home 589 domain, the one that is closest to the MN in terms of IP routing 590 hops. This approach is normally expected to improve performance. 591 However, the detailed definition of a Home Agent Selection Algorithm 592 is out of the scope of this document. 594 After a suitable HA has been identified, the AAAH server selects the 595 peer authentication method to be used in IKE phase 1. The peer 596 authentication methods supported by the MN are known from the IKE- 597 Authentication-Options-TLV received during the previous exchange. If 598 possible, the AAAH server should choose the method on top of the list 599 provided by the MN (i.e. the one with the highest preference). 601 As soon as the peer authentication method has been identified, the 602 AAAH server interacts with the HA to dynamically configure the state 603 needed to enable subsequent MIPv6 protocol operations, including the 604 authorization lifetime of the MIPv6 service granted to the MN and the 605 necessary security parameters (e.g. pre-shared key). Possible 606 protocols that can be used for this purpose include Diameter (through 607 a new Diameter Application), SNMPv3 or COPS-PR. Further details about 608 this communication are provided in section 6. Anyway, the detailed 609 specification of the interface between AAAH and HA is out of the 610 scope of this document. Additional considerations on the nature and 611 goals of such an interface can be found in [AAAH-HA] and [AAAMIPFWK]. 613 The security parameters that the AAAH server delivers to the HA may 614 vary depending on the peer authentication method chosen for IKE 615 bootstrapping: 617 - if the AAAH server selects pre-shared key as peer authentication 618 method it needs to send the chosen PSK (randomly generated or 619 derived from the EAP key hierarchy) to the HA together with the 620 associated lifetime; 622 - if the AAAH server selects a peer authentication method based on 623 certificates it does not need to derive keys nor to send security 624 parameters to the HA. 626 After the AAAH server has configured the state on the HA, it 627 continues the EAP session communicating to the MN all the MIPv6 628 configuration data it is waiting for. This is achieved delivering to 629 the MN an EAP Request containing a MIPv6-Authorization-TLV and the 630 following sub-TLVs: Home-Address-TLV (i.e. the home address), Home- 631 Agent-Address-TLV (i.e. the address of the HA), IKE-Bootstrap- 632 Information-TLV (i.e. the peer authentication method to be used in 633 IKE phase 1 and associated cryptographic material) and Authorization- 634 Lifetime-TLV (i.e. the lifetime granted to the MN for this session). 636 After the MN has received all the configuration data from the AAAH 637 server (i.e. HA address, Home Address and IKE bootstrap information), 638 it sends back an EAP Response containing a Negotiation-Result-TLV, 639 stating whether it accepts, or refuses, the proposed arrangement. If 640 the MN refuses the configuration, the AAAH server should immediately 641 release the resources previously allocated on the Home Agent. 643 After the completion of the EAP session, MN holds all data needed to 644 perform Mobile IPv6 registration: the MN knows its Home Address, the 645 address of the correspondent Home Agent and all cryptographic data 646 needed to establish the IPsec security association with it; 647 furthermore, since it has been successfully authenticated, the MN can 648 acquire an IPv6 address to be used as Care-of Address. 650 The first operation carried out by the MN after the acquisition of 651 the Care-of Address is the establishment of the IPsec Security 652 Association with the HA, that is mandated by [RFC3775] to protect 653 MIPv6 location update signaling. Set-up of the IPsec SA can be 654 accomplished following the procedure detailed in [RFC3776]. 656 As soon as the IPsec Security Association is established, MN can send 657 a Binding Update to the HA, thus starting up Mobile IPv6 service. 659 5.2 Management of re-authentication events 661 At the expiration of AAA session time-outs or after a change in the 662 point of attachment to the network (e.g. change of Access Point), a 663 re-authentication procedure is performed leading to the user identity 664 to be checked again along with its right to continue exploiting 665 network resources. To that purpose the AAAH server may repeat a full 666 authentication or, alternatively, decide to use optimizations in 667 order to make the procedure faster. Once this phase is completed the 668 AAAH server also undertakes the re-negotiation of the MIPv6 service. 670 Since the MIPv6 bootstrapping procedure is assumed to be completely 671 stateless, when a re-authentication event occurs the AAAH server may 672 not know the state of the MIPv6 service on the MN. For this reason 673 the AAAH server starts the MIPv6 negotiation like in the 674 bootstrapping case: it delivers a MIPv6-Authorization-TLV containing 675 a Service-Status-TLV and optionally a Service-Options-TLV. 677 If the MIPv6 service is not active on the MN the procedure continues 678 as described in section 5.1. Otherwise, the MN replies with a MIPv6- 679 Authorization-TLV containing a Service-Selection-TLV indicating that 680 the MIPv6 service is already in use. Furthermore, the MN inserts the 681 Home-Agent-Address-TLV, the Home-Address-TLV and the IKE- 682 Authentication-Options-TLV to inform the AAAH server about its 683 current state. The AAAH server can then get in touch with the HA to 684 check the integrity of the state, renew the MIPv6 authorization 685 lifetime and eventually refresh the security parameters. 687 If the peer authentication method used by the MN in IKE phase 1 is 688 pre-shared key, the AAAH server must derive a new PSK and send it to 689 the HA together with the associated lifetime. In case the PSK is not 690 derived from the EAP key hierarchy (i.e. it is randomly generated by 691 the AAAH server), the AAAH server must communicate it also to the MN. 692 Instead, in case of authentication based on certificates, the AAAH 693 server does not need to derive keys nor deliver additional security 694 data to the HA and the MN. 696 If the state on the HA is successfully updated, the AAAH server 697 terminates the EAP communication sending an EAP Success message. 698 Otherwise, the AAAH server should continue the EAP communication 699 renegotiating the MIPv6 service (i.e. allocation of a new HA and 700 related Home Address). 702 This solution can be easily deployed even within a network including 703 several AAA servers, each one managing a subset of the available 704 Network Access Servers (NASs). This is because the re-negotiation 705 procedure does not assume to have any long term state related to 706 Mobile IPv6 stored on the AAAH server. In this way, everything works 707 correctly even if, due to MN's movements within the network, the AAAH 708 server that handles the re-authentication is not the same server that 709 authenticated the MN for the first time and performed the MIPv6 710 bootstrapping procedure. 712 As explained above, the re-authentication events are normally 713 triggered by the network. Nonetheless, if the EAP lower layer offers 714 a way to trigger EAP re-authentications (e.g. PANA supports this 715 feature), it may be possible for the MN to re-negotiate the MIPv6 716 service at any time. 718 6. Home Agent considerations 720 This section provides further thoughts about the AAAH-HA 721 communication and lists specific features that have to be supported 722 by the Home Agent to allow dynamic negotiation of Mobile IPv6 723 protocol parameters. 725 6.1 Requirements on AAAH-HA communication 727 This draft details only the message exchange between the MN and the 728 AAAH server. Obviously a complete Mobile IPv6 bootstrapping solution 729 requires also the definition of a mechanism for the communication 730 between the AAAH server and the Home Agent. Possible protocols that 731 may be used for this purpose include SNMPv3, COPS-PR or Diameter but 732 a formal definition of such a protocol is out of scope of this 733 document. 735 A detailed analysis of the goals for a generic AAAH-HA protocol can 736 be found in [AAAH-HA]; in this section some requirements, specific to 737 this scenario, are highlighted. 739 The selected protocol should allow the AAAH server to: 741 - use a Network Access Identifier (NAI) to identify the mobile node 742 in the communication with the HA; 744 - send an authorization lifetime to the HA to limit Mobile IPv6 745 session duration for the MN; 747 - send to the HA a set of hints for the construction of the Home 748 Address (e.g. a preferred Home Address or a preferred Interface 749 Identifier); 751 - poll the designated HA for the allocation of a Home Address to the 752 MN; 754 - force the HA to terminate an active Mobile IPv6 session for 755 authorization policy reasons (e.g. credit exhaustion or 756 reallocation of a new HA to the MN); 758 - enforce explicit operational limitations and authorization 759 restrictions on the HA (e.g. packet filters, QoS parameters); 761 - retrieve the Mobile IPv6 state associated to a specific MN from 762 the correspondent HA. This may be useful to periodically verify 763 the Mobile IPv6 service status; 764 - send to the HA the security data needed to setup the IPsec SA with 765 the MN. Possible security data are the authentication method and 766 the cryptographic material to be used for IKE bootstrapping. 768 Moreover, the protocol selected to implement the communication 769 between the AAAH server and the HA should fulfill the following 770 general requirements: 772 - the AAAH server and the HA must be able to authenticate each other 773 (mutual authentication) in order to prevent the installation of 774 unauthorized state on the HA; 776 - the AAA-HA interface must provide integrity protection in order to 777 prevent any alteration of exchanged data (e.g. Mobile IPv6 778 configuration parameters); 780 - the AAA-HA interface must provide replay protection; 782 - the AAA-HA interface should provide confidentiality since it may 783 be used to transfer security parameters (e.g. IKE pre-shared key); 785 - the AAA-HA interface should support inactive peer detection. This 786 functionality can be used by the AAAH server to maintain a list of 787 active HAs (e.g. useful for HA selection); 789 6.2 Management of MIPv6 authorization state 791 The Home Agent is required to store some authorization data for each 792 of the MNs it is serving. A new data structure may be used for this 793 purpose and it should include at least the following fields: 795 - NAI of the user; 797 - Home Address assigned to the MN; 799 - Cryptographic Data: this field includes the peer authentication 800 method to be used in IKE and, if needed, the pre-shared key and 801 its lifetime; 803 - Authorization Lifetime: it is the lifetime of the Mobile IPv6 804 service granted to the MN; 806 At the expiration of the Authorization Lifetime the HA should check 807 if there is an active entry for the MN in its Binding Cache in order 808 to verify if the MN is still using Mobile IPv6. If the entry is 809 available the Home Agent should negotiate with the AAAH server an 810 extension of the Authorization Lifetime granted to the MN. Otherwise, 811 the HA should immediately release the authorization state associated 812 to that MN and eventually notify the session termination to the AAAH 813 server (e.g. by means of a Session Termination Request if the 814 employed AAAH-HA protocol is Diameter). 816 Moreover, the release of the resources previously allocated on the 817 Home Agent can be undertaken at any time by the AAAH server. 818 Typically this happens at credit exhaustion or when the MN 819 disconnects from the network. 821 The policies adopted by the AAAH server to release the resources 822 allocated to the MN may vary depending on the user service profile. 823 For instance, the AAAH server may decide to postpone the release of 824 the resources on the HA in order to allow the MN to continue using 825 the Mobile IPv6 service even if it has moved to an access network for 826 which no roaming agreements are in place (e.g. a corporate network or 827 a network providing cost-free access). In that case, the MN can 828 continue to rely on the IPsec SA previously negotiated with the HA 829 and the respective authorization is managed through the Mobile IPv6 830 Authorization Lifetime. 832 7. The MIPv6-Authorization container 834 All the messages used for MIPv6 bootstrapping are encoded in TLVs 835 carried by a generic MIPv6-Authorization container. In this way, only 836 the structure of the container needs to be adapted to the actual 837 message format of the employed EAP method. 839 The MIPv6-Authorization container can be implemented as a TLV, as an 840 AVP or in some other way depending on the specific characteristics of 841 the EAP method used for network access authentication (see Figure 4). 843 +----------------------------------------------------------+ 844 | MIPv6 bootstrapping TLVs (Sec. 8) | 845 +------+--------------+--------------+--------------+------+ 846 | | | | 847 | | | | 848 +------+-----+ +------+-----+ +------+-----+ +------+------+ 849 | MIPv6 | | MIPv6 | | MIPv6 | | MIPv6 | 850 | Auth. TLV | | Auth. TLV | | Auth. AVP | | Auth. IKEv2 | 851 | | | | | | | Payload | 852 | (Sec. 7.1) | | (Sec. 7.3) | | (Sec. 7.5) | | (sec. 7.6) | 853 +------------+ +------------+ +------------+ +-------------+ 854 | PEAPv2 | | EAP-SIM | | EAP-TTLS | | EAP-IKEv2 | 855 | EAP-FAST | | EAP-AKA | | | | | 856 +------------+ +------------+ +------------+ +-------------+ 858 Figure 4 - Transport of MIPv6 bootstrapping messages 860 In the following the format of the MIPv6-Authorization container is 861 defined for each EAP method identified in section 4. This list is not 862 exhaustive and does not prevent the use of other EAP methods 863 satisfying all the requirements listed in this document. 865 7.1 PEAPv2 867 The exchange of arbitrary information in PEAPv2 is based on EAP-TLVs. 868 In this case the MIPv6-Authorization container is encoded as an EAP- 869 TLV and has the structure depicted below: 871 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 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 |M|R| Type | Length | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Value 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 M 879 0 - Non-mandatory TLV 881 R 883 Reserved, set to zero (0) 885 Type 887 TBD - MIPv6-Authorization 889 Length 891 The length of the Value field in octets 893 Value 895 This field carries the subsequent TLVs 897 7.2 EAP-FAST 899 The format of the messages for EAP-FAST [EAP-FAST] is the same as 900 PEAPv2. 902 7.3 EAP-SIM 904 EAP-SIM [EAP-SIM] allows the transport of additional information in 905 form of TLVs. The format of the MIPv6-Authorization container is 906 depicted below: 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Type | Length | Value 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 Type 915 TBD - MIPv6-Authorization 917 Length 919 Indicates the length of this attribute in multiples of four 920 bytes. The maximum length of an attribute is 1024 bytes. The 921 length includes the Type and Length bytes. 923 Value 925 This field carries the subsequent TLVs 927 7.4 EAP-AKA 929 The format of the messages for EAP-AKA [EAP-AKA] is the same as EAP- 930 SIM. 932 7.5 EAP-TTLS 934 EAP-TTLS messages [EAP-TTLS] allow the exchange of arbitrary data in 935 the form of AVPs encapsulated in the TLS record. The MIPv6- 936 Authorization container is encoded as depicted below: 938 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 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | AVP Code | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 |V M r r r r r r| AVP Length | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Vendor ID (opt) | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Data 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 AVP Code 951 TBD - MIPv6-Authorization 953 Flag 'V' (Vendor-Specific) 955 0 957 Flag 'M' (Mandatory) 959 0 961 Flag 'r' (reserved) 963 must be set to 0 964 AVP Length 966 the length of this AVP including the AVP Code, AVP 967 Length, flags, Vendor-ID (if present) and Data. 969 Data 971 this field carries subsequent TLVs 973 7.6 EAP-IKEv2 975 EAP-IKEv2 [EAP-IKEv2] allows the transport of generic data in the 976 form of IKEv2 payloads. The MIPv6-Authorization container is encoded 977 as depicted below: 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Next Payload |C| RESERVED | Payload Length | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Data ~ 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Next Payload (1 octet) 988 TBD - MIPv6-Authorization 990 Critical (1 bit) 992 must be set to zero 994 RESERVED (7 bits) 996 must be sent as zero; must be ignored on receipt. 998 Payload Length (2 octets) 1000 Length in octets of the current payload, including the generic 1001 payload header 1003 Data 1005 It contains subsequent TLVs 1006 8. New TLVs 1008 Independently from the EAP method used for network access 1009 authentication, the MIPv6-Authorization container enables to 1010 transport a series of TLVs. This gives more flexibility to the whole 1011 solution and permits the definition of new TLVs that do not need to 1012 be bound to a specific EAP method. 1014 The following TLVs have been defined so far: 1016 Service-Status-TLV 1017 Service-Selection-TLV 1018 Service-Options-TLV 1019 Home-Agent-Address-TLV 1020 Home-Address-TLV 1021 IKE-Authentication-Options-TLV 1022 IKE-Bootstrap-Information-TLV 1023 Negotiation-Result-TLV 1025 8.1 Service-Status-TLV 1027 This TLV is sent by the AAAH to inform the MN about the status of 1028 Mobile IPv6 service. It is defined as follows: 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Type=Service-Status | Length | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Code | 1035 +-+-+-+-+-+-+-+-+ 1037 Type 1039 TBD - Service-Status 1041 Length 1043 1 1045 Code 1047 0 = MIPv6 service is available 1048 1 = MIPv6 service is not available 1049 8.2 Service-Selection-TLV 1051 This TLV is sent by the MN to inform the AAAH whether it wants to 1052 activate MIPv6 service or whether the service is already active. 1054 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 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Type=Service-Selection | Length | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Code | 1059 +-+-+-+-+-+-+-+-+ 1061 Type 1063 TBD - Service-Selection 1065 Length 1067 1 1069 Code 1071 0 = activate MIPv6 service 1072 1 = MIPv6 service already active 1073 2 = do not activate MIPv6 service 1075 8.3 Service-Options-TLV 1077 This TLV is used by the AAAH server to advertise the service options 1078 the MN can ask for. It is also used by the MN to communicate its 1079 selection to the AAAH. So far only the HA in visited domain option 1080 has been defined. The TLV has the following format: 1082 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 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Type=Service-Options | Length | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 |V| Reserved | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 Type 1091 TBD - Service-Options 1093 Length 1095 2 1096 V 1097 from AAAH to MN: 1098 0 = AAAH cannot provide a HA in the visited domain 1099 1 = AAAH can provide a HA in the visited domain 1101 from MN to AAAH: 1102 0 = MN does not specify any preference on HA location 1103 1 = MN is requesting a HA in the visited domain 1105 Reserved 1107 15 bit reserved set to 0 1109 8.4 Home-Agent-Address-TLV 1111 This TLV carries the Home Agent's address and it's defined as 1112 follows: 1114 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 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Type=HA-Address | Length | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | | 1119 | Home Agent Address | 1120 | | 1121 | | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 Type 1126 TBD - Home-Agent-Address 1128 Length 1130 16 1132 Value 1134 Home Agent Address 1136 8.5 Home-Address-TLV 1138 This TLV carries the Home Address assigned to the MN. It is defined 1139 as follows: 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Type=Home-Address | Length | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | | 1146 | Home Address | 1147 | | 1148 | | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 Type 1153 TBD - Home-Address 1155 Length 1157 16 1159 Value 1161 Home Address 1163 8.6 IKE-Authentication-Options-TLV 1165 This TLV carries data related to IKE bootstrapping. If used during 1166 the initial MIPv6 bootstrapping procedure, the value field contains 1167 the list of peer authentication methods supported by the MN. 1168 Otherwise, if used during re-authentication events, the value field 1169 contains only the peer authentication method currently in use. 1171 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 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 |Type=IKE-Authentication-Options| Length | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | AuthMethod-1 | AuthMethod-2 | ... 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 Type 1180 TBD - IKE-Authentication-Options 1182 Length 1184 Length of this TLV. 1186 Value 1188 AuthMethod - code corresponding to the authentication method 1189 supported for IKE phase 1. All the methods 1190 supported by the MN are inserted in order of 1191 preference. The following values are defined: 1193 Authentication Method AuthMethod 1195 PSK (pre-shared key generated by AAAH) 0 1196 AMSK (pre-shared key derived from EAP) 1 1197 CERT (use of certificates) 2 1199 8.7 IKE-Bootstrap-Information-TLV 1201 This TLV carries data related to the set-up of an IPsec Security 1202 Association with the Home Agent. It contains the peer authentication 1203 method to be used for IKE phase 1 and, eventually, the related 1204 cryptographic material (e.g. pre-shared key). 1206 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 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 |Type= IKE-Bootstrap-Information| Length | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | AuthMethod | key Length | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Key Lifetime | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | Key Value 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 Type 1219 TBD - IKE-Bootstrap-Information 1221 Length 1223 Length of this TLV. 1225 Value 1227 AuthMethod - the authentication method to be used in IKE 1228 phase 1. This field can assume a value among 1229 those defined in section 8.6 (i.e. PSK, AMSK 1230 or CERT). 1232 Key Length - the length of the key to be used as pre-shared key 1233 for IKE phase 1 authentication. This field must be 1234 present if AuthMethod is set to PSK and may be 1235 present if AuthMethod is set to AMSK. 1237 Key Lifetime - the lifetime of the key in seconds. A value of 1238 all ones means infinite. This field is present 1239 only if the AuthMethod field is set to PSK or 1240 AMSK. 1242 Key Value - the value of the key. This field is present only if 1243 the AuthMethod field is set to PSK. 1245 8.8 Negotiation-Result-TLV 1247 It is defined as follows: 1249 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 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Type=Negotiation-Result | Length | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Result-Code | 1254 +-+-+-+-+-+-+-+-+ 1256 Type 1258 TBD - Result 1260 Length 1262 1 1264 Value 1266 0 = Success 1267 128 = Failure 1268 8.9 Authorization-Lifetime-TLV 1270 It is defined as follows: 1272 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 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Type= Authorization-Lifetime | Length | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | Authorization-Lifetime | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 Type 1281 TBD - Authorization-Lifetime 1283 Length 1285 2 1287 Value 1289 The lifetime granted to the MN (in seconds) 1290 9. Security Considerations 1292 The Mobile IPv6 bootstrapping procedure described in this document 1293 assumes the MN and the AAA server of the home domain exchange the 1294 necessary parameters exploiting the EAP communication established for 1295 network access authentication. Therefore, to secure the bootstrapping 1296 procedure, the employed EAP method must support mutual authentication 1297 as well as integrity and replay protection. 1299 Moreover, if the pre-shared key needed to bootstrap the IPsec SA with 1300 the Home Agent is not derived from the EAP key hierarchy but 1301 explicitly delivered to the MN by the AAAH server, the EAP method 1302 must also provide confidentiality. Several tunneled and non tunneled 1303 EAP methods, like PEAPv2 and EAP-IKEv2, fulfill all of these security 1304 requirements. 1306 10. References 1308 10.1 Normative References 1310 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 1311 in IPv6", RFC 3775, June 2004. 1313 [RFC3776] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to 1314 Protect Mobile IPv6 Signaling between Mobile Nodes and 1315 Home Agents", RFC 3776, June 2004. 1317 [RFC3748] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. 1318 Levkowetz, "Extensible Authentication Protocol (EAP)", 1319 RFC 3748, June 2004. 1321 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 1322 (IKE)", RFC 2409, November 1998. 1324 [PEAPv2] Palekar, A. et al., "Protected EAP Protocol (PEAP) 1325 Version 2", draft-josefsson-pppext-eap-tls-eap-08 (work 1326 in progress), July 2004. 1328 [EAPKEYFWK] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., "EAP 1329 Key Management Framework", draft-ietf-eap-keying-03 (work 1330 in progress), July 2004. 1332 [MIPv6AMSK] Giaretta, G., Guardini, I., Demaria, E., Bournelle, 1333 J., Laurent-Maknavicius, M., "Application Master Session 1334 Key (AMSK) for Mobile IPv6", draft-giaretta-mip6-amsk-00 1335 (work in progress), September 2004 1337 10.2 Informative References 1339 [MIPv6PS] Patel, A. et al. "Problem Statement for bootstrapping 1340 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in 1341 progress), July 2004. 1343 [RFC3753] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 1344 3753, June 2004. 1346 [RFC3041] Narten, T., Draves, R., "Privacy Extensions for Stateless 1347 Address Autoconfiguration in IPv6", RFC 3041, January 1348 2001. 1350 [AAAH-HA] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., 1351 Lopez, R., "Goals for AAA-HA interface", draft-giaretta- 1352 mip6-aaa-ha-goals-00 (work in progress), September 2004 1354 [AAAMIPFWK] Yegin, A., "AAA Mobile IPv6 Application Framework", 1355 draft-yegin-mip6-aaa-fwk-00 (work in progress), August 1356 2004 1358 [RFC3084] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. 1359 Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS 1360 Usage for Policy Provisioning,", RFC 3084, March 2001. 1362 [MIPv6APP] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter 1363 Mobile IPv6 Application", draft-le-aaa-diameter- 1364 mobileipv6-03 (expired), April 2003. 1366 [PANA] Forsberg, D. et al., "Protocol for Carrying 1367 Authentication for Network Access (PANA)", draft-ietf- 1368 pana-pana-04 (work in progress), May 2004. 1370 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1371 "Introduction and Applicability Statements for Internet- 1372 Standard Management Framework", RFC 3410, December 2002. 1374 [EAP-TTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS 1375 Authentication Protocol (EAP-TTLS)", draft-ietf-pppext- 1376 eap-ttls-05 (work in progress), July 2004. 1378 [EAP-IKEv2] Tschofenig, H., Kroeselberg, D., Ohba, Y., "EAP 1379 IKEv2 Method", draft-tschofenig-eap-ikev2-03, February 1380 2004. 1382 [EAP-SIM] Haverinen, H. and J. Salowey, "Extensible Authentication 1383 Protocol Method for GSM Subscriber Identity Modules (EAP- 1384 SIM)", draft-haverinen-pppext-eap-sim-13 (work in 1385 progress), April 2004. 1387 [EAP-AKA] Arkko, J. and H. Haverinen, "EAP-AKA Authentication", 1388 draft-arkko-pppext-eap-aka-12 (work in progress), April 1389 2004. 1391 [EAP-FAST] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "EAP 1392 Flexible Authentication via Secure Tunneling (EAP-FAST)", 1393 draft-cam-winget-eap-fast-00.txt (expired), 1394 February 2004 1395 Acknowledgments 1397 The authors would like to thank Simone Ruffino, Tom Hiller, Hannes 1398 Tschofening, Rafael Marin Lopez, Hiroyuki Ohnishi, Mayumi Yanagiya, 1399 James Kempf and Yoshihiro Ohba for their valuable comments. 1401 Authors' Addresses 1403 Gerardo Giaretta 1404 Telecom Italia Lab 1405 via G. Reiss Romoli, 274 1406 10148 TORINO 1407 Italy 1408 Phone: +39 011 2286904 1409 Email: gerardo.giaretta@tilab.com 1411 Ivano Guardini 1412 Telecom Italia Lab 1413 via G. Reiss Romoli, 274 1414 10148 TORINO 1415 Italy 1416 Phone: +39 011 2285424 1417 Email: ivano.guardini@tilab.com 1419 Elena Demaria 1420 Telecom Italia Lab 1421 via G. Reiss Romoli, 274 1422 10148 TORINO 1423 Italy 1424 Phone: +39 011 2285403 1425 Email: elena.demaria@tilab.com 1427 Julien Bournelle 1428 GET/INT 1429 9 rue Charles Fourier 1430 Evry 91011 1431 France 1432 Email: julien.bournelle@int-evry.fr 1434 Maryline Laurent-Maknavicius 1435 GET/INT 1436 9 rue Charles Fourier 1437 Evry 91011 1438 France 1439 Email: maryline.maknavicius@int-evry.fr 1440 Intellectual Property Statement 1442 The IETF takes no position regarding the validity or scope of any 1443 Intellectual Property Rights or other rights that might be claimed to 1444 pertain to the implementation or use of the technology described in 1445 this document or the extent to which any license under such rights 1446 might or might not be available; nor does it represent that it has 1447 made any independent effort to identify any such rights. Information 1448 on the procedures with respect to rights in RFC documents can be 1449 found in BCP 78 and BCP 79. 1451 Copies of IPR disclosures made to the IETF Secretariat and any 1452 assurances of licenses to be made available, or the result of an 1453 attempt made to obtain a general license or permission for the use of 1454 such proprietary rights by implementers or users of this 1455 specification can be obtained from the IETF on-line IPR repository at 1456 http://www.ietf.org/ipr. 1458 The IETF invites any interested party to bring to its attention any 1459 copyrights, patents or patent applications, or other proprietary 1460 rights that may cover technology that may be required to implement 1461 this standard. Please address the information to the IETF at 1462 ietf-ipr@ietf.org. 1464 Disclaimer of Validity 1466 This document and the information contained herein are provided on an 1467 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1468 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1469 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1470 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1471 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1474 Copyright Statement 1476 Copyright (C) The Internet Society (2004). This document is subject 1477 to the rights, licenses and restrictions contained in BCP 78, and 1478 except as set forth therein, the authors retain all their rights. 1480 Acknowledgement 1482 Funding for the RFC Editor function is currently provided by the 1483 Internet Society.