idnits 2.17.1 draft-giaretta-mip6-amsk-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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 740. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 747. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 751), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 751. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 1) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 549: '... G1.4 should use MUST (instead of SHOU...' RFC 2119 keyword, line 550: '... MUST provide confidentiality sin...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2006) is 6401 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) == Unused Reference: '2' is defined on line 596, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 600, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 603, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 636, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 643, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 647, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 651, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 656, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 668, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 4285 (ref. '5') ** Obsolete normative reference: RFC 4306 (ref. '6') (Obsoleted by RFC 5996) -- Duplicate reference: RFC3753, mentioned in '7', was also mentioned in '3'. ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '7') -- Duplicate reference: RFC3748, mentioned in '8', was also mentioned in '4'. ** Downref: Normative reference to an Informational RFC: RFC 4186 (ref. '9') -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-00 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-14 == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-00 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-08 == 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 (-04) exists of draft-giaretta-mip6-authorization-eap-02 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-00 -- No information found for - is the name correct? == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-01 Summary: 12 errors (**), 0 flaws (~~), 22 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group G. Giaretta 3 Internet Draft I. Guardini 4 Expires: April 2007 E. Demaria 5 M. La Monaca 6 Telecom Italia 7 J. Bournelle 8 M. Laurent-Maknavicius 9 GET/INT 10 October 2006 12 Application Master Session Key (AMSK) for Mobile IPv6 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 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 This Internet-Draft will expire on April 17, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). All Rights Reserved. 45 Abstract 47 The Extensible Authentication Protocol (EAP) defines an extensible 48 framework for performing network access authentication. Most EAP 49 authentication algorithms, also known as "methods", export keying 50 material that can be used with lower layer ciphersuites. It can be 51 useful to leverage this keying material to derive usage specific 52 keys that can be used to authenticate users or protect information 53 exchange by other applications or services.For this purpose [10] 54 proposes to derive root keys for each usage application and, then, 55 child keys to actual be used. 56 This document defines how to generate a Usage Specific Root Key 57 (USRK) and a series of Application Master Session Keys (AMSKs) 58 specific to Mobile IPv6 service. These AMSKs can be used by Mobile 59 Node and Home Agent to bootstrap Mobile IPv6 protocol operation. 61 Table of Contents 63 1. Introduction................................................3 64 2. Terminology.................................................4 65 3. Applicability Statement.....................................6 66 3.1 Bootstrapping IPsec SAs with Pre-shared keys.............6 67 3.2 Bootstrapping rfc4285-based SAs..........................6 68 4. Key derivation.............................................10 69 4.1 Mobile IPv6 USRK derivation.............................10 70 4.2 Mobile IPv6 AMSKs derivation............................10 71 4.3 Lifetimes...............................................11 72 5. Open issues................................................12 73 5.1 Key length (and other key related parameters)...........12 74 5.2 rfc4285 SAs.............................................12 75 5.3 Key Freshness...........................................12 76 5.4 Multiple EAP sessions...................................12 77 5.5 Identity management and key binding.....................12 78 6. AAA-HA interface requirements..............................14 79 7. Security Considerations....................................15 80 8. IANA Considerations........................................16 81 9. Acknowledgments............................................17 82 10. References.................................................17 83 10.1 Normative References..................................17 84 10.2 Informative References................................17 85 Authors' Addresses..............................................19 86 Intellectual Property Statement.................................20 87 1. Introduction 89 Mobile IPv6 (MIPv6) requires that Mobile Nodes (MNs) and Home 90 Agents (HAs) share a security association to protect binding 91 management signaling. The MIPv6 protocol specification [1] 92 mandates the use of IPsec for this purpose and therefore requires 93 the MN to be provisioned with the data needed to bootstrap an 94 IPsec Security Association (SA) with its Home Agent. This is one 95 of the main issues of the so called Mobile IPv6 bootstrapping 96 problem [11]. The IPsec SA between MN and HA can be established 97 from a shared secret using IKE with Pre-Shared Key (PSK) 98 authentication [6]. Alternatively, the Authentication Protocol for 99 MIPv6 [5] presents a different security mechanism for Mobile IPv6 100 that requires a shared secret between MN and HA to authenticate 101 the binding messages. In scenarios where network access control is 102 based on EAP those shared secrets can be derived from the EAP key 103 hierarchy [13]. In particular [10] specifies a mechanism for 104 deriving cryptographically separate root keys from the EMSK, 105 called Usage Specific Root Keys (USRK) in order to create a set of 106 keys for usage specific needs. 108 This document defines how to generate EAP derived key (USRK) 109 specific for Mobile IPv6 bootstrapping. In addition, it defines 110 how to derive application specific keys (AMSKs) both for IPsec SAs 111 and Authentication Protocol SAs. The solution presented in this 112 document is agnostic of the AAA-HA interface model (e.g. push/pull 113 model). 115 2. Terminology 117 Most of the terms used in this document are defined in this 118 section; more detailed general mobility and EAP terminology can be 119 found in [7] and [13]. 121 MSA 123 Mobility Service Authorizer. A service provider that 124 authorizes Mobile IPv6 service. 126 ASA 128 Access Service Authorizer. A network operator that 129 authenticates a mobile host and establishes the mobile 130 host's authorization to receive Internet service. 132 Split scenario 134 A scenario where the mobility service and the network access 135 service are authorized by different entities (MSA!=ASA). 137 Integrated scenario 139 A scenario where the mobility service and the network access 140 service are authorized by the same entity (MSA=ASA). 142 EAP server 144 The entity that terminates the EAP authentication method 145 with the peer. In the case where no backend authentication 146 server is used, the EAP server is part of the authenticator. 147 In the case where the authenticator operates in pass-through 148 mode, the EAP server is located on the backend 149 authentication server. 151 MSK Master Session key 153 Keying material that is derived between the EAP peer and 154 server and exported by the EAP method. The MSK is at least 155 64 octets in length. 157 EMSK Extended Master Session Key 159 Additional keying material derived between the peer and 160 server that is exported by the EAP method. The EMSK is at 161 least 64 octets in length, and is never shared with a third 162 party. 164 USRK Usage Specific Root Key 166 Keys derived from the EMSK which are cryptographically 167 separate from each other. 169 AMSK Application Master Session Key 171 Keys derived from the USRK which are cryptographically 172 separate from each other. 174 MN Mobile Node 176 A node that can change its point of attachment from one link 177 to another, while still being reachable via its home 178 address. 180 HA Home Agent 182 A router on a mobile node's home link with which the mobile 183 node has registered its current care-of address. While the 184 mobile node is away from home, the home agent intercepts 185 packets on the home link addressed to the mobile node's home 186 address, encapsulates them, and tunnels them to the mobile 187 node's registered care-of address. 189 BU Binding Update 191 A message indicating a mobile node's current mobility 192 binding, and in particular its care-of address. 194 BA Binding Acknowledgement 196 A message used to acknowledge receipt of a Binding Update. 198 3. Applicability Statement 200 The Mobile IPv6 bootstrapping problem statement [11] describes two 201 main scenarios. In the first scenario (i.e. the split scenario), 202 the mobility service is authorized by a different service 203 authorizer (MSA, Mobility Service Authorizer) than the basic 204 network access authorizer (ASA, Access Service Authorizer). In the 205 second scenario (i.e. the integrated scenario), the mobile node's 206 mobility service is authorized by the same service authorizer as 207 the basic network access service authorizer. This implies that 208 only in the integrated scenario it is possible to leverage the 209 network access authentication to bootstrap mobility service. 210 Therefore, the approach defined in this document applies only to 211 the integrated scenario. 213 This specification assumes that AAA server and the EAP server are 214 co-located, with the latter exporting the keys to the former. As 215 already pointed out, the solution presented here addresses both 216 the IPsec and rfc4285-based SAs bootstrapping. 218 3.1 Bootstrapping IPsec SAs with Pre-shared keys 220 The bootstrapping solution defined for integrated scenario [19] 221 requires the mobile node to run an EAP exchange over IKEv2. In 222 case the mobile node uses EAP for network access authentication, 223 this implies that the MN executes two EAP exchanges, possibly with 224 the same EAP server and using the same credentials. 226 Therefore, in this scenario a key derived from EAP key hierarchy 227 and named IKEv2-AMSK can be used as the IKEv2 Pre-shared Key 228 (PSK), with the advantage that only one EAP exchange is performed 229 (during network access authentication). 231 The key is derived by the MN and the AAAH server and needs to be 232 transferred to the HA (together with the MN/key identifier). Two 233 different approaches are possible: 235 1. The AAAH server sends proactively the key to the HA (push 236 approach). A requirement for this approach is that the AAAH 237 server needs to know the HA assigned to the MN. 239 2. The HA requests to the AAAH the PSK during the IKEv2 240 exchange with the MN (pull approach). In this case the HA 241 needs to know the AAAH server used by a specific MN for 242 network access authentication. 244 Figure 1 and 2 (pag. 8) show the message flow of the two models. 245 Note that in both approaches the MN/key identifier must be sent 246 via the AAA-HA interface and needs to be the same identifier used 247 in IKEv2. 249 3.2 Bootstrapping rfc4285-based SAs 251 Concerning rfc4285-based SAs, the keying material derived from EAP 252 can be exploited in two different ways, since two possible 253 authentication options are specified: 255 1. MN-HA Mobility Message Authentication Option. In this case a 256 key derived from EAP key hierarchy and named MN-HA-AMSK, is 257 used as the shared key for the security association between 258 the MN and HA. Similarly to the IKEv2 Pre-shared key case, 259 both the push and pull model can be envisioned for key 260 delivery. The MN/key identifier must be sent via the AAA-HA 261 interface and needs to be the same identifier to be used as 262 Mobile Node Identifier (in the form of NAI) in the BUs. 264 2. MN-AAA Mobility Message Authentication Option. In this case 265 a key derived from EAP key hierarchy and named MN-AAA-AMSK, 266 is used as the shared-key for the security association 267 between the MN and the AAAH server. In this case, no key 268 delivery is needed. 270 EAP PEER EAP-AUTH EAP-AUTH Server 271 Home 272 MN NAS Server 273 Agent 274 | | 275 | 276 | EAP session | 277 | 278 |<----------------------------->| 279 | 280 | | 281 | 282 | o o o | 283 | 284 | | 285 | 286 | | Access-Accept | 287 | 288 U A| | EAP Success, MSK | 289 | 290 S M| EAP Succ. |<------------------+ 291 | 292 R S|<----------| \ ------------ 293 | 294 K K| | USRK | 295 | 296 s| |generation | 297 | 298 | ------------ 299 | 300 | Binging Update / IKEv2 IKE_AUTH 301 | 302 |-------------------------------------------------------------- 303 >| 304 | 305 | 306 | | "Key-Request, MN identity" 307 | 308 | |<----------------------------- 309 -| 310 | | "keying material" 311 | 312 | | ----------------------------- 313 >| 314 | ----------- / 315 | 316 | | AMSKs | 317 | 318 | |generation | 319 | 320 | ----------- 321 | 323 Figure 1 - Pull model message flow 325 EAP PEER EAP-AUTH EAP-AUTH Server 326 Home 327 MN NAS Server 328 Agent 329 | | 330 | 331 | EAP session | 332 | 333 |<----------------------------->| 334 | 335 | | 336 | 337 | o o o | 338 | 339 | | 340 | 341 | | Access-Accept | 342 | 343 U A| | EAP Success, MSK | "Keying material, MN 344 identity"| 345 S M| EAP Succ. |<------------------+------------------------------ 346 >| 347 R S|<----------| \ ------------ 348 | 349 K K| | USRK | ----------- / 350 | 351 s| |generation | | AMSKs | 352 | 353 | ------------ |generation | 354 | 355 | ----------- 356 | 357 | Binging Update / IKEv2 IKE AUTH 358 | 359 |-------------------------------------------------------------- 360 >| 362 Figure 2 - Push model message flow 363 4. Key derivation 365 The key hierarchy proposed in this document is depicted in Figure 366 3. Just one key (MIP6-USRK) is directly derived from the EMSK. 367 Three different keys are then generated from the MIP6-USRK: IKEv2- 368 AMSK, MN-HA-AMSK and MN-AAA-AMSK. The basic assumption is that the 369 MIP6-USRK is exported by the EAP server to the AAA server that 370 sends this key to the HA; the other keys are then derived directly 371 from the USRK by the HA of the MSP. 373 EMSK 374 | 375 MIP6-USRK 376 | 377 +----------------------------------+ 378 | | | 379 MN-AAA-AMSK MN-HA-AMSK IKEv2-AMSK 381 Figure 3 - Proposed key hierarchy 383 4.1 Mobile IPv6 USRK derivation 385 Mobile IPv6 USRK (MIP6-USRK) is derived through the general key 386 derivation function (KDF) specified in [10]. The KDF is based on a 387 pseudo random function shown below: 389 KDF = PRF(key, data) 391 where: 393 PRF = HMAC-SHA-256 394 key = EMSK 395 data = label + "\0" + op-data + length 396 label = MIPv6-USRK-key 397 op-data = EAP Session-ID 398 length = 128 bit 399 "\0" = is a NUL byte (0x00 in hex) 400 + denotes concatenation 402 Key name = PRF-64 (EAP Session-ID, key-label) 403 Where PRF-64 is the first 64 bits from the output. 405 4.2 Mobile IPv6 AMSKs derivation 407 Based on Mobile IPv6 USRK, the keys for Mobile IPv6 operations 408 (IKEv2-AMSK, MN-HA-AMSK, and MN-AAA-AMSK) can be generated. These 409 keys are derived as follows: 411 KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... 413 where: 414 T1 = prf (K, S | 0x01) 415 T2 = prf (K, T1 | S | 0x02) 416 T3 = prf (K, T2 | S | 0x03) 417 T4 = prf (K, T3 | S | 0x04) 419 prf = HMAC-SHA-256 420 K = USRK-MIPv6 421 L = key label 422 D = application data 423 O = output length 424 S = L | " " | D | O 426 The application specific parameters are set as follows: 428 IKEv2 Pre-shared key AMSK (IKEv2-AMSK): 429 key label = "MIPv6-IKEv2-key" 430 application data = "HA Address" 431 output length = variable (default 128) 432 (key name = PRF-64(IKEv2-AMSK | EAP Session-ID) 434 rfc4285 MN-HA key (MN-HA-AMSK): 435 key label = "rfc4285-MN-HA-key" 436 application data = "HA Address" 437 output length = 128 bit 438 (key name = PRF-64(MN-HA-AMSK | EAP Session-ID) 440 rfc4285 MN-AAA key (MN-AAA-AMSK): 441 key label = "rfc4285-MN-AAA-key" 442 application data = "" 443 output length = 128 bit 444 (key name = PRF-64(MN-AAA-AMSK | EAP Session-ID) 446 The actual key(s) to be derived by MN and HA depend on the 447 authentication method deployed by the operator (or imposed by 448 specific technologies). It should be possible on the operator side 449 to differentiate users' authentication method on profile basis. 451 The KDF does not include the home address in the application data 452 because in this way the MN can derive the AMSK even if it does not 453 know its home address yet. This is what might happen in some 454 dynamic home address assignment scenarios. 456 4.3 Lifetimes 458 As specified in [10] the lifetime of USRK keys must be equal to 459 the lifetime of the EMSK. Lifetime of child keys, instead, can be 460 different then root key�s lifetime and its specification is left 461 to usage definition. 463 Since the IKEv2-AMSK serves only for identity verification and not 464 for authentication or ciphering purposes, there might be no need 465 to re-generate the key at regular intervals. For this reason its 466 lifetime is set equal to the MIP6-USRK lifetime. 468 Since the MN-HA key is used to authenticate BUs and BAs messages, 469 there is a clear need to keep these keys fresh and therefore to 470 derive new keys periodically. This is discussed in section 5.3. 472 Obviously all keys must be refreshed whenever a new EMSK is 473 generated (i.e. during re-authentication events). 475 5. Open issues 477 The usage of EAP-derived keying material is still a work in 478 progress in IETF and a good amount of study is underway to 479 standardize generation and usage for keys generated from the EMSK. 480 For this reason, this document leaves open some issues as input 481 for HOKEY WG and others related WGs. 483 5.1 Key length (and other key related parameters) 485 This specification doesn't address the problem of negotiating the 486 key length; this is a general issue for AMSKs and should be solved 487 in a generic way, not depending on the application that makes use 488 of the keys (e.g. Mobile IPv6 bootstrapping). 490 One very basic approach, applicable to some scenarios, is that the 491 operator pre-provisions the user equipment with the right 492 parameters (e.g. the right key lenght for a specific application). 494 If an explicit negotiation is needed, a possible approach could be 495 the one adopted in [18] that leverages the capability of some EAP 496 methods (e.g. EAP-SIM, EAP-FAST, etc.) to carry arbitrary 497 parameters during the authentication phase. 499 However, it is worthwhile noting that some applications require 500 only fixed length keys (e.g. MN-HA-AMSK and MN-AAA-AMSK for the 501 MIPv6 Authentication Protocol) and for those applications this is 502 not an issue. 504 5.2 rfc4285 SAs 506 This document addresses only the negotiation of the shared secret 507 among MN and HA (or AAA). Other parameters such as SPIs must be 508 negotiated through other mechanisms. As for the key length issue 509 this could be addressed by an explicit negotiation [18]. Another 510 approach might be the derivation of the SPI from the EAP keying 511 hierarchy itself. 513 5.3 Key Freshness 515 While not an issue for IKEv2 PSK authentication, for rfc2485-based 516 authentications the keys used to authenticate binding management 517 messages should be fresh and therefore periodically changed. This 518 document addresses only bootstrapping mechanisms and so the 519 renewal of keying material is out of scope. A suggested solution 520 may be that a new MN-HA-AMSK is generated at each BU/BA completed 521 exchange (e.g. exchanging nonces in BUs and BAs). 523 5.4 Multiple EAP sessions 525 In some scenarios (e.g. multi-homed terminals) a MN may have more 526 than one active EAP session at the same time. Therefore, there is 527 the need to define criteria for deciding which session(s) are in 528 charge of generating AMSKs, and for which applications. 530 5.5 Identity management and key binding 532 A MN can be associated to several identities at the same time 533 (e.g. pseudonyms for identity privacy or temporary identities for 534 EAP fast reconnect techniques like [9]). The AAAH server must be 535 aware of the identity used by the MN in IKEv2 or rfc-4285 536 signaling. In pull model this is needed to allow the AAAH server 537 to select the correct key to be delivered, upon requests, to the 538 HA. In push model this is needed to allow the AAAH server to 539 proactively deliver to the HA the correct MN identity information 540 so that the HA can bind the subsequent authentication requests to 541 the right key. 543 6. AAA-HA interface requirements 545 In order to fulfil the bootstrapping of MIPv6-related SAs, this 546 document adds/modifies some requirements for the HA-AAA interface 547 [21]: 549 - G1.4 should use MUST (instead of SHOULD): "The AAA-HA interface 550 MUST provide confidentiality since it may be used to transfer 551 keying material (e.g. shared key generated during EAP 552 authentication)" 554 - HAs must be able to fetch keys from AAA servers (pull approach) 556 - the AAAH server must be able to push a key into the HA (push 557 approach) 559 - key identifiers and lifetimes must be transferred alongside the 560 key 562 - in the request sent to the AAAH server in pull mode, HA must 563 specify the HA address known be the MN, so that the AAAH server 564 can derive the right key. 566 7. Security Considerations 568 Sending USRK for Mobile IPv6 from the AAA server to the HA 569 requires that the protocol used for AAA-HA communication provides 570 mutual authentication, integrity/reply protection and 571 confidentiality. 573 Moreover, since this document is strongly based on EAP [8] and the 574 EAP Keying Management Framework [13], additional security 575 considerations are bound to those valid for the EAP Keying 576 Framework. 578 8. IANA Considerations 580 This document does not require actions by the IANA. 582 9. Acknowledgments 584 The authors would like to thank Alpesh Patel, Hannes Tschofenig, 585 Rafa Lopez and Antonio Skarmeta for reviewing the document and the 586 European Commission support in the co-funding of the ENABLE 587 project, where this work is partly being developed. 589 10. References 591 10.1 Normative References 593 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 594 IPv6", RFC 3775, June 2004. 596 [2] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect 597 Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 598 3776, June 2004. 600 [3] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, 601 June 2004 603 [4] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 604 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 605 June 2004. 607 [5] A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury, 608 "Authentication Protocol for Mobile IPv6", RFC 4285, January 609 2006. 611 [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 612 December 2005. 614 [7] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, 615 June 2004 617 [8] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., Levkowetz, 618 H., "Extensible Authentication Protocol (EAP)", RFC 3748, June 619 2004. 621 [9] Haverinen, H., Salowey, J. "Extensible Authentication Protocol 622 Method for Global System for Mobile Communications (GSM) 623 Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006. 625 [10] Salowey J., Dondeti L., Narayanan V., Nakhjiri M., 626 "Specification for the Derivation of Usage Specific Root Keys 627 (USRK) from an Extended Master Session Key (EMSK)", draft- 628 salowey-eap-emsk-deriv-01 (work in progress), June 2006. 630 10.2 Informative References 632 [11] Patel, A. et al. "Problem Statement for bootstrapping Mobile 633 IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 634 2004. 636 [12] K. Chowdhury, J. Bournelle, M. Nakhjiri, "Problem Statement for 637 AMSK", February 2006. 639 [13] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., "EAP Key 640 Management Framework", draft-ietf-eap-keying-14(work in 641 progress), June 2006. 643 [14] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "EAP Flexible 644 Authentication via Secure Tunneling (EAP-FAST)", draft-cam- 645 winget-eap-fast-00.txt (work in progress), February 2004 647 [15] Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2", 648 draft-josefsson-pppext-eap-tls-eap-08 (work in progress), July 649 2004. 651 [16] Haverinen, H. and J. Salowey, "Extensible Authentication 652 Protocol Method for GSM Subscriber Identity Modules (EAP-SIM)", 653 draft-haverinen-pppext-eap-sim-13 (work in progress), April 654 2004. 656 [17] Arkko, J. and H. Haverinen, "EAP-AKA Authentication", draft- 657 arkko-pppext-eap-aka-12 (work in progress), April 2004. 659 [18] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., Laurent- 660 Maknavicius, M., "MIPv6 Authorization and Configuration based on 661 EAP", draft-giaretta-mip6-authorization-eap-02 (work in 662 progress), October 2004. 664 [19] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 665 the Integrated Scenario", draft-ietf-mip6-bootstrapping- 666 integrated-dhc-00 (work in progress), October 2005. 668 [20] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 669 draft- ietf-mip6-bootstrapping-split-01 (work in progress), 670 October 2005. 672 [21] Giaretta G., Guardini I., Demaria E., Bournelle J., Lopez, R., 673 "Goals for AAA-HA interface ", draft-ietf-mip6-aaa-ha-goals-01 674 (work in progress), January 2006. 676 Authors' Addresses 678 Gerardo Giaretta 679 Telecom Italia Lab 680 via G. Reiss Romoli, 274 681 10148 TORINO 682 Italy 683 Phone: +39 011 2286904 684 Email: gerardo.giaretta@telecomitalia.it 686 Ivano Guardini 687 Telecom Italia Lab 688 via G. Reiss Romoli, 274 689 10148 TORINO 690 Italy 691 Phone: +39 011 2285424 692 Email: ivano.guardini@telecomitalia.it 694 Elena Demaria 695 Telecom Italia Lab 696 via G. Reiss Romoli, 274 697 10148 TORINO 698 Italy 699 Phone: +39 011 2285403 700 Email: elena.demaria@telecomitalia.it 702 Michele La Monaca 703 Telecom Italia Lab 704 via G. Reiss Romoli, 274 705 10148 TORINO 706 Italy 707 Phone: +39 011 2285729 708 Email: michele.lamonaca@telecomitalia.it 710 Julien Bournelle 711 GET/INT 712 9 rue Charles Fourier 713 Evry 91011 714 France 715 Email: julien.bournelle@int-evry.fr 717 Maryline Laurent-Maknavicius 718 GET/INT 719 9 rue Charles Fourier 720 Evry 91011 721 France 722 Email: maryline.maknavicius@int-evry.fr 723 Intellectual Property Statement 725 The IETF takes no position regarding the validity or scope of any 726 Intellectual Property Rights or other rights that might be claimed 727 to pertain to the implementation or use of the technology 728 described in this document or the extent to which any license 729 under such rights might or might not be available; nor does it 730 represent that it has made any independent effort to identify any 731 such rights. Information on the procedures with respect to rights 732 in RFC documents can be found in BCP 78 and BCP 79. 734 Copies of IPR disclosures made to the IETF Secretariat and any 735 assurances of licenses to be made available, or the result of an 736 attempt made to obtain a general license or permission for the use 737 of such proprietary rights by implementers or users of this 738 specification can be obtained from the IETF on-line IPR repository 739 at 740 http://www.ietf.org/ipr. 742 The IETF invites any interested party to bring to its attention 743 any copyrights, patents or patent applications, or other 744 proprietary rights that may cover technology that may be required 745 to implement this standard. Please address the information to the 746 IETF at 747 ietf-ipr@ietf.org. 749 Full Copyright Statement 751 Copyright (C) The Internet Society (2006). All Rights Reserved. 753 This document is subject to the rights, licenses and restrictions 754 contained in BCP 78, and except as set forth therein, the authors 755 retain all their rights. 757 Disclaimer of Validity 759 This document and the information contained herein are provided on 760 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 761 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 762 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 763 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 764 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 765 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 766 PARTICULAR PURPOSE. 768 Acknowledgment 770 Funding for the RFC Editor function is currently provided by the 771 Internet Society.