idnits 2.17.1 draft-perkins-netext-eapbu-01.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 26, 2011) is 4559 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EAPAD' is mentioned on line 177, but not defined == Missing Reference: 'BAckAD' is mentioned on line 194, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM extensions [netext] C. Perkins 3 Internet-Draft Tellabs 4 Intended status: Informational B. Patil 5 Expires: April 28, 2012 Nokia 6 Oct 26, 2011 8 Optimizing IP Mobility Authentication with EAP 9 draft-perkins-netext-eapbu-01.txt 11 Abstract 13 The Extensible Authentication Protocol (EAP) is commonly used for 14 access authentication in many wireless networks. EAP methods often 15 involve AAA servers to effect the required authentications; 16 notifications about success or failure are then relayed back to a 17 functional module in the access network known as the Network Access 18 Server. The Binding Authentication Data option has been defined for 19 enabling alternative methods for authentication in the context of 20 Mobile IPv6, and there is a subtype allocated for AAA-based 21 authentication methods such as EAP. However, some EAP methods 22 require additional handling that requires specification not yet 23 available in the existing documentation for the Binding 24 Authentication Data option. This document provides the required 25 specification for at least some very widely deployed EAP methods. In 26 many situations requiring the use of EAP, this enables much faster 27 operation for Mobile IPv6 tunnel redirection to a wireless device's 28 new care-of address by avoiding having to do multiple 29 authentications. 31 Status of This Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 28, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. EAP subtype for Binding Authentication Data . . . . . . . . . . 5 69 5. Binding Acknowledgement Authentication Data option . . . . . . 5 70 6. Example of use with EAP-AKA . . . . . . . . . . . . . . . . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 75 9.2. Informational References . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The Extensible Authentication Protocol (EAP) [RFC3748] is commonly 80 used for access authentication in many wireless networks. EAP 81 methods often involve AAA servers to effect the required 82 authentications; notifications are then relayed back to a functional 83 module in the access network known as the Network Access Server. For 84 Mobile IPv6 [RFC6275], the Binding Authentication Data option 85 [RFC4285] has been defined for enabling alternative methods for 86 authentication, and a subtype has been allocated for AAA-based 87 authentication methods such as EAP. However, some EAP methods 88 require additional handling that requires specification not yet 89 available in the existing documentation for the Binding 90 Authentication Data option. This document provides the required 91 specification for at least some very widely deployed EAP methods. In 92 many situations requiring the use of EAP, this enables much faster 93 operation for Mobile IPv6 tunnel redirection to a wireless device's 94 new care-of address. 96 2. Problem Statement 98 Mobile IPv6 [RFC6275] requires the mobile node (MN) to authenticate 99 with its assigned home agent. Establishing an IPsec SA is 100 accomplished after the MN has been authenticated. EAP methods may be 101 used within IKEv2 to authenticate the MN and then establish the MN's 102 IPsec security association (SA). The authentication and 103 establishment of the IPsec SA is required in addition to access 104 network authentication. Most networks require a user/device to 105 authenticate prior to be being connected to the network. This 106 results in the MN having to perform two authentications. The MN has 107 to first perform access authentication and then authenticate again 108 for a second time with the home agent to establish the IPsec SA. 109 This causes significant delay in the MN being registered with the HA. 110 It should be noted that when the MN moves to a different access 111 network, access network authentication is typically performed. 112 However, when the IPsec SA already exists, that SA only needs to be 113 updated with the changed end-point. This can be achieved by setting 114 the 'K' bit in the binding update sent from the new care-of-address. 116 In the case of network based mobility, i.e Proxy Mobile IPv6 117 [RFC5213] the Mobility Access Gateway (MAG) performs registration 118 with the Local Mobility Agent (LMA) following access authentication. 119 The MAG receives confirmation from a AAA server if the MN is 120 authorized for mobility service and only after that does it send the 121 proxy binding update to the LMA. 123 Combining access authentication with mobility authentication results 124 in an optimization and faster connectivity. How to optimize or 125 combine the access authentication with the authentication required 126 for obtaining mobility service is the problem dealt with in this 127 document. 129 3. Proposed Solution 131 The proposal contained in this I-D is to combine access 132 authentication with Mobile IPv6 authentication. As a result it saves 133 at least one authentication sequence and hence speeds up the process 134 of sending and receiving packets via the home agent or LMA. 136 EAP is commonly used for access authentication. Many of the EAP 137 authentication methods interact with a AAA server which contain the 138 credentials of the user. The NAS element in an access network is 139 essentially a AAA relay entity. The proposal contained in this 140 document aims to utilize the information available to the NAS from 141 the access authentication phase to perform Mobile IP authentication 142 as well. The extensions needed to EAP and the Mobile IP signaling 143 are described in the following sections. 145 The basic idea is to route the access authentication signaling 146 messages via the HA/LMA and thereby perform authentication and 147 registration in a single transaction. The HA acts as a relay entity 148 in the access authentication procedure and is aware of the result of 149 the authentication procedure and can act on it by updating the 150 binding cache. 152 3.1. Example 154 The figure below shows an example of the solution which combines 155 access authentication with mobility registration. In the figure the 156 MN is presumed to already have a binding at the HA. Additionally the 157 same scenario can be considered applicable to the network based 158 mobility solution in which case the MAG routes the access 159 authentication messages via the LMA. 161 MN NAS HA AAA 162 | | | | 163 |<--Attach=-------->| | | 164 | | | | 165 |<---Access Authentication routed via the HA-------->| 166 | | | | 167 | | |<-Auth Resp---| 168 |<------------------------------------| | 169 | | |HA Updates | 170 | | |Binding cache | 171 | | | | 172 Figure 1: Example of combined authentication and registration 174 4. EAP subtype for Binding Authentication Data 176 This specification defines a new subtype, called the EAP 177 Authentication Data [EAPAD] subtype, for the Binding Authentication 178 Data suboption for Mobile IPv6. The EAPAD subtype has the following 179 format, which is identical to the EAP message format: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Code | Identifier | Length | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Type-Data ... 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 189 Please consult the EAP specification [RFC3748] for details about 190 these header fields. 192 5. Binding Acknowledgement Authentication Data option 194 The Binding Acknowledgement Authentication Data option [BAckAD] is 195 specified to enable the EAP method to return data from the AAA server 196 back to the Authenticator and the Peer as may be required by the EAP 197 method specification. The nature of the data returned in the BAckAD 198 depends on the method. The EAP message is of type EAP Success or EAP 199 Failure. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Option Type | Option Length | Subtype | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Code | Identifier | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type | Type-Data ... 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 211 The Subtype for the Binding Acknowledgement Authentication Data 212 option is 0, for EAP methods. There is no need for the SPI field. 213 The Type-Data is the EAP method-specific data. Since this option 214 appears in the Binding Acknowledgement (or Proxy Binding 215 Acknowledgement) message, the Code will either correspond to EAP- 216 Success or EAP-Failure. 218 6. Example of use with EAP-AKA 220 The following figure shows how to use the new Binding Authentication 221 Data subtype along with the new Binding Acknowledgement 222 Authentication Data subtype with EAP-AKA [RFC4187]. A very similar 223 procedure will also work for EAP-AKA' [RFC5448]. 225 Peer Authenticator LMA AAA Server 226 | | | | 227 | EAP-Request/Identity | | | 228 |<---------------------------| | | 229 | | | | 230 | EAP-Response/Identity | | | 231 | (Includes user''s NAI) | | | 232 |--------------------------->+------------------------->| 233 | | | +-----------+ 234 | | | | Process A | 235 | | | +-----------+ 236 | EAP-Request/AKA-Challenge | | | 237 | (AT_RAND, AT_AUTN, AT_MAC) | | | 238 |<---------------------------+<-------------------------| 239 +-----------+ | | | 240 | Process B | | | | 241 +-----------+ | | | 242 | EAP-Response/AKA-Challenge | PBU | EAP | 243 | (AT_RES, AT_MAC) |(EAP-Response) | Response | 244 |--------------------------->+-------------->+--------->| 245 | | | +-----------+ 246 | | | | Process C | 247 | | PBAck | EAP +-----------+ 248 | | (EAP-Success)| Success | 249 |<---------------------------+<--------------+<---------| 251 Figure 2: Use of EAPAD and BAckAD in EAP-AKA Authentication 253 where: 255 Process A 257 means "Server runs AKA algorithms, generates RAND and AUTN." 259 Process B 261 means "Peer runs AKA algorithms, verifies AUTN and MAC, derives 262 RES and session key" 264 Process C 266 means "Server checks the given RES, and MAC and finds them 267 correct." 269 7. Security Considerations 271 This document introduces a new subtype for the Binding Authentication 272 Data of Mobile IPv6. The security characteristics for the 273 authentication data are exactly those of the base EAP method which 274 defines the data fields and security parameters for the new subtype. 276 This document specifies the Binding Acknowledgement Data option, 277 which is a new option for the Binding Acknowledgement message of 278 Mobile IPv6. The security characteristics for the new option are 279 exactly those of the base EAP method which defines the data fields 280 and security parameters for the new option. The Mobile-Home 281 Authentication extension is still also required for the Binding 282 Acknowledgement, but additional security features and notifications 283 may be included in the EAP method data defining the contents of the 284 new option. PMIP uses the same message format for BAck, and the new 285 option works in the same way whether or not the 'P' bit is set. 287 8. IANA Considerations 289 This document requires allocation of a new subtype for the Binding 290 Authentication Option of Mobile IPv6. 292 This document specifies the Binding Acknowledgement Data option, 293 which is a new option for the Binding Acknowledgement message of 294 Mobile IPv6. 296 9. References 298 9.1. Normative References 300 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 301 Levkowetz, "Extensible Authentication Protocol (EAP)", 302 RFC 3748, June 2004. 304 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 305 Chowdhury, "Authentication Protocol for Mobile IPv6", 306 RFC 4285, January 2006. 308 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 309 in IPv6", RFC 6275, July 2011. 311 9.2. Informational References 313 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 314 Protocol Method for 3rd Generation Authentication and Key 315 Agreement (EAP-AKA)", RFC 4187, January 2006. 317 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 318 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 320 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 321 Extensible Authentication Protocol Method for 3rd 322 Generation Authentication and Key Agreement (EAP-AKA')", 323 RFC 5448, May 2009. 325 Authors' Addresses 327 Charles E. Perkins 328 Tellabs 330 Phone: +1-408-970-6560 331 EMail: charliep@tellabs.com 333 Basavaraj Patil 334 Nokia 335 6021 Connection Drive 336 Irving, TX 75039 337 USA 339 EMail: basavaraj.patil@nokia.com