idnits 2.17.1 draft-ietf-radius-tunnel-imp-07.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 301 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 506 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... its worki...' == Line 18 has weird spacing: '... and may ...' == Line 19 has weird spacing: '...afts as refer...' == Line 22 has weird spacing: '... To learn...' == (296 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 May 1998) is 9468 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1007, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1049, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '1') == Outdated reference: A later version (-10) exists of draft-ietf-roamops-roamreq-09 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-roamreq (ref. '2') ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-10 == Outdated reference: A later version (-10) exists of draft-ietf-pppext-pptp-02 ** Downref: Normative reference to an Informational draft: draft-ietf-pppext-pptp (ref. '6') == Outdated reference: A later version (-08) exists of draft-ietf-radius-tunnel-auth-05 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-auth (ref. '7') == Outdated reference: A later version (-12) exists of draft-ietf-roamops-nai-10 == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-01 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '10') -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2284 (ref. '12') (Obsoleted by RFC 3748) == Outdated reference: A later version (-04) exists of draft-ietf-radius-tunnel-acct-00 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-acct (ref. '13') Summary: 22 errors (**), 0 flaws (~~), 20 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Standards Track Glen Zorn 5 Microsoft 6 18 May 1998 8 Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as and expires December 1, 1998. Please 29 send comments to the authors. 31 2. Abstract 33 This document discusses implementation issues arising in the provi- 34 sioning of compulsory tunneling in dial-up networks using the PPTP and 35 L2TP protocols. This provisioning can be accomplished via the inte- 36 gration of RADIUS and tunneling protocols. Implementation issues 37 encountered with other tunneling protocols are left to separate docu- 38 ments. 40 3. Terminology 42 Voluntary Tunneling 43 In voluntary tunneling, a tunnel is created by the user, 44 typically via use of a tunneling client. 46 Compulsory Tunneling 47 In compulsory tunneling, a tunnel is created without any 48 action from the user and without allowing the user any 49 choice. 51 Roaming "Roaming capability" can be loosely defined as the ability 52 to use any one of multiple Internet service providers 53 (ISPs), while maintaining a formal, customer-vendor rela- 54 tionship with only one. Examples of cases where roaming 55 capaility might be required include ISP "confederations" and 56 ISP-provided corporate network access support. 58 Shared Use Network 59 This is an IP dialup network whose use is shared by two or 60 more organizations. Shared use networks typically implement 61 distributed authentication and accounting in order to facil- 62 itate the relationship among the sharing parties. Since 63 these facilities are also required for implementation of 64 roaming, implementation of shared use is frequently a first 65 step toward development of roaming capabilities. In fact, 66 one of the ways by which a provider can offer roaming ser- 67 vice is to conclude shared use agreements with multiple net- 68 works. However, to date the ability to accomplish this has 69 been hampered by lack of interoperability among shared use 70 implementations. 72 Tunnel Network Server 73 This is a server which terminates a tunnel. In PPTP termi- 74 nology, this is known as the PPTP Network Server (PNS). In 75 L2TP terminology, this is known as the L2TP Network Server 76 (LNS). 78 Network Access Server 79 The Network Access Server (NAS) is the device that clients 80 contact in order to get access to the network. In PPTP ter- 81 minology this is referred to as the PPTP Access Concentrator 82 (PAC). In L2TP terminology, the NAS is referred to as the 83 L2TP Access Concentrator (LAC). 85 RADIUS server 86 This is a server which provides for authentication/autho- 87 rization via the protocol described in [3], and for account- 88 ing as described in [4]. 90 RADIUS proxy 91 In order to provide for the routing of RADIUS authentication 92 and accounting requests, a RADIUS proxy can be employed. To 93 the NAS, the RADIUS proxy appears to act as a RADIUS server, 94 and to the RADIUS server, the proxy appears to act as a 95 RADIUS client. 97 Network Access Identifier 98 In order to provide for the routing of RADIUS authentication 99 and accounting requests, the userID field used in PPP and in 100 the subsequent RADIUS authentication and accounting 101 requests, known as the Network Access Identifier (NAI) MAY 102 contain structure. This structure provides a means by which 103 the RADIUS proxy will locate the RADIUS server that is to 104 receive the request. This same structure MAY also be used to 105 locate the tunnel endpoint when domain-based tunneling is 106 used. 108 4. Requirements language 110 In this document, the key words "MAY", "MUST, "MUST NOT", 111 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 112 interpreted as described in [9]. 114 5. Introduction 116 Many applications of tunneling protocols involve dial-up network 117 access. Some, such as the provisioning of secure access to corporate 118 intranets via the Internet, are characterized by voluntary tunneling: 119 the tunnel is created at the request of the user for a specific pur- 120 pose. Other applications involve compulsory tunneling: the tunnel is 121 created without any action from the user and without allowing the user 122 any choice. 124 Examples of applications that might be implemented using compulsory 125 tunnels are Internet software upgrade servers, software registration 126 servers and banking services. These are all services which, without 127 compulsory tunneling, would probably be provided using dedicated net- 128 works or at least dedicated network access servers (NAS), since they 129 are characterized by the need to limit user access to specific hosts. 131 Given the existence of widespread support for compulsory tunneling, 132 however, these types of services could be accessed via any Internet 133 service provider (ISP). The most popular means of authorizing dial-up 134 network users today is through the RADIUS protocol. The use of 135 RADIUS allows the dial-up users' authorization and authentication data 136 to be maintained in a central location, rather than on each NAS. It 137 makes sense to use RADIUS to centrally administer compulsory tun- 138 neling, since RADIUS is widely deployed and was designed to 139 carry this type of information. New RADIUS attributes are needed to 140 carry the tunneling information from the RADIUS server to the NAS 141 and to transfer accounting data from the NAS to the RADIUS accounting 142 server; those attributes are defined in [7] and [13]. 144 5.1. Advantanges of RADIUS-based compulsory tunneling 146 The use of RADIUS in provisioning of compulsory tunnels has several 147 advantages. These include: 149 User-based tunneling 150 Auditing capabilities 152 5.1.1. User-based Tunneling 154 Current proposals for routing of tunnel requests include static tun- 155 neling, where all users are automatically tunneled to a given end- 156 point, and realm-based tunneling, where the tunnel endpoint is deter- 157 mined from the realm portion of the userID. User-based tunneling as 158 provided by integration of RADIUS and tunnel protocols offers signifi- 159 cant advantages over both of these approaches. 161 Static tunneling requires dedication of a NAS device to the purpose. 162 In the case of an ISP, this is undesirable because it requires them to 163 dedicate a NAS to tunneling service for a given corporate customer, 164 rather than allowing them to use existing NASes deployed in the field. 165 As a result static tunneling is likely to be costly for deployment of 166 a global service. 168 Realm-based tunneling assumes that all users within a given realm wish 169 to be treated the same way. This limits flexibility in account manage- 170 ment. For example, BIGCO may desire to provide Janet with an account 171 that allows access to both the Internet and the intranet, with Janet's 172 intranet access provided by a tunnel server located in the engineering 173 department. However BIGCO may desire to provide Fred with an account 174 that provides only access to the intranet, with Fred's intranet access 175 provided by a tunnel network server located in the sales department. 176 Such a situation cannot be accommodated with realm-based tunneling, 177 but can be accomodated via user-based tunneling as enabled by the 178 attributes defined in [7]. When deployed in concert with roaming, 179 user-based tunneling offers corporations the ability to provide their 180 users with access to the corporate Intranet on a global basis. 182 5.2. Auditing Capabilities 184 The integration of RADIUS and tunnel protocols allows the ISP and the 185 corporation to synchronize their accounting activities so that each 186 side receives a record of the user's resource consumption. This pro- 187 vides the corporation with the means to audit ISP bills. 189 In auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client-End- 190 point and Tunnel-Server-Endpoint attributes are typically used to 191 uniquely identify the call, allowing the Accounting-Request sent by 192 the NAS to be reconciled with the corresponding Accounting-Request 193 sent by the tunnel server. 195 When implementing L2TP/PPTP tunneling based on RADIUS, the Call- 196 Serial-Number SHOULD be used in the Acct-Tunnel-Connection attribute. 197 In L2TP, the Call-Serial-Number is a 32-bit field and in PPTP it is a 198 16-bit field. As described in [6], in PPTP the combination of IP 199 Address and Call-Serial-Number SHOULD be unique, but this is not 200 required. In addition, no method for determining the Call-Serial-Num- 201 ber is specified, which leaves open the possibility of wrapping after 202 a reboot. 204 Note that a 16-bit Call-Serial-Number is not sufficient to distinguish 205 a given call from all other calls over an extended time period. For 206 example, if the Call-Serial-Number is assigned monotonically, the NAS 207 in question has 96 ports which are continually busy and the average 208 call is of 20 minutes duration, then a 16-bit Call-Serial-Number will 209 wrap within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.48 days. 211 6. Authentication alternatives 213 RADIUS-based compulsory tunneling can support both single authentica- 214 tion, where the user is authenticated at the NAS or tunnel server, or 215 dual authentication, where the user is authenticated at both the NAS 216 and the tunnel server. When single authentication is supported, a 217 variety of modes are possible, including telephone-number based 218 authentication. When dual-authentication is used, a number of modes 219 are available, including dual CHAP authentications; CHAP/EAP authenti- 220 cation; CHAP/PAP(token) authentication; and EAP/EAP authentication, 221 using the same EAP type for both authentications. 223 The alternatives are described in more detail below. 225 6.1. Single authentication 227 Single authentication alternatives include: 229 NAS authentication 230 NAS authentication with RADIUS reply forwarding 231 Tunnel server authentication 233 6.1.1. NAS authentication 235 With this approach, authentication and authorization (including tun- 236 neling information) occurs once, at the NAS. The advantages of this 237 approach are that it disallows network access for unauthorized NAS 238 users, and allows RADIUS accounting to be used at the NAS. Disadvan- 239 tages are that it requires that the tunnel server trust the NAS, since 240 no user authentication occurs at the tunnel server. Due to the lack of 241 user authentication, accounting cannot take place at the tunnel server 242 with strong assurance that the correct party is being billed. 244 NAS-only authentication is most typically employed along with LCP for- 245 warding and tunnel authentication, both of which are supported in 246 L2TP, described in [5]. Thus, the tunnel server can be set up to 247 accept all calls occurring within authenticated tunnels, without 248 requiring PPP authentication. This approach is not compatible with 249 roaming, since the tunnel server will typically only be set up to 250 accept tunnels from a restricted set of NASes. A typical initiation 251 sequence looks like this: 253 Client and NAS: Call Connected 254 Client and NAS: PPP LCP negotiation 255 Client and NAS: PPP authentication 256 NAS to RADIUS Server: RADIUS Access-request 257 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 258 NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding 259 Tunnel Server to NAS: L2TP Incoming-Call-Reply 260 NAS to Tunnel Server: L2TP Incoming-Call-Connected 261 Client and Tunnel Server: NCP negotiation 262 NAS to RADIUS Server: RADIUS Accounting-Request with 263 Acct-Status-Type=Tunnel-Link-Start 264 RADIUS Server to NAS: RADIUS Accounting-Response 266 The process begins with an incoming call to the NAS, and the PPP LCP 267 negotiation between the client and the NAS. In order to authenticate 268 the client, the NAS will send a RADIUS Access-Request to the RADIUS 269 server and will receive a RADIUS Access-Accept including tunnel 270 attributes, or an Access-Reject. 272 In the case where an L2TP tunnel is indicated, the NAS will now bring 273 up a control connection if none existed before, and the NAS and tunnel 274 server will bring up the call. At this point, data will begin to flow 275 through the tunnel. The NAS will typically employ LCP forwarding, 276 although it is also possible for the tunnel server to renegotiate LCP. 277 If LCP renegotiation is to be permitted, the NAS SHOULD NOT send an 278 LCP CONFACK completing LCP negotiation. Rather than sending an LCP 279 CONFACK, the NAS will instead send an LCP DOWN message. The Client MAY 280 then renegotiate LCP, and from that point forward, all PPP packets 281 originated from the client will be encapsulated and sent to the tunnel 282 server. 284 Since address assignment will occur at the tunnel server, the client 285 and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will 286 occur between the client and the tunnel server. 288 6.1.2. NAS authentication with RADIUS reply forwarding 290 With this approach, authentication and authorization occurs once at 291 the NAS and the RADIUS reply is forwarded to the tunnel server. This 292 approach disallows network access for unauthorized NAS users; does not 293 require trust between the NAS and tunnel server; and allows for RADIUS 294 accounting to be used at both ends of the tunnel. However, it also 295 requires that both ends share the same secret with the RADIUS server, 296 since that is the only way that the tunnel server can check the RADIUS 297 reply. 299 In this approach, the tunnel server will share secrets with all the 300 NASes and associated RADIUS servers, and there is no provision for LCP 301 renegotiation by the tunnel server. Also, the tunnel server will need 302 to know how to handle and verify RADIUS Access-Accept messages. 304 While this scheme can be workable if the reply comes directly from a 305 RADIUS server, it would become unmanageable if a RADIUS proxy is 306 involved, since the reply would be authenticated using the secret 307 shared by the client and proxy, rather than the RADIUS server. As a 308 result, this scheme is impractical. 310 6.1.3. Tunnel server authentication 312 In this scheme, authentication and authorization occurs once at the 313 tunnel server. This requires that the NAS determine that the user 314 needs to be tunneled (through RADIUS or NAS configuration). Where 315 RADIUS is used, the determination can be made using one of the follow- 316 ing methods: 318 Telephone-number based authentication 319 User-Name 321 6.1.3.1. Telephone-number based authentication 323 Using the Calling-Station-Id and Called-Station-Id RADIUS attributes, 324 authorization and subsequent tunnel attributes can be based on the 325 phone number originating the call, or the number being called. This 326 allows the RADIUS server to authorize users based on the calling phone 327 number or to provide tunnel attributes based on the Calling-Station-Id 328 or Called-Station-Id. Similarly, in PPTP/L2TP the tunnel server MAY 329 choose to reject or accept the call based on the Dialed Number and 330 Dialing Number included in the PPTP/L2TP Incoming-Call-Request packet 331 sent by the NAS. 333 The use of RADIUS accounting by the NAS and/or the tunnel server 334 allows for accounting to take place based on the Calling-Station-Id 335 and Called-Station-Id. RADIUS as defined in [3] requires that an 336 Access-Request packet contain a User-Name attribute as well as either 337 a CHAP-Password or User-Password attribute, which must be non-empty. 338 To satisfy this requirement the Called-Station-Id or Calling-Station- 339 Id may be furnished in the User-Name attribute and a dummy value may 340 be used in the User-Password or CHAP-Password attribute. 342 In the case of telephone-number based authentication, a typical initi- 343 ation sequence looks like this: 345 Client and NS: Call Connected 346 NAS to RADIUS Server: RADIUS Access-request 347 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 348 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 349 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 350 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 351 Client and Tunnel Server: PPP LCP negotiation 352 Client and Tunnel Server: PPP authentication 353 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 354 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 355 Client and Tunnel Server: NCP negotiation 356 NAS to RADIUS Server: RADIUS Accounting-Request 357 with Acct-Status-Type=Tunnel-Link-Start 358 RADIUS Server to NAS: RADIUS Accounting-Response 359 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 360 with Acct-Status-Type=Tunnel-Link-Start (Optional) 361 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 363 The process begins with an incoming call to the NAS. If configured for 364 telephone-number based authentication, the NAS sends a RADIUS Access- 365 Request containing the Calling-Station-Id and the Called-Station-Id 366 attributes. The RADIUS server will then respond with a RADIUS Access- 367 Accept or Access-Reject. 369 The NAS MUST NOT begin PPP authentication before bringing up the tun- 370 nel. If timing permits, the NAS MAY bring up the tunnel prior to 371 beginning LCP negotiation with the peer. If this is done, then LCP 372 will not need to be renegotiated between the peer and tunnel server, 373 nor will LCP forwarding need to be employed. 375 If the initial telephone-number based authentication is unsuccessful, 376 the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS 377 MUST send an LCP-Terminate and disconnect the user. 379 In the case where tunnel attributes are included in the RADIUS Access- 380 Accept, and a PPTP/L2TP tunnel is indicated, the NAS will now bring up 381 a control connection if none existed before. This is accomplished by 382 sending a PPTP/L2TP Start-Control-Connection-Request message to the 383 tunnel server. The tunnel server will then reply with a PPTP/L2TP 384 Start-Control-Connection-Reply. If this message indicates an error, 385 or if the control connection is terminated at any future time, then 386 the NAS MUST send an LCP-Terminate and disconnect the user. 388 The NAS will then send an PPTP/L2TP Incoming-Call-Request message to 389 the tunnel server. Among other things, this message will contain the 390 Call Serial Number, which along with the NAS-IP-Address and Tunnel- 391 Server-Endpoint is used to uniquely identify the call. The tunnel 392 server will reply with a PPTP/L2TP Incoming-Call-Reply message. If 393 this message indicates an error, then the NAS MUST send an LCP-Termi- 394 nate and disconnect the user. If no error is indicated, the NAS then 395 replies with a PPTP/L2TP Incoming-Call-Connected message. 397 At this point, data MAY begin to flow through the tunnel. If LCP nego- 398 tiation had been begun between the NAS and the client, then LCP for- 399 warding may be employed, or the client and tunnel server will now 400 renegotiate LCP and begin PPP authentication. Otherwise, the client 401 and tunnel server will negotiate LCP for the first time, and then move 402 on to PPP authentication. 404 If a renegotiation is required, at the time that the renegotiation 405 begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP 406 negotiation, and the client and NAS MUST NOT have begun NCP negotia- 407 tion. Rather than sending an LCP CONFACK, the NAS will instead send an 408 LCP DOWN message. The Client MAY then renegotiate LCP, and from that 409 point forward, all PPP packets originated from the client will be 410 encapsulated and sent to the tunnel server. When LCP re-negotiation 411 has been concluded, the NCP phase will begin, and the tunnel server 412 will assign an address to the client. 414 If L2TP is being used as the tunnel protocol, and LCP renegotiation is 415 required, the NAS MAY in its initial setup notification include a copy 416 of the LCP CONFACKs sent in each direction which completed LCP negoti- 417 ation. The tunnel server MAY then use this information to avoid an 418 additional LCP negotiation. With L2TP, the initial setup notification 419 can also include the authentication information required to allow the 420 tunnel server to authenticate the user and decide to accept or decline 421 the connection. However, in telephone-number based authentication, PPP 422 authentication MUST NOT occur prior to the NAS bringing up the tunnel. 423 As a result, L2TP authentication forwarding MUST NOT be employed. 425 In performing the PPP authentication, the tunnel server can access its 426 own user database, or alternatively can send a RADIUS Access-Request. 427 The latter approach is useful in cases where authentication forwarding 428 is enabled, such as with roaming or shared use networks. In this case, 429 the RADIUS and tunnel servers are under the same administration and 430 are typically located close together, possibly on the same LAN. 431 Therefore having the tunnel server act as a RADIUS client provides for 432 unified user administration. Note that the tunnel server's RADIUS 433 Access-Request is typically sent directly to the local RADIUS server 434 rather than being forwarded via a proxy. 436 After the tunnel has been brought up, the NAS and tunnel server will 437 typically start accounting. In the case of the NAS, this is done by 438 sending a RADIUS Accounting-Request packet with Acct-Status-Type=Tun- 439 nel-Start to a RADIUS server. When an individual call is brought up, a 440 RADIUS Accounting-Request packet is sent with Acct-Status-Type=Tunnel- 441 Link-Start. The tunnel server can produce its own accounting records, 442 or it MAY send a RADIUS Accounting-Request packet to a local RADIUS 443 server. 445 The interactions involved in initiation of a compulsory tunnel with 446 telephone-number based authentication are summarized below. In order 447 to simplify the diagram that follows, we have left out the client. 448 However, it is understood that the client participates via PPP negoti- 449 ation, authentication and subsequent data interchange with the Tunnel 450 Server. 452 INITIATION SEQUENCE 454 NAS Tunnel Server RADIUS Server 455 --- ------------- ------------- 456 Call connected 457 Send RADIUS 458 Access-Request 459 with Called-Station-Id, 460 and/or Calling-Station-Id 461 LCP starts 462 IF authentication 463 succeeds 464 Send ACK 465 ELSE Send NAK 466 IF NAK DISCONNECT 467 ELSE 468 IF no control 469 connection exists 470 Send 471 Start-Control-Connection-Request 472 to Tunnel Server 473 Send 474 Start-Control-Connection-Reply 475 to NAS 476 ENDIF 478 Send 479 Incoming-Call-Request 480 message to Tunnel Server 481 Send Incoming-Call-Reply 482 to NAS 483 Send 484 Incoming-Call-Connected 485 message to Tunnel Server 487 Send data through the tunnel 488 Re-negotiate LCP, 489 authenticate user, 490 bring up IPCP, 491 start accounting 492 Send RADIUS 493 Accounting-Request with 494 Acct-Status-Type=Tunnel-Link-Start 495 (optional) 496 Send 497 RADIUS 498 Accounting-Response 499 Send a RADIUS 500 Accounting-Request message 501 with Acct-Status-Type=Tunnel-Link-Start 502 Send 503 RADIUS 504 Accounting-Response 506 6.1.3.2. User-Name 508 Since authentication will occur only at the tunnel-server, tunnel ini- 509 tiation must occur prior to user authentication at the NAS. As a 510 result, this scheme typically uses either the domain portion of the 511 userID or attribute-specific processing on the RADIUS server. Since 512 the user identity is never verified by the NAS, either the tunnel 513 server owner must be willing to be billed for all incoming calls, or 514 other information such as the Calling-Station-Id must be used to ver- 515 ify the user's identity for accounting purposes. 517 In attribute-specific processing RADIUS may be employed and an 518 attribute is used to signal tunnel initiation. For example, tunnel 519 attributes can be sent back if the User-Password attribute contains a 520 dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID 521 beginning with a special character ('*') could be used to indicate the 522 need to initiate a tunnel. When attribute-specific processing is 523 used, the tunnel server may need to renegotiate LCP. 525 Another solution involves using the domain portion of the userID; all 526 users in domain X would be tunneled to address Y. This proposal sup- 527 ports compulsory tunneling, but does not provide for user-based tun- 528 neling. 530 In order for the NAS to start accounting on the connection, it would 531 need to use the identity claimed by the user in authenticating to the 532 tunnel server, since it did not verify the identity via RADIUS. How- 533 ever, in order for that to be of any use in accounting, the tunnel 534 endpoint needs to have an account relationship with the NAS owner. 535 Thus even if a user has an account with the NAS owner, they cannot use 536 this account for tunneling unless the tunnel endpoint also has a busi- 537 ness relationship with the NAS owner. Thus this approach is incompati- 538 ble with roaming. 540 A typical initiation sequence involving use of the domain portion of 541 the userID looks like this: 543 Client and NAS: Call Connected 544 Client and NAS: PPP LCP negotiation 545 Client and NAS: Authentication 546 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 547 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 548 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 549 Client and Tunnel Server: PPP LCP re-negotiation 550 Client and Tunnel Server: PPP authentication 551 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 552 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 553 Client and Tunnel Server: NCP negotiation 554 NAS to RADIUS Server: RADIUS Accounting-Request 555 with Acct-Status-Type=Tunnel-Link-Start 556 RADIUS Server to NAS: RADIUS Accounting-Response 557 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 558 with Acct-Status-Type=Tunnel-Link-Start (Optional) 559 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 561 The process begins with an incoming call to the NAS, and the PPP LCP 562 negotiation between the Client and NAS. The authentication process 563 will then begin and based on the domain portion of the userID, the NAS 564 will now bring up a control connection if none existed before, and the 565 NAS and tunnel server will bring up the call. At this point, data MAY 566 begin to flow through the tunnel. The client and tunnel server MAY 567 now renegotiate LCP and will complete PPP authentication. 569 At the time that the renegotiation begins, the NAS SHOULD NOT have 570 sent an LCP CONFACK completing LCP negotiation, and the client and NAS 571 MUST NOT have begun NCP negotiation. Rather than sending an LCP CON- 572 FACK, the NAS will instead send an LCP DOWN message. The Client MAY 573 then renegotiate LCP, and from that point forward, all PPP packets 574 originated from the client will be encapsulated and sent to the tunnel 575 server. In single authentication compulsory tunneling, L2TP authenti- 576 cation forwarding MUST NOT be employed. When LCP re-negotiation has 577 been concluded, the NCP phase will begin, and the tunnel server will 578 assign an address to the client. 580 In performing the PPP authentication, the tunnel server can access its 581 own user database, or it MAY send a RADIUS Access-Request. After the 582 tunnel has been brought up, the NAS and tunnel server MAY start 583 accounting. 585 The interactions are summarized below. 587 INITIATION SEQUENCE 589 NAS Tunnel Server RADIUS Server 590 --- ------------- ------------- 591 Call accepted 592 LCP starts 593 Authentication 594 phase starts 595 IF no control 596 connection exists 597 Send 598 Start-Control-Connection-Request 599 to Tunnel Server 600 ENDIF 601 IF no control 602 connection exists 603 Send 604 Start-Control-Connection-Reply 605 to NAS 606 ENDIF 608 Send 609 Incoming-Call-Request 610 message to Tunnel Server 611 Send Incoming-Call-Reply 612 to NAS 613 Send 614 Incoming-Call-Connected 615 message to Tunnel Server 617 Send data through the tunnel 618 Re-negotiate LCP, 619 authenticate user, 620 bring up IPCP, 621 start accounting 622 Send RADIUS 623 Accounting-Request with 624 Acct-Status-Type=Tunnel-Link-Start 625 (optional) 626 Send 627 RADIUS 628 Accounting-Response 629 Send a RADIUS 630 Accounting-Request message 631 with Acct-Status-Type=Tunnel-Link-Start 632 Send 633 RADIUS 634 Accounting-Response 636 6.2. Dual authentication 638 In this scheme, authentication occurs both at the NAS and the tunnel 639 server. This requires the dial-up client to handle dual authentica- 640 tion, with attendant LCP re-negotiations. In order to allow the NAS 641 and tunnel network server to authenticate against the same database, 642 this requires RADIUS client capability on the tunnel network server, 643 and possibly a RADIUS proxy on the NAS end. 645 Advantages of dual authentication include support for authentication 646 and accounting at both ends of the tunnel; use of a single 647 userID/password pair via implementation of RADIUS on the tunnel net- 648 work server; no requirement for telephone-number based authentication, 649 or attribute-specific processing on the RADIUS server. 651 Dual authentication allows for accounting records to be generated on 652 both the NAS and tunnel server ends, making auditing possible. Also 653 the tunnel endpoint does not need to have an account relationship with 654 the NAS owner, making this approach compatible with roaming. 656 A disadvantage of dual authentication is that unless LCP forwarding is 657 used, LCP will need to be renegotiated; some clients do not support it 658 at all, and others only support only a subset of the dual authentica- 659 tion combinations. Feasible combinations include PAP/PAP(token), 660 PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, CHAP/EAP, EAP/CHAP, and 661 EAP/EAP. 663 In the case of a dual authentication, a typical initiation sequence 664 looks like this: 666 Client and NAS: PPP LCP negotiation 667 Client and NAS: PPP authentication 668 NAS to RADIUS Server: RADIUS Access-request 669 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 670 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 671 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 672 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 673 Client and Tunnel Server: PPP LCP re-negotiation (optional) 674 Client and Tunnel Server: PPP authentication 675 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 676 RADIUS server to Tunel Server: RADIUS Access-Accept/Access-Reject 677 Client and Tunnel Server: NCP negotiation 678 NAS to RADIUS Server: RADIUS Accounting-Request 679 with Acct-Status-Type=Tunnel-Link-Start 680 RADIUS Server to NAS: RADIUS Accounting-Response 681 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 682 with Acct-Status-Type=Tunnel-Link-Start (Optional) 683 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 685 The process begins with an incoming call to the NAS. The client and 686 NAS then begin LCP negotiation. Subsequently the PPP authentication 687 phase starts, and the NAS sends a RADIUS Access-Request message to the 688 RADIUS server. If the authentication is successful, the RADIUS server 689 responds with a RADIUS Access-Accept containing tunnel attributes. 691 In the case where a PPTP/L2TP tunnel is indicated, the NAS will now 692 bring up a control connection if none existed before, and the NAS and 693 tunnel server will bring up the call. At this point, data MAY begin to 694 flow through the tunnel. The client and tunnel server MAY now renego- 695 tiate LCP and go through another round of PPP authentication. At the 696 time that this renegotiation begins, the NAS SHOULD NOT have sent an 697 LCP CONFACK completing LCP negotiation, and the client and NAS MUST 698 NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, 699 the NAS will instead send an LCP DOWN message. The Client MAY then 700 renegotiate LCP, and from that point forward, all PPP packets origi- 701 nated from the client will be encapsulated and sent to the tunnel 702 server. When LCP re-negotiation has been concluded, the NCP phase 703 will begin, and the tunnel server will assign an address to the 704 client. 706 If L2TP is being used as the tunnel protocol, the NAS MAY in its ini- 707 tial setup notification include a copy of the LCP CONFACKs sent in 708 each direction which completed LCP negotiation. The tunnel server MAY 709 then use this information to avoid an additional LCP negotiation. With 710 L2TP, the initial setup notification can also include the authentica- 711 tion information required to allow the tunnel server to authenticate 712 the user and decide to accept or decline the connection. However, this 713 facility creates a vulnerability to replay attacks, and can create 714 problems in the case where the NAS and tunnel server authenticate 715 against different RADIUS servers. As a result, where user-based tun- 716 neling via RADIUS is implemented, L2TP authentication forwarding 717 SHOULD NOT be employed. 719 In performing the PPP authentication, the tunnel server can access its 720 own user database, or it MAY send a RADIUS Access-Request. After the 721 tunnel has been brought up, the NAS and tunnel server MAY start 722 accounting. 724 The interactions involved in initiation of a compulsory tunnel with 725 dual authentication are summarized below. 727 INITIATION SEQUENCE 729 NAS Tunnel Server RADIUS Server 730 --- ------------- ------------- 731 Call accepted 732 LCP starts 733 PPP authentication 734 phase starts 735 Send RADIUS 736 Access-Request 737 with username and 738 authentication data 739 IF authentication 740 succeeds 741 Send ACK 742 ELSE Send NAK 743 IF NAK DISCONNECT 744 ELSE 745 IF no control 746 connection exists 747 Send 748 Start-Control-Connection-Request 749 to Tunnel Server 750 Send 751 Start-Control-Connection-Reply 752 to NAS 753 ENDIF 755 Send 756 Incoming-Call-Request 757 message to Tunnel Server 758 Send Incoming-Call-Reply 759 to NAS 760 Send 761 Incoming-Call-Connected 762 message to Tunnel Server 764 Send data through the tunnel 765 Re-negotiate LCP, 766 authenticate user, 767 bring up IPCP, 768 start accounting 769 Send RADIUS 770 Accounting-Request with 771 Acct-Status-Type=Tunnel-Link-Start 772 (optional) 773 Send 774 RADIUS 775 Accounting-Response 776 Send a RADIUS 777 Accounting-Request message 778 with Acct-Status-Type=Tunnel-Link-Start 779 Send 780 RADIUS 781 Accounting-Response 783 ENDIF 784 7. Termination sequence 786 The tear down of a compulsory tunnel involves an interaction between 787 the client, NAS, Tunnel Server, and RADIUS Accounting server. This 788 interaction is virtually identical regardless of whether telephone- 789 number based authentication, single authentication, or dual authenti- 790 cation is being used. In any of the cases, the following events 791 occur: 793 Tunnel Server to NAS: PPTP/L2TP Call-Clear-Request (optional) 794 NAS to Tunnel Server: PPTP/L2TP Call-Disconnect-Notify 795 NAS to RADIUS Server: RADIUS Accounting-Request 796 with Acct-Status-Type=Tunnel-Link-Stop 797 RADIUS Server to NAS: RADIUS Accounting-Response 798 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 799 with Acct-Status-Type=Tunnel-Link-Stop (Optional) 800 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 802 Tunnel termination can occur due to a client request (PPP termina- 803 tion), a tunnel server request (Call-Clear-Request), or a line problem 804 (call disconnect). 806 In the case of a client-requested termination, the tunnel server MUST 807 terminate the PPP session. The tunnel server MUST subsequently send a 808 Call-Clear-Request to the NAS. The NAS MUST then send a Call-Discon- 809 nect-Notify message to the tunnel server, and will disconnect the 810 call. 812 The NAS MUST also respond with a Call-Disconnect-Notify message and 813 disconnection if it receives a Call-Clear-Request from the tunnel 814 server without a client-requested termination. 816 In the case of a line problem or user hangup, the NAS MUST send a 817 Call-Disconnect-Notify to the tunnel server. Both sides will then tear 818 down the call. 820 After call tear down is complete, if RADIUS accounting is being used 821 then the NAS MUST send a RADIUS Accounting-Request with Acct-Status- 822 Type=Tunnel-Link-Stop packet to a RADIUS accounting server. 824 The tunnel server MAY produce its own accounting records, or it MAY 825 use RADIUS accounting. If RADIUS accounting is being used then the 826 tunnel server MUST send a RADIUS Accounting-Request with Acct-Status- 827 Type=Tunnel-Link-Stop to a RADIUS accounting server. 829 The interactions involved in termination of a compulsory tunnel are 830 summarized below. In order to simplify the diagram that follows, we 831 have left out the client. However, it is understood that the client 832 MAY participate via PPP termination and disconnection. 834 TERMINATION SEQUENCE 836 NAS Tunnel Server RADIUS Server 837 --- ------------- ------------- 838 IF user disconnected 839 send 840 Call-Disconnect-Notify 841 message to tunnel server 842 Tear down the call 843 stop accounting 844 Send RADIUS 845 Accounting-Request with 846 Acct-Status-Type=Tunnel-Link-Stop 847 (optional) 848 Send RADIUS 849 Accounting-Response 850 ELSE IF client requests 851 termination 852 send 853 Call-Clear-Request 854 to the NAS 855 Send 856 Call-Disconnect-Notify 857 message to tunnel server 858 Disconnect the user 859 Tear down the call 860 stop accounting 861 Send RADIUS 862 Accounting-Request with 863 Acct-Status-Type=Tunnel-Link-Stop 864 (optional) 865 Send RADIUS 866 Accounting-Response 868 Send a RADIUS 869 Accounting-Request message 870 with Acct-Status-Type=Tunnel-Link-Stop 871 Send RADIUS 872 Accounting-Response 874 ENDIF 876 8. Use of distinct RADIUS servers 878 In the case that the NAS and the tunnel server are using distinct 879 RADIUS servers, some interesting cases can arise in the provisioning 880 of compulsory tunnels. 882 8.1. Distinct userIDs 884 If distinct RADIUS servers are being used, it is likely that distinct 885 userID/password pairs will be required to complete the RADIUS and tun- 886 nel authentications. One pair will be used in the initial PPP authen- 887 tication with the NAS, and the second pair will be used for authenti- 888 cation at the tunnel server. 890 However, in order to provide maximum ease of use in the case where the 891 userID/password pairs are identical, tunnel clients typically attempt 892 authentication with the same userID/password pair as was used in the 893 initial PPP negotiation. Only after this fails do they prompt the user 894 for the second pair. 896 In this case, tunnel client implementations SHOULD take care not to 897 put up error messages indicating a bad password. Instead a dialog 898 SHOULD be presented requesting the tunnel userID/password combination. 900 In the case where token cards are being used for both authentications, 901 the tunnel client MUST NOT attempt to present the token used in the 902 first authentication during the second authentication, since these 903 will never be identical. Instead the user SHOULD be prompted to enter 904 the second token. 906 The same issue arises in L2TP if the NAS attempts to forward authenti- 907 cation information to the tunnel server in the initial setup notifica- 908 tion. Since the userID/password pair used for tunnel authentication is 909 different from that used to authenticate against the NAS, forwarding 910 authentication information in this manner will cause the tunnel 911 authentication to fail. As a result, where user-based tunneling via 912 RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be 913 employed. 915 8.2. Multilink PPP issues 917 It is possible for the two RADIUS servers to return different Port- 918 Limit attributes. For example, it is conceivable that the NAS RADIUS 919 server will only grant use of a single channel, while the tunnel 920 RADIUS server will grant more than one channel. In this case, the cor- 921 rect behavior is for the tunnel client to open a connection to another 922 NAS in order to bring up a multilink bundle on the tunnel server. The 923 client MUST NOT indicate to the NAS that this additional link is being 924 brought up as part of a multilink bundle; this will only be indicated 925 in the subsequent negotiation with the tunnel server. 927 It is also conceivable that the NAS RADIUS server will allow the 928 client to bring up multiple channels, but that the tunnel RADIUS 929 server will allow fewer channels than the NAS RADIUS server. In this 930 case, the client should terminate use of the excess channels. 932 9. UserID Issues 934 In the provisioning of roaming and shared use networks, one of the 935 requirements is to be able to route the authentication request to the 936 user's home RADIUS server. This authentication routing is accomplished 937 based on the userID submitted by the user to the NAS in the initial 938 PPP authentication. The userID is subsequently relayed by the NAS to 939 the RADIUS server in the User-Name attribute, as part of the RADIUS 940 Access-Request. 942 Similarly, references [5] and [6] refer to use of the userID in deter- 943 mining the tunnel endpoint. However, since none of these references 944 provide guidelines for how RADIUS or tunnel routing is to be accom- 945 plished, the possibility of conflicting interpretations exists. 947 9.1. UserID convergence in user-based tunneling 949 The use of RADIUS in provisioning of compulsory tunneling relieves the 950 userID from having to do double duty. Rather than being used both for 951 routing of the RADIUS authentication/authorization request as well for 952 determination of the tunnel endpoint, the userID is now used solely 953 for routing of RADIUS authentication/authorization requests. Tunnel 954 attributes returned in the RADIUS Access-Response are then used to 955 determine the tunnel endpoint. 957 Since the framework described in this document allows both ISPs and 958 tunnel users to authenticate users as well as to account for resources 959 consumed by them, and provides for maintenance of two distinct 960 userID/password pairs, this scheme provides a high degree of flexibil- 961 ity. Where RADIUS proxies and tunneling are employed, it is possible 962 to allow the user to authenticate with a single userID/password pair 963 at both the NAS and the tunnel endpoint. This is accomplished by rout- 964 ing the NAS RADIUS Access-Request to the same RADIUS server used by 965 the tunnel server. 967 As described in [8], the recommended form for the user ID is 968 userID@realm, i.e. fred@bigco.com. 970 10. Security considerations 972 In compulsory tunneling, PAP authentication SHOULD NOT be used, since 973 this will typically involve transmission of a cleartext password over 974 the Internet. A possible exception is where PAP is used to support a 975 one time password or token. 977 Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS 978 server may be processed by one or more proxies prior to being received 979 by the NAS. In order to ensure that tunnel attributes arrive without 980 modification, intermediate RADIUS proxies forwarding the Access-Reply 981 MUST NOT modify tunnel attributes. If the RADIUS proxy does not sup- 982 port tunnel attributes, then it MUST send an Access-Reject to the NAS. 983 This is necessary to ensure that the user is only granted access if 984 the services requested by the RADIUS server can be provided. 986 Since RADIUS tunnel attributes are used for compulsory tunneling, 987 address assignment is handled by the tunnel server rather than the 988 NAS. As a result, if tunnel attributes are present, the NAS MUST 989 ignore any address assignment attributes sent by the RADIUS server. In 990 addition, the NAS and client MUST NOT begin NCP negotiation, since 991 this could create a time window in which the client will be capable of 992 sending packets to the transport network, which is not permitted in 993 compulsory tunneling. 995 11. Acknowledgements 997 Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions 998 of this problem space, and to Allan Rubens of Ascend and Bertrand 999 Buclin of AT&T Labs Europe for his comments on this document. 1001 12. References 1003 [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming 1004 Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asi- 1005 ainfo, Merit, September 1997. 1007 [2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." Internet draft 1008 (work in progress), draft-ietf-roamops-roamreq-09.txt, Microsoft, 1009 March 1998. 1011 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 1012 cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, 1013 Daydreamer, April 1997. 1015 [4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 1016 1997. 1018 [5] A. Valencia, K. Hamzeh, A. Rubens, T. Kolar, M. Littlewood, W. 1019 Townsley, J. Taarud, G. Pall, B. Palter, W. Verthein. "Layer Two Tun- 1020 neling Protocol L2TP." Internet draft (work in progress), draft-ietf- 1021 pppext-l2tp-10.txt, Ascend Communications, Microsoft, Copper Mountain 1022 Networks, U.S. Robotics, March 1998. 1024 [6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little. 1025 "Point-to-Point Tunneling Protocol -- PPTP." ." Internet draft (work 1026 in progress), draft-ietf-pppext-pptp-02.txt, Ascend Communications, 1027 Microsoft, Copper Mountain Networks, U.S. Robotics, September 1997. 1029 [7] G. Zorn, D. Leifer, A. Rubens, J. Shriver. "RADIUS Attributes for 1030 Tunnel Protocol Support." Internet draft (work in progress), draft- 1031 ietf-radius-tunnel-auth-05.txt, Microsoft, Ascend Communications, 1032 Shiva Corporation, April 1998. 1034 [8] B. Aboba, M. A. Beadles. "The Network Access Identifier." Inter- 1035 net draft (work in progress), draft-ietf-roamops-nai-10.txt, 1036 Microsoft, CompuServe, March 1998. 1038 [9] S. Bradner. "Key words for use in RFCs to Indicate Requirement 1039 Levels." RFC 2119, Harvard University, March, 1997. 1041 [10] C. Rigney, W. Willats. "RADIUS Extensions." Work in 1042 progress, draft-ietf-radius-ext-01.txt, Livingston, June, 1997. 1044 [11] P. Calhoun, A.C. Rubens, B. Aboba. "Extensible Authentication 1045 Protocol Support in RADIUS." Internet draft (work in progress), draft- 1046 ietf-radius-eap-05.txt, Sun Microsystems., Merit Network, Microsoft, 1047 May, 1998. 1049 [12] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Proto- 1050 col (EAP)." RFC 2284, Merit Network, Inc., March 1998. 1052 [13] G. Zorn, D. Mitton. "RADIUS Accounting Modifications for Tunnel 1053 Protocol Support." Internet draft (work in progress), draft-ietf- 1054 radius-tunnel-acct-00.txt, Microsoft, Bay Networks, November 1997. 1056 13. Chair's Address 1058 The RADIUS Working Group can be contacted via the current chair: 1060 Carl Rigney 1061 Livingston Enterprises 1062 4464 Willow Road 1063 Pleasanton, California 94588 1065 Phone: +1 510 426 0770 1066 E-Mail: cdr@livingston.com 1068 14. Authors' Addresses 1070 Bernard Aboba 1071 Microsoft Corporation 1072 One Microsoft Way 1073 Redmond, WA 98052 1075 Phone: +1 425 936 6605 1076 EMail: bernarda@microsoft.com 1078 Glen Zorn 1079 Microsoft Corporation 1080 One Microsoft Way 1081 Redmond, WA 98052 1083 Phone: +1 425 703 1559 1084 EMail: glennz@microsoft.com