[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kelkar-l2tpext-eap-proxy-authen-ext) 00 01 02

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/