RADIUS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Category: Standards Track Glen Zorn Microsoft 18 May 1998 Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as and expires December 1, 1998. Please send comments to the authors. 2. Abstract This document discusses implementation issues arising in the provi- sioning of compulsory tunneling in dial-up networks using the PPTP and L2TP protocols. This provisioning can be accomplished via the inte- gration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate docu- ments. 3. 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. Aboba & Zorn [Page 1] INTERNET-DRAFT 18 May 1998 Roaming "Roaming capability" can be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor rela- tionship with only one. Examples of cases where roaming capaility might be required include ISP "confederations" and ISP-provided corporate network access support. Shared Use Network This is an IP dialup network whose use is shared by two or more organizations. Shared use networks typically implement distributed authentication and accounting in order to facil- itate the relationship among the sharing parties. Since these facilities are also required for implementation of roaming, implementation of shared use is frequently a first step toward development of roaming capabilities. In fact, one of the ways by which a provider can offer roaming ser- vice is to conclude shared use agreements with multiple net- works. However, to date the ability to accomplish this has been hampered by lack of interoperability among shared use implementations. Tunnel Network Server This is a server which terminates a tunnel. In PPTP termi- nology, this is known as the PPTP Network Server (PNS). In L2TP terminology, this is known as the L2TP Network Server (LNS). Network Access Server The Network Access Server (NAS) is the device that clients contact in order to get access to the network. In PPTP ter- minology this is referred to as the PPTP Access Concentrator (PAC). In L2TP terminology, the NAS is referred to as the L2TP Access Concentrator (LAC). RADIUS server This is a server which provides for authentication/autho- rization via the protocol described in [3], and for account- ing as described in [4]. RADIUS proxy In order to provide for the routing of RADIUS authentication and accounting 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. Network Access Identifier In order to provide for the routing of RADIUS authentication and accounting requests, the userID field used in PPP and in the subsequent RADIUS authentication and accounting requests, known as the Network Access Identifier (NAI) MAY contain structure. This structure provides a means by which the RADIUS proxy will locate the RADIUS server that is to receive the request. This same structure MAY also be used to Aboba & Zorn [Page 2] INTERNET-DRAFT 18 May 1998 locate the tunnel endpoint when domain-based tunneling is used. 4. 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 [9]. 5. 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 pur- pose. 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 net- works 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 data to be maintained in a central location, rather than on each NAS. It makes sense to use RADIUS to centrally administer compulsory tun- neling, 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 and to transfer accounting data from the NAS to the RADIUS accounting server; those attributes are defined in [7] and [13]. 5.1. Advantanges of RADIUS-based compulsory tunneling The use of RADIUS in provisioning of compulsory tunnels has several advantages. These include: User-based tunneling Auditing capabilities Aboba & Zorn [Page 3] INTERNET-DRAFT 18 May 1998 5.1.1. User-based Tunneling Current proposals for routing of tunnel requests include static tun- neling, where all users are automatically tunneled to a given end- point, and realm-based tunneling, where the tunnel endpoint is deter- mined from the realm portion of the userID. User-based tunneling as provided by integration of RADIUS and tunnel protocols offers signifi- cant 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 corporate 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 manage- ment. 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 accomodated via user-based tunneling as enabled by the attributes defined in [7]. When deployed in concert with roaming, user-based tunneling offers corporations the ability to provide their users with access to the corporate Intranet on a global basis. 5.2. Auditing Capabilities The integration of RADIUS and tunnel protocols allows the ISP and the corporation to synchronize their accounting activities so that each side receives a record of the user's resource consumption. This pro- vides the corporation with the means to audit ISP bills. In auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client-End- point and Tunnel-Server-Endpoint attributes are typically used to uniquely identify the call, allowing the Accounting-Request sent by the NAS to be reconciled with the corresponding Accounting-Request sent by the tunnel server. When implementing L2TP/PPTP tunneling based on RADIUS, the Call- Serial-Number SHOULD be used in the Acct-Tunnel-Connection attribute. In L2TP, the Call-Serial-Number is a 32-bit field and in PPTP it is a 16-bit field. As described in [6], in PPTP the combination of IP Address and Call-Serial-Number SHOULD be unique, but this is not required. In addition, no method for determining the Call-Serial-Num- ber is specified, which leaves open the possibility of wrapping after a reboot. Aboba & Zorn [Page 4] INTERNET-DRAFT 18 May 1998 Note that a 16-bit Call-Serial-Number is not sufficient to distinguish a given call from all other calls over an extended time period. For example, if the Call-Serial-Number is assigned monotonically, the NAS in question has 96 ports which are continually busy and the average call is of 20 minutes duration, then a 16-bit Call-Serial-Number will wrap within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.48 days. 6. Authentication alternatives RADIUS-based compulsory tunneling can support both single authentica- tion, 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; CHAP/EAP authenti- cation; CHAP/PAP(token) authentication; and EAP/EAP authentication, using the same EAP type for both authentications. The alternatives are described in more detail below. 6.1. Single authentication Single authentication alternatives include: NAS authentication NAS authentication with RADIUS reply forwarding Tunnel server authentication 6.1.1. NAS authentication With this approach, authentication and authorization (including tun- neling information) occurs once, at the NAS. The advantages of this approach are that it disallows network access for unauthorized NAS users, and allows RADIUS accounting to be used at the NAS. Disadvan- tages 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 for- warding and tunnel authentication, both of which are supported in L2TP, described in [5]. Thus, the tunnel server can be set up to accept all calls occurring within authenticated tunnels, without requiring PPP authentication. 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 Aboba & Zorn [Page 5] INTERNET-DRAFT 18 May 1998 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 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Start RADIUS Server to NAS: RADIUS Accounting-Response 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 DOWN message. 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. 6.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 RADIUS accounting to be used 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 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 Aboba & Zorn [Page 6] INTERNET-DRAFT 18 May 1998 result, this scheme is impractical. 6.1.3. 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 follow- ing methods: Telephone-number based authentication User-Name 6.1.3.1. 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 PPTP/L2TP the tunnel server MAY choose to reject or accept the call based on the Dialed Number and Dialing Number included in the PPTP/L2TP Incoming-Call-Request packet sent by the NAS. The use of RADIUS accounting by the NAS and/or the tunnel server allows for accounting to take place based on the Calling-Station-Id and Called-Station-Id. RADIUS as defined in [3] 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 initi- ation 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: PPTP/L2TP Incoming-Call-Request Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply NAS to Tunnel Server: PPTP/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 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Start RADIUS Server to NAS: RADIUS Accounting-Response Tunnel Server to RADIUS Server: RADIUS Accounting-Request Aboba & Zorn [Page 7] INTERNET-DRAFT 18 May 1998 with Acct-Status-Type=Tunnel-Link-Start (Optional) RADIUS Server to Tunnel Server: RADIUS Accounting-Response 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 tun- nel. 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 a PPTP/L2TP tunnel is indicated, the NAS will now bring up a control connection if none existed before. This is accomplished by sending a PPTP/L2TP Start-Control-Connection-Request message to the tunnel server. The tunnel server will then reply with a PPTP/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 PPTP/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 a PPTP/L2TP Incoming-Call-Reply message. If this message indicates an error, then the NAS MUST send an LCP-Termi- nate and disconnect the user. If no error is indicated, the NAS then replies with a PPTP/L2TP Incoming-Call-Connected message. At this point, data MAY begin to flow through the tunnel. If LCP nego- tiation had been begun between the NAS and the client, then LCP for- warding 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 negotia- tion. Rather than sending an LCP CONFACK, the NAS will instead send an LCP DOWN message. 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. Aboba & Zorn [Page 8] INTERNET-DRAFT 18 May 1998 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 negoti- ation. 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. After the tunnel has been brought up, the NAS and tunnel server will typically start accounting. In the case of the NAS, this is done by sending a RADIUS Accounting-Request packet with Acct-Status-Type=Tun- nel-Start to a RADIUS server. When an individual call is brought up, a RADIUS Accounting-Request packet is sent with Acct-Status-Type=Tunnel- Link-Start. The tunnel server can produce its own accounting records, or it MAY send a RADIUS Accounting-Request packet to a local RADIUS server. 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 negoti- ation, authentication and subsequent data interchange with the Tunnel Server. 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 Aboba & Zorn [Page 9] INTERNET-DRAFT 18 May 1998 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 Send RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Start (optional) Send RADIUS Accounting-Response Send a RADIUS Accounting-Request message with Acct-Status-Type=Tunnel-Link-Start Send RADIUS Accounting-Response 6.1.3.2. User-Name Since authentication will occur only at the tunnel-server, tunnel ini- tiation 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 ver- ify 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 Aboba & Zorn [Page 10] INTERNET-DRAFT 18 May 1998 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 sup- ports compulsory tunneling, but does not provide for user-based tun- neling. 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. How- ever, 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 busi- ness relationship with the NAS owner. Thus this approach is incompati- ble 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: PPTP/L2TP Incoming-Call-Request Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply NAS to Tunnel Server: PPTP/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 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Start RADIUS Server to NAS: RADIUS Accounting-Response Tunnel Server to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Start (Optional) RADIUS Server to Tunnel Server: RADIUS Accounting-Response 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 CON- FACK, the NAS will instead send an LCP DOWN message. The Client MAY Aboba & Zorn [Page 11] INTERNET-DRAFT 18 May 1998 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 authenti- cation 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 MAY start accounting. 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 Send RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Start Aboba & Zorn [Page 12] INTERNET-DRAFT 18 May 1998 (optional) Send RADIUS Accounting-Response Send a RADIUS Accounting-Request message with Acct-Status-Type=Tunnel-Link-Start Send RADIUS Accounting-Response 6.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 authentica- tion, 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. 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 net- work 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 authentica- tion combinations. Feasible combinations include PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, CHAP/EAP, EAP/CHAP, and EAP/EAP. 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: PPTP/L2TP Incoming-Call-Request Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply NAS to Tunnel Server: PPTP/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 Tunel Server: RADIUS Access-Accept/Access-Reject Aboba & Zorn [Page 13] INTERNET-DRAFT 18 May 1998 Client and Tunnel Server: NCP negotiation NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Start RADIUS Server to NAS: RADIUS Accounting-Response Tunnel Server to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Start (Optional) RADIUS Server to Tunnel Server: RADIUS Accounting-Response 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 a PPTP/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 renego- tiate LCP and go through another round of PPP authentication. At the time that this 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 DOWN message. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets origi- nated 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 ini- tial 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 authentica- tion 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 tun- neling 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 MAY start accounting. The interactions involved in initiation of a compulsory tunnel with dual authentication are summarized below. INITIATION SEQUENCE NAS Tunnel Server RADIUS Server Aboba & Zorn [Page 14] INTERNET-DRAFT 18 May 1998 --- ------------- ------------- Call accepted LCP starts PPP authentication phase starts Send RADIUS Access-Request with username 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 Send RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Start (optional) Send RADIUS Accounting-Response Send a RADIUS Accounting-Request message with Acct-Status-Type=Tunnel-Link-Start Send RADIUS Accounting-Response ENDIF Aboba & Zorn [Page 15] INTERNET-DRAFT 18 May 1998 7. Termination sequence The tear down of a compulsory tunnel involves an interaction between the client, NAS, Tunnel Server, and RADIUS Accounting server. This interaction is virtually identical regardless of whether telephone- number based authentication, single authentication, or dual authenti- cation is being used. In any of the cases, the following events occur: Tunnel Server to NAS: PPTP/L2TP Call-Clear-Request (optional) NAS to Tunnel Server: PPTP/L2TP Call-Disconnect-Notify NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Stop RADIUS Server to NAS: RADIUS Accounting-Response Tunnel Server to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Stop (Optional) RADIUS Server to Tunnel Server: RADIUS Accounting-Response Tunnel termination can occur due to a client request (PPP termina- tion), 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-Discon- nect-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. After call tear down is complete, if RADIUS accounting is being used then the NAS MUST send a RADIUS Accounting-Request with Acct-Status- Type=Tunnel-Link-Stop packet to a RADIUS accounting server. The tunnel server MAY produce its own accounting records, or it MAY use RADIUS accounting. If RADIUS accounting is being used then the tunnel server MUST send a RADIUS Accounting-Request with Acct-Status- Type=Tunnel-Link-Stop to a RADIUS accounting server. 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. TERMINATION SEQUENCE NAS Tunnel Server RADIUS Server Aboba & Zorn [Page 16] INTERNET-DRAFT 18 May 1998 --- ------------- ------------- IF user disconnected send Call-Disconnect-Notify message to tunnel server Tear down the call stop accounting Send RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Stop (optional) Send RADIUS Accounting-Response 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 Send RADIUS Accounting-Request with Acct-Status-Type=Tunnel-Link-Stop (optional) Send RADIUS Accounting-Response Send a RADIUS Accounting-Request message with Acct-Status-Type=Tunnel-Link-Stop Send RADIUS Accounting-Response ENDIF 8. 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. 8.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 tun- nel authentications. One pair will be used in the initial PPP authen- tication with the NAS, and the second pair will be used for authenti- cation at the tunnel server. Aboba & Zorn [Page 17] INTERNET-DRAFT 18 May 1998 However, 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. In this case, tunnel client implementations SHOULD take care not to put up error messages indicating a bad password. Instead a dialog SHOULD be presented requesting the tunnel userID/password combination. In the case where token cards are being used for both authentications, the tunnel client MUST NOT attempt to present the token used in the first authentication during the second authentication, since these will never be identical. Instead the user SHOULD be prompted to enter the second token. The same issue arises in L2TP if the NAS attempts to forward authenti- cation information to the tunnel server in the initial setup notifica- tion. 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. 8.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 cor- rect 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. 9. 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. Aboba & Zorn [Page 18] INTERNET-DRAFT 18 May 1998 Similarly, references [5] and [6] refer to use of the userID in deter- mining the tunnel endpoint. However, since none of these references provide guidelines for how RADIUS or tunnel routing is to be accom- plished, the possibility of conflicting interpretations exists. 9.1. UserID convergence in user-based tunneling 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 flexibil- ity. 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 rout- ing the NAS RADIUS Access-Request to the same RADIUS server used by the tunnel server. As described in [8], the recommended form for the user ID is userID@realm, i.e. fred@bigco.com. 10. Security considerations In compulsory tunneling, PAP authentication SHOULD NOT be used, since this will typically involve transmission of a cleartext password over the Internet. A possible exception is where PAP is used to support a one time password or token. 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 sup- port 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. Aboba & Zorn [Page 19] INTERNET-DRAFT 18 May 1998 11. Acknowledgements Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions of this problem space, and to Allan Rubens of Ascend and Bertrand Buclin of AT&T Labs Europe for his comments on this document. 12. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asi- ainfo, Merit, September 1997. [2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." Internet draft (work in progress), draft-ietf-roamops-roamreq-09.txt, Microsoft, March 1998. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, Daydreamer, April 1997. [4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 1997. [5] A. Valencia, K. Hamzeh, A. Rubens, T. Kolar, M. Littlewood, W. Townsley, J. Taarud, G. Pall, B. Palter, W. Verthein. "Layer Two Tun- neling Protocol L2TP." Internet draft (work in progress), draft-ietf- pppext-l2tp-10.txt, Ascend Communications, Microsoft, Copper Mountain Networks, U.S. Robotics, March 1998. [6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little. "Point-to-Point Tunneling Protocol -- PPTP." ." Internet draft (work in progress), draft-ietf-pppext-pptp-02.txt, Ascend Communications, Microsoft, Copper Mountain Networks, U.S. Robotics, September 1997. [7] G. Zorn, D. Leifer, A. Rubens, J. Shriver. "RADIUS Attributes for Tunnel Protocol Support." Internet draft (work in progress), draft- ietf-radius-tunnel-auth-05.txt, Microsoft, Ascend Communications, Shiva Corporation, April 1998. [8] B. Aboba, M. A. Beadles. "The Network Access Identifier." Inter- net draft (work in progress), draft-ietf-roamops-nai-10.txt, Microsoft, CompuServe, March 1998. [9] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997. [10] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress, draft-ietf-radius-ext-01.txt, Livingston, June, 1997. [11] P. Calhoun, A.C. Rubens, B. Aboba. "Extensible Authentication Protocol Support in RADIUS." Internet draft (work in progress), draft- ietf-radius-eap-05.txt, Sun Microsystems., Merit Network, Microsoft, May, 1998. Aboba & Zorn [Page 20] INTERNET-DRAFT 18 May 1998 [12] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Proto- col (EAP)." RFC 2284, Merit Network, Inc., March 1998. [13] G. Zorn, D. Mitton. "RADIUS Accounting Modifications for Tunnel Protocol Support." Internet draft (work in progress), draft-ietf- radius-tunnel-acct-00.txt, Microsoft, Bay Networks, November 1997. 13. 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 E-Mail: cdr@livingston.com 14. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 936 6605 EMail: bernarda@microsoft.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 703 1559 EMail: glennz@microsoft.com Aboba & Zorn [Page 21]