One document matched: draft-ietf-l2tpext-proxy-authen-ext-eap-00.txt
Network Working Group M. Kelkar
Internet Draft Juniper Networks
Expires: June 2006 December 16, 2005
L2TP Proxy Authenticate Extensions for EAP
draft-ietf-l2tpext-proxy-authen-ext-eap-00.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 June 16, 2006 [Page 1]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 2]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 3]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 4]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 5]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 6]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 7]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 8]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 9]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 10]
Internet-Draft L2TP Proxy Authen Extensions For EAP December 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 June 16, 2006 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-22 13:18:28 |