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

Versions: 00 01 draft-ietf-l2tpext-proxy-authen-ext-eap

Network Working Group                                         M. Kelkar
Internet Draft                                         Juniper Networks
Expires: May 2006                                     November 21, 2005



                L2tp Proxy Authenticate Extensions for EAP
             draft-kelkar-l2tpext-eap-proxy-authen-ext-01.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] 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



Kelkar                   Expires May 21, 2006                  [Page 1]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 2005


     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.

   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. Possible Configurations for Tunneling EAP......................5
      4.1. Scenario I................................................5
      4.2. Scenario II...............................................6
      4.3. Scenario III..............................................7
      4.4. Scenario IV...............................................8
   5. IANA Considerations............................................9
   6. Security Considerations........................................9
   7. Intellectual Property Statement................................9
   8. Copyright Statement...........................................10


Kelkar                   Expires May 21, 2006                  [Page 2]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 2005


   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.

   Proxy Authentication AVPs would be comprised of:

   o  Proxy Authen Type - New authentication type defined for EAP



Kelkar                   Expires May 21, 2006                  [Page 3]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 2005


   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:

       TBD - 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.

     This AVP MUST be present in messages containing a Proxy Authen Type
     AVP TBD.  For TBD, it is the Type-Data value of the EAP Identity



Kelkar                   Expires May 21, 2006                  [Page 4]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 2005


     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 TBD.
     For TBD, 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.

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) as recommended by [RFC1661] and the peer responds with an EAP
   Identity response.  LAC tunnels the session to LNS.  LNS accepts the


Kelkar                   Expires May 21, 2006                  [Page 5]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 2005


   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.

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.















Kelkar                   Expires May 21, 2006                  [Page 6]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 2005


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
   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.


























Kelkar                   Expires May 21, 2006                  [Page 7]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 2005


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
   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


Kelkar                   Expires May 21, 2006                  [Page 8]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 2005


   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 is already managed by IANA as per section
   2.1 of [6].  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 - 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,
   [7] 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
   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 May 21, 2006                  [Page 9]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 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.

8. Copyright Statement

   Copyright (C) The Internet Society (2005).

   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 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 May 21, 2006                 [Page 10]


Internet-Draft   L2tp Proxy Authen Exten For EAP          November 2005


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)", 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

10.2. Informative References

   [5]   Extensible Authentication Protocol (EAP) IANA Registry,
         http://www.iana.org/assignments/eap-numbers

   [6]   BCP0068, Townsley, W., "Layer Two Tunneling Protocol (L2TP)
         Internet Assigned Numbers Authority (IANA) Considerations
         Update" RFC3438, BCP0068, December 2002

   [7]   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 May 21, 2006                 [Page 11]


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