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