HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:25:29 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 26 Nov 1996 16:50:00 GMT ETag: "3dde66-b630-329b1fb8" Accept-Ranges: bytes Content-Length: 46640 Connection: close Content-Type: text/plain Network Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Glen Zorn 26 November 1996 Microsoft Corporation Implementation of Mandatory 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 June 1, 1997. Please send comments to the authors. 2. Abstract This document discusses implementation issues arising in the provi- sioning of mandatory tunneling in dial-up networks using the PPTP and L2TP protocols. This provisioning may be accomplished via the inte- gration of RADIUS and tunneling protocols. 3. Terminology Roaming "Roaming capability" may 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 roam- ing capability might be required include ISP "confedera- tions" 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 Aboba & Zorn [Page 1] INTERNET-DRAFT 26 November 1996 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 may 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 dial in order to get access to the network. In PPTP termi- nology 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 authentica- tion/authorization via the protocol described in [3], and for accounting as described in [4]. RADIUS proxy In order to provide for the routing of RADIUS authentication and accounting requests, a RADIUS proxy may 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 locate the tunnel endpoint when domain-based tunneling is used. 4. Requirements language This document uses the same words as RFC 1123 [4] for defining the significance of each particular requirement. These words are: MUST This word or the adjective "required" means that the item is an absolute requirement of the specification. Aboba & Zorn [Page 2] INTERNET-DRAFT 26 November 1996 MUST NOT This phrase means that the definition is an absolute prohi- bition of the specification. SHOULD This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be under- stood and the case carefully weighed before choosing a dif- ferent course. MAY This word or the adjective "optional" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. Silently Discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter. An implementation is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its proto- cols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant." 5. Introduction Many of the most interesting applications of tunneling protocols such as PPTP and L2TP 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 automatically, without any action from the user and more importantly, without allowing the user any choice in the matter. 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 mandatory 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. Aboba & Zorn [Page 3] INTERNET-DRAFT 26 November 1996 Given the existence of widespread support for mandatory tunneling, however, these types of services could be accessed via virtually any Internet service provider (ISP). The most popular means of authoriz- ing dial-up network users today is through the RADIUS protocol. The use of RADIUS allows the dial-up users' authorization and authentica- tion data to be maintained in a central location, rather than being subject to manual configuration. It makes sense to use RADIUS to cen- trally 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 and to transfer accounting data from the NAS to the RADIUS server; those attributes are defined in [7]. This document focuses on implementation issues arising in the provi- sioning of mandatory tunneling in dialup networks. The use of RADIUS in provisioning of mandatory tunneling has several advantages. These include: Auditing capabilities Per-user tunneling Telephone-number based authentication and accounting 5.1. 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 ability to audit ISP bills. This capa- bility is particularly important when the user is taking advantage of roaming capabilities in order to connect to the corporate intranet from a remote location. As described in [7], auditing requires implementation of number of new RADIUS attributes. These new attributes allow the RADIUS server to provide information within the Accounting-Request packet that will allow matching with the corresponding tunnel server Accounting-Request packet. This information includes the Connection-Identifier, the tun- nel protocol (PPTP, L2F, or L2TP), tunnel-media (X.25, ATM, Frame Relay, IP) the address of the remote tunnel endpoint, and the tunnel client address. 5.1.1. Connection-Identifier In L2TP the Call-Serial-Number is used as the RADIUS Connection Iden- tifier, and the tuple (userID, tunnel-client-endpoint address, tunnel- server-endpoint address, Call-Serial-Number) is used to uniquely iden- tify the call. In order to protect against wrapping due to reboots or call volume, it is recommended that a 64-bit NTP timestamp be used as the Call-Serial Number. While the PPTP specification states that the Call-Serial-Number SHOULD be unique, it does not mandate this. In addition, no method for Aboba & Zorn [Page 4] INTERNET-DRAFT 26 November 1996 determining the Call-Serial-Number is specified, which leaves open the possibility of wrapping after a reboot. Finally since the Call-Serial- Number is a 16-bit value, the Call-Serial-Number is not sufficient to distinguish a given call from all other calls over an extended time period. For example, let us assume that the Call Serial Number is assigned monotonically, and that the NAS in question has 96 ports. If the NAS ports are kept continually busy and the average call is of 20 minutes duration, then the Call Serial Number will wrap within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.48 days. In order to rectify this, it is recommended that another message be added to PPTP so that the NAS could provide the tunnel server with a unique Connection Identifier. It is recommended that a 64-bit NTP timestamp be used for this purpose. This is not an issue in L2TP since the Call-Serial-Number string may be of variable length. 5.2. Per-user 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. Per-user tunneling as pro- vided 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 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 a corporation's flexibility in managing the account rights of their users. For example, BIGCO may wish 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 wish 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. On the other hand, per-user tunneling as enabled by the attributes defined in [7] provides BIGCO with the flexibility to administer tun- neling behavior on a per-user basis. When deployed in concert with roaming, per-user tunneling offers corporations the ability to provide their users with access to the corporate Intranet on a global basis. As described in [7], provisioning of mandatory tunneling requires no new RADIUS messages, and implementation of three new RADIUS attributes. During authentication, the new attributes allow the RADIUS server to indicate the tunnel protocol (PPTP, L2F, or L2TP), the Aboba & Zorn [Page 5] INTERNET-DRAFT 26 November 1996 tunnel medium (X.25, ATM, Frame Relay, IP) and the address of the remote tunnel endpoint. During accounting, the new attributes allow the NAS to provide the RADIUS server with these same attributes, as well as the tunnel client address and Connection Identifier. Together the Connection Identifier and tunnel client and endpoint addresses uniquely identify the call, and allow linking of the RADIUS server and tunnel server accounting records. 5.3. Telephone-number based authentication and accounting 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 (with or without a userID/password combination), or to select the tunnel type, tunnel medium, or tunnel endpoint address based on the calling or called phone number. Similarly, the tunnel server may choose to reject or accept the call based on the Dialed Number and Dialing Number included in the 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/or Called-Station-ID. 6. Alternatives for implementation of mandatory tunneling There are several alternatives for integration of RADIUS and tunnel- ing: Authenticate at the NAS Authenticate at the NAS, and forward the RADIUS reply Authenticate at the tunnel network server Authenticate at both the NAS and the tunnel network server We discuss each of these alternatives in turn. 6.1. Authenticate at the NAS 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 network server trust the NAS, since no user authentication occurs on the tunnel network server end of the tunnel. Another disadvantage is that this does not allow LCP parameters to be re-negotiated by the tunnel network server. Also, due to the lack of user authentication, accounting cannot take place at the tunnel network server with strong assurance that the correct party is being billed. Aboba & Zorn [Page 6] INTERNET-DRAFT 26 November 1996 6.2. Authenticate at the NAS, and forward the RADIUS reply With this approach, authentication and authorization occurs once, at the NAS end of the tunnel and the RADIUS reply is forwarded to the tunnel network server. This approach disallows network access for unauthorized NAS users; does not require trust between the NAS and tunnel network server ends of the tunnel; 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's the only way that the tunnel network server could check the RADIUS reply. Also, the tunnel network server must share secrets with all the NASes and associated RADIUS servers. Other disadvantages include lack of provision for LCP renegotiation by the tunnel network server; and the tunnel network server must know how to handle and ver- ify RADIUS Access-Accept messages. While this scheme may 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. 6.3. Authenticate at the tunnel network server In this scheme, authentication and authorization occurs once at the tunnel network server. This requires that the NAS determine that the user needs to be tunneled (through a RADIUS request, manual configura- tion, etc.). Since the RADIUS specification [3] requires that either a CHAP or PAP password be present in an Access-Request message, but doesn't require that it be non-empty, this scheme probably requires either attribute-specific processing on the RADIUS server, or addition of a new "Authorize-Only" RADIUS message. In attribute-specific processing an attribute is used to signal tunnel initiation. For example, tunnel attributes can be sent back if the PAP password is empty (or "tunnel" or "L2TP"). Alternatively, a user could prefix his NAI with some special character ('*') if he wanted to be tunneled. This particular solution does not support compulsory tun- neling. Another solution involves keying on the domain portion of the NAI; all users in domain 'X' would be tunneled to address 'Y'. This proposal supports compulsory tunneling, but does not provide for per- user tunneling. An Authorize-Only message would not include a CHAP or PAP password; nevertheless, in response the RADIUS server would return the attribute list. In order to prevent password guessing attacks, an Authorize-Only message would need to be authenticated via the RADIUS shared secret. This could be accomplished by adding a field within the Authorization- Only message for an MD5 hash over the contents of the message (with the authenticator field set to zero) and the shared secret. Note that when either attribute-specific processing or authorization- only messages are used, the tunnel network server would need to rene- gotiate LCP. Note also that in order for the NAS to start accounting on the connection, it would need to use the identity claimed by the Aboba & Zorn [Page 7] INTERNET-DRAFT 26 November 1996 user in authenticating to the tunnel network 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. Without putting in place a public key infrastructure, it is not clear how the NAS would be able to verify the existence of such a business relationship in a scalable manner. Thus this approach nulli- fies many of the benefits of roaming. 6.4. Authenticate at both the NAS and the tunnel network server In this scheme, authentication occurs both at the NAS and the tunnel network server. This requires the dial-up PPP peer to handle dual authentications, 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 this scheme are that it allows secure authentication and accounting at both ends of the tunnel; allows the use of a single userID/password pair via implementation of RADIUS on the tunnel net- work server; and does not require attribute-specific processing or addition of an Authorize-Only message on the RADIUS server. This scheme allows for accounting records to be generated on both the NAS and tunnel server ends allowing for auditing. Also, in contrast to the previous scheme, the tunnel endpoint does not need to have an account relationship with the NAS owner. Thus this scheme is compatible with roaming. Disadvantages are that LCP must be renegotiated, and that dual authentications are required. Considering all the advantages and disadvantages of the various schemes, we believe that this scheme is the best choice, and as a result, the rest of this document focuses on the dual authentication scheme. 7. Initiation Sequence The provisioning of a mandatory tunnel involves an interaction between the client, NAS, Tunnel Server, and RADIUS server. The following events occur in initiation of the connection: Client and NAS: PPP LCP negotiation Client and NAS: PPP authentication NAS to RADIUS Server: RADIUS Access-request RADIUS server to NAS: RADIUS Access-reply/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 Client and Tunnel Server: PPP re-authentication Tunnel Server to RADIUS Server: RADIUS Access-request (optional) Aboba & Zorn [Page 8] INTERNET-DRAFT 26 November 1996 RADIUS server to Tunnel Server: RADIUS Access-reply/Access-Reject Client and Tunnel Server: IPCP negotiation NAS to RADIUS Server: RADIUS Accounting-Request/START RADIUS Server to NAS: RADIUS Accounting-Reply Tunnel Server to RADIUS Server: RADIUS Accounting-Request/START (Optional) RADIUS Server to Tunnel Server: RADIUS Accounting-Reply 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-Reply indicating a ACK and including the following attributes: the tunnel type (L2F, PPTP, L2TP), tunnel medium type (X.25, ATM, Frame Relay, IP), and the address of the remote tun- nel endpoint. It is possible that RADIUS proxies may be used to forward the Access- Reply message from the RADIUS server to the NAS. In order to ensure that the mandatory tunnel attributes arrive without modification, RADIUS proxies present in the path MUST NOT modify these attributes in any way. Since this is a mandatory tunnel, address assignment will be 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 IPCP negotiation, since this could create a time window in which the client will be capable of sending packets to the Inter- net, which is not permitted under mandatory tunneling. If the authentication is unsuccessful, the RADIUS server sends a RADIUS Access-Reply indicating a NAK. In this case, the NAS MUST dis- connect the user. The NAS will now bring up a control connection to the tunnel server if none existed before. This is accomplished by sending a PPTP/L2TP Start-Control-Connection-Request message to the tunnel server. The tunnel server replies 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 disconnect the user. The NAS will then proceed to send a 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 IP addresses of the NAS and tunnel server, 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 disconnect the user. The NAS then replies with an Incoming-Call-Connected message. At this point, data begins to flow through the tunnel, and the client and tunnel server must renegotiate LCP and go through another round of PPP authentication. At the time that this renegotiation begins, the client and NAS should have concluded LCP negotiation, but must not have begun IPCP negotiation. When LCP negotiation has been concluded, Aboba & Zorn [Page 9] INTERNET-DRAFT 26 November 1996 the IPCP phase will begin, and the tunnel server will assign an IP address to the client. In performing the PPP authentication, the tunnel server may access its own user database, or it may issue a RADIUS Access-Request to a RADIUS server. 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 server and tunnel server 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 a means for unifying user administration. Other meth- ods are also available, such as use of LDAP. Note that the tunnel server's RADIUS Access-Request is typically sent directly to the local RADIUS server rather than being forwarded via the authentication rout- ing procedure described in [8]. After the tunnel has been brought up, the NAS and tunnel server may start accounting. In the case of the NAS, this is done by sending a RADIUS Accounting-Request/START packet to the RADIUS server. The Accounting-Request packet MUST include the following attributes: Tun- nel-Type, Tunnel-Medium-Type, Tunnel-Client-Endpoint, Tunnel-Server- Endpoint, and Connection-Identifier. The tunnel server may produce its own accounting records, or it may send a RADIUS Accounting-Request/START packet to a local RADIUS server. In the latter case, the RADIUS Accounting-Request/START packet MUST contain the following attributes: Tunnel-Type, Tunnel-Medium- Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Connection- Identifier. The interactions involved in initiation of a mandatory tunnel are sum- marized below. In order to simplify the diagram that follows, we have left out the client. However, it should be understood that the client participates via PPP negotiation, authentication and subsequent data interchange with the Tunnel Server. INITIATION SEQUENCE NAS Tunnel Server RADIUS Server --- ------------- ------------- Call accepted LCP starts PPP authentication phase starts Send RADIUS Access-Request with username and authentication data IF authentication succeeds Send ACK with Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Server-Endpoint Aboba & Zorn [Page 10] INTERNET-DRAFT 26 November 1996 ELSE Send NAK IF NAK DISCONNECT ELSE IF no control connection exists Send Start-Control-Connection-Request message 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 (optional) Send RADIUS Accounting-Reply Send a RADIUS Accounting-Request message with Acct-Status-Type set to Start, containing Tunnel-Type, Tunnel-Medium-Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Connection-Identifier. Send RADIUS Accounting-Reply ENDIF 8. Termination Sequence As with initiation, the tear down of a mandatory tunnel involves an interaction between the client, NAS, Tunnel Server, and RADIUS server. The following events occur in termination of the connection: 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/STOP Aboba & Zorn [Page 11] INTERNET-DRAFT 26 November 1996 RADIUS Server to NAS: RADIUS Accounting-Reply Tunnel Server to RADIUS Server: RADIUS Accounting-Request/STOP (Optional) RADIUS Server to Tunnel Server: RADIUS Accounting-Reply Tunnel termination may occur due to a client request (PPP termina- tion), a tunnel server request (Call-Clear-Request), or a telco issue (call disconnect). In the case of a client-requested termination, the tunnel server will terminate the PPP session. The tunnel server will subsequently send a Call-Clear-Request to the NAS. The NAS will then send a Call- Disconnect-Notify message to the tunnel server, and will disconnect the call. The NAS will 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 telco issue or user hangup, the NAS will send a Call- Disconnect-Notify to the tunnel server. Both sides will then tear down the call. After call tear down is complete, the NAS and tunnel server may stop accounting. In the case of the NAS, this is done by sending a RADIUS Accounting-Request/STOP packet to the RADIUS server. The Accounting- Request packet MUST include the following attributes: Tunnel-Type, Tunnel-Medium-Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Connection-Identifier. The tunnel server may produce its own accounting records, or it may send a RADIUS Accounting-Request/STOP packet to a local RADIUS server. In the latter case, the RADIUS Accounting-Request/STOP packet MUST contain the following attributes: Tunnel-Type, Tunnel-Medium-Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Connection- Identifier. The interactions involved in termination of a mandatory tunnel are summarized below. In order to simplify the diagram that follows, we have left out the client. However, it should be understood that the client participates via PPP termination and disconnection. TERMINATION SEQUENCE NAS Tunnel Server RADIUS Server --- ------------- ------------- IF user disconnected send Call-Disconnect-Notify message to tunnel server Tear down the call stop accounting Send RADIUS Accounting-Request/STOP message (optional) Aboba & Zorn [Page 12] INTERNET-DRAFT 26 November 1996 Send RADIUS Accounting-Reply 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/STOP message (optional) Send RADIUS Accounting-Reply Send a RADIUS Accounting-Request message with Acct-Status-Type set to Stop, containing Tunnel-Type, Tunnel-Medium-Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Connection-Identifier. Send RADIUS Accounting-Reply ENDIF 9. 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 mandatory tunnels. 9.1. Distinct userIDs If distinct RADIUS servers are being used, it is likely that two dis- tinct userID/password pairs will be required to complete the RADIUS and tunnel authentications. One pair will be used in the initial PPP authentication, and the second pair will be used for the tunnel authentication. 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. Aboba & Zorn [Page 13] INTERNET-DRAFT 26 November 1996 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. 9.2. Multilink PPP issues It is possible for the two RADIUS servers to return distinct MAX CHAN- NEL attributes. For example, it is conceivable that the NAS RADIUS server will only grant use of a single channel to the user, 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 dual channels, but that the tunnel RADIUS server will only allow a single channel. In this case, the client should ter- minate use of the second channel. 10. 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. 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 has emerged. To head off this conflict, we must come to agreement on the syntax and semantics expected from the userID. This convergence must be achieved to allow for use of mandatory tunneling in roaming or shared network situations. 10.1. UserID convergence in per-user tunneling Among other things, the use of RADIUS in provisioning of mandatory tunneling relieves the userID from having to do double duty. Rather than being used both for routing of the RADIUS authentica- tion/authorization request as well for determination of the tunnel Aboba & Zorn [Page 14] INTERNET-DRAFT 26 November 1996 endpoint, the userID is now used solely for routing of RADIUS authen- tication/authorization requests. The response to that request is in turn used to determine the tunnel endpoint. In fact, in per-user tunneling the userID and password submitted to RADIUS need not even be valid at the tunnel endpoint. In proposals [5] and [6] after the user is granted access to the NAS, an attempt is made to bring up a tunnel using the userID and password submitted by the user. However, if this userID and password is not valid on the tunnel endpoint, the user will then be asked to submit another userID and password. Thus it is not required that the user maintain the same userID and password both for his ISP and tunnel endpoint. Since the framework provided in [7] allows both ISPs and tunnel users to authenticate users as well as account for resources consumed by them, and provides for maintenance of two distinct userID/password pairs, it is believed that this scheme offers the maximum degree of flexibility. However, in a great number of situations, it is highly desirable for the user to only have to remember a single userID and password. This is made possible by the joint implementation of RADIUS authentication routing and tunneling. How will this work in practice? Typically the user will login with a userID of the form userID [@ | : | / ] domain. Examples: fred@bigco.com, fred:bigco.com, fred/bigco.com. Let us assume that user Fred logs in to a NAS using his corporate account, fred@bigco.com, and wishes to access BIGCO's Intranet. Through a process described in [8], the RADIUS access-request is routed to BIGCO's RADIUS server, which then returns tunnel attributes in the RADIUS access-reply. After it receives the tunnel attributes, the NAS will attempt to open a tunnel to the tunnel server specified in the RADIUS access-reply, using the specified tunnel-type and tunnel-media. Fred's client will then attempt to authenticate against the tunnel server, with the userID fred@bigco.com, and the original password. Assuming that BIGCO's RADIUS and tunnel server go against the same user database, then this authentication will succeed. This can be accomplished by having the tunnel server act as a RADIUS client, as described previ- ously. 11. Acknowledgements Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions of this problem space. 12. References [1] B. Aboba, L. Liu, J. Alsop, J. Ding. "Review of Roaming Imple- mentations." draft-ietf-roamops-imprev-00.txt, Microsoft, Aimnet, i- Pass Alliance, Asiainfo, September, 1996. Aboba & Zorn [Page 15] INTERNET-DRAFT 26 November 1996 [2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." draft-ietf- roamops-roamreq-00.txt, Microsoft, October, 1996. [3] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authen- tication Dial In User Service (RADIUS)." draft-ietf-radius- radius-05.txt, Livingston, Merit, Daydreamer, July 1996. [4] C. Rigney. "RADIUS Accounting." draft-ietf-radius- accounting-05.txt, Livingston, July 1996. [5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." draft- ietf-pppext-l2tp-00.txt, Ascend Communications, August, 1996. [6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, J. Taarud, W. A. Little. "Point-to-Point Tunneling Protocol -- PPTP." draft-ietf- pppext-pptp-00.txt, Ascend Communications, June, 1996. [7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." draft- zorn-radius-tunnel-auth-00.txt, Microsoft Corporation, October, 1996. [8] B. Aboba. "The Network Access Identifier and Authentication Rout- ing." draft-ietf-roamops-nai-00.txt, Microsoft Corporation, November, 1996. 13. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-703-1559 EMail: glennz@microsoft.com Aboba & Zorn [Page 16]