Network Working Group M. Kelkar Internet Draft Juniper Networks Intended status: Standards Track March 1, 2007 Expires: September 2007 L2TP Proxy Authenticate Extensions for EAP draft-ietf-l2tpext-proxy-authen-ext-eap-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Please send comments to the Layer Two Tunneling Protocol Extensions (l2tpext) working group at l2tpext@ietf.org. Abstract L2TP [1] and [6] defines Proxy Authentication AVPs that MAY be exchanged during session establishment, to provide forwarding of PPP authentication information obtained at the LAC to the LNS for validation. This document defines contents of this PPP authenticate information for the Extensible Authentication Protocol (EAP). Kelkar Expires September 1, 2007 [Page 1] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 Conventions used in this document AAA Authentication, Authorization, and Accounting. AAA protocols with EAP support include RADIUS [2] and Diameter. In this document, the terms "AAA server" and "backend authentication server" are used interchangeably. Authenticator The end of the link initiating EAP authentication. In L2TP, both the LAC and LNS can act as an authenticator. Backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. Peer The end of the link that responds to the authenticator. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [5]. Table of Contents 1. Introduction...................................................3 2. Applicability..................................................3 3. Proxy Authen AVPs..............................................4 4. Possible Configurations for Tunneling EAP......................5 4.1. Scenario I................................................6 4.2. Scenario II...............................................7 4.3. Scenario III..............................................7 4.4. Scenario IV...............................................8 Kelkar Expires September 1, 2007 [Page 2] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 5. IANA Considerations............................................9 6. Security Considerations........................................9 7. Intellectual Property Statement................................9 8. Copyright Statement...........................................10 9. Acknowledgments...............................................10 10. References...................................................11 10.1. Normative References....................................11 10.2. Informative References..................................11 Author's Address.................................................11 1. Introduction The LAC answers the incoming call and negotiates LCP and authentication with the peer in order to determine the destination LNS. The LAC MAY include Proxy LCP and Proxy Authentication AVPs in the tunneling data passed to the LNS. It contains the link properties the peer initially requested, properties the peer and LAC ultimately negotiated, and PPP authentication information sent and received by the LAC. This information may be used to initiate the PPP LCP and authentication systems on the LNS, allowing PPP to continue without renegotiation of LCP and re-exchange of authenticate parameters. Note that the LNS policy may be to enter an additional round of LCP negotiation and/or authentication if the LAC is not trusted. 2. Applicability EAP defined in [3] is a request-response protocol. After an initial identity exchange, EAP authentication method is negotiated between EAP-server and the peer. Currently, if EAP is configured as an authentication option on the LAC, then LAC is forced to negotiate the complete EAP authentication protocol with the peer, and then tunnel the session to LNS. Normally, LAC chooses a less strenuous authentication option, such as PAP or CHAP and lets LNS negotiate the EAP. However, such a mechanism forces a renegotiation of the LCP on the LNS and causes inefficiency. Following mechanism allows LNS to take off the EAP negotiation where LAC left it off. AAA on the LAC SHOULD be configured to tunnel the user just by looking at the Type-Data in the EAP identity response i.e. forced or compulsory tunneling. The LAC SHOULD obtain the EAP Identity from the peer, forward it to the LNS in the form of Proxy Authentication AVPs, and MUST let the EAP-server on LNS negotiate the EAP authentication method with the peer. Possible configurations are discussed in section 4. Kelkar Expires September 1, 2007 [Page 3] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 Proxy Authentication AVPs would be comprised of: o Proxy Authen Type - New authentication type defined for EAP o Proxy Authen Name - Type-Data obtained from the EAP identity response packet o Proxy Authen Id - Identifier value of the last received EAP Identity response on LAC If peer obtains the identity via user input, then we avoid an extra user interaction by passing the identity in the Proxy Authen AVPs to the LNS. On LNS, EAP identity response is reconstructed from the Proxy Authen AVPs and is forwarded to the AAA. EAP-server will respond to it with an EAP request for the configured authentication method. 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. 3. Proxy Authen AVPs With the inclusion of Proxy Authen Type EAP, definitions are updated as follows: Proxy Authen Type (ICCN) The Proxy Authen Type AVP, Attribute Type 29, determines if proxy authentication should be used. New Authen Type values are: 7 - Extensible Authentication Protocol (EAP) This AVP MUST be present if proxy authentication is to be utilized. If it is not present, then it is assumed that this peer cannot perform proxy authentication, requiring a restart of the authentication phase at the LNS, if the client has already entered this phase with the LAC (which may be determined by the Proxy LCP AVP if present). Proxy Authen Name (ICCN) The Proxy Authen Name AVP, Attribute Type 30, specifies the name of the authenticating client when using proxy authentication. Kelkar Expires September 1, 2007 [Page 4] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 This AVP MUST be present in messages containing a Proxy Authen Type 7. The Authen Name field contains the Type-Data value of the EAP Identity response packet. It may be desirable to employ AVP hiding for obscuring the cleartext name. Proxy Authen ID (ICCN) The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value of the PPP Authentication that was started between the LAC and the PPP Peer, when proxy authentication is being used. The Proxy Authen ID AVP MUST be present for Proxy Authen Type 7. For Proxy Authen Type 7, it is the Identifier value of the last received EAP Identity response. 4. Possible Configurations for Tunneling EAP This section outlines the various configuration scenarios in which EAP would be negotiated in the L2TP setup. Scenario I, II and III are recommended. Scenario IV is not recommended due to the complex requirements, various limitations and interoperability problems. Kelkar Expires September 1, 2007 [Page 5] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 4.1. Scenario I +-----------+ +-----------+ +-----------+ | | | | | | | Peer | | LAC | | LNS | | | | | | | +-----------+ +-----------+ +-----------+ : : : : LCP : : :<================>: : :EAP ID req (id=15): : :<-----------------: : :EAP ID resp(id=15): : :----------------->: : : : L2TP Tunnel : : :<===============>: : EAP ID req (id=101) : :<-----------------+-----------------: : EAP ID resp (id=101) : :-----------------+----------------->: : EAP negotiation : :<==================================>: : : : LAC sends an EAP Identity request with a random identifier (say id=15) and the peer responds with an EAP Identity response. LAC tunnels the session to LNS. LNS accepts the proxy LCP, discards the proxy authenticate, and starts the EAP negotiation by sending the EAP Identity request with a random identifier (say id=101). As per the peer state machine in section 4 of Ref [4], the peer will respond back with a EAP Identity response whether the identifier matches with the Identifier of the earlier identity request or not. This scenario MUST be supported. It allows LNS to start a new EAP negotiation with the peer. Kelkar Expires September 1, 2007 [Page 6] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 4.2. Scenario II +-----------+ +-----------+ +-----------+ | | | | | | | Peer | | LAC | | LNS | | | | | | | +-----------+ +-----------+ +-----------+ : : : : LCP : : :<================>: : : EAP ID req : : :<-----------------: : : EAP ID resp : : :----------------->: : : : L2TP Tunnel : : :<===============>: : EAP negotiation : :<==================================>: : : : LAC sends an EAP Identity request with a random identifier and the peer responds back with an EAP Identity response. LAC tunnels the session to LNS. LNS accepts the proxy LCP and proxy authenticate, and sends the reconstructed EAP Identity response to the EAP server. EAP server at LNS continues the EAP conversation with the peer. This scenario MUST be supported. It allows LNS to pick up the EAP negotiation, where LAC left it off. 4.3. Scenario III +-----------+ +-----------+ +-----------+ | | | | | | | Peer | | LAC | | LNS | | | | | | | +-----------+ +-----------+ +-----------+ : : : : LCP : : :<================>: : : : L2TP Tunnel : : :<===============>: : EAP negotiation : :<==================================>: LAC bypasses the initial identity exchange and obtains the identity by another manner such as port id, calling station identity, MAC address, etc. LAC tunnels the session to LNS. In this scenario, LNS should accept the proxy authenticate or should be able to obtain the Identity by other means such as via L2TP AVPs. LNS sends the reconstructed EAP Identity response to the EAP server and EAP server Kelkar Expires September 1, 2007 [Page 7] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 initiates the EAP conversation with the peer by sending EAP Identity Request or initial EAP request with an authentication method. This scenario MUST be supported. 4.4. Scenario IV +--------+ +--------+ | EAP | | EAP | | Server | | Server | +--------+ +--------+ | | +-----------+ +-----------+ +-----------+ | | | | | | | Peer | | LAC | | LNS | | | | | | | +-----------+ +-----------+ +-----------+ : : : : LCP : : :<================>: : : EAP : : :<================>: : : (EAP Success) : : :<-----------------: : : : L2TP Tunnel : : :<===============>: : EAP negotiation : :<==================================>: : : : LAC negotiates EAP with the peer. At the end of negotiation, LAC sends EAP success to the peer and tunnels the session to LNS. If LNS accepts the proxy authenticate, then it can start the EAP negotiation with the peer without the EAP Identity exchange. However, if LNS does not accept the proxy authenticate, then it will have to start the EAP negotiation with the EAP Identity exchange. As per the peer state machine in section 4 of Ref [4], if the peer receives an EAP success packet from the LAC followed by an EAP Identity request packet from the LNS, then the peer discards the EAP Identity request and thus resulting in termination. Hence, LNS MUST accept the proxy authenticate data forwarded by the LAC in order to avoid the EAP Identity exchange. If LNS accepts the proxy authenticate data, then the peer will receive an EAP success packet from the LAC followed by an EAP request with the authentication method from the EAP server at LNS. The peer will treat it as a re- authentication because renegotiation is taking place within the same EAP conversation. The EAP conversation is defined as EAP packets exchanged between the EAP server and the peer, while lower layer Kelkar Expires September 1, 2007 [Page 8] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 remains open. Since the Ref [3] does not allow negotiation of multiple authentication methods within the same EAP conversation, the EAP server at LNS MUST use the same authentication method for renegotiation. However, LNS cannot suggest or hint its EAP server with a particular authentication method unless EAP server resides on the LNS, hence the EAP server at the LNS MUST be explicitly configured to negotiate the same EAP authentication method as the one negotiated by the EAP server at the LAC. Also, EAP authentication method MUST allow the re-authentication in order to support the above-mentioned behavior. Thus, this scenario conflicts with the flexibility of the EAP framework that allows seamless negotiation of any EAP authentication method. Alternatively, vendor specific EAP authentication method or EAP authentication methods that allow multiple EAP conversation could be used. This scenario is not recommended and SHOULD not be supported. 5. IANA Considerations The Proxy Authen Type AVP (Attribute Type 29) has an associated value maintained by IANA. Values 0-5 are defined in Section 4.4.5 of [1] and section 5.1.3 of [6]; the remaining values are available for assignment via First Come First Served [7]. A new Proxy Authen Type is defined in Section 2. It is summarized as follows: Proxy Authen Type AVP (Attribute Type 29) Values ------------------------------------------------- Authen Type values 7 - Extended Authentication Protocol (EAP) 6. Security Considerations If the AVPs described in this document are of concern then AVP hiding, described in [1] MAY be used to help mitigate the security threat; though it is not widely regarded as cryptographically secure, [8] describes a more robust method for securing L2TP in general, and should be used to encrypt all L2TP messages. 7. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to Kelkar Expires September 1, 2007 [Page 9] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 8. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9. Acknowledgments The author gratefully acknowledges the valuable contributions of Paul Howard. Kelkar Expires September 1, 2007 [Page 10] Internet-Draft L2TP Proxy Authen Extensions For EAP March 2007 10. References 10.1. Normative References [1] RFC 2661, W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", August 1999. [2] RFC 3579, B. Aboba, P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", September 2003. [3] RFC 3748, B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, Ed. H. Levkowetz, "Extensible Authentication Protocol (EAP)", June 2004. [4] RFC 4137, J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", August 2005 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] C. Pignataro, Ed, "PPP Tunneling Using Layer Two Tunneling Protocol Version 3" work in progress, draft-ietf-l2tpext-l2tp- ppp-05.txt, November 2006. 10.2. Informative References [7] RFC 2434, Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434bcp26, October 1998. [8] RFC 3193, B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing L2TP using IPsec", November 2001 Author's Address Mahesh Kelkar Juniper Networks 10 Technology Park Drive Westford, MA 01886 Phone: +1 978 589 0535 Email: mkelkar@juniper.net Kelkar Expires September 1, 2007 [Page 11]