idnits 2.17.1 draft-giaretta-mip6-authorization-eap-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1122. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1099. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1106. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1112. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1128), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (July 16, 2004) is 7223 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) -- Looks like a reference, but probably isn't: 'Service-Options' on line 453 -- Looks like a reference, but probably isn't: 'Home-Agent-Address' on line 454 -- Looks like a reference, but probably isn't: 'Home-Address' on line 454 -- Looks like a reference, but probably isn't: 'Interface-Identifier' on line 455 -- Looks like a reference, but probably isn't: 'IKE-PSK' on line 466 == Unused Reference: '7' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1023, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-00 ** Downref: Normative reference to an Informational draft: draft-cam-winget-eap-fast (ref. '5') == Outdated reference: A later version (-05) exists of draft-ietf-pppext-eap-ttls-04 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-03 ** Downref: Normative reference to an Experimental draft: draft-tschofenig-eap-ikev2 (ref. '8') ** Obsolete normative reference: RFC 3041 (ref. '9') (Obsoleted by RFC 4941) -- No information found for draft-le-aaa-diameter- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' ** Obsolete normative reference: RFC 2409 (ref. '12') (Obsoleted by RFC 4306) == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-04 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-02 ** Downref: Normative reference to an Historic RFC: RFC 3084 (ref. '15') ** Downref: Normative reference to an Informational RFC: RFC 3410 (ref. '16') Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIP6 Working Group G. Giaretta 2 Internet Draft I. Guardini 3 Expires: January 14, 2005 E. Demaria 4 TILab 5 J. Bournelle 6 M. Laurent-Maknavicius 7 GET/INT 8 July 16, 2004 10 MIPv6 Authorization and Configuration based on EAP 11 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance 18 with RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 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 January 14, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 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. 56 Table of Contents 58 1. Introduction................................................2 59 2. Terminology.................................................3 60 3. Protocol Overview...........................................3 61 4. Requirements on EAP methods.................................8 62 5. Detailed Description of the Protocol........................9 63 5.1 Mobile Node bootstrap....................................9 64 5.2 Management of reauthentication events...................14 65 6. Home Agent considerations..................................15 66 6.1 Requirements on AAAH-HA communication...................15 67 6.2 Management of MIPv6 authorization state.................16 68 7. New EAP TLVs...............................................17 69 8. Security Considerations....................................22 70 Acknowledgments.................................................22 71 References......................................................22 72 Authors' Addresses..............................................24 73 Intellectual Property Statement.................................25 75 1. Introduction 77 Mobile IPv6 [1] requires that Mobile Nodes (MNs) and Home Agents 78 (HAs) share a set of configuration parameters: the MN must know its 79 Home Address, the Home Agent Address and the cryptographic material 80 needed to protect MIPv6 signaling (e.g. shared keys or certificates 81 to setup an IPsec security association). MIPv6 base protocol does not 82 specify any method to automatically acquire this information; which 83 means that network administrators are normally required to manually 84 set configuration data on MNs and HAs. 86 Manual configuration of Home Agents and Mobile Nodes also works as an 87 implicit method for Mobile IPv6 authorization, because only the users 88 that have been administratively enabled on a specific Home Agent are 89 allowed to exploit Mobile IPv6 and its features. 91 However, in a large network (e.g. the network of a mobile operator), 92 which may include millions of users and many Home Agents, the 93 operational and administrative burden of this procedure may easily 94 become overwhelming. In addition, the extensive use of manual and 95 static configurations limits the flexibility and reliability of the 96 system, in that it is not possible to dynamically assign the HA when 97 the user enters the network, which would help to optimize performance 98 and resource utilization (e.g. assignment of the HA closest to the 99 MN's point of attachment). 101 This is generally referred as the Mobile IPv6 bootstrapping problem. 102 As discussed in [2], several bootstrapping scenarios can be 103 identified depending on the relationship between the network operator 104 providing IP services to the MN (Access Service Provider, ASP) and 105 the service provider managing the HA (Mobility Service Provider, 106 MSP). This document describes a solution to the bootstrapping problem 107 that is applicable in a scenario where the ASP and the MSP are the 108 same provider (Integrated ASP, IASP). 110 The proposed solution performs dynamic Mobile IPv6 authorization and 111 configuration together with MN authentication for network access. 112 MIPv6 negotiation and bootstrapping is controlled by the AAA server 113 of the home provider (IASP), that interacts with the mobile node 114 relying on AAA routing and EAP, exploiting the capability of some EAP 115 methods (e.g. PEAPv2 [4], EAP-FAST [5]) to convey generic information 116 items together with authentication data. 118 2. Terminology 120 General mobility terminology can be found in [3]. The following 121 additional terms are used here: 123 ASP Access Service Provider 125 IASP Integrated Access Service Provider 127 MSP Mobility Service Provider 129 AAA Authentication Authorization Accounting 131 AAAH AAA server of the Home domain 133 3. Protocol Overview 135 The basic idea behind the solution proposed herewith is to perform 136 Mobile IPv6 authorization and configuration during the authentication 137 procedure undertaken by the Mobile Node to gain network access. 138 In particular, this draft defines a method to: 140 - explicitly authorize the use of Mobile IPv6 based on the service 141 profile of the user, its position within the network, etc. 143 - dynamically allocate a Home Agent to the Mobile Node; 144 - dynamically configure Mobile IPv6 start-up parameters (i.e. MIPv6 145 bootstrapping) on both the Home Agent and the Mobile Node. These 146 parameters include the Home Address and the cryptographic material 147 needed to set-up the IPsec Security Association used to protect 148 Mobile IPv6 signaling (i.e. Binding Updates and Binding 149 Acknowledgements); 151 - allow the MN to negotiate additional Mobile IPv6 service options, 152 such as the assignment of a HA within the visited domain. 154 Figure 1 shows the overall architecture of the solution proposed in 155 this draft. The central element of the architecture is the AAA server 156 of the Home Domain (i.e. AAAH), which interacts with both the MN and 157 the selected HA to perform service authorization and configuration. 159 AAA 160 Client 161 IEEE 802.1x +------+ RADIUS 162 or PANA | | or Diameter 163 +--------+ /--------------EAP Exchange-----------------\ +--------+ 164 | Mobile |/ <------------Authentication---------------> \| AAAH | 165 | Node |\ <--MIPv6 authorization and configuration--> /| Server | 166 +--------+ \-------------------------------------------/ +--------+ 167 | | /\ 168 +------+ /||\ 169 Router || 170 or AP AAAH-HA || 171 (pass through) Protocol || 172 \||/ 173 \/ 174 +--------+ 175 | Home | 176 | Agent | 177 +--------+ 179 Figure 1 - Solution architecture 181 The solution is applicable to any access network relying on EAP [6] 182 for user authentication and works with all EAP methods supporting the 183 exchange of general purpose information elements, in the form of TLVs 184 or AVPs, between EAP peers. Exploiting this capability, MN and AAAH 185 can embed MIPv6 negotiation signaling within the same EAP 186 conversation used to carry out user authentication. 188 This kind of operation is already supported by several tunneled (e.g. 189 PEAPv2 [4]) and non tunneled (e.g. EAP-IKEv2 [8]) EAP methods, that 190 also include native support for encryption, authentication and 191 integrity protection of exchanged configuration information (e.g. HA 192 address). 194 Figure 2 shows an overview of the procedure defined to handle MIPv6 195 bootstrap on the Mobile Node. For the sake of simplicity it is 196 assumed that the employed AAA protocol is Diameter, but obviously 197 RADIUS is suitable as well. 199 The whole procedure can be divided in six steps: 201 1.EAP identity exchange (i.e. exchange of EAP Request Identity and 202 EAP Response Identity messages); 204 2.set-up of a protected channel (e.g. TLS tunnel) for the delivery 205 of subsequent EAP signaling. This is an optional step that is 206 present only if the EAP method provides confidentiality support. 207 It is mandatory only if the MIPv6 negotiation procedure involves 208 the exchange of sensible information; 210 3.authentication phase. The actual authentication procedure and its 211 security properties depend on the selected EAP method. In tunneled 212 EAP methods (e.g. PEAPv2) this step may involve one or more 213 complete EAP conversations occurring within a previously 214 negotiated TLS session. Each EAP conversation may accomplish user 215 authentication relying on any available EAP method (e.g. EAP-MD5, 216 EAP-SIM, EAP-AKA); 218 4.Mobile IPv6 service authorization and configuration. MN and AAAH 219 exchange a sequence of signaling messages to authorize and 220 configure Mobile IPv6. Those messages are encapsulated in TLVs (or 221 AVPs) delivered as part of the on-going EAP session. If the EAP 222 method provides confidentiality this protocol handshake is 223 encrypted using the previously negotiated ciphersuite. During this 224 phase, AAAH selects a suitable Home Agent for the MN and exchanges 225 authorization and configuration data with it using a AAAH-HA 226 protocol (e.g. SNMPv3 [16], COPS-PR [15], a new Diameter 227 application), whose specification is out of the scope of the 228 present document. At the end of this phase, the MN knows its own 229 Home Address, the address of the correspondent Home Agent and the 230 cryptographic material (i.e. pre-shared key) needed to set-up an 231 IPsec security association with IKE [12]. The IKE pre-shared key 232 can be either constructed by AAAH and then delivered to MN in a 233 proper TLV or can be independently derived by MN and AAAH from the 234 EAP key hierarchy; 236 5.EAP session termination. Assuming the mobile node has been 237 successfully authenticated, the AAAH server sends a Diameter EAP 238 Answer message with Result-Code equal to SUCCESS and, optionally, 239 other authorization AVPs containing some filtering rules to be 240 enforced on the NAS (e.g. the AP if the access network is a WLAN, 241 or the Enforcement Point in case of an IP network running the PANA 242 [13] protocol). Then the NAS extracts the EAP Success message from 243 the Diameter EAP Answer and forwards it to the MN terminating the 244 EAP session; 246 6.set-up of IPsec Security Association and MIPv6 registration. At 247 the end of the EAP communication, the MN gains network access and 248 acquires a valid Care-of Address within the visited subnet (e.g. 249 via stateless autoconfiguration); then, using the cryptographic 250 material collected during the MIPv6 negotiation phase (step 4), it 251 performs an IKE exchange to establish the IPsec Security 252 Association with the HA. Finally, the MN performs MIPv6 253 registration, sending a Binding Update (protected with IPsec) to 254 the HA. 256 EAP over 257 IEEE 802.1x EAP over Diameter AAAH-HA 258 or PANA AAA (or RADIUS) AAAH Protocol 259 MN +---------+ Client +----------------+ Server +-------------+ HA 261 1) <--Req. Id.--- 262 --Identity---> --Diameter EAP Req.--> 263 /-------------------------------------\ 264 2) / Set-up of protected channel \ 265 \ e.g. TLS Tunnel (optional) / 266 \-------------------------------------/ 267 /-------------------------------------\ 268 3) / Authentication \ 269 \ Phase / 270 \-------------------------------------/ 271 /-------------------------------------\ +-+ /--------------\ +-+ 272 4) / Mobile IPv6 service \| |/ HoA selection \| | 273 \ authorization and configuration /| |\ and HA config. /| | 274 \-------------------------------------/ +-+ \--------------/ +-+ 275 Home Agent State 276 Selection Set-up 278 5) <-----EAP----- <-----Diameter EAP---- 279 Success/Failure Answer (Success/Failure 280 and authorization AVPs) 282 /----------------------------------------------------------\ 283 6) / Set-up Security Association MN-HA and \ 284 \ Mobile IPv6 registration (exchange of BU and BA) / 285 \----------------------------------------------------------/ 287 Figure 2 - Overview of Mobile IPv6 bootstrap procedure 289 This draft also defines the procedures to handle re-authentication 290 events and to manage the termination of the Mobile IPv6 session. 292 In summary, the proposed architecture has the following advantages: 294 - allows the operator to maintain a centralized management (on the 295 AAA server) of the user profiles and the authentication, 296 authorization and accounting procedures for any type of service, 297 including Mobile IPv6; 299 - improves the reliability and performance of the Mobile IPv6 300 protocol, in that the HA to be dynamically assigned to the MN can 301 be freely chosen among those that are closest to the user's point 302 of attachment, thus optimizing network usage and reducing the 303 transfer delay for data traffic in bi-directional tunneling; 305 - can be deployed, or extended with new features, without having to 306 update the access equipment and the AAA protocols in use. Only 307 minor changes in the AAA servers, the Home Agents and the mobile 308 terminals are required, in that the AAA client does not play any 309 active role in MIPv6 negotiation (i.e. it is a pass-through for 310 EAP signaling). This reduces the deployment costs and makes the 311 solution easy to use even when a Mobile Node is roaming with a 312 provider different from its own; 314 - allows the usage of any AAA protocol supporting the transport of 315 EAP messages for the communication between the AAA client and 316 server (i.e. not just Diameter, but also RADIUS). This 317 significantly simplifies the deployment of MIPv6 in existing 318 communication networks, where support for Diameter protocol in 319 access equipment is not so extensive. 321 As a whole, the solution adds a maximum of 2 RTTs (see the detailed 322 protocol description in section 5) to the EAP conversation carried 323 out by the mobile node to authenticate itself and gain network 324 access. The number of extra RTTs can be reduced if the employed EAP 325 method has the capability of transporting MIPv6 negotiation TLVs (or 326 AVPs) together with authentication data. Nonetheless, it should be 327 noted that the full negotiation procedure can be undertaken by the MN 328 only during its initial bootstrap, and therefore the performance 329 requirements are not so strict. 331 4. Requirements on EAP methods 333 In EAP methods, the EAP peer and EAP server exchange data in order 334 to authenticate the EAP peer and eventually the EAP server (mutual 335 authentication). This draft proposes the use of these exchanges to 336 transport MIPv6 parameters, as part of an handshake that requires at 337 maximum 2 RTTs. Thus, the main requirement for the applicability of 338 our proposal is: 340 - the EAP method must provide a way to carry arbitrary parameters 341 during or after the authentication phase. This implies that the 342 EAP method must provide messages and mechanisms for this purpose. 344 Then, for security reasons, the EAP method must provide the following 345 properties: 347 - mutual authentication: the EAP method must provide mutual 348 authentication. The access network must authenticate users 349 before granting them Mobile IPv6 service and the EAP peer should 350 authenticate the access network before delivering sensitive 351 data; 353 - integrity: the exchanged MIPv6 parameters must be protected 354 against any alteration and thus the EAP method must provide 355 integrity protection; 357 - replay protection: the EAP messages containing MIPv6 parameters 358 must be protected against Replay Attack, so that an attacker is 359 not able to get previous given data by replaying an old request; 361 - confidentiality: depending on which data the AAA server provides 362 to the mobile node (e.g. an IKE pre-shared key), it may be 363 necessary to protect the message exchange against eavesdropping. 365 The table below checks some existing EAP methods against the 366 requirements listed above. 368 M-A: Mutual Authentication 369 R-P: Replay Protection 371 +---+----------+---+---------------+-------------+ 372 | | | | | Exchange | 373 |M-A| Integrity|R-P|Confidentiality| of arbitrary| 374 | | | | | Parameters | 375 +------------+---+----------+---+---------------+-------------+ 376 | PEAPv2 | x | x | x | x | x | 377 +------------+---+----------+---+---------------+-------------+ 378 | EAP-FAST | x | x | x | x | x | 379 +------------+---+----------+---+---------------+-------------+ 380 | EAP-TTLS | x | x | x | x | x | 381 +------------+---+----------+---+---------------+-------------+ 382 | EAP-IKEv2 | x | x | x | x | x | 383 +------------+---+----------+---+---------------+-------------+ 384 | EAP-SIM | x | x | x | x | x | 385 +------------+---+----------+---+---------------+-------------+ 386 | EAP-AKA | x | x | x | x | x | 387 +------------+---+----------+---+---------------+-------------+ 388 | EAP-TLS | x | x | x | x | | 389 +------------+---+----------+---+---------------+-------------+ 390 | EAP-MD5 | | | | | | 391 +------------+---|----------|---|---------------|-------------| 393 In summary, it is possible to note that the procedure described in 394 this draft can be successfully undertaken with several tunneled 395 (PEAPv2, EAP-FAST and EAP-TTLS) and non tunneled EAP methods (EAP- 396 IKEv2, EAP-SIM, EAP-AKA, EAP-TLS), that all support the transport of 397 arbitrary parameters in the form of TLVs or AVPs. 399 5. Detailed Description of the Protocol 401 This section details the procedures and message exchanges that can be 402 adopted by the network operator to explicitly authorize the 403 activation of Mobile IPv6 support for a specific user as well as 404 enable dynamic bootstrapping of MIPv6 protocol parameters (e.g. Home 405 Address, Home Agent Address). 407 5.1 Mobile Node bootstrap 409 If EAP is used for access control, when the MN enters the network it 410 is immediately polled for its identity, by means of an EAP Request 411 Identity message. This message is used to start the EAP 412 communication. The MN replies sending its identity, in the form of a 413 NAI (Network Access Identifier), within an EAP Response Identity 414 message, that is received by a local attendant (e.g. the Access Point 415 in the case of a Wireless LAN) and forwarded via AAA routing to the 416 AAAH server using the Diameter EAP Application (or the RADIUS EAP 417 extensions). Then the AAAH server selects an EAP method (e.g. based 418 on the user service profile) and proposes it to the MN in subsequent 419 EAP messages. In order to enable the Mobile IPv6 negotiation 420 procedure defined in this document, the EAP method chosen by the AAAH 421 server must be an EAP method supporting the transport of general 422 purpose and variable length information elements, in the form of TLVs 423 (or AVPs), together with authentication data (see section 4). 425 After this initial handshake, MN and AAAH undertake the actual 426 authentication phase, that may require the exchange of a variable 427 number of EAP Request/Response messages. In many EAP methods, like 428 PEAPv2 or EAP-IKEv2, the authentication phase is preceded by the 429 establishment of an encrypted channel between MN and AAAH that 430 provides protection capabilities (i.e. privacy, integrity protection, 431 etc.) for all the messages exchanged during the rest of the EAP 432 conversation. 434 As soon as the authentication phase is completed, the procedure for 435 MIPv6 bootstrapping may take place. In order to do that, the MN and 436 the AAAH server exploit the on-going EAP communication to exchange a 437 sequence of signaling messages encapsulated in a new TLV, called 438 MIPv6-Authorization-TLV. This TLV is used as a generic container for 439 other, more specific, TLVs. 441 The whole bootstrapping procedure is depicted in Figure 3. 443 AAAH 444 MN +----------------------------+ Server +----------------+ HA 446 <--------------------- 447 MIPv6-Authorization-TLV( 448 Service-Status, 449 [Service-Options]) 451 -----------------------> 452 MIPv6-Authorization-TLV( 453 Service-Selection, [Service-Options], 454 [Home-Agent-Address], [Home-Address], 455 [Interface-Identifier]) 456 +-+ +-+ 457 | |/----------------\| | 458 | |\----------------/| | 459 +-+ +-+ 460 Home Agent HA 461 Selection Conf. 463 <--------------------- 464 MIPv6-Authorization-TLV( 465 Home-Address, HA-Address, 466 [IKE-PSK]) 468 -----------------------> 469 MIPv6-Authorization-TLV( 470 Negotiation-Result) 472 Figure 3 - MIPv6 bootstrapping procedure 474 AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6- 475 Authorization-TLV including the following TLVs: 477 - Service-Status-TLV: used to communicate whether the home domain is 478 willing to provide Mobile IPv6 service to the MN. This might 479 depend on the user service profile or on other administrative 480 rules (e.g. service accountability); 482 - Service-Options-TLV (optional): used to specify other service 483 options the MN can ask for (e.g. allocation of a HA in the visited 484 domain). 486 MN replies to this first message confirming its intention to start 487 Mobile IPv6 and, optionally, providing a set of hints on the desired 488 service capabilities; this is achieved delivering a MIPv6- 489 Authorization-TLV including the following TLVs: 491 - Service-Selection-TLV: used by the MN to specify if it is willing 492 to activate Mobile IPv6 protocol operation; 494 - Service-Options-TLV (optional): used by the MN to communicate 495 which service options, among those previously advertised by AAAH, 496 it would like make use of; 498 - Home-Agent-Address-TLV (optional): used by the MN to suggest a 499 preferred Home Agent. This can be a HA with whom the MN has a pre- 500 configured Security Association or a HA acquired through dynamic 501 HA address discovery. The AAAH server treats this indication just 502 as a hint, which means that, for administrative reasons, the MN 503 may be assigned a Home Agent different from the one previously 504 requested; 506 - Home-Address-TLV (optional): used by the MN to suggest a preferred 507 Home Address (e.g. an address pre-configured on one of its network 508 interfaces); like the previous TLV, this indication is considered 509 only as a hint by the AAAH server; 511 - Interface-Identifier-TLV (optional): through this TLV, the MN can 512 suggest a preferred Interface Identifier (selected according to 513 [9] or following other criteria) to be used by the AAA 514 infrastructure to build the Home Address starting from the 515 selected home prefix. Also in this case, this information, if 516 present, is treated as a pure hint by AAAH. 518 If in the Service-Selection-TLV the MN has chosen not to make use of 519 Mobile IPv6, AAAH terminates the EAP communication sending an EAP 520 Success message, since the authentication procedure has been 521 accomplished successfully. 523 Otherwise, if the MN has confirmed its willingness to start MIPv6 524 service, AAAH selects a suitable Home Agent through a Home Agent 525 Selection Algorithm. Possible parameters to be taken into account by 526 this algorithm include: current load of available HAs (e.g. number of 527 active bindings), location of the MN and, eventually, the preferences 528 provided by the MN itself in the previous message exchange (i.e. 529 Service-Options-TLV, Home-Agent-Address-TLV, Home-Address-TLV). For 530 example, based on the knowledge of the MN's current point of 531 attachment (i.e. the current NAS), the AAAH server may select, among 532 the HAs available in the home domain, the one that is closest to the 533 MN in terms of IP routing hops. This approach is normally expected to 534 improve performance. However, the detailed definition of a Home Agent 535 Selection Algorithm is out of the scope of this document. 537 After a suitable HA has been identified, AAAH interacts with it to 538 dynamically configure all the state needed to enable subsequent MIPv6 539 protocol operations, including the authorization lifetime of the 540 MIPv6 service granted to the MN. Possible protocols that can be used 541 for this purpose include Diameter (through a new Diameter 542 Application), SNMPv3 or COPS-PR. Further details about this 543 communication are provided in section 6. Anyway, the detailed 544 specification of the interface between AAAH and HA is out of the 545 scope of this document. 547 As soon as the AAAH server has configured the state on the HA, it 548 continues the EAP session communicating to the MN all the MIPv6 549 configuration data it is waiting for. This is achieved delivering to 550 the MN an EAP Request containing a MIPv6-Authorization-TLV and the 551 following sub-TLVs: Home-Address-TLV (i.e. the home address) and 552 Home-Agent-Address-TLV (i.e. the address of the HA). 554 The pre-shared key needed to bootstrap the IKE session with the Home 555 Agent, and set-up the correspondent IPsec Security Association, can 556 be derived by the MN from the keying material exported by the 557 employed EAP method. This approach provides excellent security 558 guarantees but requires the definition of a specific Application 559 Master Session Key (AMSK) [14] bound to MIPv6. Alternatively, if the 560 on-going EAP session provides confidentiality support, the AAAH 561 server can override the default behaviour by explicitly delivering a 562 valid PSK to the MN within an IKE-PSK-TLV. 564 After the MN has received all the configuration data from the AAAH 565 server (i.e. HA address, Home Address and optionally the PSK), it 566 sends back an EAP Response containing a Negotiation-Result-TLV, 567 stating whether it accepts, or refuses, the proposed arrangement. If 568 the MN refuses the configuration, the AAAH server should immediately 569 release the resources previously allocated on the Home Agent. 571 After the completion of the EAP session, MN holds all data needed to 572 perform Mobile IPv6 registration: the MN knows its Home Address, the 573 address of the correspondent Home Agent and all cryptographic data 574 needed to establish the IPsec security association with it; 575 furthermore, since it has been successfully authenticated, the MN can 576 acquire an IPv6 address to be used as Care-of Address. 578 The first operation carried out by the MN after the acquisition of 579 the Care-of Address is the establishment of the IPsec Security 580 Association with the HA, that is mandated by [1] to protect MIPv6 581 location update signaling. Set-up of the IPsec SA can be accomplished 582 following the procedure detailed in [11]. In this regard, it is 583 important to note that: 585 - since the mutual authentication in IKE Phase 1 is based on a Pre- 586 Shared Key (PSK), Aggressive Mode must be used. This is because 587 Aggressive Mode is the only way to use PSK authentication with a 588 NAI as peer identifier [12]. Indeed, the NAI of the MN is the only 589 identity information stored in the HA (see section 6.2); 591 - in IKE phase 1 messages, the source address used by the MN has to 592 be the Care-of Address, as described in [11]; the Home Address is 593 used only in IKE phase 2; 595 - in IKE phase 2 (Quick Mode), while still using the CoA as source 596 address of IKE messages, the MN has to use the Home Address as its 597 peer identifier, so that the HA can correctly set the MN entries 598 in its Security Policy Database (SPD) and in the Security 599 Association Database (SAD). 601 As soon as the IPsec Security Association is established, MN can send 602 a Binding Update to the HA, thus starting up Mobile IPv6 service. 604 5.2 Management of reauthentication events 606 At the expiration of AAA session time-outs or after a change in the 607 point of attachment to the network (e.g. change of Access Point), a 608 re-authentication procedure is performed leading to the user identity 609 to be checked again along with its right to continue exploitation of 610 network resources. To that purpose the AAAH server may repeat a full 611 authentication or, alternatively, decide to use optimizations in 612 order to make the procedure faster. Once this phase is completed the 613 AAAH server also undertakes the re-negotiation of the MIPv6 service. 615 Since the MIPv6 bootstrapping procedure is assumed to be completely 616 stateless, when a re-authentication event occurs the AAAH server may 617 not know the state of the MIPv6 service on the MN. For this reason 618 the AAAH server starts the MIPv6 negotiation as in the bootstrap 619 case: it delivers a MIPv6-Authorization-TLV containing a Service- 620 Status-TLV and optionally a Service-Options-TLV. 622 If the MIPv6 service is not active on the MN the procedure continues 623 as described in section 5.1. Otherwise, the MN replies with a MIPv6- 624 Authorization-TLV containing a Service-Selection-TLV indicating that 625 the MIPv6 service is already in use. Furthermore, the MN inserts the 626 Home-Agent-Address-TLV and the Home-Address-TLV to inform the AAAH 627 server about its current state. The AAAH server can then get in touch 628 with the HA to check the integrity of the state and eventually renew 629 the MIPv6 authorization lifetime. If this procedure is accomplished 630 successfully, the AAAH server terminates the EAP communication 631 sending an EAP Success message. Otherwise, the AAAH server should 632 continue the EAP communication renegotiating the MIPv6 service (i.e. 633 allocation of a new HA and related Home Address). 635 This solution can be easily deployed even within a network including 636 several AAA servers, each one managing a subset of the available 637 Network Access Servers (NASs). This is because the re-negotiation 638 procedure does not assume to have any long term state related to 639 Mobile IPv6 stored on the AAAH server. In this way, everything works 640 correctly even if, due to MN's movements within the network, the AAAH 641 server that handles the re-authentication is not the same server that 642 authenticated the MN for the first time and performed the MIPv6 643 bootstrapping procedure. 645 6. Home Agent considerations 647 This section provides further thougths about the AAAH-HA 648 communication and lists specific features that have to be supported 649 by the Home Agent to allow dynamic negotiation of Mobile IPv6 650 protocol parameters. 652 6.1 Requirements on AAAH-HA communication 654 This draft details only the message exchange between the MN and the 655 AAAH server. Obviously a complete Mobile IPv6 bootstrapping solution 656 requires also the definition of a mechanism for the communication 657 between the Home Agent and the AAAH server. Possible protocols that 658 may be used for this purpose include SNMPv3, COPS-PR or Diameter. 660 The selected protocol should allow the AAAH server to: 662 - verify if the selected HA is available to serve the MN (e.g. based 663 on current traffic load and on the number of active bindings); 665 - send to the HA the MN's NAI, the authorization lifetime of the 666 Mobile IPv6 service granted to the MN, the IKE PSK to be used to 667 bootstrap the IPsec Security Association and, optionally, a set of 668 hints for the construction of the Home Address (i.e. a preferred 669 Home Address or a preferred Interface Identifier); 671 - obtain from the selected Home Agent a valid Home Address to be 672 assigned to the MN; 674 - force the termination of the Mobile IPv6 service for a specific MN 675 removing the state stored on the correspondent HA; 677 - manage the extension of the authorization lifetime for a specific 678 MN; 680 - retrieve the state associated to a specific MN from the 681 correspondent HA. 683 Moreover, the protocol selected to implement the communication 684 between the AAAH server and the HA should fulfill the following 685 general requirements: 687 - inactive peer detection: the AAAH server should be able to 688 promptly detect an HA failure. This may be useful to aid the HA 689 selection algorithm; 691 - mutual-authentication: the AAAH server and the HA must be able to 692 authenticate each other in order to prevent the installation of 693 unauthorized state on the HA; 695 - confidentiality: since the IKE pre-shared key is derived by the 696 AAAH server and then delivered to the HA, the correspondent 697 message exchange must be protected against eavesdropping. This 698 implies that confidentiality is one of the main requirements; 700 - integrity: the exchanged configuration parameters must be 701 protected against any alteration and thus the protocol must 702 provide integrity protection. 704 6.2 Management of MIPv6 authorization state 706 The Home Agent is required to store some authorization data for each 707 of the MNs it is serving. A new data structure may be used for this 708 purpose and it should include at least the following fields: 710 - NAI of the user; 712 - Home Address assigned to the MN; 714 - Cryptographic Data: this field includes all the information to be 715 used for bootstrapping IKE, that is the PSK value and its 716 lifetime; 718 - Authorization Lifetime: it is the lifetime of the Mobile IPv6 719 service granted to the MN; 721 At the expiration of the Authorization Lifetime the HA should check 722 if there is an active entry for the MN in its Binding Cache in order 723 to verify if the MN is still using Mobile IPv6. If the entry is 724 available the Home Agent should negotiate with the AAAH server an 725 extension of the Authorization Lifetime granted to the MN. Otherwise, 726 the HA should immediately release the authorization state associated 727 to that MN and eventually notify the session termination to the AAAH 728 server (e.g. by means of a Session Termination Request if the 729 employed AAAH-HA protocol is Diameter). 731 Moreover, the release of the resources previously allocated on the 732 Home Agent can be undertaken at any time by the AAAH server. 733 Typically this happens at credit exhaustion or when the MN 734 disconnects from the network. 736 The policies adopted by the AAAH server to release the resources 737 allocated to the MN may vary depending on the user service profile. 738 For instance, the AAAH server may decide to postpone the release of 739 the resources on the HA in order to allow the MN to continue using 740 the Mobile IPv6 service even if it has moved to an access network for 741 which no roaming agreements are in place (e.g. a corporate network or 742 a network providing cost-free access). In that case, the MN can 743 continue to rely on the IPsec SA previously negotiated with the HA 744 and the respective authorization is managed through the Mobile IPv6 745 Authorization Lifetime. 747 7. New EAP TLVs 749 The general format of an EAP-TLV is depicted below. 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 |M|R| Type | Length | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Value... 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 TLVs defined in this draft are: 760 - MIPv6-Authorization-TLV. This is a generic TLV which carries all 761 TLVs related to MIPv6 authorization and configuration. It is 762 defined as follows: 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 |M|R| Type | Length | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Value... 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 M 773 0 - Non-mandatory TLV 775 R 777 Reserved, set to zero (0) 779 Type 781 TBD - MIPv6-Authorization 783 Length 785 The length of the Value field in octets 787 Value 789 This field carries the subsequent TLVs 791 - Service-Status-TLV. This TLV is sent by the AAAH to inform the MN 792 about the status of Mobile IPv6 service. It is defined as follows: 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Type=Service-Status | Length | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Code | 799 +-+-+-+-+-+-+-+-+ 801 Type 803 TBD - Service-Status 805 Length 807 1 809 Code 811 0 = MIPv6 service is available 812 1 = MIPv6 service is not available 814 - Service-Selection-TLV. This TLV is sent by the MN to inform the 815 AAAH whether it wants to activate MIPv6 service or whether the 816 service is already active. 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Type=Service-Selection | Length | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Code | 823 +-+-+-+-+-+-+-+-+ 824 Type 826 TBD - Service-Selection 828 Length 830 1 832 Code 834 0 = activate MIPv6 service 835 1 = MIPv6 service already active 836 2 = do not activate MIPv6 service 838 - Service-Options-TLV. This TLV is used by the AAAH server to 839 advertise the service options the MN can ask for. It is also used 840 by the MN to communicate its selection to the AAAH. So far only 841 the HA in visited domain option has been defined. The TLV has the 842 following format: 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Type=Service-Options | Length | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 |V| Reserved | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Type 853 TBD - Service-Options 855 Length 857 2 859 V 860 from AAAH to MN: 861 0 = AAAH cannot provide a HA in the visited domain 862 1 = AAAH can provide a HA in the visited domain 864 from MN to AAAH: 865 0 = MN does not specify any preference on HA location 866 1 = MN is requesting a HA in the visited domain 868 Reserved 870 15 bit reserved set to 0 872 - Home-Agent-Address-TLV. It is defined as follows: 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 | Type=HA-Address | Length | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | | 879 | Home Agent Address | 880 | | 881 | | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Type 886 TBD - Home-Agent-Address 888 Length 890 16 892 Value 894 Home Agent Address 896 - Home-Address-TLV. It is defined as follows: 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Type=Home-Address | Length | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | | 903 | Home Address | 904 | | 905 | | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Type 910 TBD - Home-Address 912 Length 914 16 916 Value 918 Home Address 920 - IKE-PSK-TLV. This TLV carries data related to IKE bootstrap; the 921 value field contains the PSK lifetime and the PSK value. 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Type=IKE-PSK | Length | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Key Lifetime | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Key Value... 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Type 934 TBD - IKE-PSK 936 Length 938 4 + Key length 940 Value 942 Key Lifetime - the lifetime of the PSK in seconds. A value of 943 all ones means infinite 945 Key Value - the value of the PSK 947 - Negotiation-Result-TLV. It is defined as follows: 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Type=Negotiation-Result | Length | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Result-Code | 954 +-+-+-+-+-+-+-+-+ 956 Type 958 TBD - Result 960 Length 962 1 964 Value 966 0 = Success 967 128 = Failure 969 8. Security Considerations 971 The Mobile IPv6 bootstrapping procedure described in this document 972 assumes the MN and the AAA server of the home domain exchange the 973 necessary parameters exploiting the EAP communication established for 974 network access authentication. Therefore, to secure the bootstrapping 975 procedure, the employed EAP method must support mutual authentication 976 as well as integrity and replay protection. Moreover, if the pre- 977 shared key needed to bootstrap the IPsec SA with the Home Agent is 978 not derived from the EAP key hierarchy but explicitly delivered to 979 the MN by the AAAH server, the EAP method must also provide 980 confidentiality. Several tunneled and non tunneled EAP methods, like 981 PEAPv2 and EAP-IKEv2, fulfill all of these security requirements. 983 Acknowledgments 985 The authors would like to thank Simone Ruffino, Tom Hiller, Hannes 986 Tschofening, Rafael Marin Lopez, Hiroyuki Ohnishi, Mayumi Yanagiya 987 and Yoshihiro Ohba for their valuable comments. 989 References 991 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 992 IPv6", RFC 3775, June 2004. 994 [2] Patel, A. et al. "Problem Statement for bootstrapping Mobile 995 IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 996 2004. 998 [3] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, 999 June 2004. 1001 [4] Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2", 1002 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 1003 October 2003. 1005 [5] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "EAP Flexible 1006 Authentication via Secure Tunneling (EAP-FAST)", draft-cam- 1007 winget-eap-fast-00.txt (work in progress), February 2004 1009 [6] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, 1010 "Extensible Authentication Protocol (EAP)", RFC 3748, June 1011 2004. 1013 [7] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication 1014 Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-04 (work in 1015 progress), April 2004. 1017 [8] Tschofenig, H., Kroeselberg, D., Ohba, Y., "EAP IKEv2 Method", 1018 draft-tschofenig-eap-ikev2-03, February 2004. 1020 [9] Narten, T., Draves, R., "Privacy Extensions for Stateless 1021 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1023 [10] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter Mobile 1024 IPv6 Application", draft-le-aaa-diameter- mobileipv6-03 1025 (expired), April 2003. 1027 [11] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect 1028 Mobile IPv6 Signaling between Mobile Nodes and Home Agents", 1029 RFC 3776, June 2004. 1031 [12] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 1032 2409, November 1998. 1034 [13] Forsberg, D. et al., "Protocol for Carrying Authentication for 1035 Network Access (PANA)", draft-ietf-pana-pana-04 (work in 1036 progress), May 2004. 1038 [14] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., "EAP Key 1039 Management Framework", draft-ietf-eap-keying-02 (work in 1040 progress), July 2004. 1042 [15] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. 1043 Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for 1044 Policy Provisioning,", RFC 3084, March 2001. 1046 [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 1047 and Applicability Statements for Internet-Standard Management 1048 Framework", RFC 3410, December 2002. 1050 Authors' Addresses 1052 Gerardo Giaretta 1053 Telecom Italia Lab 1054 via G. Reiss Romoli, 274 1055 10148 TORINO 1056 Italy 1057 Phone: +39 011 2286904 1058 Email: gerardo.giaretta@tilab.com 1060 Ivano Guardini 1061 Telecom Italia Lab 1062 via G. Reiss Romoli, 274 1063 10148 TORINO 1064 Italy 1065 Phone: +39 011 2285424 1066 Email: ivano.guardini@tilab.com 1068 Elena Demaria 1069 Telecom Italia Lab 1070 via G. Reiss Romoli, 274 1071 10148 TORINO 1072 Italy 1073 Phone: +39 011 2285403 1074 Email: elena.demaria@tilab.com 1076 Julien Bournelle 1077 GET/INT 1078 9 rue Charles Fourier 1079 Evry 91011 1080 France 1081 Email: julien.bournelle@int-evry.fr 1083 Maryline Maknavicius-Laurent 1084 GET/INT 1085 9 rue Charles Fourier 1086 Evry 91011 1087 France 1088 Email: maryline.maknavicius@int-evry.fr 1090 Intellectual Property Statement 1092 The IETF takes no position regarding the validity or scope of any 1093 Intellectual Property Rights or other rights that might be claimed to 1094 pertain to the implementation or use of the technology described in 1095 this document or the extent to which any license under such rights 1096 might or might not be available; nor does it represent that it has 1097 made any independent effort to identify any such rights. Information 1098 on the procedures with respect to rights in RFC documents can be 1099 found in BCP 78 and BCP 79. 1101 Copies of IPR disclosures made to the IETF Secretariat and any 1102 assurances of licenses to be made available, or the result of an 1103 attempt made to obtain a general license or permission for the use of 1104 such proprietary rights by implementers or users of this 1105 specification can be obtained from the IETF on-line IPR repository at 1106 http://www.ietf.org/ipr. 1108 The IETF invites any interested party to bring to its attention any 1109 copyrights, patents or patent applications, or other proprietary 1110 rights that may cover technology that may be required to implement 1111 this standard. Please address the information to the IETF at 1112 ietf-ipr@ietf.org. 1114 Disclaimer of Validity 1116 This document and the information contained herein are provided on an 1117 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1118 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1119 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1120 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1121 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1122 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1124 Copyright Statement 1126 Copyright (C) The Internet Society (2004). This document is subject 1127 to the rights, licenses and restrictions contained in BCP 78, and 1128 except as set forth therein, the authors retain all their rights. 1130 Acknowledgement 1132 Funding for the RFC Editor function is currently provided by the 1133 Internet Society.