diff options
Diffstat (limited to 'doc/rfc/rfc2809.txt')
| -rw-r--r-- | doc/rfc/rfc2809.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc2809.txt b/doc/rfc/rfc2809.txt new file mode 100644 index 0000000..3e98128 --- /dev/null +++ b/doc/rfc/rfc2809.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group B. Aboba +Request for Comments: 2809 Microsoft +Category: Informational G. Zorn + Cisco + April 2000 + + + Implementation of L2TP Compulsory Tunneling via RADIUS + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document discusses implementation issues arising in the + provisioning of compulsory tunneling in dial-up networks using the + L2TP protocol. This provisioning can be accomplished via the + integration of RADIUS and tunneling protocols. Implementation issues + encountered with other tunneling protocols are left to separate + documents. + +1. Terminology + + Voluntary Tunneling + In voluntary tunneling, a tunnel is created by the user, + typically via use of a tunneling client. + + Compulsory Tunneling + In compulsory tunneling, a tunnel is created without any + action from the user and without allowing the user any + choice. + + Tunnel Network Server + This is a server which terminates a tunnel. In L2TP + terminology, this is known as the L2TP Network Server + (LNS). + + + + + + + + +Aboba & Zorn Informational [Page 1] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + Network Access Server + The Network Access Server (NAS) is the device that clients + contact in order to get access to the network. In L2TP + terminology, a NAS performing compulsory tunneling is + referred to as the L2TP Access Concentrator (LAC). + + RADIUS authentication server + This is a server which provides for + authentication/authorization via the protocol described in + [1]. + + RADIUS proxy + In order to provide for the routing of RADIUS + authentication requests, a RADIUS proxy can be employed. + To the NAS, the RADIUS proxy appears to act as a RADIUS + server, and to the RADIUS server, the proxy appears to act + as a RADIUS client. Can be used to locate the tunnel + endpoint when realm-based tunneling is used. + +2. Requirements language + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as + described in [4]. + +3. Introduction + + Many applications of tunneling protocols involve dial-up network + access. Some, such as the provisioning of secure access to corporate + intranets via the Internet, are characterized by voluntary tunneling: + the tunnel is created at the request of the user for a specific + purpose. Other applications involve compulsory tunneling: the tunnel + is created without any action from the user and without allowing the + user any choice. + + Examples of applications that might be implemented using compulsory + tunnels are Internet software upgrade servers, software registration + servers and banking services. These are all services which, without + compulsory tunneling, would probably be provided using dedicated + networks or at least dedicated network access servers (NAS), since + they are characterized by the need to limit user access to specific + hosts. + + Given the existence of widespread support for compulsory tunneling, + however, these types of services could be accessed via any Internet + service provider (ISP). The most popular means of authorizing dial- + up network users today is through the RADIUS protocol. The use of + RADIUS allows the dial-up users' authorization and authentication + + + +Aboba & Zorn Informational [Page 2] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + data to be maintained in a central location, rather than on each NAS. + It makes sense to use RADIUS to centrally administer compulsory + tunneling, since RADIUS is widely deployed and was designed to carry + this type of information. New RADIUS attributes are needed to carry + the tunneling information from the RADIUS server to the NAS. Those + attributes are defined in [3]. + +3.1. Advantages of RADIUS-based compulsory tunneling + + Current proposals for routing of tunnel requests include static + tunneling, where all users are automatically tunneled to a given + endpoint, and realm-based tunneling, where the tunnel endpoint is + determined from the realm portion of the userID. User-based tunneling + as provided by integration of RADIUS and tunnel protocols offers + significant advantages over both of these approaches. + + Static tunneling requires dedication of a NAS device to the purpose. + In the case of an ISP, this is undesirable because it requires them + to dedicate a NAS to tunneling service for a given customer, rather + than allowing them to use existing NASes deployed in the field. As a + result static tunneling is likely to be costly for deployment of a + global service. + + Realm-based tunneling assumes that all users within a given realm + wish to be treated the same way. This limits flexibility in account + management. For example, BIGCO may desire to provide Janet with an + account that allows access to both the Internet and the intranet, + with Janet's intranet access provided by a tunnel server located in + the engineering department. However BIGCO may desire to provide Fred + with an account that provides only access to the intranet, with + Fred's intranet access provided by a tunnel network server located in + the sales department. Such a situation cannot be accommodated with + realm-based tunneling, but can be accommodated via user-based + tunneling as enabled by the attributes defined in [3]. + +4. Authentication alternatives + + RADIUS-based compulsory tunneling can support both single + authentication, where the user is authenticated at the NAS or tunnel + server, or dual authentication, where the user is authenticated at + both the NAS and the tunnel server. When single authentication is + supported, a variety of modes are possible, including telephone- + number based authentication. When dual-authentication is used, a + number of modes are available, including dual CHAP authentications; + + + + + + + +Aboba & Zorn Informational [Page 3] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + CHAP/EAP authentication; CHAP/PAP(token) authentication; and EAP/EAP + authentication, using the same EAP type for both authentications. EAP + is described in [5]. + + The alternatives are described in more detail below. + +4.1. Single authentication + + Single authentication alternatives include: + + NAS authentication + NAS authentication with RADIUS reply forwarding + Tunnel server authentication + +4.1.1. NAS authentication + + With this approach, authentication and authorization (including + tunneling information) occurs once, at the NAS. The advantages of + this approach are that it disallows network access for unauthorized + NAS users, and permits accounting to done at the NAS. Disadvantages + are that it requires that the tunnel server trust the NAS, since no + user authentication occurs at the tunnel server. Due to the lack of + user authentication, accounting cannot take place at the tunnel + server with strong assurance that the correct party is being billed. + + NAS-only authentication is most typically employed along with LCP + forwarding and tunnel authentication, both of which are supported in + L2TP, described in [2]. Thus, the tunnel server can be set up to + accept all calls occurring within authenticated tunnels, without + requiring PPP authentication. However, this approach is not + compatible with roaming, since the tunnel server will typically only + be set up to accept tunnels from a restricted set of NASes. A typical + initiation sequence looks like this: + + Client and NAS: Call Connected + Client and NAS: PPP LCP negotiation + Client and NAS: PPP authentication + NAS to RADIUS Server: RADIUS Access-request + RADIUS server to NAS: RADIUS Access-Accept/Access-Reject + NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding + Tunnel Server to NAS: L2TP Incoming-Call-Reply + NAS to Tunnel Server: L2TP Incoming-Call-Connected + Client and Tunnel Server: NCP negotiation + + + + + + + + +Aboba & Zorn Informational [Page 4] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + The process begins with an incoming call to the NAS, and the PPP LCP + negotiation between the client and the NAS. In order to authenticate + the client, the NAS will send a RADIUS Access-Request to the RADIUS + server and will receive a RADIUS Access-Accept including tunnel + attributes, or an Access-Reject. + + In the case where an L2TP tunnel is indicated, the NAS will now bring + up a control connection if none existed before, and the NAS and + tunnel server will bring up the call. At this point, data will begin + to flow through the tunnel. The NAS will typically employ LCP + forwarding, although it is also possible for the tunnel server to + renegotiate LCP. If LCP renegotiation is to be permitted, the NAS + SHOULD NOT send an LCP CONFACK completing LCP negotiation. Rather + than sending an LCP CONFACK, the NAS will instead send an LCP + Configure-Request packet, described in [6]. The Client MAY then + renegotiate LCP, and from that point forward, all PPP packets + originated from the client will be encapsulated and sent to the + tunnel server. + + Since address assignment will occur at the tunnel server, the client + and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will + occur between the client and the tunnel server. + +4.1.2. NAS authentication with RADIUS reply forwarding + + With this approach, authentication and authorization occurs once at + the NAS and the RADIUS reply is forwarded to the tunnel server. This + approach disallows network access for unauthorized NAS users; does + not require trust between the NAS and tunnel server; and allows for + accounting to be done at both ends of the tunnel. However, it also + requires that both ends share the same secret with the RADIUS server, + since that is the only way that the tunnel server can check the + RADIUS Access-Reply. + + In this approach, the tunnel server will share secrets with all the + NASes and associated RADIUS servers, and there is no provision for + LCP renegotiation by the tunnel server. Also, the tunnel server will + need to know how to handle and verify RADIUS Access-Accept messages. + + While this scheme can be workable if the reply comes directly from a + RADIUS server, it would become unmanageable if a RADIUS proxy is + involved, since the reply would be authenticated using the secret + shared by the client and proxy, rather than the RADIUS server. As a + result, this scheme is impractical. + + + + + + + +Aboba & Zorn Informational [Page 5] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + +4.1.2.1. Tunnel server authentication + + In this scheme, authentication and authorization occurs once at the + tunnel server. This requires that the NAS determine that the user + needs to be tunneled (through RADIUS or NAS configuration). Where + RADIUS is used, the determination can be made using one of the + following methods: + + Telephone-number based authentication + UserID + +4.1.2.2. Telephone-number based authentication + + Using the Calling-Station-Id and Called-Station-Id RADIUS attributes, + authorization and subsequent tunnel attributes can be based on the + phone number originating the call, or the number being called. This + allows the RADIUS server to authorize users based on the calling + phone number or to provide tunnel attributes based on the Calling- + Station-Id or Called-Station-Id. Similarly, in L2TP the tunnel + server MAY choose to reject or accept the call based on the Dialed + Number and Dialing Number included in the L2TP Incoming-Call-Request + packet sent by the NAS. Accounting can also take place based on the + Calling-Station-Id and Called-Station-Id. + + RADIUS as defined in [1] requires that an Access-Request packet + contain a User-Name attribute as well as either a CHAP-Password or + User-Password attribute, which must be non-empty. To satisfy this + requirement the Called-Station-Id or Calling-Station-Id MAY be + furnished in the User-Name attribute and a dummy value MAY be used in + the User-Password or CHAP-Password attribute. + + In the case of telephone-number based authentication, a typical + initiation sequence looks like this: + + Client and NS: Call Connected + NAS to RADIUS Server: RADIUS Access-request + RADIUS server to NAS: RADIUS Access-Accept/Access-Reject + NAS to Tunnel Server: L2TP Incoming-Call-Request + Tunnel Server to NAS: L2TP Incoming-Call-Reply + NAS to Tunnel Server: L2TP Incoming-Call-Connected + Client and Tunnel Server: PPP LCP negotiation + Client and Tunnel Server: PPP authentication + Tunnel Server to RADIUS Server: RADIUS Access-request (optional) + RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject + Client and Tunnel Server: NCP negotiation + + + + + + +Aboba & Zorn Informational [Page 6] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + The process begins with an incoming call to the NAS. If configured + for telephone-number based authentication, the NAS sends a RADIUS + Access-Request containing the Calling-Station-Id and the Called- + Station-Id attributes. The RADIUS server will then respond with a + RADIUS Access-Accept or Access-Reject. + + The NAS MUST NOT begin PPP authentication before bringing up the + tunnel. If timing permits, the NAS MAY bring up the tunnel prior to + beginning LCP negotiation with the peer. If this is done, then LCP + will not need to be renegotiated between the peer and tunnel server, + nor will LCP forwarding need to be employed. + + If the initial telephone-number based authentication is unsuccessful, + the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS + MUST send an LCP-Terminate and disconnect the user. + + In the case where tunnel attributes are included in the RADIUS + Access-Accept, and an L2TP tunnel is indicated, the NAS will now + bring up a control connection if none existed before. This is + accomplished by sending an L2TP Start-Control-Connection-Request + message to the tunnel server. The tunnel server will then reply with + an L2TP Start-Control-Connection-Reply. If this message indicates an + error, or if the control connection is terminated at any future time, + then the NAS MUST send an LCP-Terminate and disconnect the user. + + The NAS will then send an L2TP Incoming-Call-Request message to the + tunnel server. Among other things, this message will contain the Call + Serial Number, which along with the NAS-IP-Address and Tunnel- + Server-Endpoint is used to uniquely identify the call. The tunnel + server will reply with an L2TP Incoming-Call-Reply message. If this + message indicates an error, then the NAS MUST send an LCP-Terminate + and disconnect the user. If no error is indicated, the NAS then + replies with an L2TP Incoming-Call-Connected message. + + At this point, data can begin to flow through the tunnel. If LCP + negotiation had been begun between the NAS and the client, then LCP + forwarding may be employed, or the client and tunnel server will now + renegotiate LCP and begin PPP authentication. Otherwise, the client + and tunnel server will negotiate LCP for the first time, and then + move on to PPP authentication. + + If a renegotiation is required, at the time that the renegotiation + begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP + negotiation, and the client and NAS MUST NOT have begun NCP + negotiation. Rather than sending an LCP CONFACK, the NAS will + instead send an LCP Configure-Request Packet, described in [6]. The + Client MAY then renegotiate LCP, and from that point forward, all PPP + packets originated from the client will be encapsulated and sent to + + + +Aboba & Zorn Informational [Page 7] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + the tunnel server. When LCP re-negotiation has been concluded, the + NCP phase will begin, and the tunnel server will assign an address to + the client. + + If L2TP is being used as the tunnel protocol, and LCP renegotiation + is required, the NAS MAY in its initial setup notification include a + copy of the LCP CONFACKs sent in each direction which completed LCP + negotiation. The tunnel server MAY then use this information to avoid + an additional LCP negotiation. With L2TP, the initial setup + notification can also include the authentication information required + to allow the tunnel server to authenticate the user and decide to + accept or decline the connection. However, in telephone-number based + authentication, PPP authentication MUST NOT occur prior to the NAS + bringing up the tunnel. As a result, L2TP authentication forwarding + MUST NOT be employed. + + In performing the PPP authentication, the tunnel server can access + its own user database, or alternatively can send a RADIUS Access- + Request. The latter approach is useful in cases where authentication + forwarding is enabled, such as with roaming or shared use networks. + In this case, the RADIUS and tunnel servers are under the same + administration and are typically located close together, possibly on + the same LAN. Therefore having the tunnel server act as a RADIUS + client provides for unified user administration. Note that the tunnel + server's RADIUS Access-Request is typically sent directly to the + local RADIUS server rather than being forwarded via a proxy. + + The interactions involved in initiation of a compulsory tunnel with + telephone-number based authentication are summarized below. In order + to simplify the diagram that follows, we have left out the client. + However, it is understood that the client participates via PPP + negotiation, authentication and subsequent data interchange with the + Tunnel Server. + + + + + + + + + + + + + + + + + + +Aboba & Zorn Informational [Page 8] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + INITIATION SEQUENCE + + NAS Tunnel Server RADIUS Server + --- ------------- ------------- + Call connected + Send RADIUS + Access-Request + with Called-Station-Id, + and/or Calling-Station-Id + LCP starts + IF authentication + succeeds + Send ACK + ELSE Send NAK + IF NAK DISCONNECT + ELSE + IF no control + connection exists + Send + Start-Control-Connection-Request + to Tunnel Server + Send + Start-Control-Connection-Reply + to NAS + ENDIF + + Send + Incoming-Call-Request + message to Tunnel Server + Send Incoming-Call-Reply + to NAS + Send + Incoming-Call-Connected + message to Tunnel Server + + Send data through the tunnel + Re-negotiate LCP, + authenticate user, + bring up IPCP, + start accounting + + + + + + + + + + + +Aboba & Zorn Informational [Page 9] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + +4.1.2.3. User-Name + + Since authentication will occur only at the tunnel-server, tunnel + initiation must occur prior to user authentication at the NAS. As a + result, this scheme typically uses either the domain portion of the + userID or attribute-specific processing on the RADIUS server. Since + the user identity is never verified by the NAS, either the tunnel + server owner must be willing to be billed for all incoming calls, or + other information such as the Calling-Station-Id must be used to + verify the user's identity for accounting purposes. + + In attribute-specific processing RADIUS may be employed and an + attribute is used to signal tunnel initiation. For example, tunnel + attributes can be sent back if the User-Password attribute contains a + dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID + beginning with a special character ('*') could be used to indicate + the need to initiate a tunnel. When attribute-specific processing is + used, the tunnel server may need to renegotiate LCP. + + Another solution involves using the domain portion of the userID; all + users in domain X would be tunneled to address Y. This proposal + supports compulsory tunneling, but does not provide for user-based + tunneling. + + In order for the NAS to start accounting on the connection, it would + need to use the identity claimed by the user in authenticating to the + tunnel server, since it did not verify the identity via RADIUS. + However, in order for that to be of any use in accounting, the tunnel + endpoint needs to have an account relationship with the NAS owner. + Thus even if a user has an account with the NAS owner, they cannot + use this account for tunneling unless the tunnel endpoint also has a + business relationship with the NAS owner. Thus this approach is + incompatible with roaming. + + A typical initiation sequence involving use of the domain portion of + the userID looks like this: + + Client and NAS: Call Connected + Client and NAS: PPP LCP negotiation + Client and NAS: Authentication + NAS to Tunnel Server: L2TP Incoming-Call-Request + Tunnel Server to NAS: L2TP Incoming-Call-Reply + NAS to Tunnel Server: L2TP Incoming-Call-Connected + Client and Tunnel Server: PPP LCP re-negotiation + Client and Tunnel Server: PPP authentication + Tunnel Server to RADIUS Server: RADIUS Access-request (optional) + RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject + Client and Tunnel Server: NCP negotiation + + + +Aboba & Zorn Informational [Page 10] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + The process begins with an incoming call to the NAS, and the PPP LCP + negotiation between the Client and NAS. The authentication process + will then begin and based on the domain portion of the userID, the + NAS will now bring up a control connection if none existed before, + and the NAS and tunnel server will bring up the call. At this point, + data MAY begin to flow through the tunnel. The client and tunnel + server MAY now renegotiate LCP and will complete PPP authentication. + + At the time that the renegotiation begins, the NAS SHOULD NOT have + sent an LCP CONFACK completing LCP negotiation, and the client and + NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP + CONFACK, the NAS will instead send an LCP Configure-Request packet, + described in [6]. The Client MAY then renegotiate LCP, and from that + point forward, all PPP packets originated from the client will be + encapsulated and sent to the tunnel server. In single authentication + compulsory tunneling, L2TP authentication forwarding MUST NOT be + employed. When LCP re-negotiation has been concluded, the NCP phase + will begin, and the tunnel server will assign an address to the + client. + + In performing the PPP authentication, the tunnel server can access + its own user database, or it MAY send a RADIUS Access-Request. After + the tunnel has been brought up, the NAS and tunnel server can start + accounting. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba & Zorn Informational [Page 11] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + The interactions are summarized below. + + INITIATION SEQUENCE + + NAS Tunnel Server RADIUS Server + --- ------------- ------------- + Call accepted + LCP starts + Authentication + phase starts + IF no control + connection exists + Send + Start-Control-Connection-Request + to Tunnel Server + ENDIF + IF no control + connection exists + Send + Start-Control-Connection-Reply + to NAS + ENDIF + + Send + Incoming-Call-Request + message to Tunnel Server + Send Incoming-Call-Reply + to NAS + Send + Incoming-Call-Connected + message to Tunnel Server + + Send data through the tunnel + Re-negotiate LCP, + authenticate user, + bring up IPCP, + start accounting + +4.2. Dual authentication + + In this scheme, authentication occurs both at the NAS and the tunnel + server. This requires the dial-up client to handle dual + authentication, with attendant LCP re-negotiations. In order to allow + the NAS and tunnel network server to authenticate against the same + database, this requires RADIUS client capability on the tunnel + network server, and possibly a RADIUS proxy on the NAS end. + + + + + +Aboba & Zorn Informational [Page 12] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + Advantages of dual authentication include support for authentication + and accounting at both ends of the tunnel; use of a single + userID/password pair via implementation of RADIUS on the tunnel + network server; no requirement for telephone-number based + authentication, or attribute-specific processing on the RADIUS + server. + + Dual authentication allows for accounting records to be generated on + both the NAS and tunnel server ends, making auditing possible. Also + the tunnel endpoint does not need to have an account relationship + with the NAS owner, making this approach compatible with roaming. + + A disadvantage of dual authentication is that unless LCP forwarding + is used, LCP will need to be renegotiated; some clients do not + support it at all, and others only support only a subset of the dual + authentication combinations. Feasible combinations include + PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, + CHAP/EAP, EAP/CHAP, and EAP/EAP. EAP is described in [5]. + + In the case of a dual authentication, a typical initiation sequence + looks like this: + + Client and NAS: PPP LCP negotiation + Client and NAS: PPP authentication + NAS to RADIUS Server: RADIUS Access-request + RADIUS server to NAS: RADIUS Access-Accept/Access-Reject + NAS to Tunnel Server: L2TP Incoming-Call-Request + Tunnel Server to NAS: L2TP Incoming-Call-Reply + NAS to Tunnel Server: L2TP Incoming-Call-Connected + Client and Tunnel Server: PPP LCP re-negotiation (optional) + Client and Tunnel Server: PPP authentication + Tunnel Server to RADIUS Server: RADIUS Access-request (optional) + RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject + Client and Tunnel Server: NCP negotiation + + The process begins with an incoming call to the NAS. The client and + NAS then begin LCP negotiation. Subsequently the PPP authentication + phase starts, and the NAS sends a RADIUS Access-Request message to + the RADIUS server. If the authentication is successful, the RADIUS + server responds with a RADIUS Access-Accept containing tunnel + attributes. + + In the case where an L2TP tunnel is indicated, the NAS will now bring + up a control connection if none existed before, and the NAS and + tunnel server will bring up the call. At this point, data MAY begin + to flow through the tunnel. The client and tunnel server MAY now + renegotiate LCP and go through another round of PPP authentication. + At the time that this renegotiation begins, the NAS SHOULD NOT have + + + +Aboba & Zorn Informational [Page 13] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + sent an LCP CONFACK completing LCP negotiation, and the client and + NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP + CONFACK, the NAS will instead send an LCP Configure-Request packet, + described in [6]. The Client MAY then renegotiate LCP, and from that + point forward, all PPP packets originated from the client will be + encapsulated and sent to the tunnel server. When LCP re-negotiation + has been concluded, the NCP phase will begin, and the tunnel server + will assign an address to the client. + + If L2TP is being used as the tunnel protocol, the NAS MAY in its + initial setup notification include a copy of the LCP CONFACKs sent in + each direction which completed LCP negotiation. The tunnel server MAY + then use this information to avoid an additional LCP negotiation. + With L2TP, the initial setup notification can also include the + authentication information required to allow the tunnel server to + authenticate the user and decide to accept or decline the connection. + However, this facility creates a vulnerability to replay attacks, and + can create problems in the case where the NAS and tunnel server + authenticate against different RADIUS servers. As a result, where + user-based tunneling via RADIUS is implemented, L2TP authentication + forwarding SHOULD NOT be employed. + + In performing the PPP authentication, the tunnel server can access + its own user database, or it MAY send a RADIUS Access-Request. After + the tunnel has been brought up, the NAS and tunnel server can start + accounting. + + The interactions involved in initiation of a compulsory tunnel with + dual authentication are summarized below. + + + + + + + + + + + + + + + + + + + + + + +Aboba & Zorn Informational [Page 14] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + INITIATION SEQUENCE + + NAS Tunnel Server RADIUS Server + --- ------------- ------------- + Call accepted + LCP starts + PPP authentication + phase starts + Send RADIUS + Access-Request + with userID and + authentication data + IF authentication + succeeds + Send ACK + ELSE Send NAK + IF NAK DISCONNECT + ELSE + IF no control + connection exists + Send + Start-Control-Connection-Request + to Tunnel Server + Send + Start-Control-Connection-Reply + to NAS + ENDIF + + Send + Incoming-Call-Request + message to Tunnel Server + Send Incoming-Call-Reply + to NAS + Send + Incoming-Call-Connected + message to Tunnel Server + + Send data through the tunnel + Re-negotiate LCP, + authenticate user, + bring up IPCP, + start accounting + ENDIF + + + + + + + + +Aboba & Zorn Informational [Page 15] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + +5. Termination sequence + + The tear down of a compulsory tunnel involves an interaction between + the client, NAS and Tunnel Server. This interaction is virtually + identical regardless of whether telephone-number based + authentication, single authentication, or dual authentication is + being used. In any of the cases, the following events occur: + + Tunnel Server to NAS: L2TP Call-Clear-Request (optional) + NAS to Tunnel Server: L2TP Call-Disconnect-Notify + + Tunnel termination can occur due to a client request (PPP + termination), a tunnel server request (Call-Clear-Request), or a line + problem (call disconnect). + + In the case of a client-requested termination, the tunnel server MUST + terminate the PPP session. The tunnel server MUST subsequently send a + Call-Clear-Request to the NAS. The NAS MUST then send a Call- + Disconnect-Notify message to the tunnel server, and will disconnect + the call. + + The NAS MUST also respond with a Call-Disconnect-Notify message and + disconnection if it receives a Call-Clear-Request from the tunnel + server without a client-requested termination. + + In the case of a line problem or user hangup, the NAS MUST send a + Call-Disconnect-Notify to the tunnel server. Both sides will then + tear down the call. + + The interactions involved in termination of a compulsory tunnel are + summarized below. In order to simplify the diagram that follows, we + have left out the client. However, it is understood that the client + MAY participate via PPP termination and disconnection. + + + + + + + + + + + + + + + + + + +Aboba & Zorn Informational [Page 16] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + TERMINATION SEQUENCE + + NAS Tunnel Server RADIUS Server + --- ------------- ------------- + IF user disconnected + send + Call-Disconnect-Notify + message to tunnel server + Tear down the call + stop accounting + ELSE IF client requests + termination + send + Call-Clear-Request + to the NAS + Send + Call-Disconnect-Notify + message to tunnel server + Disconnect the user + Tear down the call + stop accounting + ENDIF + +6. Use of distinct RADIUS servers + + In the case that the NAS and the tunnel server are using distinct + RADIUS servers, some interesting cases can arise in the provisioning + of compulsory tunnels. + +6.1. Distinct userIDs + + If distinct RADIUS servers are being used, it is likely that distinct + userID/password pairs will be required to complete the RADIUS and + tunnel authentications. One pair will be used in the initial PPP + authentication with the NAS, and the second pair will be used for + authentication at the tunnel server. + + This has implications if the NAS attempts to forward authentication + information to the tunnel server in the initial setup notification. + Since the userID/password pair used for tunnel authentication is + different from that used to authenticate against the NAS, forwarding + authentication information in this manner will cause the tunnel + authentication to fail. As a result, where user-based tunneling via + RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be + employed. + + + + + + +Aboba & Zorn Informational [Page 17] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + In order to provide maximum ease of use in the case where the + userID/password pairs are identical, tunnel clients typically attempt + authentication with the same userID/password pair as was used in the + initial PPP negotiation. Only after this fails do they prompt the + user for the second pair. Rather than putting up an error message + indicating an authentication failure, it is preferable to present a + dialog requesting the tunnel userID/password combination. + + A similar issue arises when extended authentication methods are being + used, as is enabled by EAP, described in [5]. In particular, when + one-time passwords or cryptographic calculators are being used, + different passwords will be used for the first and second + authentications. Thus the user will need to be prompted to enter the + second password. + +6.2. Multilink PPP issues + + It is possible for the two RADIUS servers to return different Port- + Limit attributes. For example, it is conceivable that the NAS RADIUS + server will only grant use of a single channel, while the tunnel + RADIUS server will grant more than one channel. In this case, the + correct behavior is for the tunnel client to open a connection to + another NAS in order to bring up a multilink bundle on the tunnel + server. The client MUST NOT indicate to the NAS that this additional + link is being brought up as part of a multilink bundle; this will + only be indicated in the subsequent negotiation with the tunnel + server. + + It is also conceivable that the NAS RADIUS server will allow the + client to bring up multiple channels, but that the tunnel RADIUS + server will allow fewer channels than the NAS RADIUS server. In this + case, the client should terminate use of the excess channels. + +7. UserID Issues + + In the provisioning of roaming and shared use networks, one of the + requirements is to be able to route the authentication request to the + user's home RADIUS server. This authentication routing is + accomplished based on the userID submitted by the user to the NAS in + the initial PPP authentication. The userID is subsequently relayed by + the NAS to the RADIUS server in the User-Name attribute, as part of + the RADIUS Access-Request. + + Similarly, [2] refers to use of the userID in determining the tunnel + endpoint, although it does not provide guidelines for how RADIUS or + tunnel routing is to be accomplished. Thus the possibility of + conflicting interpretations exists. + + + + +Aboba & Zorn Informational [Page 18] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + + The use of RADIUS in provisioning of compulsory tunneling relieves + the userID from having to do double duty. Rather than being used both + for routing of the RADIUS authentication/authorization request as + well for determination of the tunnel endpoint, the userID is now used + solely for routing of RADIUS authentication/authorization requests. + Tunnel attributes returned in the RADIUS Access-Response are then + used to determine the tunnel endpoint. + + Since the framework described in this document allows both ISPs and + tunnel users to authenticate users as well as to account for + resources consumed by them, and provides for maintenance of two + distinct userID/password pairs, this scheme provides a high degree of + flexibility. Where RADIUS proxies and tunneling are employed, it is + possible to allow the user to authenticate with a single + userID/password pair at both the NAS and the tunnel endpoint. This is + accomplished by routing the NAS RADIUS Access-Request to the same + RADIUS server used by the tunnel server. + +8. References + + [1] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2138, April + 1997. + + [2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and + Palter, B., "Layer Two Tunneling Protocol "L2TP"", RFC 2661, + August 1999. + + [3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and + Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", + Work in Progress. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Blunk, L. anf J. Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + + + + + + + + + + +Aboba & Zorn Informational [Page 19] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + +9. Security Considerations + + In PPP-based tunneling, PPP security is negotiated between the client + and the tunnel server, and covers the entire length of the path. This + is because the client does not have a way to know that they are being + tunneled. Thus, any security the NAS may negotiate with the tunnel + server will occur in addition to that negotiated between the client + and NAS. + + In L2TP compulsory tunneling, this means that PPP encryption and + compression will be negotiated between the client and the tunnel + server. In addition, the NAS may bring up an IPSEC security + association between itself and the tunnel server. This adds + protection against a number of possible attacks. + + Where RADIUS proxies are deployed, the Access-Reply sent by the + RADIUS server may be processed by one or more proxies prior to being + received by the NAS. In order to ensure that tunnel attributes + arrive without modification, intermediate RADIUS proxies forwarding + the Access-Reply MUST NOT modify tunnel attributes. If the RADIUS + proxy does not support tunnel attributes, then it MUST send an + Access-Reject to the NAS. This is necessary to ensure that the user + is only granted access if the services requested by the RADIUS server + can be provided. + + Since RADIUS tunnel attributes are used for compulsory tunneling, + address assignment is handled by the tunnel server rather than the + NAS. As a result, if tunnel attributes are present, the NAS MUST + ignore any address assignment attributes sent by the RADIUS server. + In addition, the NAS and client MUST NOT begin NCP negotiation, since + this could create a time window in which the client will be capable + of sending packets to the transport network, which is not permitted + in compulsory tunneling. + +10. Acknowledgements + + Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions + of this problem space, and to Allan Rubens of Tut Systems and + Bertrand Buclin of AT&T Labs Europe for their comments on this + document. + + Most of the work on this document was performed while Glen Zorn was + employed by the Microsoft Corporation. + + + + + + + + +Aboba & Zorn Informational [Page 20] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + +11. Chair's Address + + The RADIUS Working Group can be contacted via the current chair: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 510-426-0770 + EMail: cdr@livingston.com + +12. Authors' Addresses + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425-936-6605 + EMail: bernarda@microsoft.com + + + Glen Zorn + Cisco Systems, Inc. + 500 108th Avenue N.E., Suite 500 + Bellevue, WA 98004 + USA + + Phone: +1 425 438 8218 + FAX: +1 425 438 1848 + EMail: gwz@cisco.com + + + + + + + + + + + + + + + + + + + +Aboba & Zorn Informational [Page 21] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + +13. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba & Zorn Informational [Page 22] + +RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Aboba & Zorn Informational [Page 23] + |