Network Working Group M. Kelkar Internet Draft Juniper Networks Expires: January 2006 July 14, 2005 L2tp Proxy Authenticate Extensions for EAP draft-kelkar-l2tpext-eap-proxy-authen-ext-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may not be modified, and derivative works of it may not be created. This document may only be posted in an Internet-Draft. 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. Kelkar Expires January 14, 2006 [Page 1] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 This Internet-Draft will expire on December 14, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract L2TP [1] 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). Conventions used in this document AAA Authentication, Authorization, and Accounting. AAA protocols with EAP support include RADIUS [2] and Diameter [DIAM-EAP]. 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. Kelkar Expires January 14, 2006 [Page 2] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 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 RFC-2119. Table of Contents 1. Introduction...................................................3 2. Applicability..................................................3 3. Proxy Authen AVPs..............................................4 4. IANA Considerations............................................7 5. Security Considerations........................................7 6. Acknowledgments................................................7 APPENDIX A: Possible Configurations for Tunneling EAP.............8 A.1. Scenario I................................................8 A.2. Scenario II...............................................9 A.3. Scenario III..............................................9 A.4. Scenario IV..............................................10 7. References....................................................12 7.1. Normative References.....................................12 7.2. Informative References...................................12 Author's Addresses...............................................12 Intellectual Property Statement..................................12 Disclaimer of Validity...........................................13 Copyright Statement..............................................13 Acknowledgment...................................................13 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, to indicate 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. Kelkar Expires January 14, 2006 [Page 3] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 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 Appendix A. 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 of the Appendix A. 3. Proxy Authen AVPs With the inclusion of Proxy Authen Type EAP, definitions are updated as follows: Proxy Authen Type (ICCN) Kelkar Expires January 14, 2006 [Page 4] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 The Proxy Authen Type AVP, Attribute Type 29, determines if proxy authentication should be used. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authen Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authen Type is a 2 octet unsigned integer, holding: This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 8. Defined Authen Type values are: 0 - Reserved 1 - Textual username/password exchange 2 - PPP CHAP 3 - PPP PAP 4 - No Authentication 5 - Microsoft CHAP Version 1 (MSCHAPv1) TBD-2 - 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). Associated AVPs for each type of authentication follow. Proxy Authen Name (ICCN) The Proxy Authen Name AVP, Attribute Type 30, specifies the name of the authenticating client when using proxy authentication. The Attribute Value field for this AVP has the following format: Kelkar Expires January 14, 2006 [Page 5] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authen Name... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authen Name is a string of octets of arbitrary length. It contains the name specified in the client's authentication response. This AVP MUST be present in messages containing a Proxy Authen Type AVP with an Authen Type of 1, 2, 3, 5 or TBD-2. For TBD-2, it is the Type-Data value of the EAP Identity response packet. It may be desirable to employ AVP hiding for obscuring the cleartext name. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) is 6 plus the length of 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 Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID is a 2 octet unsigned integer, the most significant octet MUST be 0. The Proxy Authen ID AVP MUST be present for Proxy Authen Types 2, 3, 5 and TBD-2. For 2 and 5, the ID field contains the byte ID value presented to the client by the LAC in its Challenge. For 3, it is the Identifier value of the Authenticate-Request. For TBD-2, it is the Identifier value of the last received EAP Identity response. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. Kelkar Expires January 14, 2006 [Page 6] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 4. IANA Considerations The Proxy Authen Type AVP is already managed by IANA as per [RFC3438]. 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 TBD-2 - Extended Authentication Protocol (EAP) 5. 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. [RFC 3193] describes a more robust method for securing L2TP in general, and should be used to encrypt all L2TP messages. 6. Acknowledgments The author gratefully acknowledges the valuable contributions of Paul Howard. Kelkar Expires January 14, 2006 [Page 7] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 APPENDIX A: 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. A.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) as recommended by [RFC1661] 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 January 14, 2006 [Page 8] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 A.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. A.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 January 14, 2006 [Page 9] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 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. A.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 January 14, 2006 [Page 10] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 remains open. Since the ref [2] 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. Kelkar Expires January 14, 2006 [Page 11] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 7. References 7.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)", RFC 3579, September 2003. [3] RFC 3748, B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, Ed. H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [4] J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator" work in progress, draft-ietf-eap-statemachine- 06.txt, December 2004 7.2. Informative References [5] Extensible Authentication Protocol (EAP) IANA Registry, http://www.iana.org/assignments/eap-numbers Author's Address Mahesh Kelkar Juniper Networks 10 Technology Park Drive Westford, MA 01886 Phone: +1 978 589 0535 Email: mkelkar@juniper.net 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 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. Kelkar Expires January 14, 2006 [Page 12] Internet-Draft L2tp Proxy Authenticate Extensions For EAP July 2005 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. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kelkar Expires January 14, 2006 [Page 13]