idnits 2.17.1 draft-liebsch-netext-pmip6-authiwk-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 12, 2012) is 4237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IPmn' is mentioned on line 276, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG S. Gundavelli 3 Internet-Draft Cisco 4 Intended status: Informational M. Liebsch 5 Expires: March 16, 2013 NEC 6 P. Seite 7 France Telecom - Orange 8 September 12, 2012 10 PMIPv6 inter-working with WiFi access authentication 11 draft-liebsch-netext-pmip6-authiwk-05.txt 13 Abstract 15 Proxy Mobile IPv6, the IETF's protocol for network-based mobility 16 management, requires a completed and successful authentication of the 17 mobile node before it is registered at the mobility anchor. This 18 document describes inter-working between access authentication 19 mechanisms, such as IEEE 802.1X, and the Proxy Mobile IPv6 protocol 20 to enable trusted WiFi access to a network-based mobility management 21 domain. Furthermore, the use of authentication method specific 22 identifiers for unique identification of mobile nodes during setup 23 and maintenance of their mobility session is described, following 24 recommendations of related standards organizations, such as 3GPP and 25 the WiMAX Forum. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 16, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 65 3. Functional Objectives . . . . . . . . . . . . . . . . . . . . 6 67 4. Inter-working with IEEE 802.1X EAP . . . . . . . . . . . . . . 9 68 4.1. General use with authentication against a RADIUS Server . 9 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 7. Normative References . . . . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Proxy Mobile IPv6 (PMIPv6) [RFC5213] represents the IETF's protocol 81 for network-based mobility management and is being deployed in 82 various standards, such as the 3rd Generation Partnership Project 83 (3GPP), to complement host mobility. According to the PMIPv6 84 standard, mobile nodes (MN) do not require a secure interface to the 85 mobility anchor (LMA), as there is no direct signaling for mobility 86 management between the MN and the LMA, but the Mobility Access 87 Gateway (MAG) sets up and maintains a mobility binding on the LMA on 88 behalf of the host by means of a Proxy Binding Update (PBU). 89 [RFC5213] requires a successful authentication of the MN before the 90 MAG sends a PBU to the LMA to set up a mobility binding for the MN. 91 Furthermore, it assumes the MAG to be informed about a mobile node 92 identifier (MN-Identifier), which unambiguously identifies the MN 93 during the mobility session. Such MN-Identifier can be a static 94 identifier or a temporary identifier, which may be derived from a 95 static identifier. 97 This document intends to provide guidelines for PMIPv6 to inter-work 98 with access authentication protocols which have been designed for 99 IEEE 802-type of link technologies. Initial versions of this 100 document focus on IEEE 802.1X and its recommendation to use the 101 Extensible Authentication Protocol (EAP) [RFC3748]. Based on the 102 procedure for general inter-working, more specific use cases are 103 documented for discussion and reference. These use cases include the 104 use of the Wireless LAN technology according to the IEEE 802.11 105 standard to provide trusted access to 3GPP's packet core network. So 106 far, WLAN has been considered as untrusted access being even provided 107 by third parties and MNs connect through WLAN to the mobile operator 108 network through an established secure tunnel. Stepping towards WLAN 109 trusted access avoids the overhead of an established IPsec tunnel 110 with a packet data gateway in the operator's core network, but 111 requires inter-working between WLAN access authentication and the 112 operator's authentication and identification mechanisms. In the 113 context of trusted WLAN access and network-based mobility management, 114 WLAN security is being used to protect traffic on the wireless link 115 whereas the trust relationship between a MAG and the LMA is used to 116 convey traffic through the operator's core network. 118 The first version of this document discusses inter-working between 119 IEEE 802.1X EAP and PMIPv6 as well as some specific use cases for 120 trusted WLAN access in 3GPP's evolved packet core, which are based on 121 recommended authentication schemes, such as EAP-AKA [RFC5448]. 122 Further use cases with different EAP authentication schemes as well 123 as inter-working between PMIPv6 and web authentication will be added 124 to future versions of this document. Prior to describing details of 125 PMIPv6 inter-working with various access authentication schemes in 126 Section 4, Section 3 describes functional objectives to enable 127 trusted WLAN access to mobile operator networks and efficient inter- 128 working between WiFi access authentication and operators' mobility 129 management as well as policy and AAA infrastructure. 131 2. Conventions and Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 This document uses the terminology of [RFC5213]. The following 138 additional terms are used in the context of this draft: 140 o AAA -- Authentication, Authorization and Accounting 142 o EAP -- Extensible Authentication Protocol 144 o PCC -- Policy and Charging Control 146 o PMK -- Pairwise Master Key 148 3. Functional Objectives 150 Major motivation and objective to document inter-working between WiFi 151 access authentication and PMIPv6 is to describe complete system 152 operation, message sequences and identification schemes for network- 153 based mobility management using PMIPv6 including IEEE 802.11-based 154 access as proven and widely accepted radio technology and associated 155 authentication mechanisms. Inter-action between access 156 authentication and mobility management allows the specification of 157 missing components in [RFC5213], mainly referring to MAG operation 158 being triggered by successful MN authentication and MN 159 identification. 161 The relevance of WiFi radio access is proven by various standards' 162 initiative in specifying inter-working with IEEE 802.11-based 163 technology. One example is the 3GPP's interest in supporting traffic 164 offload to WLAN networks. Another example is the WiMax Forum's 165 Network Architecture, which consider a WiFi-WiMAX inter-working 166 function to enable access to the WiMAX network through WiFi radio 167 access and to support handover between WiFi and WiMAX radio access. 169 The PMIPv6 standard [RFC5213] assumes a completed and successful 170 access authentication of MNs (or their subscriber) before the MAG 171 registers the MN at an LMA by means of a PBU. One objective of this 172 document is to analyze relevant access authentication schemes and to 173 document the operation of PMIPv6 in dependency of these 174 authentication mechanisms. The EAP procedure as IEEE 802.X 175 recommendation is being considered most relevant at this time. Web- 176 authentication is a further popular access authentication scheme, 177 which can be analyzed and inter-working with PMIPv6 can be specified, 178 even though manual subscriber inter-action during access 179 authentication conflicts with automatic and seamless operation, e.g. 180 during dual radio handover from 3GPP access to WiFi access. 182 A further objective is to analyze the details of preferred 183 authentication schemes, taking 3GPP and WiMAX Forum recommendations 184 into account, and to document the use of common identifiers for 185 access authentication and PMIPv6-based mobility management. Such 186 identifier-specific inter-working must take further requirements, 187 such as unique identification of a MN during the mobility session, 188 into account. Some identifiers, which are generated during access 189 authentication, are unique for an MN, but are not stable and valid 190 beyond a certain radio access point. In such case, the MAG must use 191 a different identifier or resolve such temporary identifier into a 192 unique identifier which is valid beyond a single access point and 193 MAG. 195 A further goal is to analyze inter-working between access 196 authentication schemes and PMIPv6 during handover, which may also 197 imply a change in the radio access technology. Treatment of 198 authentication methods, keys and identifiers and associated inter- 199 working with PMIPv6 operation is documented. 201 Figure 1 depicts a high-level view of a WiFi network being integrated 202 into a mobile operator network as trusted access. Instead of using a 203 Security and Mobility Gateway, such as the 3GPP's Packet Data Gateway 204 (PDG), which terminates an IPsec tunnel with the UE, the system 205 relies on concatenated protected links between the UE and the WiFi 206 access network, as well as between the WiFi access network and the 207 LMA. The illustrated setup assumes a MAG function to be co-located 208 with the WiFi Access Point or a WiFi Controller (Ctrlr). Inter- 209 working between WiFi access authentication, PMIPv6 operation and the 210 operator network's AAA and PCC (Policy and Charging Control) 211 infrastructure is achieved by means of associated interfaces with the 212 LMA. Future extensions may consider a direct policy configuration 213 interface with the WiFi access network controller. This version of 214 the inter-working document does not assume a direct policy control 215 interface between the WiFi access network and the operator's PCC 216 system. If needed, the PMIPv6 protocol interface may be proposed to 217 convey associated information. Policy configuration in the WiFi 218 access network is considered out of scope of this documentation. 220 +-------+ +-----+ 221 (future option) |Policy | | | 222 +. . . . . . +Control| | AAA | 223 : +---+---+ | | 224 +--+ : | +-----+ 225 |MN|~~~~~~~ : | | 226 +--+ +-II-+ : +---+ +---+ 227 |WiFi| : | | 228 | AP +---+ +---+---+ +-+-+-+ 229 +----+ | | WiFi | PMIPv6 | + +--------+ 230 +----+ Ctrlr/+==============+ LMA | / Packet \ 231 ~~~~~ | | MAG | tunnel | +---< Data > 232 +-II-+ | +-------+ +-----+ \ Network / 233 |WiFi+---+ +--------+ 234 | AP | 235 +----+ 237 WiFi access Network-based 238 <----security &---><-------------------> 239 L2 mobility mobility 241 Figure 1: Integration of the WiFi radio technology to provide trusted 242 access to mobile operator networks 244 4. Inter-working with IEEE 802.1X EAP 246 4.1. General use with authentication against a RADIUS Server 248 IEEE 802.1X recommends EAP for access authentication, which can make 249 use of an Authentication Server using for example the RADIUS protocol 250 between the Authenticator and the Authentication Server. [RFC3579] 251 specifies RADIUS extensions to convey EAP attributes between an 252 Authenticator and the RADIUS server. Figure 2 depicts general inter- 253 working between PMIPv6 and IEEE 802.1X using EAP. 255 +--+ +--------+ +---+ +------++------+ 256 |MN| |WiFi CPE| |LMA| |RADIUS|| DHCP | 257 +--+ | MAG | +---+ |Server||Server| 258 | +--------+ | +------++------+ 259 | | | | | 260 |---EAPOL Start---->| | | | 261 |<---EAP REQ[IDap]--| | | | 262 (1)|--EAP RESP[IDmn]-->|-----RADIUS Access REQ[IDmn]---->| | 263 |<-EAP REQ[Method]--|<--RADIUS Access Chall[EAP REQ]--| | 264 (2)|-EAP RESP[Method]->|----RADIUS Access REQ[Method]--->| | 265 |<-EAP REQ[Method]--|<--RADIUS Access Chall[EAP REQ]--| | 266 |-EAP RESP[Method]->|----RADIUS Access REQ[Method]--->| | 267 |<---EAP SUCCESS----|<-RADIUS Access Accept[EAP SUC]--| | 268 (3)| LMA | | | 269 | assigned | | | 270 (4)|<----EAPOL-Key---->| | | | 271 (5)| |----PBU[SSID,IDmn]-->|<------DHCP------->| 272 | |<-----PBA[IPmn]------| | | 273 | +======IP tunnel======+ | | 274 (6)|---DHCP Discover-->|----DHCP Discover--->| | | 275 |<-DHCP Offer[IPmn]-|<--DHCP Offer[IPmn]--| | | 276 |--DHCP REQ[IPmn]-->|---DHCP REQ[IPmn]...>| | | 277 (7)|<-DHCP Ack[IPmn]---|<--DHCP Ack[IPmn]----| | | 278 | | | | | 279 |<------data--------+======IP tunnel======+--->- - | | 280 | | | | | 282 Figure 2: PMIPv6 inter-working with WPA2-802.1X access authentication 283 against a RADIUS server 285 After the MN has associated with a WiFi Access Point, the EAPOL 286 procedure starts (1). EAP attributes are mapped by the WiFi AP/Ctrlr 287 between EAPOL on the wireless link and RADIUS operation on the link 288 towards the RADIUS server. The RADIUS server selects one or multiple 289 authentication methods, which are performed with the MN in a 290 challenge-response procedure (2). As a result of a successful EAP 291 procedure, the RADIUS server may assign an LMA to the MN and signal 292 the LMA identifier or the LMA IP address to the MAG function in the 293 WiFi access network (3). The MN and the WiFi Access Point can now 294 negotiate the Session Key to protect the wireless access (4). At 295 that time, the MAG can take the EAP success as trigger to initiate 296 the PBU registration of the MN with the LMA (5). The keys and 297 identifiers being used and generated differ between the EAP and 298 authentication method. In general, the MAG should not use the 299 generated Session Key or security association identifier, as scope is 300 limited to the the MN's association with the Access Point. More 301 suitable is an identifier being negotiated during the authentication 302 procedure with the RADIUS server, e.g. based on the Pairwise Master 303 Key (PMK) or any identifier which derives from the PMK without 304 including single Access Point specific information, such as the AP's 305 MAC address. One example, which will be described in more detail in 306 future versions of this document, is the use of the International 307 Mobile Subscriber Identity (IMSI) to derive a NAI at the 308 Authentication Server. This IMSI-based NAI is then used as MN- 309 Identifier in the PBU. Such approach is being proposed in 3GPP for 310 trusted access to the mobile operator network through non-3GPP type 311 radio access networks [3GPP-TS23.402] [3GPP-TS33.402]. 313 As a result of the MN's registration, the LMA performs DHCP with a 314 DHCP server to retrieve a valid IP address for the MN (IPmn). The 315 assigned IP address is then signaled to the MAG in the PBA. The MN 316 learns about this IP address from the DHCP procedure (6). After 317 successful completion of the DHCP procedure (7), the MN can use the 318 protected wireless link to communicate with the network 319 infrastructure. 321 5. Security Considerations 323 This document analyzes and documents inter-working between WiFi 324 access authentication and PMIPv6 mobility management to enable 325 trusted access to a mobile operator network which uses network-based 326 mobility management. The document refers to standard operation of 327 PMIPv6 [RFC5213] as well as well accepted WiFi authentication 328 mechanisms, such as EAP using a RADIUS server as authentication 329 server, without introducing new messages or message sequences. 330 Solely the inter-working of access authentication and PMIPv6 is 331 described by means of message sequence charts. Furthermore, the use 332 of identifiers, which are built during access authentication, for MN 333 identification in the PMIPv6-based mobility management protocol is 334 described. Hence, the documented inter-working should not introduce 335 any new security threats. 337 6. IANA Considerations 339 This document is based on standardized protocols for WiFi access 340 authentication and network-based mobility management. No additional 341 protocol messages and options are specified so far in this document. 343 7. Normative References 345 [3GPP-TS23.402] 346 "3GPP TS 23.402; 3rd Generation Partnership Project; 347 Technical Specification Group Services and System Aspects; 348 Architecture enhancements for non-3GPP accesses (Release 349 10)", . 351 [3GPP-TS33.402] 352 "3GPP TS 33.402; 3rd Generation Partnership Project; 353 Technical Specification Group Services and System Aspects; 354 3GPP System Architecture Evolution (SAE); Security aspects 355 of non-3GPP accesses (Release 9)", . 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 361 Dial In User Service) Support For Extensible 362 Authentication Protocol (EAP)", RFC 3579, September 2003. 364 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 365 Levkowetz, "Extensible Authentication Protocol (EAP)", 366 RFC 3748, June 2004. 368 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 369 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 371 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 372 Extensible Authentication Protocol Method for 3rd 373 Generation Authentication and Key Agreement (EAP-AKA')", 374 RFC 5448, May 2009. 376 Authors' Addresses 378 Sri Gundavelli 379 Cisco 380 170 West Tasman Drive 381 San Jose, CA 95134, 382 USA 384 Email: sgundave@cisco.com 386 Marco Liebsch 387 NEC Laboratories Europe 388 Kurfuersten-Anlage 36 389 D-69115 Heidelberg, 390 Germany 392 Email: liebsch@neclab.eu 394 Pierrick Seite 395 France Telecom - Orange 396 4, rue du clos courtel BP 91226 397 Cesson-Sevigne, 35512 398 France 400 Email: pierrick.seite@orange-ftgroup.com