idnits 2.17.1 draft-kelkar-l2tpext-eap-proxy-authen-ext-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 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: It is recommended that AAA on the LAC SHOULD not be configured to negotiate EAP with the peer; its limitations are discussed in the scenario IV in section 4.4. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: This scenario is not recommended and SHOULD not be supported. -- 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 (November 21, 2005) is 6731 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: 'DIAM-EAP' on line 47 -- Looks like a reference, but probably isn't: 'RFC1661' on line 229 == Unused Reference: '5' is defined on line 437, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3579 (ref. '2') ** Downref: Normative reference to an Informational draft: draft-ietf-eap-statemachine (ref. '4') Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Kelkar 2 Internet Draft Juniper Networks 3 Expires: May 2006 November 21, 2005 5 L2tp Proxy Authenticate Extensions for EAP 6 draft-kelkar-l2tpext-eap-proxy-authen-ext-01.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Distribution of this document is unlimited. Please send comments to 32 the Layer Two Tunneling Protocol Extensions (l2tpext) working group 33 at l2tpext@ietf.org. 35 Abstract 37 L2TP [1] defines Proxy Authentication AVPs that MAY be exchanged 38 during session establishment, to provide forwarding of PPP 39 authentication information obtained at the LAC to the LNS for 40 validation. This document defines contents of this PPP authenticate 41 information for the Extensible Authentication Protocol (EAP). 43 Conventions used in this document 45 AAA 46 Authentication, Authorization, and Accounting. AAA protocols with 47 EAP support include RADIUS [2] and Diameter [DIAM-EAP]. In this 48 document, the terms "AAA server" and "backend authentication 49 server" are used interchangeably. 51 Authenticator 53 The end of the link initiating EAP authentication. In L2TP, both 54 the LAC and LNS can act as an authenticator. 56 Backend authentication server 58 A backend authentication server is an entity that provides an 59 authentication service to an authenticator. When used, this server 60 typically executes EAP methods for the authenticator. 62 EAP server 64 The entity that terminates the EAP authentication method with the 65 peer. In the case where no backend authentication server is used, 66 the EAP server is part of the authenticator. In the case where the 67 authenticator operates in pass-through mode, the EAP server is 68 located on the backend authentication server. 70 Peer 72 The end of the link that responds to the authenticator. 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC-2119. 78 Table of Contents 80 1. Introduction...................................................3 81 2. Applicability..................................................3 82 3. Proxy Authen AVPs..............................................4 83 4. Possible Configurations for Tunneling EAP......................5 84 4.1. Scenario I................................................5 85 4.2. Scenario II...............................................6 86 4.3. Scenario III..............................................7 87 4.4. Scenario IV...............................................8 88 5. IANA Considerations............................................9 89 6. Security Considerations........................................9 90 7. Intellectual Property Statement................................9 91 8. Copyright Statement...........................................10 92 9. Acknowledgments...............................................10 93 10. References...................................................11 94 10.1. Normative References....................................11 95 10.2. Informative References..................................11 96 Author's Address.................................................11 98 1. Introduction 100 The LAC answers the incoming call and negotiates LCP and 101 authentication with the peer in order to determine the destination 102 LNS. The LAC MAY include Proxy LCP and Proxy Authentication AVPs in 103 the tunneling data passed to the LNS. It contains the link properties 104 the peer initially requested, properties the peer and LAC ultimately 105 negotiated, and PPP authentication information sent and received by 106 the LAC. This information may be used to initiate the PPP LCP and 107 authentication systems on the LNS, allowing PPP to continue without 108 renegotiation of LCP and re-exchange of authenticate parameters. 109 Note that the LNS policy may be to enter an additional round of LCP 110 negotiation and/or authentication if the LAC is not trusted. 112 2. Applicability 114 EAP defined in [3] is a request-response protocol. After an initial 115 identity exchange, EAP authentication method is negotiated between 116 EAP-server and the peer. 118 Currently, if EAP is configured as an authentication option on the 119 LAC, then LAC is forced to negotiate the complete EAP authentication 120 protocol with the peer, and then tunnel the session to LNS. 121 Normally, LAC chooses a less strenuous authentication option, such as 122 PAP or CHAP and lets LNS negotiate the EAP. However, such a 123 mechanism forces a renegotiation of the LCP on the LNS and causes 124 inefficiency. Following mechanism allows LNS to take off the EAP 125 negotiation where LAC left it off. 127 AAA on the LAC SHOULD be configured to tunnel the user just by 128 looking at the Type-Data in the EAP identity response i.e. forced or 129 compulsory tunneling. The LAC SHOULD obtain the EAP Identity from 130 the peer, forward it to the LNS in the form of Proxy Authentication 131 AVPs, and MUST let the EAP-server on LNS negotiate the EAP 132 authentication method with the peer. Possible configurations are 133 discussed in section 4. 135 Proxy Authentication AVPs would be comprised of: 137 o Proxy Authen Type - New authentication type defined for EAP 138 o Proxy Authen Name - Type-Data obtained from the EAP identity 139 response packet 141 o Proxy Authen Id - Identifier value of the last received EAP 142 Identity response on LAC 144 If peer obtains the identity via user input, then we avoid an extra 145 user interaction by passing the identity in the Proxy Authen AVPs to 146 the LNS. 148 On LNS, EAP identity response is reconstructed from the Proxy Authen 149 AVPs and is forwarded to the AAA. EAP-server will respond to it with 150 an EAP request for the configured authentication method. 152 It is recommended that AAA on the LAC SHOULD not be configured to 153 negotiate EAP with the peer; its limitations are discussed in the 154 scenario IV in section 4.4. 156 3. Proxy Authen AVPs 158 With the inclusion of Proxy Authen Type EAP, definitions are updated 159 as follows: 161 Proxy Authen Type (ICCN) 163 The Proxy Authen Type AVP, Attribute Type 29, determines if proxy 164 authentication should be used. 166 New Authen Type values are: 168 TBD - Extensible Authentication Protocol (EAP) 170 This AVP MUST be present if proxy authentication is to be utilized. 171 If it is not present, then it is assumed that this peer cannot 172 perform proxy authentication, requiring a restart of the 173 authentication phase at the LNS, if the client has already entered 174 this phase with the LAC (which may be determined by the Proxy LCP 175 AVP if present). 177 Proxy Authen Name (ICCN) 179 The Proxy Authen Name AVP, Attribute Type 30, specifies the name of 180 the authenticating client when using proxy authentication. 182 This AVP MUST be present in messages containing a Proxy Authen Type 183 AVP TBD. For TBD, it is the Type-Data value of the EAP Identity 184 response packet. It may be desirable to employ AVP hiding for 185 obscuring the cleartext name. 187 Proxy Authen ID (ICCN) 189 The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value 190 of the PPP Authentication that was started between the LAC and the 191 PPP Peer, when proxy authentication is being used. 193 The Proxy Authen ID AVP MUST be present for Proxy Authen Type TBD. 194 For TBD, it is the Identifier value of the last received EAP 195 Identity response. 197 4. Possible Configurations for Tunneling EAP 199 This section outlines the various configuration scenarios in which 200 EAP would be negotiated in the L2TP setup. Scenario I, II and III 201 are recommended. Scenario IV is not recommended due to the complex 202 requirements, various limitations and interoperability problems. 204 4.1. Scenario I 206 +-----------+ +-----------+ +-----------+ 207 | | | | | | 208 | Peer | | LAC | | LNS | 209 | | | | | | 210 +-----------+ +-----------+ +-----------+ 211 : : : 212 : LCP : : 213 :<================>: : 214 :EAP ID req (id=15): : 215 :<-----------------: : 216 :EAP ID resp(id=15): : 217 :----------------->: : 218 : : L2TP Tunnel : 219 : :<===============>: 220 : EAP ID req (id=101) : 221 :<-----------------+-----------------: 222 : EAP ID resp (id=101) : 223 :-----------------+----------------->: 224 : EAP negotiation : 225 :<==================================>: 226 : : : 228 LAC sends an EAP Identity request with a random identifier (say 229 id=15) as recommended by [RFC1661] and the peer responds with an EAP 230 Identity response. LAC tunnels the session to LNS. LNS accepts the 231 proxy LCP, discards the proxy authenticate, and starts the EAP 232 negotiation by sending the EAP Identity request with a random 233 identifier (say id=101). As per the peer state machine in section 4 234 of Ref [4], the peer will respond back with a EAP Identity response 235 whether the identifier matches with the Identifier of the earlier 236 identity request or not. This scenario MUST be supported. It allows 237 LNS to start a new EAP negotiation with the peer. 239 4.2. Scenario II 241 +-----------+ +-----------+ +-----------+ 242 | | | | | | 243 | Peer | | LAC | | LNS | 244 | | | | | | 245 +-----------+ +-----------+ +-----------+ 246 : : : 247 : LCP : : 248 :<================>: : 249 : EAP ID req : : 250 :<-----------------: : 251 : EAP ID resp : : 252 :----------------->: : 253 : : L2TP Tunnel : 254 : :<===============>: 255 : EAP negotiation : 256 :<==================================>: 257 : : : 258 LAC sends an EAP Identity request with a random identifier and the 259 peer responds back with an EAP Identity response. LAC tunnels the 260 session to LNS. LNS accepts the proxy LCP and proxy authenticate, 261 and sends the reconstructed EAP Identity response to the EAP server. 262 EAP server at LNS continues the EAP conversation with the peer. This 263 scenario MUST be supported. It allows LNS to pick up the EAP 264 negotiation, where LAC left it off. 266 4.3. Scenario III 268 +-----------+ +-----------+ +-----------+ 269 | | | | | | 270 | Peer | | LAC | | LNS | 271 | | | | | | 272 +-----------+ +-----------+ +-----------+ 273 : : : 274 : LCP : : 275 :<================>: : 276 : : L2TP Tunnel : 277 : :<===============>: 278 : EAP negotiation : 279 :<==================================>: 280 LAC bypasses the initial identity exchange and obtains the identity 281 by another manner such as port id, calling station identity, MAC 282 address, etc. LAC tunnels the session to LNS. In this scenario, LNS 283 should accept the proxy authenticate or should be able to obtain the 284 Identity by other means such as via L2TP AVPs. LNS sends the 285 reconstructed EAP Identity response to the EAP server and EAP server 286 initiates the EAP conversation with the peer by sending EAP Identity 287 Request or initial EAP request with an authentication method. This 288 scenario MUST be supported. 290 4.4. Scenario IV 292 +--------+ +--------+ 293 | EAP | | EAP | 294 | Server | | Server | 295 +--------+ +--------+ 296 | | 297 +-----------+ +-----------+ +-----------+ 298 | | | | | | 299 | Peer | | LAC | | LNS | 300 | | | | | | 301 +-----------+ +-----------+ +-----------+ 302 : : : 303 : LCP : : 304 :<================>: : 305 : EAP : : 306 :<================>: : 307 : (EAP Success) : : 308 :<-----------------: : 309 : : L2TP Tunnel : 310 : :<===============>: 311 : EAP negotiation : 312 :<==================================>: 313 : : : 314 LAC negotiates EAP with the peer. At the end of negotiation, LAC 315 sends EAP success to the peer and tunnels the session to LNS. If LNS 316 accepts the proxy authenticate, then it can start the EAP negotiation 317 with the peer without the EAP Identity exchange. However, if LNS 318 does not accept the proxy authenticate, then it will have to start 319 the EAP negotiation with the EAP Identity exchange. 321 As per the peer state machine in section 4 of Ref [4], if the peer 322 receives an EAP success packet from the LAC followed by an EAP 323 Identity request packet from the LNS, then the peer discards the EAP 324 Identity request and thus resulting in termination. Hence, LNS MUST 325 accept the proxy authenticate data forwarded by the LAC in order to 326 avoid the EAP Identity exchange. If LNS accepts the proxy 327 authenticate data, then the peer will receive an EAP success packet 328 from the LAC followed by an EAP request with the authentication 329 method from the EAP server at LNS. The peer will treat it as a re- 330 authentication because renegotiation is taking place within the same 331 EAP conversation. The EAP conversation is defined as EAP packets 332 exchanged between the EAP server and the peer, while lower layer 333 remains open. Since the Ref [3] does not allow negotiation of 334 multiple authentication methods within the same EAP conversation, the 335 EAP server at LNS MUST use the same authentication method for 336 renegotiation. However, LNS cannot suggest or hint its EAP server 337 with a particular authentication method unless EAP server resides on 338 the LNS, hence the EAP server at the LNS MUST be explicitly 339 configured to negotiate the same EAP authentication method as the one 340 negotiated by the EAP server at the LAC. Also, EAP authentication 341 method MUST allow the re-authentication in order to support the 342 above-mentioned behavior. Thus, this scenario conflicts with the 343 flexibility of the EAP framework that allows seamless negotiation of 344 any EAP authentication method. Alternatively, vendor specific EAP 345 authentication method or EAP authentication methods that allow 346 multiple EAP conversation could be used. 348 This scenario is not recommended and SHOULD not be supported. 350 5. IANA Considerations 352 The Proxy Authen Type AVP is already managed by IANA as per section 353 2.1 of [6]. A new Proxy Authen Type is defined in Section 2. It is 354 summarized as follows: 356 Proxy Authen Type AVP (Attribute Type 29) Values 357 ------------------------------------------------- 358 Authen Type values 360 TBD - Extended Authentication Protocol (EAP) 362 6. Security Considerations 364 If the AVPs described in this document are of concern then AVP 365 hiding, described in [1] MAY be used to help mitigate the security 366 threat; though it is not widely regarded as cryptographically secure, 367 [7] describes a more robust method for securing L2TP in general, and 368 should be used to encrypt all L2TP messages. 370 7. Intellectual Property Statement 372 The IETF takes no position regarding the validity or scope of any 373 Intellectual Property Rights or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; nor does it represent that it has 377 made any independent effort to identify any such rights. Information 378 on the procedures with respect to rights in RFC documents can be 379 found in BCP 78 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of an 383 attempt made to obtain a general license or permission for the use of 384 such proprietary rights by implementers or users of this 385 specification can be obtained from the IETF on-line IPR repository at 386 http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights that may cover technology that may be required to implement 391 this standard. Please address the information to the IETF at ietf- 392 ipr@ietf.org. 394 8. Copyright Statement 396 Copyright (C) The Internet Society (2005). 398 This document is subject to the rights, licenses and restrictions 399 contained in BCP 78, and except as set forth therein, the authors 400 retain all their rights. 402 This document and the information contained herein are provided on an 403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 405 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 406 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 407 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 410 9. Acknowledgments 412 The author gratefully acknowledges the valuable contributions of Paul 413 Howard. 415 10. References 417 10.1. Normative References 419 [1] RFC 2661, W. Townsley, A. Valencia, A. Rubens, G. Pall, G. 420 Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", August 1999. 422 [2] RFC 3579, B. Aboba, P. Calhoun, "RADIUS (Remote Authentication 423 Dial In User Service) Support For Extensible Authentication 424 Protocol (EAP)", RFC 3579, September 2003. 426 [3] RFC 3748, B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, Ed. H. 427 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 428 3748, June 2004. 430 [4] J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba, "State Machines 431 for Extensible Authentication Protocol (EAP) Peer and 432 Authenticator" work in progress, draft-ietf-eap-statemachine- 433 06.txt, December 2004 435 10.2. Informative References 437 [5] Extensible Authentication Protocol (EAP) IANA Registry, 438 http://www.iana.org/assignments/eap-numbers 440 [6] BCP0068, Townsley, W., "Layer Two Tunneling Protocol (L2TP) 441 Internet Assigned Numbers Authority (IANA) Considerations 442 Update" RFC3438, BCP0068, December 2002 444 [7] RFC 3193, B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, 445 "Securing L2TP using IPsec", November 2001 447 Author's Address 449 Mahesh Kelkar 450 Juniper Networks 451 10 Technology Park Drive 452 Westford, MA 01886 454 Phone: +1 978 589 0535 455 Email: mkelkar@juniper.net